Discuz!NT千萬級資料量上的兩駕馬車--TokyoCabinet,MongoDB

在Discuz!NT的企業版設計過程中，處理大資料表一直是一個讓人頭疼的問題，特別是像主題表 （topic），使用者表（user）等，因為對於一個流量和發帖量都很大的論壇而言，在運行幾年之後，這兩 個表的資料量可能會破千萬（註：因為文章表採用分表機制，所以這裡暫未涉及，但出於效能考慮，也提 供了本文中類似的解決方案）。當時考慮的架構設計中有兩種思路來解決這種問題：

一種是採用類似MYSPACE的方式，即按一定記錄KEY值（比如使用者表的UID）來對大資料表中的記錄進行 分割，比如前200萬使用者（即：UID<200w）放入一個表，200-400萬的使用者放入另一個表，以此類推。 當然可以把幾個表都放到一個資料庫中，也可以放到別的 MSSQL資料庫上或執行個體上。但這種方案有一些問 題，例如當使用者表需要被聯表（如LEFT JION）查詢時使用，比如我們的文章表進行分頁查詢時就需要左 聯user表，這時如採用分表或分布式布署就可能面臨這樣的問題，不僅商務邏輯要變化，就連預存程序中 也要產生不小的變化，這裡還不考慮效率上的問題。當然有人建議可以使用資料冗餘的方式，比如在文章 表中冗餘使用者資訊相應欄位，但這種方案同樣要大幅度的修改即有代碼，同時如果使用者資訊發生變化時， 不僅要更新使用者表，還要更新文章表中的相應冗餘欄位，如果這兩者不同步，就會造成資料顯示異常，當 然在資料庫層面增加儲存成本也是不得不付出的。

第二種就是使用能處理大資料量表格的第三方工具，比如本文所說的TokyoTyrant,Mongodb等，這類 NOSQL軟體從一問世就是面向海量資料存放區訪問的，而且這類軟體往往都是開源的，另外通過與打算布署 企業版的使用者接觸，發現雖然他們的伺服器配置很高，但數量即不多，所以就要考慮如何最大限度的複用 已有的機器資源，而這類NOSQL軟體往往都是‘性價比’很高的，即用不多的資源（記憶體，CPU等）就能達 到意想不到的效果。當然我目前對其還是很謹慎的使用，即不會馬上把它當做主力資料存放區工具，而是輔 助MSSQL資料庫工具，所以大家在看完本文後會發現，這兩個工具在企業版中的角色頂多就是一個進階的 MEMCACEHD。不過我的想法很簡單，就是任何工具和技術，如果不是很瞭解它或者它很新，那麼必定要有 一個“考核期”，如果在‘任間’內它通過考核，才委以重任，如未通過考核，也不會讓系統平台承擔過 多的技術層面上的‘風險’。

綜上所述，最終我把方向放到了TokyoTyrant,Mongodb上，之所以選擇了這兩個工具，主要基於下面因 素：

1.海量資料的解決方案應該可以跑在LINUX和WINDOW平台上。當然有人會說Mongodb完全可以跑這兩個 平台，那還為什麼要引入 TokyoTyrant呢？其實這裡有一些產品的特殊情況要考慮，比如我們的使用者中絕 大多數對於資料的讀寫比在 4：1，即5條SQL訪問中有4條是SELECT操作，1條是CUD操作，這就造成了讀寫 比例的失衡。雖然Mongodb在讀寫效能上非常優異和穩定，但在並發讀上相對於TokyoTyrant+cabinet還是 有一些差距（注:更多內容參見該連結，然後這隻限於在我們產品中壓力測試環境下的結果，不具備普遍 性，所以希望大傢具體問題具體分析）

2.考慮到有些使用者公司是有相應技術儲備的，兩種方案也便於使用者公司進行的技術選型（當然因為采 用介面方式，使用者完全可以引入其它第三方的NOSQL工具來實現）。

好了，說了這麼多，開始今天的本文吧。

前面說過，該方案使用了介面方式，這裡就先看一下相應的介面聲明：