有很多资源建议使用高基数属性作为分区键。我的问题是，如果我改为执行与此完全相反的，并为我的所有项提供相同的分区键值(仅通过排序键进行区分(，允许我查询整个表，会发生什么？
这会导致性能和/或热分区问题吗？如果热分区不能达到3000个RCU/1000个WCU，那么它们的自适应容量是否重要？即便如此，如果查询在我的排序键中均匀分布，该怎么办？
共识似乎是我们不应该这样做，但我的问题是：为什么不呢
建议和最佳实践可指导您从使用DynamoDB中获得最大收益。通常，人们使用DynamoDB来存储大量高速数据，这些数据在传统的RDBMS中存在可扩展性问题。
如果您谈论的是聚合访问速度不超过3000 RCU/1000 WCU的少量数据，那么这还不足以让您达到使用DynamoDB的痛点。事实上，如果使用传统的RDBMS，您可能可以实现相同级别的性能。然而，一旦你的应用程序流行起来，或者即使你的应用在5分钟内遇到了峰值，数据量和速度就会迅速增加，你会感到痛苦。这就是为什么遵循最佳实践通常会给你带来这种经得起未来考验的好处。
即便如此，如果查询均匀分布在我的排序键中，该怎么办？
DynamoDB如果集合大小增长到大于10 GB，则按排序键拆分分区。[ref]所以很可能您仍然会遇到热分区问题。
别误会我的意思。有些用例需要使用相同的分区键，例如对数据的一对多和多对多关系进行建模。这些都是有效的用例，因为数据本质上是关系的，这是在DynamoDB中有效建模的唯一方法。然而，如果您选择与文档所建议的完全相反的做法，那么您的可扩展性是有限的，您将无法从DynamoDB中获得全部好处。
好吧，我们开始吧，我将用一个示例应用程序来完成。
假设您正在为加拿大创建人口普查申请。您的分区密钥将是省或地区名称，其中总共有13个iirc。您将初始数据加载到中，一切都很好。你打开它让用户进来。一切都很顺利，但到了晚上，每个人都在家，只收到一张卡片，上面写着他们应该去你的网站。加拿大的人口中心在哪里？安大略省和魁北克省是最多的，它们恰好在同一个表分区中。哎呀。是的，自适应能力会试图拯救你，但在短时间内，现在有成千上万的人(或更多(试图使用你的网站。该分区现在很热，因为它达到了每个分区3000 IOPS的配额，多伦多只有一个分区在线。DynamoDB已经在尝试将项目移动到其他分区，并创建更多的分区来避免您的错误，但您的用户已经被限制了。你选得不好。推特/reddit/等网站现在充斥着我不想在这里引用的恶意评论。与此同时，爱德华王子岛和育空地区的分治根本没有起到多大作用。如果您选择了不同的分区键，或者使用了具有省/地区名称的写碎片，则项目将更均匀地分布，这不会成为问题。
也就是说，在另一种情况下，使用较少的应用程序和较低的基数PK，一切都可能很好。随着应用程序的扩展，你的错误就会变得显而易见。如果它永远不会扩大规模，那么它可能会很好……为什么要这么麻烦呢？
希望你能明白。此外，这种事情并不是DynamoDB独有的。我曾与许多其他数据库合作过，这些数据库在可能存在问题的地方进行分区。至少DynamoDB足够聪明，随着时间的推移，它会试图把你从错误中拯救出来，但为什么要让自己陷入困境呢？
对于一个可扩展的应用程序，你不能假设它的IOPS从未达到。由于每个地区的流量从来都不均匀，一些数据中心的流量可能比另一个高得多。在一些特殊事件中，预计会出现巨大的流量高峰(例如，Alexa设备在圣诞节访问(，在这种情况下，自适应容量会在不确定的延迟下生效，因此您需要提前计划扩大规模，当然，在一开始就要尽量避免潜在的热分区问题。