ElasticSearch最佳入門實踐（三十二）bulk api的奇特json格式與底層效能優化關係揭祕
1、bulk api奇特的json格式
{"action": {"meta"}}\n
{"data"}\n
{"action": {"meta"}}\n
{"data"}\n
2、bulk中的每個操作都可能要轉發到不同的node的shard去執行
3、如果採用比較良好的json陣列格式
假如弄成下面這樣
[{
"action": {
},
"data": {
}
}]
允許任意的換行，整個可讀性非常棒，讀起來很爽，es拿到那種標準格式的json串以後，要按照下述流程去進行處理
（1）將json陣列解析為JSONArray物件，這個時候，整個資料，就會在記憶體中出現一份一模一樣的拷貝，一份資料是json文字，一份資料是JSONArray物件
（2）解析json數組裡的每個json，對每個請求中的document進行路由
（3）為路由到同一個shard上的多個請求，建立一個請求陣列
（4）將這個請求陣列序列化
（5）將序列化後的請求陣列傳送到對應的節點上去
這樣會耗費更多記憶體，更多的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上去