`IN` 指令如何影响 Druid SQL 请求？

Question

Druid Documentation of the IN Filter 没有提到效率。我们遇到了一个 SQL 语句的问题，它一直超时，我认为主要的罪魁祸首是WHERE 子句中的field IN (v, e, r, y, l, o, n, g, l, i, s, t, o, f, i, d, s)。

是否有关于 Druid 中 IN 过滤器效率的文档？如何使用它以及如何不使用它？

我认为这是我们的罪魁祸首的主要原因是IN 列表中的元素列表可能非常大（数千个标识符）并且列表可能每天都在变化（增长）。增长是一两三倍（我不太确定最大值是多少，我怀疑有些客户一天可能会添加多达 10 件新商品），这些年来，有些人最终会增加数千件我们的客户。

我们可以使用JOIN 或将WHERE 转换为计算动态标识符列表。看起来像这样的东西：

`WHERE ... object.customer_id = customer.id AND object.id = id ...`

我想知道 Druid 是如何为我们聚合数据的，以及当更简单的 WHERE ... 子句可能会更好地工作并真正自动聚合结果时，IN 过滤器是否会随着时间的推移导致聚合问题。

我们的查询使用设置为年初至今的时间（即从 1 月 1 日到今天）。

Answer 1

我认为首先检查 druid 生成什么样的查询是明智的。

你能做一个explain plan for select .. WHERE ... object.customer_id = customer.id AND object.id = id ...吗？

druid 会为它生成什么样的查询？您能否也提供这些数据？

我还注意到您没有在查询中指定__time 过滤器。由于 druid 是一个时间序列数据库，您应该始终尝试指定一个时间窗口来搜索它的数据。如果您不指定它，它将需要遍历所有数据。