北冥有 Data,其名為鯤,鯤之大,一個 MySQL 放不下!

張哥說技術發表於2022-12-06

千萬量級的資料,用 MySQL 要怎麼存?

初學者在看到這個問題的時候,可能首先想到的是 MySQL 一張表到底能存放多少條資料?

根據 MySQL 官方文件的介紹,MySQL 理論上限是 (232)2 條資料,然而實際操作中,往往還受限於下面兩條因素:

  1. myisam_data_pointer_size,MySQL 的 myisam_data_pointer_size 一般預設是 6,即 48 位,那麼對應的行數就是 248-1。
  2. 表的儲存大小 256TB

那有人會說,只要我的資料大小不超過上限,資料行數也不超過上限,是不是就沒有問題了?其實不盡然。

在實際專案中,一般沒有哪個專案真的觸發到 MySQL 資料的上限了,因為當資料量變大了之後,查詢速度會慢的嚇人,而一般這個時候,你的資料量離 MySQL 的理論上限還遠著呢!

傳統的企業應用一般資料量都不大,資料也都比較容易處理,但是在網際網路專案中,上千萬、上億的資料量並不鮮見。在這種時候,還要保證資料庫的操作效率,我們就不得不考慮資料庫的分庫分表了。

那麼接下來就和大家簡單聊一聊資料庫分庫分表的問題。

資料庫切分

看這個名字就知道,就是把一個資料庫切分成 N 多個資料庫,然後存放在不同的資料庫例項上面,這樣做有兩個好處:

  1. 降低單臺資料庫例項的負載
  2. 可以方便的實現對資料庫的擴容

一般來說,資料庫的切分有兩種不同的切分規則:

  1. 水平切分
  2. 垂直切分

接下來我們就對這兩種不同的切分規則分別進行介紹。

水平切分

先來一張簡單的示意圖,大家感受一下什麼是水平切分:

北冥有 Data,其名為鯤,鯤之大,一個 MySQL 放不下!

假設我的 DB 中有 table-1、table-2 以及 table-3 三張表,水平切分就是拿著我的絕世好劍,對準黑色的線條,砍一劍或者砍 N 劍!

砍完之後,將砍掉的部分放到另外一個資料庫例項中,變成下面這樣:

北冥有 Data,其名為鯤,鯤之大,一個 MySQL 放不下!
北冥有 Data,其名為鯤,鯤之大,一個 MySQL 放不下!

這樣,原本放在一個 DB 中的 table 現在放在兩個 DB 中了,觀察之後我們發現:

  1. 兩個 DB 中表的個數都是完整的,就是原來 DB 中有幾張表,現在還是幾張。
  2. 每張表中的資料是不完整的,資料被拆分到了不同的 DB 中去了。

這就是資料庫的水平切分,也可以理解為按照資料行進行切分,即按照表中某個欄位的某種規則來將表資料分散到多個庫之中,每個表中包含一部分資料。

這裡的某種規則都包含哪些規則呢?這就涉及到資料庫的分片規則問題了,這個鬆哥在後面的文章中也會和大家一一展開詳述。這裡先簡單說幾個常見的分片規則:

  1. 按照日期劃分:不容日期的資料存放到不同的資料庫中。
  2. 對 ID 取模:對錶中的 ID 欄位進行取模運算,根據取模結果將資料儲存到不同的例項中。
  3. 使用一致性雜湊演算法進行切分。

詳細的用法,將在後面的文章中和大家仔細說。

垂直切分

先來一張簡單的示意圖,大家感受一下垂直切分:

北冥有 Data,其名為鯤,鯤之大,一個 MySQL 放不下!

所謂的垂直切分就是拿著我的屠龍刀,對準了黑色的線條砍。砍完之後,將不同的表放到不同的資料庫例項中去,變成下面這個樣子:

北冥有 Data,其名為鯤,鯤之大,一個 MySQL 放不下!
北冥有 Data,其名為鯤,鯤之大,一個 MySQL 放不下!
北冥有 Data,其名為鯤,鯤之大,一個 MySQL 放不下!

這個時候我們發現如下幾個特點:

  1. 每一個資料庫例項中的表的數量都是不完整的。
  2. 每一個資料庫例項中表的資料是完整的。

這就是垂直切分。一般來說,垂直切分我們可以按照業務來劃分,不同業務的表放到不同的資料庫例項中。

老實說,在實際專案中,資料庫垂直切分並不是一件容易的事,因為表之間往往存在著複雜的跨庫 JOIN 問題,那麼這個時候如何取捨,就要考驗架構師的水平了!

優缺點分析

通過上面的介紹,相信大家對於水平切分和垂直切分已經有所瞭解,優缺點其實也很明顯了,鬆哥再來和大家總結一下。

水平切分

  • 優點
  1. 水平切分最大的優勢在於資料庫的擴充套件性好,提前選好切分規則,資料庫後期可以非常方便的進行擴容。
  2. 有效提高了資料庫穩定性和系統的負載能力。拆分規則抽象好, join 操作基本可以資料庫做。
  • 缺點
  1. 水平切分後,分片事務一致性不容易解決。
  2. 拆分規則不易抽象,對架構師水平要求很高。
  3. 跨庫 join 效能較差。

垂直切分

  • 優點
  1. 一般按照業務拆分,拆分後業務清晰,可以結合微服務一起食用。
  2. 系統之間整合或擴充套件相對要容易很多。
  3. 資料維護相對簡單。
  • 缺點
  1. 最大的問題在於存在單庫效能瓶頸,資料表擴充套件不易。
  2. 跨庫 join 不易。
  3. 事務處理複雜。

結語

雖然 MySQL 中資料儲存的理論上限比較高,但是在實際開發中我們不會等到資料存不下的時候才去考慮分庫分表問題,因為在那之前,你就會明顯的感覺到資料庫的各項效能在下降,就要開始考慮分庫分表了。

好了,今天主要是向大家介紹一點概念性的東西,算是我們分散式資料庫中介軟體正式出場前的一點鋪墊。

參考資料:

  1. MySQL 官方文件

關注公眾號【江南一點雨】,專注於 Spring Boot+微服務以及前後端分離等全棧技術,定期視訊教程分享,關注後回覆 Java ,領取鬆哥為你精心準備的 Java 乾貨!

北冥有 Data,其名為鯤,鯤之大,一個 MySQL 放不下!

相關文章