DynamoDB 跟踪 2 个表之间的执行
DynamoDB keep track of execution between 2 tables
我有一个 Lambda，它向服务发出 API 请求并获取给定标识符的匹配列表。
一旦获得匹配列表，它就会按以下方式更新 DynamoDB table：
requestId (partitionKey)
ID
matches
status
uuid1
ID1
[match1,match2, match3...]
FOUND_MATCHES
对于此 table 中的每个匹配项，都会向 SQS 发送一条消息，由 Lambda 侦听。对于每场比赛，Lambda 将调用不同的服务并更新一个 table 来跟踪比赛的执行。
Match (partitionKey)
requestId (sortKey + GSI Partition Key)
match1
uuid1
match2
uuid1
...
...
match10
uuid1
现在给定 requestId，我想知道第二个 table 中是否有所有匹配项。
我想的一个选项是通过 requestId 查找第一个 table，它会给出匹配列表，然后它会通过主键多次调用第二个 table , sortKey 组合并编译出一个结果。另一个选项不是通过主 key/sort 键查找第二个 table，而是通过 requestId 列上的 GSI Parition 键查找并一次获取所有匹配项（在分页列表中）。
我想通过 API 调用公开此操作，我想知道我是否会 运行 进入 APIG 30 秒超时（我知道我'我将需要 运行 对我的数据集进行一些实验，但只是想看看在执行此操作之前是否还有其他我可以考虑的选项）。如果匹配数超过 50,000。每个 get 调用大约需要 20 毫秒，大约需要 50,000 * 20 = 1000 秒，这远远超过 APIG 限制。也许批量调用可能有点帮助，但不确定那里有多少空间。
基本上我想将第一个 table 中的状态从 FOUND_MATCHES 更新为 ALL_MATCHES_PROCESSED。
- 理想的选择是自动更新状态
- A Get status API 本质上触发计算并更新状态（也许使这个异步超过 30 秒 APIG 限制）
我可能会这样做，因为我是单一 table 设计模式的粉丝：
PK
SK
type
attributes
REQ#<id>METAREQUEST
matches: [a,b,c]; unprocessed_matches: 3; status: FOUND_MATCHES
REQ#<id>M#aMATCH
result
REQ#<id>M#bMATCH
result
REQ#<id>M#cMATCH
result
每当收到新请求时，您将 REQUEST 写入包含匹配项的 table 和计算所有匹配项的 unprocessed_matches 属性。
然后你有一个 Lambda 函数“stream-processor”，它监听 table 的流。
当出现 new REQUEST 项目时（不存在旧图像），它会在您的 SQS 队列中创建任务。
您的 SQS 队列上的工作进程然后调用第 3 方 API 并记录结果。
然后通过带有两项的事务将结果写入table：
- 一个
UpdateItem 调用，将请求 ID 的 unprocessed_matches 值减一。
- 一个
PutItem 调用，创建 MATCH 项。
此处的交易很重要，您希望这是一个全有或全无的操作。
你的流处理器 lambda 有第二份工作。
每当 REQUEST 项目有更新时，它应该检查是否 unprocessed_matches <= 0 and status = FOUND_MATCHES。
在这种情况下，它应该更新 REQUEST 项目并将状态设置为 ALL_MATCHES_PROCESSED.
您发出第一个请求的原始 Lambda 可以定期轮询 table 中项目的状态。
这种设计还让您可以通过简单的 Query 到具有请求 ID 的分区键来轻松获取有关请求的所有信息。
您应该知道 DynamoDB 中有 400KB 的项目大小限制，这取决于您的匹配列表的长度，这可能会成为一个问题。
我有一个 Lambda，它向服务发出 API 请求并获取给定标识符的匹配列表。 一旦获得匹配列表，它就会按以下方式更新 DynamoDB table：
| requestId (partitionKey) | ID | matches | status |
|---|---|---|---|
| uuid1 | ID1 | [match1,match2, match3...] | FOUND_MATCHES |
对于此 table 中的每个匹配项，都会向 SQS 发送一条消息，由 Lambda 侦听。对于每场比赛，Lambda 将调用不同的服务并更新一个 table 来跟踪比赛的执行。
| Match (partitionKey) | requestId (sortKey + GSI Partition Key) |
|---|---|
| match1 | uuid1 |
| match2 | uuid1 |
| ... | ... |
| match10 | uuid1 |
现在给定 requestId，我想知道第二个 table 中是否有所有匹配项。
我想的一个选项是通过 requestId 查找第一个 table，它会给出匹配列表，然后它会通过主键多次调用第二个 table , sortKey 组合并编译出一个结果。另一个选项不是通过主 key/sort 键查找第二个 table，而是通过 requestId 列上的 GSI Parition 键查找并一次获取所有匹配项（在分页列表中）。
我想通过 API 调用公开此操作，我想知道我是否会 运行 进入 APIG 30 秒超时（我知道我'我将需要 运行 对我的数据集进行一些实验，但只是想看看在执行此操作之前是否还有其他我可以考虑的选项）。如果匹配数超过 50,000。每个 get 调用大约需要 20 毫秒，大约需要 50,000 * 20 = 1000 秒，这远远超过 APIG 限制。也许批量调用可能有点帮助，但不确定那里有多少空间。
基本上我想将第一个 table 中的状态从 FOUND_MATCHES 更新为 ALL_MATCHES_PROCESSED。
- 理想的选择是自动更新状态
- A Get status API 本质上触发计算并更新状态（也许使这个异步超过 30 秒 APIG 限制）
我可能会这样做，因为我是单一 table 设计模式的粉丝：
| PK | SK | type | attributes |
|---|---|---|---|
REQ#<id> |
META |
REQUEST | matches: [a,b,c]; unprocessed_matches: 3; status: FOUND_MATCHES |
REQ#<id> |
M#a |
MATCH | result |
REQ#<id> |
M#b |
MATCH | result |
REQ#<id> |
M#c |
MATCH | result |
每当收到新请求时，您将 REQUEST 写入包含匹配项的 table 和计算所有匹配项的 unprocessed_matches 属性。
然后你有一个 Lambda 函数“stream-processor”，它监听 table 的流。
当出现 new REQUEST 项目时（不存在旧图像），它会在您的 SQS 队列中创建任务。
您的 SQS 队列上的工作进程然后调用第 3 方 API 并记录结果。 然后通过带有两项的事务将结果写入table：
- 一个
UpdateItem调用，将请求 ID 的 unprocessed_matches 值减一。 - 一个
PutItem调用，创建MATCH项。
此处的交易很重要，您希望这是一个全有或全无的操作。
你的流处理器 lambda 有第二份工作。
每当 REQUEST 项目有更新时，它应该检查是否 unprocessed_matches <= 0 and status = FOUND_MATCHES。
在这种情况下，它应该更新 REQUEST 项目并将状态设置为 ALL_MATCHES_PROCESSED.
您发出第一个请求的原始 Lambda 可以定期轮询 table 中项目的状态。
这种设计还让您可以通过简单的 Query 到具有请求 ID 的分区键来轻松获取有关请求的所有信息。
您应该知道 DynamoDB 中有 400KB 的项目大小限制，这取决于您的匹配列表的长度，这可能会成为一个问题。