數(shù)據(jù)分庫分表最佳實踐

1、 數(shù)據(jù)分庫分表最佳實踐為什么討論分庫分表在服務(wù)器后端技術(shù)人員的成長路線上，分片（Sharding）思想的理解和把握是繞不過去的門檻，而數(shù)據(jù)庫分庫分表可能是講述拆分思想最好的教材，大部分后端技術(shù)人員都會在成長過程中遇到這樣的問題。為什么講道，因為道比術(shù)重要一萬倍。技術(shù)浪潮一波一波在推動社會的前進(jìn)，新的技術(shù)雨后春筍，簡單且樸實的道理，更長久也更樸實且普適。分庫分表是什么我們?nèi)绾蚊枋龇謳旆直?。可以這樣定義分庫分表，當(dāng)業(yè)務(wù)的增長導(dǎo)致數(shù)據(jù)庫瓶頸的時候，一種解決瓶頸的手段。數(shù)據(jù)庫的是很容易出瓶頸的一個地方，瓶頸，包含性能，容量等等。一方面是存在放大效應(yīng)。比如業(yè)務(wù)強(qiáng)要求所有的請求在100ms得到返回，這10

2、0ms分配到數(shù)據(jù)層，可能留的時間也就1-2ms，任何數(shù)據(jù)庫的波動，會被放大10-20倍反應(yīng)到上層。另一方面是存在單點問題，數(shù)據(jù)庫保持了最新且最準(zhǔn)確的狀態(tài)，這個狀態(tài)增長是隨業(yè)務(wù)增長同步的，且業(yè)務(wù)的增長會導(dǎo)致業(yè)務(wù)的復(fù)雜性，復(fù)雜性最后反應(yīng)到數(shù)據(jù)庫的存儲里代表的就是增量。數(shù)據(jù)庫需要應(yīng)對隨業(yè)務(wù)增長指數(shù)上升的數(shù)據(jù)增量，且數(shù)據(jù)庫系統(tǒng)本身通過單點性，來保持狀態(tài)的準(zhǔn)確性，很容易遇到單機(jī)的性能問題。而分庫分表就是大多數(shù)互聯(lián)網(wǎng)公司遇到數(shù)據(jù)庫瓶頸后，解決瓶頸的近乎行業(yè)標(biāo)準(zhǔn)手段。分庫分表的本質(zhì)我們回顧數(shù)據(jù)庫發(fā)展的歷史，數(shù)據(jù)庫是怎么發(fā)展起來的，它在先解決什么問題，為什么現(xiàn)在會有瓶頸的問題計算機(jī)的本質(zhì)滿足可計算性的快速計算

3、。而數(shù)據(jù)庫系統(tǒng)的本質(zhì)來源于，隨著計算力擴(kuò)大隨之匹配的對數(shù)據(jù)的儲存和管理能力。最早的編程是通過在紙帶上打孔來完成計算計算步驟的編寫，輸出的也是紙帶。數(shù)據(jù)庫就是對一系列紙帶的管理，還別說，那時候就有搜索的需求了。1968年，IBM做出了第一現(xiàn)代意義上的數(shù)據(jù)庫系統(tǒng)。DBMS，除了沒有SQL的支持，但是基本上已經(jīng)是完善的現(xiàn)代數(shù)據(jù)庫了。擁有現(xiàn)代數(shù)據(jù)庫應(yīng)有的，存儲，檢索，狀態(tài)一致等功能。1970年后關(guān)系型數(shù)據(jù)庫興起，那時候搞關(guān)系型數(shù)據(jù)庫的公司，就像現(xiàn)在專門做NoSQL的數(shù)據(jù)庫那么的酷。Oracle 是關(guān)系型數(shù)據(jù)庫最終的勝利者。如果去深挖這段歷史，確實是IBM的員工在1974 年的時候提出了SQL的觀點，但

