垂直分表：垂直分表在日常開發(fā)和設(shè)計(jì)中比較常見，通俗的說法叫做“大表拆小表”，拆分是基于關(guān)系型數(shù)據(jù)庫中的“列”（字段）進(jìn)行的。通常情況，某個(gè)表中的字段比較多，可以新建立一張“擴(kuò)展表”，將不經(jīng)常使用或者長(zhǎng)度較大的字段拆分出去放到“擴(kuò)展表”中。
ps:在字段很多的情況下，拆分開確實(shí)更便于開發(fā)和維護(hù)（曾見過某個(gè)遺留系統(tǒng)中，一個(gè)大表中包含100多列的）。某種意義上也能避免“跨頁”的問題（MySQL、MSSQL底層都是通過“數(shù)據(jù)頁”來存儲(chǔ)的，“跨頁”問題可能會(huì)造成額外的性能開銷）。拆分字段的操作建議在數(shù)據(jù)庫設(shè)計(jì)階段就做好。如果是在發(fā)展過程中拆分，則需要改寫以前的查詢語句，會(huì)額外帶來一定的成本和風(fēng)險(xiǎn)，建議謹(jǐn)慎。
垂直分庫:基本的思路就是按照業(yè)務(wù)模塊來劃分出不同的數(shù)據(jù)庫，而不是像早期一樣將所有的數(shù)據(jù)表都放到同一個(gè)數(shù)據(jù)庫中。
ps：系統(tǒng)層面的“服務(wù)化”拆分操作，能夠解決業(yè)務(wù)系統(tǒng)層面的耦合和性能瓶頸，有利于系統(tǒng)的擴(kuò)展維護(hù)。而數(shù)據(jù)庫層面的拆分，道理也是相通的。與服務(wù)的“治理”和“降級(jí)”機(jī)制類似，我們也能對(duì)不同業(yè)務(wù)類型的數(shù)據(jù)進(jìn)行“分級(jí)”管理、維護(hù)、監(jiān)控、擴(kuò)展等。眾所周知，數(shù)據(jù)庫往往最容易成為應(yīng)用系統(tǒng)的瓶頸，而數(shù)據(jù)庫本身屬于“有狀態(tài)”的，相對(duì)于Web和應(yīng)用服務(wù)器來講，是比較難實(shí)現(xiàn)“橫向擴(kuò)展”的。數(shù)據(jù)庫的連接資源比較寶貴且單機(jī)處理能力也有限，在高并發(fā)場(chǎng)景下，垂直分庫一定程度上能夠突破IO、連接數(shù)及單機(jī)硬件資源的瓶頸，是大型分布式系統(tǒng)中優(yōu)化數(shù)據(jù)庫架構(gòu)的重要手段。
水平分表：水平分表也稱為橫向分表，比較容易理解，就是將表中不同的數(shù)據(jù)行按照一定規(guī)律分布到不同的數(shù)據(jù)庫表中（這些表保存在同一個(gè)數(shù)據(jù)庫中），這樣來降低單表數(shù)據(jù)量，優(yōu)化查詢性能。最常見的方式就是通過主鍵或者時(shí)間等字段進(jìn)行Hash和取模后拆分。
ps:水平分表，能夠降低單表的數(shù)據(jù)量，一定程度上可以緩解查詢性能瓶頸。但本質(zhì)上這些表還保存在同一個(gè)庫中，所以庫級(jí)別還是會(huì)有IO瓶頸。所以，一般不建議采用這種做法。
水平分庫分表:水平分庫分表與上面講到的水平分表的思想相同，唯一不同的就是將這些拆分出來的表保存在不同的數(shù)據(jù)庫中。這也是很多大型互聯(lián)網(wǎng)公司所選擇的做法。
ps:某種意義上來講，有些系統(tǒng)中使用的“冷熱數(shù)據(jù)分離”（將一些使用較少的歷史數(shù)據(jù)遷移到其他的數(shù)據(jù)庫中。而在業(yè)務(wù)功能上，通常默認(rèn)只提供熱點(diǎn)數(shù)據(jù)的查詢），也是類似的實(shí)踐。在高并發(fā)和海量數(shù)據(jù)的場(chǎng)景下，分庫分表能夠有效緩解單機(jī)和單庫的性能瓶頸和壓力，突破IO、連接數(shù)、硬件資源的瓶頸。當(dāng)然，投入的硬件成本也會(huì)更高。同時(shí)，這也會(huì)帶來一些復(fù)雜的技術(shù)問題和挑戰(zhàn)（例如：跨分片的復(fù)雜查詢，跨分片事務(wù)等）
在拆分之前，系統(tǒng)中很多列表和詳情頁所需的數(shù)據(jù)是可以通過sql join來完成的。而拆分后，數(shù)據(jù)庫可能是分布式在不同實(shí)例和不同的主機(jī)上，join將變得非常麻煩。而且基于架構(gòu)規(guī)范，性能，安全性等方面考慮，一般是禁止跨庫join的。那該怎么辦呢？首先要考慮下垂直分庫的設(shè)計(jì)問題，如果可以調(diào)整，那就優(yōu)先調(diào)整。如果無法調(diào)整的情況，下面將結(jié)合以往的實(shí)際經(jīng)驗(yàn)，總結(jié)幾種常見的解決思路，并分析其適用場(chǎng)景。
全局表
所謂全局表，就是有可能系統(tǒng)中所有模塊都可能會(huì)依賴到的一些表。比較類似我們理解的“數(shù)據(jù)字典”。為了避免跨庫join查詢，我們可以將這類表在其他每個(gè)數(shù)據(jù)庫中均保存一份。同時(shí)，這類數(shù)據(jù)通常也很少發(fā)生修改（甚至幾乎不會(huì)），所以也不用太擔(dān)心“一致性”問題。
字段冗余
這是一種典型的反范式設(shè)計(jì)，在互聯(lián)網(wǎng)行業(yè)中比較常見，通常是為了性能來避免join查詢。
舉個(gè)電商業(yè)務(wù)中很簡(jiǎn)單的場(chǎng)景：
“訂單表”中保存“賣家Id”的同時(shí)，將賣家的“Name”字段也冗余，這樣查詢訂單詳情的時(shí)候就不需要再去查詢“賣家用戶表”。
字段冗余能帶來便利，是一種“空間換時(shí)間”的體現(xiàn)。但其適用場(chǎng)景也比較有限，比較適合依賴字段較少的情況。最復(fù)雜的還是數(shù)據(jù)一致性問題，這點(diǎn)很難保證，可以借助數(shù)據(jù)庫中的觸發(fā)器或者在業(yè)務(wù)代碼層面去保證。當(dāng)然，也需要結(jié)合實(shí)際業(yè)務(wù)場(chǎng)景來看一致性的要求。就像上面例子，如果賣家修改了Name之后，是否需要在訂單信息中同步更新呢？
數(shù)據(jù)同步
A庫中的tab_a表和B庫中tbl_b有關(guān)聯(lián)，可以定時(shí)將指定的表做同步。當(dāng)然，同步本來會(huì)對(duì)數(shù)據(jù)庫帶來一定的影響，需要性能影響和數(shù)據(jù)時(shí)效性中取得一個(gè)平衡。這樣來避免復(fù)雜的跨庫查詢。
系統(tǒng)層組裝
在系統(tǒng)層面，通過調(diào)用不同模塊的組件或者服務(wù)，獲取到數(shù)據(jù)并進(jìn)行字段拼裝。說起來很容易，但實(shí)踐起來可真沒有這么簡(jiǎn)單，尤其是數(shù)據(jù)庫設(shè)計(jì)上存在問題但又無法輕易調(diào)整的時(shí)候。具體情況通常會(huì)比較復(fù)雜。組裝的時(shí)候要避免循環(huán)調(diào)用服務(wù)，循環(huán)RPC，循環(huán)查詢數(shù)據(jù)庫，最好一次性返回所有信息，在代碼里做組裝。
http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency
我們往往直接使用數(shù)據(jù)庫自增特性來生成主鍵ID，這樣確實(shí)比較簡(jiǎn)單。而在分庫分表的環(huán)境中，數(shù)據(jù)分布在不同的分片上，不能再借助數(shù)據(jù)庫自增長(zhǎng)特性直接生成，否則會(huì)造成不同分片上的數(shù)據(jù)表主鍵會(huì)重復(fù)。簡(jiǎn)單介紹幾種ID生成算法。
Twitter的Snowflake（又名“雪花算法”）
UUID/GUID（一般應(yīng)用程序和數(shù)據(jù)庫均支持）
MongoDB ObjectID（類似UUID的方式）
Ticket Server（數(shù)據(jù)庫生存方式，F(xiàn)lickr采用的就是這種方式）
其中，Twitter 的Snowflake算法生成的是64位唯一Id（由41位的timestamp+ 10位自定義的機(jī)器碼+ 13位累加計(jì)數(shù)器組成）。
在開始分片之前，我們首先要確定分片字段（也可稱為“片鍵”）。很多常見的例子和場(chǎng)景中是采用ID或者時(shí)間字段進(jìn)行拆分。這也并不絕對(duì)的，我的建議是結(jié)合實(shí)際業(yè)務(wù)，通過對(duì)系統(tǒng)中執(zhí)行的sql語句進(jìn)行統(tǒng)計(jì)分析，選擇出需要分片的那個(gè)表中最頻繁被使用，或者最重要的字段來作為分片字段。
常見分片規(guī)則
常見的分片策略有隨機(jī)分片和連續(xù)分片這兩種，當(dāng)需要使用分片字段進(jìn)行范圍查找時(shí)，連續(xù)分片可以快速定位分片進(jìn)行高效查詢，大多數(shù)情況下可以有效避免跨分片查詢的問題。后期如果想對(duì)整個(gè)分片集群擴(kuò)容時(shí)，只需要添加節(jié)點(diǎn)即可，無需對(duì)其他分片的數(shù)據(jù)進(jìn)行遷移。但是，連續(xù)分片也有可能存在數(shù)據(jù)熱點(diǎn)的問題，有些節(jié)點(diǎn)可能會(huì)被頻繁查詢壓力較大，熱數(shù)據(jù)節(jié)點(diǎn)就成為了整個(gè)集群的瓶頸。而有些節(jié)點(diǎn)可能存的是歷史數(shù)據(jù)，很少需要被查詢到。隨機(jī)分片其實(shí)并不是隨機(jī)的，也遵循一定規(guī)則。通常，我們會(huì)采用Hash取模的方式進(jìn)行分片拆分，所以有些時(shí)候也被稱為離散分片。隨機(jī)分片的數(shù)據(jù)相對(duì)比較均勻，不容易出現(xiàn)熱點(diǎn)和并發(fā)訪問的瓶頸。但是，后期分片集群擴(kuò)容起來需要遷移舊的數(shù)據(jù)。使用一致性Hash算法能夠很大程度的避免這個(gè)問題，所以很多中間件的分片集群都會(huì)采用一致性Hash算法。離散分片也很容易面臨跨分片查詢的復(fù)雜問題。
很少有項(xiàng)目會(huì)在初期就開始考慮分片設(shè)計(jì)的，一般都是在業(yè)務(wù)高速發(fā)展面臨性能和存儲(chǔ)的瓶頸時(shí)才會(huì)提前準(zhǔn)備。因此，不可避免的就需要考慮歷史數(shù)據(jù)遷移的問題。一般做法就是通過程序先讀出歷史數(shù)據(jù)，然后按照指定的分片規(guī)則再將數(shù)據(jù)寫入到各個(gè)分片節(jié)點(diǎn)中。此外，我們需要根據(jù)當(dāng)前的數(shù)據(jù)量和QPS等進(jìn)行容量規(guī)劃，綜合成本因素，推算出大概需要多少分片（一般建議單個(gè)分片上的單表數(shù)據(jù)量不要超過1000W）。如果是采用隨機(jī)分片，則需要考慮后期的擴(kuò)容問題，相對(duì)會(huì)比較麻煩。如果是采用的范圍分片，只需要添加節(jié)點(diǎn)就可以自動(dòng)擴(kuò)容。
分頁時(shí)需要按照指定字段進(jìn)行排序。當(dāng)排序字段就是分片字段的時(shí)候，我們通過分片規(guī)則可以比較容易定位到指定的分片，而當(dāng)排序字段非分片字段的時(shí)候，情況就會(huì)變得比較復(fù)雜了。為了最終結(jié)果的準(zhǔn)確性，我們需要在不同的分片節(jié)點(diǎn)中將數(shù)據(jù)進(jìn)行排序并返回，并將不同分片返回的結(jié)果集進(jìn)行匯總和再次排序，最后再返回給用戶。
在使用Max、Min、Sum、Count之類的函數(shù)進(jìn)行統(tǒng)計(jì)和計(jì)算的時(shí)候，需要先在每個(gè)分片數(shù)據(jù)源上執(zhí)行相應(yīng)的函數(shù)處理，然后再將各個(gè)結(jié)果集進(jìn)行二次處理，最終再將處理結(jié)果返回。
Join是關(guān)系型數(shù)據(jù)庫中最常用的特性，但是在分片集群中，join也變得非常復(fù)雜。應(yīng)該盡量避免跨分片的join查詢（這種場(chǎng)景，比上面的跨分片分頁更加復(fù)雜，而且對(duì)性能的影響很大）。通常有以下幾種方式來避免：
全局表
全局表的概念之前在“垂直分庫”時(shí)提過?；舅枷胍恢?，就是把一些類似數(shù)據(jù)字典又可能會(huì)產(chǎn)生join查詢的表信息放到各分片中，從而避免跨分片的join。
ER分片
在關(guān)系型數(shù)據(jù)庫中，表之間往往存在一些關(guān)聯(lián)的關(guān)系。如果我們可以先確定好關(guān)聯(lián)關(guān)系，并將那些存在關(guān)聯(lián)關(guān)系的表記錄存放在同一個(gè)分片上，那么就能很好的避免跨分片join問題。在一對(duì)多關(guān)系的情況下，我們通常會(huì)選擇按照數(shù)據(jù)較多的那一方進(jìn)行拆分。
內(nèi)存計(jì)算
隨著spark內(nèi)存計(jì)算的興起，理論上來講，很多跨數(shù)據(jù)源的操作問題看起來似乎都能夠得到解決?？梢詫?shù)據(jù)丟給spark集群進(jìn)行內(nèi)存計(jì)算，最后將計(jì)算結(jié)果返回。
其實(shí)這點(diǎn)沒有明確的判斷標(biāo)準(zhǔn)，比較依賴實(shí)際業(yè)務(wù)情況和經(jīng)驗(yàn)判斷。一般MySQL單表1000W左右的數(shù)據(jù)是沒有問題的（前提是應(yīng)用系統(tǒng)和數(shù)據(jù)庫等層面設(shè)計(jì)和優(yōu)化的比較好）。
當(dāng)然，除了考慮當(dāng)前的數(shù)據(jù)量和性能情況時(shí)，作為架構(gòu)師，我們需要提前考慮系統(tǒng)半年到一年左右的業(yè)務(wù)增長(zhǎng)情況，對(duì)數(shù)據(jù)庫服務(wù)器的QPS、連接數(shù)、容量等做合理評(píng)估和規(guī)劃，并提前做好相應(yīng)的準(zhǔn)備工作。如果單機(jī)無法滿足，且很難再從其他方面優(yōu)化，那么說明是需要考慮分片的。這種情況可以先去掉數(shù)據(jù)庫中自增ID，為分片和后面的數(shù)據(jù)遷移工作提前做準(zhǔn)備。
很多人覺得“分庫分表”是宜早不宜遲，應(yīng)該盡早進(jìn)行，因?yàn)閾?dān)心越往后公司業(yè)務(wù)發(fā)展越快、系統(tǒng)越來越復(fù)雜、系統(tǒng)重構(gòu)和擴(kuò)展越困難…這種話聽起來是有那么一點(diǎn)道理，但我的觀點(diǎn)恰好相反，對(duì)于關(guān)系型數(shù)據(jù)庫來講，我認(rèn)為“能不分片就別分片”，除非是系統(tǒng)真正需要，因?yàn)閿?shù)據(jù)庫分片并非低成本或者免費(fèi)的。這里推薦一個(gè)比較靠譜的過渡技術(shù)–“表分區(qū)”。主流的關(guān)系型數(shù)據(jù)庫中基本都支持。不同的分區(qū)在邏輯上仍是一張表，但是物理上卻是分開的，能在一定程度上提高查詢性能，而且對(duì)應(yīng)用程序透明，無需修改任何代碼。當(dāng)時(shí)有一個(gè)系統(tǒng)，主業(yè)務(wù)表有大約8000W左右的數(shù)據(jù)，考慮到成本問題，當(dāng)時(shí)就是采用“表分區(qū)”來做的，效果比較明顯，且系統(tǒng)運(yùn)行的很穩(wěn)定。
當(dāng)前主要有兩類解決方案：
基于應(yīng)用程序?qū)用娴腄DAL（分布式數(shù)據(jù)庫訪問層）
比較典型的就是淘寶半開源的TDDL，當(dāng)當(dāng)網(wǎng)開源的Sharding-JDBC等。分布式數(shù)據(jù)訪問層無需硬件投入，技術(shù)能力較強(qiáng)的大公司通常會(huì)選擇自研或參照開源框架進(jìn)行二次開發(fā)和定制。對(duì)應(yīng)用程序的侵入性一般較大，會(huì)增加技術(shù)成本和復(fù)雜度。通常僅支持特定編程語言平臺(tái)（Java平臺(tái)的居多），或者僅支持特定的數(shù)據(jù)庫和特定數(shù)據(jù)訪問框架技術(shù)（一般支持MySQL數(shù)據(jù)庫，JDBC、MyBatis、Hibernate等框架技術(shù)）。
數(shù)據(jù)庫中間件，比較典型的像mycat（在阿里開源的cobar基礎(chǔ)上做了很多優(yōu)化和改進(jìn)，屬于后起之秀，也支持很多新特性），基于Go語言實(shí)現(xiàn)kingSharding，比較老牌的Atlas（由360開源）等。這些中間件在互聯(lián)網(wǎng)企業(yè)中大量被使用。另外，MySQL 5.x企業(yè)版中官方提供的Fabric組件也號(hào)稱支持分片技術(shù)，不過國(guó)內(nèi)使用的企業(yè)較少。
中間件也可以稱為“透明網(wǎng)關(guān)”，大名鼎鼎的mysql_proxy大概是該領(lǐng)域的鼻祖（由MySQL官方提供，僅限于實(shí)現(xiàn)“讀寫分離”）。中間件一般實(shí)現(xiàn)了特定數(shù)據(jù)庫的網(wǎng)絡(luò)通信協(xié)議，模擬一個(gè)真實(shí)的數(shù)據(jù)庫服務(wù)，屏蔽了后端真實(shí)的Server，應(yīng)用程序通常直接連接中間件即可。而在執(zhí)行SQL操作時(shí)，中間件會(huì)按照預(yù)先定義分片規(guī)則，對(duì)SQL語句進(jìn)行解析、路由，并對(duì)結(jié)果集做二次計(jì)算再最終返回。
引入數(shù)據(jù)庫中間件的技術(shù)成本更低，對(duì)應(yīng)用程序來講侵入性幾乎沒有，可以滿足大部分的業(yè)務(wù)。增加了額外的硬件投入和運(yùn)維成本，同時(shí)，中間件自身也存在性能瓶頸和單點(diǎn)故障問題，需要能夠保證中間件自身的高可用、可擴(kuò)展。
總之，不管是使用分布式數(shù)據(jù)訪問層還是數(shù)據(jù)庫中間件，都會(huì)帶來一定的成本和復(fù)雜度，也會(huì)有一定的性能影響。所以，還需讀者根據(jù)實(shí)際情況和業(yè)務(wù)發(fā)展需要慎重考慮和選擇。
聯(lián)系客服
