现在我使用ES来进行聚合。基本逻辑可以表示为
select count(*)
from
(select key, count(*) from table where *** 按键分组,其计数(*)>c)z,这里的where过滤器条件是由最终用户指定的,这意味着我不能做任何预工作。我用桶选择器实现了逻辑。
但是,在我的例子中,通常有几百万个不同的键,这意味着有几百万个按ES返回的桶,默认情况下按其doc_count排序。这很费时。我不知道是否有一些策略可以加速查询,例如关闭排序。
发布于 2016-06-04 12:27:04
如果我正确理解,您的查询将执行以下操作:
key对所有条目进行分组count <= c那么SELECT key, count(*)就没用了,因为它再也不会被使用了。您可以简单地使用SELECT 1。
这个查询根本不需要排序。
基本上有3种方法可以加快查询的速度:
STORE 2中看到的数据相同的数据。当然,这样您将始终必须交付旧的数据,但它将加快的事情!- When a new document is getting inserted: Get its key, and increment the number.
- When a document is getting deleted: Get its key, and decrement the counter.
然后基本上有两个存储:一个用于实际文档,一个用于聚合数据,即
STORE 1:
[
{id: 1, key: foo, ...},
{id: 2, key: foo, ...},
{id: 3, key: bar, ...},
{id: 4, key: baz, ...}
]
STORE 2:
[
{id: foo, counter: 2},
{id: bar, counter: 1},
{id: baz, counter: 1}
]这样,您就可以在从STORE 1中插入/删除文档时进行聚合。当然,这在插入/删除过程中更耗时,因为每次都必须触摸2个数据存储。
但是现在您可以简单地计数来自STORE 2的条目以获得结果。这将极大地提高此操作的查询性能。
你看:这总是一种权衡。你必须决定你需要什么:
https://stackoverflow.com/questions/37627814
复制相似问题