面向API調(diào)用的開(kāi)放數(shù)據(jù)存儲(chǔ)管理研究

劉海房 莫世鴻 龔 振 范冰冰

(華南師范大學(xué)計(jì)算機(jī)學(xué)院 廣東 廣州 510631)

0 引 言

隨著互聯(lián)網(wǎng)及移動(dòng)互聯(lián)網(wǎng)的不斷發(fā)展，人類(lèi)生產(chǎn)、生活等各領(lǐng)域數(shù)據(jù)信息量呈爆炸性增長(zhǎng)，其中大量數(shù)據(jù)為政府、組織機(jī)構(gòu)、企業(yè)所擁有。目前數(shù)據(jù)已是生產(chǎn)要素和戰(zhàn)略資源，數(shù)據(jù)開(kāi)放共享成為大數(shù)據(jù)應(yīng)用發(fā)展的基礎(chǔ)和保障，社會(huì)對(duì)開(kāi)放數(shù)據(jù)的需求越來(lái)越強(qiáng)烈[1]。近年來(lái)，各國(guó)政府、組織機(jī)構(gòu)、企業(yè)等紛紛加入數(shù)據(jù)開(kāi)放的浪潮中，主要國(guó)家和組織機(jī)構(gòu)均已建立數(shù)據(jù)開(kāi)放平臺(tái)，開(kāi)放交通、醫(yī)療、稅務(wù)等幾十個(gè)領(lǐng)域的龐大數(shù)據(jù)，部分企業(yè)也制定了數(shù)據(jù)開(kāi)放戰(zhàn)略，對(duì)擁有的海量數(shù)據(jù)實(shí)施開(kāi)放[2]。

開(kāi)放數(shù)據(jù)一般以數(shù)據(jù)集的形式進(jìn)行發(fā)布，數(shù)據(jù)集是被標(biāo)識(shí)且能夠被系統(tǒng)或設(shè)備識(shí)別處理的數(shù)據(jù)集合，是一種數(shù)據(jù)資源收集與組織的新型數(shù)據(jù)組織方式和數(shù)據(jù)資源的“封裝”單元[3]。開(kāi)放數(shù)據(jù)的數(shù)據(jù)集一般包含若干個(gè)文件和數(shù)據(jù)集描述信息(數(shù)據(jù)集元數(shù)據(jù))，如“上市公司財(cái)報(bào)”數(shù)據(jù)集，包含一個(gè)記錄財(cái)報(bào)數(shù)據(jù)的JSON文件，同時(shí)還包含數(shù)據(jù)集名稱(chēng)、發(fā)布者等數(shù)據(jù)集描述信息。數(shù)據(jù)文件可分為結(jié)構(gòu)化文件、半結(jié)構(gòu)化文件和非結(jié)構(gòu)化文件，文件大小各異。數(shù)據(jù)集發(fā)布者可以對(duì)數(shù)據(jù)集進(jìn)行新增、刪除、更新等操作，但頻率較低。獲取開(kāi)放數(shù)據(jù)主要有數(shù)據(jù)集下載和API調(diào)用兩種方式，數(shù)據(jù)集下載方式不足有：對(duì)數(shù)據(jù)集完全下載，針對(duì)應(yīng)用數(shù)據(jù)需進(jìn)一步加工處理，無(wú)法和業(yè)務(wù)系統(tǒng)直接對(duì)接。API調(diào)用是通過(guò)API有條件(如時(shí)間、地理空間、關(guān)聯(lián)等)精確獲取所需數(shù)據(jù)，調(diào)用方式靈活便捷、響應(yīng)快。未來(lái)的業(yè)務(wù)系統(tǒng)和智能應(yīng)用將會(huì)更多依賴(lài)API方式調(diào)用獲取數(shù)據(jù)。

