Amazon DynamoDB doc专注于分区密钥统一分发是创建正确数据库体系结构的最重要的一点。另一方面，当事情变为实数时，您会发现您的应用永远不会超出一个分区。也就是说，根据doc：https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.Partitions分区计算公式是
( readCapacityUnits / 3,000 ) + ( writeCapacityUnits / 1,000 ) = initialPartitions (rounded up)
因此，您需要每秒超过1000次写入需求（1 kb数据）从一个分区出来。但根据我对大多数小应用程序的计算，你甚至不需要每秒默认5次写入 - 1就足够了。 （确切地说，如果你的数据超过10Gb，你可以走出一个分区，但它也是一个很大的数字）。
当您意识到创建任何其他索引需要每秒额外写入分配时，问题就变得更加重要。试想一下，我有一些与特定用户相关的数据，例如“帖子”。我创建“帖子”数据表，然后根据亚马逊指南我选择下一个键格式：
partition: id, // post id like uuid
sort: // don't need it
由于没有任何两个帖子具有相同的ID，因此我们不需要排序键。但后来您意识到，您最常见的操作是请求特定用户的帖子列表。所以你需要创建二级索引，如：
partition: userId,
sort: id // post id
但每个二级索引都需要额外的读/写单元，因此这种决策的成本加倍！另一方面，请记住，您只有一个分区，您可能已经拥有这样的主键：
partition: userId
sort: id // post id
这适用于您的目的，并不会使您的成本加倍。所以问题是：我错过了什么吗？可能是分区键比一个分区内的排序键更有效吗？
另外：你可能会说“好吧，现在将userId作为帖子的分区键是可以的，但是当你的应用程序中有100000个用户时，你会遇到缩放问题”。但实际上，问题只是针对某些“过渡”情况 - 当您只有一些分区时，一组活动用户在一个分区中发布，而在另一个分区中则不活动。如果你有成千上万的用户很自然，你有很多用户有活跃的帖子，一个用户的影响是微不足道的，并且统计上他们的帖子由于数字大而均匀地分布在很多分区之间。
如果你确保通过增加RCU/WCU或增加你的数据来确保你不会超过分区限制，我认为它绝对没问题。此外，best practices说
如果该表完全适合单个分区（考虑到数据随时间的增长），并且如果您的应用程序的读写吞吐量要求不超过单个分区的读写能力，那么您的应用程序不应该遇到由于分区而导致的任何意外限制。