http://blog.chinaunix.net/uid-25979788-id-3270311.html
1) 分布式DB水平切分中用到的主要關鍵技術：分庫，分表，M-S,集群，負載均衡
2) 需求分析：一個大型互聯(lián)網應用每天幾十億的PV對DB造成了相當高的負載，對系統(tǒng)的穩(wěn)定性的擴展性帶來極大挑戰(zhàn)。
3) 現(xiàn)有解決方式：通過數(shù)據切分提高網站性能，橫向擴展數(shù)據層
水平切分DB，有效降低了單臺機器的負載，也減小了宕機的可能性。
集群方案：解決DB宕機帶來的單點DB不能訪問問題。
讀寫分離策略：極大限度提高了應用中Read數(shù)據的速度和并發(fā)量。
典型例子：Taobao,Alibaba,Tencent，它們大都實現(xiàn)了自己的分布式數(shù)據訪問層（DDAL）。Taobao的基于ibatis和Spring的的分布式數(shù)據訪問層，已有多年的應用，運行效率和生產實效性得到了開發(fā)人員和用戶的肯定。
水平切分需要考慮的后續(xù)問題：分庫后路由規(guī)則的選擇和制定，以及后期擴展。如，如何以最少的數(shù)據遷移達到最大容量的擴展。因些路由表分規(guī)則以及負載均衡的考慮很重要。
4）對于DB切分，實質上就是數(shù)據切分。下面從What, Why, How三個方面來講述。
What？什么是數(shù)據切分？
。
具體將有什么樣的切分方式呢和路由方式呢？舉個簡單的例子：我們針對一個Blog應用中的日志來說明，比如日志文章（article）表有如下字段：
article_id(int),title(varchar(128)),content(varchar(1024)),user_id(int)
面對這樣的一個表，我們怎樣切分呢？怎樣將這樣的數(shù)據分布到不同的數(shù)據庫中的表中去呢？其實分析blog的應用，我們不難得出這樣的結論：blog的應用中，用戶分為兩種：瀏覽者和blog的主人。瀏覽者瀏覽某個blog，實際上是在一個特定的用戶的blog下進行瀏覽的，而blog的主人管理自己的blog，也同樣是在特定的用戶blog下進行操作的（在自己的空間下）。所謂的特定的用戶，用數(shù)據庫的字段表示就是“user_id”。就是這個“user_id”，它就是我們需要的分庫的依據和規(guī)則的基礎。我們可以這樣做，將user_id為1～10000的所有的文章信息放入DB1中的article表中，將user_id為10001～20000的所有文章信息放入DB2中的article表中，以此類推，一直到DBn。這樣一來，文章數(shù)據就很自然的被分到了各個數(shù)據庫中，達到了數(shù)據切分的目的。接下來要解決的問題就是怎樣找到具體的數(shù)據庫呢？其實問題也是簡單明顯的，既然分庫的時候我們用到了區(qū)分字段user_id，那么很自然，數(shù)據庫路由的過程當然還是少不了user_id的?？紤]一下我們剛才呈現(xiàn)的blog應用，不管是訪問別人的blog還是管理自己的blog，總之我都要知道這個blog的用戶是誰吧，也就是我們知道了這個blog的user_id，就利用這個user_id，利用分庫時候的規(guī)則，反過來定位具體的數(shù)據庫，比如user_id是234，利用該才的規(guī)則，就應該定位到DB1，假如user_id是12343，利用該才的規(guī)則，就應該定位到DB2。以此類推，利用分庫的規(guī)則，反向的路由到具體的DB，這個過程我們稱之為“DB路由”。
當然考慮到數(shù)據切分的DB設計必然是非常規(guī)，不正統(tǒng)的DB設計。那么什么樣的DB設計是正統(tǒng)的DB設計呢？
我們平常規(guī)規(guī)矩矩用的基本都是。平常我們會自覺的按照范式來設計我們的數(shù)據庫，負載高點可能考慮使用相關的Replication機制來提高讀寫的吞吐和性能，這可能已經可以滿足很多需求，但這套機制自身的缺陷還是比較顯而易見的。上面提到的“自覺的按照范式設計”?？紤]到數(shù)據切分的DB設計，將違背這個通常的規(guī)矩和約束，為了切分，我們不得不在數(shù)據庫的表中出現(xiàn)冗余字段，用作區(qū)分字段或者叫做分庫的標記字段，比如上面的article的例子中的user_id這樣的字段（當然，剛才的例子并沒有很好的體現(xiàn)出user_id的冗余性，因為user_id這個字段即使就是不分庫，也是要出現(xiàn)的，算是我們撿了便宜吧）。當然冗余字段的出現(xiàn)并不只是在分庫的場景下才出現(xiàn)的，在很多大型應用中，冗余也是必須的，這個涉及到高效DB的設計。
Why?為什么要切分數(shù)據？
1) 像Oracle這樣成熟穩(wěn)定的DB可以支撐海量數(shù)據的存儲和查詢，但是價格不是所有人都承受得起。
2) 負載高點時，Master-Slaver模式中存在瓶頸?，F(xiàn)有技術中，在負載高點時使用相關的Replication機制來實現(xiàn)相關的讀寫的吞吐性能。這種機制存在兩個瓶頸：一是有效性依賴于讀操作的比例，這里Master往往會成為瓶頸所在，寫操作時需要一個順序隊列來執(zhí)行，過載時Master會承受不住，Slaver的數(shù)據同步延遲也會很大，同時還會消耗CPU的計算能力，為write操作在Master上執(zhí)行以后還是需要在每臺slave機器上都跑一次。而Sharding可以輕松的將計算，存儲，I/O并行分發(fā)到多臺機器上，這樣可以充分利用多臺機器各種處理能力，同時可以避免單點失敗，提供系統(tǒng)的可用性，進行很好的錯誤隔離。
3) 用免費的MySQL和廉價的Server甚至是PC做集群，達到小型機+大型商業(yè)DB的效果，減少大量的資金投入，降低運營成本，何樂而不為呢？
How？如何切分數(shù)據？
先對數(shù)據切分的方法和形式進行比較詳細的闡述和說明。
數(shù)據切分可以是物理上的，對數(shù)據通過一系列的切分規(guī)則將數(shù)據分布到不同的DB服務器上，通過路由規(guī)則路由訪問特定的數(shù)據庫，這樣一來每次訪問面對的就不是單臺服務器了，而是N臺服務器，這樣就可以降低單臺機器的負載壓力。
數(shù)據切分也可以是數(shù)據庫內的，對數(shù)據通過一系列的切分規(guī)則，將數(shù)據分布到一個數(shù)據庫的不同表中，比如將article分為article_001,article_002等子表，若干個子表水平拼合有組成了邏輯上一個完整的article表，這樣做的目的其實也是很簡單的。舉個例子說明，比如article表中現(xiàn)在有5000w條數(shù)據，此時我們需要在這個表中增加（insert）一條新的數(shù)據，insert完畢后，數(shù)據庫會針對這張表重新建立索引，5000w行數(shù)據建立索引的系統(tǒng)開銷還是不容忽視的。但是反過來，假如我們將這個表分成100個table呢，從article_001一直到article_100，5000w行數(shù)據平均下來，每個子表里邊就只有50萬行數(shù)據，這時候我們向一張只有50w行數(shù)據的table中insert數(shù)據后建立索引的時間就會呈數(shù)量級的下降，極大了提高了DB的運行時效率，提高了DB的并發(fā)量。當然分表的好處還不知這些，還有諸如寫操作的鎖操作等，都會帶來很多顯然的好處。
綜上，分庫降低了單點機器的負載；分表，提高了數(shù)據操作的效率，尤其是Write操作的效率。
上文中提到，要想做到數(shù)據的水平切分，在每一個表中都要有相冗余字符作為切分依據和標記字段，通常的應用中我們選用user_id作為區(qū)分字段，基于此就有如下三種分庫的方式和規(guī)則：（當然還可以有其他的方式）
按號段分：
(1) user_id為區(qū)分，1～1000的對應DB1，1001～2000的對應DB2，以此類推；
優(yōu)點：可部分遷移
缺點：數(shù)據分布不均
(2) hash取模分：
對user_id進行hash（或者如果user_id是數(shù)值型的話直接使用user_id的值也可），然后用一個特定的數(shù)字，比如應用中需要將一個數(shù)據庫切分成4個數(shù)據庫的話，我們就用4這個數(shù)字對user_id的hash值進行取模運算，也就是user_id%4,這樣的話每次運算就有四種可能：結果為1的時候對應DB1；結果為2的時候對應DB2；結果為3的時候對應DB3；結果為0的時候對應DB4，這樣一來就非常均勻的將數(shù)據分配到4個DB中。
優(yōu)點：數(shù)據分布均勻
缺點：數(shù)據遷移的時候麻煩，不能按照機器性能分攤數(shù)據
(3) 在認證庫中保存數(shù)據庫配置
就是建立一個DB，這個DB單獨保存user_id到DB的映射關系，每次訪問數(shù)據庫的時候都要先查詢一次這個數(shù)據庫，以得到具體的DB信息，然后才能進行我們需要的查詢操作。
優(yōu)點：靈活性強，一對一關系
缺點：每次查詢之前都要多一次查詢，性能大打折扣
以上就是通常的開發(fā)中我們選擇的三種方式，有些復雜的項目中可能會混合使用這三種
方式。
4) 接下來對分布式數(shù)據庫解決海量數(shù)據的存訪問題做進一步介紹
分布式數(shù)據方案提供功能如下：
（1）提供分庫規(guī)則和路由規(guī)則（RouteRule簡稱RR），將上面的說明中提到的三中切分規(guī)則直接內嵌入本系統(tǒng)，具體的嵌入方式在接下來的內容中進行詳細的說明和論述；
（2）引入集群（Group）的概念，解決容錯性的問題，保證數(shù)據的高可用性；
（3）引入負載均衡策略（LoadBalancePolicy簡稱LB）；
（4）引入集群節(jié)點可用性探測機制，對單點機器的可用性進行定時的偵測，以保證LB策略的正確實施，以確保系統(tǒng)的高度穩(wěn)定性；
（5）引入讀/寫分離，提高數(shù)據的查詢速度；