目前，國(guó)際上大部分?jǐn)?shù)據(jù)開(kāi)放平臺(tái)基于CKAN、DKAN開(kāi)源框架搭建[4]，通過(guò)關(guān)系型數(shù)據(jù)庫(kù)和文件系統(tǒng)存儲(chǔ)管理開(kāi)放數(shù)據(jù)，將數(shù)據(jù)集元數(shù)據(jù)存儲(chǔ)在關(guān)系型數(shù)據(jù)庫(kù)中，將數(shù)據(jù)文件存儲(chǔ)在文件系統(tǒng)，文件路徑存儲(chǔ)到對(duì)應(yīng)的數(shù)據(jù)表中，如圖1所示。這種傳統(tǒng)的開(kāi)放數(shù)據(jù)管理方式，能提供基于數(shù)據(jù)集元數(shù)據(jù)的數(shù)據(jù)集檢索和下載功能，但不支持高效可用的API[5]，制約了開(kāi)放數(shù)據(jù)應(yīng)用發(fā)展。為了支持API數(shù)據(jù)調(diào)用，同時(shí)考慮未來(lái)海量的開(kāi)放數(shù)據(jù)，需要一種新的開(kāi)放數(shù)據(jù)存儲(chǔ)管理模型，對(duì)開(kāi)放數(shù)據(jù)的各類(lèi)形式數(shù)據(jù)進(jìn)行有效管理，且具有較高的API調(diào)用效率。

圖1 傳統(tǒng)開(kāi)放數(shù)據(jù)存儲(chǔ)管理方式

1 ODSMM開(kāi)放數(shù)據(jù)存儲(chǔ)管理模型

ODSMM模型示意圖如圖2所示，對(duì)數(shù)據(jù)集元數(shù)據(jù)、文件、結(jié)構(gòu)化數(shù)據(jù)進(jìn)行存儲(chǔ)管理，結(jié)構(gòu)化數(shù)據(jù)是對(duì)結(jié)構(gòu)化和半結(jié)構(gòu)化文件數(shù)據(jù)轉(zhuǎn)換后得到的具體內(nèi)容數(shù)據(jù)。ODSMM模型使用MongoDB[6]作為存儲(chǔ)載體，將所有數(shù)據(jù)集元數(shù)據(jù)存儲(chǔ)在一個(gè)獨(dú)立的元數(shù)據(jù)集合中，利用MongoDB良好的擴(kuò)展性及支持大文件存儲(chǔ)等特性，將數(shù)據(jù)文件及文件描述信息(文件元數(shù)據(jù))根據(jù)文件大小存儲(chǔ)到小文件集合或GridFS中[7]，利用MongoDB在海量結(jié)構(gòu)化數(shù)據(jù)處理方面的優(yōu)越性能及模式自由等特性，將每個(gè)數(shù)據(jù)集的結(jié)構(gòu)化數(shù)據(jù)分別存儲(chǔ)在一個(gè)集合中[8]。元數(shù)據(jù)集合中每個(gè)文檔存儲(chǔ)一個(gè)數(shù)據(jù)集元數(shù)據(jù)，同時(shí)存儲(chǔ)該數(shù)據(jù)集對(duì)應(yīng)的所有文件引用及對(duì)應(yīng)的結(jié)構(gòu)化數(shù)據(jù)集合引用。

基于ODSMM模型，在數(shù)據(jù)集檢索時(shí)，應(yīng)用程序調(diào)用MongoDB接口從數(shù)據(jù)集元數(shù)據(jù)集合中查找滿(mǎn)足條件的數(shù)據(jù)集。在數(shù)據(jù)集下載時(shí)，應(yīng)用程序先通過(guò)文件大小判斷文件存儲(chǔ)在GridFS還是小文件集合，再通過(guò)文件ID定位到具體文件，調(diào)用相應(yīng)的MongoDB接口讀取文件二進(jìn)制數(shù)據(jù)。在A(yíng)PI調(diào)用時(shí)，先傳入篩選條件、排序字段及排序方式等參數(shù)，再根據(jù)頁(yè)碼及每頁(yè)大小定位到數(shù)據(jù)起始位置，調(diào)用相應(yīng)的MongoDB接口從結(jié)構(gòu)化數(shù)據(jù)集合中精確查找出滿(mǎn)足條件的數(shù)據(jù)。所以O(shè)DSMM模型不僅能夠支持通過(guò)數(shù)據(jù)集下載方式獲取數(shù)據(jù)，而且能夠支持通過(guò)API調(diào)用方式獲取數(shù)據(jù)。

