深刻分析Elastic Search的写入过程

摘要

以前写过一篇ElasticSearch初识之吐槽,不知觉居然过去了两年了。哎，时光催人老啊。最近又用到了ES，想找找过去的总结文档，竟然只有一篇，搞了半年的ES，遇到那么多的问题，产出只有这么点，真是说不过去啊。只好又从新捡起ES，发现ES槽点依然不少，不兼容的更新太多了，各个版本之间的差别不小，感受ES就是偏理论算法的人设计出来的，而不是工程学家写的。很是像公司里面，算法工程师吐槽后端应用开发算法能力弱，后端应用开发吐槽算法工程师工程能力太差。做为一个应用开发对ES差很少就是这种感受。不过要用到搜索，不用他又不行。既然不能拒绝，只能去享受了。

写入分析

为何要分析写入了，由于好奇呗。好比有以下问题一直困惑着我

1. 为何es会丢数据
2. 什么样的节点能够是coordinate node
3. refresh index和flush index是什么操做
4. memory buffer,filesystem cache都存在什么地方。
5. 集群中的节点如何配合写入的
6. 数据怎么存放的
7. 为何写入到filesystem cache中就能够索引了

写入概览

首先咱们从分布式集群的角度分析下写入，采用系统默认的参数来讲明

集群有三个节点，都存储数据，indexA 有5个分片，2个复制集。
数据以下分布
Node1: shard1
Node2: shard2,shard3,shard1-R1(shard1的复制集)
Node3: shard4,shard5,shard-R2(shard1的复制集)

为了简化问题，shard2,shard5等shard的复制集忽略问题了。
如今以写入shard1为例说明问题。

1. 首先客户端根据配置的链接节点，经过轮询方式链接到一个coordinate节点。

coordinate节点不是很master/client/data节点一个维度的描述，它就是指处理客户端请求的节点。这个描述和cassandra的coordinate节点是一个概念。集群中全部的节点均可以是coordinate节点。

2. coodinate节点经过hash算法计算出数据在shard1上shard = hash(document_id) % (num_of_primary_shards)，而后根据节点上维护的shard信息，将请求发送到node1上。
3. node1 对索引数据进行校验，而后写入到shard中。具体细节见下一节写入到shard。
4. 主节点数据写入成功后，将数据并行发送到副本集节点Node2,Node3。
5. Node2,Node3写入数据成功后，发送ack信号给shard1主节点Node1。
6. Node1发送ack给coordinate node
7. coordinate node发送ack给客户端。

整个过程coordinate node部分相似cassandra,主shard节点和副本集受master-slave模式影响，必须有master决定写入成功与否，和mysql相似的。

写入shard

上面第三步骤，shard内写入还须要详细分析下

1. 数据写入到内存buffer
2. 同时写入到数据到translog buffer
3. 每隔1s数据从buffer中refresh到FileSystemCache中，生成segment文件，一旦生成segment文件，就能经过索引查询到了
4. refresh完，memory buffer就清空了。
5. 每隔5s中，translog 从buffer flush到磁盘中
6. 按期/定量从FileSystemCache中,结合translog内容flush index到磁盘中。作增量flush的。

各类数据库的单节点写入过程大同小异，通常都是写内存，记录操做日志（防止节点宕机，内存中的数据丢失）而后flush到磁盘，有个线程不断的merge 数据块。不过是写入的数据格式不一样。

另外分布式或者主从式部署结构，又须要将写入的数据复制到不一样的节点，这个过程比较复杂，每一个数据库处理也有不一样的逻辑。

elastic search 写入的中间过程还多了一层buffer，咱们知道buffer和cache虽然都是为了提升写入效率，可是工做原理不一样，

一、Buffer（缓冲区）是系统两端处理速度平衡（从长时间尺度上看）时使用的。它的引入是为了减少短时间内突发I/O的影响，起到流量整形的做用。好比生产者——消费者问题，他们产生和消耗资源的速度大致接近，加一个buffer能够抵消掉资源刚产生/消耗时的忽然变化。
二、Cache（缓存）则是系统两端处理速度不匹配时的一种折衷策略。由于CPU和memory之间的速度差别愈来愈大，因此人们充分利用数据的局部性（locality）特征，经过使用存储系统分级（memory hierarchy）的策略来减少这种差别带来的影响。

因此写入到buffer中的数据，仍是原始数据，尚未索引，搜索不到的。只有到Cache中还能够。

和MySQL,Cassandra,Mongo的写入对比

数据库写入过程都须要写入操做日志，复制集日志，不一样的数据库不同的处理方法。
有些数据库是共用的，有些数据库则是分开的。

写操做日志的过程通常是直接写入磁盘的，由于它自己就是防止进程，机器宕机形成内存数据丢失，而用来恢复数据的。写入buffer中又会可能会致使数据的丢失。因此像elastic search mysql innodb这种操做日志写buffer的也会提供配置项，来保证当事务成功后，操做日志会被刷盘的。不过es 的操做日志最小刷盘不能低于100ms.

下面是各个数据库的日志对比，相同的功能，可是每一个建立者都有本身的逼格，须要有不一样的命名。

数据库	记录日志，刷磁盘	复制日志	备注
cassandra	commit log	commit log	commit log 直接写磁盘的
mongo	journal	oplog	journal log写磁盘的
mysql	redo logs	bin log	redo logs写buffer的，
elastic search	translog	translog	写buffer的

有兴趣的同窗能够以前写过的mongo,cassandra写入分析

mongo写入分析

cassandra写入分析

关注公众号【方丈的寺院】，第一时间收到文章的更新，与方丈一块儿开始技术修行之路

参考

https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-translog.html

https://www.elastic.co/pdf/architecture-best-practices.pdf

https://lalitvc.files.wordpress.com/2018/05/mysql_architecture_guide.pdf

https://www.infoq.cn/article/analysis-of-elasticsearch-cluster-part01

https://blog.insightdatascience.com/anatomy-of-an-elasticsearch-cluster-part-i-7ac9a13b05db