数据路由

存储文档时应该存储到哪个分片上，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集群，经历以下步骤:

查询内部机制

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

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

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" }}

{
          
    "test_field": "bulk yyds" }

{
          
    "delete": {
          
    "_index": "stu",  "_id": "2" }}

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

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