轉(zhuǎn)自https://www.jianshu.com/p/7aec260ca1a2

前言

在互聯(lián)網(wǎng)還未崛起的時代,我們的傳統(tǒng)應用都有這樣一個特點：訪問量、數(shù)據(jù)量都比較小，單庫單表都完全可以支撐整個業(yè)務。隨著互聯(lián)網(wǎng)的發(fā)展和用戶規(guī)模的迅速擴大,對系統(tǒng)的要求也越來越高。因此傳統(tǒng)的MySQL單庫單表架構(gòu)的性能問題就暴露出來了。而有下面幾個因素會影響數(shù)據(jù)庫性能:

• 數(shù)據(jù)量
  MySQL單庫數(shù)據(jù)量在5000萬以內(nèi)性能比較好,超過閾值后性能會隨著數(shù)據(jù)量的增大而變?nèi)酢ySQL單表的數(shù)據(jù)量是500w-1000w之間性能比較好,超過1000w性能也會下降。
• 磁盤
  因為單個服務的磁盤空間是有限制的,如果并發(fā)壓力下,所有的請求都訪問同一個節(jié)點,肯定會對磁盤IO造成非常大的影響。
• 數(shù)據(jù)庫連接
  數(shù)據(jù)庫連接是非常稀少的資源,如果一個庫里既有用戶、商品、訂單相關的數(shù)據(jù),當海量用戶同時操作時,數(shù)據(jù)庫連接就很可能成為瓶頸。

為了提升性能,所以我們必須要解決上述幾個問題,那就有必要引進分庫分表。

垂直拆分 or 水平拆分？

當我們單個庫太大時,我們先要看一下是因為表太多還是數(shù)據(jù)量太大，如果是表太多,則應該將部分表進行遷移(可以按業(yè)務區(qū)分),這就是所謂的垂直切分。如果是數(shù)據(jù)量太大,則需要將表拆成更多的小表,來減少單表的數(shù)據(jù)量,這就是所謂的水平拆分。

垂直拆分

• 垂直分庫
  垂直分庫針對的是一個系統(tǒng)中的不同業(yè)務進行拆分,比如用戶一個庫,商品一個庫,訂單一個庫。 一個購物網(wǎng)站對外提供服務時,會同時對用戶、商品、訂單表進行操作。沒拆分之前, 全部都是落到單一的庫上的,這會讓數(shù)據(jù)庫的單庫處理能力成為瓶頸。如果垂直分庫后還是將用戶、商品、訂單放到同一個服務器上,只是分到了不同的庫,這樣雖然會減少單庫的壓力,但是隨著用戶量增大,這會讓整個數(shù)據(jù)庫的處理能力成為瓶頸,還有單個服務器的磁盤空間、內(nèi)存也會受非常大的影響。 所以我們要將其拆分到多個服務器上，這樣上面的問題都解決了，以后也不會面對單機資源問題。

• 垂直分表
  也就是“大表拆小表”，基于列字段進行的。一般是表中的字段較多，將不常用的， 數(shù)據(jù)較大，長度較長（比如text類型字段）的拆分到“擴展表“。一般是針對那種幾百列的大表，也避免查詢時，數(shù)據(jù)量太大造成的“跨頁”問題。

水平拆分

• 水平分表
  和垂直分表有一點類似,不過垂直分表是基于列的,而水平分表是基于全表的。水平拆分可以大大減少單表數(shù)據(jù)量,提升查詢效率。
• 水平分庫分表
  將單張表的數(shù)據(jù)切分到多個服務器上去，每個服務器具有相應的庫與表，只是表中數(shù)據(jù)集合不同。 水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數(shù)、硬件資源等的瓶頸。

幾種常用的分庫分表的策略

• HASH取模
  假設有用戶表user,將其分成3個表user0,user1,user2.路由規(guī)則是對3取模,當uid=1時,對應到的是user1,uid=2時,對應的是user2.

• 范圍分片
  從1-10000一個表,10001-20000一個表。

• 地理位置分片
  華南區(qū)一個表,華北一個表。

• 時間分片
  按月分片，按季度分片等等,可以做到冷熱數(shù)據(jù)。

分庫分表后引入的問題

• 分布式事務問題
  如果我們做了垂直分庫或者水平分庫以后,就必然會涉及到跨庫執(zhí)行SQL的問題,這樣就引發(fā)了互聯(lián)網(wǎng)界的老大難問題-"分布式事務"。那要如何解決這個問題呢？
  1.使用分布式事務中間件 2.使用MySQL自帶的針對跨庫的事務一致性方案(XA),不過性能要比單庫的慢10倍左右。3.能否避免掉跨庫操作(比如將用戶和商品放在同一個庫中)

• 跨庫join的問題
  分庫分表后表之間的關聯(lián)操作將受到限制，我們無法join位于不同分庫的表，也無法join分表粒度不同的表， 結(jié)果原本一次查詢能夠完成的業(yè)務，可能需要多次查詢才能完成。粗略的解決方法： 全局表：基礎數(shù)據(jù)，所有庫都拷貝一份。 字段冗余：這樣有些字段就不用join去查詢了。 系統(tǒng)層組裝：分別查詢出所有，然后組裝起來，較復雜。

• 橫向擴容的問題
  當我們使用HASH取模做分表的時候,針對數(shù)據(jù)量的遞增,可能需要動態(tài)的增加表,此時就需要考慮因為reHash導致數(shù)據(jù)遷移的問題。

• 結(jié)果集合并、排序的問題
  因為我們是將數(shù)據(jù)分散存儲到不同的庫、表里的,當我們查詢指定數(shù)據(jù)列表時,數(shù)據(jù)來源于不同的子庫或者子表,就必然會引發(fā)結(jié)果集合并、排序的問題。如果每次查詢都需要排序、合并等操作,性能肯定會受非常大的影響。走緩存可能一條路!

使用分庫分表中間件

• Mycat
  Mycat發(fā)展到現(xiàn)在，適用的場景已經(jīng)很豐富，而且不斷有新用戶給出新的創(chuàng)新性的方案，以下是幾個典型的應用場景：
  單純的讀寫分離，此時配置最為簡單，支持讀寫分離，主從切換
  分表分庫，對于超過1000萬的表進行分片，最大支持1000億的單表分片
  多租戶應用，每個應用一個庫，但應用程序只連接Mycat，從而不改造程序本身，實現(xiàn)多租戶化報表系統(tǒng)，借助于Mycat的分表能力，處理大規(guī)模報表的統(tǒng)計
  替代Hbase，分析大數(shù)據(jù)作為海量數(shù)據(jù)實時查詢的一種簡單有效方案，比如100億條頻繁查詢的記錄需要在3秒內(nèi)查詢出來結(jié)果，除了基于主鍵的查詢，還可能存在范圍查詢或其他屬性查詢，此時Mycat可能是最簡單有效的選擇.
• Sharding-JDBC
  當當網(wǎng)開發(fā)的簡單易用、輕量級的中間件。

此外還有淘寶的TDDL,支付寶的OneProxy,360的Atlas等。