如何优化我的DynamoDB表的次全局索引，以便记录均匀分布，同时保持所有记录可排序？
如何优化我的DynamoDB表的次全局索引，以便记录均匀分布，同时保持所有记录可排序？
和这个问题有关，我正在寻找更具体的答案。为了使这个问题非主观化，我将提供一个完整的思路，创建一个包含活动的表，并提供一个可以通过快速示例回答的困难点。\n为了更好地理解DynamoDB，我正在创建一个个人网站，其中包含来自DynamoDB表的活动动态。目标是在仍然能够对所有分区键进行排序的同时，均匀分配分区键（我在这一点上遇到了困难）。\n不同类型的活动包括博客文章、项目、Twitter帖子引用、LinkedIn帖子引用等。使用活动类型作为分区键并不明智，因为我的活动主要集中在Twitter方面，几乎不写博客文章。\n一个唯一的活动ID似乎是在DynamoDB分区中均匀分布活动的最佳选择。然而，这完全取消了对活动进行排序的能力，因为查询需要首先知道分区ID。这就是次全局索引（SGI）的作用。借助次全局索引，主分区键上不需要排序键，而是与次全局索引配对。\n这就是我被卡住的地方。我应该以什么为基础来创建次全局索引的分区键？目前我正在考虑为所有活动使用一个唯一值\"activity\"作为分区键，使用\"date\"作为排序键，但这是一个单一分区的所有条目。一个单一的次全局索引分区键值会限制这个项目的性能吗？\n请注意，这是一个小规模的项目。然而，在构建这个项目时，我考虑到了大规模项目，试图创建最佳的DynamoDB表，以实现优化的分区分布，同时仍然保持对所有表记录的灵活排序。
在设计模式时，将GSI（全局次要索引）视为主表索引，因为它们也具有读/写预配限制，并且也会受到热分区限流的影响，这会对主表产生背压，换句话说，如果GSI被限流，那么主表将开始限流请求。
单个SGI分区键值是否会限制项目性能？
完整表的单个分区肯定会滥用DDB的可伸缩能力。
目标是在仍然能够对所有分区键进行排序的情况下均匀分布分区键（我在这一部分有困难）。
您可以使用GSI在分区之间进行排序，但是您仍然需要GSI的分区键，如果该分区键分布不足，则会遇到我上面提到的问题。
如果正确建模并具有一些过滤器的相当简单的查询，DDB对于put/get操作非常强大。通常，当访问的分区键值与表中的分区键值总数的比值增加时，您将更有效地利用吞吐量。
对于您的特定需求，从DDB直接获得可伸缩解决方案是不可能的，但我们仍然有一些选择。
选项1：
我们可以对数据进行建模，以便在写入时它是相当分布的，并且在读取时需要额外的工作，这种模式也称为跨多个分区键值的随机化。由于您不希望在给定时间访问特定项，因此这对我们有用。
思路是创建一个固定集合（例如1到100），并从中随机选择一个数字附加到创建日期（而不是时间戳），并将创建时间戳作为排序键。
这将将负载分布到多个随机分区，但会增加读取复杂性，因为您需要查询所有分区并合并以获取该日期的最终排序视图。
选项2：
根据时间序列的数据，使用多个表用于热数据和冷数据。有关详细信息，请阅读
选项3：
扫描？如果我们谈论可伸缩性和数据增长时，这不是一个好选择，但对于相当小的数据集，它肯定有帮助，所以我提到它。
这些只是示例，不一定适合您的用例。
所以，这是一个思考问题：写下所有用例和访问模式。找出它们的重要性，哪些可以接受最终一致性，哪些不行，并查看DDB是否适合它们的第一个地方，请不要诱使自己使用DDB，然后为所需的访问模式而苦苦挣扎。
在限制自己使用DDB的特定访问模式之前，请务必阅读最佳实践：http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html
这个答案非常有帮助。