elasticsearch 机制原理之索引写入、存储

机制原理
主分片和副本分片是如何同步的？
创建索引的流程是什么样的？
ES如何将索引数据分配到不同的分片上的？
以及这些索引数据是如何存储的？
为什么说ES是近实时搜索引擎而文档的 CRUD (创建-读取-更新-删除) 操作是实时的？
以及Elasticsearch 是怎样保证更新被持久化在断电时也不丢失数据？
还有为什么删除文档不会立刻释放空间？

写索引原理

写索引是只能写在主分片上，然后同步到副本分片

这是别的博主的图片，一共3个节点的集群，共拥有12个分片，其中有4个主分片，从左往右依次，S3,S2,S1,S0和其余8个副本分片R开头的（replica）

4个主分片，一条ES数据怎么写入的，根据什么规则写到特定分片上呢？

• 首先肯定不是随机写入的，否则将来去哪找呢？ 就像你把车停地下车库里，停的时候没有记录号码，回来的时候满场找，怕是没挨过骂。
• 实际上 shard = hash(routing) % number_of_primary_shards
  routing 是一个可变值，默认是文档的 _id(doc_id),也可以设置成一个自定义的值
  routing 通过 hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数 。这个在 0 到 numberofprimary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置

所以我们要在创建索引的时候就确定好主分片的数量。并且永远不会改变这个数量：
因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。

由于在ES集群中每个节点通过上面的计算公式都知道集群中的文档的存放位置，所以每个节点都有处理读写请求的能力。在一个写请求被发送到某个节点后，该节点即为前面说过的协调节点，协调节点会根据路由公式计算出需要写到哪个分片上，再将请求转发到该分片的主分片节点上。因为写都是写入主分片的

举个栗子：
假如此时数据通过路由计算公式取余后得到的值是 shard = hash(routing) % 4 = 0

1 客户端向ES1节点（发送写请求），通过路由计算公式得到值为0，则当前数据应被写到主分片S0上。
2 ES1节点将请求转发到S0主分片所在的节点ES3，ES3接受请求并写入到磁盘
3 并发将数据复制到两个副本分片R0上，其中通过乐观并发控制数据的冲突。一旦所有的副本分片都报告成功，则节点ES3将向协调节点报告成功，协调节点向客户端报告成功。

存储原理

以上都是在ES内存中执行的，数据被分配到特定的分片和副本上之后，最终是存储到磁盘上的，这样在断电的时候就不会丢失数据。

配置在config/elasticsearch.yml

path.data: # 索引数据
path.logs: # 日志记录
建议不要使用默认值，因为若ES进行了升级，则有可能导致数据全部丢失。

shard详解

当新的文档创建的时候，如何构建倒排索引呢？es的倒排索引一旦创建就不会修改，新文档创建时会根据新文档重新构建倒排索引。查询是会查询所有的倒排索引。es使用的是lucene的倒排索引，lucene的单个倒排索引称为segment，合在一起称为Index，与ES的Index的概念不同。ES中的一个Shard对应一个Lucene Index。Lucene会有一个专门的文件来记录所有的segment信息，称为commit point。

分段存储（segment)

