前言
最近,我在學習瞭解MySQL資料庫結構描述相關的內容,從網上搜尋了大量的相關資料和文章,粗粗閱覽了一遍,發現架構相關的東西深不可測,需要非常豐富的知識閱曆和實踐經驗。
我的閱曆和經驗明顯不夠用,所以我把瞭解到的相關內容作了下分類整理,算作這次學習的一個大致總結吧!這篇文章的大部分內容都來自網路,由於我的水平有限,整理的也並不準確,其中可能有很多錯誤之處,希望大家能不吝指正!希望這篇文章能拋磚引玉,協助我們瞭解資料庫結構描述相關的一些內容。
1 資料切分方案
當資料庫比較龐大,讀寫操作特別是寫入操作過於頻繁,很難由一台伺服器支撐的時候,我們就要考慮進行資料庫的切分。所謂資料庫的切分,就是我們按照某些特定的條件,將一台資料庫上的資料分散到多台資料庫伺服器上。因為使用多台伺服器,所以當一台伺服器宕機後,整個系統只有部分資料不可用,而不是全部不可用。因此,資料庫切分不僅能夠用多台伺服器分擔資料庫的負載壓力,還可以提高系統的總體可用性。
資料的切分有兩種方式:垂直切分和水平切分。
1.1 垂直切分
垂直切分就是按照系統功能模組,將每個模組訪問的資料表切分到不同的資料庫中。
適用情況:垂直切分適用於架構設計較好,各個模組間的互動點比較統一而且比較少,耦合度較低的系統。
優點:資料庫的切分簡單明了,規則明確;系統模組清晰明確,容易整合;資料維護方便,定位容易。
缺點:無法在資料庫內實現表關聯,只能在程式中實現;對於訪問量大且資料量超大的資料表仍然會存在效能問題;事物處理會變得更為複雜,跨伺服器的分散式交易會增多;過度切分會導致系統過度複雜、無法擴充、維護困難。
1.2 水平切分
水平切分就是對資料量超大的資料表,按照其中資料的邏輯關係,根據某個欄位的某種規則,將其中的資料切分到多個資料庫上。
適用情況:水平切分適用於有超大資料量的表且有合適的欄位和規則進行水平切分的資料庫。資料庫進行水平切分後的多個資料庫不應該存在互動的情況。
優點:可以在資料庫內實現表關聯;不會存在超大資料量且超高負載的資料表;可以在資料庫內實現交易處理,交易處理相對簡單;在合理的切分規則下,擴充性較好。
缺點:切分規則一般比較複雜,很難找出一個適合整個資料庫的切分規則;資料的維護難度增加,人工定位元據難度增加;系統模組的耦合度較高,資料移轉拆分難度增加。
在實際進行資料切分時,我們首先應該根據系統模組的設計,合理地進行垂直切分。當模組細分到一定程度後,如果繼續進行細分,就會使系統架構過於複雜,整個系統面臨失控的危險。這時,我們就要利用水平切分的優勢,來避免繼續進行垂直切分導致的系統複雜化、面臨失控的問題。同時,因為資料已經進行了合理的垂直切分,所以水平切分規則相對簡單,系統模組耦合度較高的問題也已得到解決。總之,資料切分應該遵循一個原則,那就是“先合理垂直切分,再適時水平切分;先模組化切分,後資料集切分”。
2 資料整合方案
資料在經過垂直和水平切分被存放在不同的資料庫伺服器上之後,系統面臨的最大問題就是如何來讓這些來自不同資料庫伺服器上的資料得到較好的整合。解決這個問題有兩種方式,第一種:在系統的每個模組中組態管理該模組需要的一個或者幾個資料庫及其所在伺服器的資訊,資料在模組中進行整合;第二種:通過中間代理層來統一管理所有的資料來源,資料庫叢集對系統應用透明。第一種方案在初期開發時所需成本較小,但是長期來看,系統的擴充性會受到較大的限制。第二種方案則剛好相反,短期內付出的成本相對較大,但有利於系統的擴充。第二種方案可以通過一些第三方軟體實現。
2.1 MySQLProxy
MySQLProxy可用來監視、分析、傳輸應用與資料庫之間的通訊。它可以實現連線路由,Query分析,Query過濾和修改,負載平衡,以及基本的HA機制等。
原理:MySQLProxy 實際上是在應用請求與資料庫服務之間建立了一個串連池。所有應用請求都發向MySQLProxy,然後經由MySQLProxy 進行相應的分析,判斷出是讀操作還是寫操作,分發至對應的MySQLServer 上。對於多節點Slave叢集,也可以起到負載平衡的效果。
優點:MySQLProxy具有很大的靈活性,我們可以最大限度的使用它。
缺點:MySQLProxy實際上並不直接提供相關功能,這些功能都要依靠自行編寫LUA指令碼實現。
2.2 Amoeba
Amoeba是一個基於Java開發的Proxy程式開源架構,致力於解決分散式資料庫的資料整合問題。它具有Query路由,Query過濾,讀寫分離,負載平衡功能以及HA機制等。Amoeba可以整合資料切分後的複雜資料來源,降低資料切分給整個系統帶來的影響,降低資料庫與用戶端的串連數,實現資料的讀寫分離。
原理:Amoeba相當於一個SQL請求的路由器,它集中地響應應用的請求,依據使用者事先設定的規則,將SQL請求發送到特定的資料庫伺服器上執行。據此實現負載平衡、讀寫分離、高可用性等需求。
優點:基於XML的設定檔,用SQLJEP文法編寫規則,配置比較簡單
缺點:目前還不支援事務;對返回大數量的查詢並不合適;不支援分庫分表,只能做到分資料庫執行個體。
2.3 HiveDB
HiveDB也是一個基於Java開發,針對MySQL資料庫提供資料切分及整合的開源架構。但是,目前的HiveDB僅支援資料的水平切分。HiveDB主要解決大資料量下資料庫的擴充性及資料的高效能訪問問題,同時支援資料的冗餘及基本的HA機制。
原理:HiveDB通過使用者自訂的各種Partition keys將資料分散到多個資料庫伺服器上,訪問時解析query請求,自動分析過濾條件,並行從多個資料庫上讀取資料後合并結果集返回給用戶端應用程式。HiveDB的實現機制與Amoeba和MySQLProxy不同,它不用藉助其他複製同步技術即可自行實現資料的冗餘。其底層主要是基於Hibernate Shards 來實現的。Hibernate Shards是Google 技術團隊在對 Google 財務系統資料 Sharding 過程中誕生的。Hibernate Shards是在架構層實現的,有其獨特的特性:標準的 Hibernate 編程模型,會用 Hibernate 就能搞定,技術成本較低;相對彈性的 Sharding 策略以及支援虛擬 Shard 等。
優點:有商業公司支援,可自行實現資料冗餘。
缺點:僅支援水平資料分割
在資料的整合過程中,還存在一些問題,比如:分散式交易的問題,跨節點JOIN的問題,跨節點排序分頁的問題等。對於分散式交易的問題,我們需要將其拆分成多個單資料庫內的小事務,由應用程式進行總控;跨節點JOIN的問題,我們需要先從一個節點中取出資料,然後由應用程式去其他節點進行JOIN或者使用Federated引擎;跨節點排序分頁時,我們可以並行地從多個節點中讀取資料,然後由應用程式進行排序分頁。
3 資料冗餘方案
任何裝置或服務,只要是單點,就存在著很大的安全隱患。因為一旦這台裝置或服務宕機之後,在短時間內就很難有備用裝置或服務來頂替其功能。資料庫作為系統的核心,必須存在一個備份以在出現異常時能夠快速頂替原有服務,實現高可用性。同時,要實現資料庫的讀寫分離,也必須採用複製技術保持多資料庫節點的資料同步。實現資料同步的方式有很多,下面簡要介紹常用的幾個。
3.1 MySQL Replication
MySQL Replication是MySQL內建的一個非同步複製的功能。複製過程中一個伺服器充當主伺服器,而一個或多個其它伺服器充當從伺服器,也就是主從模式。
原理:MySQL使用3個線程來執行複製功能。當開始複製時,從伺服器會建立一個I/O線程串連主伺服器並要求主伺服器發送記錄在其上的二進位日誌中的語句。主伺服器會建立一個線程將二進位日誌中的內容發送到從伺服器。從伺服器I/O線程讀取主伺服器線程發送的內容並將該資料複製到從伺服器資料目錄中的本地檔案中,這個檔案稱為中繼日誌。第三個線程是SQL線程,是由從伺服器建立的,用來讀取中繼日誌並執行日誌中包含的更新。常用的架構方式為:主-從、主-主、主-從級聯、主-主-從級聯等。
優點:部署簡單、實施方便,是MySQL自動支援的功能,主備機切換方便,可以通過第三方軟體或者自行編寫簡單的指令碼即可自動完成主備切換。
缺點:實際使用時,只能單主機進行寫入,不一定能滿足效能要求;伺服器主機硬體故障時,可能會造成部分尚未傳輸至從機的資料丟失。
3.2 MySQLCluster
MySQL Cluster 是MySQL適用於分散式運算環境的高可用、高冗餘版本,採用了NDB Cluster 儲存引擎(“NDB”是一種“記憶體中”的儲存引擎,它具有可用性高和資料一致性好的特點),允許在1個 Cluster 中運行多個MySQL伺服器。
原理:MySQL Cluster將標準的MySQL伺服器與NDB Cluster儲存引擎整合了起來。MySQL Cluster由一組電腦構成,每台電腦上均運行著多種進程,包括MySQL伺服器,NDB Cluster的資料節點,管理伺服器,以及(可能)專門的資料訪問程式。所有這些程式一起構成了MySQL Cluster。將資料儲存到NDB Cluster儲存引擎時,表(結構)被儲存到了資料節點中,應用程式能夠從所有其他MySQL伺服器上直接存取這些表。 參見:
優點:可用性非常高,效能非常好;每一份資料至少在不同主機上面存在一份拷貝,且即時同步;通過無共用體繫結構,系統能夠使用廉價的硬體,而且對軟硬體無特殊要求。
缺點:維護比較複雜,很多情景下不適合使用。3.3 DRBD磁碟網路鏡像方案
DRBD(Distributed Replicated Block Device),是由LINBIT 公司開發的,通過網路來實現塊裝置的資料鏡像同步的一款開源Cluster軟體,也被俗稱為網路RAID1。
原理:DRBD介於檔案系統與磁碟介質之間,通過捕獲上層檔案系統的所有IO操作,調用核心中的IO模組來讀寫底層的磁碟介質。當DRBD捕獲到檔案系統的寫操作之後,會在進行本地的磁碟寫操作的同時,以TCP/IP協議,通過本地主機的網路裝置(NIC)將IO傳遞至遠程主機的網路裝置。當遠程主機的DRBD監聽到傳遞過來的IO資訊之後,會立即將該資料寫入到該DRBD所維護的磁碟裝置。DRBD在處理遠端資料寫入的時候有三種複製模式,適用於不同的可靠性和效能要求情景。
優點:功能強大,資料在底層塊裝置層級跨物理主機鏡像,可根據效能和可靠性要求配置不同層級的同步;IO操作保持順序,可滿足對資料一致性的苛刻要求。
缺點:非Distributed File System環境無法支援鏡像資料同時可見,效能和可靠性兩者相互矛盾,無法適用於效能和可靠性要求都比較苛刻的環境,維護成本比較高。
3.4 RaiDB
RaiDB,其全稱為RedundantArrays of Inexpensive Databases,也就是通過Raid理念來管理資料庫的資料:通過將多個廉價的資料庫執行個體組合到一個資料庫陣列,提供比單台資料庫更好的效能和容錯性,同時隱藏分散式資料庫的複雜性,提供給應用程式一個獨立的資料庫。
原理:在RaiDB中,控制器在資料庫陣列的前面。應用程式發送請求到RaiDB控制器,控制器將請求分發給一組資料庫。跟磁碟的Raid一樣,RaiDB也有不同的層級或資料分發方案,如RaiDB-0、RaiDB-1、RaiDB-1-0、RaiDB-0-1等,用於提供不同的成本、效能、容錯權衡。
優點:和磁碟的Raid一樣,RaiDB也可以大幅提高資料的讀寫速度,並提供容錯功能
缺點:只能支援將資料庫中的表分割到不同的資料庫執行個體上,資料表本身不能再進行分割了;不支援分布式的join;擴充性的提升取決於表的數目和各個表的負載情況。