ELK高级搜索三Elasticsearch写入原理

目录

ElasticSearch中的index

ES数据写入路由机制

Update和Delete实现原理

Read读的实现阶段

---

ElasticSearch中的index

如图显示一个由三个主分片组成的ElasticSearch集群，每个主分片分别有一个副本。所有这些分片一起形成一个Elasticsearch索引。

后者显示了Elasticsearch索引、分片、lucene索引和doc文档之间的逻辑关系。

ES数据写入路由机制

当向协调节点发送请求以索引新文档时，将执行以下操作：
· 所有在Elasticsearch集群中的节点都包含：分片存在哪个节点上的元数据。协调节点(coordination node)使用doc id(默认)进行路由到对应的分片。路由计算方式：shard=hash(document id)%(num_of_primary_shards)

当节点接受到来自协调节点的请求时，请求被写入translog,并将该文档添加到内存缓冲区，如果请求在主分片上成功，则请求将并行发送到副本分片。只有在所有主分片和和副本分片上的translog被fsynced后，客户端才会收到该请求成功的确认。

1. 数据先被写进内存buffer，同时这一操作也写进translog中，这时的数据还不可被检索到。
2. 每隔1s(这个时间可以调整)进行一次refresh，将buffer内1s的数据写进os cache中，构成一个segment分段，同时清空buffer，这时数据可以被检索到，但由于数据仍然在内存中，若发生故障，数据是可以丢失的。
3. 不断地重复上面的步骤，不断产生新的segment，translog也不断的变大。
4. 当时间达到30分钟或者translog足够大的时候，进行一次fsync，将内存中所有的segment都写进磁盘中，并删除translog，重新生成新的translog。

由上面可以看得出来，文件存储在内存以及os cache中是不安全的，因此ES引入translog来记录两次fsync之间的操作，以便发生故障，也能恢复数据。
但translog也是存在内存中的，发生故障依然会丢失数据，因此每隔5s或一次请求完成后，translog就会写进磁盘，被写进磁盘后就可以认为是安全复原的，因此只有当translog写入磁盘后，ES才能向客户端反馈成功的信息。
另外每隔1s就产生一个segment，很快分片内就有大量的segment，而搜索时会搜索所有的segment，影响性能，因此ES会自动合并大小相似的segment，同时删除合并的旧segment

数据先写入Buffer，同时写入Translog（用于极端情况下的数据恢复），Buffer缓存数据达到阈值会批量刷到磁盘（中间有个文件系统缓冲），所以说es的数据写入是一个近实时的（延时默认是1秒）

Update和Delete实现原理

删除和更新操作也是写操作。但是，ElasticSearch中的文档时不可变的（immutable），因此不能删除或修改。

如何删除/更新文档呢?
删除：磁盘上的每个分段(segement)都有一个.del文件与它关联。当客户端发送删除请求时，该文档未被真正删除，而是在.del文件中标记为已删除。此文档仍然可能被搜到，但会从结果中过滤掉。当分段合并时，在.del文件中标记为删除的文档不会包括在新的合并段中。

更新:创建新文件，Elasticsearch将该文档分配一个版本号。对文档的每次更改都会产生一个新的版本号，当执行更新时，旧版本在.del文件中标记为已删除，并且在新版本的分片中编入索引。旧版本可能仍然与搜索查询匹配，但是从结果中将其将其过滤掉。
 

Read读的实现阶段

读操作由两个阶段组成：查询阶段(query)和获取阶段（fetch）阶段。

查询阶段
在此阶段，协调节点将搜索请求路由到索引中的所有分片(包括：主分片和副本分片)。分片独立执行搜索，并根据相关性分数创建一个优先级排序结果.所有分片将匹配到的文档和相关性分数的文档id返回给协调节点。协调节点创建一个新的优先级队列，并对全局结果进行排序。可以有很多文档匹配结果，但默认情况下，每个分片将前10个结果发送到协调节点，协调节点创建优先级队列，从所有分片中分选结果并返回前10个匹配结果。

获取阶段
在协调节点对所有的结果进行排序，生成全局排序的文档列表后，它将所有分片请求原始文档。所有的分片都会丰富文档并将其返回到协调节点。

一个请求被分发的过程：

GET /book_index/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "author.keyword": "古龙"
          }
        },
        {
          "term": {
            "bookName.keyword": "三少爷的剑"
          }
        }
      ]
    }
  }
}

这个请求可能被分发到集群里的任意一个节点：

这时这个节点就成为当前请求的协调节点(coordinator),它决定：

1）根据所有信息，判断请求会被路由到哪个核心节点

2）以及哪个副本是可用的