在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工具來實現）。
好了，說了這麼多，開始今天的正文吧。
前面說過，該方案使用了接口方式，這裡就先看一下相應的接口聲明：
