這篇文章主要介紹“怎么理解MySQL垂直和水平切分”，在日常操作中，相信很多人在怎么理解MySQL垂直和水平切分問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么理解MySQL垂直和水平切分”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

replication的限制:一旦數(shù)據(jù)庫過于龐大，尤其是當(dāng)寫入過于頻繁，很難由一臺主機支撐的時候，我們還是會面臨到擴展瓶頸。數(shù)據(jù)切分(sharding):通過某種特定的條件，將我們存放在同一個數(shù)據(jù)庫中的數(shù)據(jù)分散存放到多個數(shù)據(jù)庫（主機）上面，以達到分散單臺設(shè)備負載的效果。。數(shù)據(jù)的切分同時還可以提高系統(tǒng)的總體可用性，因為單臺設(shè)備Crash之后，只有總體數(shù)據(jù)的某部分不可用，而不是所有的數(shù)據(jù)。

數(shù)據(jù)的切分（Sharding）模式

一種是按照不同的表（或者Schema）來切分到不同的數(shù)據(jù)庫（主機）之上，這種切可以稱之為數(shù)據(jù)的垂直（縱向）切分；另外一種則是根據(jù)表中的數(shù)據(jù)的邏輯關(guān)系，將同一個表中的數(shù)據(jù)按照某種條件拆分到多臺數(shù)據(jù)庫（主機）上面，這種切分稱之為數(shù)據(jù)的水平（橫向）切分。

垂直切分:

一個架構(gòu)設(shè)計較好的應(yīng)用系統(tǒng)，其總體功能肯定是由很多個功能模塊所組成的，而每一個功能模塊所需要的數(shù)據(jù)對應(yīng)到數(shù)據(jù)庫中就是一個或者多個表。而在架構(gòu)設(shè)計中，各個功能模塊相互之間的交互點越統(tǒng)一越少，系統(tǒng)的耦合度就越低，系統(tǒng)各個模塊的維護性以及擴展性也就越好。這樣的系統(tǒng)，實現(xiàn)數(shù)據(jù)的垂直切分也就越容易。

一般來說，如果是一個負載相對不是很大的系統(tǒng)，而且表關(guān)聯(lián)又非常的頻繁，那可能數(shù)據(jù)庫讓步，將幾個相關(guān)模塊合并在一起減少應(yīng)用程序的工作的方案可以減少較多的工作量，這是一個可行的方案。一個垂直拆分的例子:

1.用戶模塊表：user,user_profile,user_group,user_photo_album
2.群組討論表：groups,group_message,group_message_content,top_message
3.相冊相關(guān)表：photo,photo_album,photo_album_relation,photo_comment
4.事件信息表：event

群組討論模塊和用戶模塊之間主要存在通過用戶或者是群組關(guān)系來進行關(guān)聯(lián)。一般關(guān)聯(lián)的時候都會是通過用戶的id或者nick_name以及group的id來進行關(guān)聯(lián)，通過模塊之間的接口實現(xiàn)不會帶來太多麻煩；
相冊模塊僅僅與用戶模塊存在通過用戶的關(guān)聯(lián)。這兩個模塊之間的關(guān)聯(lián)基本就有通過用戶id關(guān)聯(lián)的內(nèi)容，簡單清晰，接口明確；
事件模塊與各個模塊可能都有關(guān)聯(lián)，但是都只關(guān)注其各個模塊中對象的ID信息，同樣可以做到很容易分拆。

垂直切分的優(yōu)點

數(shù)據(jù)庫的拆分簡單明了，拆分規(guī)則明確；
應(yīng)用程序模塊清晰明確，整合容易；
數(shù)據(jù)維護方便易行，容易定位；

垂直切分的缺點

部分表關(guān)聯(lián)無法在數(shù)據(jù)庫級別完成，需要在程序中完成；
對于訪問極其頻繁且數(shù)據(jù)量超大的表仍然存在性能瓶頸，不一定能滿足要求；
事務(wù)處理相對更為復(fù)雜；
切分達到一定程度之后，擴展性會遇到限制；
過讀切分可能會帶來系統(tǒng)過渡復(fù)雜而難以維護。