1.1 數(shù)據(jù)集描述與元數(shù)據(jù)存儲(chǔ)

為了更方便存儲(chǔ)管理開(kāi)放數(shù)據(jù)，需對(duì)數(shù)據(jù)集進(jìn)行描述，數(shù)據(jù)集描述的元數(shù)據(jù)主要包括數(shù)據(jù)集名稱(chēng)、簡(jiǎn)介、創(chuàng)建時(shí)間、發(fā)布者、關(guān)鍵字等核心元數(shù)據(jù)[9]，還包括文件個(gè)數(shù)、文件引用等擴(kuò)展元數(shù)據(jù)。如果數(shù)據(jù)文件為結(jié)構(gòu)化或半結(jié)構(gòu)化文件，為了了解文件內(nèi)部數(shù)據(jù)結(jié)構(gòu)和提供更詳細(xì)的接口說(shuō)明，還需要添加結(jié)構(gòu)化數(shù)據(jù)描述相關(guān)的擴(kuò)展元數(shù)據(jù)，如字段描述信息、結(jié)構(gòu)化數(shù)據(jù)集合大小、結(jié)構(gòu)化數(shù)據(jù)集合引用等。通過(guò)查看數(shù)據(jù)集元數(shù)據(jù)，可以大致了解一個(gè)數(shù)據(jù)集的基本信息。

在ODSMM模型中，元數(shù)據(jù)存儲(chǔ)程序調(diào)用MongoDB接口將數(shù)據(jù)集元數(shù)據(jù)存儲(chǔ)到元數(shù)據(jù)集合中，該集合中每個(gè)文檔都存儲(chǔ)了一個(gè)數(shù)據(jù)集的基本信息。為了能夠在數(shù)據(jù)集查找及下載時(shí)找到對(duì)應(yīng)的文件，每個(gè)元數(shù)據(jù)文檔還存儲(chǔ)了文件引用，隨著數(shù)據(jù)集的更新，很可能一個(gè)數(shù)據(jù)集包含多個(gè)文件，所以使用數(shù)組來(lái)存儲(chǔ)所有文件引用。為了能夠在A(yíng)PI調(diào)用時(shí)找到對(duì)應(yīng)的結(jié)構(gòu)化數(shù)據(jù)，每個(gè)元數(shù)據(jù)文檔還存儲(chǔ)了結(jié)構(gòu)化數(shù)據(jù)集合引用。此外，因結(jié)構(gòu)化數(shù)據(jù)字段描述信息較復(fù)雜，所以采用BSON數(shù)組來(lái)存儲(chǔ)字段描述信息。數(shù)據(jù)集元數(shù)據(jù)集合詳細(xì)存儲(chǔ)結(jié)構(gòu)如下所示：

{

″_id″:ObjectId(″IDENTIFIER″),

″title″: ″TITLE″,

″publisher″: ″PUBLISHER″,

″creator″: ″CREATOR″,

″date″: DATE_ TIMESTAMP,

″language″: ″LANGUAGE″,

″rights″: ″RIGHTS″,

″modified″: MODIFIED_ TIMESTAMP,

″description″: ″DESCRIPTION″,

″category″: ″CATEGORY″,

″keyword″: ″KEYWORD″,

″fileCount″: COUNT_INTEGER,

″dataCount″: COUNT_INTEGER,

″files″:[

ObjectId(″FILE_ID1″),

ObjectId(″FILE_ID2″)

],

″fields″: [

{

″name″: ″NAME″,

″type″: ″TYPE″,

″value″: ″VALUE″,

″description″: ″DESCRIPTION″

},

{

″name″: ″NAME″,

″type″: ″TYPE″,

″value″: ″VALUE″,

″description″: ″DESCRIPTION″

}

],

″ref″: ″DATA_COLLECTION″

}

