数据库分库分表
- 1. 數(shù)據(jù)庫分庫分表
- 1.1. 前言
- 1.1.1. 名詞解釋
- 1.2. 數(shù)據(jù)庫架構(gòu)演變
- 1.3. 分庫分表前的問題
- 1.3.1. 用戶請求量太大
- 1.3.2. 單庫太大
- 1.3.3. 單表太大
- 1.4. 分庫分表的方式方法
- 1.4.1. 垂直拆分
- 1.4.2. 水平拆分
- 1.5. 分庫分表后面臨的問題
- 1.5.1. 事務支持
- 1.5.2. 多庫結(jié)果集合并（group by，order by）
- 1.5.3. 跨庫join
- 1.6. 分庫分表方案產(chǎn)品
- 1.7. 為什么不建議分庫分表
- 1.8. 參考
- 1.1. 前言
數(shù)據(jù)庫分庫分表
前言
公司最近在搞服務分離，數(shù)據(jù)切分方面的東西，因為單張包裹表的數(shù)據(jù)量實在是太大，并且還在以每天60W的量增長。 之前了解過數(shù)據(jù)庫的分庫分表，讀過幾篇博文，但就只知道個模糊概念， 而且現(xiàn)在回想起來什么都是模模糊糊的。
今天看了一下午的數(shù)據(jù)庫分庫分表，看了很多文章，現(xiàn)在做個總結(jié)，“摘抄”下來。（但更期待后期的實操） 會從以下幾個方面說起： 第一部分：實際網(wǎng)站發(fā)展過程中面臨的問題。 第二部分：有哪幾種切分方式，垂直和水平的區(qū)別和適用面。 第三部分：目前市面有的一些開源產(chǎn)品，技術(shù)，它們的優(yōu)缺點是什么。 第四部分：可能是最重要的，為什么不建議水平分庫分表！？這能讓你能在規(guī)劃前期謹慎的對待，規(guī)避掉切分造成的問題。
名詞解釋
庫：database；表：table；分庫分表：sharding
數(shù)據(jù)庫架構(gòu)演變
剛開始我們只用單機數(shù)據(jù)庫就夠了，隨后面對越來越多的請求，我們將數(shù)據(jù)庫的寫操作和讀操作進行分離， 使用多個從庫副本（Slaver Replication）負責讀，使用主庫（Master）負責寫， 從庫從主庫同步更新數(shù)據(jù)，保持數(shù)據(jù)一致。架構(gòu)上就是數(shù)據(jù)庫主從同步。 從庫可以水平擴展，所以更多的讀請求不成問題。
但是當用戶量級上來后，寫請求越來越多，該怎么辦？加一個Master是不能解決問題的， 因為數(shù)據(jù)要保存一致性，寫操作需要2個master之間同步，相當于是重復了，而且更加復雜。
這時就需要用到分庫分表（sharding），對寫操作進行切分。
分庫分表前的問題
任何問題都是太大或者太小的問題，我們這里面對的數(shù)據(jù)量太大的問題。
用戶請求量太大
因為單服務器TPS，內(nèi)存，IO都是有限的。 解決方法：分散請求到多個服務器上； 其實用戶請求和執(zhí)行一個sql查詢是本質(zhì)是一樣的，都是請求一個資源，只是用戶請求還會經(jīng)過網(wǎng)關(guān)，路由，http服務器等。
單庫太大
單個數(shù)據(jù)庫處理能力有限；單庫所在服務器上磁盤空間不足；單庫上操作的IO瓶頸 解決方法：切分成更多更小的庫
單表太大
CRUD都成問題；索引膨脹，查詢超時 解決方法：切分成多個數(shù)據(jù)集更小的表。
分庫分表的方式方法
一般就是垂直切分和水平切分，這是一種結(jié)果集描述的切分方式，是物理空間上的切分。 我們從面臨的問題，開始解決，闡述： 首先是用戶請求量太大，我們就堆機器搞定（這不是本文重點）。
然后是單個庫太大，這時我們要看是因為表多而導致數(shù)據(jù)多，還是因為單張表里面的數(shù)據(jù)多。 如果是因為表多而數(shù)據(jù)多，使用垂直切分，根據(jù)業(yè)務切分成不同的庫。
如果是因為單張表的數(shù)據(jù)量太大，這時要用水平切分，即把表的數(shù)據(jù)按某種規(guī)則切分成多張表，甚至多個庫上的多張表。?分庫分表的順序應該是先垂直分，后水平分。?因為垂直分更簡單，更符合我們處理現(xiàn)實世界問題的方式。
垂直拆分
垂直分表
也就是“大表拆小表”，基于列字段進行的。一般是表中的字段較多，將不常用的， 數(shù)據(jù)較大，長度較長（比如text類型字段）的拆分到“擴展表“。 一般是針對那種幾百列的大表，也避免查詢時，數(shù)據(jù)量太大造成的“跨頁”問題。
垂直分庫
垂直分庫針對的是一個系統(tǒng)中的不同業(yè)務進行拆分，比如用戶User一個庫，商品Producet一個庫，訂單Order一個庫。 切分后，要放在多個服務器上，而不是一個服務器上。為什么？ 我們想象一下，一個購物網(wǎng)站對外提供服務，會有用戶，商品，訂單等的CRUD。沒拆分之前， 全部都是落到單一的庫上的，這會讓數(shù)據(jù)庫的單庫處理能力成為瓶頸。按垂直分庫后，如果還是放在一個數(shù)據(jù)庫服務器上， 隨著用戶量增大，這會讓單個數(shù)據(jù)庫的處理能力成為瓶頸，還有單個服務器的磁盤空間，內(nèi)存，tps等非常吃緊。 所以我們要拆分到多個服務器上，這樣上面的問題都解決了，以后也不會面對單機資源問題。
數(shù)據(jù)庫業(yè)務層面的拆分，和服務的“治理”，“降級”機制類似，也能對不同業(yè)務的數(shù)據(jù)分別的進行管理，維護，監(jiān)控，擴展等。 數(shù)據(jù)庫往往最容易成為應用系統(tǒng)的瓶頸，而數(shù)據(jù)庫本身屬于“有狀態(tài)”的，相對于Web和應用服務器來講，是比較難實現(xiàn)“橫向擴展”的。 數(shù)據(jù)庫的連接資源比較寶貴且單機處理能力也有限，在高并發(fā)場景下，垂直分庫一定程度上能夠突破IO、連接數(shù)及單機硬件資源的瓶頸。
水平拆分
水平分表
針對數(shù)據(jù)量巨大的單張表（比如訂單表），按照某種規(guī)則（RANGE,HASH取模等），切分到多張表里面去。 但是這些表還是在同一個庫中，所以庫級別的數(shù)據(jù)庫操作還是有IO瓶頸。不建議采用。
水平分庫分表
將單張表的數(shù)據(jù)切分到多個服務器上去，每個服務器具有相應的庫與表，只是表中數(shù)據(jù)集合不同。 水平分庫分表能夠有效的緩解單機和單庫的性能瓶頸和壓力，突破IO、連接數(shù)、硬件資源等的瓶頸。
水平分庫分表切分規(guī)則
RANGE
從0到10000一個表，10001到20000一個表；
HASH取模
一個商場系統(tǒng)，一般都是將用戶，訂單作為主表，然后將和它們相關(guān)的作為附表，這樣不會造成跨庫事務之類的問題。 取用戶id，然后hash取模，分配到不同的數(shù)據(jù)庫上。
地理區(qū)域
比如按照華東，華南，華北這樣來區(qū)分業(yè)務，七牛云應該就是如此。
時間
按照時間切分，就是將6個月前，甚至一年前的數(shù)據(jù)切出去放到另外的一張表，因為隨著時間流逝，這些表的數(shù)據(jù) 被查詢的概率變小，所以沒必要和“熱數(shù)據(jù)”放在一起，這個也是“冷熱數(shù)據(jù)分離”。
分庫分表后面臨的問題
事務支持
分庫分表后，就成了分布式事務了。如果依賴數(shù)據(jù)庫本身的分布式事務管理功能去執(zhí)行事務，將付出高昂的性能代價； 如果由應用程序去協(xié)助控制，形成程序邏輯上的事務，又會造成編程方面的負擔。
多庫結(jié)果集合并（group by，order by）
TODO
跨庫join
TODO 分庫分表后表之間的關(guān)聯(lián)操作將受到限制，我們無法join位于不同分庫的表，也無法join分表粒度不同的表， 結(jié)果原本一次查詢能夠完成的業(yè)務，可能需要多次查詢才能完成。 粗略的解決方法： 全局表：基礎(chǔ)數(shù)據(jù)，所有庫都拷貝一份。 字段冗余：這樣有些字段就不用join去查詢了。 系統(tǒng)層組裝：分別查詢出所有，然后組裝起來，較復雜。
分庫分表方案產(chǎn)品
目前市面上的分庫分表中間件相對較多，其中基于代理方式的有MySQL Proxy和Amoeba， 基于Hibernate框架的是Hibernate Shards，基于jdbc的有當當sharding-jdbc， 基于mybatis的類似maven插件式的有蘑菇街的蘑菇街TSharding， 通過重寫spring的ibatis template類的Cobar Client。
還有一些大公司的開源產(chǎn)品：
為什么不建議分庫分表
請參看一篇我翻譯的stackoverflow上的回答，這個答者功力深厚，鐵定的老司機：?MySQL分庫分表方案
參考
MySQL Sharding-slideshare
數(shù)據(jù)庫分庫分表方式
數(shù)據(jù)庫Sharding的基本思想和切分策略
來源:http://www.cnblogs.com/3gods/p/7406213.html
總結(jié)
- 上一篇： HARVEST臻仕家居旗下有什么知名的品
- 下一篇： mysql长连接与短连接