水平切分

將某個訪問極其頻繁的表再按照某個字段的某種規(guī)則來分散到多個表之中，每個表中包含一部分數(shù)據(jù)。

對于上面的例子:所有數(shù)據(jù)都是和用戶關(guān)聯(lián)的，那么我們就可以根據(jù)用戶來進行水平拆分，將不同用戶的數(shù)據(jù)切分到不同的數(shù)據(jù)庫中。

現(xiàn)在互聯(lián)網(wǎng)非?；鸨腤eb2.0類型的網(wǎng)站，基本上大部分數(shù)據(jù)都能夠通過會員用戶信息關(guān)聯(lián)上，可能很多核心表都非常適合通過會員ID來進行數(shù)據(jù)的水平切分。而像論壇社區(qū)討論系統(tǒng)，就更容易切分了，非常容易按照論壇編號來進行數(shù)據(jù)的水平切分。切分之后基本上不會出現(xiàn)各個庫之間的交互。

水平切分的優(yōu)點

表關(guān)聯(lián)基本能夠在數(shù)據(jù)庫端全部完成；
不會存在某些超大型數(shù)據(jù)量和高負載的表遇到瓶頸的問題；
應(yīng)用程序端整體架構(gòu)改動相對較少；
事務(wù)處理相對簡單；
只要切分規(guī)則能夠定義好，基本上較難遇到擴展性限制；

水平切分的缺點

切分規(guī)則相對更為復(fù)雜，很難抽象出一個能夠滿足整個數(shù)據(jù)庫的切分規(guī)則；
后期數(shù)據(jù)的維護難度有所增加，人為手工定位數(shù)據(jù)更困難；
應(yīng)用系統(tǒng)各模塊耦合度較高，可能會對后面數(shù)據(jù)的遷移拆分造成一定的困難。

兩種切分結(jié)合用:

一般來說，我們數(shù)據(jù)庫中的所有表很難通過某一個（或少數(shù)幾個）字段全部關(guān)聯(lián)起來，所以很難簡單的僅僅通過數(shù)據(jù)的水平切分來解決所有問題。而垂直切分也只能解決部分問題，對于那些負載非常高的系統(tǒng)，即使僅僅只是單個表都無法通過單臺數(shù)據(jù)庫主機來承擔(dān)其負載。我們必須結(jié)合“垂直”和“水平”兩種切分方式同時使用

每一個應(yīng)用系統(tǒng)的負載都是一步一步增長上來的，在開始遇到性能瓶頸的時候，大多數(shù)架構(gòu)師和DBA都會選擇先進行數(shù)據(jù)的垂直拆分，因為這樣的成本最先，最符合這個時期所追求的大投入產(chǎn)出比。然而，隨著業(yè)務(wù)的不斷擴張，系統(tǒng)負載的持續(xù)增長，在系統(tǒng)穩(wěn)定一段時期之后，經(jīng)過了垂直拆分之后的數(shù)據(jù)庫集群可能又再一次不堪重負，遇到了性能瓶頸。

如果我們再一次像最開始那樣繼續(xù)細分模塊，進行數(shù)據(jù)的垂直切分，那我們可能在不久的將來，又會遇到現(xiàn)在所面對的同樣的問題。而且隨著模塊的不斷的細化，應(yīng)用系統(tǒng)的架構(gòu)也會越來越復(fù)雜，整個系統(tǒng)很可能會出現(xiàn)失控的局面。

這時候我們就必須要通過數(shù)據(jù)的水平切分的優(yōu)勢，來解決這里所遇到的問題。而且，我們完全不必要在使用數(shù)據(jù)水平切分的時候，推倒之前進行數(shù)據(jù)垂直切分的成果，而是在其基礎(chǔ)上利用水平切分的優(yōu)勢來避開垂直切分的弊端，解決系統(tǒng)復(fù)雜性不斷擴大的問題。而水平拆分的弊端（規(guī)則難以統(tǒng)一）也已經(jīng)被之前的垂直切分解決掉了，讓水平拆分可以進行的得心應(yīng)手。

