關於大型網站技術演進的思考（四）--存儲的瓶頸（4）[轉]

若是數據庫須要進行水平拆分，這實際上是一件很開心的事情，由於它表明公司的業務正在迅猛的增加，對於開發人員而言那就是有不盡的項目能夠作，雖然會感受很忙，可是人過的充實，內心也踏實。

　　數據庫水平拆分簡單說來就是先將原數據庫裏的一張表在作垂直拆分出來放置在單獨的數據庫和單獨的表裏後更進一步的把原本是一個總體的表進一步拆分紅多張表，每一張表都用獨立的數據庫進行存儲。當表被水平拆分後，原數據表成爲了一個邏輯的概念，而這個邏輯表的業務含義須要多張物理表協同完成，所以數據庫的表被水平拆分後，那麼咱們對這張表的操做已經超出了數據庫自己提供給咱們現有的手段，換句話說咱們對錶的操做會超出數據庫自己所擁有的處理能力，這個時候我就須要設計相關的方案來彌補數據庫缺失的能力，這就是數據庫水平拆分最大的技術難點所在。

　　數據庫的水平拆分是數據庫垂直拆分的升級版，它和垂直拆分更像繼承機制裏的父子關係，所以水平拆分後，垂直拆分所遇到的join查詢的問題以及分佈式事務的問題任然存在，因爲表被物理拆解增長了邏輯表的維度，這也給垂直拆分裏碰到的兩個難題增長了更多的維度，所以水平拆分裏join查詢的問題和分佈式事務會變得更加複雜。水平拆分除了垂直拆分兩個難題外，它還會產生新的技術難題，這些難題具體以下：

　　難題一：數據庫的表被水平拆分後，該表的主鍵設計會變得十分困難；

　　難題二：原來單表的查詢邏輯會面臨挑戰。

　　在準備本篇文章時候，我看到一些資料裏還提到了一些難題，這些難題是：

　　難題三：水平拆分表後，外鍵的設計也會變得十分困難；

　　難題四：這個難題是針對數據的新增操做的，大體的意思是，咱們到底按什麼規則把須要存儲的數據存儲在拆分出的那個具體的物理數據表裏。

　　難題三的問題，我在上篇已經給出瞭解答，這裏我進行必定的補充，其實外鍵問題在垂直拆分就已經存在，不過在講垂直拆分時候咱們沒有講到這個問題，這主要是我設定了一個前提，就是數據表在最原始的數據建模階段就要拋棄全部外鍵的設計，並將外鍵的邏輯拋給服務層去完成，咱們要盡全力減輕數據庫承擔的運算壓力，其實除了減輕數據庫運算壓力外，咱們還要將做爲存儲原子的表保持相對的獨立性，互不關聯，那麼要作到這點最直接的辦法就是去掉表與表之間關聯的象徵：外鍵，這樣咱們就能夠從根基上爲未來數據庫作垂直拆分和水平拆分打下堅實的基礎。

　　至於難題四，其實問題的本質是分庫分表後具體的數據在哪裏落地的問題，而數據存儲在表裏的關鍵障礙其實就是主鍵，試想一下，咱們設計張表，全部字段咱們都准許能夠爲空，可是表裏有個字段是絕對不能爲空的，那就是主鍵，主鍵是數據在數據庫裏身份的象徵，所以咱們在主鍵設計上是能夠體現出該數據的落地規則，那麼難題四也會隨之解決。所以下文我會重點講解前兩個水平拆分的難題。

　　首先是水平拆分裏的主鍵設計問題，拋開全部主鍵所能表明的業務含義，數據庫裏標的主鍵本質是表達表裏的某一條記錄的惟一性，在設計數據庫的時候咱們能夠由一個絕對不可重複的字段表示主鍵，也可使用多個字段組合起來表達這種惟一性，使用一個字段表示主鍵，這已是很原子級的操做，無法作進一步的修改，可是若是使用多個字段表示一個主鍵對於水平拆分而言就會碰到問題了，這個問題主要是體如今數據到底落地於哪一個數據庫，關於主鍵對數據落地的影響我會在把相關知識講解完畢後再着重闡述，這裏要提的是當碰到聯合主鍵時候咱們能夠設定一個沒有任何業務含義的字段來替代，不過這個要看場景了，我傾向於將聯合主鍵各個字段裏的值合併爲一個字段來表示主鍵，若是有的朋友認爲這樣會致使數據冗餘，那麼能夠乾脆去掉原來作聯合主鍵的相關字段就是用一個字段表示，只不過歸併字段時候使用一個分隔符，這樣方便服務層進行業務上的拆分。

