我们有一个设置，其中各种工作程序节点在DynamoDB表中执行计算并更新它们的相对状态。该表充当一种工作节点活动的历史记录。看门狗节点需要定期扫描表，并建立一个代表工作程序节点及其作业的当前状态的对象。因此，对于我们的应用程序来说，能够按时间顺序扫描表并检索数据（即按时间戳排序）非常重要。该表最终将太大，无法扫描到本地内存中以供以后排序，因此我们无法在扫描后对其进行排序。
从AWS documentation中读取有关主键的信息：
DynamoDB使用分区键值作为内部哈希的输入 功能。哈希函数的输出确定分区 （DynamoDB内部的物理存储）项将在其中 存储。具有相同分区键的所有项目都存储在 按排序键值排序的顺序。
有关扫描功能的文档似乎没有提及返回结果的顺序。但是，上面引用中的最后一部分（我用黑体强调的那部分）是否可以解释为扫描结果是按排序键排序的？如果将所有分区键设置为相同的值，例如“ 0”，然后将时间戳记用作排序键，是否可以保证扫描操作将按时间顺序返回数据？
一些注意事项：
答案 0 :(得分：0)
从技术上讲SCAN从不保证顺序（尽管作为观察，缺少顺序保证似乎意味着该分区是随机排序的，但是排序仍然很好地进行了排序。）< / p>
您提出的 可以工作，但是您无需扫描，而是在partition-key == 0上执行 query ，然后返回所有分区键为0的项目（最多limit，并且可选的向前/向后排序）按排序键排序。
也就是说，这确实不是发电机要您使用它的方式。例如，它保证您的分区将运行热（因为您已将所有内容明确地放置在相同分区上），并且此操作将使您失去读取每个项目的能力。在桌子上。
我建议研究一些模式，例如使用由lambda处理的动力发电机流来构建和维护此“当前状态”的实体化视图，而不是通过这种昂贵的扫描和不良的键设计来“轮询”表。 / p>
答案 1 :(得分：0)
最好使用yyyy-mm-dd作为分区键，而不要使用全部0。每个分区的数据限制为10 GB，这也意味着每个分区键值的数据量不能超过10 GB。
如果您希望能够检索按日期排序的数据，请采用ISO 8601时间戳格式（大约为yyyy-mm-ddThh-mm-ss.sss），将其拆分为适合您数据的位置，然后将第一部分用作分区键，然后第二部分作为排序键。 （这种方法的另一个优点是，您可以对大多数查询使用最终一致的读取，因为可以肯定的是，假设一天（或一个小时左右）后数据已完全复制。）
如果可以管理它，最好使用Worker ID或Job ID作为分区键，然后可以使用完整时间戳作为排序键。
正如@thomasmichaelwallace所提到的，最好使用DynamoDB streams with Lambda创建实例化视图。
现在，要说的是，如果您要处理在工人身上执行的工作，那么您还应该考虑是否可以通过使用工作流服务而不是数据库来实现您的目标。工作流程将为您维护工作历史和/或当前状态。 AWS提供了Step Functions和Simple Workflow。