elasticsearch简介和倒排序索引介绍

介绍

咱们为何要用搜索引擎？咱们的全部数据在数据库里面都有，并且 Oracle、SQL Server 等数据库里也能提供查询检索或者聚类分析功能，直接经过数据库查询不就能够了吗？确实，咱们大部分的查询功能均可以经过数据库查询得到，若是查询效率低下，还能够经过建数据库索引，优化SQL等方式进行提高效率，甚至经过引入缓存来加快数据的返回速度。若是数据量更大，就能够分库分表来分担查询压力。

那为何还要全文搜索引擎呢？咱们主要从如下几个缘由分析：

• 数据类型
  全文索引搜索支持非结构化数据的搜索，能够更好地快速搜索大量存在的任何单词或单词组的非结构化文本。
  例如 Google，百度类的网站搜索，它们都是根据网页中的关键字生成索引，咱们在搜索的时候输入关键字，它们会将该关键字即索引匹配到的全部网页返回；还有常见的项目中应用日志的搜索等等。对于这些非结构化的数据文本，关系型数据库搜索不是能很好的支持。

• 索引的维护
  通常传统数据库，全文检索都实现的很鸡肋，由于通常也没人用数据库存文本字段。进行全文检索须要扫描整个表，若是数据量大的话即便对SQL的语法优化，也收效甚微。创建了索引，可是维护起来也很麻烦，对于 insert 和 update 操做都会从新构建索引。

何时使用全文搜索引擎：

1. 搜索的数据对象是大量的非结构化的文本数据。
2. 文件记录量达到数十万或数百万个甚至更多。
3. 支持大量基于交互式文本的查询。
4. 需求很是灵活的全文搜索查询。
5. 对高度相关的搜索结果的有特殊需求，可是没有可用的关系数据库能够知足。
6. 对不一样记录类型、非文本数据操做或安全事务处理的需求相对较少的状况。

Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎.

Elasticsearch 是一个创建在全文搜索引擎 Apache Lucene(TM) 基础上的搜索引擎. 固然 Elasticsearch 并不只仅是 Lucene 那么简单，它不只包括了全文搜索功能，还能够进行如下工做:

分布式实时文件存储，并将每个字段都编入索引，使其能够被搜索。

实时分析的分布式搜索引擎。

能够扩展到上百台服务器，处理PB级别的结构化或非结构化数据。

基本概念

先说Elasticsearch的文件存储，Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档，用JSON做为文档序列化的格式，好比下面这条用户数据：

{"name":"John","sex":"Male","age":25,"birthDate":"1990/05/01","about":"I love to go rock climbing","interests":["sports","music"]}

用Mysql这样的数据库存储就会容易想到创建一张User表，有balabala的字段等，在Elasticsearch里这就是一个文档，固然这个文档会属于一个User的类型，各类各样的类型存在于一个索引当中。这里有一份简易的将Elasticsearch和关系型数据术语对照表:

关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)

Elasticsearch ⇒ 索引 ⇒ 类型 ⇒ 文档 ⇒ 字段(Fields)

一个 Elasticsearch 集群能够包含多个索引(数据库)，也就是说其中包含了不少类型(表)。这些类型中包含了不少的文档(行)，而后每一个文档中又包含了不少的字段(列)。

Elasticsearch的交互，可使用Java API，也能够直接使用HTTP的Restful API方式，好比咱们打算插入一条记录，能够简单发送一个HTTP的请求：

PUT/megacorp/employee/1{"name":"John","sex":"Male","age":25,"about":"I love to go rock climbing","interests":["sports","music"]}

更新，查询也是相似这样的操做，具体操做手册能够参见Elasticsearch权威指南

倒排序索引

Elasticsearch最关键的就是提供强大的索引能力了。

Elasticsearch索引的精髓：

一切设计都是为了提升搜索的性能

另外一层意思：为了提升搜索的性能，不免会牺牲某些其余方面，好比插入/更新，不然其余数据库不用混了:)

前面看到往Elasticsearch里插入一条记录，其实就是直接PUT一个json的对象，这个对象有多个fields，那么在插入这些数据到Elasticsearch的同时，Elasticsearch还默默的为这些字段创建索引–倒排索引，由于Elasticsearch最核心功能是搜索。

Elasticsearch是如何作到快速索引的

InfoQ那篇文章里说Elasticsearch使用的倒排索引比关系型数据库的B-Tree索引快，为何呢？

什么是B-Tree索引?

二叉树查找效率是logN，同时插入新的节点没必要移动所有节点，因此用树型结构存储索引，能同时兼顾插入和查询的性能。

