上一篇文章介紹了分庫分表的幾種形式和方法，也重點介紹了垂直分庫帶來的問題和解決方案。 在這篇文章中，我們將討論一些數(shù)據(jù)庫和表水平分片的技術。

1、分片技術的起源。 關系數(shù)據(jù)庫本身更有可能成為系統(tǒng)性能瓶頸。 單機存儲容量、連接數(shù)、處理能力等都非常有限。 數(shù)據(jù)庫本身的“有狀態(tài)”特性使其不同于 Web 和應用程序服務器。 很容易擴展。 在互聯(lián)網(wǎng)行業(yè)海量數(shù)據(jù)、高并發(fā)訪問的考驗下，聰明的技術人員提出了分庫分表（有的地方也叫分片）技術。 同時，流行的分布式系統(tǒng)中間件（如等）都有自己的友好支持，其原理和思想都是相似的。 2、分布式全局唯一ID 在很多中小型項目中，我們經(jīng)常直接利用數(shù)據(jù)庫自??增功能來生成主鍵ID，確實比較簡單。 在分庫分表環(huán)境下，數(shù)據(jù)分布在不同的分片上，不能直接利用數(shù)據(jù)庫的自動增長特性生成數(shù)據(jù)，否則不同分片上的數(shù)據(jù)表主鍵會重復。 下面簡單介紹一下使用和理解的幾種ID生成算法。 1.（又名“雪花算法”）

2. UUID/GUID（一般應用程序和數(shù)據(jù)庫都支持）

3.（類似UUID方法）

4.（數(shù)據(jù)庫就是這樣生存的）

3. 常用分片規(guī)則和策略分片字段如何選擇

在開始分片之前，我們首先需要確定分片字段（也稱為“分片鍵”）。 在很多常見的例子和場景中，都會使用ID或者時間字段來進行拆分。 這并不是絕對的。 我的建議是結合實際業(yè)務，對系統(tǒng)中執(zhí)行的SQL語句進行統(tǒng)計分析，選擇表中最常用或者最重要的需要分片的字段進行分片。 場地。

常見的分片規(guī)則

常見的分片策略包括隨機分片和連續(xù)分片，如下圖所示：

當需要使用分片字段進行范圍搜索時，連續(xù)分片可以快速定位分片進行高效查詢，并且大多數(shù)情況下可以有效避免跨分片查詢問題。 如果后續(xù)想要擴展整個分片集群，只需要添加節(jié)點即可，不需要遷移其他分片的數(shù)據(jù)。 但連續(xù)分片也可能存在數(shù)據(jù)熱點的問題。 就像圖中按時間字段分片的例子一樣，部分節(jié)點可能面臨頻繁的查詢壓力，熱點數(shù)據(jù)節(jié)點成為瓶頸。 有些節(jié)點可能會存儲歷史數(shù)據(jù)，很少需要查詢。

隨機分片實際上并不是隨機的，而是遵循一定的規(guī)則。 通常，我們使用Hash模來進行分片分裂，因此有時也稱為離散分片。 隨機分片的數(shù)據(jù)相對均勻，不易出現(xiàn)熱點和并發(fā)訪問瓶頸。 但后期分片集群的擴容需要舊數(shù)據(jù)的遷移。 使用一致性Hash算法可以很大程度上避免這個問題，所以很多中間件分片集群都會使用一致性Hash算法。 離散分片也容易出現(xiàn)跨分片查詢的復雜問題。

數(shù)據(jù)遷移、容量規(guī)劃、擴容等問題

很少有項目在早期就開始考慮分片設計，通常是在業(yè)務快速發(fā)展、面臨性能和存儲瓶頸時提前準備。 因此，不可避免地要考慮歷史數(shù)據(jù)遷移的問題。 一般的做法是先通過程序讀取歷史數(shù)據(jù)，然后按照指定的分片規(guī)則將數(shù)據(jù)寫入到各個分片節(jié)點。

另外，我們需要根據(jù)當前的數(shù)據(jù)量和QPS進行容量規(guī)劃，并根據(jù)成本因素計算出大概需要的分片數(shù)量（一般建議單個分片上單表的數(shù)據(jù)量不宜超過超過1000W）。

如果采用隨機分片，需要考慮后期的擴容問題，會比較麻煩。 如果使用范圍分片，只需要添加節(jié)點即可自動擴容。

