首頁技術(shù)文章正文

Java培訓:分庫分表

更新時間:2022-08-25 來源:黑馬程序員 瀏覽量:

  1. 導讀


  各位小伙伴,在目前企業(yè)級開發(fā)中采用Mysql做為數(shù)據(jù)庫是一個主流選擇,而當數(shù)據(jù)量比較大的情況下,為了支撐項目的正??焖俚倪\行,我們不得不選擇對數(shù)據(jù)庫分庫分表操作,本章節(jié)就對數(shù)據(jù)庫的分表做一些方案的講解,包括如下:

  - 為什么要分庫分表

  - 分庫分表的具體方式

  - 分庫分表帶來的問題及解決方案有哪些

  2 .為什么分庫分表

   隨著平臺的業(yè)務發(fā)展,數(shù)據(jù)可能會越來越多,甚至達到億級。以MySQL為例,單庫數(shù)據(jù)量在5000萬以內(nèi)性能比較好,超過閾值后性能會隨著數(shù)據(jù)量的增大而明顯降低。單表的數(shù)據(jù)量超過1000w,性能也會下降嚴重。這就會導致查詢一次所花的時間變長,并發(fā)操作達到一定量時可能會卡死,甚至把系統(tǒng)給拖垮。

   我們是否可以通過提升服務器硬件能力來提高數(shù)據(jù)處理能力?能,但是這種方案很貴,并且提高硬件是有上限的。**那我們能不能把數(shù)據(jù)分散在不同的數(shù)據(jù)庫中,使得單一數(shù)據(jù)庫和表的數(shù)據(jù)量變小,從而達到提升數(shù)據(jù)庫操作性能的目的?** 可以,這就是數(shù)據(jù)庫分庫分表。

   分庫分表就是把較大的數(shù)據(jù)庫和數(shù)據(jù)表按照某種策略進行拆分。目的在于:降低每個庫、每張表的數(shù)據(jù)量,減小數(shù)據(jù)庫的負擔,提高數(shù)據(jù)庫的效率,縮短查詢時間。另外,因為分庫分表這種改造是可控的,底層還是基于RDBMS,因此整個數(shù)據(jù)庫的運維體系以及相關(guān)基礎設施都是可重用的。

  3. 分庫分表的方式

  3.1 垂直分表

   用戶在電商平臺流覽商品時,首先看到的是商品的基本信息,如果對該商品感興趣時才會繼續(xù)查看該商品的詳細描述。因此,商品基本信息的訪問頻次要高于商品詳細描述信息,商品基本信息的訪問效率要高于商品詳細描述信息(大字段)。 由于這兩種數(shù)據(jù)的特性不一樣,因此考慮將商品信息表拆分如下:

  

1661398933384_1.jpg

  這種拆分就叫垂直分表。垂直分表定義:將一個表的字段分散到多個表中,每個表存儲其中一部分字段。垂直分表帶來的提升是:

       1.減少IO爭搶,減少鎖表的幾率,查看商品詳情的與商品概述互不影響

  2. 充分發(fā)揮高頻數(shù)據(jù)的操作效率,對商品概述數(shù)據(jù)操作的高效率不會被操作商品詳情數(shù)據(jù)的低效率所拖累。

   一般來說,某業(yè)務實體中的各個數(shù)據(jù)項的訪問頻次是不一樣的,部分數(shù)據(jù)項可能是占用存儲空間比較大的BLOB或是TEXT,例如上例中的商品描述字段。所以,當數(shù)據(jù)量很大時,可以將表按字段拆分,將熱門字段、冷門字段分開放置在不同表中。垂直切分帶來的性能提升,主要集中在熱門數(shù)據(jù)的操作效率上,而且磁盤爭用情況減少。通常我們按以下原則進行垂直拆分:

  - 把不常用的字段單獨放在一張表

  - 把text,blob等大字段拆分出來單獨放在一張表

  - 經(jīng)常組合查詢的字段單獨放在一張表中

  3.2 垂直分庫

   通過垂直分表,數(shù)據(jù)庫性能得到了一定程度的提升,但是還沒有達到要求,并且磁盤空間也快不夠了,因為數(shù)據(jù)還是始終存放在一臺服務器。庫內(nèi)垂直分表只解決了單一表數(shù)據(jù)量過大的問題,但沒有將表分布到不同機器的庫上,因此對于減輕數(shù)據(jù)庫的壓力來說,作用有限,大家還是競爭同一個物理機的CPU、內(nèi)存、網(wǎng)絡IO、磁盤。

   以電商平臺為例,可以把原有的SELLER_DB(賣家?guī)?,拆分為PRODUCT_DB(商品庫)和STORE_DB(店鋪庫),并把這兩個庫分散到不同服務器上,如下圖所示:

  

