一種基于Ｐ２Ｐ網絡的虛擬全局數據庫

(1. 燕山大學 a.計算機科學與工程系； b.信息與計算科學系， 河北 秦皇島 066004； 2. 浙江大學 計算機科學與技術系， 杭州 310027)



摘要：

提出了一種基于P2P網絡的虛擬全局數據庫(virtual global database，VGDB)。它使用構成覆蓋層網絡的不穩定的Internet節點自發組成一個可靠的全局數據庫，為基本P2P網絡中的所有節點提供了一個全局數據管理中心。VGDB提供了近乎永不丟失數據存儲功能、安全的數據操作方式、靈活的數據查詢或修改方式、快速的命令響應速度。在一個具有10 000個節點的模擬P2P網絡上進行的分析和實驗表明，VGDB在存儲量、數據穩定性、數據訪問速度、檢索靈活性等方面表現非常突出。

關鍵詞：虛擬全局數據庫； 結構化對等網； 非結構化對等網； 數據庫； 性能分析

中圖分類號：TP391文獻標志碼：A

文章編號：10013695(2009)03105405



Virtual global database for P2P networks



MA Qinyong1a， NIE Dongdong1b， WANG Shenkang2



(1.a.Dept. of Computer Science Engineering， b.Dept. of Information Computing Sciences， Yanshan University， Qinhuangdao Hebei 066004， China； 2.Dept. of Computer Science Technology， Zhejiang University， Hangzhou 310027， China)



Abstract:

This paper proposed a virtual global database system (VGDB)， which was organized from unreliable underlying P2P network nodes， and provided persistent data storage， and flexible， efficient and secure global data access for them. Analyzing its performance and verify its core components in a simulated P2P network with 10 000 nodes， the results show， for global data， VGDB can provide considerable storage capacity while achieves high stability. Experiments confirm that VGDB achieves high performance and flexibility for responding various commands under different loads.

Key words：virtual global database; structured P2P; unstructured P2P; database; performance analysis



第一個著名的P2P系統Napster使用一個中心服務器發布數據的索引信息，此類中心化P2P系統是比較脆弱的，單個服務器的崩潰會使整個網絡失效。目前不使用服務器的P2P系統可以實現一些搜索功能，但是由于缺少可靠的全局信息中心，此類系統很難提供對全局數據的索引功能。例如Bittorrent如果沒有服務器的支持，用戶將無法得到種子文件；eMule如果沒有服務器的支持，用戶無法得到文件列表等索引信息。缺少可靠的全局信息中心，在P2P系統中執行一些較復雜的查詢也相對困難，如查詢系統中最流行的五個文件、查詢具有最大帶寬或最長在線時間的節點、計算節點的平均帶寬等。沒有可靠的全局信息中心，對用戶進行身份認證，精確地保存及查詢用戶的聲譽數據也難以實現。

為了解決上述這些問題，本文設計了一種基于P2P網絡的VGDB。VGDB運行在基本的非結構化[1， 2]或結構化[3， 4]P2P網絡之上，使用構成P2P網絡的不穩定的Internet節點自發組成可靠的全局數據庫，為基本P2P網絡中的節點提供了全局數據管理中心。VGDB提供了近乎永不丟失數據存儲功能、安全的數據操作方式、靈活的數據查詢或修改方式、快速的命令響應速度。使用VGDB，普通節點可以方便、快速、可靠地執行全局數據存儲、更改和查詢操作。VGDB的這些特性使得P2P系統很容易實現很多重要的功能。例如BitTorrent可以使用VGDB來發布種子文件；eMule可以使用VGDB提供熱點文件列表；對于以前一些系統中的Aggregation功能[5]，如果有本文提出的全局數據中心的幫助，實現會容易得多。

對VGDB的分析表明，對于具有10 000個節點的eMule類型的系統，VGDB可以實現最多1 GB存儲空間。如果VGDB中總共有1 GB數據，則整個VGDB的MTTDL(mean time to data loss)為739.7年。本文的實驗表明，在系統中所有節點的命令執行頻率都非常高的情況下，80%以上的讀命令可在0.25 s以內完成，80%以上的寫命令可以在1.0 s內完成。

