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

我們已經(jīng)非常清晰了通過數(shù)據(jù)庫的數(shù)據(jù)切分能夠極大的提高系統(tǒng)的擴展性逞刷，可是數(shù)據(jù)庫中的數(shù)據(jù)在經(jīng)過垂直和（或）水平切分被存放在不同的數(shù)據(jù)庫主機之后，應用系統(tǒng)面臨的最大問題就是怎樣來讓這些數(shù)據(jù)源得到較好的整合侦镇。

數(shù)據(jù)的整合非常難依靠數(shù)據(jù)庫本身來達到這個效果，盡管MySQL存在Federated存儲引擎，能夠解決部分相似的問題叶组。可是在實際應用場景中卻非常難較好的運用历造。那我們該怎樣來整合這些分散在各個MySQL主機上面的數(shù)據(jù)源呢甩十？

總的來說，存在兩種解決思路：

1. 在每一個應用程序模塊中配置管理自己須要的一個（或者多個）數(shù)據(jù)源吭产。直接訪問各個數(shù)據(jù)庫侣监，在模塊內(nèi)完畢數(shù)據(jù)的整合；
2. 通過中間代理層來統(tǒng)一管理全部的數(shù)據(jù)源臣淤。后端數(shù)據(jù)庫集群對前端應用程序透明橄霉；

可能90%以上的人在面對上面這兩種解決思路的時候都會傾向于選擇第二種，尤其是系統(tǒng)不斷變得龐大復雜的時候邑蒋，盡管短期內(nèi)須要付出的成本可能會相對更大一些姓蜂，可是對整個系統(tǒng)的擴展性來說按厘，是非常有幫助的。所以钱慢，對于第一種解決思路我這里就不準備過多的分析刻剥，以下我重點分析一下在另外一種解決思路中的一些解決方式。

自行開發(fā)中間代理層

通過自行開發(fā)中間代理層能夠最大程度的應對自身應用的特點滩字，最大化的定制非常多個性化需求造虏，在面對變化的時候也能夠靈活的應對。當然麦箍，選擇自行開發(fā)享受讓個性化定制最大化的樂趣的同一時候漓藕，自然也須要投入很多其它的成本來進行前期研發(fā)以及后期的持續(xù)升級改進工作，并且本身的技術(shù)門檻可能也比簡單的Web應用要更高一些挟裂。

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

基于MySQLProxy自行編寫LUA腳本實現(xiàn)數(shù)據(jù)切分相關代理功能享钞。

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

Amoeba是一個基于Java開發(fā)的，專注于解決分布式數(shù)據(jù)庫數(shù)據(jù)源整合Proxy程序的開源框架诀蓉，基于GPL3開源協(xié)議栗竖。眼下Amoeba已經(jīng)具有Query路由、Query過濾渠啤、讀寫分離狐肢、負載均衡以及HA機制等相關內(nèi)容。

Amoeba 主要解決的以下幾個問題：

1. 數(shù)據(jù)切分后復雜數(shù)據(jù)源整合沥曹；
2. 提供數(shù)據(jù)切分規(guī)則并降低數(shù)據(jù)切分規(guī)則給數(shù)據(jù)庫帶來的影響份名。
3. 降低數(shù)據(jù)庫與client的連接數(shù)。
4. 讀寫分離路由妓美；

我們能夠看出僵腺，Amoeba所做的事情，正好就是我們通過數(shù)據(jù)切分來提升數(shù)據(jù)庫的擴展性所須要的壶栋。

Amoeba并非一個代理層的Proxy程序辰如，而是一個開發(fā)數(shù)據(jù)庫代理層Proxy程序的開發(fā)框架，眼下基于Amoeba所開發(fā)的Proxy程序有AmoebaForMySQL和AmoebaForAladin兩個贵试。

AmoebaForMySQL主要是專門針對MySQL數(shù)據(jù)庫的解決方式琉兜，前端應用程序請求的協(xié)議以及后端連接的數(shù)據(jù)源數(shù)據(jù)庫都必須是MySQL。對于client的不論什么應用程序來說锡移，AmoebaForMySQL和一個MySQL數(shù)據(jù)庫沒有什么差別呕童。不論什么使用MySQL協(xié)議的client請求，都能夠被AmoebaForMySQL解析并進行對應的處理淆珊。下如能夠告訴我們AmoebaForMySQL的架構(gòu)信息（出自Amoeba開發(fā)人員博客）：

image.png

AmoebaForAladin則是一個適用更為廣泛夺饲，功能更為強大的Proxy程序。

他能夠同一時候連接不同數(shù)據(jù)庫的數(shù)據(jù)源為前端應用程序提供服務，可是僅僅接受符合MySQL協(xié)議的client應用程序請求往声。也就是說擂找，僅僅要前端應用程序通過MySQL協(xié)議連接上來之后，AmoebaForAladin會自己主動分析Query語句浩销，依據(jù)Query語句中所請求的數(shù)據(jù)來自己主動識別出該所Query的數(shù)據(jù)源是在什么類型數(shù)據(jù)庫的哪一個物理主機上面贯涎。下圖展示了AmoebaForAladin的架構(gòu)細節(jié)（出自Amoeba開發(fā)人員博客）：

image.png

咋一看，兩者好像全然一樣慢洋。細看之后才會發(fā)現(xiàn)兩者主要的差別僅在于通過MySQLProtocalAdapter處理之后塘雳。依據(jù)分析結(jié)果推斷出數(shù)據(jù)源數(shù)據(jù)庫。然后選擇特定的JDBC驅(qū)動和對應協(xié)議連接后端數(shù)據(jù)庫普筹。

