剖析写操作
创建 ((C)reate)
当我们发送索引一个新文档的请求到协调节点后，将发生如下一组操作：
Elasticsearch 集群中的每个节点都包含了该节点上分片的元数据信息。
更新 ((U)pdate) 和删除 ((D)elete)
删除和更新也都是写操作。但是 Elasticsearch 中的文档是不可变的，因此不能被删除或者改动以展示其变更。那么，该如何删除和更新文档呢？
磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并 (我们将在本系列接下来的文章中讲到) 时，在.del文件中被标记为删除的文档将不会被写入新段。
接下来我们看更新是如何工作的。在新的文档被创建时，Elasticsearch 会为该文档指定一个版本号。当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。
文档被索引或者更新后，我们就可以执行查询操作了。让我们看看在 Elasticsearch 中是如何处理查询请求的。
剖析读操作 ((R)ead)
读操作包含 2 部分内容：
- 查询阶段
- 提取阶段
我们来看下每个阶段是如何工作的。
查询阶段
在这个阶段，协调节点会将查询请求路由到索引的全部分片 (主分片或者其副本) 上。每个分片独立执行查询，并为查询结果创建一个优先队列，以相关性得分排序 (我们将在本系列的后续文章中讲到)。全部分片都将匹配文档的 ID 及其相关性得分返回给协调节点。协调节点创建一个优先队列并对结果进行全局排序。会有很多文档匹配结果，但是，默认情况下，每个分片只发送前 10 个结果给协调节点，协调节点为全部分片上的这些结果创建优先队列并返回前 10 个作为 hit
提取阶段
当协调节点在生成的全局有序的文档列表中，为全部结果排好序后，它将向包含原始文档的分片发起请求。全部分片填充文档信息并将其返回给协调节点。
下图展示了读请求及其数据流。
搜索相关性
相关性是由搜索结果中 Elasticsearch 打给每个文档的得分决定的。默认使用的排序算法是 tf/idf(词频 / 逆文档频率)。词频衡量了一个词项在文档中出现的次数 (频率越高 == 相关性越高)，逆文档频率衡量了词项在全部索引中出现的频率，是一个索引中文档总数的百分比 (频率越高 == 相关性越低)。最后的得分是 tf-idf 得分与其他因子比如 (短语查询中的) 词项接近度、(模糊查询中的) 词项相似度等的组合。
图解elasticsearch的写入流程(包含对refresh、fsync、flush操作的理解)
elasticsearch写入数据时涉及到的核心概念讲解：
segment file: 存储倒排索引的文件，每个segment本质上就是一个倒排索引，每秒都会生成一个segment文件，当文件过多时es会自动进行segment merge（合并文件），合并时会同时将已经标注删除的文档物理删除；
commit point（重点理解）: 记录当前所有可用的segment，每个commit point都会维护一个.del文件（es删除数据本质是不属于物理删除），当es做删改操作时首先会在.del文件中声明某个document已经被删除，文件内记录了在某个segment内某个文档已经被删除，当查询请求过来时在segment中被删除的文件是能够查出来的，但是当返回结果时会根据commit point维护的那个.del文件把已经删除的文档过滤掉；
translog日志文件: 为了防止elasticsearch宕机造成数据丢失保证可靠存储，es会将每次写入数据同时写到translog日志中(图中会有详解)。
完整elasticsearch的写入数据流程如下：
补充：将es中比较困惑的几个概念简单总结一下，这三种操作对理解es底层原理和优化很有帮助！
refresh
es接收数据请求时先存入内存中，默认每隔一秒会从内存buffer中将数据写入filesystem cache，这个过程叫做refresh；
