基于Lucene查询原理分析Elasticsearch的性能

摘要： 前言 Elasticsearch是一个很火的分布式搜索系统，提供了很是强大并且易用的查询和分析能力，包括全文索引、模糊查询、多条件组合查询、地理位置查询等等，并且具备必定的分析聚合能力。由于其查询场景很是丰富，因此若是泛泛的分析其查询性能是一个很是复杂的事情，并且除了场景以外，还有不少影响因素，包括机型、参数配置、集群规模等等。

前言

Elasticsearch是一个很火的分布式搜索系统，提供了很是强大并且易用的查询和分析能力，包括全文索引、模糊查询、多条件组合查询、地理位置查询等等，并且具备必定的分析聚合能力。由于其查询场景很是丰富，因此若是泛泛的分析其查询性能是一个很是复杂的事情，并且除了场景以外，还有不少影响因素，包括机型、参数配置、集群规模等等。本文主要是针对几种主要的查询场景，从查询原理的角度分析这个场景下的查询开销，并给出一个大概的性能数字，供你们参考。

Lucene查询原理

本节主要是一些Lucene的背景知识，了解这些知识的同窗能够略过。

Lucene的数据结构和查询原理

Elasticsearch的底层是Lucene，能够说Lucene的查询性能就决定了Elasticsearch的查询性能。关于Lucene的查询原理你们能够参考如下这篇文章：

Lucene查询原理

Lucene中最重要的就是它的几种数据结构，这决定了数据是如何被检索的，本文再简单描述一下几种数据结构：

1. FST：保存term字典，能够在FST上实现单Term、Term范围、Term前缀和通配符查询等。
2. 倒排链：保存了每一个term对应的docId的列表，采用skipList的结构保存，用于快速跳跃。
3. BKD-Tree：BKD-Tree是一种保存多维空间点的数据结构，用于数值类型(包括空间点)的快速查找。
4. DocValues：基于docId的列式存储，因为列式存储的特色，能够有效提高排序聚合的性能。

组合条件的结果合并

了解了Lucene的数据结构和基本查询原理，咱们知道：

1. 对单个词条进行查询，Lucene会读取该词条的倒排链，倒排链中是一个有序的docId列表。
2. 对字符串范围/前缀/通配符查询，Lucene会从FST中获取到符合条件的全部Term，而后就能够根据这些Term再查找倒排链，找到符合条件的doc。
3. 对数字类型进行范围查找，Lucene会经过BKD-Tree找到符合条件的docId集合，但这个集合中的docId并不是有序的。

如今的问题是，若是给一个组合查询条件，Lucene怎么对各个单条件的结果进行组合，获得最终结果。简化的问题就是如何求两个集合的交集和并集。

1. 对N个倒排链求交集

上面Lucene原理分析的文章中讲过，N个倒排链求交集，能够采用skipList，有效的跳过无效的doc。

2. 对N个倒排链求并集

处理方式一：仍然保留多个有序列表，多个有序列表的队首构成一个优先队列(最小堆)，这样后续能够对整个并集进行iterator(堆顶的队首出堆，队列里下一个docID入堆)，也能够经过skipList的方式向后跳跃(各个子列表分别经过skipList跳)。这种方式适合倒排链数量比较少(N比较小)的场景。

处理方式二：倒排链若是比较多(N比较大)，采用方式一就不够划算，这时候能够直接把结果合并成一个有序的docID数组。

处理方式三：方式二中，直接保存原始的docID，若是docID很是多，很消耗内存，因此当doc数量超过必定值时(32位docID在BitSet中只须要一个bit，BitSet的大小取决于segments里的doc总数，因此能够根据doc总数和当前doc数估算是否BitSet更加划算)，会采用构造BitSet的方式，很是节约内存，并且BitSet能够很是高效的取交/并集。

3. BKD-Tree的结果怎么跟其余结果合并

经过BKD-Tree查找到的docID是无序的，因此要么先转成有序的docID数组，或者构造BitSet，而后再与其余结果合并。

查询顺序优化

若是采用多个条件进行查询，那么先查询代价比较小的，再从小结果集上进行迭代，会更优一些。Lucene中作了不少这方面的优化，在查询前会先估算每一个查询的代价，再决定查询顺序。

结果排序

默认状况下，Lucene会按照Score排序，即算分后的分数值，若是指定了其余的Sort字段，就会按照指定的字段排序。那么，排序会很是影响性能吗？首先，排序并不会对全部命中的doc进行排序，而是构造一个堆，保证前(Offset+Size)个数的doc是有序的，因此排序的性能取决于(Size+Offset)和命中的文档数，另外就是读取docValues的开销。由于(Size+Offset)并不会太大，并且docValues的读取性能很高，因此排序并不会很是的影响性能。

各场景查询性能分析

上一节讲了一些查询相关的理论知识，那么本节就是理论结合实践，经过具体的一些测试数字来分析一下各个场景的性能。测试采用单机单Shard、64核机器、SSD磁盘，主要分析各个场景的计算开销，不考虑操做系统Cache的影响，测试结果仅供参考。

