面向容器的云平臺數(shù)據(jù)重分布策略研究*

丁璽潤， 陳 梅， 李 暉

(1.貴州大學(xué) 計算機(jī)科學(xué)與技術(shù)學(xué)院，貴州 貴陽 550025；2.貴州大學(xué) 貴州省先進(jìn)計算與醫(yī)療信息服務(wù)工程實驗室，貴州 貴陽 550025)

面向容器的云平臺數(shù)據(jù)重分布策略研究*

丁璽潤1,2， 陳 梅1,2， 李 暉1,2

(1.貴州大學(xué) 計算機(jī)科學(xué)與技術(shù)學(xué)院，貴州 貴陽 550025；
2.貴州大學(xué) 貴州省先進(jìn)計算與醫(yī)療信息服務(wù)工程實驗室，貴州 貴陽 550025)

隨著Docker等的問世，基于容器的操作系統(tǒng)級虛擬化技術(shù)受到云計算廠商的廣泛關(guān)注。針對云平臺上不同應(yīng)用領(lǐng)域的數(shù)據(jù)庫容器(面向事務(wù)型任務(wù)的數(shù)據(jù)庫容器與面向分析型任務(wù)的數(shù)據(jù)庫容器)在運行時對宿主機(jī)資源需求的差異，提出一種面向容器的數(shù)據(jù)重分布策略，用于優(yōu)化容器中數(shù)據(jù)庫服務(wù)的性能。實驗結(jié)果表明，該策略達(dá)到了預(yù)期效果，可以有效提升容器中數(shù)據(jù)庫服務(wù)的性能。

云計算；虛擬化；數(shù)據(jù)庫；容器；數(shù)據(jù)重分布

0 引言

以Docker為代表的Linux容器技術(shù)為云平臺提供了更輕量級的虛擬化解決方案。Linux容器技術(shù)是一種內(nèi)核虛擬化技術(shù)(即操作系統(tǒng)級虛擬化技術(shù))，它提供了輕量級的虛擬化解決方案。可以在一臺主機(jī)上通過隔離進(jìn)程和資源，同時提供多個虛擬環(huán)境(即容器)。每個容器都擁有自己的進(jìn)程和獨立的網(wǎng)絡(luò)空間。從用戶角度看，一個運行的容器與一臺運行的主機(jī)無異。

基于容器的虛擬化技術(shù)通過隔離操作系統(tǒng)的對象，例如PID、UID、系統(tǒng)共享內(nèi)存、IPC等，實現(xiàn)對不同容器提供不同的系統(tǒng)視圖，并且通過Cgroups和Namespace技術(shù)實現(xiàn)。Linux容器技術(shù)在資源管理方面依賴于Linux內(nèi)核的Cgroups，它是Linux內(nèi)核提供的一個基于進(jìn)程組的資源管理框架，為特定的進(jìn)程組限定可以使用的資源。Linux在隔離控制方面依賴于Linux內(nèi)核的Namespace，即將原來的全局對象隔離到不同的Namespace里，不同容器之間不可見。

目前，應(yīng)用廣泛的虛擬化技術(shù)包括以VMWare和微軟的Virtual PC為代表的全虛擬化技術(shù)以及以Xen為代表的半虛擬化技術(shù)。與上述技術(shù)相比，容器級虛擬化可以直接運行CPU指令，避免全虛擬化指令級模擬或即時編譯造成的系統(tǒng)開銷，同時也避免了半虛擬化和系統(tǒng)調(diào)用替換的復(fù)雜操作。因此，容器級虛擬化技術(shù)比傳統(tǒng)虛擬化技術(shù)具有更輕量級，但是容器技術(shù)強(qiáng)制所有容器必須使用與宿主機(jī)相同的內(nèi)核。

文獻(xiàn)[1-2]指出，運行在云平臺上的服務(wù)，例如Web服務(wù)，容易受到網(wǎng)絡(luò)帶寬、CPU、內(nèi)存的影響，導(dǎo)致其服務(wù)質(zhì)量降低。傳統(tǒng)的解決方案是遷移云平臺上運行該服務(wù)的虛擬機(jī)到其他節(jié)點，即Virtual-to-Virtual。云平臺上面向容器的數(shù)據(jù)重分布技術(shù)與其類似，通過遷移一臺宿主機(jī)的容器及其數(shù)據(jù)卷到另一臺宿主機(jī)，以解決容器中服務(wù)的性能問題。本文針對云平臺上數(shù)據(jù)庫容器，設(shè)計并實現(xiàn)了LXCDDS，一種云平臺上面向容器的數(shù)據(jù)重分布策略，用于提升云平臺上Linux容器中不同類型任務(wù)(事務(wù)型和分析型)的數(shù)據(jù)庫服務(wù)的性能。

