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  ⇒ 索引(Index)   ⇒ 类型(type) ⇒ 文档(Docments)  ⇒ 字段(Fields) 

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

Node与Cluster

Elastic 本质上是一个分布式数据库，允许多台服务器协同工作，每台服务器可以运行多个 Elastic 实例。

单个 Elastic 实例称为一个节点（node）。一组节点构成一个集群（cluster）。

Index

Elastic 会索引所有字段，经过处理后写入一个反向索引（Inverted Index）。查找数据的时候，直接查找该索引。

所以，Elastic 数据管理的顶层单位就叫做 Index（索引）。它是单个数据库的同义词。每个 Index （即数据库）的名字必须是小写。

下面的命令可以查看当前节点的所有 Index。

$ curl -X GET 'http://localhost:9200/_cat/indices?v'

Type

Document 可以分组，比如weather这个 Index 里面，可以按城市分组（北京和上海），也可以按气候分组（晴天和雨天）。这种分组就叫做 Type，它是虚拟的逻辑分组，用来过滤 Document。

不同的 Type 应该有相似的结构（schema），举例来说，id字段不能在这个组是字符串，在另一个组是数值。这是与关系型数据库的表的一个区别。性质完全不同的数据（比如products和logs）应该存成两个 Index，而不是一个 Index 里面的两个 Type（虽然可以做到）。

下面的命令可以列出每个 Index 所包含的 Type。

$ curl 'localhost:9200/_mapping?pretty=true'

根据规划，Elastic 6.x 版只允许每个 Index 包含一个 Type，7.x 版将会彻底移除 Type。

Document

Index 里面单条的记录称为 Document（文档）。许多条 Document 构成了一个 Index。

Document 使用 JSON 格式表示，下面是一个例子。

{

  "user": "张三",

  "title": "工程师",

  "desc": "数据库管理"

}

同一个 Index 里面的 Document，不要求有相同的结构（scheme），但是最好保持相同，这样有利于提高搜索效率。

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权威指南。

倒排索引到底是啥？

假如说你现在不用搜索引擎，单纯使用数据库来存放和搜索一些数据，比如说放了一些论坛的帖子数据吧，那么这个数据的格式大致如下：

那么这个时候，比如我们要是用数据库来进行搜索包含“Java”这个关键字的所有帖子，大致SQL如下：

咱们姑且不论这个数据库层面也有支持全文检索的一些特殊索引类型，或者数据库层面是怎么执行的，这个不是本文讨论的重点，你就看看数据库的数据格式以及搜索的方式就好了。但是如果你通过搜索引擎类的技术来存放帖子的内容，他是可以建立倒排索引的。也就是说，你把上述的几行数据放到搜索引擎里，这个倒排索引的数据大致看起来如下：

关键词    id

Java      [1, 2, 3]

语言      [1]

面试      [3]

资源      [2]

所谓的倒排索引，就是把你的数据内容先分词，每句话分成一个一个的关键词，然后记录好每个关键词对应出现在了哪些id标识的数据里。那么你要搜索包含“Java”关键词的帖子，直接扫描这个倒排索引，在倒排索引里找到“Java”这个关键词对应的那些数据的id就好了。然后你可以从其他地方根据这几个id找到对应的数据就可以了，这个就是倒排索引的数据格式以及搜索的方式，上面这种利用倒排索引查找数据的方式，也被称之为全文检索。

什么叫做分布式搜索引擎？

其实要知道什么叫做分布式搜索引擎，你首先得知道，假如我们就用一台机器部署一个搜索引擎系统，然后利用上述的那种倒排索引来存储数据，同时支持一些全文检索之类的搜索功能，那么会有什么问题？

其实还是很简单，假如说你现在要存储1TB的数据，那么放在一台机器还是可以的。

但是如果你要存储超过10TB，100TB，甚至1000TB的数据呢？你用一台机器放的下吗？

