这里写目录标题
ES 的使用场景
ES 的特征
所以其使用场景主要是：
- 全文检索
- 日志搜索
- 交易订单曲线，安全指标监控
ES 的分布式架构
ES 写入数据的原理
整体写入流程
- 客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node (协调节点)
- coordinating node，对 document 进行路由，将请求转发给对应的 node
- 实际上的 node 上的 primary shard 处理请求，然后将数据同步到 replica node
- coordinating node，如果发现 primary node 和所有的 replica node 都搞定之后，就会返回请求到客户端
底层写入原理
数据在被 refresh 之后就可以被立马查到了！
ES的 refresh 操作是为了让最新的数据可以立即被搜索到。而flush操作则是为了让数据持久化到磁盘中，另外ES的搜索是在内存中处理的，因此flush操作不影响数据能否被搜索到。
flush 之后，TransLog 被清除，所有segment被写入内存。
ES 搜索数据的原理
整体搜索流程
- 如果是精确值搜索，比如搜索Id为20002，直接去正排和倒排索引中查找匹配的文档
- 如果是全文查询，则需要先对检索内容进行分析，产生token词条，再根据token词条去正排和倒排索引中匹配相应的文档
大致流程如图所示：
底层搜索原理
当ES在索引中搜索的时候，他发送查询到每一个属于索引的分片(Lucene 索引)，然后像分布式检索提到的那样，合并每个分片的结果到一个全局的结果集。
- 请求发到协调节点
- 协调节点转发查询请求到索引的每个分片上（可能是主，也可能是副本，负载均衡）
- 每个分片在本地执行查询，并且使用本地的Term/Document Frequency信息进行评分，添加结果到大小from+size的本地优先队列中
- 每个分片返回各自的优先队列中所有的文档id和排序值给协调节点，协调节点再合并这些值放入自己的优先队列中，产生一个全局排序后的列表
有三类：
- query_and_fetch
- query_then_fetch
- dfs_query_then_fetch
其中 Get 请求是会真正查询 TransLog，也就是真正的实时查询
ES 数据的删除
- 索引是不可变的。所以当一个文档被 “删除” 时，它实际上只是在 .del 文件中被标记删除。一个被标记删除的文档仍然可以被查询匹配到， 但它会在最终结果被返回前从结果集中移除。
- 文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记删除，文档的新版本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就已经被移除。
段合并
当段的数量变得很多的时候，就会进行段合并，这时会处理一些真正数据删除的操作。