分布式存儲系統(tǒng)在通信運營商中的應(yīng)用分析

黃柳

【摘要】? ? 隨著運營商的網(wǎng)路的發(fā)展，數(shù)據(jù)大部分存儲在不同的區(qū)域網(wǎng)絡(luò)，所以數(shù)據(jù)管理系統(tǒng)將面臨數(shù)據(jù)的存取效率以及確保取得的數(shù)據(jù)內(nèi)容一致的問題。針對數(shù)據(jù)分散存儲與數(shù)據(jù)存取的問題，本論文提出一個通過階層式邏輯數(shù)據(jù)索引與快取的設(shè)計建立在分布式數(shù)據(jù)管理系統(tǒng)中的數(shù)據(jù)存取機制，在現(xiàn)有網(wǎng)絡(luò)帶寬與架構(gòu)下，提供更有效率的數(shù)據(jù)傳輸與數(shù)據(jù)管理。

【關(guān)鍵詞】? ? 分布式數(shù)據(jù)存取? ? 階層式索引? ? 分散存儲

引言：

現(xiàn)今數(shù)據(jù)管理系統(tǒng)的數(shù)據(jù)大部分存儲在不同的區(qū)域網(wǎng)絡(luò)，且數(shù)據(jù)存放越來越分散，如何做到有效率的管理十分重要。對于此種情況，使用者取數(shù)據(jù)的存取效率以及使用者取得的數(shù)據(jù)內(nèi)容一致的問題變得更繁瑣。

以上所面臨的問題可分為：1.數(shù)據(jù)內(nèi)容一致性問題：由于數(shù)據(jù)內(nèi)容可能不斷持續(xù)在更新，即使采用異地備份或數(shù)據(jù)復(fù)制機制，數(shù)據(jù)的同步仍須配合復(fù)雜的算法才能達成;2.數(shù)據(jù)存取效率問題：使用者必須從遠端下載文件至本端，如果有多線程同時下載文件，將會導(dǎo)致原本的網(wǎng)絡(luò)帶寬不敷使用。沒有效率的數(shù)據(jù)存取機制將會用盡所有網(wǎng)絡(luò)帶寬，甚至影響到正在運作的其他系統(tǒng)。任由使用者在服務(wù)器間傳輸大量數(shù)據(jù)，對運營商來說是一個無形的成本支出。

我們將重點放在如何快速有效率的取得遠端數(shù)據(jù)，尋求更好更佳的解決辦法，在不改變現(xiàn)在低效能的網(wǎng)絡(luò)帶寬與架構(gòu)下，系統(tǒng)能自動適應(yīng)使用者位置，自動調(diào)整數(shù)據(jù)存取位置的分布式數(shù)據(jù)管理系統(tǒng)，希望能滿足運營商所需的數(shù)據(jù)集中管理、分散存儲的需求。

一、適應(yīng)性數(shù)據(jù)存取機制

本論文主要在不改變運營商現(xiàn)有的網(wǎng)絡(luò)架構(gòu)與帶寬的情況下，大量提升數(shù)據(jù)管理與存取效率，提供運營商完整的數(shù)據(jù)管理解決方案。此方法的重點在于設(shè)計通過集中管理的知識地圖，提供使用者一個一致性的存取界面，通過這個界面，使用者可以從任何地方進行數(shù)據(jù)存取的動作，而做到數(shù)據(jù)集中管理、分散存儲的管理機制。另一重點則是實體文件分散存儲，系統(tǒng)必須能自動適應(yīng)使用者所在位置，并且動態(tài)的調(diào)整回復(fù)實體文件的文件服務(wù)器。

通過快取機制（Cache）的設(shè)計、多層邏輯文件索引等使用者適應(yīng)性機制的建立，所有的使用者將只通過本地端的文件服務(wù)器存取文件，如此可讓99%以上的數(shù)據(jù)存取效率與本地數(shù)據(jù)存取效率幾乎一樣快。各個客戶端的文件樹通過中間層的分布式文件服務(wù)器（Distributed File Server），對應(yīng)至各個不同地區(qū)存儲器的實體文件。黃色部分為文件服務(wù)器之間互相快?。–ache）的實體文件。

