mongodb 單表億級資料的拆分方案

拆表是一種常見的解決單表資料庫瓶頸的方案，在實際的應用情境中能夠部分解決單表的寫壓力和讀壓力，但是也會帶來一些更複雜的影響：

彙總查詢變得困難

拆分的鍵一旦選定，更改會非常困難
拆表的過程要保證線上業務不受影響，操作複雜度高
因此，表的拆分一定要選在恰當的時候進行，過早，付出很大代價也並不會帶來效能的提升，過晚，資料量龐大，操作難度加大。

在本次實施的拆分方案中，資料特點是:

單表過億
業務資料是使用者對資源的收藏，結構比較單一
只做單向(使用者–>資料)尋找，不要求反向(資料–>使用者)尋找
資料處於即時變更狀態(新增、刪除、查詢等操作並存)
如何選擇拆分鍵
本例中，拆分的鍵就是使用者 id，且每個使用者關聯的資源資料最大不會過萬。

如何保證拆分的過程中不影響使用者的操作？
本例中，表中的資料基本上只有如下操作

使用者新增一條資料
使用者刪除一條資料
使用者查詢資料(有翻頁)
拆表的基本原理就是對選擇的鍵進行 hash 產生每個鍵所屬的資料表空間名，也就是說，在任意時刻，任意使用者的資料只有以下三種狀態

1.全部在舊錶中
2.部分在新表，部分在舊錶
3.全部在新表中

資料拆分的具體工作是要離線進行的，為了能保證使用者資料在這樣三種狀態之下依然具有像單表中一樣的一致性，需要業務層在處理目前使用者資料時判斷使用者是否在遷移中，只有處於遷移狀態之下，使用者資料才需要特別處理。

遷移狀態如何判斷?
如果目前使用者資料處於遷移狀態，為了保證使用者資料全部可用，即要做到不跨表翻頁，這裡做了特殊處理：一旦開始遷移，使用者的全部資料就會載入到一個特殊地區(這裡我們用了 redis，後面再討論這樣處理可能帶來的問題)，且儲存為有序集資料。

所以，如果使用者處於遷移狀態，則使用者的資料一定存在於這個地區，暫且給此地區命名為 on_progress。

遷移狀態下如何保證使用者資料的正確性？
當使用者處於遷移狀態，使用者新增一條資料，則在新表和 on_progress 中各寫入新增資料，使用者刪除一條資料，則在新表、on_progress同時刪除該資料。

這樣做的目的是什麼?

處於遷移狀態下的使用者，on_progress 中儲存了其所有資料，可以進行翻頁操作，on_progress 中的所有資料會在離線狀態下不斷寫入新表中，遷移完成之後，舊錶中的資料將被刪除，on_progress 中資料也將被清除，這樣使用者資料全部進入新表中，後續的所有操作將只在新表上進行。

on_progress 中的資料在不斷寫入新表的過程中，是按照由新–>舊或由舊–>新的順序進行，在這個過程中：

使用者刪除一條資料

1）有可能該條資料已經寫入新表中，所以刪除操作要在新表中執行。
2）on_progress 中的資料要始終和使用者所有的操作同步來保證資料的正確性和一致性，因而刪除操作也要在 on_progress 中執行。

使用者新增一條資料

1）on_progress 中的資料要始終和使用者所有的操作同步來保證資料的正確性和一致性，因而 on_progress 需要寫入一條資料。
2）在某些邊界條件下，on_progress (假如資料由舊–>新寫入新表) 中的資料移轉完成但還未被刪除，使用者恰巧寫入一條資料，此時使用者仍處於遷移狀態中，但是離線的遷移操作已經認為遷移停止了，因而此時新增資料需要進入新表才能保證資料最終是正確的。

on_progress 的選擇
在這個方案的實施中，on_progress 用了 redis 的有序集，鍵就是使用者的 id，只要檢測到使用者 id 的存在就認為該使用者處於遷移狀態中。

遷移完成之後，先刪除舊錶中的資料，然後再刪除 on_progress 中有序集，所以，只要使用者處於 redis 中，則此時一定是遷移中或遷移完成，如果在舊錶中找到使用者資料，則該使用者一定還沒有開始遷移，否則使用者已經遷移成功。

需要注意的是，選用 redis 可能帶來的問題是 redis 宕機會導致遷移中的資料無法回複(redis 未開持久化操作或其他原因導致資料不能恢複)，只要使用者在舊錶中有資料存在，則使用者刪除或新增資料的操作一定也要在舊錶中執行，再次恢複遷移時，要清除新表資料之後才能正常進行。