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  ⇒ 索引(Index)   ⇒ 类型(type)  ⇒ 文档(Docments)  ⇒ 字段(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里插入一条记录，其实就是直接PUT一个json的对象，这个对象有多个fields，比如上面例子中的name, sex, age, about, interests，那么在插入这些数据到Elasticsearch的同时，Elasticsearch还默默1的为这些字段建立索引--倒排索引，因为Elasticsearch最核心功能是搜索。

倒排索引原理：





如何创建索引


第一步：一些要索引的原文档（Document）

第二步：将原文档传给分词组件（Tokenizer）
      1)将文档分成一个一个单独的单词
      2）去除标点符号
      3）去除停词（stop word）

第三步：将得到的词元（Token）传给语言处理组件（Linguistic Processor）
      1)变为小写（Lowercase）
      2)将单词缩减为词根形式，如"cars"到"car"等。这种操作称为：stemming
      3)将单词转变为词根形式，如"drove"到"drive"等。这种操作称为：lemmatization

第四步：将得到的词（Term）传给索引组件（Indexer）
      1)利用得到的词（Term）创建一个字典
      2）对字典按字母顺序进行排序
      3）合并相同的词（Term）成为文档倒排（Posting List）链表



继续上面的例子，假设有这么几条数据(为了简单，去掉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是一颗树：


Elasticsearch的索引思路:

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

所以，对于使用Elasticsearch进行索引时需要注意:
•不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的
•同样的道理，对于String类型的字段，不需要analysis的也需要明确定义出来，因为默认也是会analysis的
•选择有规律的ID很重要，随机性太大的ID(比如java的UUID)不利于查询


Elasticsearch中的Cluster是对外提供索引服务的集群，组成这个集群的各个节点叫Node。

集群Cluster是一组有着相同cluster.name的节点，他们协同工作，互相分享数据，提供了故障转移和扩展的功能。

节点之间是对等关系的（去中心化），而弱化的Master节点只不过多了维护集群状态的功能。





（1）关系型数据库中的数据库（DataBase），等价于ES中的索引（Index）
（2）一个数据库下面有N张表（Table），等价于1个索引Index下面有N多类型（Type），
（3）一个数据库表（Table）下的数据由多行（ROW）多列（column，属性）组成，等价于1个Type由多个文档（Document）和多Field组成。
（4）在一个关系型数据库里面，schema定义了表、每个表的字段，还有表和字段之间的关系。 与之对应的，在ES中：Mapping定义索引下的Type的字段处理规则，即索引如何建立、索引类型、是否保存原始索引JSON文档、是否压缩原始JSON文档、是否需要分词处理、如何进行分词处理等。
（5）在数据库中的增insert、删delete、改update、查search操作等价于ES中的增PUT/POST、删Delete、改_update、查GET.


Elasticsearch致力于隐藏分布式系统的复杂性。以下这些操作都是在底层自动完成的：

1)将你的文档分区到不同的容器或者分片(shards)中，它们可以存在于一个或多个节点中。

2)将分片均匀的分配到各个节点，对索引和搜索做负载均衡。

3)冗余每一个分片，防止硬件故障造成的数据丢失。

4)将集群中任意一个节点上的请求路由到相应数据所在的节点。

5)无论是增加节点，还是移除节点，分片都可以做到无缝的扩展和迁移。


一个节点(node)就是一个Elasticsearch实例，而一个集群(cluster)由一个或多个节点组成，它们具有相同的 cluster.name ，它们协同工作，分享数据和负载。当加入新的节点或者删除一个节点时，集群就会感知到并平衡数据。

集群中一个节点会被选举为主节点(master),它将临时管理集群级别的一些变更，例如新建或删除索引、增加或移除节点等。主节点不参与文档级别的变更或搜索，这意味着在流量增长的时候，该主节点不会成为集群的瓶颈。任何节点都可以成为主节点。

做为用户，我们能够与集群中的任何节点通信，包括主节点。每一个节点都知道文档存在于哪个节点上，它们可以转发请求到相应的节点上。我们访问的节点负责收集各节点返回的数据，最后一起返回给客户端。这一切都由Elasticsearch处理。


为了将数据添加到Elasticsearch，我们需要索引(index)——一个存储关联数据的地方。实际上，索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”。

一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分。


分片就是一个Lucene实例，并且它本身就是一个完整的搜索引擎。我们的文档存储在分片中，并且在分片中被索引，但是我们的应用程序不会直接与它们通信，取而代之的是，直
接与索引通信。

分片是Elasticsearch在集群中分发数据的关键。把分片想象成数据的容器。文档存储在分片中，然后分片分配到你集群中的节点上。当你的集群扩容或缩小，Elasticsearch将会自动在你的节点间迁移分片，以使集群保持平衡。