示例數(shù)據(jù)庫:

假設(shè)在最開始，我們進行了數(shù)據(jù)的垂直切分，然而隨著業(yè)務(wù)的不斷增長，數(shù)據(jù)庫系統(tǒng)遇到了瓶頸，我們選擇重構(gòu)數(shù)據(jù)庫集群的架構(gòu)。如何重構(gòu)？考慮到之前已經(jīng)做好了數(shù)據(jù)的垂直切分，而且模塊結(jié)構(gòu)清晰明確。而業(yè)務(wù)增長的勢頭越來越猛，即使現(xiàn)在進一步再次拆分模塊，也堅持不了太久。

==>選擇了在垂直切分的基礎(chǔ)上再進行水平拆分。

==>在經(jīng)歷過垂直拆分后的各個數(shù)據(jù)庫集群中的每一個都只有一個功能模塊，而每個功能模塊中的所有表基本上都會與某個字段進行關(guān)聯(lián)。如用戶模塊全部都可以通過用戶ID進行切分，群組討論模塊則都通過群組ID來切分，相冊模塊則根據(jù)相冊ID來進切分，最后的事件通知信息表考慮到數(shù)據(jù)的時限性（僅僅只會訪問最近某個事件段的信息），則考慮按時間來切分。

數(shù)據(jù)切分以及整合方案.

數(shù)據(jù)庫中的數(shù)據(jù)在經(jīng)過垂直和（或）水平切分被存放在不同的數(shù)據(jù)庫主機之后，應(yīng)用系統(tǒng)面臨的大問題就是如何來讓這些數(shù)據(jù)源得到較好的整合，其中存在兩種解決思路：

在每個應(yīng)用程序模塊中配置管理自己需要的一個（或者多個）數(shù)據(jù)源，直接訪問各個數(shù)據(jù)庫，在模塊內(nèi)完成數(shù)據(jù)的整合；
通過中間代理層來統(tǒng)一管理所有的數(shù)據(jù)源，后端數(shù)據(jù)庫集群對前端應(yīng)用程序透明；

第二種方案,雖然短期內(nèi)需要付出的成本可能會相對更大一些，但是對整個系統(tǒng)的擴展性來說，是非常有幫助的。針對第二種方案，可以選擇的方法和思路有：

1.利用MySQLProxy 實現(xiàn)數(shù)據(jù)切分及整合.

可用來監(jiān)視、分析或者傳輸他們之間的通訊信息。他的靈活性允許你大限度的使用它，目前具備的功能主要有連接路由，Query分析，Query過濾和修改，負載均衡，以及基本的HA機制等。MySQLProxy 本身并不具有上述所有的這些功能，而是提供了實現(xiàn)上述功能的基礎(chǔ)。要實現(xiàn)這些功能，還需要通過我們自行編寫LUA腳本來實現(xiàn)。

原理:MySQLProxy 實際上是在客戶端請求與MySQLServer 之間建立了一個連接池。所有客戶端請求都是發(fā)向MySQLProxy，然后經(jīng)由MySQLProxy 進行相應(yīng)的分析，判斷出是讀操作還是寫操作，分發(fā)至對應(yīng)的MySQLServer 上。對于多節(jié)點Slave集群，也可以起做到負載均衡的效果。

2.利用Amoeba實現(xiàn)數(shù)據(jù)切分及整合

Amoeba是一個基于Java開發(fā)的，專注于解決分布式數(shù)據(jù)庫數(shù)據(jù)源整合Proxy程序的開源框架，Amoeba已經(jīng)具有Query路由，Query過濾，讀寫分離，負載均衡以及HA機制等相關(guān)內(nèi)容。Amoeba主要解決的以下幾個問題：

