MySQL要分表分庫怎麼進行資料切分?

MySQL要分表分庫怎麼進行資料切分?

導讀:關係型資料庫本身比較容易成為系統瓶頸,單機儲存容量、連線數、處理能力都有限。當單表的資料量達到1000W或100G以後,由於查詢維度較多,即使新增從庫、最佳化索引,做很多操作時效能仍下降嚴重。此時就要考慮對其進行切分了,切分的目的就在於減少資料庫的負擔,縮短查詢時間。

資料庫分散式核心內容無非就是資料切分(Sharding)以及切分後對資料的定位、整合。資料切分就是將資料分散儲存到多個數據庫中,使得單一資料庫中的資料量變小,透過擴充主機的數量緩解單一資料庫的效能問題,從而達到提升資料庫操作效能的目的。

資料切分根據其切分型別,可以分為兩種方式:垂直(縱向)切分和水平(橫向)切分。

1。垂直(縱向)切分

垂直切分常見有垂直分庫和垂直分表兩種。

1.1 垂直分庫

就是根據業務耦合性,將關聯度低的不同表儲存在不同的資料庫。做法與大系統拆分為多個小系統類似,按業務分類進行獨立劃分。與“微服務治理”的做法相似,每個微服務使用單獨的一個數據庫。如圖:

MySQL要分表分庫怎麼進行資料切分?

將不同模組的資料表分庫儲存。模組間不相互關聯查詢

如果有,就需要透過資料冗餘或者應層二次加工來解決。這種業務方法和資料結構最清晰。但若不能杜絕跨庫關聯查詢,宣告此路不同

1.2 垂直分表

是基於資料庫中的“列”進行,某個表字段較多,可以新建一張擴充套件表,將不經常用或欄位長度較大的欄位拆分出去到擴充套件表中。在欄位很多的情況下(例如一個大表有100多個欄位),透過“大表拆小表”,更便於開發與維護,也能避免跨頁問題,MySQL底層是透過資料頁儲存的,一條記錄佔用空間過大會導致跨頁,造成額外的效能開銷。另外資料庫以行為單位將資料載入到記憶體中,這樣表中欄位長度較短且訪問頻率較高,記憶體能載入更多的資料,命中率更高,減少了磁碟IO,從而提升了資料庫效能。

MySQL要分表分庫怎麼進行資料切分?

垂直切分的優點:

解決業務系統層面的耦合,業務清晰

與微服務的治理類似,也能對不同業務的資料進行分級管理、維護、監控、擴充套件等

高併發場景下,垂直切分一定程度的提升IO、資料庫連線數、單機硬體資源的瓶頸

缺點:

部分表無法join,只能透過介面聚合方式解決,提升了開發的複雜度

分散式事務處理複雜

依然存在單表資料量過大的問題(需要水平切分)

2。 水平(橫向)切分

當一個應用難以再細粒度的垂直切分,或切分後資料量行數巨大,存在單庫讀寫、儲存效能瓶頸,這時候就需要進行水平切分了。

水平切分分為庫內分表和分庫分表,是根據表內資料內在的邏輯關係,將同一個表按不同的條件分散到多個數據庫或多個表中,每個表中只包含一部分資料,從而使得單個表的資料量變小,達到分散式的效果。如圖所示:

MySQL要分表分庫怎麼進行資料切分?

相對縱向切分這一將表分類的做法,此法是按表內每個欄位的某個規則來將資料分散儲存於不同的資料庫(或不同的表),也就是按照數行來進行切分資料。

庫內分表只解決了單一表資料量過大的問題,但沒有將表分佈到不同機器的庫上,因此對於減輕MySQL資料庫的壓力來說,幫助不是很大,大家還是競爭同一個物理機的CPU、記憶體、網路IO,最好透過分庫分表來解決。

水平切分的優點:

不存在單庫資料量過大、高併發的效能瓶頸,提升系統穩定性和負載能力

應用端改造較小,不需要拆分業務模組

缺點:

跨分片的事務一致性難以保證

跨庫的join關聯查詢效能較差

資料多次擴充套件難度和維護量極大

水平切分後同一張表會出現在多個數據庫/表中,每個庫/表的內容不同。幾種典型的資料分片規則為:

2。1 根據數值範圍

按照時間區間或ID區間來切分。例如:按日期將不同月甚至是日的資料分散到不同的庫中;將userId為1~9999的記錄分到第一個庫,10000~20000的分到第二個庫,以此類推。某種意義上,某些系統中使用的“冷熱資料分離”,將一些使用較少的歷史資料遷移到其他庫中,業務功能上只提供熱點資料的查詢,也是類似的實踐。

這樣的優點在於:

單表大小可控

天然便於水平擴充套件,後期如果想對整個分片叢集擴容時,只需要新增節點即可,無需對其他分片的資料進行遷移

使用分片欄位進行範圍查詢時,連續分片可快速定位分片進行快速查詢,有效避免跨分片查詢的問題。

缺點:

熱點資料成為效能瓶頸。連續分片可能存在資料熱點,例如按時間欄位分片,有些分片儲存最近時間段內的資料,可能會被頻繁的讀寫,而有些分片儲存的歷史資料,則很少被查詢

MySQL要分表分庫怎麼進行資料切分?

2。2 根據數值取模

一般採用hash取模mod的切分方式,例如:將 Customer 表根據 cusno 欄位切分到4個庫中,餘數為0的放到第一個庫,餘數為1的放到第二個庫,以此類推。這樣同一個使用者的資料會分散到同一個庫中,如果查詢條件帶有cusno欄位,則可明確定位到相應庫去查詢。

優點:

資料分片相對比較均勻,不容易出現熱點和併發訪問的瓶頸

缺點:

後期分片叢集擴容時,需要遷移舊的資料(使用一致性hash演算法能較好的避免這個問題)

容易面臨跨分片查詢的複雜問題。比如上例中,如果頻繁用到的查詢條件中不帶cusno時,將會導致無法定位資料庫,從而需要同時向4個庫發起查詢,再在記憶體中合併資料,取最小集返回給應用,分庫反而成為拖累。

MySQL要分表分庫怎麼進行資料切分?

往期推薦

技術人具備“結構化思維”意味著什麼?

Gradle 比 Maven 好為什麼用的人少?

Kafka 提供哪些日誌清理策略?

為什麼ConcurrentHashMap的讀操作不需要加鎖?

Kafka 是怎麼儲存的?為什麼速度那麼快?

分享、點贊、在看

,給個

3連擊

唄!

TAG: 切分分片資料庫資料查詢