当然是放不下的了，你的机器磁盘空间是不够的。

大家看一下下面的图：

所以这个时候，你就得用分布式搜索引擎了，也就是要使用多台机器来部署搜索引擎集群。

比如说，假设你用的是Elasticsearch（后面简写为：ES）。

现在你总共有3TB的数据，那么你搞3台机器，每台机器上部署一个ES进程，管理那台机器上的1TB数据就可以了。

这样不就可以把3TB的数据分散在3台机器上来存储了？这不就是索引数据的分布式存储吗？而且，你在搜索数据的时候，不就可以利用3台机器来对分布式存储后的数据进行搜索了？每台机器上的ES进程不都可以对一部分数据搜索？这不就是分布式的搜索？

是的，这就是所谓的分布式搜索引擎：把大量的索引数据拆散成多块，每台机器放一部分，然后利用多台机器对分散之后的数据进行搜索，所有操作全部是分布在多台机器上进行，形成了完整的分布式的架构。

同样，我们来看下面的图，直观的感受一下。

Shard数据分片机制

那么这个时候大家考虑一下，比如说你有一个index，专门存放论坛里的帖子，现在论坛里的帖子有1亿，占用了1TB的磁盘空间，这个还好说。

如果这个帖子有10亿，100亿，占用了10TB、甚至100TB的磁盘空间呢？

那你这个index的数据还能在一台机器上存储吗？答案明显是不能的。

这个时候，你必须得支持这个index的数据分布式存储在多台机器上，利用多台机器的磁盘空间来承载这么大的数据量。

而且，需要保证每台机器上对这个index存储的数据量不要太大，因为控制单台机器上这个index的数据量，可以保证他的搜索性能更高。

所以这里就引入了一个概念：Shard数据分片结构。每个index你都可以指定创建多少个shard，每个shard就是一个数据分片，会负责存储这个index的一部分数据。

比如说index里有3亿帖子，占据3TB数据。然后这个index你设置了3个shard。

那么每个shard就可以包含一个1TB大小的数据分片，每个shard在集群里的一台机器上，这样就形成了利用3台机器来分布式存储一个index的数据的效果了。

大家看下面的图：

现在index里的3TB数据分布式存储在了3台机器上，每台机器上有一个shard，每个shard负责管理这个index的其中1TB数据的分片。

而且，另外一个好处是，假设我们要对这个index的3TB数据运行一个搜索，是不是可以发送请求到3台机器上去？

3台机器上的shard直接可以分布式的并行对一部分数据进行搜索，起到一个分布式搜索的效果，大幅度提升海量数据的搜索性能和吞吐量。

Replica多副本数据冗余机制

但是现在有一个问题，假如说3台机器中的其中一台宕机了，此时怎么办呢？

是不是这个index的3TB数据的1/3就丢失了？因为上面有1TB的数据分片没了。

所以说，还需要为了实现高可用使用Replica多副本数据冗余机制。

在Elasticsearch里，就是支持对每个index设置一个replica数量的，也就是每个shard对应的replica副本的数量。

比如说你现在一个index有3个shard，你设置对每个shard做1个replica副本，那么此时每个shard都会有一个replica shard。

这个初始的shard就是primary shard，而且primary shard和replica shard是绝对不会放在一台机器上的，避免一台机器宕机直接一个shard的副本也同时丢失了。

我们再来看下面的图，感受一下：

在上述的replica机制下，每个primary shard都有一个replica shard在别的机器上，任何一台机器宕机，都可以保证数据不会丢失，分布式搜索引擎继续可用。

Elasticsearch默认是支持每个index是5个primary shard，每个primary shard有1个replica shard作为副本。

Elasticsearch是如何做到快速索引的

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，大大减少了磁盘随机读的次数。

联合索引

上面说了半天都是单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)不利于查询

参考：

https://www.cnblogs.com/dreamroute/p/8484457.html

https://juejin.im/post/5c49ae25f265da613d7c6635