事實上通過上面兩個架構(gòu)圖大家可能也已經(jīng)發(fā)現(xiàn)了Amoeba的特點了败明，他僅僅僅僅是一個開發(fā)框架。我們除了選擇他已經(jīng)提供的ForMySQL和ForAladin這兩款產(chǎn)品之外太防。還能夠基于自身的需求進行對應的二次開發(fā)妻顶。得到更適應我們自己應用特點的Proxy程序。

當對于使用MySQL數(shù)據(jù)庫來說蜒车。不論是AmoebaForMySQL還是AmoebaForAladin都能夠非常好的使用讳嘱。當然，考慮到不論什么一個系統(tǒng)越是復雜酿愧，其性能肯定就會有一定的損失沥潭，維護成本自然也會相對更高一些。所以寓娩，對于僅僅須要使用MySQL數(shù)據(jù)庫的時候叛氨，我還是建議使用AmoebaForMySQL呼渣。

AmoebaForMySQL的使用非常簡單棘伴，全部的配置文件都是標準的XML文件，總共同擁有四個配置文件屁置。分別為：

• amoeba.xml：主配置文件焊夸，配置全部數(shù)據(jù)源以及Amoeba自身的參數(shù)設置。
• rule.xml：配置全部Query路由規(guī)則的信息蓝角。
• functionMap.xml：配置用于解析Query中的函數(shù)所對應的Java實現(xiàn)類阱穗；
• rullFunctionMap.xml：配置路由規(guī)則中須要使用到的特定函數(shù)的實現(xiàn)類；

假設您的規(guī)則不是太復雜使鹅，基本上僅須要使用到上面四個配置文件里的前面兩個就可完畢全部工作揪阶。Proxy程序經(jīng)常使用的功能如讀寫分離。負載均衡等配置都在amoeba.xml中進行患朱。此外鲁僚。Amoeba已經(jīng)支持了實現(xiàn)數(shù)據(jù)的垂直切分和水平切分的自己主動路由。路由規(guī)則能夠在rule.xml進行設置。

眼下Amoeba少有欠缺的主要就是其在線管理功能以及對事務的支持了冰沙，以前在與相關開發(fā)人員的溝通過程中提出過相關的建議侨艾，希望能夠提供一個能夠進行在線維護管理的命令行管理工具，方便在線維護使用拓挥，得到的反饋是管理專門的管理模塊已經(jīng)納入開發(fā)日程了唠梨。另外在事務支持方面臨時還是Amoeba無法做到的，即使client應用在提交給Amoeba的請求是包括事務信息的侥啤，Amoeba也會忽略事務相關信息当叭。當然，在經(jīng)過不斷完好之后盖灸，我相信事務支持肯定是Amoeba重點考慮添加的feature科展。

關于Amoeba更為具體的用法讀者朋友能夠通過Amoeba開發(fā)人員博客（http://amoeba.sf.net）上面提供的使用手冊獲取，這里就不再細述了糠雨。

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

和前面的MySQLProxy以及Amoeba一樣才睹，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ù)切分工作逗抑。

在HiveDB中剧辐，通過用戶自己定義的各種Partitionkeys（事實上就是制定數(shù)據(jù)切分規(guī)則），將數(shù)據(jù)分散到多個MySQLServer中邮府。在訪問的時候荧关。在執(zhí)行Query請求的時候。會自己主動分析過濾條件褂傀，并行從多個MySQLServer中讀取數(shù)據(jù)忍啤，并合并結(jié)果集返回給client應用程序。

單純從功能方面來講仙辟，HiveDB可能并不如MySQLProxy和Amoeba那樣強大同波，可是其數(shù)據(jù)切分的思路與前面二者并無本質(zhì)差異。此外叠国，HiveDB并不僅僅僅僅是一個開源愛好者所共享的內(nèi)容未檩，而是存在商業(yè)公司支持的開源項目。

以下是HiveDB官方站點上面一章圖片粟焊，描寫敘述了HiveDB怎樣來組織數(shù)據(jù)的基本信息冤狡，盡管不能具體的表現(xiàn)出太多架構(gòu)方面的信息校赤，可是也基本能夠展示出其在數(shù)據(jù)切分方面獨特的一面了。

image.png

mycat數(shù)據(jù)整合

參見：http://www.songwie.com/articlelist/11

其它實現(xiàn)數(shù)據(jù)切分及整合的解決方式

除了上面介紹的幾個數(shù)據(jù)切分及整合的總體解決方式之外筒溃，還存在非常多其它相同提供了數(shù)據(jù)切分與整合的解決方式马篮。如基于MySQLProxy的基礎上做了進一步擴展的HSCALE，通過Rails構(gòu)建的SpockProxy怜奖。以及基于Pathon的Pyshards等等浑测。

無論大家選擇使用哪一種解決方式，總體設計思路基本上都不應該會有什么變化歪玲。那就是通過數(shù)據(jù)的垂直和水平切分迁央，增強數(shù)據(jù)庫的總體服務能力，讓應用系統(tǒng)的總體擴展能力盡可能的提升滥崩，擴展方式盡可能的便捷岖圈。

僅僅要我們通過中間層Proxy應用程序較好的攻克了數(shù)據(jù)切分和數(shù)據(jù)源整合問題。那么數(shù)據(jù)庫的線性擴展能力將非常容易做到像我們的應用程序一樣方便钙皮。僅僅須要通過加入便宜的PCServerserver蜂科，就可以線性添加數(shù)據(jù)庫集群的總體服務能力，讓數(shù)據(jù)庫不再輕易成為應用系統(tǒng)的性能瓶頸短条。