您好,登錄后才能下訂單哦!
Elasticsearch的文檔的存儲路由是什么,針對這個問題,這篇文章詳細介紹了相對應的分析和解答,希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
以 Elasticsearch 7.9.2 為準。
在一個索引中創建文檔時,如何確定放到哪個分片中?
潛在 3 個方式:
隨機
將文檔 id 和分片編號的對應關系保存在數據庫
計算代替存儲:按照某種算法計算出分片編號
如果采用第 1 種方式:
則創建時省事(獲取隨機數即可),但在查詢文檔時需要在多個分片中尋找文檔。
如果采用第 2 種方式:
則實現起來簡單、直接、可靠,但在數據量大的時候表會很大,查詢比較慢。
如果采用第 3 種方式:
創建和查詢時需要進行一次計算,好處是不必在維護對應關系。
ES 采用的是第 3 種方式。
PUT /<索引名>/_doc/<id>?routing=<rk>
如上,在創建文檔時指定 id 和 routing,則此文檔被放到的分片編號為:
es_hash(routing) % 分片數
如果不指定 routing,則在計算時把文檔 id 作為 routing。
指定 routing 的文檔創建之后,會有一個 _routing 字段:
{ "_index": "myindex", "_id": "aaa", "_routing": "myrk", "_source": <obj> // 其他字段 }
假定:
某索引有 n >= 2 個分片。
es_hash("a") % n == 0
es_hash("r") % n == 1
依次執行:
PUT /the_index/_doc/a PUT /the_index/_doc/a?routing=r
則 ES 中會出現 2 個 id 為 a 的文檔。這絕不是使用者所期望的。
造成這樣的原因是:一個 ES 分片其實是一個 Lucene 索引。同一個 Lucene 索引內部,文檔的 id 保證互不相同,但多個 Lucene 索引之間無法保證這一點。
避免方式:
對于某 id 的文檔,要使用 routing,就一直使用,不然就一直不使用。
關于Elasticsearch的文檔的存儲路由是什么問題的解答就分享到這里了,希望以上內容可以對大家有一定的幫助,如果你還有很多疑惑沒有解開,可以關注億速云行業資訊頻道了解更多相關知識。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。