資料庫架構的演變

在業務資料量比較少的時代，我們使用單機資料庫就能滿足業務使用，隨著業務請求量越來越多，資料庫中的資料量快速增加，這時單機資料庫已經不能滿足業務的效能要求，資料庫主從複製架構隨之應運而生。

主從複製是將資料庫寫操作和讀操作進行分離，使用多個只讀例項（slaver replication）負責處理讀請求，主例項（master）負責處理寫請求，只讀例項通過複製主例項的資料來保持與主例項的資料一致性。由於只讀例項可以水平擴充套件，所以更多的讀請求不成問題，隨著雲端計算、大資料時代的到來，事情並沒有完美的得以解決，當寫請求越來越多，主例項的寫請求變成主要的效能瓶頸。

如何解決上述問題？如果僅僅通過增加一個主例項來分擔寫請求，寫操作如何在兩個主例項之間同步來保證資料一致性，如何避免雙寫，問題會變的更加複雜。這時就需要用到分庫分表（sharding），對寫操作進行切分來解決，如圖1所示：

圖1：典型的讀寫分離和分庫分表

華為雲中間件產品DDM（Distributed Database Middleware）作為RDS的前置分散式資料庫訪問服務，徹底解決了資料庫的擴充套件性問題，對應用透明地實現海量資料的高併發訪問，實現了讀寫分離和分庫分表。

資料分片的實現方案

資料分片的實現方案可分為應用層分片和中介軟體分片，這兩種實現方案的特點如圖2所示：

圖2：應用層分片和中介軟體分片

DDM作為一款優秀的分散式資料庫中介軟體產品，實現了讀寫分離和資料分片功能，使用DDM來分庫分表，應用0改動，對應用完全透明。

分庫分表的切分方式

資料的切分（Sharding）根據其切分規則的型別，可以分為兩種切分模式。一種是按照不同的表（或者Schema）來切分到不同的資料庫（主機）之上，這種切分方式可以稱之為資料的垂直（縱向）切分；另外一種則是根據表中的資料的邏輯關係，將同一個表中的資料按照某種條件拆分到多臺資料庫（主機）上面，這種切分稱之為資料的水平（橫向）切分。

垂直切分最大特點就是規則簡單，實施也更為方便，尤其適合各業務之間的耦合度非常低，相互影響很小，業務邏輯非常清晰的系統。在這種系統中，可以很容易做到將不同業務模組所使用的表分拆到不同的資料庫中。根據不同的表來進行拆分，對應用程式的影響也更小，拆分規則也會比較簡單清晰。

水平切分於垂直切分相比，相對來說稍微複雜一些。因為要將同一個表中的不同資料拆分到不同的資料庫中，對於應用程式來說，拆分規則本身比根據表名來拆分更為複雜，後期的資料維護也會更為複雜一些。

具體而言，如果單個庫太大，這時我們要看是因為表多而導致資料多，還是因為單張表裡面的資料多。如果是因為表多而資料多，使用垂直切分，根據業務切分成不同的庫。如果是因為單張表的資料量太大，這時要用水平切分，即把表的資料按某種規則切分成多張表，甚至多個庫上的多張表。分庫分表的順序應該是先垂直分，後水平分。因為垂直分更簡單，更符合我們處理現實世界問題的方式。

水平切分

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

圖3：水平切分

水平切分的優點

1、拆分規則抽象好，join操作基本可以資料庫做。

2、不存在單庫大資料，高併發的效能瓶頸。

3、應用端改造較少。

4、  提高了系統的穩定性跟負載能力。

水平切分的缺點

1、拆分規則難以抽象。

2、分片事務一致性難以解決。

3、資料多次擴充套件難度跟維護量極大。

4、跨庫join效能較差。

水平切分的典型分片規則

1、HASH取模

例如：取使用者id，然後hash取模，分配到不同的資料庫上。

2、RANGE

例如：從0到10000一個表，10001到20000一個表。

3、時間

按照時間切分，例如：將6個月前，甚至一年前的資料切出去放到另外的一張表，因為隨著時間流逝，這些表的資料被查詢的概率變小，所以沒必要和”熱資料“放在一起，這個也是“冷熱資料分離”。

切分原則一般是根據業務找到適合的切分規則分散到不同的庫，如圖4，根據使用者ID取模作為切分規則。

圖4：根據userid取模進行切分

垂直切分

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

圖5：垂直切分

垂直切分的優點

1、資料維護簡單。

2、拆分後業務清晰，拆分規則明確。

3、系統之間整合或擴充套件容易。

垂直切分的缺點

1、事務處理複雜。

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

3、受每種業務不同的限制存在單庫效能瓶頸，不易資料擴充套件跟效能提高。

