資料庫水平垂直拆分

㈠ 垂直切分和水平切分經常一起使用嗎

1. 為什麼要拆分資料庫？
單體項目在構建之初，資料庫的負載和數據量都不大，所以不需要對資料庫做拆分，小型財務系統、文書系統、ERP系統、OA系統，用一個MySQL資料庫實例基本就夠用了。

就像《淘寶技術這十年》裡面說到的，電商業務的數據量增長飛快，所以最開始的PHP+MySQL的架構已經不能滿足實際要求了，於是淘寶想到的第一個辦法就是把MySQL替換成Oracle。但是沒過了多久，在08年前後，單節點的Oracle資料庫也不好用了，於是淘寶終於告別了單節點資料庫，開始拆分資料庫。從一個節點，變成多個節點。

拆分資料庫是有講究的，比如說拆分方法有兩種：垂直切分和水平切分。那你是先水平切分還是垂直切分呢？順序無所謂？不，順序有所為，次序絕對不能錯：先水平切分，然後垂直切分。

2. 什麼是垂直切分？
垂直切分是根據業務來拆分資料庫，同一類業務的數據表拆分到一個獨立的資料庫，另一類的數據表拆分到其他資料庫。

比如說一個新零售的電商資料庫，我們可以把跟商品相關的數據表拆分成一個資料庫，然後在這些數據表的基礎之上，構建出商品系統。比如用JAVA或者PHP語言，創建出一個商城系統。然後把跟進銷存相關的數據表拆分到另外一個資料庫上，再用程序構建出倉庫系統。

垂直切分解決了什麼問題

垂直切分可以降低單節點資料庫的負載。原來所有數據表都放在一個資料庫節點上，無疑所有的讀寫請求也都發到這個MySQL上面，所以資料庫的負載太高。如果把一個節點的資料庫拆分成多個MySQL資料庫，這樣就可以有效的降低每個MySQL資料庫的負載。

垂直切分不能解決什麼問題

垂直切分不能解決的是縮表，比如說商品表無論劃分給哪個資料庫節點，商品表的記錄還是那麼多，不管你把資料庫垂直拆分的有多細致，每個數據表裡面的數據量是沒有變化的。

MySQL單表記錄超過2000萬，讀寫性能會下降的很快，因此說垂直切分並不能起到縮表的效果。

3. 什麼是水平切分？
水平切分是按照某個欄位的某種規則，把數據切分到多張數據表。一張數據表化整為零，拆分成多張數據表，這樣就可以起到縮表的效果了。

很多人，都會水平切分存在誤解，以為水平切分出來的數據表必須保存在不同的MySQL節點上。其實水平切分出來的數據表也可以保存在一個MySQL節點上面。不是水平切分一定需要多個MySQL節點。為什麼這么說呢？

許多人不知道MySQL自帶一種數據分區的技術，可以把一張表的數據，按照特殊規則，切分存儲在不同的目錄下。如果我們給Linux主機掛載了多塊硬碟，我們完全可以利用MySQL分區技術，把一張表的數據切分存儲在多個硬碟上。這樣就由原來一塊硬碟有限的IO能力，升級成了多個磁碟增強型的IO。如果你感興趣數據分區的具體效果，可以看《MySQL資料庫集群》這門實戰課。

水平切分的用途

水平切分可以把數據切分到多張數據表，可以起到縮表的作用。

但是也不是所有的數據表都要做水平切分。數據量較大的數據表才需要做數據切分，比如說電商系統中的，用戶表、商品表、產品表、地址表、訂單表等等。有些數據表就不需要切分，因為數據量不多，比如說品牌表、供貨商表、倉庫表，這些都是不需要切分的。

水平切分的缺點