1系統概述

如圖1所示，整個VGDB的存儲空間由多個穩定數據單元 (persistent data cell，PDC)提供，每個PDC提供最大Cmax的存儲空間。PDC的個數是根據VGDB中存儲的數據多少，以及系統中穩定數據單元替補(persistent data cell candidate，PDCC)的數量來決定的。PDC既是數據存儲空間的提供者，也直接執行其他節點的命令。PDC支持四種基本的SQL命令，即Select、Insert、Delete和Update。PDC根據需要為每個域的記錄提供不同的訪問控制策略。只要系統中有足夠的PDCC，VGDB的數據存儲容量就可以不斷增大。

VGDB的存儲空間被劃分為多個域，域相當于傳統數據庫中的表(table)，VGDB中的每個記錄都歸屬于某個域。就像應用程序可以使用表來實現各種功能一樣，P2P系統可以使用VGDB中不同的域來實現各種功能。數據記錄(record)使用域名加上記錄的關鍵字段進行標志，如域 DA中一個記錄的關鍵字段內容為RA，則此記錄的標志為/DA/RA/。所有記錄在域中按照關鍵字段的順序進行存儲，所有域按照域名的順序進行存儲。每個PDC負責這些有序排列的記錄組成的名字空間的某部分，如圖1中，PDC A負責/Domain A/Record A/到/Domain A/Record S/這些記錄，PDC B負責/Domain A/Record T/到/Domain E/Record F/這些記錄。PDC使用所負責的第一個記錄和最后一個記錄作為這個PDC的標志，如PDC B的標志為/Domain A/Record T/ /Domain E/Record F/。不同的PDC使用標志來排序。在序列中相鄰的兩個PDC稱為鄰居。這樣同一個域可能存儲在多個相鄰的PDC中，一個PDC中也可能存儲了多個不同的域。

一個PDC由Nm個穩定數據單元成員(persistent data cell member，PDCM)組成。Nm的個數最小為Nmin。組成一個PDC的每個成員都存儲了相同的數據，以保證數據的穩定性。當一個節點希望訪問一個數據記錄時，首先定位到負責這個記錄所在區域的PDC，然后選擇PDC中的某一個成員，向它發送命令。對于查詢命令，這個成員可以單獨處理；對于修改、刪除等需要改變數據的命令，這個成員需要將請求轉發給其他幾個成員，這幾個成員全都確認修改完成后，這個成員提示命令發起節點這次操作成功。

通過復制，PDC也提供了良好的查詢性能。當一個PDC接收的命令過多，導致這個PDC可能超載時，PDC執行分裂或膨脹操作。如果請求主要是由讀數據的請求引起的，這個PDC找到一個新的PDCC加入此PDC；如果請求主要是由寫數據的請求引起的，這個PDC找到Nmin個PDCC，讓它們組成一個新的PDC，并將自己一半的數據分給它。組成PDC節點的數目最大不超過Nmax。如果一個PDC有Nmax個節點之后仍然超載，則將這個PDC再分裂，直到不再超載為止。由于組成PDC的節點數量不多，一個PDC的節點之間通過全相連的方式連接在一起。VGDB中PDC的個數是通過系統需要的存儲量來自動調節的，最初系統中只有一個PDC，隨著全局數據的不斷增加，PDC的個數也會隨之增加。

2系統實現

2.1PDC的構成

每個PDC最初包含Nmin個成員(PDCM)，每個成員都復制了相同的數據。成員之間通過全相連的方式連接在一起。這里假定運行此VGDB的P2P網絡中的每個節點都有一個惟一的ID。每一個成員都保存了該PDC內所有成員信息的二元組(節點ID，節點地址)列表，列表中二元組的順序按照節點ID從低到高的順序排列。

