https://www.jianshu.com/p/14821fa5f0bd
前言：最近公司要討論分庫分表，正好一起參加了培訓。一般mysql單表數據庫容量達到一定的極限，性能會急劇下降，之前工作的時候已經大佬們高喊幾次了分庫分表，但是最終沒能實現或者落地的方案不佳。在這裏一篇很好的文章指出了當前開源的分庫分表的框架的不足，並介紹了使用TiDb作爲新的分佈式數據庫的各種優點傳送門。
目前的常用的分庫分表概述
一種是中間件代理，例如mycat和sharding-proxy,對於應用是比較透明的，支持的語言也多；第二種是侵入式,也就是數據庫直連，例如sharding-jdbc。sharding-proxy和sharding-jdbc都已經整合到sharding-Sphere裏，中文文檔可以點擊這裏
sharding-sphere作爲分庫分表的實現短板。
sharding-sphere包含三個項目：sharding-jdbc、sharding-proxy和Sharding-Sidecar。如果有興趣大家可一查看demo，裏面包含各種應用場景。我僅僅以後臺人員的角度來看侷限性。
- shrdingkey粘連 例如sharding-jdbc裏面需要指出分庫鍵和分表鍵，如果你的業務很複雜，意味着你要建立很多shrdingkey；即使你認爲這沒有啥，最要命的是你增刪改查都必須帶上這個shrdingkey才能路由到你要去的那張表，這就好比回孃家，還真得左右一隻雞右手一隻鴨，不然孃家不認你。
- 數據冷熱均衡、高可用複雜度很高 一般分表分庫數據，熱點數據我就需要設計非常複雜的算法，提前規劃好幾張庫幾張表；例如購物記錄表，你設計2個庫，每個庫水平切4張表，再爲這些表設計一套均衡的數據分流，但是人員表你最多一個庫兩張表，再爲這衝業務維度設計一套數據均衡。最後，你要爲這些來個主從、讀寫分離保證高可用，...同志，你確定你能行嗎？牛逼的話希望可以給口飯喫。
- 擴容非常困難 如果你已經提前規劃好了幾個庫幾個表，並且爲每個業務表都設計好一套牛逼的算法，保證一百年性能不出問題，並且也給了我一口湯喝，百年之後老闆的兒子要擴容。運維人員需要根據你的算法，再來擴容，4庫變成8個庫，每個庫再來切一下，再來弄個高可用，再來遷移數據。運維黑人問號臉：我去你***%……%%35433454
- sql不支持關聯查詢、分佈式事務複雜度高、一致性差。不過這些都是分佈式都面臨的問題，已閱。
TIDB原理簡介
TIDB.png
- TiDB Server ：解析SQL 請求，最後通過 PD 找到存儲計算所需數據的 TiKV （鍵值對）然後返回。TiDB 是無狀態的，也就是無腦傳話機，本身不存儲任何數據。
- PD Server： TiKV存儲集羣的元信息；對 TiKV 集羣進行調度和負載均衡；分配全局唯一且遞增的事務 ID。他是集羣，集羣是要選舉的，必須是奇數個哦！ PD Server是指揮官，負責調度。
- TiKV Server： 負責存儲數據，基本單元就是Region，也就是一個K-V。多個Region組成一個TiKV 節點，多個節點組成一個GROUP。
TiDB作爲分佈式數據庫的優點
- 對於現有得應用非常透明化。Tidb的原理是解析sql語句，進入自己的key-value存儲單元獲取數據，使得現有得應用可以平滑過渡，掛的是關係型數據庫的皮，做的是NOSQL數據庫的事，我們叫他不是個東...new SQL。他借用了mysql引擎，所以你直接在NAVICAT上就可以直接界面化操作啦。
- 可以非常快捷的伸縮，實現冷熱數據的均衡。例如使用sharding-jdbc，要實現熱點數據的分佈存儲，拋開復雜的分庫分表算法不說，每次擴容對於運維人員非常繁瑣。但是TIDB就不存在啦，只要擴展TiDB Server 節點增加計算能力，擴展TIKV節點增加存儲能力就可以。這是一場戰爭，號角吹響，補兵不行補兵，傳話的不夠加傳話的，指揮官掛了選新的。男人不能說自己不xing.
- 支持分佈式事務，數據強一致性，百億級存儲。根據官網吹牛（shihua）逼(shishuo)說,金融級高可用。
TiDB作爲分佈式數據庫的缺點
- 存儲過程、觸發器、事件、外鍵約束不支持，但是這個是人家謙（chenqie）虛的說法(zuobudao)，分佈式數據庫誰還用這些雞肋玩意兒,特別是觸發器。
-
硬件要求高，不多說的，反正就是高，你想想人家這麼快肯定IO輕鬆不了，人家大神都說了，最好全換成SSD。
image.png
TiDB的安裝
作爲後臺人員，我們就是用最快捷的docker快速安裝搭建TIDB，Tidb官網已經給出了非常完整的文檔，這裏不再詳述。這也是我第一次在簡書寫，畢竟支持MARKDOWN還是很爽的，工作繁忙，下一章我會示例一下docker安裝TIDB快速整合後臺應用的DEMO。