Elasticsearch-索引文档写入和近实时搜索原理

索引文档写入和近实时搜索原理

基本概念

• Segments in Lucene
  众所周知，Elasticsearch 存储的基本单元是 shard ， ES 中一个 Index 可能分为多个 shard， 事实上每个 shard 都是一个 Lucence 的 Index，并且每个 Lucence Index 由多个 Segment 组成， 每个Segment 事实上是一些倒排索引的集合， 每次创建一个新的 Document ， 都会归属于一个新的Segment， 而不会去修改原来的 Segment 。且每次的文档删除操作，会仅仅标记 Segment 中该文档为删除状态， 而不会真正的立马物理删除， 所以说 ES 的 index 可以理解为一个抽象的概念。 就像下图所示：
  

• Commits in Lucene
  Commit 操作意味着将 Segment 合并，并写入磁盘。保证内存数据尽量不丢。但刷盘是很重的 IO 操作， 所以为了机器性能和近实时搜索， 并不会刷盘那么及时。

• Translog
  新文档被索引意味着文档会被首先写入内存 buffer 和 translog 文件。每个 shard 都对应一个 translog文件
  

• Refresh in Elasticsearch
  在 Elasticsearch 中， _refresh 操作默认每秒执行一次， 意味着将内存 buffer 的数据写入到一个新的 Segment 中，这个时候索引变成了可被检索的。写入新Segment后 会清空内存buffer。
  

• Flush in Elasticsearch
  Flush 操作意味着将内存 buffer 的数据全都写入新的 Segments 中， 并将内存中所有的 Segments全部刷盘， 并且清空 translog 日志的过程
  

近实时搜索

提交（Commiting）一个新的段到磁盘需要一个 fsync 来确保段被物理性地写入磁盘，这样在断电的时候就不会丢失数据。 但是 fsync 操作代价很大; 如果每次索引一个文档都去执行一次的话会造成很大的性能问题。
我们需要的是一个更轻量的方式来使一个文档可被搜索，这意味着 fsync 要从整个过程中被移除。

在 Elasticsearch 和磁盘之间是文件系统缓存。 像之前描述的一样， 在内存索引缓冲区中的文档会被写入到一个新的段中。 但是这里新段会被先写入到文件系统缓存–这一步代价会比较低，稍后再被刷新到磁盘–这一步代价比较高。不过只要文件已经在系统缓存中， 就可以像其它文件一样被打开和读取了

在内存缓冲区中包含了新文档的 Lucene 索引

Lucene 允许新段被写入和打开–使其包含的文档在未进行一次完整提交时便对搜索可见。 这种方式比进行一次提交代价要小得多，并且在不影响性能的前提下可以被频繁地执行。

缓冲区的内容已经被写入一个可被搜索的段中，但还没有进行提交

• 原理
  下图表示是 es 写操作流程，当一个写请求发送到 es 后，es 将数据写入 memory buffer 中，并添加事务日志（ translog ）。如果每次一条数据写入内存后立即写到硬盘文件上，由于写入的数据肯定是离散的，因此写入硬盘的操作也就是随机写入了。硬盘随机写入的效率相当低，会严重降低es的性能

因此 es 在设计时在 memory buffer 和硬盘间加入了 Linux 的高速缓存（ File system cache ）来提
高 es 的写效率。
当写请求发送到 es 后，es 将数据暂时写入 memory buffer 中，此时写入的数据还不能被查询到。默认设置下，es 每1秒钟将 memory buffer 中的数据 refresh 到 Linux 的 File system cache ，并清空 memory buffer ，此时写入的数据就可以被查询到了

• refresh API
  在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 refresh 。 默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是 近 实时搜索： 文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。
  这些行为可能会对新用户造成困惑： 他们索引了一个文档然后尝试搜索它，但却没有搜到。这个问题的解决办法是用 refresh API 执行一次手动刷新：

1. POST /_refresh
2. POST /my_blogs/_refresh
3. PUT /my_blogs/_doc/1?refresh
{"test": "test"}
PUT /test/_doc/2?refresh=true
{"test": "test"}

1. 刷新（Refresh）所有的索引。
2. 只刷新（Refresh） blogs 索引
3. 只刷新 文档
   并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件， 你可能想优化索引速度而不是近实时搜索， 可以通过设置 refresh_interval ， 降低每个索引的刷新频率