1661398956441_2.jpg

  由于商品信息與商品描述業(yè)務耦合度較高,因此一起被存放在PRODUCT_DB(商品庫);而店鋪信息相對獨立,因此單獨被存放在STORE_DB(店鋪庫),這就叫垂直分庫。

   垂直分庫是指按照業(yè)務將表進行分類,分布到不同的數(shù)據(jù)庫上面,每個庫可以放在不同的服務器上,從而達到多個服務器共同分攤壓力的效果。垂直分庫帶來的提升是:

  - 解決業(yè)務層面的耦合,業(yè)務清晰

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

  - 高并發(fā)場景下,垂直分庫在一定程度上可以提升IO、數(shù)據(jù)庫連接數(shù)、單機硬件資源的性能

  3.3 水平分庫

   經(jīng)過**垂直分表和垂直分庫**后,數(shù)據(jù)庫性能問題就完全解決了?假設某電商平臺發(fā)展迅猛,PRODUCT_DB(商品庫)單庫存儲數(shù)據(jù)已經(jīng)超出預估。假設目前該平臺有8w店鋪,每個店鋪平均有150個不同規(guī)格的商品,再算上增長,那商品數(shù)量就會達到1500w+級別,并且PRODUCT_DB(商品庫)屬于訪問非常頻繁的資源,性能瓶頸再次出現(xiàn)。

   能再次垂直分庫嗎?從業(yè)務角度分析,目前已經(jīng)無法再次垂直拆分。于是我們又想了一個辦法,判斷商品ID是奇數(shù)還是偶數(shù),然后把商品信息分別存放到兩個數(shù)據(jù)庫中。也就是說,要操作某條數(shù)據(jù),先分析這條數(shù)據(jù)的商品ID,如果商品ID為奇數(shù),將此操作映射至RRODUCT_DB1(商品庫1);如果商品ID為偶數(shù),將操作映射至RRODUCT_DB2(商品庫2),這就叫**水平分庫**。

  

1661398996116_3.jpg

   水平分庫是把同一個表的數(shù)據(jù)按一定規(guī)則拆分到不同的數(shù)據(jù)庫中,每個庫可以放在不同的服務器上。它帶來的提升是:

  - 解決了單庫大數(shù)據(jù),高并發(fā)的性能瓶頸。

  - 按照合理拆分規(guī)則拆分,join操作基本避免跨庫。

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

   當一個應用難以再細粒度的垂直切分,或切分后數(shù)據(jù)量行數(shù)仍然巨大,存在單庫讀寫、存儲性能瓶頸,這時候就需要進行**水平分庫**了,經(jīng)過水平切分的優(yōu)化,往往能解決單庫存儲量及性能瓶頸。但由于同一個表被分配在不同的數(shù)據(jù)庫,需要額外進行數(shù)據(jù)操作的路由工作,因此大大增加了系統(tǒng)復雜度。

  3.4 水平分表

   數(shù)據(jù)庫能水平拆分,那數(shù)據(jù)表是不是也可以呢?我們嘗試把某PRODUCT_DB(商品庫)內(nèi)的表,進行了一次水平拆分:

  

1661399013967_4.jpg

   與水平分庫的思路類似,不過這次拆分的目標是表,商品信息及商品描述被分成了兩套表。如果商品ID為奇數(shù),將此操作映射至商品信息1表;如果商品ID為偶數(shù),將操作映射至商品信息2表,這就叫水平分表。水平分表是在同一個數(shù)據(jù)庫內(nèi),把同一個表的數(shù)據(jù)按一定規(guī)則拆分到多個表中。它帶來的提升是:

  - 優(yōu)化單一表數(shù)據(jù)量過大而產(chǎn)生的性能問題

  - 避免IO爭搶并減少鎖表的幾率

   庫內(nèi)的水平分表,解決了單一表數(shù)據(jù)量過大的問題,分出來的小表中只包含一部分數(shù)據(jù),從而使得單個表的數(shù)據(jù)量變小,提高檢索性能。但由于同一個表的數(shù)據(jù)被拆分為多張表,也需要額外進行數(shù)據(jù)操作的路由工作,因此增加了系統(tǒng)復雜度。

  3.5 小結(jié)

  - 垂直分表:可以把一個寬表的字段按訪問頻次、業(yè)務耦合松緊、是否是大字段的原則拆分為多個表,這樣既能使業(yè)務清晰,還能提升部分性能。拆分后,盡量從業(yè)務角度避免聯(lián)查,否則性能方面將得不償失。

  - 垂直分庫:可以把多個表按業(yè)務耦合松緊歸類,分別存放在不同的庫,這些庫可以分布在不同服務器,從而使訪問壓力被多服務器負載,大大提升性能,同時能提高整體架構(gòu)的業(yè)務清晰度,不同的業(yè)務庫可根據(jù)自身情況定制優(yōu)化方案。但是它需要解決跨庫帶來的所有復雜問題。

  - 水平分庫:可以把一個表的數(shù)據(jù)(按數(shù)據(jù)行)分到多個不同的庫,每個庫只有這個表的部分數(shù)據(jù),這些庫可以分布在不同服務器,從而使訪問壓力被多服務器負載,大大提升性能。它不僅需要解決跨庫帶來的所有復雜問題,還要解決數(shù)據(jù)路由的問題。

  - 水平分表:可以把一個表的數(shù)據(jù)(按數(shù)據(jù)行)分到多個同一個數(shù)據(jù)庫的多張表中,每個表只有這個表的部分數(shù)據(jù),這樣做能小幅提升性能,它僅僅作為水平分庫的一個補充優(yōu)化。

  一般來說,在系統(tǒng)設計階段就應該根據(jù)業(yè)務耦合松緊來確定垂直分庫,垂直分表方案,在數(shù)據(jù)量及訪問壓力不是特別大的情況,首先考慮緩存、讀寫分離、索引技術(shù)等方案。若數(shù)據(jù)量極大,且持續(xù)增長,再考慮水平分庫分表方案。

  4 .分庫分表帶來的問題

   分庫分表有效的緩解了大數(shù)據(jù)、高并發(fā)帶來的性能和壓力,也能突破網(wǎng)絡IO、硬件資源、連接數(shù)的瓶頸,但同時也帶來了一些問題。

  4.1 事務一致性問題

   由于分庫分表把數(shù)據(jù)分布在不同庫甚至不同服務器,不可避免會帶來**分布式事務**問題,我們需要額外編程解決該問題。

  4.2 跨節(jié)點join

   在沒有進行分庫分表前,我們檢索商品時可以通過以下SQL對店鋪信息進行關(guān)聯(lián)查詢:

