如何优化DynamoDB表辅助全局索引，以便在保持所有记录可排序的同时均匀分布记录？

Question

关于这个问题，我正在寻找更具体的答案。为了保持这种非主观性，这里有一个完整的思想过程，用于创建一个带有固定点的活动表，可以通过一个快速的示例答案来完成。

为了更好地理解DynamoDB，我正在创建一个个人网站，其中包含来自DynamoDB表的活动提要。目标是均匀分布分区键，同时仍然能够对所有分区键进行排序（我正在努力解决这一部分）。

不同类型的活动包括博客帖子、项目、推特帖子引用、LinkedIn帖子引用等。使用活动类型作为分区键并不明智，因为我的活动权重很高，主要是在推特方面，几乎从不创建博客帖子。

唯一的活动id似乎是在DynamoDB分区中均匀分布活动的最佳选择。但是，这完全取消了对活动进行排序以启动的功能，因为查询需要首先知道分区id。这就是二级全局索引（SGI）将很有帮助的地方。这样，主分区键上就不需要排序键，而是在SGI中配对。

这是我被困的地方。SGI分区键的基础是什么？目前，我正在考虑对所有活动使用一个值“activity”，排序键为“date”，但这是对所有条目的一个分区。单个SGI分区键值是否会限制此项目中的性能？

请注意，这是一个小规模项目。但是，我在构建这个项目时考虑了大型项目，试图在优化分区分布方面创建最好的DynamoDB表，同时仍然保持对所有表记录进行排序的灵活性。

Answer 1

在设计架构时考虑与主表索引相同的GSI（全局辅助索引），因为它们也会受到读/写配置限制，并且还会受到热分区限制，这会给主表带来压力，换句话说，如果您的GSI受到限制，那么您的主表将开始限制请求。

单个SGI分区键值是否会限制此项目中的性能？

完整表的单分区肯定是对DDB可扩展能力的滥用。

目标是均匀分布分区键，同时仍然能够对所有分区键进行排序（我正在努力解决这部分问题）。

您可以使用GSI跨分区排序，但您将再次需要GSI的分区键，如果该分区键分布不够，那么您将遇到我上面提到的问题。

如果建模正确，DDB对于put/get操作非常强大，对于使用一些过滤器的非常简单的查询也非常强大。通常，随着访问的分区键值与表中分区键值总数的比率增加，您将更有效地利用吞吐量。

对于您的特定需求，无法直接从DDB获得可扩展的解决方案，但我们仍然没有多少选择

选项1：

我们可以对数据进行建模，使其在写入时公平分布，并且在回读时需要额外的工作，这种模式也称为跨多个分区键值的随机化。由于您在给定的时间内不想访问特定的项目，这将对我们有效。

想法是创建固定集（比如1到100），从中随机选取一个数字附加到创建日期（不是时间戳），并将创建时间戳作为排序键。

这将在多个随机分区之间分配负载，但会增加读取复杂性，因为您需要查询所有分区并合并以获得该日期的最终排序视图。

选项2：

对冷热数据使用多个表，因为它是基于时间序列的数据。信息请阅读http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html#GuidelinesForTables.TimeSeriesDataAccessPatterns

选项3：

扫描如果我们谈论可伸缩性以及数据增长时，这不是一个好的选择，但对于相当小的数据集，提到它肯定会有所帮助。

这些只是一个不适合您的用例的示例。所以这里有一个思考过程的问题：写下所有的用例和访问模式。弄清楚它们的重要性，哪些是好的，哪些是不好的，看看DDB是否适合它们，不要试图使用DDB，然后再与访问模式的可伸缩性作斗争。

另外，请阅读https://stackoverflow.com/a/38790120/962545，了解在限制自己从DDB获取特定访问模式之前必须问自己的更多问题。

不要忘记阅读最佳实践：http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GuidelinesForTables.html