分片可以是主分片(primary shard)或者是复制分片(replica shard)。你索引中的每个文档属于一个单独的主分片，所以主分片的数量决定了索引最多能存储多少数据。

理论上主分片能存储的数据大小是没有限制的，限制取决于你实际的使用情况。分片的最大容量完全取决于你的使用状况：硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档，以及你期望的响应时间。

复制分片只是主分片的一个副本，它可以防止硬件故障导致的数据丢失，同时可以提供读请求，比如搜索或者从别的shard取回文档。

当索引创建完成的时候，主分片的数量就固定了，但是复制分片的数量可以随时调整。

主分片的数量在创建索引时已经给定。实际上，这个数字定义了能存储到索引里数据的最大数量（实际的数量取决于你的数据、硬件和使用情况）。当然，读请求——搜索和文档检索——能够通过主分片或者复制分片处理，所以数据的冗余越多，我们能处理的搜索吞吐量就越大。

复制分片的数量可以在运行中的集群中动态地变更，这允许我们可以根据需求扩大或者缩小规模。


Elasticsearch是一个分布式的文档(document)存储引擎。它可以实时存储并检索复杂数据结构——序列化的JSON文档。换言说，一旦文档被存储在Elasticsearch中，它就可以在集群的任一节点上被检索。

在Elasticsearch中，每一个字段的数据都是默认被索引的。也就是说，每个字段专门有一个反向索引用于快速检索。而且，与其它数据库不同，它可以在同一个查询中利用所有的这些反向索引，以惊人的速度返回结果。

索引(index)类似于关系型数据库里的“数据库”——它是我们存储和索引关联数据的地方。

每个类型(type)都有自己的映射(mapping)或者结构定义，就像传统数据库表中的列一样。所有类型下的文档被存储在同一个索引下，但是类型的映射(mapping)会告诉Elasticsearch不同的文档如何被索引。

乐观并发控制：

Elasticsearch是分布式的。当文档被创建、更新或删除，文档的新版本（"_version"）会被复制到集群的其它节点。

路由文档到分片

当你索引一个文档，它被存储在单独一个主分片上。Elasticsearch是如何知道文档属于哪个分片的呢？当你创建一个新文档，它是如何知道是应该存储在分片1还是分片2上的呢？

事实上，它根据一个简单的算法决定：
shard = hash(routing) % number_of_primary_shards

routing 值是一个任意字符串，它默认是 _id 但也可以自定义。这个 routing 字符串通过哈希函数生成一个数字，然后除以主切片的数量得到一个余数(remainder)，余数的范围永远是 0 到 number_of_primary_shards - 1 ，这个数字就是特定文档所在的分片。

这也解释了为什么主分片的数量只能在创建索引时定义且不能修改：如果主分片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了。


主分片和复制分片如何交互

1）新建、索引和删除文档

新建、索引和删除请求都是写(write)操作，它们必须在主分片上成功完成才能复制到相关的复制分片上。




顺序步骤：

1. 客户端给 Node 1 发送新建、索引或删除请求。

2. 节点使用文档的 _id 确定文档属于分片 0 。它转发请求到 Node 3 ，分片 0 位于这个节点上。

3. Node 3 在主分片上执行请求，如果成功，它转发请求到相应的位于 Node 1 和 Node 2 的复制节点上。当所有的复制节点报告成功， Node 3 报告成功到请求的节点，请求的节点再报告给客户端。

客户端接收到成功响应的时候，文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了。

2）检索文档

文档能够从主分片或任意一个复制分片被检索。




顺序步骤：

1. 客户端给 Node 1 发送get请求。

2. 节点使用文档的 _id 确定文档属于分片 0 。分片 0 对应的复制分片在三个节点上都有。此时，它转发请求到 Node 2 。

3. Node 2 返回endangered给 Node 1 然后返回给客户端。

对于读请求，为了平衡负载，请求节点会为每个请求选择不同的分片——它会循环所有分片副本。

可能的情况是，一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到，主分片会成功返回文档。一旦索引请求成功返回给用户，文档则在主分片和复制分片都是可用的。

3）局部更新文档

update API 结合了之前提到的读和写的模式。




顺序步骤：

1. 客户端给 Node 1 发送更新请求。

2. 它转发请求到主分片所在节点 Node 3 。

3. Node 3 从主分片检索出文档，修改 _source 字段的JSON，然后在主分片上重建索引。如果有其他进程修改了文档，它以 retry_on_conflict 设置的次数重复步骤3，都未成功则放弃。

4. 如果 Node 3 成功更新文档，它同时转发文档的新版本到 Node 1 和 Node 2 上的复制节点以重建索引。当所有复制节点报告成功， Node 3 返回成功给请求节点，然后返回给客户端。