1.2 文件管理

為了更方便存儲(chǔ)管理數(shù)據(jù)文件，首先需對(duì)單個(gè)文件進(jìn)行描述，主要包括文件名、文件大小、文件格式、上傳時(shí)間、下載次數(shù)等信息，這些描述文件的屬性稱(chēng)為文件元數(shù)據(jù)。在ODSMM模型中，文件管理主要是對(duì)文件元數(shù)據(jù)，結(jié)構(gòu)化文件、半結(jié)構(gòu)化文件和非結(jié)構(gòu)化文件進(jìn)行存儲(chǔ)管理。MongoDB使用了BSON(Binary JSON)格式存儲(chǔ)數(shù)據(jù)，無(wú)需定義任何結(jié)構(gòu)，可以把完全不同結(jié)構(gòu)的數(shù)據(jù)存儲(chǔ)到一個(gè)集合。目前由于MongoDB的BSON單個(gè)文檔16 MB大小限制，同時(shí)又因?yàn)槲募臋n還需要存儲(chǔ)一些必要的文件元數(shù)據(jù)信息，所以規(guī)定15.5 MB以下的文件，稱(chēng)為小文件，超過(guò)15.5 MB的文件，稱(chēng)為大文件，故文件管理可分為小文件管理和大文件管理兩部分[10]。

1.2.1 小文件管理

對(duì)于小文件存儲(chǔ)，可以將文件元數(shù)據(jù)和文件二進(jìn)制數(shù)據(jù)直接存儲(chǔ)到一個(gè)文檔中，小文件集合的數(shù)據(jù)結(jié)構(gòu)如下：

{

″_id″:ObjectId(″IDENTIFIER″),

″filename″:″FILENAME″,

″format″: ″FORMAT″,

″uploadDate″: UPLOAD_TIMESTAMP,

″length″: INTEGER,

″downloadCount″: INTEGER,

″data″: BINARY DATA

}

小文件存儲(chǔ)：文件存儲(chǔ)程序調(diào)用MongoDB接口將文件元數(shù)據(jù)和二進(jìn)制內(nèi)容數(shù)據(jù)寫(xiě)入小文件集合，寫(xiě)入成功后，更新數(shù)據(jù)集元數(shù)據(jù)集合中相應(yīng)的元數(shù)據(jù)文檔，即將小文件ID映射添加到對(duì)應(yīng)文檔中。

小文件讀?。簯?yīng)用程序首先調(diào)用MongoDB接口從數(shù)據(jù)集元數(shù)據(jù)集合中找到小文件ID映射，然后根據(jù)文件ID調(diào)用MongoDB接口讀取小文件元數(shù)據(jù)和二進(jìn)制內(nèi)容數(shù)據(jù)。

1.2.2 大文件管理

大文件使用GridFS進(jìn)行存儲(chǔ)，GridFS是存儲(chǔ)和檢索超過(guò)BSON文檔16 MB大小限制的二進(jìn)制數(shù)據(jù)存儲(chǔ)解決方案。GridFS不是將文件存儲(chǔ)在單個(gè)文檔中，而是將文件分割成部分或塊，并將每塊存儲(chǔ)為單獨(dú)的文檔，默認(rèn)情況下，GridFS使用255 KB的塊大小，也就是說(shuō)，除了最后一個(gè)塊之外，GridFS將文件分成255 KB大小的若干塊。所以對(duì)于大文件存儲(chǔ)，需要兩個(gè)集合，一個(gè)是fs.files，用于存儲(chǔ)文件基本信息、文件塊總塊數(shù)(chunkSize)、文件校驗(yàn)值(MD5)等文件元數(shù)據(jù)，fs.files存儲(chǔ)結(jié)構(gòu)如下所示：