在一個PDC中，具有最低ID的成員自動成為這個PDC的管理員(persistent data cell leader，PDCL)，負責PDC整體的管理及決策工作。PDCL不斷檢查PDC內每個成員是否在線，每隔一段時間對其所負責的所有PDCM發送一次alive消息進行狀態檢查，每個收到此消息的成員將自己目前的負載情況搭載alive確認消息返回給PDCL，PDCL將上次收到的所有成員的負載信息搭載下次的alive檢查消息發送給所有成員，這樣一個PDC內每一個成員都知道其他成員目前的負載情況。當PDCL的alive檢查發現PDC的一個成員離開后，它從PDCC中選擇新的節點加入此PDC。

對于查詢命令，每個PDC的成員都可以單獨進行響應。如果針對此PDC的查詢不斷增加，使得構成這個PDC的所有成員的平均最近可用帶寬很低，則執行膨脹操作。這個PDC的PDCL找出幾個PDCC，給它們復制同樣的數據，然后將它們加入到此PDC中。這樣隨著讀數據請求次數的不斷增加，組成PDC的成員也不斷增加，這個PDC對讀操作的響應能力不斷增強。

對于需要PDC進行寫 (包括添加、更改或刪除)數據的命令，需要更新構成這個PDC的所有成員的數據。可見，如果一個PDC接收的寫數據命令過多，它用于更新所有成員數據的帶寬會增加很多。隨著PDC的擴大，PDC因為寫數據造成超載的可能性也不會增大。對此問題本文后面介紹的數據更新方式會減少一些數據更新占用的帶寬。此外，在寫數據超載時需要執行分裂操作。此時PDCL找到幾個PDCC，將一半的數據分給它們，然后讓它們組成一個新的PDC。這樣隨著寫數據請求次數的不斷增加， PDC不斷分裂，這個PDC對寫操作的響應能力不斷增強。除了寫數據超載可能造成PDC分裂外，當一個PDC所負責的記錄數量超過Cmax時，這個PDC也會產生分裂。

對于PDC之間的組織結構，可以采用SkipList[6]方法。但是為了減少系統內部組織的開銷，本文決定采用不同的方法。像傳統數據庫中很多程序都只使用幾個固定的表一樣，本文預計一個節點經常使用VGDB幾個固定域，而不會經常搜索其他新的域。而且只有普通節點才需要查找負責某個域的PDC，一個PDC通常并不需要查找另一個PDC。基于這種考慮，管理一個域的PDC一般并不直接維持指向管理其他域的PDC的指針。這里使用VGDB的功能來搜索負責某個域的PDC。每個PDC都將自己所負責記錄的范圍作為一條記錄寫入VGDB中，寫入的域為/VGDB PDC/。這個記錄有三個字段：第一個字段是這個PDC的標志，即它所負責記錄的范圍，這個字段是關鍵字段，所有PDC的記錄也按序排列；第二個字段是構成這個PDC的所有成員地址的列表；第三個字段是隱藏字段，它并不參與查詢過程，包含的是這個PDC的公鑰。VGDB中每個PDCM都維護了指向負責域/VGDB PDC/的PDCM的指針。

2.2PDCM之間的數據傳輸

基于膨脹原理，組成一個PDC的成員個數可能大于Nmin，將PDC中ID最小的Nmin個PDCM作為這個PDC的核心成員。由于PDCL的ID在這個PDC中是最小的，它肯定是這個PDC的核心成員。對于刪除、插入等需要更改數據的操作，只要這Nmin個核心成員完成了操作，就認為這個操作成功了。當一個節點希望執行寫入類型的操作(如修改、刪除等改變數據的命令)時，它首先找到負責這個記錄所在范圍的PDC的某個核心成員Ma，并將寫入命令發送給它。Ma收到后立即將寫入命令轉發給其他幾個核心成員，這幾個核心成員全都確認修改完成后，Ma提示命令發起節點這次操作成功。這個操作成功以后更新的數據并不馬上生效。這些核心成員只是將更改的數據暫存起來，并沒覆蓋原有的數據。只有當這個PDC的所有成員(包括普通成員)都接收了數據后，此數據變更才開始生效。

