架構設計原則：資料庫拆分六大原則

最新 08-06

很多同學問我關於架構設計的思維，其實架構設計思維方法，主要是經驗的積累，比如：

資料庫拆分原則

工程拆分原則

性能調優原則

性能評估原則

容錯原則

框架選擇原則

安全設計原則

緩存選擇原則

Nosql選擇原則等

以上架構設計原則，我會一一對應講解，今天講講數據拆分原則。

數據拆分是要首先做準備工作的，然後才開始數據拆分，我先講拆分前準備工作：

第一步：採用分散式緩存redis、memcached等降低對資料庫的讀操作。

第二步：如果緩存使用過後，資料庫訪問量還是非常大，可以考慮資料庫讀、寫分離原則。

第三步：當我們使用讀寫分離、緩存後，資料庫的壓力還是很大的時候，這就需要使用到資料庫拆分了。

資料庫拆分原則：就是指通過某種特定的條件，按照某個維度，將我們存放在同一個資料庫中的數據分散存放到多個資料庫（主機）上面以達到分散單庫（主機）負載的效果。

第一步，首選垂直拆分

一個資料庫由很多表的構成，每個表對應著不同的業務，垂直切分是指按照業務將表進行分類，分布到不同的資料庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面。

比如淘寶中期開始的資料庫端按照業務垂直拆分：按照業務交易資料庫、用戶資料庫、商品資料庫、店鋪資料庫等進行拆分。

優點：

1. 拆分後業務清晰，拆分規則明確。

2. 系統之間整合或擴展容易。

3. 數據維護簡單。

缺點：

1. 部分業務表無法join，只能通過介面方式解決，提高了系統複雜度。

2. 受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。

3. 事務處理複雜。

第二步：其次水平拆分

水平拆分的典型場景就是大家熟知的分庫分表。

垂直拆分後遇到單機瓶頸，可以使用水平拆分。相對於垂直拆分的區別是：垂直拆分是把不同的表拆到不同的資料庫中，而水平拆分是把同一個表拆到不同的資料庫中。

相對於垂直拆分，水平拆分不是將表的數據做分類，而是按照某個欄位的某種規則來分散到多個庫之中，每個表中包含一部分數據。簡單來說，我們可以將數據的水平切分理解為是按照數據行的切分，就是將表中的某些行切分到一個資料庫，而另外的某些行又切分到其他的資料庫中。

分庫分表需要涉及到對應的SQL路由規則主庫備庫等，例如：淘寶設計了一套TDDL來解決這些問題，應用端只需配置對應的規則即可，對應用端的沒有任何侵入的設計。

水平拆分，總之，一般先分庫，如果分庫後查詢仍然慢，於是按照分庫的思想開始做分表的工作資料庫採用分散式資料庫（所有節點的數據加起來才算是整體數據），文件系統採用分散式文件系統任何強大的單一伺服器都滿足不了大型系統持續增長的業務需求，資料庫讀寫分離隨著業務的發展最終也將無法滿足需求，需要使用分散式資料庫及分散式文件系統來支撐。

總結，資料庫拆分原則：