4. 跨分片技術問題 跨分片排序與分頁

一般來說，分頁時需要按照指定字段進行排序。 當排序字段為分片字段時，我們可以通過分片規(guī)則輕松定位到指定的分片。 但當排序字段為非分片字段時，情況就變得更加復雜。 為了保證最終結果的準確性，我們需要對不同分片節(jié)點中的數(shù)據(jù)進行排序返回，對不同分片返回的結果集進行匯總并重新排序，最后返回給用戶。 如下所示：

上圖描述的只是最簡單的情況（取第一頁數(shù)據(jù)），看起來影響不大。 但如果要取出第10頁的數(shù)據(jù)，情況就會變得復雜很多，如下圖所示：

有些讀者可能不太明白為什么不能像獲取第一頁數(shù)據(jù)那樣簡單處理（排序，取出前10條，然后合并排序）。 其實也不難理解，因為每個分片節(jié)點中的數(shù)據(jù)可能是隨機的。 為了排序的準確性，必須對所有分片節(jié)點的前N頁數(shù)據(jù)進行排序并合并，最后進行整體排序。 顯然，這樣的操作會消耗資源。 用戶翻頁越多，系統(tǒng)性能就越差。

跨分片功能處理

使用Max、Min、Sum、Count等函數(shù)進行統(tǒng)計和計算時intellij idea 數(shù)據(jù)庫關系圖，需要首先對每個分片數(shù)據(jù)源進行相應的函數(shù)處理，然后對每個結果集進行二次處理，最后返回處理結果。 如下所示：

跨分片連接

Join是關系數(shù)據(jù)庫中最常用的功能，但在分片集群中，Join也變得非常復雜。 應盡可能避免跨分片聯(lián)接查詢（這種場景比上面的跨分片分頁更復雜，并且對性能影響很大）。 通常有幾種方法可以避免：

全局表

全局表的概念之前在《垂直分庫》中提到過。 基本思想是一樣的，就是把一些類似于數(shù)據(jù)字典的、可能產(chǎn)生join查詢的表信息放到每個shard中，從而避免跨shard join。

ER 分片

在關系型數(shù)據(jù)庫中，表與表之間往往存在一些相關關系。 如果我們能夠先確定關聯(lián)，并將關聯(lián)的表記錄存儲在同一個分片上，就可以避免跨分片連接問題。 在一對多關系的情況下，我們通常選擇按照數(shù)據(jù)多的一方進行拆分。 如下所示：

這樣，Data Node1上的訂單表和訂單明細表就可以直接關聯(lián)起來進行本地連接查詢，Data Node2上也是如此。 這種基于ER分片的方式可以有效避免大多數(shù)業(yè)務場景下的跨分片連接問題。

內存計算

隨著Spark內存計算的興起，從理論上來說，很多跨數(shù)據(jù)源的操作問題似乎都可以得到解決。 數(shù)據(jù)可以扔到spark集群進行內存計算，最后返回計算結果。

5. 跨分片交易問題 跨分片交易也是分布式交易。 如果想了解分布式事務，就需要了解“XA接口”和“兩階段提交”。 值得一提的是，.5x和5.6x中xa支持存在問題，會導致主從數(shù)據(jù)不一致。 直到 5.7x 版本才修復。 Java應用程序可以使用框架來實現(xiàn)XA事務（J2EE中的JTA）。 有興趣的讀者可以自行參考《分布式事務一致性解決方案》，鏈接地址：

6、我們的系統(tǒng)真的需要分庫分表嗎？ 看完上面的內容intellij idea 數(shù)據(jù)庫關系圖，有的讀者不禁會想，我們的系統(tǒng)需要分庫分表嗎？

事實上，這一點并沒有明確的判斷標準，更多地依賴于實際業(yè)務情況和經(jīng)驗。 根據(jù)筆者的個人經(jīng)驗，一般MySQL單表1000萬左右的數(shù)據(jù)是沒有問題的（前提是應用系統(tǒng)和數(shù)據(jù)庫設計和優(yōu)化得當）。 當然，除了考慮當前的數(shù)據(jù)量和性能之外，作為架構師，我們還需要提前考慮系統(tǒng)半年到一年左右的業(yè)務增長情況，對QPS、連接數(shù)等做出合理的評估和規(guī)劃數(shù)據(jù)庫服務器的情況、容量等，并提前做好相應的準備。 如果單臺機器無法滿足要求，并且很難從其他方面進行優(yōu)化，那么就需要考慮分片。 這種情況下，可以先刪除數(shù)據(jù)庫中的自增ID，為分片和后續(xù)數(shù)據(jù)遷移做準備。

