爲何要分庫分表?

隨着近些年信息化大躍進,各行各業無紙化辦公產生了大量的數據,而愈來愈多的數據存入了數據庫中。當使用MySQL數據庫的時候,單表超出了2000萬數據量就會出現性能上的分水嶺。算法

而且物理服務器的CPU、內存、存儲、鏈接數等資源有限,某個時段大量鏈接同時執行操做,會致使數據庫在處理上遇到性能瓶頸。數據庫

爲了解決這個問題,行業先驅門充分發揚了分而治之的思想,對大表進行分割,而後實施更好的控制和管理,同時使用多臺機器的CPU、內存、存儲,提供更好的性能。而分而治之則有兩種方式:垂直拆分和水平拆分。緩存

垂直拆分

垂直拆分分爲垂直分庫和垂直分表。先說說垂直分庫。垂直分庫實際上是一種簡單邏輯分割。好比咱們的數據庫中有商品表Products、還有對訂單表Orders,還有積分表Scores。接下來咱們就能夠建立三個數據庫,一個數據庫存放商品,一個數據庫存放訂單,一個數據庫存放積分。以下圖所示:服務器

attachments-2020-04-TMv1Lkq85e8440cdf3b94.jpg

垂直分庫有一個優勢,他可以根據業務場景進行孵化,好比某一單一場景只用到某2-3張表,基本上應用和數據庫能夠拆分出來作成相應的服務。併發

再來講說垂直分表,比較適用於那種字段比較多的表,假設咱們一張表有100個字段,咱們分析了一下當前業務執行的SQL語句,有20個字段是常用的,而另外80個字段使用比較少。分佈式

這樣咱們就能夠把20個字段放在主表裏面,咱們在建立一個輔助表,存放另外80個字段。固然主表和輔助表都是有主鍵的。他們經過主鍵進行關聯合並,就能夠湊成100個字段的表。微服務


attachments-2020-04-loyzpLv65e8441024bb29.jpg


垂直分表能夠解決跨頁的問題。在Oracle中叫行連接。怎麼理解呢?就是你字段少的狀況下,本來一行數據只須要存在一個頁裏面就好了,可是字段多的狀況就存不下了,就須要跨頁。高併發

這樣就會形成額外尋址,形成性能上的開銷。另外將這麼長的一行數據載到內存中,每每是幾個頁面,結果我們常常只訪問其中的幾個字段,對內存也是一個極大的開銷。因此爲了讓內存緩存更多數據,減小磁盤I/O,垂直分表就是很好的手段。性能

整體來講:垂直拆分有如下優勢:3d

  1. 跟隨業務進行分割,和最近流行的微服務概念類似,方便解耦以後的管理及擴展。
  2. 高併發的場景下,垂直拆分使用多臺服務器的CPU、I/O、內存能提高性能,同時對單機數據庫鏈接數、一些資源限制也獲得了提高。
  3. 能實現冷熱數據的分離。

垂直拆分的缺點:

  1. 部分業務表沒法join,應用層須要很大的改造,只能經過聚合的方式來實現。增長了開發的難度。
  2. 當單庫中的表數據量增大的時候依然沒有獲得有效的解決。
  3. 分佈式事務也是一個難題。

水平拆分

當某張表數據量達到必定的程度的時候,前面曾說過MySQL單表出現2000萬以上數據就會出現性能上的分水嶺。此時發現沒有辦法根據業務規則再進行拆分了,就會致使單庫上的讀寫性能出現瓶頸。此時就只能進行水平拆分了。

水平拆分又分爲庫內分表和分庫分表。先說說庫內分表。假設當咱們的Orders表達到了5000萬行記錄的時候,很是影響數據庫的讀寫效率,怎麼辦呢?

咱們能夠考慮按照訂單編號的order_id進行rang分區,就是把訂單編號在1-1000萬的放在order1表中,將編號在1000萬-2000萬的放在order2中,以此類推,每一個表中存放1000萬數據。以下圖所示:


attachments-2020-04-l6gWcE6i5e84415a89320.jpg


雖然咱們能夠經過庫內分表把單表的容量固定在1000萬,可是這些表的數據仍然存放在一個庫內,使用的是該主機的CPU、IO、內存。

單庫的鏈接數也有限制。並不能徹底的下降系統的壓力。此時,咱們就要考慮另一種技術叫分庫分表。

分庫分表在庫內分表的基礎上,將分的表挪動到不一樣的主機和數據庫上。能夠充分的使用其餘主機的CPU、內存和IO資源。而且分庫以後,單庫的鏈接數限制也不在成爲瓶頸。

可是「成也蕭何敗也蕭何」,若是你執行一個掃描不帶分片鍵,則須要在每一個庫上查一遍。

剛剛咱們按照order_id分紅了5個庫,可是咱們查詢是name='AAA'的條件而且不帶order_id字段時,它並不知道在哪一個分片上查,則會建立5個鏈接,而後每一個庫都檢索一遍。這種廣播查詢則會形成鏈接數增多。

由於它須要在每一個庫上都創立鏈接。若是是高併發的系統,執行這種廣播查詢,系統的thread很快就會告警。


attachments-2020-04-LKE7LJgM5e8441762d16e.jpg


整體來講:水平拆分的優勢有如下:

  1. 水平擴展能無線擴展。不存在某個庫某個表過大的狀況。
  2. 可以較好的應對高併發,同時能夠將熱點數據打散。
  3. 應用側的改動較小,不須要根據業務來拆分。

水平拆分的缺點:

  1. 路由是個問題,須要增長一層路由的計算,並且像前面說的同樣,不帶分片鍵查詢會產生廣播SQL。
  2. 跨庫join的性能比較差。
  3. 須要處理分佈式事務的一致性問題。

一塊兒使用

當前咱們的系統,垂直拆分和水平拆分都在使用,垂直拆分主要是作業務上的分割,把業務的各個子系統都規劃好,能解耦就解耦。而垂直拆分以後。咱們再作水平分庫分表。經過取模算法將大表數據拆到若干個庫中。

邏輯庫和物理庫

介紹了上述的分庫分表,咱們有必要說一下幾個概念,一個是邏輯庫和物理庫的概念。咱們仍是拿水平拆分中的分庫分表來講。咱們在物理層面,將一個庫的數據分割到了5個數據庫中。這5個數據庫就是物理庫,而它們對上層應用的展示則是一個庫。這個對上層展示的庫就叫邏輯庫。邏輯庫對應用層是透明的。應用不須要了解底層的狀況,直接使用就好了。

仍是拿水平拆分中的分庫分表來講,orders表總共被分紅了5份,分別在底層是orders_1~5。這底層的5個表就是物理表。可是對應用層面來講,只有orders表。這就是邏輯表。

總結:這一篇主要是講述一些分庫分表以後的概念。須要加深一些理解,由於咱們的項目也纔是剛剛開始拆分,因此有寫的不對的地方還但願提出意見指正。



attachments-2020-04-RQTImKtM5e843d87232c6.jpg

相關文章
相關標籤/搜索