此系統(tǒng)的軟件架構(gòu)如圖2所示，整個適應(yīng)性分布式數(shù)據(jù)存取系統(tǒng)大致上可以分為兩個主要子系統(tǒng)，分別為DMS服務(wù)器（Document Management System）以及DMS文件服務(wù)器。一個DMS可以連接多個DMS文件服務(wù)器，每DMS文件服務(wù)器也會借由內(nèi)部的Cache Policy模塊連接到其他 DMS文件服務(wù)器或通過索引分割樹（Index Partitioner）來與下一階層的DMS文件服務(wù)器互動。以下將描述本架構(gòu)的內(nèi)部設(shè)計。

1.1 DMS服務(wù)器

DMS服務(wù)器主要負責(zé)接收所有的使用者的請求。對于Metadata的相關(guān)請求，則于DMS服務(wù)器直接回應(yīng)，如果是對于遠端文件的上傳或下載請求，則會通過Adaptive File Server Locator 模塊的判斷，將該請求送到對應(yīng)的DMS文件服務(wù)器。DMS服務(wù)器主要由Global Document Index、Adaptive File Server Locator、GlobelIndex Partitioiner 、Metadata Manager 、File Server Manager以及Authentication/Authorization 模塊組成。以下概述2個核心模塊的主要功能。

1.2 Global Index Partitioner

此模塊的主要功能是將運營商內(nèi)的單一知識地圖切成許多個子地圖，分別由一個DMS文件服務(wù)器來負責(zé)存儲。圖2-3可以清楚描述設(shè)計該模塊的主要目的。樹狀結(jié)構(gòu)即是運營商內(nèi)部完整的知識文件地圖。FS1～FS4各代表不同文件關(guān)系樹，整個完整的文件樹可以被切分為三個主要Partition，而每一個Partition分別為文件服務(wù)器FS1， FS2與FS3負責(zé)。其中FS4為FS2的下游文件服務(wù)器。此外，系統(tǒng)也可以再將 FS2的其中一個文件交由FS4管理。如此，通過 FS2 與FS4的委托關(guān)系，便可建構(gòu)出階層式的文件服務(wù)器軟件架構(gòu)。

1.3 Cache Policy 模塊

Cache Policy 模塊負責(zé)管理當(dāng)?shù)厥褂谜叽嫒∥募r，發(fā)生Cache miss的文件實體文件。目前我們規(guī)劃的Cache Policy如下：

1.3.1Cache in policy

我們預(yù)計將文件快取的模式分為以下三種：要求模式（On-Demand）、定期模式（Periodical）以及手動模式（Manual）。要求模式是指當(dāng)使用者有文件下載，但發(fā)生 Cache miss時，立刻啟動快取機制（Cache），將文件從遠端的DMS文件服務(wù)器快取到目前的DMS文件服務(wù)器。定期模式則是每天固定時間將其他 DMS文件服務(wù)器的文件快取到目前的DMS文件服務(wù)器。手動模式則是管理者隨時可以決定要快取那個文件到DMS文件服務(wù)器中，可以提供臨時的數(shù)據(jù)傳輸需求。至于系統(tǒng)將采用哪種模式的Cache策略則由管理者自行決定。

1.3.2 Cache out policy

我們將根據(jù)管理者設(shè)定的Cache Size，在Cache Size 剩下不到管理者設(shè)定的threshold時，于半夜啟動Cache out機制。而Cache out的算法則采用LRU （Least Recently Used）的方式，將最少用到的快取文件清除。

1.Data Transmission。此模塊主要負責(zé)文件的傳輸，需要特別獨立此模塊是因為部分產(chǎn)業(yè)的文件Size非常大，需要特別管理上傳的文件格式、以及傳輸時間。尤其當(dāng)通過Web的方式上傳、下載文件時，常會發(fā)生暫停（timeout）的問題，必須通過數(shù)據(jù)傳送（Data transmission）模塊專責(zé)處理相關(guān)問題。

2.Index Bridge。此模塊負責(zé)將邏輯的文件索引，對應(yīng)到實際的文件存儲位置。例如可以將DMS服務(wù)器的＼root＼SOP＼請假標(biāo)準(zhǔn)程序，對應(yīng)到DMS文件服務(wù)器FS1的＼SOP＼請假標(biāo)準(zhǔn)程序，再對應(yīng)到FS1的d：＼00000001＼00000002.doc?；虍?dāng)FS1 后端的文件系統(tǒng)是NFS時，則必須對應(yīng)到/user/home/files_server/001/003.doc。通過這個模塊的構(gòu)建，我們可以將實體文件存儲的文件系統(tǒng)以及存儲空間做很好的分離切割。如此才能連接到運營商既有的所有大型的存儲空間。

二、 效果分析

