點擊上方藍色字體，選擇“標星公眾號”

優(yōu)質文章，第一時間送達

  作者 |  aduner

來源 |  urlify.cn/uUZBrm

前言

現代業(yè)務越來越復雜，數據量也越來越大，關系型數據庫本身就比較容易形成系統(tǒng)瓶頸，單機存儲容量，連接數，處理能力都有限。

當單表的數據量達到一定量級以后，比如1000萬，由于查詢維度較多，即使添加從庫，優(yōu)化索引，做很多操作時性能還是下降嚴重。

這個時候要如何提高數據的性能呢？

有人說，可以通過提升服務器硬件能力來提高數據處理能力，比如換更快的硬盤，換更強的CPU。

這種方案成本是很高的，并且瓶頸有時候往往不在硬件上，而在數據庫本身。

基于這種現狀，分表/分庫就出現了！

什么是分別分庫

分表分庫是兩種操作，一種是分表，一種是分庫。

但是他們的中心思想都是將數據分散，使得單一數據庫/表的數據量變小來緩解單一數據庫的性能問題，從而達到提升數據庫性能的目的。

例如，將某業(yè)務的數據庫分為若干個獨立的數據庫，并且對于大表也拆分為若干小表，這樣就很大程度上降低了并發(fā)數據查詢時的數據沖突。

分表

垂直分表

定義：將一個表按照字段分為多表，每個表里面都存儲其中一部分字段。

我們以商品表來舉例子：

商品信息中，一般包括多條字段，如商品名、價格、簡介……

而其中商品名和價格可能是最重要的，而簡介就相對沒有那么重要。

對比兩者：

• 商品名和價格：字段很小，請求很頻繁。

• 簡介：字段很大，一般只有詳情頁才需要它。

大字段都如下幾個壞處：

• 由于數據量本身大，需要更長的讀取時間

• 跨頁時，單頁內的數據行越多數據庫整體性能越好，而大字段占用空間大，單頁內存儲行數小，因此IO效率低

• 據庫以行為單位將數據加載到內存中，表中字段越短，內存能加載的數據越多，命中率更高，減少了磁盤IO，從而提升了數據庫性能。

因此簡介這種低頻數據，會拖累商品名和價格這種高頻數據，這個時候，我們就可以將簡介從表中拆分出來。

這樣做的好處是：

• 查看詳情的用戶與商品信息瀏覽互不影響，避免了IO爭搶并減少鎖表的幾率。

• 充分發(fā)揮高頻數據（商品名和價格）的操作效率，商品名和價格的操作的高效率不會被商品簡介的低效率所拖累。

水平分表

定義：同一個數據庫內，對數據行拆分，不影響表結構。

優(yōu)點：

• 優(yōu)化單一表數據量過大而產生的性能問題。

• 避免IO爭搶而減少鎖表的幾率。

分庫

雖然通過分表性能得到一定程度的提升，但是很多時候還無法達到預期效果。

因為數據庫始終限制在一臺服務器上，所以分表有如下幾個局限性：

• 磁盤空間可能不夠。

• 只解決了單一表數據量過大的問題。

• 每個表還是競爭同一個物理機的物理資源。

垂直分庫

定義：專庫專用，按照業(yè)務將表進行分類，分布在不同的數據庫中，每個庫可以放在不同的服務器上

例如，我們可以將購物車表、商品表、店鋪表、買家表分在不同的服務器中。

優(yōu)點：

• 解決業(yè)務層面的耦合，業(yè)務清晰

• 能對不同業(yè)務的數據進行分級管理、維護、監(jiān)控、擴展等

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

水平分庫

隨著業(yè)務的繼續(xù)擴大，垂直分庫也將在次面臨單表過大的情況。

而已經經過了垂直分庫，我們很難再進行進一步的垂直細分，這時候就要嘗試水平分庫了。

水平分庫和水平分表十分相似，應該說就是水平分表是水平分庫的一種延續(xù)。

定義：同一個表的數據按一定規(guī)則拆到不同的數據庫中，庫放在不同的服務器上。

優(yōu)點：

• 解決了單庫大數據，高并發(fā)的性能瓶頸

• 提高了系統(tǒng)的穩(wěn)定性及可用性

分庫分表的缺點

分頁/排序

在同一張表時，只需要用limit、order by便可輕松搞定。

跨節(jié)點多庫進行查詢時，分頁、排序，就變得很復雜。

• 先在不同的分片節(jié)點中將數據進行排序并返回

• 然后將不同分片返回的結果集進行匯總和再次排序

主鍵重復

分表分庫會讓平時經常使用的主鍵自增長形同虛設。生成的ID無法保證全局唯一。

因此我們需要單獨設計全局主鍵，以便面跨庫主鍵重復問題。

事務的一致性

因為分庫分表把數據分布在不同的庫、不同服務器，所以不可避免的帶來分布式事務問題。

當一個請求要先請求數據庫A，再請求數據庫B，這兩個屬于同一個事務，多個庫會導致分布式事務問題。

需要有一些措施來保證事務一致性的問題，這里不在展開，有興趣自行了解。

關聯查詢

分庫后，如果兩個表不在同一個數據庫，甚至不在同一臺服務器上，無法進行關聯查詢。

解決方案：

• 將原關聯查詢分為兩次查詢

• 第一個查詢的結果找出關聯數據id

• 根據id發(fā)起第二次請求得到關聯數據

• 最后將獲得的數據進行拼裝

總結

分庫分表的誕生是為了解決數據庫的性能瓶頸，雖然有很多好處，但相應的也有很多壞處。

但在業(yè)務量還不大的時候，我們其實應該首先考慮索引、緩存、讀寫分離等方案，盲目使用分表分庫技術，會導致業(yè)務變得臃腫，反而徒增煩惱。

粉絲福利：Java從入門到入土學習路線圖

??????

??長按上方微信二維碼 2 秒

感謝點贊支持下哈