query-optimization - QLDB sum() 函数是否已优化？

Question

我们想使用该SUM()函数查询我们的 QLDB 分类帐（带有WHERE仅引用索引字段的子句）。例如，

select count(*), sum(NonIndexedField) from myTable where IndexedField1 = "foo" and IndexedField2 = "bar";

这是一个好还是坏的查询模式？此页面上的指南讨论了该COUNT()功能未优化的原因，这也让我对该SUM()方法产生了怀疑。

Answer 1

动漫，

总体而言，您的查询遵循良好的模式，因为它主要依赖于与索引 (IndexedField1) 的相等比较。但是，如果有数千个 IndexedField1 = "foo" 的文档，您的查询可能会运行缓慢甚至超时。如果 IndexedField2 = "bar" 的文档少于 IndexedField1 = "foo"，则将 IndexedField2 比较放在 WHERE 子句中。QLDB 可能会尝试使用这两个索引，但最左边的索引是最重要的。

除了性能之外，如果在索引命中后有大量文档要扫描，您可能会遇到的另一个问题是 OCC 异常。如果另一个进程插入/更新/删除 IndexedField1 值为“foo”或 IndexedField2 值为“bar”的文档，那么您的聚合查询将获得 OCC 异常。这通常不是问题，因为驱动程序只会重试，但如果冲突频率很高并且该频率随着事务范围内的文档数量而增加，则它可能会成为一个感知的性能问题。我们建议您尽可能缩小交易范围。

一般来说，QLDB 使用与索引值进行相等比较，针对少量数据的写入和目标提取进行了优化。这对于通知交易决策的验证读取非常有用（我的帐户是否有足够的余额，此记录是否已经存在，给我由唯一 ID 'X' 标识的客户记录等）。随着事务范围内文档数量的增加，OCC 和事务超时的可能性也会增加。我们通常建议您将数据从 QLDB 流式传输到辅助数据库，以支持 OLAP、报告、即席查询等。

所以真正的答案是您的查询看起来不错，但您应该考虑您的数据集现在、明年等在生产中的样子，并对其进行测试以确保您可以继续使用。