当主分片转发更改给复制分片时，并不是转发更新请求，而是转发整个文档的新版本。记住这些修改转发到复制节点是异步的，它们并不能保证到达的顺序与发送相同。如果Elasticsearch转发的仅仅是修改请求，修改的顺序可能是错误的，那得到的就是个损坏的文档。


4）多文档模式

mget 和 bulk API与单独的文档类似。差别是请求节点知道每个文档所在的分片。它把多文档请求拆成每个分片的对文档请求，然后转发每个参与的节点。

一旦接收到每个节点的应答，然后整理这些响应组合为一个单独的响应，最后返回给客户端。





mget顺序步骤：

1. 客户端向 Node 1 发送 mget 请求。

2. Node 1 为每个分片构建一个多条数据检索请求，然后转发到这些请求所需的主分片或复制分片上。当所有回复被接收， Node 1 构建响应并返回给客户端。





bulk顺序步骤：

1. 客户端向 Node 1 发送 bulk 请求。

2. Node 1 为每个分片构建批量请求，然后转发到这些请求所需的主分片上。

3. 主分片一个接一个的按序执行操作。当一个操作执行完，主分片转发新文档（或者删除部分）给对应的复制节点，然后执行下一个操作。复制节点为报告所有操作完成，节点报告给请求节点，请求节点整理响应并返回给客户端。


分布式搜索

1）查询阶段

在初始化查询阶段（query phase），查询被向索引中的每个分片副本（原本或副本）广播。每个分片在本地执行搜索并且建立了匹配document的优先队列（priority queue）。

优先队列（priority queue is）：只是一个存有前n个（top-n）匹配document的有序列表。这个优先队列的大小由分页参数from和size决定。




查询阶段包含以下三步：

1.客户端发送一个 search（搜索） 请求给 Node 3 , Node 3 创建了一个长度为 from+size 的空优先级队列。

2. Node 3 转发这个搜索请求到索引中每个分片的原本或副本。每个分片在本地执行这个查询并且结果将结果到一个大小为 from+size 的有序本地优先队列里去。

3.每个分片返回document的ID和它优先队列里的所有document的排序值给协调节点 Node 3 。 Node 3 把这些值合并到自己的优先队列里产生全局排序结果。

当一个搜索请求被发送到一个节点Node，这个节点就变成了协调节点。这个节点的工作是向所有相关的分片广播搜索请求并且把它们的响应整合成一个全局的有序结果集。这个结果集会被返回给客户端。

第一步是向索引里的每个节点的分片副本广播请求。就像document的 GET 请求一样，搜索请求可以被每个分片的原本或任意副本处理。这就是更多的副本（当结合更多的硬件时）如何提高搜索的吞吐量的方法。对于后续请求，协调节点会轮询所有的分片副本以分摊负载。

每一个分片在本地执行查询和建立一个长度为 from+size 的有序优先队列——这个长度意味着它自己的结果数量就足够满足全局的请求要求。分片返回一个轻量级的结果列表给协调节点。只包含documentID值和排序需要用到的值，例如 _score 。

协调节点将这些分片级的结果合并到自己的有序优先队列里。这个就代表了最终的全局有序结果集。到这里，查询阶段结束。

注意：一个索引可以由一个或多个原始分片组成，所以一个对于单个索引的搜索请求也需要能够把来自多个分片的结果组合起来。一个对于 多（multiple）或全部（all）索引的搜索的工作机制和这完全一致——仅仅是多了一些分片而已。


2）取回阶段

查询阶段辨别出那些满足搜索请求的document，但我们仍然需要取回那些document本身。这就是取回阶段的工作。



取回阶段由以下步骤构成：

1.协调节点辨别出哪个document需要取回，并且向相关分片发出 GET 请求。

2.每个分片加载document并且根据需要丰富（enrich）它们，然后再将document返回协调节点。

3.一旦所有的document都被取回，协调节点会将结果返回给客户端。

协调节点先决定哪些document是实际（actually）需要取回的。例如，我们指定查询 { "from": 90, "size": 10 } ，那么前90条将会被丢弃，只有之后的10条会需要取回。这些document可能来自与原始查询请求相关的某个、某些或者全部分片。

协调节点为每个持有相关document的分片建立多点get请求然后发送请求到处理查询阶段的分片副本。

分片加载document主体—— _source field。如果需要，还会根据元数据丰富结果和高亮搜索片断。一旦协调节点收到所有结果，会将它们汇集到单一的回答响应里，这个响应将会返回给客户端。

深分页:

查询然后取回过程虽然支持通过使用 from 和 size 参数进行分页，但是要在有限范围内（within limited）。还记得每个分片必须构造一个长度为 from+size 的优先队列吧，所有这些都要传回协调节点。这意味着协调节点要通过对 分片数量 * (from +size) 个document进行排序来找到正确的 size 个document。

