Discuz!NT千萬級數據量上的兩駕馬車 TokyoCabinet,MongoDB

特別是像主題表（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工具來實現）。

    好了，說了這么多，開始今天的正文吧。

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