{

″_id″:ObjectId(″IDENTIFIER″),

″filename″: ″FILENAME″,

″format″: ″FORMAT″,

″uploadDate″: UPLOAD_TIMESTAMP,

″length″: INTEGER,

″downloadCount″: INTEGER,

″md5″: ″MD5″,

″chunkSize″: INTEGER

}

另一個(gè)集合是fs.chunks，主要包括文件ID(fileId)，文件塊序號(hào)(n)，文件二進(jìn)制數(shù)據(jù)(data)，數(shù)據(jù)結(jié)構(gòu)如下所示：

{

″_id″:ObjectId(″IDENTIFIER″),

″fileId″: ObjectId(″FILE_IDENTIFIER″),

″n″: INTEGER,

″data″: BINARY DATA

}

大文件存儲(chǔ)：文件存儲(chǔ)程序調(diào)用GridFS接口將文件元數(shù)據(jù)寫(xiě)入fs.files集合，再將大文件分塊后的各個(gè)數(shù)據(jù)塊依次寫(xiě)入fs.chunks集合，寫(xiě)入成功后，更新數(shù)據(jù)集元數(shù)據(jù)集合中對(duì)應(yīng)的元數(shù)據(jù)文檔，將文件ID映射添加到元數(shù)據(jù)文檔，即完成了大文件寫(xiě)入。

大文件讀取：應(yīng)用程序首先調(diào)用MongoDB接口從數(shù)據(jù)集元數(shù)據(jù)集合中找到大文件ID映射，然后根據(jù)文件ID調(diào)用GridFS接口讀取大文件元數(shù)據(jù)和二進(jìn)制數(shù)據(jù)。讀取文件二進(jìn)制數(shù)據(jù)時(shí)，GridFS驅(qū)動(dòng)程序?qū)⒏鶕?jù)需要重新組合塊，按照塊序號(hào)拼接數(shù)據(jù)塊，生成一個(gè)大文件返回給應(yīng)用程序，即完成大文件讀取。此外，若只讀取大文件的部分?jǐn)?shù)據(jù)，只需讀取文件部分?jǐn)?shù)據(jù)塊，而不用將整個(gè)文件加載到內(nèi)存。

1.3 結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)

在ODSMM模型中，對(duì)于數(shù)據(jù)集結(jié)構(gòu)化和半結(jié)構(gòu)化文件，除了需要存儲(chǔ)文件二進(jìn)制數(shù)據(jù)外，還需對(duì)文件進(jìn)行數(shù)據(jù)轉(zhuǎn)換，將轉(zhuǎn)換后的具體內(nèi)容數(shù)據(jù)存儲(chǔ)到結(jié)構(gòu)化數(shù)據(jù)集合，結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)過(guò)程如下：

(1) 數(shù)據(jù)轉(zhuǎn)換程序?qū)⒔Y(jié)構(gòu)化和半結(jié)構(gòu)化文件轉(zhuǎn)換成BSON數(shù)據(jù)。

(2) 根據(jù)存儲(chǔ)在數(shù)據(jù)集元數(shù)據(jù)文檔中的結(jié)構(gòu)化數(shù)據(jù)集合引用，找到對(duì)應(yīng)的結(jié)構(gòu)化數(shù)據(jù)集合。

(3) 結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)程序調(diào)用MongoDB接口將BSON格式的文件內(nèi)容數(shù)據(jù)寫(xiě)入結(jié)構(gòu)化數(shù)據(jù)集合。

