當客戶端的處理過多時,ElasticSearch中的map-reduce等價於什麼? 有沒有像「流」的東西,所以客戶可以減少數據輸出,因爲它是在?相當於Map-Reduce的Elasticsearch
假設我需要在客戶端執行聯接或複雜過濾,這種類型在沒有某種map-reduce方案的情況下可能不適合內存。 我不介意等待很長時間的響應,但我不想粉碎機器(客戶端和/或服務器)。
我應該怎麼辦?
實施例,映射:
{"book":{"properties":{
"title":{"type":"string", "index":"analyzed"},
"author":{"type":"string", "index":"analyzed"},
}
{"character":{"properties":{
"book_id":{"type":"string", "index":"not_analyzed"},
"name":{"type":"string", "index":"analyzed"},
"age":{"type":"integer"},
"catch-phrase":{"type":"string", "index":"analyzed"},
}
說我要查找所有具有該具有catch語句比N(其中,N是在客戶機側供給的參數)不再至少M個字符的書籍
所以這將是get_books_with_short_phrases(M,N)
我當然可以添加字段,如「短語長」到「字符」類型,但讓我們假設的「掛在嘴邊的一句話」的處理可能會改變所有的時間。
我想流的「人物」和「書」的客戶,去了每一個客戶端和輸出然後<book>-<character,len(phrase)>
鍵值進一步降低它<book>-<num_of_chars_with_short_phrase>
如果我加載的所有文件到客戶端內存,這可能是一場災難。如果客戶處理每本書並將其減少到k,那麼它可能會更好。
我錯了嗎?
該解決方案是否在服務器上運行腳本,因此它執行map-reduce?