Lucene系列-index擴展
Shard與Replica
- Shard：index數據分片.當索引數據到達百億級別的,單份數據索引讀取和搜索都是非常耗時間的,即使在用earlytermination的情況下,latency也在100ms左右. 數據分片成shard,可以快速的提高搜索效率.
- Replica：shard的備份，在搜索QPS較高的時候,Replica可以提供搜索的吞吐量. 一般包含一個primary shard和多個replica shards.
Index擴展
index擴展一般包含橫向擴展和縱向擴展,將大數據切分成小數據塊,或者將數據分片複製copy到一臺機器.
橫向擴展策略:
考慮線上機器運行,此時要保證搜索正常的work,並向外提供搜索服務.
1.首先應該停掉index write操作, 即利用一些消息隊列存儲操作階段的線上來的增量消息.
2.循環依次複製所有的消息分片.
3.打開之前的index服務接口和新的replica.
縱向擴展策略:
當索引量比較大,disk讀寫速度變慢,搜索latency變高.我們需要增加分片,從而改變單個shard index的大小
縱向擴展分兩種:
(1)增加新的shard,之後所有的新增索引建到新的shard上,之前的刪除操作要遍歷所有的shard.
(2)增加新的shard,把所有數據在平均分配一下.例如之前有2個shard,現在將2個shard的數據平均分配到3個shard上.新增的數據還是按路由規則(hash規則)寫入到某一個特定的shard中.
以下策略是主要是針對無原始數據或者重建索引時間代價比較大的,這種情況下,即使在hadoop index 離線索引也不可抵消.我們實現了以下方案.具體實現:
以2個shard擴展成3個shard爲例,如圖:
我們定義document文檔路由規則, hash函數: routeId = documentId % shardSize;
根據hash函數我們可以知道,shard1上的數據需要分裂數據到shard1’, shard2’, shard3’上.我們知道lucene底層數據的刪除是先將要刪除的doc設置標識位delete標識, 在index merge的時候進行刪除.我們可以利用這個規律來進行. 假設shard1有三個文檔.原始標識位是111,然後複製2份, 這時候就有三份shard1.通過設置標識位100,010,001,這樣就shard1的數據根據我們之前定義的規則hash出來了.同理shard2也是這樣.
如此進行之後,將分配到同一個node上的兩個segment數據合併成統一的一份索引.
上面要注意的問題:
1.上線服務一致性問題,即在shard1,shard2分裂的過程中,這個時間段如果還繼續向外提供服務,可能不穩定.因此如果有多個replica服務就可以停掉此服務.
2.線上數據的copy是比較費時間的,即相對於數據重建索引的代價而言,一般較小