Elasticsearch Bulk API 奇特的 JSON 格式

为社么 Elasticsearch 的 Bulk 批量操作要采用看上去很奇怪的 JSON 格式？文字内容来自 B 站中华石杉 Elasticsearch 高手进阶课程

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

如果按照以前的 JSON 格式

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

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

1. 将 JSON 数组解析为 JSONArray 对象，这个时候，整个数据，就会在内存中出现一份一模一样的拷贝，一份数据是 JSON 文本，一份数据是 JSONArray 对象

2. 解析  JSONArray 数组里的每个 JSON，对每个请求中的 Document 进行路由

3. 为路由到同一个 shard 上的多个请求，创建一个请求数组

4. 将这个请求数组序列化

5. 将序列化后的请求数组发送到对应的节点上去

结果：耗费更多内存，更多的 JVM GC 开销

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

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

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

现在的奇特格式

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

1. 不用将其转换为 JSON 对象，不会出现内存中的相同数据的拷贝，直接按照换行符切割 JSON

2. 对每两个一组的 JSON ，读取 meta，进行 Document 路由

3. 直接将对应的 JSON 发送到 node 上去

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

题外话

最后，#28 天写作 挑战 自此告一段落，原以为可以在 28 天内掌握 Elasticsearch 的大部分内容，现在看起来也就是入门而已，所以，我会继续参加 #2 月春节不断更 的活动，继续学习 Elasticsearch。