一. 數據切分

關系型數據庫本身比較容易成為系統(tǒng)瓶頸，單機存儲容量、連接數、處理能力都有限。當單表的數據量達到 1000W 或 100G 以后，由于查詢維度較多，即使添加從庫、優(yōu)化索引，做很多操作時性能仍下降嚴重。此時就要考慮對其進行切分了，切分的目的就在于減少數據庫的負擔，縮短查詢時間。

數據庫分布式核心內容無非就是數據切分 (Sharding)，以及切分后對數據的定位、整合。數據切分就是將數據分散存儲到多個數據庫中，使得單一數據庫中的數據量變小，通過擴充主機的數量緩解單一數據庫的性能問題，從而達到提升數據庫操作性能的目的。

[[230784]]

數據切分根據其切分類型，可以分為兩種方式：垂直 (縱向) 切分和水平 (橫向) 切分

1、垂直 (縱向) 切分

垂直切分常見有垂直分庫和垂直分表兩種。

垂直分庫就是根據業(yè)務耦合性，將關聯(lián)度低的不同表存儲在不同的數據庫。做法與大系統(tǒng)拆分為多個小系統(tǒng)類似，按業(yè)務分類進行獨立劃分。與 "微服務治理" 的做法相似，每個微服務使用單獨的一個數據庫。如圖：

垂直分表是基于數據庫中的 "列" 進行，某個表字段較多，可以新建一張擴展表，將不經常用或字段長度較大的字段拆分出去到擴展表中。在字段很多的情況下 (例如一個大表有 100 多個字段)，通過 "大表拆小表"，更便于開發(fā)與維護，也能避免跨頁問題，MySQL 底層是通過數據頁存儲的，一條記錄占用空間過大會導致跨頁，造成額外的性能開銷。另外數據庫以行為單位將數據加載到內存中，這樣表中字段長度較短且訪問頻率較高，內存能加載更多的數據，命中率更高，減少了磁盤 IO，從而提升了數據庫性能。

垂直切分的優(yōu)點：

解決業(yè)務系統(tǒng)層面的耦合，業(yè)務清晰

與微服務的治理類似，也能對不同業(yè)務的數據進行分級管理、維護、監(jiān)控、擴展等

高并發(fā)場景下，垂直切分一定程度的提升 IO、數據庫連接數、單機硬件資源的瓶頸

缺點：

部分表無法 join，只能通過接口聚合方式解決，提升了開發(fā)的復雜度

分布式事務處理復雜

依然存在單表數據量過大的問題 (需要水平切分)

2、水平 (橫向) 切分

當一個應用難以再細粒度的垂直切分，或切分后數據量行數巨大，存在單庫讀寫、存儲性能瓶頸，這時候就需要進行水平切分了。

水平切分分為庫內分表和分庫分表，是根據表內數據內在的邏輯關系，將同一個表按不同的條件分散到多個數據庫或多個表中，每個表中只包含一部分數據，從而使得單個表的數據量變小，達到分布式的效果。如圖所示：

庫內分表只解決了單一表數據量過大的問題，但沒有將表分布到不同機器的庫上，因此對于減輕 MySQL 數據庫的壓力來說，幫助不是很大，大家還是競爭同一個物理機的 CPU、內存、網絡 IO，最好通過分庫分表來解決。

水平切分的優(yōu)點：

不存在單庫數據量過大、高并發(fā)的性能瓶頸，提升系統(tǒng)穩(wěn)定性和負載能力

應用端改造較小，不需要拆分業(yè)務模塊

缺點：

跨分片的事務一致性難以保證

跨庫的 join 關聯(lián)查詢性能較差

數據多次擴展難度和維護量極大

水平切分后同一張表會出現在多個數據庫 / 表中，每個庫 / 表的內容不同。幾種典型的數據分片規(guī)則為：

1、根據數值范圍

按照時間區(qū)間或 ID 區(qū)間來切分。例如：按日期將不同月甚至是日的數據分散到不同的庫中; 將 userId 為 1~9999 的記錄分到第一個庫，10000~20000 的分到第二個庫，以此類推。某種意義上，某些系統(tǒng)中使用的 "冷熱數據分離"，將一些使用較少的歷史數據遷移到其他庫中，業(yè)務功能上只提供熱點數據的查詢，也是類似的實踐。

