千萬量級的數據,用 MySQL 要怎麼存?算法
初學者在看到這個問題的時候,可能首先想到的是 MySQL 一張表到底能存放多少條數據?數據庫
根據 MySQL 官方文檔的介紹,MySQL 理論上限是 (232)2 條數據,然而實際操做中,每每還受限於下面兩條因素:後端
那有人會說,只要個人數據大小不超過上限,數據行數也不超過上限,是否是就沒有問題了?其實不盡然。架構
在實際項目中,通常沒有哪一個項目真的觸發到 MySQL 數據的上限了,由於當數據量變大了以後,查詢速度會慢的嚇人,而通常這個時候,你的數據量離 MySQL 的理論上限還遠着呢!前後端分離
傳統的企業應用通常數據量都不大,數據也都比較容易處理,可是在互聯網項目中,上千萬、上億的數據量並不鮮見。在這種時候,還要保證數據庫的操做效率,咱們就不得不考慮數據庫的分庫分表了。分佈式
那麼接下來就和你們簡單聊一聊數據庫分庫分表的問題。微服務
看這個名字就知道,就是把一個數據庫切分紅 N 多個數據庫,而後存放在不一樣的數據庫實例上面,這樣作有兩個好處:性能
通常來講,數據庫的切分有兩種不一樣的切分規則:3d
接下來咱們就對這兩種不一樣的切分規則分別進行介紹。視頻
先來一張簡單的示意圖,你們感覺一下什麼是水平切分:
假設個人 DB 中有 table-一、table-2 以及 table-3 三張表,水平切分就是拿着個人絕世好劍,對準黑色的線條,砍一劍或者砍 N 劍!
砍完以後,將砍掉的部分放到另一個數據庫實例中,變成下面這樣:
這樣,本來放在一個 DB 中的 table 如今放在兩個 DB 中了,觀察以後咱們發現:
這就是數據庫的水平切分,也能夠理解爲按照數據行進行切分,即按照表中某個字段的某種規則來將表數據分散到多個庫之中,每一個表中包含一部分數據。
這裏的某種規則都包含哪些規則呢?這就涉及到數據庫的分片規則問題了,這個鬆哥在後面的文章中也會和你們一一展開詳述。這裏先簡單說幾個常見的分片規則:
詳細的用法,將在後面的文章中和你們仔細說。
先來一張簡單的示意圖,你們感覺一下垂直切分:
所謂的垂直切分就是拿着個人屠龍刀,對準了黑色的線條砍。砍完以後,將不一樣的表放到不一樣的數據庫實例中去,變成下面這個樣子:
這個時候咱們發現以下幾個特色:
這就是垂直切分。通常來講,垂直切分咱們能夠按照業務來劃分,不一樣業務的表放到不一樣的數據庫實例中。
老實說,在實際項目中,數據庫垂直切分並非一件容易的事,由於表之間每每存在着複雜的跨庫 JOIN 問題,那麼這個時候如何取捨,就要考驗架構師的水平了!
經過上面的介紹,相信你們對於水平切分和垂直切分已經有所瞭解,優缺點其實也很明顯了,鬆哥再來和你們總結一下。
雖然 MySQL 中數據存儲的理論上限比較高,可是在實際開發中咱們不會等到數據存不下的時候纔去考慮分庫分表問題,由於在那以前,你就會明顯的感受到數據庫的各項性能在降低,就要開始考慮分庫分表了。
好了,今天主要是向你們介紹一點概念性的東西,算是咱們分佈式數據庫中間件正式出場前的一點鋪墊。
參考資料:
關注公衆號【江南一點雨】,專一於 Spring Boot+微服務以及先後端分離等全棧技術,按期視頻教程分享,關注後回覆 Java ,領取鬆哥爲你精心準備的 Java 乾貨!