33_分散式文件系統_bulk api的奇特json格式與底層效能最佳化關係大揭秘

5765809發表於2024-10-01

課程大綱

bulk api奇特的json格式

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

[{
"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物件,形成一份大資料的複製,浪費記憶體空間,儘可能地保證效能

相關文章