单Term查询

这个请求耗费了233ms，而且返回了符合条件的数据总数：5184867条。

对于Tag1="a"这个查询条件，咱们知道是查询Tag1="a"的倒排链，这个倒排链的长度是5184867，是很是长的，主要时间就花在扫描这个倒排链上。其实对这个例子来讲，扫描倒排链带来的收益就是拿到了符合条件的记录总数，由于条件中设置了constant_score，因此不须要算分，随便返回一条符合条件的记录便可。对于要算分的场景，Lucene会根据词条在doc中出现的频率来计算分值，并取分值排序返回。

目前咱们获得一个结论，233ms时间至少能够扫描500万的倒排链，另外考虑到单个请求是单线程执行的，能够粗略估算，一个CPU核在一秒内扫描倒排链内doc的速度是千万级的。

咱们再换一个小一点的倒排链，长度为1万，总共耗时3ms。

{"took":3,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":10478,"max_score":1.0,"hits":...}

Term组合查询

首先考虑两个Term查询求交集：

这个请求耗时21ms，主要是作两个倒排链的求交操做，所以咱们主要分析skipList的性能。

这个例子中，倒排链长度是1万、500万，合并后仍有5000多个doc符合条件。对于1万的倒排链，基本上不进行skip，由于一半的doc都是符合条件的，对于500万的倒排链，平均每次skip1000个doc。由于倒排链在存储时最小的单位是BLOCK，一个BLOCK通常是128个docID，BLOCK内不会进行skip操做。因此即便可以skip到某个BLOCK，BLOCK内的docID仍是要顺序扫描的。因此这个例子中，实际扫描的docID数粗略估计也有几十万，因此总时间花费了20多ms也符合预期。

对于Term查询求并集呢，将上面的bool查询的must改为should，查询结果为：

{"took":393,"timed_out":false,"_shards":{"total":1,"successful":1,"skipped":0,"failed":0},"hits":{"total":5190079,"max_score":1.0,"hits":...}

花费时间393ms，因此求并集的时间是多于其中单个条件查询的时间。

字符串范围查询

这个查询咱们主要分析FST的查询性能，从上面的结果中咱们能够看到，FST的查询性能相比扫描倒排链要差许多，一样扫描500万的数据，倒排链扫描只须要不到300ms，而FST上的扫描花费了3秒，基本上是慢十倍的。对于UUID长度的字符串来讲，FST范围扫描的性能大概是每秒百万级。

字符串范围查询加Term查询

这个例子中，查询消耗时间的大头仍是在扫描FST的部分，经过FST扫描出符合条件的Term，而后读取每一个Term对应的docID列表，构造一个BitSet，再与两个TermQuery的倒排链求交集。

数字Range查询

这个场景咱们主要测试BKD-Tree的性能，能够看到BKD-Tree查询的性能仍是不错的，查找500万个doc花费了500多ms，只比扫描倒排链差一倍，相比FST的性能有了很大的提高。地理位置相关的查询也是经过BKD-Tree实现的，性能很高。

数字Range查询加Term查询

这个结果出乎咱们的意料，居然只须要27ms！由于在上一个例子中，数字Range查询耗时500多ms，而咱们增长两个Term条件后，时间居然变为27ms，这是为什么呢？

实际上，Lucene在这里作了一个优化，底层有一个查询叫作IndexOrDocValuesQuery，会自动判断是查询Index(BKD-Tree)仍是DocValues。在这个例子中，查询顺序是先对两个TermQuery求交集，获得5000多个docID，而后读取这个5000多个docID对应的docValues，从中筛选符合数字Range条件的数据。由于只须要读5000多个doc的docValues，因此花费时间不多。

简单结论

1. 整体上讲，扫描的doc数量越多，性能确定越差。
2. 单个倒排链扫描的性能在每秒千万级，这个性能很是高，若是对数字类型要进行Term查询，也推荐建成字符串类型。
3. 经过skipList进行倒排链合并时，性能取决于最短链的扫描次数和每次skip的开销，skip的开销好比BLOCK内的顺序扫描等。
4. FST相关的字符串查询要比倒排链查询慢不少(通配符查询更是性能杀手,本文未作分析)。
5. 基于BKD-Tree的数字范围查询性能很好，可是因为BKD-Tree内的docID不是有序的，不能采用相似skipList的向后跳的方式，若是跟其余查询作交集，必须先构造BitSet，这一步可能很是耗时。Lucene中经过IndexOrDocValuesQuery对一些场景作了优化。

最后结尾再放一个彩蛋，既然扫描数据越多，性能越差，那么可否获取到足够数据就提早终止呢，下一篇文章我会介绍一种这方面的技术，能够极大的提升不少场景下的查询性能。

阿里云双十一1折拼团活动:已满6人,都是最低折扣了
【满6人】1核2G云服务器99.5元一年298.5元三年 2核4G云服务器545元一年 1227元三年
【满6人】1核1G MySQL数据库 119.5元一年
【满6人】3000条国内短信包 60元每6月
参团地址：http://click.aliyun.com/m/1000020293/

原文连接