很多人認為“分庫分表”宜早不宜遲，因為擔心以后公司業(yè)務發(fā)展更快，系統(tǒng)變得更加復雜，系統(tǒng)改造和擴容會影響公司的業(yè)務。更難……這聽起來似乎有一定道理，但我的觀點卻恰恰相反。 對于關系型數(shù)據(jù)庫，我認為“不能分片就不分片”，除非系統(tǒng)確實需要，因為數(shù)據(jù)庫分片并不是低成本或者免費的。

這里筆者推薦一種更靠譜的過渡技術——“表分區(qū)”。 主流關系數(shù)據(jù)庫基本支持。 不同分區(qū)邏輯上仍然是一張表，但物理上是分開的，可以在一定程度上提高查詢性能，并且對應用程序透明，無需修改任何代碼。 作者曾經(jīng)負責優(yōu)化一個系統(tǒng)。 主業(yè)務表有8000W左右的數(shù)據(jù)。 考慮到成本問題，當時采用的是“表分區(qū)”。 效果明顯，系統(tǒng)運行非常穩(wěn)定。

7.總結 最后，很多讀者想了解社區(qū)是否有開源、免費的分片解決方案。 畢竟，站在巨人的肩膀上，可以省去很多力氣。 目前解決方案主要有兩類：

1、基于應用層的DDAL（分布式數(shù)據(jù)庫訪問層）

比較典型的有淘寶的半開源TDDL、當當?shù)拈_源-JDBC等，分布式數(shù)據(jù)訪問層不需要硬件投入。 技術能力較強的大公司通常會選擇自研或者參考開源框架進行二次開發(fā)和定制。 它通常對應用程序更具侵入性，并增加技術成本和復雜性。 通常只支持特定的編程語言平臺（多為Java平臺），或者只支持特定的數(shù)據(jù)庫和特定的數(shù)據(jù)訪問框架技術（一般支持MySQL數(shù)據(jù)庫、JDBC等框架技術）。

2、數(shù)據(jù)庫中間件，典型的有mycat（在阿里開源cobar的基礎上做了很多優(yōu)化和改進，是后起之秀，也支持很多新功能），基于Go語言實現(xiàn)，還有比較老的Atlas（開源360）等待。 這些中間件在互聯(lián)網(wǎng)公司中得到廣泛應用。 另外，MySQL 5.x企業(yè)版中官方提供的組件也聲稱支持分片技術，但國內很少有公司使用。

中間件也可以稱為“透明網(wǎng)關”，最著名的可能就是這個領域的鼻祖（由MySQL官方提供，僅限于實現(xiàn)“讀寫分離”）。 中間件一般實現(xiàn)特定數(shù)據(jù)庫的網(wǎng)絡通信協(xié)議，模擬真實的數(shù)據(jù)庫服務，屏蔽真實的后端。 應用程序通常直接連接到中間件。 執(zhí)行SQL操作時，中間件會根據(jù)預定義的分片規(guī)則對SQL語句進行解析和路由，并對結果集進行二次計算并最終返回。 引入數(shù)據(jù)庫中間件的技術成本較低，對應用幾乎無侵入，可以滿足大多數(shù)業(yè)務。 這就增加了額外的硬件投資和運維成本。 同時，中間件本身也存在性能瓶頸和單點故障。 需要保證中間件本身的高可用性和可擴展性。

總之，無論是使用分布式數(shù)據(jù)訪問層還是數(shù)據(jù)庫中間件，都會帶來一定的成本和復雜度，同時也會帶來一定的性能影響。 因此，讀者需要根據(jù)實際情況和業(yè)務發(fā)展需要仔細考慮和選擇。

近期值得閱讀的熱門文章：

1、

2、

3.

4.

5.

6.

7.

8、

9、

10.

關注公眾號，你想要的Java這里都有

如有侵權請聯(lián)系刪除！