Elasticsearch的文檔的存儲路由是什么，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

為內(nèi)黃等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及內(nèi)黃網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為做網(wǎng)站、成都網(wǎng)站建設(shè)、內(nèi)黃網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

以 Elasticsearch 7.9.2 為準。

問題

在一個索引中創(chuàng)建文檔時，如何確定放到哪個分片中？

潛在 3 個方式：

• 隨機

• 將文檔 id 和分片編號的對應(yīng)關(guān)系保存在數(shù)據(jù)庫

• 計算代替存儲：按照某種算法計算出分片編號

如果采用第 1 種方式：

則創(chuàng)建時省事（獲取隨機數(shù)即可），但在查詢文檔時需要在多個分片中尋找文檔。

如果采用第 2 種方式：

則實現(xiàn)起來簡單、直接、可靠，但在數(shù)據(jù)量大的時候表會很大，查詢比較慢。

如果采用第 3 種方式：

創(chuàng)建和查詢時需要進行一次計算，好處是不必在維護對應(yīng)關(guān)系。

ES 的實現(xiàn)方式

ES 采用的是第 3 種方式。

PUT /<索引名>/_doc/?routing=

如上，在創(chuàng)建文檔時指定 id 和 routing，則此文檔被放到的分片編號為：

es_hash(routing) % 分片數(shù)

如果不指定 routing，則在計算時把文檔 id 作為 routing。

指定 routing 的文檔創(chuàng)建之后，會有一個 _routing 字段：

{
    "_index": "myindex",
    "_id": "aaa",
    "_routing": "myrk",
    "_source": 
    // 其他字段
}

使用 routing 潛在問題以及避免方式

假定：

• 某索引有 n >= 2 個分片。

• es_hash("a") % n == 0

• es_hash("r") % n == 1

依次執(zhí)行：

PUT /the_index/_doc/a
PUT /the_index/_doc/a?routing=r

則 ES 中會出現(xiàn) 2 個 id 為 a 的文檔。這絕不是使用者所期望的。

造成這樣的原因是：一個 ES 分片其實是一個 Lucene 索引。同一個 Lucene 索引內(nèi)部，文檔的 id 保證互不相同，但多個 Lucene 索引之間無法保證這一點。

避免方式：

對于某 id 的文檔，要使用 routing，就一直使用，不然就一直不使用。

關(guān)于Elasticsearch的文檔的存儲路由是什么問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識。