跟我学Elasticsearch(16) _bulk api的奇特json格式与底层性能关系
1、bulk的执行过程
一次bulk请求可能包含了多个增删改document的操作，因此bulk的每个操作都可能要转发到不同的es node的primary shard去执行，这个过程就包含了json数据的传输。
2、假如采用比较良好的json数组格式
假如使用比较良好的json数组格式，会是这个样子
POST /_bulk
{ "update": { "_index": "test_index", "_type": "test_type", "_id": "1", "_retry_on_conflict" : 3} }
{
"doc": {
"test_field": "update test"
}
}
这样看起来是不是清晰明了？但es是不支持的。因为假如es支持的话，es需要对json数组进行额外处理，整个_bulk流程是下面这样的
(1) 将良好的json数组格式解析为JSONArray对象，这个时候，整个json就会在内存中出现一份一模一样的拷贝，一份是json文本，一份是JSONArray对象
(2) 解析出json数组里的每个json(也就是document)
(3) 对每个请求的document进行路由
(4) 为路由到同一个shard上的多个请求，创建一个请求数组
(5) 将这个请求数组序列化
(6) 将序列化后的请求数组发送到对应的节点上去
之前提到过bulk size最佳大小的问题，一般建议在几千条或者10MB左右。所以说可怕的事情来了，假如有100个bulk请求发送到一个节点上去，然后每个请求是10MB，100个请求就是1000M=1G，然后每个请求的json都copy一份为JSONArray对象，此时内存占用就会翻倍，共占用2G内存，甚至不止，因为弄成JSONArray之后，还可能会搞一些其它的数据结构，就会占用2G+的内存。
占用更多的内存可能就会积压内存，影响其它请求的内存使用量，比如说最重要的搜索请求、搜索请求等等，此时就可能导致其它请求的性能急速下降。
另外，占用内存更多，也会导致java虚拟机的垃圾回收次数更频繁，每次要回收的垃圾对象更多，耗费时间更多，导致es的java虚拟机阻塞工作线程的时间更多
3、es支持的json格式
bulk的格式要求为一条数据的json要放在一行
POST /_bulk
{ "update": { "_index": "test_index", "_type": "test_type", "_id": "1", "_retry_on_conflict" : 3} }
{ "doc" : {"test_field" : "update test"} }
这样做有什么好处呢？我们来看下整个_bulk流程
(1) 不用将其转换为json对象，不会出现内存中相同数据的拷贝，直接按照换行符切割json
(2) 对每两个一组的json，读取meta，进行document路由
(3) 直接将对应的json发送到node上去
其最大优势在于，不需要讲json数组解析为一个JSONArray对象，形成一份大数据的拷贝，浪费内存空间，尽可能地保证性能
