26.分布式文档系统_bulk api的奇特json格式与底层性能优化关系大揭秘

关于_bulk api的奇特设计格式，比如之前动手练习的，如：

  

   

    

     

    
    

     

      POST /_bulk
     
    
   

    

     

    
    

     

      {
      "delete":{
      "_index":
      "test_index",
      "_type":
      "test_type",
      "_id":
      "4"}}
     
    
   

    

     

    
    

     

      {
      "create":{
      "_index":
      "test_index",
      "_type":
      "test_type",
      "_id":
      "5"}}
     
    
   

    

     

    
    

     

      {
      "test_field1":
      "test client 5",
      "test_field2":
      "test service 5"}
     
    
   

    

     

    
    

     

      {
      "create":{
      "_index":
      "test_index",
      "_type":
      "test_type",
      "_id":
      "5"}}
     
    
   

    

     

    
    

     

      {
      "test_field1":
      "test client 5",
      "test_field2":
      "test service 5"}
     
    
   

    

     

    
    

     

      {
      "index":{
      "_index":
      "test_index",
      "_type":
      "test_type",
      "_id":
      "1"}}
     
    
   

    

     

    
    

     

      {
      "test_field":
      "test service 1"}
     
    
   

    

     

    
    

     

      {
      "update":{
      "_index":
      "test_index",
      "_type":
      "test_type",
      "_id":
      "3"}}
     
    
   

    

     

    
    

     

      {
      "doc":{
      "test_field2":
      "test update 3"}}
     
    
   

    

     

    
    

     

      -----------------------------------_bulk支持的格式----------------------------------------
     
    
   

    

     

    
    

     

      {
      "action": {
      "meta"}}\n
     
    
   

    

     

    
    

     

      {
      "data"}\n
     
    
   

    

     

    
    

     

      {
      "action": {
      "meta"}}\n
     
    
   

    

     

    
    

     

      {
      "data"}\n
     
    
  

总会有疑问，为什么_bulk不能用之前我们用的那种格式，如：

  

   

    

     

    
    

     

      PUT /test_index/test_type/
      3
     
    
   

    

     

    
    

     

      {
     
    
   

    

     

    
    

     
  
      "test_field1":
      "test client 3",
     
    
   

    

     

    
    

     
  
      "test_field2":
      "test test 3"
     
    
   

    

     

    
    

     

      }
     
    
   

    

     

    
    

     

      -----------------------------------_bulk不支持格式----------------------------------------
     
    
   

    

     

    
    

     

      [
      {
     
    
   

    

     

    
    

     

       "action": {
     
    
   

    

     

    
    

     

       },
     
    
   

    

     

    
    

     

       "data": {
     
    
   

    

     

    
    

     

       }
     
    
   

    

     

    
    

     

      }]
     
    
  

这种格式明显看起来更易读，并且写起来不易出错，为什么不用呢？

原因：

1、bulk中的每个操作都可能要转发到不同的node的shard去执行

2、如果采用比较良好的json数组格式

允许任意的换行，整个可读性非常棒，读起来很爽，es拿到那种标准格式的json串以后，要按照下述流程去进行处理：
（1）将json数组解析为JSONArray对象，这个时候，整个数据，就会在内存中出现一份一模一样的拷贝，一份数据是json文本，一份数据是JSONArray对象
（2）解析json数组里的每个json，对每个请求中的document进行路由
（3）为路由到同一个shard上的多个请求，创建一个请求数组
（4）将这个请求数组序列化
（5）将序列化后的请求数组发送到对应的节点上去

3、这将会耗费更多内存，更多的jvm gc开销

我们之前提到过bulk size最佳大小的那个问题，一般建议说在几千条那样，然后大小在10MB左右，所以说，可怕的事情来了。假设说现在100个bulk请求发送到了一个节点上去，然后每个请求是10MB，100个请求，就是1000MB = 1GB，然后每个请求的json都copy一份为jsonarray对象，此时内存中的占用就会翻倍，就会占用2GB的内存，甚至还不止。因为弄成jsonarray之后，还可能会多搞一些其他的数据结构，2GB+的内存占用。

占用更多的内存可能就会积压其他请求的内存使用量，比如说最重要的搜索请求，分析请求，等等，此时就可能会导致其他请求的性能急速下降
另外的话，占用内存更多，就会导致java虚拟机的垃圾回收次数更多，跟频繁，每次要回收的垃圾对象更多，耗费的时间更多，导致es的java虚拟机停止工作线程的时间更多

4、现在的奇特格式

  

   

    

     

    
    

     

      {
      "action": {
      "meta"}}\n
     
    
   

    

     

    
    

     

      {
      "data"}\n
     
    
   

    

     

    
    

     

      {
      "action": {
      "meta"}}\n
     
    
   

    

     

    
    

     

      {
      "data"}\n
     
    
  

（1）不用将其转换为json对象，不会出现内存中的相同数据的拷贝，直接按照换行符切割json
（2）对每两个一组的json，读取meta，进行document路由
（3）直接将对应的json发送到node上去。

5、最大的优势在于，不需要将json数组解析为一个JSONArray对象，形成一份大数据的拷贝，浪费内存空间，尽可能地保证性能。