• 文档以段的形式存储在磁盘
  索引文件被拆分为多个子文件，则每个子文件叫作segment(段）,每个segment本身就是都是一个倒排索引，并且segment(段）具有不变性，一旦索引的数据被写入硬盘，就不可再修改。在底层采用了分段的存储模式，使它在读写时几乎完全避免了锁的出现，大大提升了读写性能。

• 段可读、可写时机不同
  段被写入到磁盘后会生成一个提交点（commit point），提交点是一个用来记录所有提交后段信息的文件。一个段一旦拥有了提交点，就说明这个段只有读的权限，失去了写的权限。相反，当段在内存中时，就只有写的权限，而不具备读数据的权限，意味着不能被检索

• 索引文件分段存储
  索引文件分段存储并且不可修改，那么新增、更新和删除如何处理呢？

新增，新增很好处理，由于数据是新的，所以只需要对当前文档新增一个段就可以了。
删除，由于不可修改，所以对于删除操作，不会把文档从旧的段中移除而是通过新增一个 .del文件，文件中会列出这些被删除文档的段信息。这个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。
更新，不能修改旧的段来进行反映文档的更新，其实更新相当于是删除和新增这两个动作组成。会将旧的文档在 .del文件中标记删除，然后文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就会被移除。

• 设定为不可修改具有一定的优势也有一定的缺点，优势主要表现在：

不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
其它缓存(像filter缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。

段缺点如下：

当对旧数据进行删除时，旧数据不会马上被删除，而是在 .del文件中被标记为删除。而旧数据只能等到段更新时才能被移除，这样会造成大量的空间浪费。
若有一条数据频繁的更新，每次更新都是新增新的标记旧的，则会有大量的空间浪费。
每次新增数据时都需要新增一个段来存储数据。当段的数量太多时，对服务器的资源例如文件句柄的消耗会非常大。
在查询的结果中包含所有的结果集，需要排除被标记删除的旧数据，这增加了查询的负担。

延迟写策略

介绍完了存储的形式，那么索引是写入到磁盘的过程是这怎样的？是否是直接调 fsync 物理性地写入磁盘？

答案是显而易见的，如果是直接写入到磁盘上，磁盘的I/O消耗上会严重影响性能，那么当写数据量大的时候会造成ES停顿卡死，查询也无法做到快速响应。如果真是这样ES也就不会称之为近实时全文搜索引擎了。

为了提升写的性能，ES并没有每新增一条数据就增加一个段到磁盘上，而是采用延迟写的策略。

• segment写入磁盘的过程已然很耗时，可以借助文件系统缓存的特性，先将segment在缓存中创建并开放查询来进一步提升实时性，该过程在es中被称为 refresh （即内存刷新到文件缓存系统）。
• 在refresh之前文件会先存储在一个buffer中，refresh中将bufffer的所有文档清空并生成segment
• 默认情况下每个分片会1秒自动刷新一次。这就是为什么我们说 Elasticsearch 是近实时（Near Real Time）搜索，因为文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。我们也可以手动触发 refresh，
  POST/_refresh 刷新所有索引
  POST/nba/_refresh刷新指定的索引。

每当有新增的数据时，就将其先写入到内存中，在内存和磁盘之间是文件系统缓存，当达到默认的时间（1秒钟）或者内存的数据达到一定量时，会触发一次刷新（Refresh），将内存中的数据生成到一个新的段上并缓存到文件缓存系统 上，稍后再被刷新到磁盘中并生成commit point。

这里的内存使用的是ES的JVM内存，而文件缓存系统使用的是操作系统（OS）的内存。新的数据会继续的被写入内存，但内存中的数据并不是以段的形式存储的，因此不能提供检索功能。由内存刷新到文件缓存系统的时候会生成了新的段segment，并将段打开以供搜索使用，而不需要等到被刷新到磁盘。

Tips：尽管刷新是比提交轻量很多的操作，它还是会有性能开销。当写测试的时候， 手动刷新很有用，但是不要在生产
环境下每次索引一个文档都去手动刷新。而且并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引
大量的日志文件， 你可能想优化索引速度而不是近实时搜索， 这时可以在创建索引时在 settings中通过调大 
refresh_interval="30s" 的值 ， 降低每个索引的刷新频率，设值时需要注意后面带上时间单位，否则默认是毫秒。
当 refresh_interval=-1时表示关闭索引的自动刷新。

文档搜索实时性

虽然通过延时写的策略可以减少数据往磁盘上写的次数提升了整体的写入能力，但是我们知道文件缓存系统也是内存空间，属于操作系统的内存，只要是内存都存在断电或异常情况下丢失数据的危险。

为了避免丢失数据，Elasticsearch添加了事务日志（Translog），事务日志记录了所有还没有持久化到磁盘的数据。添加了事务日志后整个写索引的流程如下图所示。

• 一个新文档被索引之后，先被写入到内存中，但是为了防止数据的丢失，会追加一份数据到事务日志（translog）中。
  不断有新的文档被写入到内存，同时也都会记录到事务日志(translog)中。这时新数据还不能被检索和查询

• 当达到默认的刷新时间或内存中的数据达到一定量后，会触发一次 refresh，将内存中的数据以一个新段(segment)形式刷新到文件缓存系统中并清空内存。这时虽然新段未被提交到磁盘，但是可以提供文档的检索功能且不能被修改。

• 随着新文档索引不断被写入，当日志数据大小超过512M或者时间超过30分钟时，会触发一次 flush。内存中的数据被写入到一个新段同时被写入到文件缓存系统，文件系统缓存中数据通过 fsync 刷新到磁盘中，生成提交点(commit point)，日志文件(translog)被删除，创建一个空的新日志

  • flush负责将内存中的segment写入磁盘
    1.将translog写入磁盘
    2.将内存（图中黄色index buffer）清空，其中的文档生成一个新的segment，相当于一个refresh操作
    3.更新commit point 并写入磁盘
    4.执行fsync操作，将内存中的segment写入磁盘
    5.删除旧的translog文件

通过这种方式当断电或需要重启时，ES不仅要根据提交点去加载已经持久化过的段，还需要根据Translog里的记录，把未持久化的数据重新持久化到磁盘上，避免了数据丢失的可能。

段合并（segment merging）

由于自动刷新流程每秒会创建一个新的段 ，这样会导致短时间内的段数量暴增。而段数目太多会带来较大的麻烦。每一个段都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个段然后合并查询结果，所以段越多，搜索也就越慢。

Elasticsearch通过在后台定期进行段合并来解决这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档不会被拷贝到新的大段中。合并的过程中不会中断索引和搜索。

段合并在进行索引和搜索时会自动进行，合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中，这些段既可以是未提交的也可以是已提交的。合并结束后老的段会被删除，新的段被 flush 到磁盘，同时写入一个包含新段且排除旧的和较小的段的新提交点，新的段被打开可以用来搜索。

段合并的计算量庞大， 而且还要吃掉大量磁盘 I/O，段合并会拖累写入速率，如果任其发展会影响搜索性能。Elasticsearch在默认情况下会对合并流程进行资源限制，所以搜索仍然有足够的资源很好地执行。

上帝视角来看下es的index和Lucene Index的对照

总结：
1 写索引都是在写在主分片上
2 写索引的寻址公式： shard = hash(routing) % number_of_primary_shards
3 索引数据以segment的形式，存储在磁盘上
4 索引的更新其实是删除旧的然后新增新的
5 为了提升写性能，采用了延时写
6 为了数据安全问题，采用了事务日志（Translog)
7 为了解决短时间内的段数量暴增，采用了段合并

---

以下无正文

原文链接：
https://cloud.tencent.com/developer/article/1488535
参考文档：https://blog.51cto.com/u_15072912/3427561