這樣的優(yōu)點在于：

單表大小可控

天然便于水平擴展，后期如果想對整個分片集群擴容時，只需要添加節(jié)點即可，無需對其他分片的數據進行遷移

使用分片字段進行范圍查找時，連續(xù)分片可快速定位分片進行快速查詢，有效避免跨分片查詢的問題。

缺點：

熱點數據成為性能瓶頸。連續(xù)分片可能存在數據熱點，例如按時間字段分片，有些分片存儲最近時間段內的數據，可能會被頻繁的讀寫，而有些分片存儲的歷史數據，則很少被查詢

2、根據數值取模

一般采用 hash 取模 mod 的切分方式，例如：將 Customer 表根據 cusno 字段切分到 4 個庫中，余數為 0 的放到第一個庫，余數為 1 的放到第二個庫，以此類推。這樣同一個用戶的數據會分散到同一個庫中，如果查詢條件帶有 cusno 字段，則可明確定位到相應庫去查詢。

優(yōu)點：

數據分片相對比較均勻，不容易出現熱點和并發(fā)訪問的瓶頸

缺點：

后期分片集群擴容時，需要遷移舊的數據 (使用一致性 hash 算法能較好的避免這個問題)

容易面臨跨分片查詢的復雜問題。比如上例中，如果頻繁用到的查詢條件中不帶 cusno 時，將會導致無法定位數據庫，從而需要同時向 4 個庫發(fā)起查詢，再在內存中合并數據，取最小集返回給應用，分庫反而成為拖累。

二. 分庫分表帶來的問題

分庫分表能有效的環(huán)節(jié)單機和單庫帶來的性能瓶頸和壓力，突破網絡 IO、硬件資源、連接數的瓶頸，同時也帶來了一些問題。下面將描述這些技術挑戰(zhàn)以及對應的解決思路。

1、事務一致性問題

分布式事務

當更新內容同時分布在不同庫中，不可避免會帶來跨庫事務問題。跨分片事務也是分布式事務，沒有簡單的方案，一般可使用 "XA 協(xié)議" 和 "兩階段提交" 處理。

分布式事務能最大限度保證了數據庫操作的原子性。但在提交事務時需要協(xié)調多個節(jié)點，推后了提交事務的時間點，延長了事務的執(zhí)行時間。導致事務在訪問共享資源時發(fā)生沖突或死鎖的概率增高。隨著數據庫節(jié)點的增多，這種趨勢會越來越嚴重，從而成為系統(tǒng)在數據庫層面上水平擴展的枷鎖。

最終一致性

對于那些性能要求很高，但對一致性要求不高的系統(tǒng)，往往不苛求系統(tǒng)的實時一致性，只要在允許的時間段內達到最終一致性即可，可采用事務補償的方式。與事務在執(zhí)行中發(fā)生錯誤后立即回滾的方式不同，事務補償是一種事后檢查補救的措施，一些常見的實現方法有：對數據進行對賬檢查，基于日志進行對比，定期同標準數據來源進行同步等等。事務補償還要結合業(yè)務系統(tǒng)來考慮。

2、跨節(jié)點關聯(lián)查詢 join 問題

切分之前，系統(tǒng)中很多列表和詳情頁所需的數據可以通過 sql join 來完成。而切分之后，數據可能分布在不同的節(jié)點上，此時 join 帶來的問題就比較麻煩了，考慮到性能，盡量避免使用 join 查詢。

解決這個問題的一些方法：

1) 全局表

全局表，也可看做是 "數據字典表"，就是系統(tǒng)中所有模塊都可能依賴的一些表，為了避免跨庫 join 查詢，可以將這類表在每個數據庫中都保存一份。這些數據通常很少會進行修改，所以也不擔心一致性的問題。

2) 字段冗余

一種典型的反范式設計，利用空間換時間，為了性能而避免 join 查詢。例如：訂單表保存 userId 時候，也將 userName 冗余保存一份，這樣查詢訂單詳情時就不需要再去查詢 "買家 user 表" 了。

但這種方法適用場景也有限，比較適用于依賴字段比較少的情況。而冗余字段的數據一致性也較難保證，就像上面訂單表的例子，買家修改了 userName 后，是否需要在歷史訂單中同步更新呢? 這也要結合實際業(yè)務場景進行考慮。

