本文共 2542 字，大约阅读时间需要 8 分钟。

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

基本概念：

Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档。

{        "_index": "mart_qcsrisk.p_app_order_fact_info_m_eagle201810",        "_type": "p_app_order_fact_info_m",        "_id": "1056480852592209929",        "_score": 1,        "_source": {          "order_u_id": "105648085259220992937460000010",          "coupon_pay": 1,          "d_uuid": "3C0A83B713E2C0868950C0EEB3F16C867CCE3CD5B1192C068BF5E1745E3945D0",          "u_payaccount": "",          "start_time": 1540719638426,          "pay_type": "",          "d_mobile": "18702105709",                 ....                   "rule_list": "",          "adpay_status": 0,          "end_address": "小山沟海鲜坊（水产西路店）",          "u_mobile_type": "iPhone8,1",          "month": "201810"        }      }

支持嵌套对象存储

与关系型数据库概念对应关系

数据库Mysql ： 库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)

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

Elasticsearch的交互，可以使用API，也可以直接使用HTTP的Restful API方式，比如我们打算插入一条记录，可以简单发送一个HTTP的请求

{  "query": {    "bool": {      "must": [        {          "match_all": {}        }      ],      "must_not": [],      "should": [],      "filter": []    }  },  "from": 0,  "size": 10,  "sort": []}

索引

Elasticsearch索引的精髓：一切设计都是为了提高搜索的性能

缺点：为了提高搜索的性能，难免会牺牲某些其他方面，比如插入/更新。

索引的对比：

B+tree

倒排索引：

数据：

倒排索引：

field(字段): name ，age，sex

term（值）：Kate, John, 24, Female

Posting list：int的数组

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

Term Dictionary

Elasticsearch为了能快速找到某个term，将所有的term排个序，二分法查找term，

logN的查找效率

和B-Tree的方式类似啊

Term Index概念

Dictionary的索引，也是一棵树

B-Tree Elasticsearch 通过减少磁盘寻道次数来提高查询性能，直接通过内存查找term。

但是如果term太多，term dictionary也会很大，放内存不现实，于是有了Term Index，就像字典里的索引页一样，A开头的有哪些term，分别在哪页。

Term Index也是一棵树：不需要存下所有的term。

Term Index引入FST压缩技术缓存在内存中。

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

posting list压缩技术：Roaring bitmaps（Bitmap是一种数据结构）

比如：一个posting list [1,3,4,7,10]

对应的bitmap就是：

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

联合索引

相比Mysql中给两个字段独立建立的索引无法联合起来使用，必须对联合查询的场景建立复合索引。

而ES可以任何AND或者OR组合使用索引进行检索。

如果多个field索引的联合查询，倒排索引如何满足快速查询的要求呢？

• 利用跳表(Skip list)的数据结构快速做“与”运算，

• 或者利用bitset按位“与”

跳表：（sorted set）

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

三个posting list需要联合索引：

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

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

总结：查询效率之快的三个重要技术：

mmap(内存映射文件系统)来加载单独需要索引的列(memory mapped byte buffer)；

各种posting list的压缩方案来压缩；

Roaring Bitmap数据结构做逻辑操作；

转载地址：http://zzwzb.baihongyu.com/