Elastisearch在kibana下批量處理（mget和bulk）

一、批量查詢

有點：能夠大大減少網絡的請求次數，減少網絡開銷

1、自定義設置index、type以及document id，進行查詢

GET /_mget
{
  "docs":[
    {
      "_index":"ecommerce",
      "_type":"product",
      "_id":1
    },
    {
       "_index":"ecommerce",
      "_type":"product",
      "_id":2
      }
    ]
}

查詢結果，由於id唯一的document已經刪除，所以查出id為2的文檔

2、在對應的index、type下進行批量查詢

注意：在ElasticSearch6.0以后一個index下只能有一個type，如果設置了多個type會報錯：

GET ecommerce/product/_mget
{
  "ids":[2,3]
}
或者
GET ecommerce/product/_mget
{
  "docs":[
    {
      "_id":2
    },
    {
      "_id":3
      }
    ]
}

二、基於bulk的增刪改

　　bulk語法：

1. delete：刪除一個文檔，只要1個json串就可以了
2. create：PUT /index/type/id/_create，強制創建
3. index：普通的put操作，可以是創建文檔，也可以是全量替換文檔
4. update：執行的partial update操作

注意點：

　　1、bulk api對json的語法有嚴格的要求，除了delete外，每一個操作都要兩個json串，且每個json串內不能換行，非同一個json串必須換行，否則會報錯

　　2、bulk操作中，任意一個操作失敗，是不會影響其他的操作的，但是在返回結果里，會告訴你異常日志：

#index
{"index": {"metadata"}} 
{"data"} 
{"index": {"metadata"}} 
{"data"}
#create
{"create": {"metadata"}} 
{"data"}
{"create": {"metadata"}} 
{"data"}
#update
{"update": {"metadata"}} 
{"data"}
...
#delete
{"delete": {"metadata"}} 
{"delete": {"metadata"}}

Bulk 一次請求 多次操作

1、批量創建，一個index，多個document

任意一個操作失敗，是不會影響其他的操作的，但是在返回結果里，會告訴你異常日志：

POST _bulk
{ "index" : { "_index" : "test_index", "_type" : "test_type", "_id" : "1" } }
{ "uid":1,"age":21}
{ "index" : { "_index" : "test_index", "_type" : "test_type", "_id" : "2" } }
{ "uid":2,"age":22}

2、批量強制創建

任意一個操作失敗，是不會影響其他的操作的，但是在返回結果里，會告訴你異常日志：

POST _bulk
{ "create" : { "_index" : "test_index", "_type" : "test_type", "_id" : "3" } }
{ "uid":3,"age":23}
{ "create" : { "_index" : "test_index", "_type" : "test_type", "_id" : "3" } }
{ "uid":3,"age":23}

3、修改

POST _bulk
{ "update" : {"_index" : "test_index", "_type" : "test_type", "_id" : "3"} }
{ "doc" : {"age" : 33} }

4、刪除

刪除一個文檔，只要1個json串就可以了

POST _bulk
{ "delete" : { "_index" : "test_index", "_type" : "test_type", "_id" : "1" }}
{ "delete" : { "_index" : "test_index", "_type" : "test_type", "_id" : "5" }}

bulk api奇特的json格式

目前處理流程
直接按照換行符切割json，不用將其轉換為json對象，不會出現內存中的相同數據的拷貝；
對每兩個一組的json，讀取meta，進行document路由；
直接將對應的json發送到node上去；
 

換成良好json格式的處理流程
將json數組解析為JSONArray對象，這個時候，整個數據，就會在內存中出現一份一模一樣的拷貝，一份數據是json文本，一份數據是JSONArray對象；
解析json數組里的每個json，對每個請求中的document進行路由；
為路由到同一個shard上的多個請求，創建一個請求數組；
將這個請求數組序列化；
將序列化后的請求數組發送到對應的節點上去；
奇特格式的優缺點
缺點：可讀性差；

優點：不需要將json數組解析為一個JSONArray對象，形成一份大數據的拷貝，浪費內存空間，能夠盡可能地保證性能；

例如：

bulk size最佳大小一般建議說在幾千條，大小在10MB左右。假設說現在100個bulk請求發送到了一個節點上去，然后每個請求是10MB，100個請求，就是1000MB = 1GB，然后每個請求的json都copy一份為jsonarray對象，此時內存中的占用就會翻倍，就會占用2GB的內存，甚至還不止。因為弄成jsonarray之后，還可能會多搞一些其他的數據結構，2GB+的內存占用。

占用更多的內存可能就會積壓其他請求的內存使用量，比如說最重要的搜索請求，分析請求，等等，此時就可能會導致其他請求的性能急速下降。
另外的話，占用內存更多，就會導致java虛擬機的垃圾回收次數更多，跟頻繁，每次要回收的垃圾對象更多，耗費的時間更多，導致es的java虛擬機停止工作線程的時間更多。