不同數據表的切分規則並不一致，要根據實際業務來確定。所以我們在選擇資料庫中間件產品的時候，就要選擇切分規則豐富的產品。常見的資料庫中間件有：MyCat、Atlas、ProxySQL等等。有些人覺得MyCat是Java語言開發的，就懷疑MyCat運行效率。其實資料庫中間件的作用相當於SQL語句的路由器。你家路由器硬體配置不怎麼高，但是不影響你享用百兆寬頻。MyCat也是一個道理，它僅僅是起到SQL語句轉發的作用，並不會實際執行SQL語句。我推薦使用MyCat最主要的原因是它自帶了非常多的數據切分規則，我們可以按照主鍵求模切分數據，可以按照主鍵范圍切分數據，還可以按照日期切分數據等等。因此說，為了滿足業務的需要，MyCat目前來說算是非常不錯的中間件產品。

水平切分的另一個缺點就是擴容比較麻煩，日積月累，分片遲早有不夠用的時候。這時候不是首先選擇增加新的集群分片。因為一個MySQL分片，需要4~8個MySQL節點（最小規模），增加一個分片的投入成本是很高的。所以正確的做法是做冷熱數據分離，定期對分片中的數據歸檔。把過期的業務數據，從分片中轉移到歸檔庫。目前來說數據壓縮比最高的MySQL引擎是TokuDB，而且帶著事物的寫入速度是InnoDB引擎的6-14倍。用TokuDB作為歸檔資料庫最適合不過。

4. 為什麼先做水平切分，後作垂直切分？
隨著數據量的增加，最先應該做的是數據分片，利用多塊硬碟來增大數據IO能力和存儲空間，這么做的成本是最低的。幾塊硬碟的錢就能收獲不錯的IO性能。

進入到下一個階段，數據量繼續增大，這時候我們應該把數據切分到多個MySQL節點上，用MyCat管理數據切分。當然還要做數據的讀寫分離等等，這里不展開討論。在後台做水平切分的同時，業務系統也可以引入負載均衡、分布式架構等等。理論上，使用了冷熱數據分離之後，水平切分這種方式可以繼續維持很長一段時間，數據量再大也不怕，定期歸檔就好了。

資料庫到了水平切分的階段，數據量的增加已經不是更改架構設計的主要原因了。反而這個階段業務系統承受不住了，如果再不對系統做模塊拆分，業務系統也撐不下去了，所以按照模塊和業務，把一個系統拆分成若乾子系統。若乾子系統之間，數據相對獨立。比如淘寶不會跟支付支付寶分享全部數據，共享同一套數據表，這也影響各自業務的發展。所以就要弄垂直切分了，把數據表歸類，拆分成若干個資料庫系統。

講到這里，你仔細想想。如果過早的對資料庫做了垂直切分，勢必要重新構建若干獨立的業務系統，工作量太巨大。水平切分並不需要業務系統做大幅度的修改，因此說應該先從水平切分開始做。

㈡ 關於資料庫的水平分割和垂直分割的幾點介紹

水平切分估計是指按照時間切分，垂直切分是指按照設備ID切分，這樣切分後，設備的狀態日誌會以記錄的形式存儲在不同的數據文件中，資料庫對這些文件的訪問可以通過設備ID和時間快速地查找到。而且應用中只是存儲日誌數據，不需要進行頻繁的實時查詢和統計，所以基本上資料庫的任務就是接收數據，寫入到文件中，文件對應的分片滿了就再創建新的分片文件。這樣整體的性能沒有任何變化，系統的負載也是維持在一個常量的水平。
如果要對日誌進行統計和分析，則會隨著日誌數量增加，性能顯著下降，但這里沒有這樣的需求，即使有，也是用另外一組離線分析伺服器進行處理。

㈢ 資料庫垂直分表和水平分別到底什麼意思

垂直分表，指的是把主鍵欄位拿出來，分的兩個表都有，然後原表其他欄位根據實際情況，例如查詢頻率，放兩個表中。
水平分表相當於數據存儲拆開，建多個表，每個表欄位完全一樣，存放不同數據，例如按照月份存放

㈣ 整個資料庫的dmp文件能拆分出表嗎