3) 數據組裝

在系統(tǒng)層面，分兩次查詢，第一次查詢的結果集中找出關聯(lián)數據 id，然后根據 id 發(fā)起第二次請求得到關聯(lián)數據。最后將獲得到的數據進行字段拼裝。

4)ER 分片

關系型數據庫中，如果可以先確定表之間的關聯(lián)關系，并將那些存在關聯(lián)關系的表記錄存放在同一個分片上，那么就能較好的避免跨分片 join 問題。在 1:1 或 1:n 的情況下，通常按照主表的 ID 主鍵切分。如下圖所示：

這樣一來，Data Node1 上面的 order 訂單表與 orderdetail 訂單詳情表就可以通過 orderId 進行局部的關聯(lián)查詢了，Data Node2 上也一樣。

3、跨節(jié)點分頁、排序、函數問題

跨節(jié)點多庫進行查詢時，會出現 limit 分頁、order by 排序等問題。分頁需要按照指定字段進行排序，當排序字段就是分片字段時，通過分片規(guī)則就比較容易定位到指定的分片; 當排序字段非分片字段時，就變得比較復雜了。需要先在不同的分片節(jié)點中將數據進行排序并返回，然后將不同分片返回的結果集進行匯總和再次排序，最終返回給用戶。如圖所示：

上圖中只是取第一頁的數據，對性能影響還不是很大。但是如果取得頁數很大，情況則變得復雜很多，因為各分片節(jié)點中的數據可能是隨機的，為了排序的準確性，需要將所有節(jié)點的前 N 頁數據都排序好做合并，最后再進行整體的排序，這樣的操作時很耗費 CPU 和內存資源的，所以頁數越大，系統(tǒng)的性能也會越差。

在使用 Max、Min、Sum、Count 之類的函數進行計算的時候，也需要先在每個分片上執(zhí)行相應的函數，然后將各個分片的結果集進行匯總和再次計算，最終將結果返回。如圖所示：

4、全局主鍵避重問題

在分庫分表環(huán)境中，由于表中數據同時存在不同數據庫中，主鍵值平時使用的自增長將無用武之地，某個分區(qū)數據庫自生成的 ID 無法保證全局唯一。因此需要單獨設計全局主鍵，以避免跨庫主鍵重復問題。有一些常見的主鍵生成策略：

1)UUID

UUID 標準形式包含 32 個 16 進制數字，分為 5 段，形式為 8-4-4-4-12 的 36 個字符，例如：550e8400-e29b-41d4-a716-446655440000

UUID 是主鍵是最簡單的方案，本地生成，性能高，沒有網絡耗時。但缺點也很明顯，由于 UUID 非常長，會占用大量的存儲空間; 另外，作為主鍵建立索引和基于索引進行查詢時都會存在性能問題，在 InnoDB 下，UUID 的無序性會引起數據位置頻繁變動，導致分頁。

2) 結合數據庫維護主鍵 ID 表

在數據庫中建立 sequence 表：

　stub 字段設置為唯一索引，同一 stub 值在 sequence 表中只有一條記錄，可以同時為多張表生成全局 ID。sequence 表的內容，如下所示：

使用 MyISAM 存儲引擎而不是 InnoDB，以獲取更高的性能。MyISAM 使用的是表級別的鎖，對表的讀寫是串行的，所以不用擔心在并發(fā)時兩次讀取同一個 ID 值。

當需要全局唯一的 64 位 ID 時，執(zhí)行：

REPLACE INTO sequence (stub) VALUES ('a');

SELECT LAST_INSERT_ID();

這兩條語句是 Connection 級別的，select last_insert_id() 必須與 replace into 在同一數據庫連接下才能得到剛剛插入的新 ID。

使用 replace into 代替 insert into 好處是避免了表行數過大，不需要另外定期清理。

此方案較為簡單，但缺點也明顯：存在單點問題，強依賴 DB，當 DB 異常時，整個系統(tǒng)都不可用。配置主從可以增加可用性，但當主庫掛了，主從切換時，數據一致性在特殊情況下難以保證。另外性能瓶頸限制在單臺 MySQL 的讀寫性能。

