ElasticSearch|ElasticSearch 文档(document)内部机制详解

1、数据路由 1.1 文档存储怎么路由到相应分片?
一个文档,最终会落在主分片的一个分片上,到底应该在哪一个分片?这就是数据路由。
1.2 路由算法

shard = hash(routing) % number_of_primary_shards

简单来说就是哈希值对主分片数取模。
举例:
【ElasticSearch|ElasticSearch 文档(document)内部机制详解】对一个文档经行crud时,都会带一个路由值 routing number。默认为文档_id(可能是手动指定,也可能是自动生成)。
存储1号文档,经过哈希计算,哈希值为2,此索引有3个主分片,那么计算2%3=2,就算出此文档在P2分片上。决定一个document在哪个shard上,最重要的一个值就是routing值,默认是_id,也可以手动指定,相同的routing值,每次过来,从hash函数中,产出的hash值一定是相同的。无论hash值是几,无论是什么数字,对number_of_primary_shards求余数,结果一定是在0~number_of_primary_shards-1之间这个范围内的。
ElasticSearch|ElasticSearch 文档(document)内部机制详解
文章图片

1.3 手动指定 routing number
PUT /test_index/_doc/15?routing=num { "num": 0, "tags": [] }

场景:在程序中,架构师可以手动指定已有数据的一个属性为路由值,好处是可以定制一类文档数据存储到一个分片中。缺点是设计不好,会造成数据倾斜。所以,不同文档尽量放到不同的索引中。剩下的事情交给es集群自己处理。
1.4 主分片数量不可变
涉及到以往数据的查询搜索,所以一旦建立索引,主分片数不可变。
2、文档(Document)的增删改内部机制(写数据过程) 增删改可以看做update,都是对数据的改动。一个改动请求发送到es集群,经历以下四个步骤:
(1)客户端选择一个node发送请求过去,这个node就是coordinating node(协调节点)
(2)coordinating node,对document进行路由,将请求转发给对应的node(有primary shard)
(3)实际的node上的primary shard处理请求,然后将数据同步到replica node。
(4)coordinating node,如果发现primary node和所有replica node都搞定之后,就返回响应结果给客户端。
ElasticSearch|ElasticSearch 文档(document)内部机制详解
文章图片

如上图所示,存在一个book索引,3个主分片,一个副本分片。比如说选择第一个节点为协调节点,在根据id进行数据路由,判断出属于第一个分片,找到对应的主分片完成对应的请求,在去对应的副本分片完成请求,最后在将响应结果返回给客户端。
3、文档的查询内部机制(读数据过程) 1、客户端发送请求到任意一个node,成为coordinate node
2、coordinate node对document进行路由,将请求转发到对应的node,此时会使用round-robin随机轮询算法,在primary shard以及其所有replica中随机选择一个,让读请求负载均衡
3、接收请求的node返回document给coordinate node
4、coordinate node返回document给客户端
5、特殊情况:document如果还在建立索引过程中,可能只有primary shard有,任何一个replica shard都没有,此时可能会导致无法读取到document,但是document完成索引建立之后,primary shard和replica shard就都有了。
ElasticSearch|ElasticSearch 文档(document)内部机制详解
文章图片

如上图所示,存在一个book索引,3个主分片,一个副本分片。比如说选择第一个节点为协调节点,在根据id进行数据路由,判断出属于第一个分片,在primary shard以及其所有replica中随机选择一个,最后在将响应结果返回给客户端。
4、文档的搜索机制(过程) es 最强大的是做全文检索,就是比如你有三条数据:
  • java真好玩儿啊
  • java好难学啊
  • j2ee特别牛
你根据 java 关键词来搜索,将包含 javadocument 给搜索出来。es 就会给你返回:java真好玩儿啊,java好难学啊。
  • 客户端发送请求到一个 coordinate node
  • 协调节点将搜索请求转发到所有的 shard 对应的 primary shardreplica shard,都可以。
  • query phase:每个 shard 将自己的搜索结果(其实就是一些 doc id)返回给协调节点,由协调节点进行数据的合并、排序、分页等操作,产出最终结果。
  • fetch phase:接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据,最终返回给客户端。
5、bulk api奇特的json格式
POST /_bulk {"action": {"meta"}} {"data"} {"action": {"meta"}} {"data"}[ { "action":{ "method":"create" }, "data":{ "id":1, "field1":"java", "field1":"spring", } }, { "action":{ "method":"create" }, "data":{ "id":2, "field1":"java", "field1":"spring", } } ]

如上所示,为什么bulk api不采用下面的那种阅读性非常强的格式而是采用上面那种格式呢?原因有以下3点。
1、bulk中的每个操作都可能要转发到不同的node的shard去执行
2、如果采用比较良好的json数组格式,这种格式允许任意的换行,整个可读性非常棒,读起来很爽,es拿到这种标准格式的json串以后,要按照下述流程去进行处理
(1)将json数组解析为JSONArray对象,这个时候,整个数据,就会在内存中出现一份一模一样的拷贝,一份数据是json文本,一份数据是JSONArray对象
(2)解析json数组里的每个json,对每个请求中的document进行路由
(3)为路由到同一个shard上的多个请求,创建一个请求数组。100请求中有10个是到P1.
(4)将这个请求数组序列化
(5)将序列化后的请求数组发送到对应的节点上去
3、耗费更多内存,更多的jvm gc开销。
一般来说bulk size最佳大小在几千条左右,然后大小在10MB左右,所以说,可怕的事情来了。假设说现在100个bulk请求发送到了一个节点上去,然后每个请求是10MB,100个请求,就是1000MB = 1GB,然后每个请求的json都copy一份为jsonarray对象,此时内存中的占用就会翻倍,就会占用2GB的内存,甚至还不止。因为弄成jsonarray之后,还可能会多搞一些其他的数据结构,2GB+的内存占用。占用更多的内存可能就会积压其他请求的内存使用量,比如说最重要的搜索请求,分析请求,等等,此时就可能会导致其他请求的性能急速下降。另外的话,占用内存更多,就会导致java虚拟机的垃圾回收次数更多,跟频繁,每次要回收的垃圾对象更多,耗费的时间更多,导致es的java虚拟机停止工作线程的时间更多。
再看看现在的奇特格式
POST /_bulk { "delete": { "_index": "test_index","_id": "5" }} { "create": { "_index": "test_index","_id": "14" }} { "test_field": "test14" }\n { "update": { "_index": "test_index","_id": "2"} } { "doc" : {"test_field" : "bulk test"} }\n

(1)不用将其转换为json对象,不会出现内存中的相同数据的拷贝,直接按照换行符切割json
(2)对每两个一组的json,读取meta,进行document路由
(3)直接将对应的json发送到node上去
这种格式最大的优势在于,不需要将json数组解析为一个JSONArray对象,形成一份大数据的拷贝,不至于浪费内存空间,也能尽可能地保证性能。


    推荐阅读