數據從核心成員向普通成員傳送有兩種方式。如果更新數據量較少，可以搭載在alive消息中，則這個PDC的PDCL會每隔一段時間將這個暫存在Nmin個核心成員中的寫入命令發給PDC內普通成員。當所有的成員都確認收到修改內容后，PDCL再在下一個alive消息中搭載一個修改確認的消息發送給所有成員，這個修改的數據此時才開始生效。如果更新的數據量較大，則PDCL會選擇一個時間讓Nmin個核心成員共同傳送數據給普通成員。如果有足夠的可用帶寬，這個發送會馬上進行；否則PDCL會每隔一段時間啟動這個傳送過程。

更新的數據量有可能很大，傳輸這些數據需要花費較多時間。除此之外，分裂及膨脹操作經常需要傳輸較多數據，數據沒有傳輸完之前PDC對命令的響應速度會有一定程度的降低。所以數據傳輸的速度對于PDC響應突然增多的命令的速度影響很大。為了加快大量數據的傳送速度，本文使用類似于Bittorrent下載協議的方式傳輸數據。當PDCL希望發送數據時，給每個需要此數據的節點(PDCM或PDCC)發送一個開始傳輸命令，命令中包含了可以提供此數據的所有PDCM，讓這些需要數據的節點主動從這些數據源PDCM中下載數據。在下載時，每次隨機選擇一條記錄下載，這樣不同的下載者很可能下載了不同的記錄，下載者同時互相交換已經下載的不同記錄。這種方式可以較少地占用數據提供成員的帶寬。

2.3PDCC維護

與前面使用VGDB自身的功能來搜索PDC一樣，這里使用VGDB自身的功能來維護PDCC列表。選擇那些在線時間最少為8 h、 上傳帶寬最小為1 Mbps的系統作為組成PDC的PDCC。通常一個節點的下載帶寬會高于上傳帶寬[7]。一個P2P網絡中的普通節點隨機找幾個鄰居探測自己的下載帶寬，將探測到鄰居的最大下載帶寬作為自己的上傳帶寬數值保存起來。當一個具有1 Mbps以上的上傳帶寬的節點運行8 h以后，它將自己的信息作為數據條目插入到/VGDB Candidate/域中，這個記錄分為節點ID、節點在線時間、節點帶寬、節點地址、CPU速度幾個字段，以第一個字段作為這個記錄的關鍵字段。加入這個域之后，這個節點就成為PDCC。這個PDCC以后每隔一段時間更新一下自己的在線時間記錄。

當PDC需要找到新的PDCC加入PDC時，它從/VGDB Candidate/域中隨機取出幾個在線時間較長的PDCC，探測與它們每一個之間的上傳帶寬，然后選擇上傳帶寬最大、在線時間較長、CPU速度也較快的PDCC作為這個PDC的成員。一個PDCC成為PDCM后，將自己的記錄從/VGDB Candidate/域刪除，以免被再次使用。

當一個PDCC正常離開P2P網絡時，它將自己的信息從/VGDB Candidate/域中刪除；當一個PDCC異常離開P2P網絡時，信息殘留在/VGDB Candidate/域中。當這個PDCC的鄰居發現這個PDCC異常離開后，給管理/VGDB Candidate/的PDC發送一個通知記錄可能過期的命令。這個PDC在接到命令后探測此PDCC是否已經離開系統，如果確認它離開了，則將其記錄刪除。另外，負責/VGDB Candidate/的PDC定期檢查自己所負責的記錄，如果發現有一條記錄超出一段時間后仍然沒有更新在線時間值，并確認其對應的PDCC已經離開系統，則刪除此條記錄。這樣，當PDC需要新的成員時，它從/VGDB Candidate/域中取出的節點通常都是在線的。

3性能分析

在下面的分析和實驗中令Cmax=3MB，Nmin=4，Nmax=100。在實際應用中這幾個參數應根據具體P2P網絡的特性進行取值。

3.1PDC的構成

設基本P2P網絡中全部節點的個數為Na，符合上傳帶寬條件限制的節點的比率為Rb，符合在線時間條件限制的節點的比率為Ru，則P2P網絡中可用的PDCC的個數Nc可以如下計算：

Nc = Na×Rb× Ru(1)

