Amazon S3，存储大量文件（数百万和许多 TB 数据）答案

【问题标题】：Amazon S3, storing large number of files (millions, and many TB of data)Amazon S3，存储大量文件（数百万和许多 TB 数据）
【发布时间】：2015-07-23 09:48:54
【问题描述】：

我将不得不在 S3 中存储数百万个文件（未来将有很多 TB）。有什么限制吗？（不是价格:)），我在问架构限制（比如 - 不要以这种方式存储它，另一种方式会更好/更快）。我的文件在层次结构中

/{country}/{number}/{code}/docs

我检查过我可以保持这种方式（通过 REST 轻松访问它们）（当然我知道 S3 以其他方式将它们保存在内部 - 对我来说并不重要）。那么，是否有任何限制/陷阱？

【问题讨论】：

标签： amazon-s3

【解决方案1】：

S3 没有您可以达到的限制。这些文件实际上并不在文件夹中，它们只是作为位置的字符串。使文件夹结构易于跟踪和组织。

您不想在 S3 中列出“文件夹”内容来查找内容。 S3 提供目录列表的速度很慢，因为它不是真正的目录。

您应该将整个路径 /{country}/{number}/{code}/docs 存储在数据库中，或者逻辑应该是可重复的，以至于您可以确信文件将位于该位置。

James Brady 在这里https://stackoverflow.com/a/394505/4179009 https://stackoverflow.com/a/394505/4179009

【讨论】：

上市有多慢？我不需要列出它。可能仅用于测试或检查目的
拥有 100 个对象，一两秒还不错。但是在生产系统中，您不想尝试列出包含成千上万个对象的文件夹。只是效率不高。
抱歉我来晚了。如果我有很多小文件（例如游戏日志），我是否应该将它们偷偷放入一个存储桶中？而且由于 S3 通过更多操作收取更多费用，我是否应该尝试将多个日志合并到一个大 blob 中并存储/获取它？

【解决方案2】：

在类似路径前缀的情况下，AWS S3 确实有访问 100req/sec 的限制，请参阅官方文档：http://docs.aws.amazon.com/AmazonS3/latest/dev/request-rate-perf-considerations.html

另一方面，分层方法使逻辑变得复杂。权衡取舍取决于您的要求，一个好的选择可以是在 URL 前使用至少 4 个符号长度键（主 id 或哈希键）。如果国家数量有限，请尝试使用多个以国家代码作为存储桶名称的存储桶，如果需要，它还有助于定义特定的物理位置。

【讨论】：