DynamoDB 扫描操作的最终一致性与 GSI 查询操作的最终一致性有何区别?

4
我有一个表格,之前我一直在使用Scan API(带有"ConsistentRead": false参数,即最终一致性)来过滤非关键属性。由于成本相当高,现在我决定添加一个全局二级索引(GSI),其中我之前扫描的属性是哈希键,并且我将在此索引上使用Query API。
我知道GSI不支持“写后读”一致性或强一致性。我知道,在使用Scan API时,我也没有使用这种一致性,因为我是按最终一致性的方式进行的。
我担心,反映先前更新或写入GSI所花费的时间,是否与以最终一致性方式扫描表时反映更新和写入所花费的时间差异很大?
例如,以下情况是否可能:
a)扫描
  1. 在表格上调用了PutItem API,即插入了新记录。
  2. 我扫描了表,在50ms后获得了新鲜数据。
b)查询GSI
  1. 在表格上调用了PutItem API,即插入了新记录。
  2. 我查询了索引,在500ms后获得了新鲜数据。
所以,正如您所看到的,500ms与50ms的差异太大了。
我们是否可以在它们的一致性方面有如此大的差异?或者,我们将获得相当类似的值? 我担心这种更改是否会破坏现有的功能。

如果您需要“写入后读取”一致性,那么 DynamoDB 可能不是最合适的工具。如果您的写入操作不如读取操作频繁,可以考虑使用 Aurora 全局数据库。 - Salil
1个回答

1

我自己没有测试过,但是500ms对我来说有点慢。

你看到了文档中警告要正确地配置表格以便可以更新主表和索引吗?

此外,他们提到“几分之一秒”作为预期延迟。

话虽如此,转换到GSI是没有错的。DynamoDB扫描是非常糟糕的实践,并且随着表格的增长只会变得更糟。 GSI性能不取决于您的表格大小。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接