對于Kad，平均約有40%的節點具有8 h以上的在線時間[8]，約有35%的節點具有1 Mbps以上的上傳帶寬，且具有高帶寬的節點也趨向于有低的延遲[7]。因而可以令P2P網絡中符合PDCC的在線時間條件的節點的比率Ru為0.4，令P2P網絡中符合PDCC的帶寬條件的節點的比率Rb為0.35。根據式(1)，P2P網絡中可用的PDCC的個數Nc = 0.4×0.35×Na =0.14×Na，即P2P網絡中可成為PDCC的節點約占所有節點數量的14%。

設VGDB中可以存儲的數據容量為Cv，每個PDC可以提供的空間容量為Co，每個PDC成員的個數為Nm，則

Cv = Co×Nc/Nm(2)

令每個PDC提供的存儲空間的容量Co為Cmax，如果每個PDC的成員個數限制為最少的Nmin個，則根據式(2)，VGDB可以提供的最大容量max(Cv)=3 MB×Nc/4=(0.105×Na) MB。所以，當eMule類型的P2P網絡中有10 000個節點時，VGDB可以提供的最大數據容量大約為1 GB。

3.2讀命令相應能力分析

假設PDCM所具有的平均上傳帶寬為Bu，平均每次查詢的數據量為Sq，一個PDC對讀命令可以響應的次數Nr則如下計算：

Nr = Nm×Bu / Sq (3)

如前所述，在由于讀操作造成超載時，PDC可以膨脹，最大可以膨脹到Nmax個成員。將Bu取為PDCC的上傳帶寬最小值1 Mbps。當PDC成員數量Nm達到Nmax時，1 min內可以響應的平均大小為1 KB的查詢次數Nr =100×(1 Mbps/10)/1 KB×60=600 000次。如果還是不能滿足查詢要求，則PDC還可以通過分裂數據提高查詢的響應能力。由此可見PDC對于查詢的響應能力相當強，足以滿足幾乎所有應用的需要。

3.3寫命令響應能力分析

在節點向PDC寫入數據時，只要這個PDC的Nmin個核心成員的數據更新成功了，這個寫數據的操作就成功了。所以一個PDC對寫命令的響應次數主要與這Nmin個核心成員有關。當一個核心成員收到此數據的請求時，需要使用Nmin-1倍于這個數據的帶寬將這個數據發送給其他幾個核心成員。令PDCC所具有的平均上傳帶寬為Bd，一個PDC對寫入命令可以響應的次數Nw可如下計算：

Nw = Nmin×Bd / (Nmin-1)(4)

可見，對于PDC的寫入操作并不能通過膨脹的方式來提高對寫入操作的響應能力。通常一個節點的下載帶寬會高于上傳帶寬[7]，因而這里也可將Bd取為PDCC帶寬的最小值1 Mbps，則一個PDC在1 min內可以響應的平均大小為1KB的寫入命令的次數Nw=(1 Mbps/10)/1 KB×60 = 6 000。如果這個PDC中的平均記錄大小也為1 KB，則它可以容納的記錄的數量為3 MB/1 KB = 3 000個。即它1 min之內可以讓一個記錄修改兩次。鑒于VGDB中多數域的控制策略都只允許一條記錄的所有者修改或刪除此記錄，所以一個節點1 min之內可以修改兩次記錄的頻率一般能夠滿足多數應用的要求。如果實際修改頻率高于這個頻率，則需要通過讓這個PDC分裂的方式來提高寫入命令響應次數。例如上面的例子PDC分裂一次，它容納的記錄就減少為1 500個，可以讓一條記錄1 min之內修改的次數達到4次。這樣，隨著寫入頻率的提高，它一直分裂下去。分裂的極端情況將允許一條記錄在1 min內修改6 000次。

3.4數據穩定性分析

設數據傳輸速度為1 Mbps，則給一個PDCC傳輸完這個PDC所負責的數據(最大為Cmax)最多需要30 s。加上一些額外的時間(如PDCL檢測PDCM離開的時間和選擇PDCC的時間)，總的TTR(time to repair)最長不會超過60 s。