SELECT p.*,s.[店鋪名稱],s.[信譽]
FROM [商品信息] p
LEFT JOIN [店鋪信息] s ON p.id = s.[所屬店鋪]
WHERE...ORDER BY...LIMIT...
```

  但經(jīng)過分庫分表后,[商品信息]和[店鋪信息]不在一個數(shù)據(jù)庫或一個表中,甚至不在一臺服務器上,無法通過sql語句進行關(guān)聯(lián)查詢,我們需要額外編程解決該問題。

  4.3 跨節(jié)點分頁、排序和聚合函數(shù)

   跨節(jié)點多庫進行查詢時,limit分頁、order by排序以及聚合函數(shù)等問題,就變得比較復雜了。需要先在不同的分片節(jié)點中將數(shù)據(jù)進行排序并返回,然后將不同分片返回的結(jié)果集進行匯總和再次排序。例如,進行水平分庫后的商品庫,按ID倒序排序分頁,取第一頁:

1661399092440_5.jpg

   以上流程是取第一頁的數(shù)據(jù),性能影響不大,但由于商品信息的分布在各數(shù)據(jù)庫的數(shù)據(jù)可能是隨機的,如果是取第N頁,需要將所有節(jié)點前N頁數(shù)據(jù)都取出來合并,再進行整體的排序,操作效率可想而知,所以請求頁數(shù)越大,系統(tǒng)的性能也會越差。

   在使用Max、Min、Sum、Count之類的函數(shù)進行計算的時候,與排序分頁同理,也需要先在每個分片上執(zhí)行相應的函數(shù),然后將各個分片的結(jié)果集進行匯總和再次計算,最終將結(jié)果返回。

  4.4 主鍵避重

   在分庫分表環(huán)境中,由于表中數(shù)據(jù)同時存在不同數(shù)據(jù)庫中,主鍵值平時使用的自增長將無用武之地,某個分區(qū)數(shù)據(jù)庫生成的ID無法保證全局唯一。因此需要單獨設計全局主鍵,以避免跨庫主鍵重復問題。

1661399112904_6.jpg

   由于分庫分表之后,數(shù)據(jù)被分散在不同的服務器、數(shù)據(jù)庫和表中。因此,對數(shù)據(jù)的操作也就無法通過常規(guī)方式完成,并且它還帶來了一系列的問題。我們在開發(fā)過程中需要通過一些中間件解決這些問題,市面上有很多中間件可供我們選擇,其中Sharding-JDBC和mycat較為流行。

  5 .總結(jié)

  通過以上學習呢,我們知道,當數(shù)據(jù)庫特別大的情況下,數(shù)據(jù)庫存儲數(shù)量達到了一定的閾值以后會變慢,我們需要使用分庫分表的方案來解決這個問題。我們主要學習了垂直分表、垂直分庫、水平分表、水平分庫四種方案。當我們選擇分庫分表以后也會帶來一些問題,比如事務一致的問題、垮節(jié)點聚合的問題、分頁、主鍵避重等等問題,大家也要掌握這些問題的解決方案。

分享到:
在線咨詢 我要報名
和我們在線交談!