1 相關(guān)工作

1.1 Docker

Linux容器技術(shù)(Linux Containers，LXC)起源于1982年，由于操作復(fù)雜和維護(hù)困難等原因一直沒有得到廣泛應(yīng)用，直到Docker的出現(xiàn)，Linux容器技術(shù)再次受到業(yè)界認(rèn)可。Docker是dotCloud公司發(fā)起的一個開源項目。它始于2013年初，采用Go語言實現(xiàn)，以Linux容器技術(shù)為基礎(chǔ)，目標(biāo)是“Build, Ship, Run”，即“一次部署，多處運行”。文獻(xiàn)[3-4]中指出，對于開發(fā)和運維人員來說，最希望的是一次創(chuàng)建或配置，在任意環(huán)境中運行。Docker的出現(xiàn)使之成為可能。同時，基于操作系統(tǒng)級虛擬化技術(shù)實現(xiàn)的Docker，比傳統(tǒng)的虛擬機(jī)技術(shù)更輕量化，更易于遷移和擴(kuò)展。因此，本文采用Docker作為Linux容器技術(shù)的一種實現(xiàn)。

1.2 Flocker

本文采用Flocker作為容器中的數(shù)據(jù)遷移工具。Flocker是ClusterHQ公司的開源項目，它提供了容器數(shù)據(jù)卷管理以及多主機(jī)Docker集群管理功能。數(shù)據(jù)卷是一個可供一個或多個容器使用的特殊目錄，它繞過UFS，可以在容器之間共享和重用。Docker容器的數(shù)據(jù)卷可以用來存儲容器中的數(shù)據(jù)，一旦Docker容器由于某種原因宕機(jī)，可以通過相應(yīng)的數(shù)據(jù)卷恢復(fù)容器中的數(shù)據(jù)，因此，常用在提供數(shù)據(jù)庫服務(wù)的容器中。

Docker容器的數(shù)據(jù)卷只能綁定在一臺Docker宿主機(jī)上，不能遷移到集群中的其他節(jié)點。Flocker中的數(shù)據(jù)卷也稱作數(shù)據(jù)集(dataset)，它可以隨著容器遷移到集群中的任何節(jié)點。Flocker項目的核心是Control Service，它提供一個簡單的REST API，F(xiàn)locker Control Service使用Flocker API管理集群中的節(jié)點，通過Flocker API，開發(fā)人員可以在多主機(jī)集群中部署多容器應(yīng)用，在集群中遷移容器及其數(shù)據(jù)卷。目前，Docker官方正在測試Flocker項目，并計劃將其作為未來Docker數(shù)據(jù)卷管理工具。

2 容器級數(shù)據(jù)重分布策略的設(shè)計與實現(xiàn)

2.1 容器級數(shù)據(jù)重分布策略的設(shè)計

在Linux容器中可以運行各種應(yīng)用服務(wù)，其中數(shù)據(jù)庫服務(wù)是最常見的也是最重要的應(yīng)用服務(wù)，因此，本文重點研究如何提升Linux容器中數(shù)據(jù)庫服務(wù)的性能。

數(shù)據(jù)庫服務(wù)按照應(yīng)用領(lǐng)域可以劃分為面向事務(wù)型任務(wù)的數(shù)據(jù)庫(即OLTP型數(shù)據(jù)庫)和面向分析型任務(wù)的數(shù)據(jù)庫(即OLAP型數(shù)據(jù)庫)。本文研發(fā)的容器級數(shù)據(jù)重分布策略旨在將這兩種類型的數(shù)據(jù)庫容器重新分配到集群中的不同節(jié)點，并且通過調(diào)整節(jié)點的系統(tǒng)配置，分別提升這兩種類型的數(shù)據(jù)庫服務(wù)的性能。

