[丁原]使用Mysql來搭建可擴充套件的SNS網站（淺談）

近幾年WEB2.0的火爆，帶動了Mysql的使用熱潮，不管是小企業還是大網站，都有意無意的開始使用Mysql來搭建新資料平臺，傳統網站隨著業訪問量，資料量的急劇膨脹，集中式的資料庫也越來越成為瓶頸，很難做進一步的擴充套件，做讀寫分離，而這些都是Mysql的優勢所在，容易擴充套件使Mysql漸漸成為了企業新的選擇。

說到可擴充套件性，和APP一樣，當資料庫壓力上來時，只要通過不斷增加資料庫伺服器來解決，儘量不去調整應用程式，伺服器硬體壞掉了，直接拿臺新的伺服器頂上就可以了，這是我設計的初衷。下面我會通過Mysql來淺談SNS資料庫的設計思路（注：只是我的理解），SNS關注的是個體（userid），比如我的好友，我的日誌，我的相簿，我的幫派等等，強調人的個體行為，現在很火的SNS網站如51.com，Facebook都是通過Mysql來搭建的，接下來我將嘗試探討這種業務型別的設計軌跡，如何做到可擴充套件性。

先從如何分庫開始，考慮按使用者（userid）屬性來分庫，使用者有好友，有部落格，有相簿等，只要是使用者的行為，都跟著使用者走，單庫中包含了使用者的所有行為，這種分法定位起來很容易，找到某個庫後就找到了使用者的所有行為，很方便。也可以按業務型別來分庫，每個業務獨立成庫，分成好友庫，部落格庫，相簿庫等，不同業務模組各自獨立，這種分法思路很清晰，分庫的規則可以不同業務靈活多變，開發起來也相對比較簡單。

接下來討論分表的設計，Mysql上設計資料庫我力求做到小快靈的原則，單庫資料量要比較小，資料庫要做到快速響應，表設計要非常靈活，不同的業務可以選擇相應的分表規則，小快靈的思想要求表設計很容易做水平擴充套件，資料量過大時很容易進行表拆分。從設計思路上來說，可以使用配置表（後設資料）來儲存分表的配置資訊，假設今年的註冊使用者規劃在2000萬左右，考慮分成4張表，table1儲存1-500萬的資料，500萬-1000萬儲存在table2，。。。每個表保留500萬的資料，分表規則和查詢路由通過配置表來維護，某天我們發現table1的資料量過於活躍，資料庫壓力很大，同樣的開始考慮拆表，修改分表配置資訊，同時把table1拆成兩張表存到兩臺伺服器來分擔壓力，當然也不一定說是訪問壓力才導致分表，當表的記錄數大到一定的數量，同樣也需要拆表。採用配置資訊來維護分表的規則非常靈活，一切以配置資訊為準，不過太靈活也意味這風險點很高，配置資訊的重要性不言而喻。接下來我提到的是採用mod取模來分表，初期考慮採用mod(4)分成4張表，根據取模的結果0,1,2,3分成4張表，隨著業務發展的帶來資料量的膨脹，訪問壓力加大，需要對錶作進一步拆分，因為取模帶來的特殊性以及拆表儘量不做資料遷移的原則，我建議通過倍數來擴充套件，採用mod（8）來擴充套件表，接下來考慮使用mod(16)來拆分，不斷的通過倍數來做擴充套件。相對於配置資訊分表，取模設計相對來說並不是那麼的靈活，不過靈活也不一定全是好事，萬一配置資訊被人誤調整過，那就麻煩了。

經常看到很多表中沒有主鍵，這對於嚴謹的系統設計來說，通常是不可接受的，大部分表會使用自增id來做主鍵，剛開始可能是單表，接下來可能拆成多張表，用auto incremental很難保證在多個表中保持唯一性，那如何保證分表（user_table1,user_table2,…）之間id的唯一性呢？考慮oracle使用序列來保證id的唯一性，序列是凌駕於表之上的，同樣考慮在Mysql資料庫中增加一張序列表，模擬oracle的序列實現方式，需要自增的表都可以在這裡面新增一條記錄，對於分表來說，每個子表呼叫的是同一條記錄，應用程式直接呼叫這條記錄來做自增，來保證id的唯一性。這僅僅是一種實現方式，如果只要求id的唯一性，可以使用函式來生成，也可以按照某種規則如時間精確到毫秒來保證id的唯一，方法太多了。

圍繞可擴充套件性，簡單提了一些分庫，分表，id生成的設計思路，這僅僅是整個網站中的冰山一角，還有太多的細節上需要我們去思考，如基礎資料表，僅僅幾十條資料不做分表分庫，當其他表拆成多個庫時這些資料儲存在哪兒，專門建個基礎庫還是每個庫都保留一份呢，分表，到底分多少個合適，是用Myisam儲存引擎還是用Innodb呢？這些都需要我們細細的思索，細節決定成敗，關注每個細節，每個表的實現方式，儘量多參與到業務中去，多瞭解產品經理，開發的想法，多去了解Mysql的實現方式，Mysql自身的優勢，Mysql可擴充套件性的優勢，多瞭解業界成熟的設計思路，結合自身的業務模式，設計出更合理的系統。

參考：
http://www.biuuu.com/?p=315
http://highscalability.com/flickr-architecture
http://www.example.net.cn/archives/2006/06/feedburneruoumy.html
http://www.dbanotes.net/arch/facebook_photos_arch.html
http://www.baselinemag.com/c/a/Projects-Networks-and-Storage/Inside-MySpacecom/

<!--

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/1384/viewspace-611260/，如需轉載，請註明出處，否則將追究法律責任。