我們通過一般網(wǎng)絡(luò)傳輸速度來分析所提出的算法。假設(shè)有兩個文件服務(wù)器分別架設(shè)于A地與A地兩地，其網(wǎng)絡(luò)架構(gòu)是雙向512K，本地端的內(nèi)部網(wǎng)絡(luò)速度為100MByte/sec。以下分別分析有無使用適應(yīng)性數(shù)據(jù)存取機制的數(shù)據(jù)存取狀況，其中A代表文件在網(wǎng)絡(luò)上的傳輸時間、B代表文件存儲時間、C代表使用者端文件開啟時間。

表1為一般網(wǎng)絡(luò)文件下載情況，表2為有適應(yīng)性數(shù)據(jù)存取機制的數(shù)據(jù)存取分析且DMS服務(wù)器位于中國，那么數(shù)據(jù)傳輸?shù)臅r間如表（以10M文件大小計算），精確的時間尚須視使用者的機器設(shè)備能力而定。

以上計算方式均以理論值的最大極限計算，不考慮平時網(wǎng)絡(luò)被其他應(yīng)用系統(tǒng)或數(shù)據(jù)傳輸所占據(jù)帶寬的情況。在使用適應(yīng)性數(shù)據(jù)存取機制的情況下，使用者如下載為非文件服務(wù)器所擁有的文件或非Cache文件則只須花費一次遠端下載時間，之后其他使用者只須花費本地端下載時間，由結(jié)果得知，此作法大大減少多端點與不同網(wǎng)域文件下載時間。

三、結(jié)束語

目前運營商多屬地域公司，運營商最重要的智慧資產(chǎn)就是數(shù)據(jù)，往往會因為數(shù)據(jù)維護單位的設(shè)立地點不同而導(dǎo)致數(shù)據(jù)散落在各個地區(qū)，此外中國信息部門對于關(guān)連式數(shù)據(jù)庫的技術(shù)依賴性太高，導(dǎo)致有很多新的系統(tǒng)功能無法被快速開發(fā)，多層次的邏輯文件索引，以及適應(yīng)文件服務(wù)器的Cache即是最好的解決辦法。

本論文設(shè)計的適應(yīng)性的分布式數(shù)據(jù)存取系統(tǒng)，提供自動化的適應(yīng)能力，根據(jù)使用者來源，調(diào)整數(shù)據(jù)回復(fù)的文件服務(wù)器，以及設(shè)計邏輯文件索引與 Cache來加強數(shù)據(jù)存取的效能，希望能有助于建構(gòu)適用于目前運營商網(wǎng)絡(luò)架構(gòu)與帶寬的高效能分布式數(shù)據(jù)管理系統(tǒng)。

參? 考? 文? 獻

[1]王意潔，孫偉東，周松，等. 云計算環(huán)境下的分布存儲關(guān)鍵技術(shù)[J]. 軟件學(xué)報，2012，（4）：962-986.doi：10.3724/SP.J.1001.2012.04175.

[2]覃雄派，王會舉，李芙蓉，等. 數(shù)據(jù)管理技術(shù)的新格局[J]. 軟件學(xué)報，2013，（2）：175-197.

[3]葉小平，湯庸，林衍崇，等. 時態(tài)數(shù)據(jù)索引TDindex研究與應(yīng)用[J]. 中國科學(xué)（信息科學(xué)），2015，（8）：1025-1045

[4]葉小平，湯庸，林衍崇，等. 時態(tài)擬序數(shù)據(jù)結(jié)構(gòu)研究及應(yīng)用？[J]. 軟件學(xué)報，2014，（11）：2587-2601.

[5]劉玲玲. 分布式大數(shù)據(jù)云存儲技術(shù)分析[J]. 數(shù)碼設(shè)計（上），2018，（6）：169.

[6]周西柳. 面向大數(shù)據(jù)的分布式存儲技術(shù)研究[J]. 電腦迷，2016，（3）：136-136.

[7]劉圓，王峰，楊明川. 面向大數(shù)據(jù)的分布式存儲技術(shù)研究[J]. 電信技術(shù)，2015，（6）：33-36.

[8]姚迎樂，張志華. 面向大數(shù)據(jù)的并行數(shù)據(jù)分布式備份存儲仿真[J]. 計算機仿真，2018，35（8）：401-404，409.

[9]胡健，袁軍，王遠. 面向電網(wǎng)大數(shù)據(jù)的分布式實時數(shù)據(jù)庫管理系統(tǒng)[J]. 電力信息與通信技術(shù)，2015，13（2）：49-54.