背景

分庫分表的產(chǎn)生背景主要源于大規(guī)?；ヂ?lián)網(wǎng)應(yīng)用的需求。隨著互聯(lián)網(wǎng)應(yīng)用的不斷發(fā)展，數(shù)據(jù)量和訪問量不斷增加，單一的數(shù)據(jù)庫往往無法滿足應(yīng)用的需求。傳統(tǒng)的垂直擴(kuò)展方式（增加更多的硬件資源）存在成本高、擴(kuò)展能力受限等問題，因此水平擴(kuò)展方式逐漸成為了主流。

同時，互聯(lián)網(wǎng)應(yīng)用的訪問模式也日益復(fù)雜。傳統(tǒng)的主從復(fù)制架構(gòu)難以滿足高并發(fā)、高可用、高擴(kuò)展等需求。而分庫分表可以通過將數(shù)據(jù)分散到多個數(shù)據(jù)庫中，并通過一定的策略將請求路由到合適的數(shù)據(jù)庫上，從而提高系統(tǒng)的性能和可用性。

因此，分庫分表成為了互聯(lián)網(wǎng)應(yīng)用中常用的數(shù)據(jù)庫擴(kuò)展方案之一。

什么是分庫分表

分庫分表是一種數(shù)據(jù)庫拆分技術(shù)，旨在通過將數(shù)據(jù)分散存儲在多個數(shù)據(jù)庫中，從而提高數(shù)據(jù)庫的性能和擴(kuò)展性。

分庫：一個大型數(shù)據(jù)庫被分成多個較小的數(shù)據(jù)庫，每個數(shù)據(jù)庫被稱為“分庫”。

分表：每個分庫又被進(jìn)一步分成多個表，每個表被稱為“分表”。

這種拆分可以在多個物理服務(wù)器上進(jìn)行，也可以在同一臺服務(wù)器的不同實例上進(jìn)行。

分庫分表的進(jìn)化

現(xiàn)在我們詳細(xì)說一下從單庫的進(jìn)化過程和好處。

最開始單數(shù)據(jù)庫，但是隨著業(yè)務(wù)量的提升，整體QPS不斷增大。假設(shè)這時候的單機(jī)硬件資源無法再提高，那我們就可以考慮增加從庫，將讀壓力轉(zhuǎn)移到從庫上。

但是隨著業(yè)務(wù)進(jìn)一步增長，主庫的寫壓力也越來越大，這時候會出現(xiàn)兩種情況：單表數(shù)據(jù)量過多，大表查詢速度變慢；或者總體的IOPS壓力已經(jīng)很大。

對于單表查詢壓力過大的問題，我們可以判斷查詢的數(shù)據(jù)是否可以按照創(chuàng)建時間區(qū)分為冷熱數(shù)據(jù)，如果可以優(yōu)先考慮分區(qū)表。如果查詢場景復(fù)雜我們可以考慮拆表，即使是在同一個數(shù)據(jù)庫中，拆表也可以有效降低索引層級，加快查詢速度。但是如果是IOPS壓力大，則無法很好的緩解這個問題，證明單機(jī)性能已經(jīng)到了瓶頸需要進(jìn)行分庫。

表分區(qū)（Table partitioning）和分區(qū)表（Partitioned table）是兩個相關(guān)但不同的概念。

表分區(qū)是指將一個大表（Table）劃分成更小的、可管理的部分，這些部分被稱為分區(qū)（Partition）。每個分區(qū)都包含表的一部分?jǐn)?shù)據(jù)，可以根據(jù)不同的分區(qū)策略進(jìn)行劃分，例如按時間、按地理位置等。

分區(qū)表是指已經(jīng)進(jìn)行了分區(qū)的表。在分區(qū)表中，每個分區(qū)都被視為一個獨(dú)立的表，可以對每個分區(qū)進(jìn)行單獨(dú)的操作，例如查詢、添加、刪除等。分區(qū)表的分區(qū)結(jié)構(gòu)使得數(shù)據(jù)訪問更加高效，可以只查詢或操作特定的分區(qū)，而不需要掃描整個表。

因此，表分區(qū)和分區(qū)表的區(qū)別在于，表分區(qū)是一種數(shù)據(jù)管理技術(shù)，用于將大表劃分成更小的、可管理的部分，而分區(qū)表是指已經(jīng)進(jìn)行了分區(qū)的表，可以根據(jù)分區(qū)結(jié)構(gòu)進(jìn)行更加高效的數(shù)據(jù)訪問和操作。

為什么一般不使用分區(qū)表？

1）分區(qū)表如果查詢條件沒有分區(qū)鍵，很容易出現(xiàn)全表鎖 2）一旦數(shù)據(jù)量并發(fā)量上來，如果在分區(qū)表實施關(guān)聯(lián)，就是一個災(zāi)難 3）自己分庫分表，行為更可控