　　由上所述，這裏我給出水平拆分主鍵設計的第一個原則：被水平拆分的表的主鍵設計最好使用一個字段表示。

　　若是咱們的主鍵只是表達記錄惟一性的話，那麼水平拆分時候相對要簡單的多，例如在Oracle數據庫裏有一個sequence機制，這其實就是一個自增數的算法，自增機制幾乎全部關係數據庫都有，也是咱們平時最喜歡使用的主鍵字段設計方案，若是咱們要拆分的表，使用了自增字段，同時這個自增字段只是用來表達記錄惟一性，那麼水平拆分時候處理起來就簡單多了，我這裏給出兩個經典方案，方案以下：

　　方案一：自增列都有設定步長的特性，假如咱們打算把一張表只拆分爲兩個物理表，那麼咱們能夠在其中一張表裏把主鍵的自增列的步長設計爲2，起始值爲1，那麼它的自增規律就是1,3,5,7依次類推，另一張物理表的步長咱們也能夠設置爲2，若是起始值爲2，那麼自增規律就是2,4,6,8以此類推，這樣兩張表的主鍵就絕對不會重複了，並且咱們也不用另外作兩張物理表相應的邏輯關聯了。這種方案還有個潛在的好處，那就是步長的大小和水平數據拆分的粒度關聯，也是咱們爲水平拆分的擴容留有餘量，例如咱們把步長設計爲9，那麼理論上水平拆分的物理表能夠擴容到9個。

　　方案二：拆分出的物理表咱們容許它最多存儲多少數據，咱們其實事先經過必定業務技術規則大體估算出來，假如咱們估算一張表咱們最多讓它存儲2億條，那麼咱們能夠這麼設定自增列的規律，第一張物理表自增列從1開始，步長就設爲1，第二種物理表的自增列則從2億開始，步長也設爲1，自增列都作最大值的限制，其餘的依次類推。

　　那麼若是表的主鍵不是使用自增列，而是業務設計的惟一字段，那麼咱們又如何處理主鍵分佈問題了？這種場景很典型，例如交易網站裏必定會有訂單表，流水錶這樣的設計，訂單表裏有訂單號，流水錶裏有流水號，這些編號都是按必定業務規則定義而且保證它的惟一性，那麼前面的自增列的解決方案就無法完成它們作水平拆分的主鍵問題，那麼碰到這個狀況咱們又該如何解決了？咱們仔細回味下數據庫的水平拆分，它其實和分佈式緩存何其的相似，數據庫的主鍵就至關於分佈式緩存裏的鍵值，那麼咱們能夠按照分佈式緩存的方案來設計主鍵的模型，方案以下：

　　方案一：使用整數哈希求餘的算法，字符串若是進行哈希運算會得出一個值，這個值是該字符串的惟一標誌，若是咱們稍微改變下字符串的內容，計算的哈希值確定是不一樣，兩個不一樣的哈希值對應兩個不一樣字符串，一個哈希值有且只對應惟一一個字符串，加密算法裏的MD5，SHA都是使用哈希算法的原理計算出一個惟一標示的哈希值，經過哈希值的匹配能夠判斷數據是否被篡改過。不過大多數哈希算法最後得出的值都是一個字符加數字的組合，這裏我使用整數哈希算法，這樣計算出的哈希值就是一個整數。接下來咱們就要統計下咱們用於作水平拆分的服務器的數量，假如服務器的數量是3個，那麼接着咱們將計算的整數哈希值除以服務器的數量即取模計算，經過獲得的餘數來選擇服務器，該算法的原理圖以下所示：

 

　　方案二：就是方案一的升級版一致性哈希，一致性哈希最大的做用是保證當咱們要擴展物理數據表的數量時候以及物理表集羣中某臺服務器失效時候纔會體現，這個問題我後續文章會詳細討論物理數據庫擴容的問題，所以這裏先不展開討論了。