4、是在1979年，Oracle最終第一個做出了第一個關(guān)系型數(shù)據(jù)庫。這時候的數(shù)據(jù)庫，和我們現(xiàn)在接觸的數(shù)據(jù)庫已經(jīng)基本一致了。我們簡單概括一下數(shù)據(jù)庫所提供的功能。數(shù)據(jù)庫系統(tǒng)有存儲，管理，檢索的需要。數(shù)據(jù)庫對應(yīng)提供了儲存，索引，一致性的功能。數(shù)據(jù)庫儲存數(shù)據(jù)為文件，通過樹的結(jié)構(gòu)來提供索引，通過提供事務(wù)組的方式，來保證一致性。至于SQL，是用于管理數(shù)據(jù)的語言，用于擴(kuò)展對數(shù)據(jù)的管理能力。為什么現(xiàn)在會有數(shù)據(jù)庫瓶頸的問題，在我看來就是，單機(jī)的到計算瓶頸了，計算的部分快速的轉(zhuǎn)向分布式，大規(guī)模的集群。而數(shù)據(jù)庫做集群的方式很難。對于單機(jī)應(yīng)用來說，數(shù)據(jù)庫基本上沒有瓶頸，對于互聯(lián)網(wǎng)公司來說，流量在不停的拆分，保證單臺機(jī)器的

5、處理負(fù)載在可處理范圍內(nèi)，但是因為數(shù)據(jù)庫本身是一個針對單機(jī)的系統(tǒng)，同時需要保證一致性狀態(tài)，所以更容易到瓶頸。數(shù)據(jù)庫系統(tǒng)原本就是一個支持索引，一致性，和存儲是一個相對平衡的單機(jī)應(yīng)用，但是一旦想要擴(kuò)展分布，那就要做一些權(quán)衡。在我看來，分庫分表就是拉伸存儲，放棄一些，索引和一致性的一個方案。如何拉伸儲存拉伸儲存，本質(zhì)上就是通過減少需要計算的數(shù)據(jù)量，來換取計算速度的這樣一個過程。所以拆分的時候就是，如何計算速度最快那就如何拆分。所以貼子系統(tǒng)適合按日期分庫分表，交易系統(tǒng)適合冷熱數(shù)據(jù)分類，長期有效的商品系統(tǒng)，就需要按照Hash來直接水平拆分。分表解決的是，過大的數(shù)據(jù)表影響計算速度的問題，比如單表上億，那么我

6、拆成十個表，那么我必然會比一個表更快，原因是，用了一部分計算落表時間，來換取表計算的時間。分庫更多解決的是機(jī)器的局限的問題，單機(jī)容量有限，單機(jī)容量實際上是由，機(jī)器硬件決定，比如我的網(wǎng)卡打滿，CPU打滿，機(jī)器磁盤寫滿，這種case，必須將計算分布到其他機(jī)器上解決。先拆分進(jìn)程，隨后將進(jìn)程拆分到不同的機(jī)器上。分庫分表的核心是為了創(chuàng)建一個對業(yè)務(wù)相對透明的邏輯大表，隔離存儲的負(fù)載度，進(jìn)而實現(xiàn)在業(yè)務(wù)眼里的無限存儲。如何保障索引一定要理解，索引和存儲是相關(guān)隔離的兩件事，而對于數(shù)據(jù)庫來說，強(qiáng)行提升了儲存，而索引就是需要付出的代價。當(dāng)存儲分布之后，單機(jī)的索引是無法滿足對索引的要求的，而SQL是對索引的更上一層的