一旦可以拆庫，那復(fù)雜性就會大大提升。之前即使是分表至少寫數(shù)據(jù)可以在一個數(shù)據(jù)庫中進(jìn)行，有本地事務(wù)保證數(shù)據(jù)的一致性。但是分成多個數(shù)據(jù)庫之后，就失去了這種保證。并且可能因為不知道數(shù)據(jù)在哪些分庫上，在查詢數(shù)據(jù)的時候也有可能會造成訪問多個數(shù)據(jù)庫節(jié)點，這就需要我們采用合理的數(shù)據(jù)分配方式、

如果分庫逐漸產(chǎn)生了性能問題，我們可以進(jìn)一步拆表，或者繼續(xù)拆庫。這就需要我們的數(shù)據(jù)分片方案具有良好的擴(kuò)展性，為未來的數(shù)據(jù)量增長提供預(yù)方案。當(dāng)然，我們并不能無限制的去拆庫，畢竟存儲資源是有限的。

上面的演進(jìn)思路主要是從性能上來考慮。其實我們還容易忽略一個問題就是可用性上。機(jī)器總是有可能發(fā)生意外的，尤其現(xiàn)在我們都采用云服務(wù)器，我們的數(shù)據(jù)安全不能依賴于服務(wù)商。

除了傳統(tǒng)的部署架構(gòu)層面提升可用性，比如主從結(jié)構(gòu)、主主結(jié)構(gòu)，我們還可以從數(shù)據(jù)的拆分上來考慮，畢竟雞蛋不要放在一個籃子里。

如果數(shù)據(jù)拆成了4份，單個數(shù)據(jù)庫發(fā)生故障，影響范圍就是25%，如果沒有進(jìn)行分庫那就是100%不可用。、

總的來說，分庫分表大大提升了數(shù)據(jù)庫的性能以及可用性。

準(zhǔn)備階段

判斷是否需要分庫分表

其實在上一段關(guān)于分庫分表的進(jìn)化歷程，已經(jīng)講述了關(guān)于分庫分表方案的選擇思路。

一般來說，在數(shù)據(jù)庫層我們至少都采用了主從的高可用架構(gòu)，分區(qū)表又不常使用，所以這里更多考慮是采用分庫還是分表，這需要根據(jù)我們當(dāng)前系統(tǒng)的具體情況來做選擇。

場景方案單表數(shù)據(jù)量過大，總體QPS不高分表單庫 IOPS 過高、QPS過高、數(shù)據(jù)庫連接數(shù)不夠用分庫總體數(shù)據(jù)量過高、連接數(shù)不足分庫分表

確定分片方案

在我們確定了是選擇分庫還是分表之后就需要對具體的分片規(guī)模做選擇，分多少庫多少表，這直接關(guān)系到我們的資源情況以及數(shù)據(jù)切分方案。

分表數(shù)量

如果選擇分表方案，需要確定要分多少表，這需要根據(jù)我們的數(shù)據(jù)的增長速度、業(yè)務(wù)目標(biāo)以及設(shè)計使用年限來做規(guī)劃。

我們這里以訂單系統(tǒng)作為業(yè)務(wù)背景，假設(shè)我們系統(tǒng)初始情況下單日有1w訂單量，但是按照現(xiàn)有的業(yè)務(wù)發(fā)展速度，計劃到年底增加到單日10w訂單，系統(tǒng)設(shè)計目標(biāo)是5年，那么我們就需要按照10w來計算。

1. 估算數(shù)據(jù)量：10w\*365\*5 = 18250w 5年后我們將擁有18250w數(shù)據(jù)，假設(shè)單表500w數(shù)據(jù)。

2. 計算分表數(shù)：18250/500=36.5考慮到未來業(yè)務(wù)的增長，那我們就按照 64 張表來拆分

分庫數(shù)量

如果選擇分庫，思路跟分表有一些不同，除了考慮數(shù)據(jù)量的拆分，我們還需要考慮到一些高并發(fā)場景，比如搞一些營銷活動或者遇到節(jié)日。這種情況下業(yè)務(wù)的QPS會大量增加，我們需要根據(jù)高峰QPS估算業(yè)務(wù)資源配置情況，適當(dāng)增加資源。

比如日常峰值 300QPS，但是節(jié)日高峰時候會達(dá)到20倍也就是6k，如果每個連接的平均查詢耗時是0.2秒，則每個數(shù)據(jù)庫連接的最大并發(fā)數(shù)是5，則平均連接數(shù)為6000/5 = 1200。如果單個數(shù)據(jù)庫最大連接數(shù)是500，那么我們需要至1200/500=2.4，所以取近似 4個數(shù)據(jù)庫。

對于數(shù)據(jù)庫最大連接數(shù)的配置，我們需要根據(jù)庫服務(wù)器的硬件配置以及結(jié)合業(yè)務(wù)壓測來確認(rèn)。

切分維度選擇

一般來說，我們對于數(shù)據(jù)的切分有兩個維度，水平切分和垂直切分，當(dāng)然他們也可以結(jié)合使用

水平切分