由於垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過於龐大，存在單庫讀寫與儲存瓶頸，所以就需要水平拆分來做解決。

切分原則

由於資料切分後資料Join的難度，在此也分享一下資料切分的經驗：

第一原則：能不切分儘量不要切分。

第二原則：如果要切分一定要選擇合適的切分規則，提前規劃好。

第三原則：資料切分儘量通過資料冗餘或表分組（Table Group）來降低跨庫Join的可能。

第四原則：由於資料庫中介軟體對資料Join實現的優劣難以把握，而且實現高效能難度極大，業務讀取儘量少使用多表Join。

分庫分表後的問題和應對策略

分庫分表主要用於應對當前網際網路常見的兩個場景：海量資料和高併發。然而，分庫分表是一把雙刃劍，雖然很好的應對海量資料和高併發對資料庫的衝擊和壓力，但也提高了系統的複雜度和維護成本，帶來一些問題。

1、事務支援

在分庫分表後，就成為分散式事務了，如何保證資料的一致性成為一個必須面對的問題。一般情況下，使儲存資料儘可能達到使用者一致，保證系統經過一段較短的時間的自我恢復和修正，資料最終達到一致。

2、分頁與排序問題

一般情況下，列表分頁時需要按照指定欄位進行排序。在單庫單表的情況下，分頁和排序也是非常容易的。但是，隨著分庫與分表的演變，也會遇到跨庫排序和跨表排序問題。為了最終結果的準確性，需要在不同的分表中將資料進行排序並返回，並將不同分表返回的結果集進行彙總和再次排序，最後再返回給使用者。

3、表關聯問題

在單庫單表的情況下，聯合查詢是非常容易的。但是，隨著分庫與分表的演變，聯合查詢就遇到跨庫關聯的問題。粗略的解決方法：ER分片：子表的記錄與所關聯的父表記錄存放在同一個資料分片上。全域性表：基礎資料，所有庫都拷貝一份。欄位冗餘：這樣有些欄位就不用join去查詢了。ShareJoin：是一個簡單的跨分片join，目前支援2個表的join,原理就是解析SQL語句，拆分成單表的SQL語句執行，然後把各個節點的資料彙集。

4、分散式全域性唯一ID

在單庫單表的情況下，直接使用資料庫自增特性來生成主鍵ID，這樣確實比較簡單。在分庫分表的環境中，資料分佈在不同的分表上，不能再借助資料庫自增長特性，需要使用全域性唯一ID。

分庫分表案例

某稅務核心徵管系統，全國34個省國/地稅，電子稅務局15省格局。

技術路徑：核心徵管 + 納稅服務 業務應用分散式上雲改造。

業務挑戰

1、資料查詢時間3-5秒，響應速度慢嚴重影響體驗

當前業務邏輯大量放在資料庫層，一個辦稅業務的事務邊界過大（40條SQL語句），涉及以“申報”、“發票”大表為主的多張表關聯事務操作，導致業務查詢響應速度慢。

2、億級資料快速的增長，挑戰業務效能瓶頸

省級稅務局，辦稅高峰期承載百萬級使用者併發量，3000-5000TPS。現網分析得到資料：核心徵管庫近1000張表，其中“申報”、“發票”業務表資料量大、增長快，是主要瓶頸表；發票綜合資訊：每省10億級條記錄，每年千萬到億條記錄級別增量；申報資訊表：億級記錄資料量。

解決方案

1、垂直分庫、微服務分解資料庫壓力，降低單業務sql數

基於微服務將大事務拆解為非同步小事務，業務邏輯從資料庫層面剝離。拆分主庫資料，將大表垂直拆分到多個數據庫中，一個業務40條SQL縮減到20條SQL，達到分解資料庫壓力的目的。

2、資料分片支撐海量資料增長，線性提升業務處理速度

單表億級記錄以納稅人作為拆分鍵，拆分到RDS-MySQL 的128個分片上。實現支撐海量資料的儲存。拆分後資料庫設計簡潔、簡單，資料庫的表之間不設外來鍵，不寫觸發器，不寫儲存過程，實現資料庫記錄的水平擴充套件。

3、讀寫分離提升查詢效能

DDM自動實現讀寫分離，透明地完成寫操作和讀操作的分發，應用程式無需做特殊的改動和處理邏輯。寫操作分發到RDS主例項，讀操作自動分發到RDS的多個讀例項上，這樣寫操作不會影響讀操作的併發，讀併發業務增長時只需要按需增加只讀例項即可。

企業受益

1、使用了DDM之後，輕鬆突破原來的效能瓶頸，一次業務操作，原來需要3到5秒，現在只需要1秒。

2、讀寫操作通過DDM的自動讀寫分離，在不改動業務情況下，輕鬆提升了整體的讀寫併發能力。