可以。
數據的切分（Sharding）根據其切分規則的類型，可以分為兩種切分模式。一種是按照不同的表（或Schema）來切分到不同的資料庫（主機）之上，這種切可以稱之為數據的垂直（縱向）切分，另外一種則是根據表中的數據的邏輯關系，將同一個表中的數據按照某種條件拆分到多台資料庫（主機）上面，這種切分稱之為數據的水平（橫向）切分。垂直切分一個資料庫由很多表的構成，每個表對應著不同的業務，垂直切分是指按照業務將表進行分類，分布到不同的資料庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面， 垂直切分的優缺點介紹：
優點：拆分後業務清晰，拆分規則明確。系統之間整合或擴展容易。數據維護簡單。
缺點：部分業務表無法join，只能通過介面方式解決，提高了系統復雜度。受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高。事務處理復雜。由於垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過於龐大，存在單庫讀寫與存儲瓶頸，所以就需要水平拆分來做解決。水平切分相對於垂直拆分，水平拆分不是將表做分類，而是按照某個欄位的某種規則來分散到多個庫之中，每個表中包含一部分數據。簡單來說，我們可以將數據的水平切分理解為是按照數據行的切分，就是將表中的某些行切分到一個資料庫，而另外的某些行又切分到其他的資料庫中，水平切分的優缺點介紹：拆分規則抽象好，join操作基本可以資料庫做。
不存在單庫大數據，高並發的性能瓶頸。應用端改造較少。提高了系統的穩定性跟負載能力。拆分規則難以抽象。分片事務一致性難以解決。數據多次擴展難度跟維護量極大。跨庫join性能較差。垂直切分和水平切分共同的特點和缺點有：引入分布式事務的問題。跨節點Join的問題。跨節點合並排序分頁問題。多數據源管理問題。

㈤ 資料庫水平分庫和垂直分庫有什麼區別

常見的分庫方式有水平性和垂直性。一般來說，就是按照用戶屬性（地市或者ID的hash）進行分庫，或者按照業務功能塊進行分庫。
水平分庫方式主要根據用戶屬性（如地市）拆分物理資料庫。一種常見的方式是將全省劃分為個大區。
垂直分庫方式：根據業務維度和數據的訪問量等，進行數據的分離，剝離為多個資料庫。例如，將一些公用的配置信息存儲到一個資料庫中進行單獨維護。

㈥ 資料庫水平拆分和垂直拆分 怎麼實現

垂直拆分

垂直拆分是指數據表列的拆分，把一張列比較多的表拆分為多張表

通常我們按以下原則進行垂直拆分:

把不常用的欄位單獨放在一張表;
把text，blob等大欄位拆分出來放在附表中;
經常組合查詢的列放在一張表中;垂直拆分更多時候就應該在數據表設計之初就執行的步驟，然後查詢的時候用join關鍵起來即可;
水平拆分

水平拆分是指數據錶行的拆分，表的行數超過200萬行時，就會變慢，這時可以把一張的表的數據拆成多張表來存放。

水平拆分的一些技巧
1. 拆分原則
通常情況下，我們使用取模的方式來進行表的拆分;比如一張有400W的用戶表users，為提高其查詢效率我們把其分成4張表

users1，users2，users3，users4
通過用ID取模的方法把數據分散到四張表內Id%4+1 = [1,2,3,4]
這里是個小哈希，然後查詢,更新,刪除也是通過取模的方法來查詢

$_GET['id'] = 17,
17%4 + 1 = 2,
$tableName = 'users'.'2'
Select * from users2 where id = 17;
在insert時還需要一張臨時表uid_temp來提供自增的ID,該表的唯一用處就是提供自增的ID;

insert into uid_temp values(null);
得到自增的ID後,又通過取模法進行分表插入;
注意,進行水平拆分後的表,欄位的列和類型和原表應該是相同的,但是要記得去掉auto_increment自增長

另外
部分業務邏輯也可以通過地區，年份等欄位來進行歸檔拆分;
進行拆分後的表，只能滿足部分查詢的高效查詢需求，這時我們就要在產品策劃上，從界面上約束用戶查詢行為。比如我們是按年來進行歸檔拆分的,這個時候在頁面設計上就約束用戶必須要先選擇年,然後才能進行查詢;
在做分析或者統計時，由於是自己人的需求,多點等待其實是沒關系的,並且並發很低,這個時候可以用union把所有表都組合成一張視圖來進行查詢,然後再進行查詢;

Create view users as select from users1 union select from users2 union.........