所以在这个基础上，再结合磁盘的读取特性(顺序读/随机读)，传统关系型数据库采用了B-Tree/B+Tree这样的数据结构：

为了提升查询的效率，减小磁盘读取次数，将多个值做为一个数组经过连续区间存放，一次读取多个数据，同时也下降树的高度。

什么是倒排索引?

继续上面的例子，假设有这么几条数据(为了简单，去掉about, interests这两个field):

ID	Name	Age	Sex
1	Kate	24	Female
2	John	24	Male
3	Bill	29	Male

ID是Elasticsearch自建的文档id，那么Elasticsearch创建的索引以下:

Name:

Term	Posting List
Kate	1
John	2
Bill	3

Age:

Term	Posting List
24	[1,2]
29	3

Sex:

Term	Posting List
Female	1
Male	[2,3]

Posting List

Elasticsearch分别为每一个field都创建了一个倒排索引，Kate, John, 24, Female这些叫term，而[1,2]就是Posting List。Posting list就是一个int的数组，存储了全部符合某个term的文档id。

看到这里，不要认为就结束了，精彩的部分才刚开始…

经过posting list这种索引方式彷佛能够很快进行查找，好比要找age=24的同窗，爱回答问题的小明立刻就举手回答：我知道，id是1，2的同窗。可是，若是这里有上千万的记录呢？若是是想经过name来查找呢？

Term Dictionary

Elasticsearch为了能快速找到某个term，将全部的term排个序，二分法查找term，logN的查找效率，就像经过字典查找同样，这就是Term Dictionary。如今再看起来，彷佛和传统数据库经过B-Tree的方式相似啊，为何说比B-Tree的查询快呢？

Term Index

B-Tree经过减小磁盘读取次数来提升查询性能，Elasticsearch也是采用一样的思路，直接经过内存查找term，不读磁盘，可是若是term太多，term dictionary也会很大，放内存不现实，因而有了Term Index，就像字典里的索引页同样，A开头的有哪些term，分别在哪页，能够理解term index是一颗树：

这棵树不会包含全部的term，它包含的是term的一些前缀。经过term index能够快速地定位到term dictionary的某个offset，而后从这个位置再日后顺序查找。

因此term index不须要存下全部的term，而仅仅是他们的一些前缀与Term Dictionary的block之间的映射关系，再结合FST(Finite State Transducers)的压缩技术，可使term index缓存到内存中。从term index查到对应的term dictionary的block位置以后，再去磁盘上找term，大大减小了磁盘随机读的次数。

这时候爱提问的小明又举手了:”那个FST是神马东东啊?”

假设咱们如今要将mop, moth, pop, star, stop and top(term index里的term前缀)映射到序号：0，1，2，3，4，5(term dictionary的block位置)。最简单的作法就是定义个Map<String, Integer>，你们找到本身的位置对应入座就行了，但从内存占用少的角度想一想，有没有更优的办法呢？答案就是：FST(理论依据在此，但我相信99%的人不会认真看完的)

⭕️表示一种状态

–>表示状态的变化过程，上面的字母/数字表示状态变化和权重

将单词分红单个字母经过⭕️和–>表示出来，0权重不显示。若是⭕️后面出现分支，就标记权重，最后整条路径上的权重加起来就是这个单词对应的序号。

FSTs are finite-state machines that map a term (byte sequence) to an arbitrary output.

FST以字节的方式存储全部的term，这种压缩方式能够有效的缩减存储空间，使得term index足以放进内存，但这种方式也会致使查找时须要更多的CPU资源。

后面的更精彩，看累了的同窗能够喝杯咖啡……

---

压缩技巧

Elasticsearch里除了上面说到用FST压缩term index外，对posting list也有压缩技巧。 小明喝完咖啡又举手了:”posting list不是已经只存储文档id了吗？还须要压缩？”

嗯，咱们再看回最开始的例子，若是Elasticsearch须要对同窗的性别进行索引(这时传统关系型数据库已经哭晕在厕所……)，会怎样？若是有上千万个同窗，而世界上只有男/女这样两个性别，每一个posting list都会有至少百万个文档id。 Elasticsearch是如何有效的对这些文档id压缩的呢？

Frame Of Reference

增量编码压缩，将大数变小数，按字节存储

首先，Elasticsearch要求posting list是有序的(为了提升搜索的性能，再任性的要求也得知足)，这样作的一个好处是方便压缩，看下面这个图例：

