Indexing 如何在DynamoDB中实现可伸缩的无序集合？

我正在考虑在AmazonDynamodB上实现一个可伸缩的无序对象集合。到目前为止，已经考虑了以下选择：

使用DynamoDB文档数据类型（映射、列表）并使用文档路径访问独立项。这有一个明显的缺点，即收集的数据限制为400KB，这意味着根据对象的大小可能有1..10K个对象。不太明显的缺点是，在这样的集合中插入新对象的成本将是巨大的：Amazon指定写入容量将根据项目的总大小扣除，而不仅仅是新添加的对象——因此，当接近大小限制时，插入1KB对象的容量约为400个。那么考虑到这一点，我们排除了吗

使用复合主散列+范围键，其中主散列对集合中的所有对象保持不变，范围键只是随机的或原子计数器。明显的缺点是具有相同的散列键会导致错误的键分布——当存在具有大量对象的集合时，基数很低。这意味着分区不好，同一个集合上的所有读/写操作都被固定在一个碎片上，这会导致DynamoDB分区每秒3000次读/1000次写的限制

使用全局二级索引和二级哈希+范围键，其中哈希键对于属于同一集合的所有对象保持不变，范围键只是随机的或原子计数器。与上面类似，GSI的分区变得很差，并且由于太多相同的散列将所有配置的容量迅速消耗到索引中，这将成为瓶颈。我没有发现GSI是如何具体实现的，因此不确定它受到低基数的影响有多严重

问题是，我是否可以与（2）或（3）共存，并遭受非理想密钥分发，或者是否有另一种实现被忽略的集合的方式，或者也许我应该考虑查看另一个NoSQL数据库引擎。

< P>这是一个“从臀部拍摄”的答案，你最终做什么可能取决于你做了多少，以及你做了什么类型的阅读和写作

dynamo文档鼓励您避免的两件事是热键和扫描。您注意到，在案例（2）和（3）中，您最终会得到一个热键。如果您希望它能够扩展（大型集合），那么热键可能会对您造成越来越大的伤害，特别是在这是一个写密集型应用程序的情况下

关于查询和扫描操作的文档（）说，对于查询，“必须将散列键属性名称和值指定为相等条件。”因此，如果要避免扫描，这可能仍然会迫使您重新进入热键状态

也许其中一种方法是接受扫描操作，但只需要一张桌子专门用于收集。然后，您可以使用一个完全随机（分布均匀）的散列键，并每次进行扫描。这假设您总是想要收藏中的所有东西（您没有说）。如果你扩大到一个大的集合，这仍然会造成伤害，但是如果你总是想要全部的设置，你将不得不处理这种痛苦。如果只需要一个子集，可以添加一个限制参数。这将有助于提高性能，但您将始终返回相同的子集（或者您可以使用最后计算的键并继续）。这些文件还提到了并行扫描

如果您使用的是AWS，elasticache/redis可能是另一种尝试的途径？第一步可能比您提到的情况（1）更快/更清晰地编写代码