PUT /my_logs
{
"settings": { "refresh_interval": "30s" }
}

refresh_interval 可以在既存索引上进行动态更新。 在生产环境中，当你正在建立一个大的新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来：

PUT /my_logs/_settings
{ "refresh_interval": -1 }
PUT /my_logs/_settings
{ "refresh_interval": "1s" }

持久化变更

• 原理
  如果没有用 fsync 把数据从文件系统缓存刷（flush）到硬盘，我们不能保证数据在断电甚至是程序正常退出之后依然存在。为了保证 Elasticsearch 的可靠性，需要确保数据变化被持久化到磁盘。
  在动态更新索引时，我们说一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点。Elasticsearch 在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确保能从失败中恢复。但在两次提交之间发生变化的文档怎么办？我们也不希望丢失掉这些数据。
  Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行了日志记录。通过 translog ，整个流程看起来是下面这样：

1. 一个文档被索引之后，就会被添加到内存缓冲区，并且 追加到了 translog ，正如 图21描述的一样。
   新的文档被添加到内存缓冲区并且被追加到了事务日志
   

• 1. 刷新（refresh）使分片处于 图 22描述的状态，分片每秒被刷新（refresh）一次：
     这些在内存缓冲区的文档被写入到一个新的段中，且没有进行 fsync 操作。
     这个段被打开，使其可被搜索。
     内存缓冲区被清空。
     图 22. 刷新（refresh）完成后， 缓存被清空但是事务日志不会
     
     这个进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志
     事务日志不断积累文档
     

3. 每隔一段时间–例如 translog 变得越来越大–索引被刷新（flush）；一个新的 translog 被创建，
   并且一个全量提交被执行（见 图 24）：
   所有在内存缓冲区的文档都被写入一个新的段。
   缓冲区被清空。
   一个提交点被写入硬盘。
   文件系统缓存通过 fsync 被刷新（flush）。
   老的 translog 被删除

translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。

translog 也被用来提供实时 CRUD 。当你试着通过 ID 查询、更新、删除一个文档，它会在尝试从相应的段中检索之前， 首先检查 translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。
在刷新（flush）之后，段被全量提交，并且事务日志被清空

• flush API
  这个执行一个提交并且截断 translog 的行为在 Elasticsearch 被称作一次 flush 。 分片每 30 分钟被自
  动刷新（flush），或者在 translog 太大的时候也会刷新。
  flush API 可以 被用来执行一个手工的刷新（flush）:

POST /blogs/_flush
POST /_flush?wait_for_ongoin

1. 刷新（flush） blogs 索引。
2. 刷新（flush）所有的索引并且等待所有刷新在返回前完成。
   我们很少需要自己手动执行一个的 flush 操作；通常情况下，自动刷新就足够了。
   这就是说，在重启节点或关闭索引之前执行 flush有益于你的索引。当 Elasticsearch 尝试恢复或重新打
   开一个索引， 它需要重放 translog 中所有的操作，所以如果日志越短，恢复越快

Translog 有多安全？
translog 的目的是保证操作不会丢失。这引出了这个问题： Translog 有多安全？
在文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被
fsync 刷新到硬盘， 或者在每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过
程在主分片和复制分片都会发生。最终， 基本上，这意味着在整个请求被 fsync 到主分片和复
制分片的 translog 之前，你的客户端不会得到一个 200 OK 响应。
在每次写请求后都执行一个 fsync 会带来一些性能损失，尽管实践表明这种损失相对较小（特别
是 bulk 导入，它在一次请求中平摊了大量文档的开销）。
但是对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群，使用异步的 fsync 还是比较有
益的。比如，写入的数据被缓存到内存中，再每 5 秒执行一次 fsync 。
这个行为可以通过设置 durability 参数为 async 来启用

PUT /my_index/_settings {
"index.translog.durability": "async",
"index.translog.sync_interval": "5s"
}

这个选项可以针对索引单独设置，并且可以动态进行修改。如果你决定使用异步 translog 的话，你需要 保证 在发生 crash 时，丢失掉 sync_interval 时间段的数据也无所谓。请在决定前知晓这个特性。
如果你不确定这个行为的后果，最好是使用默认的参数（ “index.translog.durability”:“request” ）来避免数据丢失。