　　由上所述，咱們發如今數據庫進行水平拆分時候，咱們設定的算法都是經過主鍵惟一性進行的，根據主鍵惟一性設計的特色，最終數據落地於哪一個物理數據庫也是由主鍵的設計原則所決定的，回到上文裏我提到的若是原庫的數據表使用聯合字段設計主鍵，那麼咱們就必須首先合併聯合主鍵字段，而後經過上面的算法來肯定數據的落地規則，雖然不合並一個字段看起來也不是太麻煩，可是在我多年開發裏，把惟一性的字段分割成多個字段，就等於給主鍵增長了維度，字段越多，維度也就越大，到了具體的業務計算了咱們不得不時刻留心這些維度，結果就很容易出錯，我我的認爲若是數據庫已經到了水平拆分階段了，那麼就說明數據庫的存儲的重要性大大加強，爲了讓數據庫的存儲特性變得純粹乾淨，咱們就得盡力避免增長數據庫設計的複雜性，例如去掉外鍵，還有這裏的合併聯合字段爲一個字段，其實爲了下降難度，哪怕作點必要的冗餘也是值得。

　　解決數據庫表的水平拆分後的主鍵惟一性問題有一個更加直接的方案，這也是不少人碰到此類問題很天然想到的方法，那就是把主鍵生成規則作成一個主鍵生成系統，放置在單獨一臺服務器上統一輩子成，每次新增數據主鍵都從這個服務器裏獲取，主鍵生成的算法其實很簡單，不少語言都有計算UUID的功能，UUID是根據所在服務器的相關的硬件信息計算出的全球惟一的標示，可是這裏我並無首先拿出這個方案，由於它相好比我前面的方案缺點太多了，下面我要細數下它的缺點，具體以下：

　　缺點一：把主鍵生成放到外部服務器進行，這樣咱們就不得不經過網絡通訊完成主鍵值的傳遞，而網絡是計算機體系裏效率最低效的方式，所以它會影響數據新增的效率，特別是數據量很大時候，新增操做很頻繁時候，該缺點會被放大不少；

　　缺點二：若是咱們使用UUID算法作主鍵生成的算法，由於UUID是依賴單臺服務器進行，那麼整個水平拆分的物理數據庫集羣，主鍵生成器就變成整個體系的短板，並且是關鍵短板，主鍵生成服務器若是失效，整個系統都會沒法使用，而一張表須要被水平拆分，並且拆分的表是業務表的時候，那麼這張表在整個系統裏的重要度天然很高，它若是作了水平拆分後出現單點故障，這對於整個系統都是致命的。固然有人確定說，既然有單點故障，那麼咱們就作個集羣系統，問題不是解決了嗎？這個想法的確能夠解決我上面闡述的問題，可是我前文講到過，現實的軟件系統開發裏咱們要堅守一個原則那就是有簡單方案儘可能選擇簡單的方案解決問題，引入集羣就是引入了分佈式系統，這樣就爲系統開發增長了開發難度和運維風險，若是咱們上文的方案就能解決咱們的問題，咱們何須自討苦吃作這麼複雜的方案呢？

　　缺點三：使用外部系統生成主鍵使得咱們的水平拆分數據庫的方案增長了狀態性，而我上面提到的方案都是無狀態的，有狀態的系統會相互影響，例如使用外部系統生成主鍵，那麼當數據操做增大時候，必然會形成在主鍵系統上資源競爭的事情發生，若是咱們對主鍵系統上的競爭狀態處理很差，頗有可能形成主鍵系統被死鎖，這也就會產生我前文裏說到的503錯誤，而無狀態的系統是不存在資源競爭和死鎖的問題，這洋就提高了系統的健壯性，無狀態系統另外一個優點就是水平擴展很方便。

　　這裏我列出單獨主鍵生成系統的缺點不是想說明我以爲這種解決方案徹底不可取，這個要看具體的業務場景，根據做者個人經驗尚未找到一個很合適使用單獨主鍵生成器的場景。

　　上文裏我提出的方案還有個特色就是能保證數據在不一樣的物理表裏均勻的分佈，均勻分佈能保證不一樣物理表的負載均衡，這樣就不會產生系統熱點，也不會讓某臺服務器比其餘服務器作的事情少而閒置資源，均勻分配資源能夠有效的利用資源，下降生產的成本提升生產的效率，可是均勻分佈式數據每每會給咱們業務運算帶來不少麻煩。

　　水平拆分數據庫後咱們還要考慮水平擴展問題，例如若是咱們事先使用了3臺服務器完成了水平拆分，若是系統運行到必定階段，該表又遇到存儲瓶頸了，咱們就得水平擴容數據庫，那麼若是咱們的水平拆分方案開始設計的很差，那麼擴容時候就會碰到不少的麻煩。

　　以上問題將是我下篇文章裏進行討論的，今天就寫到這裏，祝你們生活愉快。

 

 

 

 轉自 http://www.cnblogs.com/sharpxiajun/p/4262983.html