flickr 團隊使用的一種主鍵生成策略，與上面的 sequence 表方案類似，但更好的解決了單點和性能瓶頸的問題。

這一方案的整體思想是：建立 2 個以上的全局 ID 生成的服務器，每個服務器上只部署一個數據庫，每個庫有一張 sequence 表用于記錄當前全局 ID。表中 ID 增長的步長是庫的數量，起始值依次錯開，這樣能將 ID 的生成散列到各個數據庫上。如下圖所示：

由兩個數據庫服務器生成 ID，設置不同的 auto_increment 值。第一臺 sequence 的起始值為 1，每次步長增長 2，另一臺的 sequence 起始值為 2，每次步長增長也是 2。結果第一臺生成的 ID 都是奇數 (1, 3, 5, 7 ...)，第二臺生成的 ID 都是偶數 (2, 4, 6, 8 ...)。

這種方案將生成 ID 的壓力均勻分布在兩臺機器上。同時提供了系統(tǒng)容錯，第一臺出現了錯誤，可以自動切換到第二臺機器上獲取 ID。但有以下幾個缺點：系統(tǒng)添加機器，水平擴展時較復雜; 每次獲取 ID 都要讀寫一次 DB，DB 的壓力還是很大，只能靠堆機器來提升性能。

可以基于 flickr 的方案繼續(xù)優(yōu)化，使用批量的方式降低數據庫的寫壓力，每次獲取一段區(qū)間的 ID 號段，用完之后再去數據庫獲取，可以大大減輕數據庫的壓力。如下圖所示：

還是使用兩臺 DB 保證可用性，數據庫中只存儲當前的最大 ID。ID 生成服務每次批量拉取 6 個 ID，先將 max_id 修改為 5，當應用訪問 ID 生成服務時，就不需要訪問數據庫，從號段緩存中依次派發(fā) 0~5 的 ID。當這些 ID 發(fā)完后，再將 max_id 修改為 11，下次就能派發(fā) 6~11 的 ID。于是，數據庫的壓力降低為原來的 1/6。

3)Snowflake 分布式自增 ID 算法

Twitter 的 snowflake 算法解決了分布式系統(tǒng)生成全局 ID 的需求，生成 64 位的 Long 型數字，組成部分：

第一位未使用

接下來 41 位是毫秒級時間，41 位的長度可以表示 69 年的時間

5 位 datacenterId，5 位 workerId。10 位的長度最多支持部署 1024 個節(jié)點

最后 12 位是毫秒內的計數，12 位的計數順序號支持每個節(jié)點每毫秒產生 4096 個 ID 序列

這樣的好處是：毫秒數在高位，生成的 ID 整體上按時間趨勢遞增; 不依賴第三方系統(tǒng)，穩(wěn)定性和效率較高，理論上 QPS 約為 409.6w/s(1000*2^12)，并且整個分布式系統(tǒng)內不會產生 ID 碰撞; 可根據自身業(yè)務靈活分配 bit 位。

不足就在于：強依賴機器時鐘，如果時鐘回撥，則可能導致生成 ID 重復。

綜上結合數據庫和 snowflake 的唯一 ID 方案，可以參考業(yè)界較為成熟的解法：Leaf——美團點評分布式 ID 生成系統(tǒng)，并考慮到了高可用、容災、分布式下時鐘等問題。

5、數據遷移、擴容問題

當業(yè)務高速發(fā)展，面臨性能和存儲的瓶頸時，才會考慮分片設計，此時就不可避免的需要考慮歷史數據遷移的問題。一般做法是先讀出歷史數據，然后按指定的分片規(guī)則再將數據寫入到各個分片節(jié)點中。此外還需要根據當前的數據量和 QPS，以及業(yè)務發(fā)展的速度，進行容量規(guī)劃，推算出大概需要多少分片 (一般建議單個分片上的單表數據量不超過 1000W)

如果采用數值范圍分片，只需要添加節(jié)點就可以進行擴容了，不需要對分片數據遷移。如果采用的是數值取模分片，則考慮后期的擴容問題就相對比較麻煩。

三. 什么時候考慮切分

下面講述一下什么時候需要考慮做數據切分。

1、能不切分盡量不要切分

并不是所有表都需要進行切分，主要還是看數據的增長速度。切分后會在某種程度上提升業(yè)務的復雜度，數據庫除了承載數據的存儲和查詢外，協(xié)助業(yè)務更好的實現需求也是其重要工作之一。