若是数学不是体育老师教的话，仍是比较容易看出来这种压缩技巧的。

原理就是经过增量，将原来的大数变成小数仅存储增量值，再精打细算按bit排好队，最后经过字节存储，而不是大大咧咧的尽管是2也是用int(4个字节)来存储。

Roaring bitmaps

说到Roaring bitmaps，就必须先从bitmap提及。Bitmap是一种数据结构，假设有某个posting list：

[1,3,4,7,10]

对应的bitmap就是：

[1,0,1,1,0,0,1,0,0,1]

很是直观，用0/1表示某个值是否存在，好比10这个值就对应第10位，对应的bit值是1，这样用一个字节就能够表明8个文档id，旧版本(5.0以前)的Lucene就是用这样的方式来压缩的，但这样的压缩方式仍然不够高效，若是有1亿个文档，那么须要12.5MB的存储空间，这仅仅是对应一个索引字段(咱们每每会有不少个索引字段)。因而有人想出了Roaring bitmaps这样更高效的数据结构。

Bitmap的缺点是存储空间随着文档个数线性增加，Roaring bitmaps须要打破这个魔咒就必定要用到某些指数特性：

将posting list按照65535为界限分块，好比第一块所包含的文档id范围在0~65535之间，第二块的id范围是65536~131071，以此类推。再用<商，余数>的组合表示每一组id，这样每组里的id范围都在0~65535内了，剩下的就好办了，既然每组id不会变得无限大，那么咱们就能够经过最有效的方式对这里的id存储。

细心的小明这时候又举手了:”为何是以65535为界限?”

程序员的世界里除了1024外，65535也是一个经典值，由于它=2^16-1，正好是用2个字节能表示的最大数，一个short的存储单位，注意到上图里的最后一行“If a block has more than 4096 values, encode as a bit set, and otherwise as a simple array using 2 bytes per value”，若是是大块，用节省点用bitset存，小块就豪爽点，2个字节我也不计较了，用一个short[]存着方便。

那为何用4096来区分采用数组仍是bitmap的阀值呢？

这个是从内存大小考虑的，当block块里元素超过4096后，用bitmap更剩空间： 采用bitmap须要的空间是恒定的: 65536/8 = 8192bytes 而若是采用short[]，所需的空间是: 2*N(N为数组元素个数) 小明手指一掐N=4096恰好是边界:

联合索引

上面说了半天都是单field索引，若是多个field索引的联合查询，倒排索引如何知足快速查询的要求呢？

• 利用跳表(Skip list)的数据结构快速作“与”运算，或者
• 利用上面提到的bitset按位“与”

先看看跳表的数据结构：

将一个有序链表level0，挑出其中几个元素到level1及level2，每一个level越往上，选出来的指针元素越少，查找时依次从高level往低查找，好比55，先找到level2的31，再找到level1的47，最后找到55，一共3次查找，查找效率和2叉树的效率至关，但也是用了必定的空间冗余来换取的。

假设有下面三个posting list须要联合索引：

若是使用跳表，对最短的posting list中的每一个id，逐个在另外两个posting list中查找看是否存在，最后获得交集的结果。

若是使用bitset，就很直观了，直接按位与，获得的结果就是最后的交集。

---

总结和思考

Elasticsearch的索引思路:

将磁盘里的东西尽可能搬进内存，减小磁盘随机读取次数(同时也利用磁盘顺序读特性)，结合各类奇技淫巧的压缩算法，用及其苛刻的态度使用内存。

因此，对于使用Elasticsearch进行索引时须要注意:

• 不须要索引的字段，必定要明肯定义出来，由于默认是自动建索引的
• 一样的道理，对于String类型的字段，不须要analysis的也须要明肯定义出来，由于默认也是会analysis的
• 选择有规律的ID很重要，随机性太大的ID(好比java的UUID)不利于查询

关于最后一点，我的认为有多个因素:

其中一个(也许不是最重要的)因素: 上面看到的压缩算法，都是对Posting list里的大量ID进行压缩的，那若是ID是顺序的，或者是有公共前缀等具备必定规律性的ID，压缩比会比较高；

另一个因素: 多是最影响查询性能的，应该是最后经过Posting list里的ID到磁盘中查找Document信息的那步，由于Elasticsearch是分Segment存储的，根据ID这个大范围的Term定位到Segment的效率直接影响了最后查询的性能，若是ID是有规律的，能够快速跳过不包含该ID的Segment，从而减小没必要要的磁盘读次数，具体能够参考这篇如何选择一个高效的全局ID方案(评论也很精彩)