使用PDCM數據緊急恢復方案，只要在最長的TTR時間內一個PDC的所有節點沒有同時退出系統，這個PDC的數據就不會丟失。已經在線時間為8 h的節點，平均剩余在線時間為6 h左右，且1 h之內離開的百分比約為10%[8]。據此可知組成PDC的一個成員在1 h內數據丟失的概率為10%，則在最長TTR時間1 min內4個節點全部離開系統的概率為 (0.1/60)4 = 7.716×10-12。所以一個PDC的MTTDL0為1/7.716×10-12 = 246 575.342年。如果VGDB中總共有1 GB數據，則整個VGDB的MTTDLa = MTTDL0/1 GB×3 MB=739.7年。這個穩定性足以滿足絕大多數系統所需的數據穩定性。如果有系統希望達到更高的可靠性，可以讓PDC的最少成員個數增加到Nmin個以上。

4實驗及分析

4.1實驗方法

本文參考Narses[9]和QueryCycle[10]中的方法對eMule類型的基本P2P網絡活動進行了模擬。在模擬的具有10 000個節點的基本P2P網絡之上實現了VGDB，并使用各種不同的參數測試了VGDB的性能。

這里主要根據QueryCycle中的方法為每個節點指定參數。QueryCycle中的文件類型分布和在線時間分布是鑒于對Napster和Gnutella的測量結果[7]，而目前最流行的P2P系統不是這兩個系統。所以對于在線時間的分布，這里使用文獻[8]中測量的KAD(eMule)的節點的在線時間分布。每個節點的帶寬和延遲是根據文獻[7]中的測量結果指定的。在模擬網絡拓撲時使用Narses中提出的最小共享分配技術為數據流分配帶寬，這樣能夠快速對具有10 000節點的基本P2P網絡活動進行模擬。

在模擬基本P2P網絡之上實現了VGDB。在基本P2P網絡運行8 h后的100 s加入第一個PDC，讓VGDB開始運轉起來，但是這時并不發出測試VGDB的讀寫命令。在基本P2P網絡運行8 h后的200 s，開始發出測試VGDB的讀寫命令。設每個記錄的大小為2 KB，通過改變讀寫命令的以下4個參數來觀察VGDB的性能：

a)讀命令頻率Fq，即平均每幾秒產生一個讀命令；

b)讀命令數據量Nq，即平均每個讀命令需要傳輸的記錄條數；

c)寫命令頻率Fi，即平均每幾秒產生一個寫命令；

d)寫命令數據量Ni，即平均每個寫命令需要傳輸的記錄條數。

本文主要希望測試VGDB的性能，從而避免因為基本P2P網絡的命令發起節點的可用帶寬太低引起造成對命令響應時間的影響。在命令發起節點讀命令的數據量大于自己的可用下載帶寬時，將數據量限制為可用下載帶寬。在命令發起節點寫命令的數據量大于自己的可用上傳帶寬時，將數據量限制為可用上傳帶寬。這樣可以更好地觀察VGDB對命令的響應時間，而不會減少與VGDB傳輸的數據量。

開始測試讀寫命令之后，記錄每個讀寫命令的發出時間和結束時間，讀寫測試運行5 h后停止。如果一個讀寫命令10 s還沒有結束，就認為這個命令超時了。以下圖中橫坐標的起點就是基本P2P網絡運行8 h后的第201 s。

4.2實驗結果

首先測試參數（Fq=1;Nq=1; Fi=1; Ni=1）。即每個節點平均每秒發出一個讀命令，每條讀命令讀一條記錄；平均每秒發出一個寫命令，每條寫命令寫一條記錄。測試結果如圖2所示。圖2(a)中橫坐標是從P2P運行8 h 200 s后的時間，縱坐標是VGDB對命令響應時間。從圖中可以看到有一些大的波動。節點的日志顯示，在平均響應時間有大的波動的時刻，VGDB中發生了一些PDC的分裂和膨脹。在開始的1.5 min里，VGDB的響應時間非常長，這段時間里因為有大量的節點同時發出讀寫命令，而這時PDC的數量只有一個，所以這段時間里發生了大量PDC的分裂和膨脹；這段時間過后，VGDB的響應時間就比較平穩了。從圖2(b)中可看出，80%以上的讀命令可以在0.28 s內完成，80%以上的寫命令可以在1.0 s內完成。VGDB對讀命令的響應時間明顯比對寫記錄的響應時間少，這是因為PDC的寫操作需要這個PDC的Nmin個核心成員全部收到數據才能成功。