當(dāng)數(shù)據(jù)集新增結(jié)構(gòu)化或半結(jié)構(gòu)化文件時(shí)，需將文件內(nèi)容數(shù)據(jù)添加到結(jié)構(gòu)化數(shù)據(jù)集合中，當(dāng)刪除數(shù)據(jù)集結(jié)構(gòu)化或半結(jié)構(gòu)化文件時(shí)，需將結(jié)構(gòu)化數(shù)據(jù)集合中相應(yīng)的文檔刪除。對(duì)于結(jié)構(gòu)化數(shù)據(jù)集合，通常并不會(huì)修改單個(gè)文檔中的部分?jǐn)?shù)據(jù)，一般是對(duì)整個(gè)文檔刪除或新增。

2 API調(diào)用優(yōu)化

由開(kāi)放數(shù)據(jù)的特點(diǎn)可知，對(duì)數(shù)據(jù)集的新增、刪除及更新操作頻率并不高，大部分操作為應(yīng)用程序通過(guò)API調(diào)用對(duì)結(jié)構(gòu)化數(shù)據(jù)進(jìn)行有條件的查詢(xún)操作。API調(diào)用的實(shí)現(xiàn)方式主要是數(shù)據(jù)分頁(yè)加載，這種方式只需將部分?jǐn)?shù)據(jù)加載到內(nèi)存，只返回當(dāng)前頁(yè)面的數(shù)據(jù)給應(yīng)用程序，在需要展示下一頁(yè)數(shù)據(jù)時(shí)，再執(zhí)行一次調(diào)用返回下一頁(yè)數(shù)據(jù)。這種方式不會(huì)占用過(guò)多的內(nèi)存，快速高效，從而被廣泛使用。API調(diào)用參數(shù)如表1所示。

表1 API調(diào)用參數(shù)列表

基于MongoDB的分頁(yè)算法中，主要有Skip-Limit算法和Where-Limit算法。MongoDB中使用limit函數(shù)限制返回的結(jié)果數(shù)，使用skip函數(shù)跳過(guò)指定條數(shù)的記錄，所以使用limit并結(jié)合skip能夠方便地實(shí)現(xiàn)數(shù)據(jù)分頁(yè)，此種方法稱(chēng)之為Skip-Limit分頁(yè)算法。當(dāng)數(shù)據(jù)量和并發(fā)訪(fǎng)問(wèn)量較小時(shí)，Skip-Limit分頁(yè)算法沒(méi)有問(wèn)題，但是當(dāng)數(shù)據(jù)量很大時(shí)，尤其是需要查找定位大量數(shù)據(jù)的中間或者后面幾頁(yè)數(shù)據(jù)時(shí)，skip函數(shù)需要跳過(guò)的數(shù)據(jù)量(偏移量)會(huì)很大，有時(shí)可能達(dá)幾萬(wàn)、幾十萬(wàn)，甚至上百萬(wàn)，這時(shí)skip操作會(huì)變得很慢。所以文獻(xiàn)[11]中提出一種分頁(yè)優(yōu)化算法Where-Limit算法，算法核心不是計(jì)算數(shù)據(jù)偏移量，而是傳上一頁(yè)的數(shù)據(jù)標(biāo)記或關(guān)鍵詞，根據(jù)where條件來(lái)查詢(xún)實(shí)現(xiàn)分頁(yè)，這種模式必須有一個(gè)連續(xù)的索引，才能通過(guò)直接指定位置，查找到要顯示頁(yè)的起始數(shù)據(jù)標(biāo)記。方法是在查詢(xún)開(kāi)始時(shí)先將所有數(shù)據(jù)關(guān)鍵詞讀取到數(shù)組中，需要分頁(yè)時(shí)通過(guò)頁(yè)碼記錄和數(shù)組下標(biāo)的對(duì)應(yīng)關(guān)系去查詢(xún)頁(yè)碼首記錄的數(shù)據(jù)標(biāo)記，這種分頁(yè)算法也體現(xiàn)了以空間換時(shí)間的思想[11]。

