關係型資料庫的架構演變

在網際網路場景下，關係型資料庫常見的效能瓶頸主要有兩個

• 大量的併發 讀/寫操作，導致倒庫出現難以承受的負載壓力
• 單表儲存資料量過大，導致檢索效率低下

資料庫讀寫分離

在系統初期，整體的併發了相對較小，因此一般都是將所有的資料資訊儲存在單庫中進行讀/寫操作。但是隨著使用者規模不斷提升，單庫逐漸力不從心，TPS/QPS越來越低。因此到了這個時候，dba會將資料庫設定為讀寫分離狀態（生產環境一般會採用一主一從或者一主多從），Master負責寫操作，Slave作為備庫，不開放寫操作，但是允許讀操作，主從之間保持資料同步即可。
讀寫分離之後，可以大大提升單庫無法支撐的負載壓力

資料垂直分庫

讀寫分離讓系統的吞吐量相對於單庫來說有了一定的提升，但是隻依靠讀寫分離並不能一勞永逸，隨著使用者規模攀升，系統瓶頸一定會暴露。
因為，這個階段Dba會對資料庫執行垂直分庫，垂直分庫就是根據自身業務垂直劃分，將表拆分到不同的業務庫中。實現分而治之的資料管理和讀寫操作。

單表資料量一大，讀操作會逐漸成為瓶頸
寫操作因為是順序寫，所以基本上資料庫的寫入操作不會因為資料膨脹而成為瓶頸，但是讀操作一定會存在上限；
讀操作成為瓶頸的時候，就該做水平分庫了

資料庫水平分庫與水平分表

水平分表:將原本冗餘在單庫中的單個業務表拆分成為n個“邏輯相關”的業務字表(如：tab_000、tab_0001、…..)
水平分庫:如果Master的TPS過高，則還可以對垂直分庫後的單一業務進行水平化，同水平分表類似。

分庫分表操作主要是為了解決：高併發場景下單庫的效能瓶頸，並充分利用分散式的威力提升資料庫的讀/寫能力。
假設後續業務表中的資料量又一次達到儲存閾值並對效能產生影響時，DBA只需要再次對現有業務庫和業務表橫向擴容，並遷移資料即可。

Mysql Sharding 和 Mysql Cluster區別

Mysql Cluster只是一個數據庫的叢集，其優勢只是擴充套件了資料庫的並行處理能力，但是其使用成本、維護成本非常高，並且實施起來比較複雜

Mysql sharding 不近提升資料庫的並行處理能力，還能夠解決因為單表資料量過大所產生的檢索瓶頸。

Mysql Cluster前者是叢集模式，Mysql sharding是分散式模式。Sharding是當下網際網路最好的選擇