怎么理解MySQL垂直和水平切分

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

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

數據的切分（Sharding）模式

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

垂直切分:

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

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

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

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

垂直切分的優點

數據庫的拆分簡單明了，拆分規則明確；
應用程序模塊清晰明確，整合容易；
數據維護方便易行，容易定位；

垂直切分的缺點

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

水平切分

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

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

現在互聯網非常火爆的Web2.0類型的網站，基本上大部分數據都能夠通過會員用戶信息關聯上，可能很多核心表都非常適合通過會員ID來進行數據的水平切分。而像論壇社區討論系統，就更容易切分了，非常容易按照論壇編號來進行數據的水平切分。切分之后基本上不會出現各個庫之間的交互。

水平切分的優點

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

水平切分的缺點

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

兩種切分結合用:

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

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

如果我們再一次像最開始那樣繼續細分模塊，進行數據的垂直切分，那我們可能在不久的將來，又會遇到現在所面對的同樣的問題。而且隨著模塊的不斷的細化，應用系統的架構也會越來越復雜，整個系統很可能會出現失控的局面。

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

示例數據庫:

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

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

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

數據切分以及整合方案.

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

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

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

1.利用MySQLProxy 實現數據切分及整合.

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

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

2.利用Amoeba實現數據切分及整合

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

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

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

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

3.利用HiveDB實現數據切分及整合

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

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

引入分布式事務的問題?

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

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

跨節點Join的問題?

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

跨節點合并排序分頁問題?

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

到此，關于“怎么理解MySQL垂直和水平切分”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！