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

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

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

　　關(guān)鍵詞：云計(jì)算；虛擬化；數(shù)據(jù)庫；容器；數(shù)據(jù)重分布

0引言

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

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

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

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

1相關(guān)工作

　　1.1Docker

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

　　1.2Flocker

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

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

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

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

　　在Linux容器中可以運(yùn)行各種應(yīng)用服務(wù)，其中數(shù)據(jù)庫服務(wù)是最常見的也是最重要的應(yīng)用服務(wù)，因此，本文重點(diǎn)研究如何提升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ǎn)，并且通過調(diào)整節(jié)點(diǎn)的系統(tǒng)配置，分別提升這兩種類型的數(shù)據(jù)庫服務(wù)的性能。

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

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

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

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

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

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

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

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

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

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

　　輸出: NULL

　　1: while true do

　　2:if HasNewContainers()=true then

　　3:for each c in ListContainers(NodeID) do

　　4:TypeContainer ( GetContainType(c);

　　5:if TypeContainer= TypeNode then

　　6:else

　　7:if IfNodeInList(c)=false then

　　8:AddMoveList(c,MoveList);

　　9:end if

　　10: end if

　　11: end for

　　12: end if

　　13: while (HasElmts(MoveList)=true and

　　HasRes(TargetNodeID)=true) do

　　14: e ( GetNextContainer(MoveList);

　　15: DataMovement(e);

　　16: RmFromMoveList(e, MoveList);

　　17: end while

　　18:end while

3實(shí)驗(yàn)結(jié)果與分析

　　3.1實(shí)驗(yàn)環(huán)境及實(shí)驗(yàn)方案

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

　　實(shí)驗(yàn)一：4核CPU；

　　實(shí)驗(yàn)二：8核CPU內(nèi)存8 GB硬盤120 GB， 15 000 r/min操作系統(tǒng)CentOS 7（內(nèi)核3.10.0）Docker版本1.7.1Flocker版本1.0.3PostgreSQL9.4.4實(shí)驗(yàn)一和實(shí)驗(yàn)二的實(shí)驗(yàn)過程相同。首先，初始狀態(tài)時(shí)兩個(gè)節(jié)點(diǎn)中分別運(yùn)行3個(gè)OLTP型PostgreSQL容器和3個(gè)OLAP型PostgreSQL容器，對其中的1個(gè)OLTP型PostgreSQL容器進(jìn)行TPCC benchmark測試，同時(shí)對1個(gè)OLAP型PostgreSQL容器進(jìn)行TPCH benchmark測試，得到實(shí)驗(yàn)結(jié)果。然后，采用容器級數(shù)據(jù)重分布策略將OTLP型數(shù)據(jù)庫和OLAP型數(shù)據(jù)庫分離，使得其中一個(gè)節(jié)點(diǎn)上運(yùn)行6個(gè)OLTP型PostgreSQL容器，另一個(gè)節(jié)點(diǎn)上運(yùn)行6個(gè)OLAP型PostgreSQL容器，分別對OLTP型PostgreSQL容器進(jìn)行TPCC benchmark測試，對OLAP型PostgreSQL容器進(jìn)行TPCH benchmark測試，得到實(shí)驗(yàn)結(jié)果。最后分別測試節(jié)點(diǎn)中僅運(yùn)行1個(gè)數(shù)據(jù)庫容器時(shí)的OLTP性能和OLAP性能作為參考，得到對此結(jié)果。

　　3.2實(shí)驗(yàn)結(jié)果分析

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

　　圖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í)行時(shí)間是其他語句執(zhí)行時(shí)間的幾千倍，因此不作為本實(shí)驗(yàn)的參考。

　　從圖4中可以看到，數(shù)據(jù)重分布后數(shù)據(jù)庫的分析性能下降很明顯，查詢語句響應(yīng)時(shí)間比數(shù)據(jù)重分布前的響應(yīng)時(shí)間長很多。通過監(jiān)控節(jié)點(diǎn)的CPU和內(nèi)存發(fā)現(xiàn)，由于本實(shí)圖4實(shí)驗(yàn)一（b）數(shù)據(jù)重分布前后TPCH測試結(jié)果

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

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

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

4結(jié)論

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

參考文獻(xiàn)

　?。?］ Wei Hao, YEN I L,THURAISINGHA M B. Dynamic service and data migration in the clouds［C］. IEEE COMPSAC, 2009:134136.

　?。?］ 石杰.云計(jì)算環(huán)境下的數(shù)據(jù)挖掘應(yīng)用［J］.微型機(jī)與應(yīng)用,2015,34(5):1315.

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

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

　?。?］ QUAMAR A, ASHWIN KUMAR K, DESHPANDE A. SWORD: scalable workloadaware data placement for transactional workloads［M］. EDBT, 2013.

　?。?］ Li Yinan, PATEL J M. WideTable: an accelerator for analytical data processing［C］. Proceedings of the VLDB Endowment, 2014:907909.