黃柳

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

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

引言：

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

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

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

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

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

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

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

1.1 DMS服務器

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

1.2 Global Index Partitioner

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

1.3 Cache Policy 模塊

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

1.3.1Cache in policy

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

1.3.2 Cache out policy

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

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

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

二、 效果分析

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

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

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

三、結束語

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

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

參? 考? 文? 獻

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

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

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

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

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

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

[7]劉圓，王峰，楊明川. 面向大數(shù)據(jù)的分布式存儲技術研究[J]. 電信技術，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]. 電力信息與通信技術，2015，13（2）：49-54.