聚合操作模式(mget,bulk)APIS和单个操作和类似,不同的是,接受请求的node知道操作的document在那个shard上,他根据各个shard拆分总的multi-document请求到单个的multi-document,然后一起分发到各个node。
一旦负责请求的node从各个node收到响应,这个请求node就整理这些请求到一个响应体,返回给客户端。
下图是使用mget进行多文档检索:
步骤如下:
1:客户端发送mget请求到node1
2:node1根据shard拆分到多个multi-get请求,然后一起发送到相应的node中的primary或者replica shard。一旦所有的相应都被node1收到,node1就把相应报告给客户端。
routing参数能设置到docs数组的每个document。preference参数能设置到顶级的mget请求中。
下图使用bulk进行document的修改:
下面列出在一个bulk中执行create,index,delete请求的必要步骤:
1:客户端向node1发送请求
2:node1根据shard构建bulk请求,转发到相对应的primary shard。
3:primary shard连续的执行每个动作,当每个动作都成功,primary shard转发新的document(或删除的document)到他的replica shard,然后在去执行下一个动作。当所有的replica shad都成功执行了所有的动作,各个node就会向requesting node作出成功的报告,然后requestiong node向客户端发送成功报告。
bulk API也接受replication和consistency参数作为整个bulk请求的顶级参数,routing参数可以对每个请求设置。
为什么是这种格式?
当我们在Cheaper in bulk学习Bulk请求的时候,你或许会问:为什么bulkAPI要对新的一行格式化一个换行符呢,而不是像mget一样包装到JSON的数组中?
回答这个问题之前,我们要解释一下背景:
每个bulk请求中的document也许是属于不同的primary shard,请求的document或许要分配到cluster中的任意的node上,也就是说,bulk中的每个请求动作,都需要转发到正确的node中正确shard上。
如果单个的请求是被包装在JSON数组中,要做如下的事情:
1:解析JSON到一个数组(包括document的数据,或许还会很大)
2:查看每个请求,决定这个请求要到那个shard上
3:为每个shard的请求都创建一个数组
4:序列化这些数组到内部的格式
5:把请求发送到每个shard
这也能工作,但是需要更多的内存备份本质上一样的数据,并且要创建很多的数据结构,然后JVM要花费一定的性能回收这些垃圾。
ES建立了网络缓冲,原始请求数据到达就直接读取。他使用了换行符标记解析action/metadate决定那个shard应该处理这个请求。
原始数据被直接的转发到正确的shard。没有冗余数据,没有浪费的数据结构。整个请求进程实在一个很小的内存中进行处理的。
原文:http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/distrib-multi-doc.html
多文档模式(multi-document parrerns),布布扣,bubuko.com
多文档模式(multi-document parrerns)
原文地址:http://www.cnblogs.com/blog1350995917/p/3735301.html