ELK--- Elastic Stack文档存储机制

数据路由

存储文档时应该存储到哪个分片上，ES通过数据路由来进行确定。

数据路由分为自动的路由算法或者手动指定。

• 路由算法

shard = hash(routing) % number_of_primary_shards

哈希值对主分片数取模

例如有三个主分片，当存储hash(id)=5的文档时，5%3=2，此时ES会将文档存储在shard2上，这就是路由算法。

• 手动指定
  语法：PUT /index/type/id?routing=key

例如进行以下插入

PUT /stu/class1/1?routing=jerry
{
"name":"jack",
"age": 18
}

此时ES会将其分配到一个主分片中，当再次插入到其它文档的routing的值为jerry，会将其存入同一个主分片中。

但是缺点是当设计的不合理的时候，会造成数据倾斜，大量数据堆积在同一个主分片。

因此不同文档尽量放到不同的索引中，剩下的事情交给ES集群自己处理。

增删改内部机制

对于增删改，统一可以看成是UPDATE，都是对数据的改动。

一个改动请求发送到ES集群，经历以下步骤:

• 客户端选择一个node发送请求过去，此节点作为coordinating node(协调节点)。
• 协调节点对document(文档)进行路由，将请求转发给对应的node。
• 实际的node上的主分片处理请求，然后将数据同步到副本分片上。
• 协调节点如果发现主分片和所有副本分片都完成后，就返回响应结果给客户端。

查询内部机制

一个查询请求发送到ES集群，经历以下步骤:

• 客户端发送请求到任意一个node，成为协调节点。
• 协调节点对文档进行路由，将请求转发到对应的node， 此时会使用round-robin随机轮询算法，在主分片以及其所有副本分片中随机选择一个，保证读请求的负载均衡。
• 收请求的node返回文档给协调节点。
• 协调节点返回文档给客户端。

特殊情况：文档如果还在建立索引过程中，可能只存在主分片有数据，任何一个副本分片都没有，此时可能会导致无法读取到文档，但是当文档完成索引建立之后，此时主分片和副本分片就都有了。

Bulk 存储的JSON格式

传统的JSON数组：

[
	{
  	  "action":{
      "method":"create"
	}, 
	  "data":{
      "id":1,
      "name":"java"
      }
    },
    {
  	  "action":{
      "method":"create"
	}, 
	  "data":{
      "id":2,
      "name":"cpp"
      }
    }
]    

这种JSON的表示形式是我们平常所用的形式，看起来比较直观，可读性较好。

但是对于ES来说，未必友好。

ES对于标准格式的JSON，需要按照下述流程去进行处理：

• 将JSON数组解析为JSONArray对象，此时整个数据会在内存中出现一份一模一样的拷贝，一份数据是JSON文本，一份数据是 JSONArray对象。
• 解析JSON数组里的每个JSON，对每个请求中的文档进行路由。
• 为路由到同一个分片上的多个请求，创建一个请求数组。
• 将这个请求数组序列化 。
• 将序列化后的请求数组发送到对应的节点上去。

这些会加大内存和资源的消耗，同时增加JVM的GC开销。JVM的垃圾回收次数频繁，导致ES的JVM停止工作线程的时间更多，从而大大降低效率和性能。

现有的特殊形式

POST /_bulk
{ "create": { "_index": "stu",  "_id": "1" }}\n
{ "test_field": "bulk yyds" }\n
{ "delete": { "_index": "stu",  "_id": "2" }} 

• 不用将其转换为JSON对象，直接按照换行符切割JSON字符串。
• 对每两个一组的JSON，读取meta，进行文档路由。
• 直接将对应的JSON发送到node上去。

和传统的格式相比，最最最大的优势在于，不需要将JSON数组解析为一个JSONArray对象，形成一份大数据的拷贝，浪费内存空间，尽可能地保证性能。