0

我正在考虑将 S3 用于后端持久存储。

但是，根据架构选择，我预测一些存储桶可能需要存储数十亿个小对象。

假设我使用 UUID 作为键，GET Object 和 PUT Object 在这些条件下将如何执行？我可以期待 O(1)、O(logN) 或 O(n) 的性能吗？

我是否需要重新考虑我的架构并以某种方式细分更大的存储桶以保持性能？我尤其需要尽可能快的对象查找 (GET)。

4

2 回答 2

7

尽管它可能适用于请求量非常大的 S3 客户，但亚马逊确实有一些技巧可以根据 S3 的内部架构充分利用 S3：

  • 按键名按字母数字递增的顺序对特定存储桶执行 PUT 可以减少每个单独调用的总响应时间。以任何排序顺序执行 GET 可以产生类似的效果。对象越小，这可能对整体吞吐量的影响就越大。

  • 从单个客户端执行多个请求时，请使用多线程来启用并发请求执行。

  • 考虑使用一小组字符为键添加散列。十进制哈希效果很好。

  • 考虑使用以不同字母数字字符开头的多个存储桶。这将确保从一开始就进行一定程度的分区。并发 PUT 和 GET 请求的数量越高，这可能产生的影响就越大。

  • 如果您要从 Amazon EC2 实例内对 Amazon S3 发出 GET 请求，您可以通过从 Amazon EC2 内对这些对象执行 PUT 来最大限度地减少这些调用的网络延迟。

资料来源：http ://aws.amazon.com/articles/1904

这是来自 AWS 的一篇很棒的文章，深入探讨了哈希前缀策略，并解释了何时需要和不需要：

http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html

底线：您计划使用 UUID 作为键将数十亿个对象放在一个存储桶中应该没问题。如果您的请求量很大，您可以将其拆分为具有不同前导字符的多个存储桶，以便更好地进行分区。

如果您打算在 AWS 上花很多钱，请考虑与 Amazon 联系并与他们讨论方法。

于 2013-04-03T19:54:45.387 回答
0

S3 就像一个外部磁盘。所以像读/写 GET 或 PUT 将取决于文件对象的大小，而不管磁盘中其他文件的数量。从常见问题页面：

由于 Amazon S3 具有高度可扩展性，并且您只需为使用的内容付费，因此开发人员可以从小处着手并根据需要扩展他们的应用程序，而不会影响性能或可靠性。它被设计为高度灵活：存储您想要的任何类型和数量的数据；读取同一条数据一百万次或仅用于紧急灾难恢复；构建一个简单的 FTP 应用程序，或一个复杂的 Web 应用程序，例如 Amazon.com 零售网站。Amazon S3 让开发人员可以专注于创新，而不是弄清楚如何存储他们的数据。

如果您想知道 S3 文件系统中文件查找的时间复杂度是多少，很难说，因为我不知道它是如何做到的。但至少比 O(n) 好。O(1) if 使用 hash 或 O(logn) if 树。但两者都具有很强的可扩展性。

底线是不要担心这一点。

于 2013-04-03T18:57:10.953 回答