如圖1所示，假設(shè)云平臺上運行Linux容器的集群中有兩個節(jié)點Node 1和Node 2，在這兩個節(jié)點上分別運行著幾個Linux容器，其中T代表OLTP型數(shù)據(jù)庫容器，A代表OLAP型數(shù)據(jù)庫容器。容器級數(shù)據(jù)重分布策略的本質(zhì)是將這兩種執(zhí)行不同任務(wù)的數(shù)據(jù)庫容器轉(zhuǎn)移到各自的節(jié)點上，讓同一種任務(wù)類型的數(shù)據(jù)庫容器運行在同一臺節(jié)點或同一集群上，即將T類型容器全部遷移到Node 1節(jié)點中，A類型容器全部遷移到Node 2節(jié)點中，最終狀態(tài)如圖2所示。

圖1 兩種類型的數(shù)據(jù)庫容器在集群節(jié)點中的分布

圖2 數(shù)據(jù)遷移后集群節(jié)點中數(shù)據(jù)庫容器的分布

從并發(fā)角度分析：對于OLTP型數(shù)據(jù)庫服務(wù)[5-6]，執(zhí)行I/O操作比CPU計算操作占用更多CPU時間片。該服務(wù)的線程負(fù)責(zé)阻塞I/O，當(dāng)某一線程因為I/O阻塞進(jìn)入阻塞狀態(tài)后，該線程的調(diào)度被操作系統(tǒng)內(nèi)核停止，不再占用CPU時間片段。而其他I/O線程立即被操作系統(tǒng)內(nèi)核調(diào)度，待I/O阻塞操作完成，原來阻塞狀態(tài)的線程重新變成就緒狀態(tài)時，可以被操作系統(tǒng)調(diào)度。因此，理論上，為圖2中Node 1的所有容器進(jìn)程設(shè)置更多的I/O密集型線程可以提升該節(jié)點中OLTP型數(shù)據(jù)庫服務(wù)的效率。

相反，對于OLAP型數(shù)據(jù)庫服務(wù)，CPU需要執(zhí)行大量的連接、聚集操作，而對于這種計算密集型任務(wù)，進(jìn)程中的線程越多，導(dǎo)致進(jìn)程內(nèi)每個線程的執(zhí)行時間越短，從而影響數(shù)據(jù)分析效率。因此，理論上，為圖2中Node 2的所有容器進(jìn)程設(shè)置更少的計算密集型線程可以提升該節(jié)點中OLAP型數(shù)據(jù)庫服務(wù)的效率。

綜上所述，該容器級數(shù)據(jù)重分布策略從理論上可以提升Linux容器中數(shù)據(jù)庫服務(wù)的性能。此外，出于簡化運維和業(yè)務(wù)管理的需要，在同一數(shù)據(jù)中心中，通常也更希望將同類型業(yè)務(wù)部署在物理位置更靠近的集群節(jié)點中。

2.2 容器級數(shù)據(jù)重分布策略的實現(xiàn)

在實際應(yīng)用中有兩種情況造成圖1所示的不同類型的容器不均勻地分布在不同節(jié)點上。第一種情況，在數(shù)據(jù)庫容器運行前，運維人員不清楚或未對數(shù)據(jù)庫容器執(zhí)行的任務(wù)類型進(jìn)行分類，因此，導(dǎo)致面向事務(wù)型和面向分析型任務(wù)的數(shù)據(jù)庫容器隨機(jī)地分布到不同節(jié)點中。第二種情況，運維人員已經(jīng)對數(shù)據(jù)庫容器執(zhí)行的任務(wù)進(jìn)行分類，但由于運行同一類任務(wù)的容器的宿主機(jī)資源不足，不能讓待運行的容器在這臺節(jié)點上運行，而運行另一類任務(wù)的容器的宿主機(jī)可以滿足這個容器的運行條件，因此它將運行在與自己不同任務(wù)類型的容器的宿主機(jī)上。

例如，如圖2所示，T類型任務(wù)運行在Node 1上，A類型任務(wù)運行在Node 2上，此時有1個T類型任務(wù)容器待運行，恰好Node 1不能提供它運行所需的資源，而Node 2可以滿足這個容器運行的條件，因此這個新的T類型任務(wù)的容器被部署在Node 2上。經(jīng)過一段時間，兩個宿主機(jī)中就會同時運行多種類型的容器。

