Elasticsearch的存储模型和读写操作

1、辨析Elasticsearch的索引和Lucence的缩影

Elasticsearch中的索引是组织数据的逻辑空间(好比数据库)。一个Elasticsearch索引有一个或者多个分片(默认是5个)。分片对应实际存储数据的Lucence索引，分片自身就是一个搜索引擎。每个分片有一个或者多个副本(默认是1个副本)。Elasticsearch中还包含'type'(数据中的table)，用于逻辑上隔离索引中存储的数据。在Elasticsearch中，给定一个type,它的所有文档都会拥有相同的属性(table的schema).

图a展示了一个包含3个分片的Elasticsearch索引，每个分片拥有1个副本。这些分片组成了一个Elasticsearch索引，每个分片自身是一个Lucene索引。

图b展示了Elasticsearch索引、分片、Lucene索引和文档之间的逻辑关系。

对应于关系数据库术语

Elasticsearch Index == Database

Types == Tables

Properties == Schema

2 节点类型

一个Elasticsearch实例是一个节点，一组节点组成了集群。Elasticsearch集群中的节点可以配置为3种不同的角色：

主节点：控制Elasticsearch集群，负责集群中的操作，比如创建/删除一个索引，跟踪集群中的节点，分配分片到节点。主节点处理集群的状态并广播到其他节点，并接收其他节点的确认响应。

每个节点都可以通过设定配置文件elasticsearch.yml中的node.master属性为true(默认)成为主节点。

对于大型的生产集群来说，推荐使用一个专门的主节点来控制集群，该节点将不处理任何用户请求。

数据节点：持有数据和倒排索引。默认情况下，每个节点都可以通过设定配置文件elasticsearch.yml中的node.data属性为true(默认)成为数据节点。如果我们要使用一个专门的主节点，应将其node.data属性设置为false。

客户端节点：如果我们将node.master属性和node.data属性都设置为false，那么该节点就是一个客户端节点，扮演一个负载均衡的角色，将到来的请求路由到集群中的各个节点。

Elasticsearch集群中作为客户端接入的节点叫协调节点。协调节点会将客户端请求路由到集群中合适的分片上。对于读请求来说，协调节点每次会选择不同的分片处理请求，以实现负载均衡。

在我们开始研究发送给协调节点的CRUD请求是如何在集群中传播并被引擎执行之前，让我们先来看一下Elasticsearch内部是如何存储数据，以支持全文检索结果的低延迟服务的。

存储模型

Elasticsearch使用了Apache Lucene，后者是Doug Cutting(Apache Hadoop之父)使用Java开发的全文检索工具库，其内部使用的是被称为倒排索引的数据结构，其设计是为全文检索结果的低延迟提供服务。文档是Elasticsearch的数据单位，对文档中的词项进行分词，并创建去重词项的有序列表，将词项与其在文档中出现的位置列表关联，便形成了倒排索引。

这和一本书后面的索引非常类似，即书中包含的词汇与其出现的页码列表关联。当我们说文档被索引了，我们指的是倒排索引。我们来看下如下2个文档是如何被倒排索引的：

文档1(Doc 1): Insight Data Engineering Fellows Program

文档2(Doc 2): Insight Data Science Fellows Program

如果我们想找包含词项"insight"的文档，我们可以扫描这个(单词有序的)倒排索引，找到"insight"并返回包含改词的文档ID，示例中是Doc 1和Doc 2。

创建（Create）

Elasticsearch集群中每个节点都包含 了该节点上分片的元数据信息。协调节点（默认）使用ID参与计算，以便为路由提供合适的分片。Elasticsearch使用MurMurHash3函数对文档ID进行Hash,其结果再对分片数量取模，得到的结果即是索引文档的分片

shard = hash(document_id) % (num_of_primary_shards)

1、当分片所在的节点接收到来自协调节点的请求后，会将该请求写入translog。并将文档加入内存缓冲（buffer）。如果请求在主分片上成功处理，该请求会并行发送的该分片副本上后，客户端才会收到确认通知。

2、内存缓冲会被周期性刷新(默认是1秒)，内容将被写到文件系统缓存的一个新段上。虽然这个段并没有被同步（fsync）,但它是开放的，内容可以被搜索到。

3、每30分钟，或者translog很大的时候，translog会被清空，文件系统缓存会被同步。这个过程在Elasticsearch中称为冲洗（flush）。在冲洗的过程中，内存中的缓存将被清除，内容被写入一个新的段，段的fsync将创建一个新的提交点，并将内容刷新到磁盘。旧的translog将被删除并开始一个全新的translog。

shard = hash(document_id) % (num_of_primary_shards)

更新（U）update 和删除（D）delete

删除和更新也都是写操作，但是在Elasticsearch中的文档时不可变的，因此删除或者改动以展示其变更；

磁盘上每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的删除，而是在.del文件中被标记为删除。该文档仍然能匹配查询，但是在结果中被过滤掉。当段合并时，在.del文件中被标记为删除的文件不写入新段。

查询阶段

查询阶段协调节点会将查询请求路由到索引的全部分片（主分片或者副本分片）上。每个分片独立执行查询，并为查询结果创建一个优先队列，以相关性得分排序。会有很多文档匹配结果，但是默认情况下，每个分片只发送前10个结果给协调节点，协调节点为全部分片上的这些结果创建优先队列并返回前10个作为hit.