不到萬不得已不用輕易使用分庫分表這個大招，避免 "過度設計" 和 "過早優(yōu)化"。分庫分表之前，不要為分而分，先盡力去做力所能及的事情，例如：升級硬件、升級網絡、讀寫分離、索引優(yōu)化等等。當數據量達到單表的瓶頸時候，再考慮分庫分表。

2、數據量過大，正常運維影響業(yè)務訪問

這里說的運維，指：

1) 對數據庫備份，如果單表太大，備份時需要大量的磁盤 IO 和網絡 IO。例如 1T 的數據，網絡傳輸占 50MB 時候，需要 20000 秒才能傳輸完畢，整個過程的風險都是比較高的

2) 對一個很大的表進行 DDL 修改時，MySQL 會鎖住全表，這個時間會很長，這段時間業(yè)務不能訪問此表，影響很大。如果使用 pt-online-schema-change，使用過程中會創(chuàng)建觸發(fā)器和影子表，也需要很長的時間。在此操作過程中，都算為風險時間。將數據表拆分，總量減少，有助于降低這個風險。

3) 大表會經常訪問與更新，就更有可能出現鎖等待。將數據切分，用空間換時間，變相降低訪問壓力

3、隨著業(yè)務發(fā)展，需要對某些字段垂直拆分

舉個例子，假如項目一開始設計的用戶表如下：

id bigint #用戶的 ID

name varchar# 用戶的名字

last_login_timedatetime #最近登錄時間

personal_infotext #私人信息

..... #其他信息字段

在項目初始階段，這種設計是滿足簡單的業(yè)務需求的，也方便快速迭代開發(fā)。而當業(yè)務快速發(fā)展時，用戶量從 10w 激增到 10 億，用戶非常的活躍，每次登錄會更新 last_login_name 字段，使得 user 表被不斷 update，壓力很大。而其他字段：id, name, personal_info 是不變的或很少更新的，此時在業(yè)務角度，就要將 last_login_time 拆分出去，新建一個 user_time 表。

personal_info 屬性是更新和查詢頻率較低的，并且 text 字段占據了太多的空間。這時候，就要對此垂直拆分出 user_ext 表了。

4、數據量快速增長

隨著業(yè)務的快速發(fā)展，單表中的數據量會持續(xù)增長，當性能接近瓶頸時，就需要考慮水平切分，做分庫分表了。此時一定要選擇合適的切分規(guī)則，提前預估好數據容量

5、安全性和可用性

雞蛋不要放在一個籃子里。在業(yè)務層面上垂直切分，將不相關的業(yè)務的數據庫分隔，因為每個業(yè)務的數據量、訪問量都不同，不能因為一個業(yè)務把數據庫搞掛而牽連到其他業(yè)務。利用水平切分，當一個數據庫出現問題時，不會影響到 100% 的用戶，每個庫只承擔業(yè)務的一部分數據，這樣整體的可用性就能提高。

四. 案例分析

1、用戶中心業(yè)務場景

用戶中心是一個非常常見的業(yè)務，主要提供用戶注冊、登錄、查詢 / 修改等功能，其核心表為：

User(uid, login_name, passwd, sex, age, nickname)

uid 為用戶 ID, 主鍵

login_name, passwd, sex, age, nickname, 用戶屬性

任何脫離業(yè)務的架構設計都是耍流氓，在進行分庫分表前，需要對業(yè)務場景需求進行梳理：

用戶側：前臺訪問，訪問量較大，需要保證高可用和高一致性。主要有兩類需求：

用戶登錄：通過 login_name/phone/email 查詢用戶信息，1% 請求屬于這種類型

用戶信息查詢：登錄之后，通過 uid 來查詢用戶信息，99% 請求屬這種類型

運營側：后臺訪問，支持運營需求，按照年齡、性別、登陸時間、注冊時間等進行分頁的查詢。是內部系統(tǒng)，訪問量較低，對可用性、一致性的要求不高。

2、水平切分方法

當數據量越來越大時，需要對數據庫進行水平切分，上文描述的切分方法有 "根據數值范圍" 和 "根據數值取模"。

