ES原理之写读搜索流程

目录

  • 非读流程
    • 写流程
      • 分布式写入
      • 写入
      • refresh
    • 删除流程
    • 更新
    • 段合并
  • 读流程
  • search流程

todo

非读流程

分布式写入

  • 用HighLevelClient写入ES时一般都是使用同步的方式写入ES


    es写入集群时.jpg

写流程

  • es存储是分段的，每个段具有不可变性，这样就避免多线程安全问题，当然后续会进行段合并以避免段过多。
写入
  1. 新document首先写入内存Buffer缓存中。
  2. 每隔一段时间，执行"commitpoint"(管理多个segment，读取也是找commit point)操作，buffer写入新Segment中。
  3. 新segment写入文件系统缓存 filesystem cache。(实际上第二，第三可以理解为一步，内存 -> 文件缓存 -> 文件。)
  4. 文件系统缓存中的index segment被fsync强制刷到磁盘上，确保物理写入。
    此时，新egment被打开供search操作。

  5. 清空内存buffer，可以接收新的文档写入。


    先被存放到内存.png
refresh
  • Lucene支持对新段写入和打开-可以使文档在没有完全刷入硬盘的状态下就能对搜索可见，而且是一个开销较小的操作，可以频繁进行,refresh操作。

  • 进行refresh操作，清空buffer，文档可被搜索但尚未flush到磁盘。translog不会清空，每隔一段时间（例如translog变得太大），index会被flush到磁盘，新的translog文件被创建，这个commit完整执行结束。


    带translog.png
  • translog可以用来断电恢复啥的

删除流程

  • 删除一个ES文档不会立即从磁盘上移除，它只是被标记成已删除。因为段是不可变的，所以文档既不能从旧的段中移除，旧的段也不能更新以反映文档最新的版本。
    ES的做法是，每一个提交点包括一个.del文件（还包括新段），包含了段上已经被标记为删除状态的文档。所以，当一个文档被做删除操作，实际上只是在.del文件中将该文档标记为删除，依然会在查询时被匹配到，只不过在最终返回结果之前会被从结果中删除。

更新

  • 文档的更新操作和删除是类似的：当一个文档被更新，旧版本的文档被标记为删除，新版本的文档在新的段中索引。
    该文档的不同版本都会匹配一个查询，但是较旧的版本会从结果中删除。

段合并

  • 段合并也会进行哪些需要被删除数据的删除操作，ES通过后台合并段解决这个问题。ES利用段合并的时机来真正从文件系统删除那些version较老或者是被标记为删除的文档。被删除的文档（或者是version较老的）不会再被合并到新的更大的段中。
  • 合并会通过比如时间戳进行分组合并。

读流程

search流程

1、客户端发送请求到一个coordinate node。
2、协调节点将搜索请求转发到所有的shard对应的primary shard 或 replica shard ，都可以。
3、query phase：每个shard将自己的搜索结果（其实就是一些doc id）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
4、fetch phase：接着由协调节点根据doc id去各个节点上拉取实际的document数据，最终返回给客户端。

  1. 进一步，参考本系列es深入篇
  2. 参考https://www.cnblogs.com/bonelee/p/6226185.html

参考

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

推荐阅读更多精彩内容