【问题标题】:Dynamodb data model for process/transaction monitoring用于流程/事务监控的 Dynamodb 数据模型
【发布时间】:2017-09-15 15:12:36
【问题描述】:

我想跟踪多阶段处理工作。

可能只需要以下字段

batchId (guid) | eventId (guid) | statusId (int) | timestamp | message (string)

每批次的事件数量相对较少。

我希望能够轻松查询 statusId 小于 n 的事件(仍在处理或未完成处理)。

对于每个状态更改使用多行并查询最新状态是最好的方法吗?我会使用全局二级索引,但 StatusId 似乎不太适合 hashkey(少于 10 个状态)。

【问题讨论】:

    标签: amazon-dynamodb data-modeling nosql


    【解决方案1】:

    如果您更新同一事件行,而不是为每个状态更改使用多行,则可以使用“使用计算值”部分中DynamoDB documentation 中描述的技术。基本上,这将涉及添加另一个属性(例如“derivedStatusId”),该属性将通过在写入 DynamoDB 时向 statusId 附加一个随机数来派生。例如,对于 2 的 statusId,derivedStatusId 可以是 {"2-00", "2-01", .. "2-99"} 之一。在 derivedStatusId 上设置全局二级索引会给你一些扇出,这将有助于防止索引变热。

    如果您确定要将此索引用于未完成的事件,那么当记录转换为已完成状态时,从记录中删除 derivedStatusId 属性也会将其从索引中删除 - 这可能如果预计事件最终会完成处理,并且如果它们永远存在,那么它是一个很好的属性。这种技术称为“稀疏索引”,在here 中有更详细的描述。

    从您的问题来看,保持状态历史记录似乎是一个理想的属性(我假设这是因为您希望有多行用于状态更改)。考虑将这些历史信息放在同一行中。 DynamoDB 支持列表数据类型,并且还具有 400KB 的项目限制,这可能只允许您在同一记录中捕获所有所需的历史信息。

    【讨论】:

    • 在 derivedStatusId 上的全局二级索引:statusId+(eventId mod n) 会使其不热,但仍需要执行 n 次查询才能使所有项目正确?
    • 扫描这个稀疏的全局二级索引的性能如何?因为我想扫描会适用于我的用例,因为任何时候都不会有很多未完成的项目。
    • 如果你像上面提到的那样从索引中删除完成的项目,扫描会非常有效,因为全局二级索引只会包含未完成的项目。
    猜你喜欢
    • 2021-11-08
    • 1970-01-01
    • 1970-01-01
    • 2011-07-30
    • 2018-11-22
    • 2016-05-23
    • 2016-02-16
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多