根据document的数量，分片的数量以及所使用的硬件，对10,000到50,000条结果（1,000到5,000页）深分页是可行的。但是对于足够大的 from 值，排序过程将会变得非常繁重，会使用巨大量的CPU，内存和带宽。因此，强烈不建议使用深分页。

在实际中，“深分页者”也是很少的一部人。一般人会在翻了两三页后就停止翻页，并会更改搜索标准。那些不正常情况通常是机器人或者网络爬虫的行为。它们会持续不断地一页接着一页地获取页面直到服务器到底崩溃的边缘。

如果你确实需要从集群里获取大量documents，你可以通过设置搜索类型 scan 禁用排序，来高效地做这件事。

分页性能优化

ES 的分页是较坑的，为啥呢？举个例子吧，假如你每页是 10 条数据，你现在要查询第 100 页，实际上是会把每个 Shard 上存储的前 1000 条数据都查到一个协调节点上。

如果你有 5 个 Shard，那么就有 5000 条数据，接着协调节点对这 5000 条数据进行一些合并、处理，再获取到最终第 100 页的 10 条数据。

分布式的，你要查第 100 页的 10 条数据，不可能说从 5 个 Shard，每个 Shard 就查 2 条数据，最后到协调节点合并成 10 条数据吧？

你必须得从每个 Shard 都查 1000 条数据过来，然后根据你的需求进行排序、筛选等等操作，最后再次分页，拿到里面第 100 页的数据。

你翻页的时候，翻的越深，每个 Shard 返回的数据就越多，而且协调节点处理的时间越长，非常坑爹。所以用 ES 做分页的时候，你会发现越翻到后面，就越是慢。

我们之前也是遇到过这个问题，用 ES 作分页，前几页就几十毫秒，翻到 10 页或者几十页的时候，基本上就要 5~10 秒才能查出来一页数据了。

有什么解决方案吗？不允许深度分页（默认深度分页性能很差）。跟产品经理说，你系统不允许翻那么深的页，默认翻的越深，性能就越差。

类似于 App 里的推荐商品不断下拉出来一页一页的；类似于微博中，下拉刷微博，刷出来一页一页的，你可以用 Scroll API。

Scroll 会一次性给你生成所有数据的一个快照，然后每次滑动向后翻页就是通过游标 scroll_id 移动，获取下一页、下一页这样子，性能会比上面说的那种分页性能要高很多很多，基本上都是毫秒级的。

但是，唯一的一点就是，这个适合于那种类似微博下拉翻页的，不能随意跳到任何一页的场景。

也就是说，你不能先进入第 10 页，然后去第 120 页，然后又回到第 58 页，不能随意乱跳页。

所以现在很多产品，都是不允许你随意翻页的，App，也有一些网站，做的就是你只能往下拉，一页一页的翻。

初始化时必须指定 Scroll 参数，告诉 ES 要保存此次搜索的上下文多长时间。你需要确保用户不会持续不断翻页翻几个小时，否则可能因为超时而失败。

除了用 Scroll API，你也可以用 search_after 来做。search_after 的思想是使用前一页的结果来帮助检索下一页的数据。

显然，这种方式也不允许你随意翻页，你只能一页页往后翻。初始化时，需要使用一个唯一值的字段作为 Sort 字段。

性能优化的杀手锏：Filesystem Cache




你往 ES 里写的数据，实际上都写到磁盘文件里去了，查询的时候，操作系统会将磁盘文件里的数据自动缓存到 Filesystem Cache 里面去。

ES 的搜索引擎严重依赖于底层的 Filesystem Cache，你如果给 Filesystem Cache 更多的内存，尽量让内存可以容纳所有的 IDX Segment File 索引数据文件，那么你搜索的时候就基本都是走内存的，性能会非常高。

性能差距究竟可以有多大？我们之前很多的测试和压测，如果走磁盘一般肯定上秒，搜索性能绝对是秒级别的，1 秒、5 秒、10 秒。

但如果是走 Filesystem Cache，是走纯内存的，那么一般来说性能比走磁盘要高一个数量级，基本上就是毫秒级的，从几毫秒到几百毫秒不等。

归根结底，你要让 ES 性能好，最佳的情况下，就是你的机器的内存，至少可以容纳你的总数据量的一半。

根据我们自己的生产环境实践经验，最佳的情况下，是仅仅在 ES 中就存少量的数据，就是你要用来搜索的那些索引，如果内存留给 Filesystem Cache 的是 100G，那么你就将索引数据控制在 100G 以内。

这样的话，你的数据几乎全部走内存来搜索，性能非常之高，一般可以在1秒以内。