對于第一種情況，不確定節(jié)點中運行的容器哪些是T類型哪些是A類型。由于每個正在運行的數(shù)據(jù)庫容器都有一個通過容器ID與它綁定的數(shù)據(jù)卷，該數(shù)據(jù)卷中存儲了該數(shù)據(jù)庫的數(shù)據(jù)、日志信息以及配置信息，通過解析該數(shù)據(jù)庫的日志信息，可以確定其執(zhí)行更新操作和查詢操作數(shù)目的比例，以及執(zhí)行更新操作和查詢操作消耗的時間。執(zhí)行事務(wù)型任務(wù)的數(shù)據(jù)庫，其更新操作頻繁，日志中更新操作的比例很高，且執(zhí)行查詢操作消耗的時間較短。反之，執(zhí)行分析型任務(wù)的數(shù)據(jù)庫，其更新操作非常少，但是由于其經(jīng)常做復(fù)雜分析操作，需要執(zhí)行大量JOIN操作和聚集操作，查詢執(zhí)行時間較長。因此，可以確定節(jié)點中的容器哪些是T類型哪些是A類型。

2.3 分布式環(huán)境下容器級數(shù)據(jù)重分布算法

算法1為分布式環(huán)境下容器級數(shù)據(jù)重分布算法。該算法核心思想：首先，確定節(jié)點Node中每一個數(shù)據(jù)庫容器的類型Type；然后，對于不符合本節(jié)點容器類型的數(shù)據(jù)庫容器，將其加入到待遷移隊列MoveList中；最后，找到待遷移的目標(biāo)節(jié)點TargetNode，判斷其是否有足夠資源運行該容器，如果條件滿足，則通過Flocker完成容器遷移，否則等待資源。算法代碼描述如下：