充分利用Skip-Limit和Where-Limit兩種算法的優(yōu)點(diǎn)，提出一種新的算法Skip-Where，主要思路是在偏移量小的時(shí)候使用Skip-Limit算法，在偏移量大的時(shí)候使用Where-Limit算法。定義偏移量為Offset，即采用Skip-Limit算法時(shí)需要跳過(guò)的數(shù)據(jù)量，閾值M表示的Offset的臨界值，則有：

Offset=(PageNumber-1)×PageSize

當(dāng)Offset小于等于M時(shí)，此時(shí)需要skip的數(shù)據(jù)量小，采用Skip-Limit算法更簡(jiǎn)單方便、響應(yīng)時(shí)間快，同時(shí)不需要使用額外的內(nèi)存空間。當(dāng)Offset大于M時(shí)，Skip-Limit算法則會(huì)變慢，此時(shí)采用Where-Limit算法響應(yīng)時(shí)間更快。Skip-Where算法流程圖如圖3所示。

圖3 Skip-Where算法流程圖

3 實(shí) 驗(yàn)

基于ODSMM模型，選取2015年1月至2017年3月“上市公司財(cái)報(bào)”數(shù)據(jù)集作為實(shí)驗(yàn)數(shù)據(jù)進(jìn)行實(shí)驗(yàn)。該數(shù)據(jù)集包含一個(gè)數(shù)據(jù)文件(financial_statements.json)，文件中包含1 100萬(wàn)條數(shù)據(jù)。根據(jù)第1節(jié)描述的方法將數(shù)據(jù)集存儲(chǔ)到MongoDB中，根據(jù)1.2節(jié)中描述的文件讀取過(guò)程實(shí)現(xiàn)了文件下載功能。

根據(jù)第2節(jié)描述的API調(diào)用算法，設(shè)Where-Limit算法中采用的關(guān)鍵詞為4字節(jié)的id字段，則Where-Limit算法需額外的輔助空間為1 100萬(wàn)×4字節(jié)=4 400萬(wàn)字節(jié)，約42 兆字節(jié)內(nèi)存空間。 設(shè)Skip-Where算法中偏移量閾值M為10 000，PageSize為10，PageNumber分別為11、101、1 001、10 001、100 001、1 000 001，則對(duì)應(yīng)的Offset分別為1 001 000、1萬(wàn)、10萬(wàn)、100萬(wàn)、1 000萬(wàn)。分別基于Skip-Limit、Where-Limit、Skip-Where算法執(zhí)行API調(diào)用，得到API調(diào)用平均響應(yīng)時(shí)間和所需輔助空間分別如圖4和圖5所示。

圖4 API調(diào)用平均響應(yīng)時(shí)間

圖5 API調(diào)用輔助空間

4 結(jié) 語(yǔ)

通過(guò)實(shí)驗(yàn)可以看出，ODSMM模型能夠高效存儲(chǔ)管理開(kāi)放數(shù)據(jù)，能夠支持API調(diào)用和數(shù)據(jù)集下載兩種方式獲取開(kāi)放數(shù)據(jù)?；贠DSMM模型的API調(diào)用優(yōu)化算法Skip-Where，在海量數(shù)據(jù)情況下，響應(yīng)時(shí)間在毫秒級(jí)，相對(duì)于Where-Limit算法，在時(shí)間上并沒(méi)有太大改進(jìn)，但在偏移量小于閾值時(shí)節(jié)省了不必要的輔助空間。此外，當(dāng)數(shù)據(jù)量和偏移量達(dá)到一定量級(jí)時(shí)，對(duì)內(nèi)存容量要求會(huì)越來(lái)越高，如何在保證快速響應(yīng)情況下進(jìn)一步優(yōu)化API調(diào)用的輔助空間等問(wèn)題仍有待進(jìn)一步研究。