7、封裝，這個部分會有一定程度的限制，比如，分庫分表最多能滿足兩個維度的拆分，Join表這種操作就不要想了。方法就是，簡單索引邏輯靠中間件構(gòu)建虛擬索引，復(fù)雜索引靠其他方式構(gòu)建外置索引。所有的分庫分表的中間件的工作，無非是在數(shù)據(jù)源和應(yīng)用之間封裝一層虛擬的滿足基本需要的索引。應(yīng)用發(fā)送請求到中間件，中間件起到一部分索引的作用，判定需要到哪個庫，哪個表來執(zhí)行，這就是單機(jī)數(shù)據(jù)庫，選擇表過程的外置。中間件還有一個作用是，對涉及邏輯表的部分，進(jìn)行一部分SQL邏輯改寫，來最終判定到某些部分執(zhí)行。對于更復(fù)雜的查詢要求，應(yīng)用方需要單獨構(gòu)建另外的索引，即把索引單獨拆出來做成一個系統(tǒng)，來滿足檢索需要。作為代價來說，外置的

8、索引會比內(nèi)置的索引相對慢些，這是在系統(tǒng)架構(gòu)上需要注意的地方。但是作為大原則，盡量把需變計算邏輯放置在索引外進(jìn)行。如何保障一致性分庫分表還好的地方在于，數(shù)據(jù)最終存儲是一份的，主從實際上是以主為準(zhǔn)的，除了嚴(yán)格的時間外窗口外，對一致性存儲的調(diào)整不是很大。但是因為分庫分表把需要操作的數(shù)據(jù)源分散了，操作的原子性在保障起來是有損耗了，核心問題就在于，如何保障，跨數(shù)據(jù)庫，跨進(jìn)程，跨機(jī)器的操作原子性。方法就是，外置保證一致性的方式。A,B,C 三個獨立動作，想讓他們保證一致，要么，在最前面一致，要么在最后面一致，就是消除這三個動作的中間狀態(tài)。通過MQ實現(xiàn)的數(shù)據(jù)一致性，相當(dāng)于把動作歸結(jié)為最終狀態(tài)，用戶付了款，那

9、我就保證一定得完成支付，發(fā)券，等等相關(guān)動作，如果交易各種原因最終失敗，我也得保證用戶的這筆交易進(jìn)入一個最終退款的狀態(tài)。通過軟事務(wù)的方式來實現(xiàn)的最終一致性，方式就是外置檢查，某一動作失敗時，往前回滾，不一定完全回滾數(shù)據(jù)狀態(tài)，但是屬于是回滾到不影響發(fā)生其它業(yè)務(wù)邏輯的業(yè)務(wù)狀態(tài)。比如下單，減庫存，創(chuàng)建訂單，創(chuàng)建訂單失敗，那我就需要釋放庫存，倒序回置狀態(tài)。一個分庫設(shè)計實例對于交易系統(tǒng)來說，天然區(qū)分冷熱數(shù)據(jù)，交易核心訂單一旦超過三個月之后，不太可能會再有更改問題，另外一個問題是，交易強(qiáng)事務(wù)驅(qū)動，必須依靠事務(wù)，對一致性強(qiáng)要求，交易的讀寫比實際上并不是特別的大。同時交易的訪問量實際上相比于流量是有數(shù)據(jù)量級差異的，如果交易量打破單機(jī)瓶頸，有其他方式，與主題無關(guān)，不再詳述。我們這套設(shè)計描述如下。交易維護(hù)一個熱數(shù)據(jù)庫，保留最近三個月的交易熱數(shù)據(jù)，事務(wù)相關(guān)表盡量保留在這個數(shù)據(jù)庫中，所有的交易的一致性需求必然會是熱數(shù)據(jù)。冷庫按時間分庫，保留三個月之后的數(shù)據(jù)，隨業(yè)務(wù)量擴(kuò)展。在交易id拼入日期因素，中間件判定id是冷是熱，確定查詢方案，如果不好判定，先查詢熱庫再查詢冷庫。兩者之間靠MQ完成數(shù)據(jù)傳輸，保證交易數(shù)據(jù)不會丟失。線上業(yè)務(wù)一般無復(fù)雜查詢，中間件可以搞定，對于線下業(yè)務(wù)，有相關(guān)復(fù)雜數(shù)據(jù)的，走單獨構(gòu)