_mget
一條一條的查詢助琐，比如說要查詢100條數(shù)據(jù)吴藻，那么就要發(fā)送100次網(wǎng)絡(luò)請求，這個開銷還是很大的
如果進(jìn)行批量查詢的話弓柱，查詢100條數(shù)據(jù)沟堡，就只要發(fā)送1次網(wǎng)絡(luò)請求，網(wǎng)絡(luò)請求的性能開銷縮減100倍
（1）mget批量查詢不同index
GET /_mget
{
"docs": [{
"_index": "test_index",
"_type": "test_type",
"_id": 1
}, {
"_index": "test_index2",
"_type": "test_type2",
"_id": 2
}]
}
（2）如果查詢的document是一個index下的不同type
GET /test_index/_mget
{
"docs": [{
"_type": "test_type",
"_id": 1
}, {
"_type": "test_type",
"_id": 2
}]
}
（3）如果查詢的數(shù)據(jù)都在同一個index下的同一個type下矢空，最簡單了
GET /test_index/test_type/_mget
{
"ids": [1, 2]
}
bulk語法
POST /_bulk
{ "delete": { "_index": "test_index", "_type": "test_type", "_id": "3" }}
{ "create": { "_index": "test_index", "_type": "test_type", "_id": "12" }}
{ "test_field": "test12" }
{ "index": { "_index": "test_index", "_type": "test_type", "_id": "2" }}
{ "test_field": "replaced test2" }
{ "update": { "_index": "test_index", "_type": "test_type", "_id": "1", "_retry_on_conflict" : 3} }
{ "doc" : {"test_field2" : "bulk test1"} }
每一個操作要兩個json串航罗，語法如下：
{"action": {"metadata"}}
{"data"}
舉例，比如你現(xiàn)在要創(chuàng)建一個文檔屁药，放bulk里面粥血，看起來會是這樣子的：
{"index": {"index": "test_index", "type", "test_type", "_id": "1"}}
{"test_field1": "test1", "test_field2": "test2"}
有哪些類型的操作可以執(zhí)行呢？
（1）delete：刪除一個文檔酿箭，只要1個json串就可以了
（2）create：PUT /index/type/id/_create复亏，強(qiáng)制創(chuàng)建
（3）index：普通的put操作，可以是創(chuàng)建文檔缭嫡，也可以是全量替換文檔
（4）update：執(zhí)行的partial update操作
注意：
（1）bulk api對json的語法缔御，有嚴(yán)格的要求，每個json串不能換行妇蛀，不同json串間耕突，必須有一個換行；
（2）bulk操作中评架，任意一個操作失敗眷茁，是不會影響其他的操作的，但是在返回結(jié)果里纵诞，會告訴你異常日志上祈；
（3）bulk request會加載到內(nèi)存里，如果太大的話浙芙，性能反而會下降登刺，因此需要反復(fù)嘗試一個最佳的bulk size。一般從10005000條數(shù)據(jù)開始茁裙，嘗試逐漸增加塘砸。另外，如果看大小的話晤锥，最好是在515MB之間掉蔬。
為什么bulk有換行的奇怪格式要求?
如果是任意換行的格式
可讀性好。bulk中的每個操作都可能要轉(zhuǎn)發(fā)到不同的node的shard去執(zhí)行
但es必須要按照下述流程去進(jìn)行處理
（1）將json數(shù)組解析為JSONArray對象矾瘾，這個時候女轿，整個數(shù)據(jù)，就會在內(nèi)存中出現(xiàn)一份一模一樣的拷貝壕翩，一份數(shù)據(jù)是json文本蛉迹，一份數(shù)據(jù)是JSONArray對象
（2）解析json數(shù)組里的每個json，對每個請求中的document進(jìn)行路由
（3）為路由到同一個shard上的多個請求放妈，創(chuàng)建一個請求數(shù)組
（4）將這個請求數(shù)組序列化
（5）將序列化后的請求數(shù)組發(fā)送到對應(yīng)的節(jié)點上去
耗費更多內(nèi)存(bulk size會翻倍北救，因為每個請求的json都copy一份為jsonarray對象)荐操，更多的jvm gc開銷
現(xiàn)在的奇特格式
{"action": {"meta"}}\n
{"data"}\n
{"action": {"meta"}}\n
{"data"}\n
（1）不用將其轉(zhuǎn)換為json對象，不會出現(xiàn)內(nèi)存中的相同數(shù)據(jù)的拷貝珍策，直接按照換行符切割json
（2）對每兩個一組的json托启，讀取meta，進(jìn)行document路由
（3）直接將對應(yīng)的json發(fā)送到node上去
最大的優(yōu)勢在于攘宙，不需要將json數(shù)組解析為一個JSONArray對象屯耸，形成一份大數(shù)據(jù)的拷貝，浪費內(nèi)存空間蹭劈，盡可能地保證性能
