elasticsearch filter bitset
关于elasticsearch filter bitset的全部
在使用ES进行查询时,你常常会发现自己深深地陷入了过滤器的各种复合中。假设你需要过滤满足下面要求的用户:
bitset
首先需要看看bitset如何工作的。基本上,bitset是一个表示状态的列表。每个位置非0即1.
过滤器不对文档打分——仅仅是包含或者拒绝。如果文档匹配了一个过滤器,则在bitset中会置成1;否则置为0.于是ES就可以在一个紧致的bitset中存储整个分段的过滤信息。
ES第一次执行过滤器时,他解析了Lucene的分段数据结构来判断哪些东西匹配了你的过滤器。而且会将这个信息存放在一个Bitset中。
下次同样的过滤器执行时,ES可以找到压缩后的Bitset而不是Lucene分段。这将带来性能的巨大提升。
我喜欢bitset的原因
怎么说bitset快都不为过
按bit进行操作是一个基础的计算单元,CPU专门设计为按照按bit操作的。执行一个内存中的按位AND比解析Lucene数据结构和手动地执行交集操作要快好几个数量级。
拥有多个过滤器时,可以进行AND操作来获得最终匹配的文档。
更好的是,bitset独立于查询本身进行cache。复杂的查询可以用一堆过滤器,但是这些过滤器bitset是独立的并且可以在其他的上下文环境中进行使用。这就使得ES重用过滤器非常高效。
而且因为bitset针对每个segment进行存储,ES可以做出一些非常酷的性能技巧。Lucene分段是不可变的——一旦写入磁盘,便永不改变
如果一个特定的过滤器不匹配一个分段中的任何文档(bitset中所有位置都是0),ES可以在其执行过滤操作时忽略整个bitset。
类似的,当新的分段被加进来时,缓存的过滤bitset不需要被关闭。如果你索引新的文档进入一个mysql表,例如B-Tree索引是不断地进行更新的。
使用ES过滤器缓存,只有新创建的分段需要构建过滤器bitset,老的bitset可以不需要修改进行重用。
boolean 还是 and/or/not
“可是这跟我有啥关系呢?”你也许会问。
当然重要了,因为bool过滤器使用了Bitset而and/or/not过滤器没有/如果你将一个term过滤器放入一个and中,尽管它存在,也不会用到Bitset。
为什么?
and/or/not是一个文档一个文档进行的。首先会载入需要放入field数据内存池中,然后对这些文档进行遍历。不会有bitset被使用,也就不会有缓存的过滤器重用复合了。ES简单地扫描文档的列表,并独立地检查每个。
如果你有多个过滤器,and/or/not将进行短路操作,只会传递匹配的文档进入下一个过滤器。
这个会降低每个后续的需要执行的过滤器工作量。因此,你最重的过滤器应该放到最后位置——典型例子是Geo过滤因为他们会进行相当重的计算来确定距离。
什么时候使用and/or/not
看起来Bool过滤器在任何方面都超过了对手,那么有没有什么时候需要使用and/or/not呢?
and/or/not在你使用哪些不返回bitset的过滤器时更有效率。这些操作肯定需要对每个文档进行一遍。例如,定制的script不是可以bitset化,因为它对每个文档进行计算。
在这些情形下,and/or/not是比bool更好的选择。Non-Bitset
过滤器非常少,下面列出来:
- Geo* filter
- Scripts
- Numeric_range
其他的过滤器都应该放在一个bool中
把bool和and/or/not结合起来
当你遇到需要用到这两者的情形时,可以将他们合起来使用。总是使用一个and/or/not整合起来。例如,你有这样的数据:
- Gender: Male
- Age: 23-26
- Language: English
- Custom Script
- Geo
你过滤器列表看起来就是这样:
{ "and" : [ { "bool" : { "must" : [ { "term" : {} }, { "range" : {} }, { "term" : {} } ] } }, { "custom_script" : {} }, { "geo_distance" : {} } ] }
总结
过滤器让我们可以找到想要的文档,通过使用bitset操作来代替简单的排除操作来提高查询性能。当我们整合过滤器时,确保你花了时间来考虑如何组织他们来使用合适的聚合过滤器的类:
- Geo, Script or Numeric_range filter: Use And/Or/Not Filters
- Everything else: Use Bool Filter
from http://www.jianshu.com/p/627a4459975d