本發(fā)明涉及大數(shù)據(jù)環(huán)境下的數(shù)據(jù)庫領(lǐng)域,尤其涉及一種基于超圖劃分的分布式數(shù)據(jù)庫及其集群分區(qū)方法。
背景技術(shù):
現(xiàn)代企業(yè)的數(shù)據(jù)中心日漸龐大,分布式數(shù)據(jù)庫被廣泛運用于企業(yè)應(yīng)用中,并對企業(yè)的業(yè)務(wù)活動提供有效的管理和支持。此外,在線事務(wù)處理是商業(yè)環(huán)境下對分布式數(shù)據(jù)庫的新的需求。簡單的說,在線事務(wù)處理(OLTP)是重復(fù)性、大批量的業(yè)務(wù)的自動化處理。隨著在線事務(wù)處理的應(yīng)用場景的快速增長,催生了針對聯(lián)機事務(wù)處理而設(shè)計的分布式數(shù)據(jù)庫管理系統(tǒng)。通過分析系統(tǒng)歷史日志文件,統(tǒng)計事務(wù)在系統(tǒng)中訪問的分布情況,通過優(yōu)化分區(qū)的方式,提出了一種高吞吐、低延遲的數(shù)據(jù)庫。這種俗稱“NewSQL”的系統(tǒng)在繼承了關(guān)系型數(shù)據(jù)庫的在線事務(wù)處理功能,保證的事務(wù)ACID的特性,通過將數(shù)據(jù)非共享的分布在機器集群上,提高并發(fā)來提高性能。
VoltDB是一個分布式的、基于行存儲的、使用主存儲器的、運行在一個數(shù)據(jù)無共享的機器集群上的關(guān)系型數(shù)據(jù)庫。VoltDB每個節(jié)點是一臺物理機器,每個節(jié)點包含了一個或多個處理執(zhí)行引擎,該引擎使用單線程處理來自外部客戶端的聯(lián)機事務(wù)處理請求。如圖1所示,每個數(shù)據(jù)庫中的關(guān)系(Relation),或稱為表(Table),在VoltDB中被水平切分(partition)成一個或多個數(shù)據(jù)快,即將組成該表的全部元組按照主鍵的值分成一份或者多份,每個數(shù)據(jù)塊會被放置在一個或者多個具體的執(zhí)行引擎上。如圖2所示,數(shù)據(jù)庫中所有的表切分放置后,每個執(zhí)行引擎所擁有的所有數(shù)據(jù)組成了一個數(shù)據(jù)分區(qū),所有表最終切分放置方法組成了分區(qū)表。
由于數(shù)據(jù)關(guān)聯(lián)的復(fù)雜程度、集群分區(qū)的規(guī)模巨大,事務(wù)在查詢和修改具有短、小、重復(fù)的特點,根據(jù)數(shù)據(jù)的放置策略,將會有很大一部分事務(wù)訪問多個物理機上的數(shù)據(jù),而多分區(qū)事務(wù)的網(wǎng)絡(luò)通信開銷是巨大的,這將大大限制了多分區(qū)事務(wù)網(wǎng)絡(luò)通信的普及。
技術(shù)實現(xiàn)要素:
有鑒于現(xiàn)有技術(shù)的上述缺陷,本發(fā)明所要解決的技術(shù)問題是旨在根據(jù)用戶的需求和在線事務(wù)處理的特點,并在基于實現(xiàn)環(huán)境中,建立原型系統(tǒng)的統(tǒng)計模塊、歷史數(shù)據(jù)分析模塊和數(shù)據(jù)遷移模塊,以解決現(xiàn)有技術(shù)的多分區(qū)事務(wù)的網(wǎng)絡(luò)通信開銷巨大的問題。
為實現(xiàn)上述目的,本發(fā)明提供了一種基于超圖劃分的分布式數(shù)據(jù)庫,包括平臺基礎(chǔ)層和算法建模層,所述平臺基礎(chǔ)層包括數(shù)據(jù)統(tǒng)計模塊、歷史數(shù)據(jù)分析模塊和數(shù)據(jù)遷移模塊,其中:
所述數(shù)據(jù)統(tǒng)計模塊被配置為在數(shù)據(jù)庫運行一段時間后,通過網(wǎng)絡(luò)連接接收數(shù)據(jù)庫集群的日志統(tǒng)計數(shù)據(jù),并進行建模、預(yù)處理、噪聲去除;
所述歷史數(shù)據(jù)分析模塊被配置為將所述數(shù)據(jù)統(tǒng)計模塊處理過的日志統(tǒng)計數(shù)據(jù)生成重分區(qū)方案和遷移計劃;
所述數(shù)據(jù)遷移模塊被配置為以歷史數(shù)據(jù)分析模塊生成的遷移計劃和數(shù)據(jù)統(tǒng)計模塊解析的日志統(tǒng)計數(shù)據(jù)作為輸入,在數(shù)據(jù)庫集群各個機器之間遷移數(shù)據(jù);
所述算法建模層包括超圖最小割模塊、復(fù)雜網(wǎng)絡(luò)社團發(fā)現(xiàn)模塊和日志統(tǒng)計模塊,其中:
超圖最小割模塊被配置為對超圖進行建模和重分區(qū);
復(fù)雜網(wǎng)絡(luò)社團發(fā)現(xiàn)模塊被配置為通過發(fā)現(xiàn)日志統(tǒng)計數(shù)據(jù)的內(nèi)在關(guān)系的社團屬性,并將相同社團屬性的日志統(tǒng)計數(shù)據(jù)放入相應(yīng)的機器中;
日志統(tǒng)計模塊被配置為通過對輸入日志對象中不同維度的統(tǒng)計,產(chǎn)生日志統(tǒng)計數(shù)據(jù)。
進一步地,所述日志統(tǒng)計模塊被配置為將上傳到分布式文件系統(tǒng)的日志統(tǒng)計數(shù)據(jù)讀入所述超圖最小割模塊,所述超圖最小割模塊對統(tǒng)計過的日志文件建立超圖模型。
進一步地,所述數(shù)據(jù)統(tǒng)計模塊被配置為估算出服務(wù)器的容量,服務(wù)器的在聯(lián)機事務(wù)處理系統(tǒng)運行時,使用寫日志文件的方式,對一段時間內(nèi)進行訪問樣本的采樣,并記錄系統(tǒng)中每個事務(wù)訪問的分區(qū),計算出所有同時訪問分區(qū)的分布式事務(wù)的數(shù)量和訪問頻率。
進一步地,所述歷史數(shù)據(jù)分析模塊被配置為將所述數(shù)據(jù)統(tǒng)計模塊統(tǒng)計的數(shù)據(jù)建模,形成了一個集群間的超圖模型,將分區(qū)的問題抽象成一個圖,再通過貪心算法分析出重分區(qū)方案和遷移計劃,其中,所述超圖模型的點是分區(qū),邊是每一條事務(wù),邊的權(quán)值是事務(wù)訪問的頻率。
進一步地,所述日志統(tǒng)計模塊對輸入日志對象的不同維度統(tǒng)計的數(shù)據(jù)包括事務(wù)編號、執(zhí)行時間、事務(wù)訪問的分區(qū)。
進一步地,所述日志統(tǒng)計模塊產(chǎn)生的日志統(tǒng)計數(shù)據(jù)包括事務(wù)執(zhí)行頻率統(tǒng)計、訪問分區(qū)和跨分區(qū)事務(wù)的統(tǒng)計、各節(jié)點的容量和節(jié)點訪問頻率統(tǒng)計內(nèi)容。
本發(fā)明還提供了一種基于超圖劃分的分布式數(shù)據(jù)庫的集群分區(qū)方法,包括以下步驟:
提供平臺基礎(chǔ)層和算法建模層,其中所述平臺基礎(chǔ)層包括數(shù)據(jù)統(tǒng)計模塊、歷史數(shù)據(jù)分析模塊和數(shù)據(jù)遷移模塊,所述算法建模層包括超圖最小割模塊、復(fù)雜網(wǎng)絡(luò)社團發(fā)現(xiàn)模塊和日志統(tǒng)計模塊;
在數(shù)據(jù)庫運行一段時間后,所述數(shù)據(jù)統(tǒng)計模塊通過網(wǎng)絡(luò)連接接收數(shù)據(jù)庫集群的日志統(tǒng)計數(shù)據(jù);
所述日志統(tǒng)計模塊將日志統(tǒng)計數(shù)據(jù)讀入所述超圖最小割模塊;
所述超圖最小割模塊對統(tǒng)計過的日志文件建立超圖模型;
所述數(shù)據(jù)統(tǒng)計模塊估算出服務(wù)器的容量,服務(wù)器的在聯(lián)機事務(wù)處理系統(tǒng)運行時,使用寫日志文件的方式,對一段時間內(nèi)進行訪問樣本的采樣,并記錄系統(tǒng)中每個事務(wù)訪問的分區(qū),計算出所有同時訪問分區(qū)的分布式事務(wù)的數(shù)量和訪問頻率;
所述歷史數(shù)據(jù)分析模塊將所述數(shù)據(jù)統(tǒng)計模塊統(tǒng)計的數(shù)據(jù)建模,形成了一個集群間的超圖模型,將分區(qū)的問題抽象成一個圖,再通過貪心算法分析出重分區(qū)方案和遷移計劃;
所述數(shù)據(jù)遷移模塊以歷史數(shù)據(jù)分析模塊生成的遷移計劃和數(shù)據(jù)統(tǒng)計模塊解析的日志統(tǒng)計數(shù)據(jù)作為輸入,在數(shù)據(jù)庫集群各個機器之間遷移數(shù)據(jù)。
進一步地,其特征在于,所述超圖模型的點是分區(qū),邊是每一條事務(wù),邊的權(quán)值是事務(wù)訪問的頻率。
進一步地,所述日志統(tǒng)計模塊對輸入日志對象的不同維度統(tǒng)計的數(shù)據(jù)包括事務(wù)編號、執(zhí)行時間、事務(wù)訪問的分區(qū)。
進一步地,所述日志統(tǒng)計模塊產(chǎn)生的日志統(tǒng)計數(shù)據(jù)包括事務(wù)執(zhí)行頻率統(tǒng)計、訪問分區(qū)和跨分區(qū)事務(wù)的統(tǒng)計、各節(jié)點的容量和節(jié)點訪問頻率統(tǒng)計內(nèi)容。
本發(fā)明數(shù)據(jù)庫系統(tǒng)的模型示意圖如圖3所示,包括數(shù)據(jù)統(tǒng)計模塊,歷史數(shù)據(jù)分析模塊以及數(shù)據(jù)遷移模塊;本發(fā)明的目標(biāo)是分析用戶的歷史數(shù)據(jù),并對查詢的數(shù)據(jù)在集群中遷移,達到可擴展地動態(tài)適應(yīng)負載。以下對涉及到的各個模塊分別進行闡述:
數(shù)據(jù)統(tǒng)計模塊:統(tǒng)計模塊計估算出服務(wù)器的容量。服務(wù)器的在聯(lián)機事務(wù)處理系統(tǒng)運行時,使用寫日志文件的方式,對一段時間內(nèi)進行訪問樣本的采樣,即記錄系統(tǒng)中每個事務(wù)都訪問了哪些分區(qū)。從采樣中我們可以計算出所有同時訪問分區(qū)的分布式事務(wù)的數(shù)量和訪問頻率。
歷史數(shù)據(jù)分析模塊:統(tǒng)計數(shù)據(jù)是一個很大的工作量,將這些數(shù)據(jù)建模,形成了一個集群間超圖的模型。其中超圖的點是分區(qū),邊是每一條事務(wù),邊的權(quán)值是事務(wù)訪問的頻率。這樣能夠?qū)⒎謪^(qū)的問題抽象成一個圖。而通過分析這個超圖,通過貪心算法分析出一種更優(yōu)的分區(qū)方案,該方案是根據(jù)數(shù)據(jù)的分析動態(tài)生成的。
數(shù)據(jù)遷移模塊:數(shù)據(jù)根據(jù)分區(qū)的方案,在每一個分區(qū)上生成一個遷移計劃,數(shù)據(jù)會在遷移計劃下進行數(shù)據(jù)遷移。
系統(tǒng)的主要過程如下:我們在擁有分區(qū)方法的基礎(chǔ)上,統(tǒng)計集群各機器的日志文件,將機器間的網(wǎng)絡(luò)通信延時對分布式數(shù)據(jù)庫系統(tǒng)的影響進行了建模量化,并提出了使用超圖模型進行分區(qū)的分組、貪心算法進行分組的放置。
本發(fā)明提出了一種結(jié)合無共享架構(gòu)、事務(wù)的特性和數(shù)據(jù)庫分區(qū)技術(shù)來生成重分區(qū)策略的新方法。該方法在歷史處理日志文件分析的基礎(chǔ)上,對用戶需求進行理解、設(shè)計了一種基于超圖的重分區(qū)算法,通過無共享架構(gòu)的NewSQL平臺構(gòu)建基礎(chǔ)層、日志文件統(tǒng)計層、超圖模型層、重新部署層。實現(xiàn)對統(tǒng)計數(shù)據(jù)的建模和分析,完成對輸入日志的流程挖掘分析。整個平臺建立在無共享架構(gòu)上,提高了數(shù)據(jù)庫系統(tǒng)的可擴展性,與此同時,超圖算法模型實現(xiàn)了對用戶日志文件的數(shù)學(xué)建模,實現(xiàn)了重分區(qū)的按需分析。本發(fā)明根據(jù)聯(lián)機在線事務(wù)的需求對數(shù)據(jù)庫的通信延遲和網(wǎng)絡(luò)開銷進行了數(shù)倍的提升,并且實現(xiàn)了動態(tài)自動化的數(shù)據(jù)庫可擴展,動態(tài)算法在設(shè)計上針對現(xiàn)實生活中數(shù)據(jù)的聯(lián)系和屬性進行了數(shù)據(jù)的重分區(qū),使得在線事務(wù)處理更好的適應(yīng)應(yīng)用場景和現(xiàn)實數(shù)據(jù)。
以下將結(jié)合附圖對本發(fā)明的構(gòu)思、具體結(jié)構(gòu)及產(chǎn)生的技術(shù)效果作進一步說明,以充分地了解本發(fā)明的目的、特征和效果。
附圖說明
圖1為本發(fā)明VoltDB數(shù)據(jù)庫Schema分區(qū)和復(fù)制策略示意圖;
圖2為本發(fā)明多分區(qū)事務(wù)的訪問數(shù)據(jù)庫集群示意圖;
圖3為本發(fā)明一個較佳實施例的系統(tǒng)模塊分析圖。
具體實施方式
下面對本發(fā)明的實施例作詳細說明,本實施例在以本發(fā)明技術(shù)方案為前提下進行數(shù)據(jù)庫集群環(huán)境下的實施,以下給出了詳細的實施方式和具體的操作過程。
如圖3所示,本發(fā)明所述的基于超圖劃分的分布式數(shù)據(jù)庫集群分區(qū)方法,操作過程包括:數(shù)據(jù)統(tǒng)計、歷史數(shù)據(jù)分析、數(shù)據(jù)遷移。
平臺基礎(chǔ)層:是整個系統(tǒng)架構(gòu)的輸入接口和實現(xiàn)基礎(chǔ),包括三個模塊,分別是數(shù)據(jù)統(tǒng)計模塊、歷史數(shù)據(jù)分析模塊和數(shù)據(jù)遷移模塊。
數(shù)據(jù)統(tǒng)計模塊:在數(shù)據(jù)庫運行一段時間后,模塊通過日志數(shù)據(jù)統(tǒng)計與數(shù)據(jù)庫集群的日志數(shù)據(jù)建立網(wǎng)絡(luò)連接(如HTTP或FTP訪問)傳輸日志數(shù)據(jù),并將接受的數(shù)據(jù)經(jīng)過日志預(yù)處理模塊進行建模、預(yù)處理、噪聲去除。
歷史數(shù)據(jù)分析模塊:將數(shù)據(jù)統(tǒng)一進行處理分析,生成一個重分區(qū)方案。最后將處理結(jié)果經(jīng)由日志解析模塊生成平臺集成模塊可供數(shù)據(jù)庫處理的遷移計劃分發(fā)給各分區(qū)。
數(shù)據(jù)遷移模塊:該模塊以數(shù)據(jù)分析模塊生成的遷移計劃為插和日志處理模塊解析的遷移計劃作為輸入,數(shù)據(jù)庫開始在集群個各個機器之間遷移數(shù)據(jù),遷移的同時,事務(wù)仍可以訪問未遷移的數(shù)據(jù),帶數(shù)據(jù)遷移完畢后將等待的事務(wù)繼續(xù)處理。
算法建模層:是整個系統(tǒng)架構(gòu)的核心處理單元,包括各數(shù)據(jù)的建模、數(shù)據(jù)分析、模型求解的具體實現(xiàn)。在本實施例中主要包括三個模塊,分別是超圖建模與最小割算法模塊、復(fù)雜網(wǎng)絡(luò)社團發(fā)現(xiàn)模塊和日志統(tǒng)計模塊。
hmetis模塊:該模塊實現(xiàn)了對超圖的重分區(qū),提供高效精確的分區(qū)算法。一次對hmetis獨立的運算比其他的算法例如FM、KL、CLIP更快。另外,因為它的很好的平均削減幅度的特性,使得高性能的高速的分區(qū)算法成為可能。該算法在大于100000結(jié)點的超圖上運行只需要數(shù)分鐘。
復(fù)雜網(wǎng)絡(luò)社團發(fā)現(xiàn)模塊:該模塊實現(xiàn)了復(fù)雜網(wǎng)絡(luò)領(lǐng)域的社團發(fā)現(xiàn)算法,該算法通過發(fā)現(xiàn)數(shù)據(jù)的內(nèi)在關(guān)系的社團屬性,并將相同社團的數(shù)據(jù)放入對應(yīng)的機器中。
日志統(tǒng)計模塊:該模塊實現(xiàn)了對輸入日志對象的統(tǒng)計功能。通過對輸入日志對象中不同維度(如事務(wù)編號、執(zhí)行時間、事務(wù)訪問的分區(qū)等)的統(tǒng)計,產(chǎn)生日志的統(tǒng)計數(shù)據(jù),包括事務(wù)執(zhí)行頻率統(tǒng)計、訪問分區(qū)和跨分區(qū)事務(wù)的統(tǒng)計、各節(jié)點的容量和節(jié)點訪問頻率統(tǒng)計等內(nèi)容。
系統(tǒng)各模塊的調(diào)用過程如下。日志統(tǒng)計模塊先將上傳到分布式文件系統(tǒng)的日志文件讀入hmetis模塊,hmetis模塊將統(tǒng)計過的日志文件建模超圖,超圖模型。
本發(fā)明所述系統(tǒng)的主要特點是基于無共享架構(gòu)的DBMS;支持多模塊動態(tài)集成;主要技術(shù)和語言是JAVA、C++、Xml、Hmetis等。運行時環(huán)境為3個節(jié)點的分布式集群,運行時利用hmetis,提高了算法的時間和空間效率,并且對于大規(guī)模集群能迅速求解,并且支持算法模塊在算法模塊層進行動態(tài)地增加、修改和刪除。由算法模塊可動態(tài)的重分區(qū)并且遷移數(shù)據(jù),使得分布式事務(wù)減少,跟好的保證了數(shù)據(jù)庫的一致性。數(shù)據(jù)庫可擴展性強。
使用了本發(fā)明中提出的構(gòu)建方法后,在按需分析的同時,使得整個DBMS平臺實現(xiàn)在線事務(wù)處理的用戶需求和算法的模型,進而能夠動態(tài)地調(diào)整平臺的分區(qū)策略,提高了系統(tǒng)的可擴展性、可維護性和易用性,同時降低了延遲并提高了吞吐量。
以上詳細描述了本發(fā)明的較佳具體實施例。應(yīng)當(dāng)理解,本領(lǐng)域的普通技術(shù)人員無需創(chuàng)造性勞動就可以根據(jù)本發(fā)明的構(gòu)思作出諸多修改和變化。因此,凡本技術(shù)領(lǐng)域中技術(shù)人員依本發(fā)明的構(gòu)思在現(xiàn)有技術(shù)的基礎(chǔ)上通過邏輯分析、推理或者有限的實驗可以得到的技術(shù)方案,皆應(yīng)在由權(quán)利要求書所確定的保護范圍內(nèi)。