下面測試在命令逐漸增加時VGDB的響應能力。令參數逐漸變化，從（Fq=100;Nq=1; Fi=100;Ni=1）逐漸過渡到（Fq=1;Nq=500;Fi=1; Ni = 500）。測試結果顯示在圖3中。如圖3(a)所示，VGDB在命令適量逐漸增加時對讀命令的響應能力相對比較平穩，但是對寫命令的響應時間有很多波動。從圖3(b)可以看出，VGDB對大多數寫命令的響應時間還是讓人比較滿意的。

在測試最后20 min時間里，讀寫相應次數突然升高。分析日志發現，這是由于系統中可用的PDCC不足，使PDC無法再繼續分裂和膨脹造成的。這意味著在VGDB已經寫入大量數據后，每個節點每8 s發出一個讀920 KB數據的命令；每8 s發出一個寫920 KB數據的命令，這時VGDB會超載。這個性能是相當讓人滿意的。



圖3參數:Fq=100~1;Nq=1~500;Fi=100~1;Ni=1~500

5結束語

可靠的全局數據中心對于P2P網絡實現復雜的查詢等重要功能有很大幫助。目前不使用固定服務器的P2P網絡無法實現一些重要功能，而使用固定服務器的P2P網絡是比較脆弱的，并且在突發大量訪問時性能會出現大幅下降。為了解決這個問題，本文設計了一種基于P2P網絡的VGDB。VGDB運行在基本的非結構化或結構化P2P網絡之上，使用構成P2P網絡的不穩定的Internet節點自發組成可靠的全局數據庫，為基本的P2P網絡中的節點提供了全局數據管理中心。分析和實驗表明VGDB在存儲量、數據穩定性、數據訪問速度、檢索靈活性等方面表現非常突出。

參考文獻:

[1]

周曉波，周健，盧漢成，等.一種基于層次化興趣的非結構化P2P拓撲形成模型[J].軟件學報，2007，18(12):31313138.

[2]SARSHAR N， ROYCHOWDHURY V P. An endtoend solution to scalable unstructured P2P networking[C]//Proc of the 7th International Conference on PeertoPeer Computing. Galway: IEEE Computer Society， 2007:123131.

[3]ZHUGE Hai， CHEN Xue， SUN Xiaoping， et al. HRing: a structured P2P overlay based on harmonic series [J]. IEEE Trans on Parallel and Distributed Systems， 2008，19(2):145158.

[4]夏啟志，謝高崗，閔應驊，等.ISP2P:一種基于索引的結構化P2P網絡模型[J].計算機學報，2006，29(4):602610.

[5]JELASITY M， MONTRESOR A， BABAOGLU O. Gossipbased aggregation in large dynamic networks[J]. ACM Trans on Computer Systems， 2005，23(3):219252.

[6]ZHANG Chi， KRISHNAMURTHY A， WANG R Y. Brushwood: distributed trees in peertopeer systems[C]//Proc of the 4th International Workshop on PeertoPeer Systems. New York: SpringerVerlag，2005:4757.

[7]SAROIU S， GUMMADI P K， GRIBBLE S D. A measurement study of peertopeer file sharing systems[C]//Proc of Conference on Multimedia Computing and Networking. San Jose: IEEE Computer Society， 2002:156170.

[8]STUTZBACH D， REJAIE R. Characterizing churn in peertopeer networks [D]. Eugene: University of Oregon， 2005.

[9]GIULI T， BAKER M. Narses: a scalable flow based network simulator [D]. Stanford: Stanford University， 2002.

[10]SCHLOSSER M， KAMVAR S. Simulating a filesharing P2P network[C]//Proc of the 1st Workshop on Semantics in P2P and Grid Computing. Budapest: SpringerVerlag， 2002:6980.