ES 搜索与写入的实现原理

ES 入门

ES 的使用场景

ES 的特征

所以其使用场景主要是：

• 全文检索
• 日志搜索
• 交易订单曲线，安全指标监控

ES 的分布式架构

ES 写入数据的原理

整体写入流程

1. 客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node (协调节点)
2. coordinating node，对 document 进行路由，将请求转发给对应的 node
3. 实际上的 node 上的 primary shard 处理请求，然后将数据同步到 replica node
4. coordinating node，如果发现 primary node 和所有的 replica node 都搞定之后，就会返回请求到客户端
   

底层写入原理

数据在被 refresh 之后就可以被立马查到了！

ES的 refresh 操作是为了让最新的数据可以立即被搜索到。而flush操作则是为了让数据持久化到磁盘中，另外ES的搜索是在内存中处理的，因此flush操作不影响数据能否被搜索到。

flush 之后，TransLog 被清除，所有segment被写入内存。

ES 搜索数据的原理

整体搜索流程

检索

• 如果是精确值搜索，比如搜索Id为20002，直接去正排和倒排索引中查找匹配的文档
• 如果是全文查询，则需要先对检索内容进行分析，产生token词条，再根据token词条去正排和倒排索引中匹配相应的文档

大致流程如图所示：

底层搜索原理

当ES在索引中搜索的时候，他发送查询到每一个属于索引的分片(Lucene 索引)，然后像分布式检索提到的那样，合并每个分片的结果到一个全局的结果集。

1. 请求发到协调节点
2. 协调节点转发查询请求到索引的每个分片上（可能是主，也可能是副本，负载均衡）
3. 每个分片在本地执行查询，并且使用本地的Term/Document Frequency信息进行评分，添加结果到大小from+size的本地优先队列中
4. 每个分片返回各自的优先队列中所有的文档id和排序值给协调节点，协调节点再合并这些值放入自己的优先队列中，产生一个全局排序后的列表

有三类：

1. query_and_fetch
2. query_then_fetch
3. dfs_query_then_fetch
   
   其中 Get 请求是会真正查询 TransLog，也就是真正的实时查询
   

ES 数据的删除

• 索引是不可变的。所以当一个文档被 “删除” 时，它实际上只是在 .del 文件中被标记删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。
• 文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。

段合并

当段的数量变得很多的时候，就会进行段合并，这时会处理一些真正数据删除的操作。