嗨客网搜索
Elasticsearch bulk json格式

bulk api json格式

bulk api 的 json 格式如下:

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

而不是

[{ "action": { }, "data": { } }]

原因

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

如果采用比较良好的json数组格式允许任意的换行,整个可读性非常棒,读起来很爽,Elasticsearch 拿到那种标准格式的 json 串以后,要按照下述流程去进行处理:

  • 将 json 数组解析为 JSONArray 对象,这个时候,整个数据,就会在内存中出现一份一模一样的拷贝,一份数据是 json 文本,一份数据是 JSONArray 对象。
  • 解析 json 数组里的每个 json,对每个请求中的 document 进行路由。
  • 为路由到同一个 shard 上的多个请求,创建一个请求数组。
  • 将这个请求数组序列化。
  • 将序列化后的请求数组发送到对应的节点上去。

耗费更多内存,更多的 jvm gc 开销。

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

占用更多的内存可能就会积压其他请求的内存使用量,比如说最重要的搜索请求,分析请求,等等,此时就可能会导致其他请求的性能急速下降

另外的话,占用内存更多,就会导致 java 虚拟机 的垃圾回收次数更多,跟频繁,每次要回收的垃圾对象更多,耗费的时间更多,导致es的java虚拟机停止工作线程的时间更多。

现在的奇特格式

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

不用将其转换为 json 对象,不会出现内存中的相同数据的拷贝,直接按照换行符切割 json。对每两个一组的 json,读取 meta,进行 document 路由。

直接将对应的 json 发送到 node 上去,最大的优势在于,不需要将 json 数组解析为一个 JSONArray 对象,形成一份大数据的拷贝,浪费内存空间,尽可能地保证性能。


赞助商链接:


嗨客网顶部