數據庫的垂直劃分和水平劃分

  讀寫分離，基本的原理是讓主數據庫處理事務性增、改、刪操做（INSERT、UPDATE、DELETE），而從數據庫處理SELECT查詢操做。數據庫複製被用來把事務性操做致使的變動同步到集羣中的從數據庫。

       爲何要分庫、分表、讀寫分？

       單表的數據量限制，當單表數據量到必定條數以後數據庫性能會顯著降低。數據多了以後，對數據庫的讀、寫就會不少。分庫減小單臺數據庫的壓力。接觸過幾個分庫分表的系統，都是經過主鍵進行散列分褲分表的。這類數據比較特殊，主鍵就是惟一的獲取該條信息的主要途徑。好比：京東的訂單、財付通的交易記錄等。。。該類數據的用法，就是經過訂單號、交易號來查詢該筆訂單、交易。

        還有一類數據，好比用戶信息，每一個用戶都有系統內部的一個userid，與userid對應的還有用戶看到的登陸名。那麼若是分庫分表的時候單純經過userid進行散列分庫，那麼根據登陸名來獲取用戶的信息，就沒法知道該用戶處於哪一個數據庫中。

       或許有朋友會說，咱們能夠維護一個email----userid的映射關係，根據email先查詢到userid，在根據userid的分庫分表規則到對應庫的對應表來獲取用戶的記錄信息。這麼作是能夠的，可是這個映射關係的條數自己也是個瓶頸，原則上是沒有減小單表內數據的條數，算是一個單點。而且要維護這個映射關係和用戶信息的一致性（修改登陸名、多登陸名等其餘特殊需求），最大一個緣由，其實用戶信息是一個讀大於寫的庫，web2.0都是以用戶爲中心，全部信息都和用戶信息相關聯，因此對用戶信息拆分仍是有必定侷限性的。

       對於這類讀大於寫而且數據量增長不是很明顯的數據庫，推薦採用讀寫分離+緩存的模式，試想一下一個用戶註冊、修改用戶信息、記錄用戶登陸時間、記錄用戶登陸IP、修改登陸密碼，這些是寫操做。可是以上這些操做次數都是很小的，因此整個數據庫的寫壓力是很小的。惟一一個比較大的就是記錄用戶登陸時間、記錄用戶登陸IP這類信息，只要把這些常常變更的信息排除在外，那麼寫操做能夠忽略不計。因此讀寫分離首要解決的就是常常變化的數據的拆分，好比：用戶登陸時間、記錄用戶登陸IP。這類信息能夠單獨獨立出來，記錄在持久化類的緩存中（可靠性要求並不高，登錄時間、IP丟了就丟了，下次來了就又來了）

        以oracle爲例，主庫負責寫數據、讀數據。讀庫僅負責讀數據。每次有寫庫操做，同步更新cache，每次讀取先讀cache在讀DB。寫庫就一個，讀庫能夠有多個，採用dataguard來負責主庫和多個讀庫的數據同步。

 

本文轉自http://blog.csdn.net/kobejayandy/article/details/8775255 感謝做者

數據切分能夠是物理上的，對數據經過一系列的切分規則將數據分佈到不一樣的DB服務器上，經過路由規則路由訪問特定的數據庫，這樣一來每次訪問面對的就不是單臺服務器了，而是N臺服務器，這樣就能夠下降單臺機器的負載壓力。

數據切分也能夠是數據庫內的，對數據經過一系列的切分規則，將數據分佈到一個數據庫的不一樣表中，好比將article分爲article_001,article_002等子表，若干個子表水平拼合有組成了邏輯上一個完整的article表，這樣作的目的其實也是很簡單的。 舉個例子說明，好比article表中如今有5000w條數據，此時咱們須要在這個表中增長（insert）一條新的數據，insert完畢後，數據庫會針對這張表從新創建索引，5000w行數據創建索引的系統開銷仍是不容忽視的。可是反過來，假如咱們將這個表分紅100 個table呢，從article_001一直到article_100，5000w行數據平均下來，每一個子表裏邊就只有50萬行數據，這時候咱們向一張只有50w行數據的table中insert數據後創建索引的時間就會呈數量級的降低，極大了提升了DB的運行時效率，提升了DB的併發量。固然分表的好處還不知這些，還有諸如寫操做的鎖操做等，都會帶來不少顯然的好處。

綜上，分庫下降了單點機器的負載；分表，提升了數據操做的效率，尤爲是Write操做的效率。

 

頂

2

踩