作好分庫分表其實很難之二

爲何分

在正式開始以前，菜菜仍是要強調一點，你的數據表是否應該分，須要綜合考慮不少因素，好比業務的數據量是否到達了必需要切分的數量級，是否能夠有其餘方案來解決當前問題？我不止一次的見過，有的leader在不考慮綜合狀況下，盲目的進行表拆分業務，致使的狀況就是你們不停的加班，連續幾周996，難道leader你不掉頭髮嗎？還有的架構師在一個小小業務初期就進行表拆分，你們爲了配合你也是快馬加鞭的加班趕進度，上線以後反而發現業務數據量很小，可是代碼上卻被分表策略牽制了太多。拆表引發的問題在特定的場景下，有時候代價真的很大。
數據庫表的拆分解決的問題主要是存儲和性能問題，mysql在單表數據量達到必定量級後，性能會急劇降低，相比較於sqlserver和Oracle這些收費DB來講，mysql在某些方面仍是處於弱勢，可是表的拆分這個策略卻適用於幾乎全部的關係型數據庫。

數據庫進行表拆分不要太盲目

分表策略

表的拆分和數據庫的拆分有類似之處，可是拆分的規則也有不一樣。如下的拆分規則針對的是拆分一個表。

橫向切分

橫向切分是諸多業務中最經常使用的切分方式，本質是把一個表中的數據行按照規則分散到多個表中，好比最多見的按照ID範圍，按照業務主鍵的哈希值等。至於表數據到達什麼數量級以後進行切分，這和表中存的數據格式有關，好比一個表只有幾列的int字段確定要比幾列text類型的表存儲的極限要高。姑且認爲這個極限是1000萬吧。可是做爲一個系統的負責人或者架構師來講，當表的數據量級到達千萬級別要引發重視，由於這是一個系統性能瓶頸的隱患。

相對於數據表的橫向切分，在符合業務優化的場景下我更傾向於作表分區，按照規則把不一樣的分區分配到不一樣的物理磁盤，這樣的話，業務裏的sql語句幾乎能夠不用改動。我司的一個sqlserver數據庫，某個業務的表作了表分區以後，已經到達幾十億級別的數據量，可是查詢和插入速度仍是能知足業務的需求（優化一個系統仍是要花精力優化業務層面）。

垂直切分

說到垂直拆分，表也能夠按照業務來拆分，好比一個數據庫中有用戶的信息，根據業務能夠劃分爲基礎信息和擴展信息，若是對業務有利，徹底能夠拆分爲基礎信息表和擴展信息表。固然也能夠按照別的規則來拆，好比把訪問頻繁的信息拆分紅一個表，其餘不頻繁的信息拆分紅一個表，具體的拆分規則仍是要看當時要解決的問題是什麼。垂直拆分可能會引入必定複雜性，好比原來查詢一個用戶的基礎信息和擴展信息能夠一次性查詢出結果，分表以後須要進行Join操做或者查詢兩次才能查詢出結果。

分表代價

1. 數據表垂直切分以後，原來一次查詢有可能會變爲連表的join查詢，在必定程度上會有性能損失。
2. 數據表橫向切分須要必定的規則，經常使用的主要有兩種規則：範圍切分和哈希值切分。範圍切分是指按照某個字段的範圍來切分，好比用戶表按照用戶ID來切分，id爲1到10萬的位於User表1中，100001到200000萬的位於User2中，這樣切分的優點是，能夠無限的擴容下去，不用考慮數據遷移的問題，劣勢就是新表和舊錶數據分佈不均勻，並且分表的範圍選取有必定難度，範圍過小會致使表太多，太大會致使問題根本上沒有解決的困惑。另一種分表策略就是把某一列按照哈希值來路由到不一樣的表中，一樣以用戶ID爲例，假如咱們一開始就規劃了10個數據庫表，路由算法能夠簡單地用 user_id %10的值來表示數據所屬的數據庫表編號，ID爲985的用戶放到編號爲 5的子表中，ID爲10086的用戶放到編號爲 6 的字表中。這種切分規則的優點是每一個表的數據分佈比較均勻，可是後期擴容會設計到部分數據的遷移工做。
3. 表拆分以後若是遇到有order by 的操做，數據庫就無能爲力了，只能由業務代碼或者數據庫中間件來完成了。
4. 當有搜索的業務需求的時候，sql語句只能是Join多個表來進行連表查詢了，相似的還有統計的需求，例如count的統計操做。

你在業務中進行過表拆分嗎？

更多精彩文章

• 分佈式大併發系列
• 架構設計系列
• 趣學算法和數據結構系列
• 設計模式系列