算法1DataDistributionAlgorithm輸入:NodeID,TargetNodeID,TypeNode,MoveList輸出:NULL1:whiletruedo2: ifHasNewContainers()=truethen3: foreachcinListContainers(NodeID)do4: TypeContainer(GetContainType(c);5: ifTypeContainer=TypeNodethen6: else7: ifIfNodeInList(c)=falsethen8: AddMoveList(c,MoveList);9: endif10: endif11: endfor12: endif13: while(HasElmts(MoveList)=trueandHasRes(TargetNodeID)=true)do14: e(GetNextContainer(MoveList);15: DataMovement(e);16: RmFromMoveList(e,MoveList);17: endwhile18:endwhile

3 實驗結(jié)果與分析

3.1 實驗環(huán)境及實驗方案

本實驗使用的硬件及系統(tǒng)配置見表1。實驗中使用的數(shù)據(jù)庫容器是DockerHub提供的PostgreSQL9.4.4官方鏡像，其配置為shared_buffers=128 MB，其他參數(shù)為PostgreSQL系統(tǒng)默認(rèn)參數(shù)。實驗使用標(biāo)準(zhǔn)的TPC-H benchmark對OLAP型數(shù)據(jù)庫的數(shù)據(jù)分析性能進(jìn)行測試，總數(shù)據(jù)量為1 GB。本實驗同時使用標(biāo)準(zhǔn)的TPC-C benchmark對OLTP型數(shù)據(jù)庫的事務(wù)性能進(jìn)行測試。

表1 硬件及系統(tǒng)配置信息表

實驗一和實驗二的實驗過程相同。首先，初始狀態(tài)時兩個節(jié)點中分別運行3個OLTP型PostgreSQL容器和3個OLAP型PostgreSQL容器，對其中的1個OLTP型PostgreSQL容器進(jìn)行TPC-C benchmark測試，同時對1個OLAP型PostgreSQL容器進(jìn)行TPC-H benchmark測試，得到實驗結(jié)果。然后，采用容器級數(shù)據(jù)重分布策略將OTLP型數(shù)據(jù)庫和OLAP型數(shù)據(jù)庫分離，使得其中一個節(jié)點上運行6個OLTP型PostgreSQL容器，另一個節(jié)點上運行6個OLAP型PostgreSQL容器，分別對OLTP型PostgreSQL容器進(jìn)行TPC-C benchmark測試，對OLAP型PostgreSQL容器進(jìn)行TPC-H benchmark測試，得到實驗結(jié)果。最后分別測試節(jié)點中僅運行1個數(shù)據(jù)庫容器時的OLTP性能和OLAP性能作為參考，得到對此結(jié)果。

3.2 實驗結(jié)果分析

實驗一的結(jié)果如圖3、圖4所示。圖3中顯示了執(zhí)行容器級數(shù)據(jù)重分布前后數(shù)據(jù)庫事務(wù)的性能對比結(jié)果。圖3的橫坐標(biāo)為測試的數(shù)據(jù)倉庫個數(shù)，每個數(shù)據(jù)倉庫中有10個測試終端(Terminal)；縱坐標(biāo)為tpmC(數(shù)據(jù)庫每分鐘處理事務(wù)數(shù))，tpmC的值越高，則數(shù)據(jù)庫的OLTP性能越好。從圖3中可以看出，節(jié)點中僅運行一個OLTP型數(shù)據(jù)庫容器時，它的事務(wù)性最好，因為節(jié)點中沒有其他容器與其競爭CPU等資源，本實驗用其作為性能參考標(biāo)準(zhǔn)。數(shù)據(jù)重分布后容器中數(shù)據(jù)庫的事務(wù)性能排在其后，因為數(shù)據(jù)重分布前節(jié)點中還有3個OLAP型數(shù)據(jù)庫容器在執(zhí)行復(fù)雜的表連接和聚集操作，占用整個節(jié)點的大量CPU時間片，導(dǎo)致CPU處理I/O操作的等待時間增加，所以執(zhí)行復(fù)雜分析操作的數(shù)據(jù)庫容器會影響OLTP型數(shù)據(jù)庫容器的更新操作性能，導(dǎo)致事務(wù)性能下降。因此，執(zhí)行容器級數(shù)據(jù)重分布有利于提升事務(wù)型數(shù)據(jù)庫容器的性能。

圖3 實驗一(a)數(shù)據(jù)重分布前后TPC-C測試結(jié)果

圖4中顯示了容器級數(shù)據(jù)重分布前后數(shù)據(jù)庫分析性能對比結(jié)果。圖4中橫坐標(biāo)為執(zhí)行TPC-H測試的22條SQL語句，其中Q17和Q20包含了復(fù)雜的嵌套查詢以及聚集操作，且由于postgresql的shared_buffers大小設(shè)置為128 MB，導(dǎo)致這兩條語句的執(zhí)行時間是其他語句執(zhí)行時間的幾千倍，因此不作為本實驗的參考。

從圖4中可以看到，數(shù)據(jù)重分布后數(shù)據(jù)庫的分析性能下降很明顯，查詢語句響應(yīng)時間比數(shù)據(jù)重分布前的響應(yīng)時間長很多。通過監(jiān)控節(jié)點的CPU和內(nèi)存發(fā)現(xiàn)，由于本實驗使用的CPU為4核，內(nèi)存8 GB，數(shù)據(jù)重分布前節(jié)點共執(zhí)行3個OLTP型數(shù)據(jù)庫容器和3個OLAP型容器，CPU使用率達(dá)到70%～90%，內(nèi)存使用7.27 GB，而數(shù)據(jù)重分布后執(zhí)行6個OLAP任務(wù)，該節(jié)點上的CPU使用率達(dá)到100%，內(nèi)存使用7.48 GB，這說明執(zhí)行OLAP型任務(wù)的數(shù)據(jù)庫容器會消耗大量 CPU時間片，而此時CPU使用率已經(jīng)達(dá)到飽和，因此數(shù)據(jù)庫的OLAP性能急劇下降。實驗證明，當(dāng)宿主機(jī)系統(tǒng)資源不足時會嚴(yán)重影響宿主機(jī)中容器的執(zhí)行效率，因此在宿主機(jī)資源不足時，應(yīng)該執(zhí)行容器數(shù)據(jù)遷移，但如果待遷移目標(biāo)主機(jī)的資源不足，則待遷移的容器應(yīng)該等待，以免由于資源競爭引起容器性能降低。

圖4 實驗一(b)數(shù)據(jù)重分布前后TPC-H測試結(jié)果

圖5 實驗二(a)數(shù)據(jù)重分布前后數(shù)據(jù)庫分析性能對比結(jié)果

實驗二在實驗一基礎(chǔ)上將CPU增加到8核，來測試容器中數(shù)據(jù)庫的OLTP和OLAP性能。實驗結(jié)果如圖5和圖6所示。圖5表明，節(jié)點中CPU和內(nèi)存充足時，數(shù)據(jù)重分布后的數(shù)據(jù)庫的OLAP性能普遍比數(shù)據(jù)重分布前性能好，其原因如下：

圖6 實驗二(b)數(shù)據(jù)重分布前后數(shù)據(jù)庫事務(wù)性能對比結(jié)果

數(shù)據(jù)重分布前，執(zhí)行OLTP任務(wù)的容器頻繁占用宿主機(jī)的CPU時間片來處理I/O請求，導(dǎo)致執(zhí)行OLAP型數(shù)據(jù)庫容器的CPU等待時間增加。因此，數(shù)據(jù)重分布后的數(shù)據(jù)庫的分析性能比數(shù)據(jù)重分布前要好。圖6為數(shù)據(jù)重分布前后數(shù)據(jù)庫事務(wù)性能對比。實驗結(jié)果表明執(zhí)行容器級數(shù)據(jù)重分布后數(shù)據(jù)庫事務(wù)性能好，具體原因圖3中同實驗一(a)。

4 結(jié)論

Docker技術(shù)的出現(xiàn)給Linux容器技術(shù)帶來巨大的發(fā)展前景，同時也促進(jìn)了云服務(wù)技術(shù)的發(fā)展與應(yīng)用。本文針對如何提升運行在云計算平臺容器中的執(zhí)行事務(wù)型任務(wù)和分析型任務(wù)的數(shù)據(jù)庫服務(wù)的性能提出了容器級數(shù)據(jù)重分布策略LXCDDS。實驗結(jié)果表明，該數(shù)據(jù)重分布策略能夠有效提升云平臺上容器中數(shù)據(jù)庫服務(wù)的性能。

[1] Wei Hao, YEN I L,THURAISINGHA M B. Dynamic service and data migration in the clouds[C]. IEEE COMPSAC, 2009:134-136.

[2] 石杰.云計算環(huán)境下的數(shù)據(jù)挖掘應(yīng)用[J].微型機(jī)與應(yīng)用,2015,34(5):13-15.

[3] 吳軍， 張軼君， 白光偉.Xen下虛擬機(jī)動態(tài)遷移優(yōu)化策略的研究[J].電子技術(shù)應(yīng)用,2015,41(11)：128-131.

[4] 楊保華， 戴王劍， 曹亞倫. Docker技術(shù)入門與實踐[M]. 北京：機(jī)械工業(yè)出版社, 2015.

[5] QUAMAR A, ASHWIN KUMAR K, DESHPANDE A. SWORD: scalable workload-aware data placement for transactional workloads[M]. EDBT, 2013.

[6] Li Yinan, PATEL J M. WideTable: an accelerator for analytical data processing[C]. Proceedings of the VLDB Endowment, 2014:907-909.

An efficient data distribution strategy for container in the cloud

Ding Xirun1,2, Chen Mei1,2, Li Hui1,2

(1.College of Cumputer Science and Technology, Guizhou University, Guiyang 550025, China; 2. Guizhou Engineering Laboratory for Advanced Computing and Medical Information Service, Guizhou University, Guiyang 550025, China)

With the advent of Docker, container technology has gained much attention by cloud computing vendors. In this paper, we propose a new strategy of data redistribution for database containers, on the different application domains (transaction or analysis) of cloud platform, call for different resource of the host at runtime. Experimental results show that the proposed strategy can improve the performance of database services in the container efficiently.

cloud computing; virtualization; database; container; data redistribution

國家自然科學(xué)基金(61462012，61562010)；貴州省高技術(shù)發(fā)展專項([2013]2069)；貴州省科技計劃項目([2013]2099，GY[2014]3018，JZ20142001-05)；貴州大學(xué)引進(jìn)人才項目(700246003301)；貴州大學(xué)研究生創(chuàng)新基金(研理工2015016)

TP39

A

1674-7720(2016)05-0026-04

丁璽潤，陳梅，李暉. 面向容器的云平臺數(shù)據(jù)重分布策略研究[J].微型機(jī)與應(yīng)用，2016,35(5)：26-29.

2015-11-13)

丁璽潤(1990-)，男，碩士研究生，主要研究方向：數(shù)據(jù)庫技術(shù)、大數(shù)據(jù)存儲等。

陳梅(1964-)，女，教授，研究生導(dǎo)師，主要研究方向：大規(guī)模數(shù)據(jù)管理與分析、高性能數(shù)據(jù)庫以及云服務(wù)技術(shù)等。

李暉(1982-)，通信作者，男，副教授，研究生導(dǎo)師，主要研究方向：大規(guī)模數(shù)據(jù)管理與分析、高性能數(shù)據(jù)庫、云計算等。E-mail:cse.HuiLi@gzu.edu.cn。