數(shù)據(jù)切分后復(fù)雜數(shù)據(jù)源整合；
提供數(shù)據(jù)切分規(guī)則并降低數(shù)據(jù)切分規(guī)則給數(shù)據(jù)庫帶來的影響；
降低數(shù)據(jù)庫與客戶端的連接數(shù)；
讀寫分離路由；

AmoebaFor MySQL 主要是專門針對MySQL數(shù)據(jù)庫的解決方案，前端應(yīng)用程序請求的協(xié)議以及后端連接的數(shù)據(jù)源數(shù)據(jù)庫都必須是MySQL。對于客戶端的任何應(yīng)用程序來說，AmoebaForMySQL 和一個MySQL數(shù)據(jù)庫沒有什么區(qū)別，任何使用MySQL協(xié)議的客戶端請求，都可以被AmoebaFor MySQL 解析并進行相應(yīng)的處理。

Proxy程序常用的功能如讀寫分離，負載均衡等配置都在amoeba.xml中進行。Amoeba已經(jīng)支持了實現(xiàn)數(shù)據(jù)的垂直切分和水平切分的自動路由，路由規(guī)則可以在rule.xml進行設(shè)置。

3.利用HiveDB實現(xiàn)數(shù)據(jù)切分及整合

HiveDB同樣是一個基于Java針對MySQL數(shù)據(jù)庫的提供數(shù)據(jù)切分及整合的開源框架，只是目前的HiveDB僅僅支持數(shù)據(jù)的水平切分。主要解決大數(shù)據(jù)量下數(shù)據(jù)庫的擴展性及數(shù)據(jù)的高性能訪問問題，同時支持數(shù)據(jù)的冗余及基本的HA機制。

HiveDB的實現(xiàn)機制與MySQLProxy 和Amoeba有一定的差異，他并不是借助MySQL的Replication功能來實現(xiàn)數(shù)據(jù)的冗余，而是自行實現(xiàn)了數(shù)據(jù)冗余機制，而其底層主要是基于HibernateShards 來實現(xiàn)的數(shù)據(jù)切分工作。數(shù)據(jù)切分與整合中可能存在的問題

引入分布式事務(wù)的問題?

一旦數(shù)據(jù)進行切分被分別存放在多個MySQLServer中之后，不管我們的切分規(guī)則設(shè)計的多么的完美（實際上并不存在完美的切分規(guī)則），都可能造成之前的某些事務(wù)所涉及到的數(shù)據(jù)已經(jīng)不在同一個MySQLServer 中了。

==>將一個跨多個數(shù)據(jù)庫的分布式事務(wù)分拆成多個僅處于單個數(shù)據(jù)庫上面的小事務(wù)，并通過應(yīng)用程序來總控各個小事務(wù)。

跨節(jié)點Join的問題?

==>先從一個節(jié)點取出數(shù)據(jù),然后根據(jù)這些數(shù)據(jù),再到另一個表中取數(shù)據(jù).
==>使用Federated存儲引擎,問題是:乎如果遠端的表結(jié)構(gòu)發(fā)生了變更，本地的表定義信息是不會跟著發(fā)生相應(yīng)變化的。

跨節(jié)點合并排序分頁問題?

==>Join本身涉及到的多個表之間的數(shù)據(jù)讀取一般都會存在一個順序關(guān)系。但是排序分頁就不太一樣了，排序分頁的數(shù)據(jù)源基本上可以說是一個表（或者一個結(jié)果集），本身并不存在一個順序關(guān)系，所以在從多個數(shù)據(jù)源取數(shù)據(jù)的過程是完全可以并行的。這樣，排序分頁數(shù)據(jù)的取數(shù)效率我們可以做的比跨庫Join更高，所以帶來的性能損失相對的要更小。

到此，關(guān)于“怎么理解MySQL垂直和水平切分”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
新聞標(biāo)題：怎么理解MySQL垂直和水平切分-創(chuàng)新互聯(lián)
URL分享：http://weahome.cn/article/dhjsod.html