我们正在创建一个网站，用户可以上传可分类和搜索的图片。
我的问题是围绕其存储的图像，什么才能成为可靠的可维护解决方案？
我看过S3 - 看起来很有希望。
如果S3是一个不错的选择，我会在哪里存储对象的引用（以及元数据/标签）？
谢谢：）
答案 0 :(得分：2)
如果我正在构建这样一个系统，那么在某种程度上实际存储图像 - 和缩略图 - 以及元数据的可扩展性和持久性我当然不会比S3更好。
S3元数据存储限制为2KB（所有键的总字节数和所有值组合在一起），仅限于US-ASCII，并且未编入索引 - 您必须获取特定对象的元数据。对于许多应用程序来说，这已经足够了，但在您的情况下这是非常值得怀疑的。
http://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMetadata.html#object-metadata
因此，问题“S3是一个很好的选择”很容易回答：如果您在AWS服务中表示答案是肯定的，那么很难说这是最合适的。
您也可以考虑使用CloudFront - 而不是S3，而不是S3。它可以通过将“流行”内容缓存到更靠近用户所在位置等方式来缩短加载时间。
存储对象的引用的位置进入“基于意见”的土地，我们在Stack Overflow上没有这样做。答案当然是“在数据库中”，但AWS在这里有选择。
我是一个关系数据库DBA，所以当然，我的意思是一切都应该有一个关系数据库（比如RDS）作为它的权威数据存储，而其他人可能会说DynamoDB NoSQL数据库产品会很有用数据存储。
从那里（“那里”），CloudSearch可以填充元数据，关键字等，用于处理实际的搜索操作，使用它构建的索引，这些索引更有可能更适合搜索密集型操作。适当的数据库但是，我不会尝试使用CloudSearch作为所有宝贵元数据的权威存储。搜索索引应该被视为一次性的，可重建的资产......虽然我担心即使这种说法可能会使一些人认为是基于意见的。
有一点不是意见问题，所有这些不同的云服务都允许您以几年前难以想象的低成本启动大量的概念验证基础架构。 ...所以你可以尝试它们，和它们一起玩，如果它们没有达到预期的效果就扔掉它们。在尝试之前不必购买。