水平切分（Horizontal Sharding）是將一個大型數(shù)據(jù)庫表按照某個規(guī)則（如數(shù)據(jù)范圍、哈希值、輪詢等）分成多個較小的表，分布在多個數(shù)據(jù)庫節(jié)點上。例如，將一個用戶表按照用戶ID分成多個小表，每個小表存儲一部分用戶數(shù)據(jù)，分布在不同的數(shù)據(jù)庫節(jié)點上。水平切分可以解決單個數(shù)據(jù)庫性能瓶頸和單點故障問題，提高數(shù)據(jù)庫的可擴(kuò)展性和可用性。

簡單來說，水平切分就是按照一定規(guī)則把一個表不同行拆分到不同表中。

垂直切分

垂直切分（Vertical Sharding）是將一個大型數(shù)據(jù)庫表按照業(yè)務(wù)功能（如用戶信息、訂單信息、商品信息等）拆分成多個表，每個表存儲不同的字段和數(shù)據(jù)。例如，將一個包含用戶信息、訂單信息和商品信息的大型表拆分成三個小表，每個小表只存儲對應(yīng)的信息。垂直切分可以將數(shù)據(jù)庫的讀寫壓力分散到不同的表和數(shù)據(jù)庫節(jié)點上，提高數(shù)據(jù)庫的性能和可維護(hù)性。

除了數(shù)據(jù)量角度，也可以從頻繁寫入的角度來看。如果一張表有20個字段，其中只有5個字段需要頻繁修改，那么可以考慮把這5個字段拆分到子表。避免在修改這5個數(shù)據(jù)時，影響到其余15個字段的查詢行鎖定。

簡單來說，垂直切分就是把一張表不同字段拆分到不同的表里。

Sharding 方案

除了在同一個數(shù)據(jù)庫去垂直拆分表，其他方案都逃不過一個問題：選擇哪個列作為拆分表的依據(jù)？sharding 的算法是什么？

選擇拆分的列

選擇一個合適的列作為分庫分表的依據(jù)非常重要，我們可以稱其為 Sharding Key。他的選擇直接影響到了我們的數(shù)據(jù)分布均勻程度以及以后的查詢效率。

通常來說互聯(lián)網(wǎng)C端應(yīng)用都是直接面對客戶，用戶在App端的操作很多都是在查詢自己的數(shù)據(jù)，所以所以比如用戶系統(tǒng)的表做切分，我們可以選擇用戶id這個列來做 Sharding Key。并且用戶id通常來說都是有序自增的，如果用戶量很大的情況下，在不同分片中的數(shù)據(jù)分布也會較為均勻。

如果是B端系統(tǒng)有些場景可能會不一樣些。比如現(xiàn)在有一個ERP系統(tǒng)，每天會產(chǎn)生大量的計劃單數(shù)據(jù)，但是這些數(shù)據(jù)主要是給工廠和運(yùn)營人員去使用的，并沒有那么高的并發(fā)量。而且這種數(shù)據(jù)有個特點，只關(guān)注近期的數(shù)據(jù)，這種情況下我們就可以按照創(chuàng)建時間去分片。

不同維度數(shù)據(jù)怎么查詢

分庫分表一個狠大的弊端就是查詢數(shù)據(jù)非常不方便。

如果是訂單系統(tǒng)可能就會更復(fù)雜一些，當(dāng)我們同樣使用用戶id做切分后，但是如果需要按照訂單id查詢呢？那就不知道這個訂單屬于哪個用戶，該從哪個分片去查詢，那就只能把每個分片都去查詢一遍，可向這個效率有多低。

既然這樣，我不用用戶id作為sharding key了，換成訂單id可以吧。雖然解決了訂單id的查詢問題，但是現(xiàn)在只有用戶id又怎么查詢呢？這顯然是行不通的。

首先可以肯定一件事情，每一條訂單數(shù)據(jù)一定包含一個列就是用戶id，我們的問題在于知道訂單id卻不知道在哪個分片，那我們在訂單生成規(guī)則里附加一下對應(yīng)用戶的id信息不就可以了嘛。比如下面的訂單id生成規(guī)則：

6位日期+2位版本號+4位用戶id后四位+8位訂單號

總結(jié)一下：我們的解決思路是把其他維度數(shù)據(jù)的生成規(guī)則中帶有 Sharding Key的一部分，這樣就知道了分片信息。

但是如果條件不止一個呢？我還想按照商戶維度去查詢，希望看到每個商家售賣出的商品數(shù)據(jù)，或者年度的報表數(shù)據(jù)?；蛘甙凑瞻l(fā)貨的快遞號去查詢，快遞號都是快遞公司生成的，你總不能按照自己的規(guī)則去改寫把。

這種情況下，可以采用空間換時間的思維去解決。

• 可以把需要查詢的數(shù)據(jù)同時同步到一個按照商家id分片的讀庫里，專門用作查詢目的。

• 或者可以將數(shù)據(jù)同步給數(shù)倉，數(shù)據(jù)部門去處理這些信息，然后生成對應(yīng)的報表信息。

• 或者專門做一個快遞單號和訂單號的映射表，需要根據(jù)快遞號查詢可以先去這個映射表中找到對應(yīng)id，然后再找到對應(yīng)的分庫。

至于選擇什么分片算法，我們下篇繼續(xù)，請繼續(xù)關(guān)注！