"根據數值范圍"：以主鍵 uid 為劃分依據，按 uid 的范圍將數據水平切分到多個數據庫上。例如：user-db1 存儲 uid 范圍為 0~1000w 的數據，user-db2 存儲 uid 范圍為 1000w~2000wuid 數據。

優(yōu)點是：擴容簡單，如果容量不夠，只要增加新 db 即可。

不足是：請求量不均勻，一般新注冊的用戶活躍度會比較高，所以新的 user-db2 會比 user-db1 負載高，導致服務器利用率不平衡

"根據數值取模"：也是以主鍵 uid 為劃分依據，按 uid 取模的值將數據水平切分到多個數據庫上。例如：user-db1 存儲 uid 取模得 1 的數據，user-db2 存儲 uid 取模得 0 的 uid 數據。

優(yōu)點是：數據量和請求量分布均均勻

不足是：擴容麻煩，當容量不夠時，新增加 db，需要 rehash。需要考慮對數據進行平滑的遷移。

3、非 uid 的查詢方法

水平切分后，對于按 uid 查詢的需求能很好的滿足，可以直接路由到具體數據庫。而按非 uid 的查詢，例如 login_name，就不知道具體該訪問哪個庫了，此時需要遍歷所有庫，性能會降低很多。

對于用戶側，可以采用 "建立非 uid 屬性到 uid 的映射關系" 的方案; 對于運營側，可以采用 "前臺與后臺分離" 的方案。

3.1、建立非 uid 屬性到 uid 的映射關系

1) 映射關系

例如：login_name 不能直接定位到數據庫，可以建立 login_name→uid 的映射關系，用索引表或緩存來存儲。當訪問 login_name 時，先通過映射表查詢出 login_name 對應的 uid，再通過 uid 定位到具體的庫。

映射表只有兩列，可以承載很多數據，當數據量過大時，也可以對映射表再做水平切分。這類 kv 格式的索引結構，可以很好的使用 cache 來優(yōu)化查詢性能，而且映射關系不會頻繁變更，緩存命中率會很高。

2) 基因法

分庫基因：假如通過 uid 分庫，分為 8 個庫，采用 uid%8 的方式進行路由，此時是由 uid 的最后 3bit 來決定這行 User 數據具體落到哪個庫上，那么這 3bit 可以看為分庫基因。

上面的映射關系的方法需要額外存儲映射表，按非 uid 字段查詢時，還需要多一次數據庫或 cache 的訪問。如果想要消除多余的存儲和查詢，可以通過 f 函數取 login_name 的基因作為 uid 的分庫基因。生成 uid 時，參考上文所述的分布式唯一 ID 生成方案，再加上最后 3 位 bit 值 = f(login_name)。當查詢 login_name 時，只需計算 f(login_name)%8 的值，就可以定位到具體的庫。不過這樣需要提前做好容量規(guī)劃，預估未來幾年的數據量需要分多少庫，要預留一定 bit 的分庫基因。

3.2、前臺與后臺分離

對于用戶側，主要需求是以單行查詢?yōu)橹?，需要建?login_name/phone/email 到 uid 的映射關系，可以解決這些字段的查詢問題。

而對于運營側，很多批量分頁且條件多樣的查詢，這類查詢計算量大，返回數據量大，對數據庫的性能消耗較高。此時，如果和用戶側公用同一批服務或數據庫，可能因為后臺的少量請求，占用大量數據庫資源，而導致用戶側訪問性能降低或超時。

這類業(yè)務最好采用 "前臺與后臺分離" 的方案，運營側后臺業(yè)務抽取獨立的 service 和 db，解決和前臺業(yè)務系統(tǒng)的耦合。由于運營側對可用性、一致性的要求不高，可以不訪問實時庫，而是通過 binlog 異步同步數據到運營庫進行訪問。在數據量很大的情況下，還可以使用 ES 搜索引擎或 Hive 來滿足后臺復雜的查詢方式。

五. 支持分庫分表中間件

站在巨人的肩膀上能省力很多，目前分庫分表已經有一些較為成熟的開源解決方案：

sharding-jdbc(當當)

TSharding(蘑菇街)

Atlas(奇虎 360)

Cobar(阿里巴巴)

MyCAT(基于 Cobar)

Oceanus(58 同城)

Vitess(谷歌)