面向區(qū)塊鏈的高效物化視圖維護(hù)和可信查詢

人工智能技術(shù)與咨詢?

來(lái)源：《軟件學(xué)報(bào)》?，作者蔡 磊等

摘 要:區(qū)塊鏈具有去中心化、不可篡改和可追溯等特性,可應(yīng)用于金融、物流等諸多行業(yè).由于所有交易數(shù)據(jù)按照交易時(shí)間順序存儲(chǔ)在各個(gè)區(qū)塊,相同類型的交易數(shù)據(jù)通常會(huì)散布在諸多區(qū)塊之中,降低了面向歷史區(qū)塊的追溯查詢的處理效率.索引構(gòu)建和物化視圖是提升查詢性能的兩種典型方法,但當(dāng)待處理數(shù)據(jù)分布于多個(gè)區(qū)塊時(shí),使用索引無(wú)法改善I/O 訪問(wèn)效率,而物化視圖可有效應(yīng)對(duì)這個(gè)問(wèn)題.然而,由于區(qū)塊鏈系統(tǒng)的特點(diǎn)明顯區(qū)別于關(guān)系數(shù)據(jù)庫(kù),傳統(tǒng)的面向關(guān)系數(shù)據(jù)庫(kù)的物化視圖技術(shù)無(wú)法被直接應(yīng)用到區(qū)塊鏈之中.鑒于此,首次提出一種面向區(qū)塊鏈的高效物化視圖機(jī)制,具有如下特征:(1)將視圖維護(hù)操作與共識(shí)過(guò)程同時(shí)執(zhí)行,降低該操作對(duì)系統(tǒng)性能的影響;(2)使用字典樹(shù)加快以區(qū)塊為單位的多物化視圖維護(hù)進(jìn)程;(3)以默克爾驗(yàn)證的方式確保物化結(jié)果不被惡意篡改,進(jìn)而確保查詢結(jié)果可信.所提出的物化視圖維護(hù)機(jī)制已經(jīng)被集成到一個(gè)區(qū)塊鏈系統(tǒng)中,并通過(guò)實(shí)驗(yàn)來(lái)驗(yàn)證該機(jī)制的高效性.

關(guān)鍵詞:物化視圖;區(qū)塊鏈;增量更新;視圖維護(hù);默克爾樹(shù)

作為一種在不可信環(huán)境中由多方共同維護(hù)的分布式賬本,區(qū)塊鏈已被應(yīng)用在金融、物流等領(lǐng)域.然而,當(dāng)前的區(qū)塊鏈技術(shù)在數(shù)據(jù)管理方面存在著無(wú)法支持復(fù)雜查詢、查詢接口單一和響應(yīng)太慢等局限性.

為了彌補(bǔ)現(xiàn)有區(qū)塊鏈平臺(tái)在數(shù)據(jù)管理性能方面的不足,一些課題組嘗試融合數(shù)據(jù)管理和區(qū)塊鏈技術(shù),例如ChainSQL[1],BigchainDB[2],FlureeDB[3],SEBDB[4]等.ChainSQL 將關(guān)系數(shù)據(jù)庫(kù)和Ripple 區(qū)塊鏈網(wǎng)絡(luò)相結(jié)合,借助關(guān)系數(shù)據(jù)庫(kù)的訪問(wèn)接口為鏈上數(shù)據(jù)訪問(wèn)提供便利,并使用區(qū)塊鏈技術(shù)來(lái)提升數(shù)據(jù)異地多活的容錯(cuò)能力.BigchainDB 是一種添加了區(qū)塊鏈特征的數(shù)據(jù)庫(kù),它集成了MongoDB 和Tendermint 區(qū)塊鏈網(wǎng)絡(luò).FlureeDB 將區(qū)塊鏈技術(shù)中不可篡改和高容錯(cuò)特性集成到圖形數(shù)據(jù)庫(kù).以上工作盡管提供了更豐富的查詢功能,但是并未聚焦查詢性能優(yōu)化.SEBDB[4]在面向傳統(tǒng)行業(yè)的聯(lián)盟鏈背景下,為區(qū)塊數(shù)據(jù)添加了關(guān)系語(yǔ)義,將每種交易類型轉(zhuǎn)化為一張關(guān)系表,將該交易類型的參數(shù)轉(zhuǎn)化為相應(yīng)關(guān)系表的列,從而有效融合關(guān)系語(yǔ)義和區(qū)塊數(shù)據(jù).

在區(qū)塊鏈中,區(qū)塊包括區(qū)塊頭(block header)和區(qū)塊體(block body),如圖1(a)所示:區(qū)塊頭由前一個(gè)區(qū)塊的哈希值、區(qū)塊ID、區(qū)塊生成時(shí)間、交易默克爾樹(shù)根、簽名和本區(qū)塊的哈希值組成;區(qū)塊體包含多個(gè)交易,每個(gè)交易由交易ID(TxID)、交易簽名(TxSig)、智能合約調(diào)用者(TxCaller)、交易時(shí)間(TxTime)、交易表名(TxName)和表數(shù)據(jù)(TxData)組成.圖1(b)為一個(gè)交易示例,表示用戶Alice 調(diào)用智能合約中的donate 函數(shù)向教育基金項(xiàng)目Edu Fund 捐助了100 元.在SEBDB[4]中,交易表名相當(dāng)于關(guān)系數(shù)據(jù)庫(kù)中的表名,表數(shù)據(jù)包含若干列,相當(dāng)于關(guān)系數(shù)據(jù)庫(kù)中的一行記錄.

Fig.1 Structure of block and transaction
圖1 區(qū)塊和交易結(jié)構(gòu)

由于交易數(shù)據(jù)在區(qū)塊中以交易提交的時(shí)間順序依次存儲(chǔ),屬于同一關(guān)系表的交易數(shù)據(jù)往往會(huì)分散在不連續(xù)的多個(gè)區(qū)塊中,這會(huì)降低針對(duì)區(qū)塊數(shù)據(jù)的查詢的執(zhí)行效率.SEBDB[4]通過(guò)在區(qū)塊鏈上建立B+樹(shù)、位圖等索引提高查詢性能,但是當(dāng)查詢涉及到多個(gè)區(qū)塊時(shí),使用索引無(wú)法持續(xù)降低I/O 訪問(wèn)開(kāi)銷,因而無(wú)法進(jìn)一步改善查詢處理效率.在數(shù)據(jù)庫(kù)中,建立物化視圖是另一種提高查詢效率的方法,物化視圖通過(guò)物化查詢結(jié)果來(lái)提高特定查詢的處理效率.因此,如何在區(qū)塊鏈中使用物化視圖也值得思考.

盡管物化視圖已被研究多年,如何維護(hù)物化視圖仍舊是一個(gè)開(kāi)放問(wèn)題.在關(guān)系數(shù)據(jù)庫(kù)中,增量刷新的物化視圖維護(hù)策略可劃分為立即維護(hù)[5]和延遲維護(hù)[6]兩大類.立即維護(hù)策略的優(yōu)點(diǎn)是實(shí)現(xiàn)較為簡(jiǎn)單,在單數(shù)據(jù)源下不存在一致性問(wèn)題;然而該策略將物化視圖維護(hù)過(guò)程嵌入到更新事務(wù)之中,延長(zhǎng)了更新事務(wù)的提交時(shí)間,這在高并發(fā)的情況下易發(fā)生死鎖.延遲維護(hù)策略解耦合視圖維護(hù)和更新事務(wù),在OLTP 場(chǎng)景下,可以通過(guò)合并無(wú)關(guān)更新[6]的方法縮短視圖維護(hù)時(shí)間;但是此策略存在一致性問(wèn)題,若視圖未更新完畢則不可使用.在延遲維護(hù)策略的諸多實(shí)現(xiàn)方法中,按需維護(hù)[7]較為常見(jiàn),即:等待查詢到來(lái)之后,只維護(hù)與查詢相關(guān)的物化視圖.由此可見(jiàn),各種策略的優(yōu)缺點(diǎn)顯著,如何合理選擇視圖維護(hù)策略非常重要.

面對(duì)被賦予了關(guān)系語(yǔ)義的區(qū)塊數(shù)據(jù),采用關(guān)系數(shù)據(jù)庫(kù)中普遍使用的建立物化視圖的方式來(lái)提升查詢性能是一種可行的方法.在區(qū)塊鏈中,系統(tǒng)查找某張表的數(shù)據(jù)需要掃描所有的區(qū)塊,當(dāng)數(shù)據(jù)量龐大時(shí),即使掃描索引也會(huì)產(chǎn)生非常大的開(kāi)銷.鑒于此,如果將物化視圖運(yùn)用于區(qū)塊鏈,將會(huì)優(yōu)化查詢的處理效率.

然而,關(guān)系數(shù)據(jù)庫(kù)與區(qū)塊鏈系統(tǒng)在存儲(chǔ)模型和更新操作上有顯著不同,區(qū)塊鏈系統(tǒng)以區(qū)塊為單位進(jìn)行更新,單個(gè)區(qū)塊包含多條交易,并且區(qū)塊鏈系統(tǒng)中的交易需要通過(guò)共識(shí)來(lái)完成.區(qū)塊鏈系統(tǒng)和關(guān)系數(shù)據(jù)庫(kù)相比,在區(qū)塊鏈上建立、維護(hù)物化視圖將面臨以下3 個(gè)挑戰(zhàn).

(1)如何選擇物化視圖的寫(xiě)入時(shí)機(jī).區(qū)塊鏈的寫(xiě)入性能受到分布式共識(shí)、智能合約執(zhí)行限制,而物化視圖的維護(hù)開(kāi)銷對(duì)系統(tǒng)的性能帶來(lái)額外影響.因此,如何合理選擇視圖維護(hù)的時(shí)機(jī)來(lái)降低視圖維護(hù)對(duì)系統(tǒng)整體性能的影響,是一個(gè)需要考慮的問(wèn)題;

(2)如何以區(qū)塊為單位維護(hù)視圖.區(qū)塊是區(qū)塊鏈的基本數(shù)據(jù)追加單位,各區(qū)塊包含多種類型的交易,對(duì)于一個(gè)區(qū)塊可能需要同時(shí)維護(hù)多個(gè)視圖.因此,設(shè)計(jì)的方案必須支持批量的物化視圖維護(hù),并且使得物化視圖維護(hù)的開(kāi)銷盡可能小;

(3)如何確保查詢結(jié)果的可信性.由于數(shù)據(jù)上鏈需要經(jīng)過(guò)較為昂貴的共識(shí)過(guò)程,為了提升查詢效率,物化視圖并不保存在區(qū)塊鏈上.與此同時(shí),將物化視圖保存在本地會(huì)面臨數(shù)據(jù)被篡改的風(fēng)險(xiǎn),需要實(shí)施相應(yīng)措施來(lái)確保查詢結(jié)果可信.

針對(duì)以上挑戰(zhàn),本文的主要貢獻(xiàn)包括:首次將物化視圖運(yùn)用于區(qū)塊鏈,提出了一種視圖維護(hù)和共識(shí)過(guò)程并行的方法,降低物化視圖的維護(hù)開(kāi)銷.區(qū)塊鏈的共識(shí)過(guò)程主要消耗網(wǎng)絡(luò)帶寬,在此期間,CPU 和I/O 資源消耗相對(duì)較少,而視圖維護(hù)過(guò)程卻主要消耗CPU 和I/O 資源.因此,將視圖維護(hù)和共識(shí)過(guò)程并行執(zhí)行可減少視圖維護(hù)對(duì)寫(xiě)入性能的影響.提出了基于字典樹(shù)的方法,以區(qū)塊為單位批量維護(hù)視圖,并且支持多種維護(hù)策略.本文使用字典樹(shù)作為索引加快查找不同表名的更新記錄,可對(duì)相同表名的更新記錄只進(jìn)行一次視圖維護(hù)操作.并且本文支持閑時(shí)維護(hù)和按需維護(hù)的維護(hù)策略.提出了基于默克爾樹(shù)的查詢結(jié)果驗(yàn)證方法,確保結(jié)果可信.為物化視圖構(gòu)造默克爾樹(shù).當(dāng)查詢使用物化視圖時(shí),系統(tǒng)掃描物化視圖建立默克爾樹(shù),并與預(yù)先保存的默克爾樹(shù)根進(jìn)行比較,以此確保物化視圖的正確性與完整性.

本文第1 節(jié)說(shuō)明本文的系統(tǒng)架構(gòu).第2 節(jié)闡述物化視圖的維護(hù)時(shí)機(jī).第3 節(jié)描述物化視圖維護(hù)的具體過(guò)程.第4 節(jié)詳述基于默克爾樹(shù)的查詢驗(yàn)證方法.第5 節(jié)展示實(shí)驗(yàn)結(jié)果.第6 節(jié)回顧與本文相關(guān)的研究工作.最后,第7節(jié)給出簡(jiǎn)短總結(jié).

1 系統(tǒng)架構(gòu)

本文原型系統(tǒng)架構(gòu)如圖2 所示,包括應(yīng)用層、查詢層、存儲(chǔ)層、共識(shí)層和網(wǎng)絡(luò)層:應(yīng)用層包括查詢API、訪問(wèn)控制和智能合約;查詢層具有查詢引擎,負(fù)責(zé)對(duì)查詢的解析、優(yōu)化、執(zhí)行,包括物化視圖的維護(hù);存儲(chǔ)層包括區(qū)塊鏈和鏈下數(shù)據(jù)(物化視圖、索引等);共識(shí)層負(fù)責(zé)交易的共識(shí),運(yùn)用的協(xié)議為PBFT[8];最后,網(wǎng)絡(luò)層采用Gossip協(xié)議.本文專注于查詢層、存儲(chǔ)層和共識(shí)層:物化視圖的更新記錄來(lái)自于共識(shí)返回的結(jié)果,查詢層負(fù)責(zé)物化視圖的維護(hù)工作,并將更新后的物化視圖存于存儲(chǔ)層.此外,查詢的結(jié)果來(lái)源于存儲(chǔ)層的區(qū)塊數(shù)據(jù)或物化視圖.

Fig.2 System architecture
圖2 系統(tǒng)架構(gòu)

在此架構(gòu)下,面向添加了關(guān)系語(yǔ)義的聯(lián)盟鏈,我們首次提出一種高效的物化視圖維護(hù)方法以提高查詢的效率,并且提出一種驗(yàn)證方法來(lái)確保查詢結(jié)果的正確性.當(dāng)系統(tǒng)應(yīng)用層接收到客戶端發(fā)來(lái)的智能合約調(diào)用請(qǐng)求時(shí),查詢層處理請(qǐng)求,然后調(diào)用智能合約產(chǎn)生一條新的交易,交易通過(guò)共識(shí)后被打包進(jìn)區(qū)塊保存在區(qū)塊鏈中.另一方面,查詢層獲取共識(shí)成功的交易進(jìn)行視圖維護(hù),視圖維護(hù)完畢后,將更新后的物化視圖存于存儲(chǔ)層的磁盤(pán)中.而當(dāng)系統(tǒng)接收到客戶端的查詢請(qǐng)求時(shí),查詢層判斷該請(qǐng)求是否可以運(yùn)用物化視圖:若可以,則獲取物化視圖數(shù)據(jù)返回給應(yīng)用層;若不能使用物化視圖,則需掃描區(qū)塊鏈查找結(jié)果.接下來(lái)我們將回答3 個(gè)問(wèn)題:何時(shí)進(jìn)行物化視圖的維護(hù)、如何進(jìn)行物化視圖的維護(hù)以及如何保證物化視圖結(jié)果的正確性.

2 物化時(shí)機(jī)的選擇

在區(qū)塊鏈中,交易在系統(tǒng)中達(dá)成共識(shí)需要在各節(jié)點(diǎn)之間進(jìn)行網(wǎng)絡(luò)通信.比如,廣泛應(yīng)用于聯(lián)盟鏈的協(xié)議PBFT 需要進(jìn)行3 輪網(wǎng)絡(luò)交互,耗費(fèi)時(shí)間較長(zhǎng).在共識(shí)階段主要消耗網(wǎng)絡(luò)資源,而CPU 和I/O 資源相對(duì)空閑.因此,視圖維護(hù)與共識(shí)階段可以并行執(zhí)行.當(dāng)上一輪共識(shí)的數(shù)據(jù)已經(jīng)有效時(shí),系統(tǒng)在執(zhí)行新一輪交易共識(shí)的過(guò)程中對(duì)上一輪產(chǎn)生的數(shù)據(jù)進(jìn)行物化操作.這樣,物化視圖維護(hù)和共識(shí)過(guò)程同時(shí)進(jìn)行,互不干擾,從而大幅度減少視圖維護(hù)對(duì)系統(tǒng)整體性能的影響.

該方案需考慮兩種情況:一是視圖的維護(hù)時(shí)間相對(duì)于共識(shí)時(shí)間比較少;二是視圖的維護(hù)時(shí)間大于共識(shí)時(shí)間,即上輪共識(shí)通過(guò)的交易相關(guān)視圖不能在此輪共識(shí)時(shí)間內(nèi)完成.假設(shè)每個(gè)區(qū)塊中的交易平均屬于k?張表,每張表的視圖個(gè)數(shù)為n,每張表的的平均視圖維護(hù)時(shí)間為tmvi(i∈[1,n]),共識(shí)的時(shí)間為T(mén),那么需要考慮:

或

如果維護(hù)時(shí)間滿足公式(1),如圖3 所示,系統(tǒng)直接對(duì)上一輪共識(shí)通過(guò)的數(shù)據(jù)進(jìn)行視圖維護(hù);如果滿足公式(2),則將剩余未維護(hù)的記錄暫存在緩沖區(qū)中,等待CPU 空閑進(jìn)行閑時(shí)維護(hù).以上方法中,正在進(jìn)行維護(hù)更新的物化視圖暫時(shí)不可用,因?yàn)樽钚碌臄?shù)據(jù)還未更新,查詢得到的結(jié)果不完整.因此,當(dāng)有可以引用物化視圖的查詢到來(lái)時(shí),系統(tǒng)采用按需維護(hù)策略,優(yōu)先維護(hù)查詢相關(guān)的物化視圖以快速響應(yīng)查詢.對(duì)于視圖維護(hù)中的一致性保證,我們將在第4.2 節(jié)詳細(xì)敘述.

Fig.3 Maintenance timing of materialized views
圖3 物化視圖的維護(hù)時(shí)機(jī)

3 視圖維護(hù)過(guò)程

3.1 維護(hù)視圖的基本步驟

在維護(hù)物化視圖時(shí),查詢層的查詢引擎獲取共識(shí)成功的交易的表名、表數(shù)據(jù)、所屬區(qū)塊ID 進(jìn)行增量維護(hù).系統(tǒng)創(chuàng)建的物化視圖與基本表類似,只是在類型上加以區(qū)別.圖4 展示了物化視圖維護(hù)的整體流程,該流程包括4 個(gè)步驟:①?gòu)墓沧R(shí)模塊獲取已完成共識(shí)的多個(gè)交易,創(chuàng)建增量記錄;② 查詢層將增量記錄按照表名分組,并存儲(chǔ)在增量記錄緩沖區(qū)中;③根據(jù)增量記錄創(chuàng)建視圖維護(hù)任務(wù),當(dāng)查詢到來(lái)時(shí),進(jìn)行視圖維護(hù)任務(wù)的調(diào)度;④ 根據(jù)物化視圖的查詢表達(dá)式計(jì)算更新的視圖行集,再將新增的視圖行集添加到視圖中.

Fig.4 Maintenance process of materialized views
圖4 物化視圖的維護(hù)過(guò)程

以下詳細(xì)介紹相關(guān)步驟.

·首先,在第①步驟中,需要?jiǎng)?chuàng)建增量記錄.

增量記錄是一個(gè)用于存儲(chǔ)記錄更新信息的三元組DeltaRecord(Row,TableName,BlockID),其中,Row?是交易的表數(shù)據(jù)部分,TableName?是交易的表名,BlockID?是當(dāng)前交易所在區(qū)塊的區(qū)塊高度.在針對(duì)交易進(jìn)行新一輪共識(shí)時(shí),系統(tǒng)獲取上一輪各交易的表名和表數(shù)據(jù)字段,結(jié)合新區(qū)塊的ID 創(chuàng)建增量記錄.該步驟可以線性復(fù)雜度執(zhí)行完畢.

·其次,為了提升數(shù)據(jù)檢索效率,步驟②將增量數(shù)據(jù)分組后存放在增量數(shù)據(jù)緩沖區(qū)之中.

由于增量記錄數(shù)目較多,可將其按照表名進(jìn)行分組,分別構(gòu)建增量記錄集(DeltaRecords),并暫存于一個(gè)常駐內(nèi)存的增量記錄緩沖區(qū)(DeltaRecordsCache).為了提升增量記錄的檢索效率,采用字典樹(shù)[9]對(duì)表名進(jìn)行索引.換言之,該字典樹(shù)包含了所有表名以及這些表名的部分前綴字符串.若字典樹(shù)中某節(jié)點(diǎn)(包括葉節(jié)點(diǎn)和非葉節(jié)點(diǎn))對(duì)應(yīng)一個(gè)表名,則有一個(gè)指針指向與該表名相對(duì)應(yīng)的增量記錄集.圖5 顯示了一個(gè)采用字典樹(shù)索引增量記錄的案例.在增量記錄緩沖區(qū)中共有3 個(gè)增量記錄集,其中,視圖維護(hù)任務(wù)Task1維護(hù)表名為donate?的增量記錄d1,d2,d3,Task2維護(hù)表名為transfer?的增量記錄t1,t2,t3.當(dāng)一個(gè)新的增量記錄被添加到增量緩沖區(qū)時(shí),我們?cè)谧值錁?shù)上查找該增量記錄的表名:若此增量記錄表名不存在,則系統(tǒng)為該表名創(chuàng)建新的節(jié)點(diǎn);若存在,則將此增量記錄插入到葉子節(jié)點(diǎn)所指向的增量記錄集.如果某個(gè)增量記錄相關(guān)的所有視圖維護(hù)完畢,則刪除該增量記錄.

·然后,步驟③基于增量記錄集來(lái)維護(hù)視圖.

由于各視圖之間相互獨(dú)立,而且整體維護(hù)開(kāi)銷較大,可分別為各個(gè)視圖分配一個(gè)維護(hù)任務(wù),并由調(diào)度器進(jìn)行調(diào)度.在此基礎(chǔ)之上,可以動(dòng)態(tài)設(shè)置維護(hù)任務(wù)的優(yōu)先級(jí),并且根據(jù)場(chǎng)景需求實(shí)時(shí)切換各維護(hù)任務(wù)的執(zhí)行次序.比如說(shuō),假設(shè)包含相同基表的待維護(hù)視圖包括v1和v2,而新來(lái)的查詢想要處理視圖v1,則可以提升v1的處理優(yōu)先級(jí),從而提升整體效率.各視圖維護(hù)任務(wù)需要指定待維護(hù)的視圖名稱(ViewName)、維護(hù)任務(wù)優(yōu)先級(jí)(Priority,默認(rèn)為1)和增量記錄集.系統(tǒng)維護(hù)一個(gè)針對(duì)所有維護(hù)任務(wù)的優(yōu)先級(jí)隊(duì)列(即視圖維護(hù)任務(wù)隊(duì)列,TaskQueue),以確保高優(yōu)先級(jí)的任務(wù)被優(yōu)先執(zhí)行.

·最后,步驟④執(zhí)行步驟③所創(chuàng)建的任務(wù),計(jì)算需要更新到物化視圖中的行集.

在物化視圖創(chuàng)建時(shí),為各視圖創(chuàng)建一個(gè)數(shù)據(jù)結(jié)構(gòu),該數(shù)據(jù)結(jié)構(gòu)保存視圖的名稱(ViewName)、視圖的基表名稱(TableName)、視圖的查詢執(zhí)行時(shí)的算子(Operators)和當(dāng)前已維護(hù)到的?BlockID.本文將其命名為視圖信息(ViewInfo).系統(tǒng)重新執(zhí)行視圖的查詢算子,便能很快計(jì)算出結(jié)果.然后將行集寫(xiě)入物化視圖中,至此,物化視圖已被更新.

Fig.5 Storage of?DeltaRecord
圖5 增量記錄的存儲(chǔ)

接下來(lái)具體描述算法步驟,包括算法1 和算法2.

算法1.創(chuàng)建視圖維護(hù)任務(wù).

算法2.物化視圖維護(hù).

算法1 描述了創(chuàng)建視圖維護(hù)任務(wù)的過(guò)程,其輸入?yún)?shù)為:字典樹(shù)TrieTree,增量記錄表名TableName,物化視圖信息ViewInfo?和視圖維護(hù)隊(duì)列TaskQueue.算法1 第1 行根據(jù)增量記錄表名TableName?查找字典樹(shù)TrieTree,得到增量記錄集DeltaRecords.這里省略了如何在字典樹(shù)中查找增量記錄集的過(guò)程.第2 行～第4 行表示創(chuàng)建一個(gè)新的視圖維護(hù)任務(wù)Task,并對(duì)其增量記錄集和視圖名稱賦值.該算法最后將此任務(wù)加入到視圖維護(hù)任務(wù)隊(duì)列中.

調(diào)度器周期性評(píng)測(cè)當(dāng)前系統(tǒng)的負(fù)載,一旦發(fā)現(xiàn)當(dāng)前系統(tǒng)處于非忙碌狀態(tài)(CPU 占用資源低于某一閾值),則從TaskQueue?中依次調(diào)取優(yōu)先級(jí)高的若干任務(wù)來(lái)執(zhí)行;在執(zhí)行過(guò)程之中,系統(tǒng)仍舊可以檢測(cè)系統(tǒng)的資源占用情況,當(dāng)系統(tǒng)過(guò)于忙碌時(shí),則暫時(shí)退出物化視圖維護(hù)過(guò)程,留待下一周期執(zhí)行.算法2 描述了在非忙碌階段調(diào)度器執(zhí)行部分視圖維護(hù)任務(wù)的過(guò)程,其輸入?yún)?shù)為:待維護(hù)物化視圖集合V,待維護(hù)視圖信息集合ViewInfoSet,視圖維護(hù)隊(duì)列TaskQueue.算法的第2 行、第3 行取出視圖維護(hù)隊(duì)列頭部的視圖維護(hù)任務(wù).第4 行根據(jù)視圖維護(hù)任務(wù)包含的視圖名稱查找視圖集合V?中相應(yīng)的視圖.第5 行表示根據(jù)視圖維護(hù)任務(wù)包含的視圖名稱查找視圖信息集合ViewInfoSet?中相應(yīng)的視圖信息.第6 行表示針對(duì)維護(hù)任務(wù)的增量記錄集執(zhí)行視圖信息中的算子獲得新增行集Rows.第7 行將第6 行中產(chǎn)生的行集添加到視圖v?中.算法最后判斷系統(tǒng)狀態(tài),若當(dāng)前系統(tǒng)繁忙,則退出算法.

例1:假設(shè)系統(tǒng)中存在兩張物化視圖Vd?和Vt,其中,物化視圖Vd?的基表為donate,Vt?的基表為transfer.系統(tǒng)中增量記錄緩沖區(qū)的增量記錄如圖5 所示,此時(shí),視圖維護(hù)任務(wù)隊(duì)列含有4 個(gè)視圖維護(hù)任務(wù).其中,Task1負(fù)責(zé)維護(hù)基表為donate?的物化視圖,Task2維護(hù)基表為transfer?的物化視圖.當(dāng)系統(tǒng)收到查詢物化視圖Vt?的請(qǐng)求,則提高視圖維護(hù)任務(wù)Task2的優(yōu)先級(jí),那么視圖維護(hù)任務(wù)隊(duì)列中視圖維護(hù)任務(wù)執(zhí)行的順序變?yōu)門(mén)ask2,Task1.當(dāng)執(zhí)行視圖維護(hù)任務(wù)時(shí),系統(tǒng)從視圖維護(hù)任務(wù)隊(duì)列頭取出Task2,然后根據(jù)物化視圖Vt?的查詢執(zhí)行算子計(jì)算視圖新增的行集并添加到Vt?中,最后刪除已維護(hù)完畢的維護(hù)任務(wù)Task2和增量記錄t1,t2,t3.

視圖維護(hù)時(shí),增量記錄的BlockID?提供了一致性保證.我們?yōu)槊總€(gè)物化視圖存儲(chǔ)已維護(hù)記錄的最新BlockID,如果該BlockID?為查詢到來(lái)時(shí)最新的區(qū)塊號(hào),則說(shuō)明物化視圖已經(jīng)更新到最新?tīng)顟B(tài).

3.2 多種維護(hù)策略的支持

許多數(shù)據(jù)庫(kù)都采用單一的物化視圖維護(hù)策略,例如:文獻(xiàn)[6]采用閑時(shí)維護(hù)的策略,文獻(xiàn)[7]采用按需維護(hù)的策略.閑時(shí)維護(hù)存在不能及時(shí)響應(yīng)查詢的情況,而按需維護(hù)可能存在一些物化視圖累積增量記錄過(guò)多、導(dǎo)致一次維護(hù)的執(zhí)行時(shí)間長(zhǎng)的問(wèn)題.為了避免上述情況,本方法同時(shí)支持閑時(shí)維護(hù)和按需維護(hù)的策略:當(dāng)CPU 空閑時(shí),查詢引擎檢查視圖維護(hù)隊(duì)列是否存在未執(zhí)行的視圖維護(hù)任務(wù),若存在,則依次執(zhí)行;如果查詢到來(lái),維護(hù)策略切換為按需維護(hù).

當(dāng)查詢到來(lái)時(shí),我們從共識(shí)層可以知道當(dāng)前最新的BlockID,而我們預(yù)先為每個(gè)視圖維護(hù)一個(gè)最近更新的BlockID.首先將兩個(gè)BlockID?比較,如果相等,則說(shuō)明該物化視圖已維護(hù)到最新?tīng)顟B(tài);如果不等,則需要訪問(wèn)增量記錄緩沖區(qū)和視圖維護(hù)任務(wù)隊(duì)列.此時(shí),根據(jù)查詢語(yǔ)句中的表名查找字典樹(shù),便可獲取到與查詢相關(guān)的增量記錄,如果存在,則建立視圖維護(hù)任務(wù).如果視圖維護(hù)任務(wù)隊(duì)列中存在查詢相關(guān)視圖的維護(hù)任務(wù),則系統(tǒng)將會(huì)提升這些視圖維護(hù)任務(wù)的優(yōu)先級(jí),從而查詢引擎優(yōu)先維護(hù)查詢相關(guān)的物化視圖以快速響應(yīng)查詢.通過(guò)將多種維護(hù)策略相互協(xié)調(diào),系統(tǒng)可以最大限度地降低查詢的延遲時(shí)間.

4 可信任的物化視圖

借助物化視圖固然可顯著提高區(qū)塊鏈中查詢的效率,但是當(dāng)物化結(jié)果被存儲(chǔ)于本地時(shí),一旦本地節(jié)點(diǎn)被攻擊,物化結(jié)果就有可能被惡意篡改,進(jìn)而影響查詢結(jié)果的正確性.鑒于此,本文利用默克爾樹(shù)來(lái)確保基于物化視圖的查詢結(jié)果的正確性.

默克爾樹(shù)[10]是基于哈希值的二叉樹(shù),其葉子節(jié)點(diǎn)是數(shù)據(jù)的哈希值,非葉子節(jié)點(diǎn)是對(duì)子節(jié)點(diǎn)哈希值進(jìn)行串接之后再進(jìn)行散列所獲得的哈希值.因此,默克爾樹(shù)具有防篡改特性.本方法預(yù)先為每個(gè)視圖構(gòu)建一棵默克爾樹(shù),并保存在內(nèi)存中.在查詢過(guò)程中,系統(tǒng)讀取物化視圖重新構(gòu)建默克爾根,并與之前保存的默克爾根進(jìn)行比對(duì),以驗(yàn)證查詢結(jié)果的正確性.每當(dāng)物化視圖更新時(shí),均會(huì)針對(duì)所更新的數(shù)據(jù)產(chǎn)生一個(gè)哈希值,該哈希值將被添加到默克爾樹(shù)的最右側(cè)子節(jié)點(diǎn),并向上更新默克爾樹(shù)直至根節(jié)點(diǎn).以圖6 為例,假定物化視圖每次更新一行,則所生成的默克爾樹(shù)共有8 個(gè)葉子節(jié)點(diǎn),其中,Hi即為Rowi的哈希值.由于新增的交易總是更新默克爾樹(shù)的最右節(jié)點(diǎn),所以當(dāng)默克爾樹(shù)增長(zhǎng)到超出可使用的內(nèi)存大小時(shí),系統(tǒng)可以只將默克爾樹(shù)的最右路徑上的節(jié)點(diǎn)保存在內(nèi)存中,以便更新默克爾樹(shù).

Fig.6 Structure of Merkle-tree
圖6 默克爾樹(shù)結(jié)構(gòu)

算法3 描述了如何使用默克爾樹(shù)驗(yàn)證基于物化視圖的查詢結(jié)果,輸入?yún)?shù)為物化視圖MV、視圖每次更新的數(shù)據(jù)長(zhǎng)度數(shù)組sArray?和預(yù)先建立的默克爾樹(shù)的樹(shù)根Root,輸出為驗(yàn)證標(biāo)志Proofs.算法第1 行創(chuàng)建一個(gè)空數(shù)組ViewHashs?以保存哈希值.第2 行初始化視圖MV?的偏移位置.算法的第3 行～第8 行表示對(duì)于每次維護(hù)的記錄行集Rows?進(jìn)行哈希操作,其中:第4 行表示每次從視圖的偏移位置讀取長(zhǎng)度為sArray[i]的數(shù)據(jù)rows;第5 行、第6 行表示將每次讀取的數(shù)據(jù)rows?進(jìn)行哈希,并把得到的哈希值保存在ViewHashs?中;第7 行更新視圖MV?的偏移位置.算法的第9 行使用ViewHashs?建立默克爾樹(shù)得到默克爾樹(shù)根RowsRoot.第10 行驗(yàn)證新計(jì)算的默克爾樹(shù)根RowsRoot?是否與Root?相同:若相同,則驗(yàn)證成功,算法返回驗(yàn)證結(jié)果Proofs?為true;反之驗(yàn)證失敗,返回false.由此,本方法保證了物化視圖物化結(jié)果的正確性,從而保證基于視圖的查詢的結(jié)果也是正確的.

算法3.默克爾樹(shù)查詢驗(yàn)證.

例2:以圖6 為例,查詢獲取視圖結(jié)果時(shí),系統(tǒng)按照每次視圖寫(xiě)入的終止位置不斷讀取物化視圖中的記錄并進(jìn)行散列,然后根據(jù)散列后的哈希值建立圖6 所示的默克爾樹(shù),如此得到默克爾樹(shù)根H15.算法3 將它與預(yù)先保存的默克爾樹(shù)根Root?比對(duì):若相同,則驗(yàn)證成功,表示物化結(jié)果沒(méi)有被惡意篡改.

算法3 的時(shí)間開(kāi)銷由內(nèi)存中的計(jì)算時(shí)間和物化視圖的讀取時(shí)間組成.其中,內(nèi)存計(jì)算的時(shí)間主要取決于哈希運(yùn)算的次數(shù).在算法3 中的循環(huán)體中,哈希運(yùn)算被運(yùn)行n?次(n?為物化視圖維護(hù)的次數(shù)),循環(huán)體外建立默克爾樹(shù)哈希運(yùn)算需要運(yùn)行n?1 次,則哈希運(yùn)算一共被運(yùn)行2×n?1 次,因此算法3 內(nèi)存中的時(shí)間復(fù)雜度為O(n).而對(duì)于視圖的讀取,設(shè)磁盤(pán)帶寬為x(MB/s),物化視圖的大小為y(MB),則視圖的讀取時(shí)間為y/x(s).

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

5.1 實(shí)驗(yàn)環(huán)境

本文將提出的物化視圖機(jī)制實(shí)現(xiàn)在區(qū)塊鏈系統(tǒng)SEBDB[4]中,以驗(yàn)證所提出方法的有效性.實(shí)驗(yàn)在4 臺(tái)機(jī)器組成的集群上進(jìn)行,其中,每臺(tái)機(jī)器配備Intel Xeon(R)2.10GHz 的CPU,96G 的RAM 和3TB 的硬盤(pán).區(qū)塊鏈系統(tǒng)運(yùn)行在CentOS 7 上,區(qū)塊鏈采用Tendermint 共識(shí),共識(shí)時(shí)間設(shè)置為1s.

此外,我們采用了SEBDB[4]中的模式,如圖7 所示,此模式的鏈上表由捐贈(zèng)系統(tǒng)中的donate,transfer?和distribute?這3 張表組成.其中,donate?表記錄捐助者的捐款信息,transfer?記錄捐贈(zèng)組織間的資產(chǎn)轉(zhuǎn)移信息,distribute?記錄捐助組織給予受助者的援助信息.由于系統(tǒng)原型的局限性,原型暫不支持多表連接和聚集查詢,因此,這里工作負(fù)載僅涉及單張表的查詢或者兩張表的連接,形式如Q1,Q2 和Q3 所示.本文實(shí)驗(yàn)的數(shù)據(jù)由SEBDB中的數(shù)據(jù)生成器生成,系統(tǒng)中各表的交易均勻地分布在區(qū)塊鏈中.

Fig.7 Database schema
圖7 數(shù)據(jù)庫(kù)模式

5.2 物化視圖維護(hù)性能

我們通過(guò)創(chuàng)建Q1,Q2 形式的物化視圖來(lái)比較單表與等值連接視圖維護(hù)所需要的時(shí)間.本實(shí)驗(yàn)設(shè)置區(qū)塊個(gè)數(shù)2 000～4 000,其中每個(gè)區(qū)塊包含5 條需要視圖維護(hù)的交易,每條交易大小為300 字節(jié).圖8 顯示了物化視圖規(guī)模在1 萬(wàn)～2 萬(wàn)條記錄之間情況下的維護(hù)時(shí)間.對(duì)于Q1 形式的單表查詢視圖,維護(hù)開(kāi)銷緩慢增長(zhǎng),即使系統(tǒng)一次維護(hù)2 萬(wàn)條數(shù)據(jù),也僅需要200ms 的時(shí)間.這種情況下,視圖維護(hù)過(guò)程完全可以與共識(shí)過(guò)程并發(fā)處理中,視圖維護(hù)對(duì)系統(tǒng)的影響非常小.Q2 形式的等值連接視圖維護(hù)過(guò)程中依然要掃描區(qū)塊以獲取另一張表的數(shù)據(jù)進(jìn)行連接,所以相對(duì)單表視圖的維護(hù)時(shí)間增長(zhǎng)許多,對(duì)于2 萬(wàn)條記錄的維護(hù)已經(jīng)超過(guò)共識(shí)設(shè)定的時(shí)間.這種情況下,系統(tǒng)采用閑時(shí)維護(hù)的策略.對(duì)于現(xiàn)階段的區(qū)塊鏈,交易的吞吐量最高為上千級(jí)別,并且現(xiàn)實(shí)情況中系統(tǒng)每張表的物化視圖數(shù)量比較少,因此我們的方法完全可行.

圖9 具體分析了Q2 形式的等值連接視圖在視圖維護(hù)過(guò)程中,存儲(chǔ)視圖和除存儲(chǔ)視圖以外其他階段消耗的時(shí)間,圖中顯示:存儲(chǔ)物化視圖的時(shí)間是短暫的,其余階段的執(zhí)行占據(jù)了視圖維護(hù)的主要部分.這是因?yàn)樵谶B接的另一張表不存在視圖的情況下連接查詢?nèi)匀恍枰獟呙鑵^(qū)塊,但這可以通過(guò)使用索引的方法來(lái)避免.

Fig.8 Cost to maintain views
圖8 視圖維護(hù)開(kāi)銷

Fig.9 Storage time and other time
圖9 存儲(chǔ)時(shí)間與其他時(shí)間

除此之外,我們測(cè)試了使用字典樹(shù)和線性掃描兩種方法查找增量記錄的物化視圖維護(hù)性能.為了更好地體現(xiàn)字典樹(shù)的性能,實(shí)驗(yàn)中模擬加入了其他表名的增量記錄,并且固定每個(gè)表名的增量記錄為100 個(gè).如圖10 所示:使用字典樹(shù)的視圖維護(hù)方法的維護(hù)性能總是優(yōu)于線性掃描增量記錄緩沖區(qū)的維護(hù)方法,當(dāng)維護(hù)的增量記錄的表名越多、增量記錄越多時(shí),兩者的差距則越大.這是因?yàn)樽值錁?shù)只需要一次字符串比較便可得到增量記錄集的位置,而不使用字典樹(shù)的情況下,系統(tǒng)每次獲取增量記錄集都需要遍歷整個(gè)增量記錄緩沖區(qū).

Fig.10 Using trie tree
圖10 使用字典樹(shù)

5.3 使用物化視圖減少查詢的延遲

本節(jié)我們對(duì)比查詢使用視圖和查詢掃描區(qū)塊所需的響應(yīng)時(shí)間.對(duì)于Q1 查詢,本實(shí)驗(yàn)固定區(qū)塊個(gè)數(shù)為1 000,每個(gè)區(qū)塊中的交易數(shù)量為200.圖11 顯示:使用物化視圖的查詢響應(yīng)時(shí)間增長(zhǎng)緩慢,而掃描區(qū)塊方式的查詢時(shí)間快速增長(zhǎng).這是因?yàn)殡S著區(qū)塊的增多,掃描區(qū)塊的時(shí)間快速增長(zhǎng),而掃描物化視圖需要更少的I/O.圖12 顯示Q2的查詢響應(yīng)時(shí)間,結(jié)果集固定為20 000 行,區(qū)塊個(gè)數(shù)從1 000～5 000 增長(zhǎng),使用物化視圖的查詢響應(yīng)時(shí)間遠(yuǎn)少于掃描區(qū)塊的查詢響應(yīng)時(shí)間.而掃描區(qū)塊的查詢響應(yīng)時(shí)間快速增長(zhǎng),這是因?yàn)镼2 查詢需要兩次掃描區(qū)塊,并且需要進(jìn)行復(fù)雜的連接操作.

Fig.11 Response time on?Q1
圖11 查詢響應(yīng)時(shí)間(Q1)

Fig.12 Response time on?Q2
圖12 查詢響應(yīng)時(shí)間(Q2)

5.4 使用物化視圖與使用索引的查詢性能對(duì)比

本實(shí)驗(yàn)將本文提出的物化視圖方法與SEBDB 中的索引方法進(jìn)行性能對(duì)比,兩者皆采用相同的查詢和數(shù)據(jù).本實(shí)驗(yàn)固定區(qū)塊個(gè)數(shù)為1 000,每個(gè)區(qū)塊有200 條交易,結(jié)果集從1 萬(wàn)～2 萬(wàn)行增長(zhǎng).由圖13 可知:對(duì)于Q1,使用物化視圖的查詢響應(yīng)時(shí)間一直低于使用索引的查詢響應(yīng)時(shí)間;當(dāng)結(jié)果集行數(shù)增加時(shí),使用索引的查詢響應(yīng)時(shí)間增長(zhǎng)較快,而使用物化視圖的查詢響應(yīng)時(shí)間平緩增長(zhǎng).這是因?yàn)楫?dāng)數(shù)據(jù)均勻分散在各個(gè)區(qū)塊中時(shí),使用索引會(huì)引起更多的磁盤(pán)隨機(jī)讀取,而使用物化視圖是對(duì)文件的順序讀取.

如圖14 所示:對(duì)于Q2,使用物化視圖的查詢始終優(yōu)于使用索引的方式;基于索引的查詢需要隨機(jī)讀取數(shù)據(jù),并且需要進(jìn)行連接操作,因此使用索引的查詢響應(yīng)時(shí)間相對(duì)使用視圖的方式越來(lái)越長(zhǎng).實(shí)驗(yàn)證明,查詢使用物化視圖方法的性能優(yōu)于使用索引的方法.

Fig.13 Index vs.materialized view on?Q1
圖13 索引和物化視圖性能對(duì)比(Q1)

Fig.14 Index vs.materialized view on?Q2
圖14 索引和物化視圖性能對(duì)比(Q2)

此外,我們使用Q3 對(duì)比在查詢具有選擇條件的情況下,使用物化視圖和索引的性能.本實(shí)驗(yàn)固定區(qū)塊個(gè)數(shù)為2 000,每個(gè)區(qū)塊的交易為1 000 條,查詢的選擇率從0.1～1 增長(zhǎng).實(shí)驗(yàn)結(jié)果如圖15 所示:當(dāng)選擇率為1 時(shí),使用索引的查詢響應(yīng)時(shí)間比使用物化視圖的方法多40ms;隨著選擇率的下降,物化視圖的優(yōu)勢(shì)越明顯;當(dāng)選擇率為0.1 時(shí),使用索引的查詢響應(yīng)時(shí)間為使用視圖的方法的2 倍多.

Fig.15 Index vs.materialized view on?Q3
圖15 索引和物化視圖性能對(duì)比(Q3)

5.5 可驗(yàn)證查詢的性能

對(duì)于使用物化視圖的查詢請(qǐng)求,我們構(gòu)建默克爾樹(shù)對(duì)視圖進(jìn)行驗(yàn)證.本實(shí)驗(yàn)采用的視圖為Q1 形式的單表視圖.實(shí)驗(yàn)設(shè)置物化視圖維護(hù)的總記錄數(shù)從5 000 增長(zhǎng)到10 000,在掃描視圖時(shí)生成默克爾樹(shù),并與內(nèi)存中保存的默克爾樹(shù)根進(jìn)行比對(duì).驗(yàn)證查詢的延遲如圖16 所示:NV?表示不加驗(yàn)證過(guò)程的查詢響應(yīng)時(shí)間,YV?表示具有驗(yàn)證階段的查詢響應(yīng)時(shí)間.圖16 中顯示:結(jié)果集為10 000 條記錄時(shí),YV?比NV?多了約100ms.這是可以接受的,因?yàn)檫@仍然比不使用視圖的查詢要快很多.

Fig.16 Verification cost
圖16 驗(yàn)證開(kāi)銷

總結(jié)以上實(shí)驗(yàn),本文描述的物化視圖維護(hù)方法可以很好地提升查詢的性能;并且通過(guò)默克爾驗(yàn)證,保證了使用視圖的查詢請(qǐng)求結(jié)果的正確性.

6 相關(guān)工作

以支持智能合約為代表的區(qū)塊鏈2.0 平臺(tái)的提出,使得區(qū)塊鏈技術(shù)可以廣泛使用到除電子貨幣以外的傳統(tǒng)行業(yè)中.為了應(yīng)對(duì)區(qū)塊鏈在傳統(tǒng)行業(yè)應(yīng)用中所面臨的數(shù)據(jù)管理方面的新需求,來(lái)自學(xué)術(shù)界和工業(yè)界的許多工作開(kāi)始專注于區(qū)塊鏈技術(shù)與數(shù)據(jù)管理技術(shù)的結(jié)合,這將促使區(qū)塊鏈技術(shù)可以在傳統(tǒng)行業(yè)領(lǐng)域有更廣泛的使用.其中,ChainSQL[1]和BigchainDB[2]在數(shù)據(jù)庫(kù)的基礎(chǔ)上使用區(qū)塊鏈,使得數(shù)據(jù)庫(kù)具有去中心化、防篡改的特點(diǎn).FlureeDB[3]是一個(gè)結(jié)合了區(qū)塊鏈技術(shù)的可擴(kuò)展的圖形數(shù)據(jù)庫(kù),雖然它們豐富了查詢的功能,但未提高查詢的性能.SEBDB[4]為區(qū)塊數(shù)據(jù)添加了關(guān)系語(yǔ)義,并且使用索引來(lái)提升查詢性能;但對(duì)于復(fù)雜查詢或均勻分布的數(shù)據(jù)查詢,響應(yīng)時(shí)間依然較長(zhǎng).

相比于索引技術(shù),物化視圖是提升區(qū)塊鏈數(shù)據(jù)庫(kù)查詢性能更直接的辦法,但物化視圖卻會(huì)帶來(lái)額外的維護(hù)開(kāi)銷.慶幸的是,數(shù)據(jù)管理領(lǐng)域的研究人員已經(jīng)對(duì)如何降低物化視圖的維護(hù)代價(jià)做了很多方面的工作.在視圖維護(hù)策略方面,文獻(xiàn)[11,12]采用立即維護(hù)的視圖維護(hù)策略;而文獻(xiàn)[6,7]使用延遲維護(hù)策略,使視圖維護(hù)不阻塞更新事務(wù).此外,文獻(xiàn)[13,14]分別討論了分布式數(shù)據(jù)庫(kù)系統(tǒng)和NOSQL 數(shù)據(jù)庫(kù)系統(tǒng)中更新物化視圖的問(wèn)題,它們都支持增量的視圖維護(hù)方法.在降低物化視圖更新開(kāi)銷方面,早期的文獻(xiàn)[5,15?19]提出了優(yōu)化的物化視圖更新算法,它們主要利用現(xiàn)有的物化視圖和表達(dá)式進(jìn)行增量更新.文獻(xiàn)[6,20?23]提出了異步更新的視圖維護(hù)工作,對(duì)于需要集成分布式數(shù)據(jù)源的數(shù)據(jù)倉(cāng)庫(kù),這種方法的優(yōu)勢(shì)更加突出.文獻(xiàn)[14,24]將分布式環(huán)境下的物化視圖的維護(hù)工作分散到多個(gè)視圖更新程序中,通過(guò)并行維護(hù),提高了物化視圖更新的效率.文獻(xiàn)[25,26]優(yōu)化了同時(shí)更新多個(gè)相關(guān)的物化視圖的算法,它們考慮多個(gè)物化視圖之間的表達(dá)式關(guān)系,利用多個(gè)物化視圖表達(dá)式之間的公共子表達(dá)式,從而找到維護(hù)一組物化視圖的最高效的維護(hù)計(jì)劃.文獻(xiàn)[27?29]提出了物化附加視圖的方法,其中,文獻(xiàn)[28,29]提出的方法對(duì)文獻(xiàn)[27]中的方法做了優(yōu)化,節(jié)省了空間開(kāi)銷.文獻(xiàn)[30]提出了一種高階形式的增量視圖維護(hù)(HIVM)算法,該算法借鑒數(shù)學(xué)中微分的思想,遞歸地使用離散的前向差異(增量修改)進(jìn)行視圖更新.文獻(xiàn)[31]提出了在分布式環(huán)境中進(jìn)行批量更新的高效增量視圖處理技術(shù).文獻(xiàn)[32]提出一種新的數(shù)據(jù)結(jié)構(gòu),并提出基于此結(jié)構(gòu)的視圖更新算法,該算法具有常量的時(shí)間復(fù)雜度和空間復(fù)雜度.在面向區(qū)塊鏈的視圖維護(hù)中,這些方法都是可以借鑒的,但它們并不完全適用于區(qū)塊鏈的數(shù)據(jù)模型,比如不支持以區(qū)塊為粒度的視圖更新,并且區(qū)塊鏈的共識(shí)過(guò)程使區(qū)塊鏈上的視圖維護(hù)變得更加復(fù)雜.

在可驗(yàn)證查詢方面,文獻(xiàn)[33]提出了3 種可驗(yàn)證的連接算法,保證了連接結(jié)果的完整性和正確性.Vchain[34]提出了輕量級(jí)可驗(yàn)證查詢框架,并保證查詢結(jié)果的正確性和完整性,此外,Vchain 中還提出了基于雙線性配對(duì)累加器的驗(yàn)證數(shù)據(jù)結(jié)構(gòu),以降低查詢驗(yàn)證的代價(jià).它們通過(guò)驗(yàn)證返回的結(jié)果來(lái)保證查詢的完備和保真.而本文則驗(yàn)證查詢的數(shù)據(jù)來(lái)源是否正確,使得驗(yàn)證更輕便、高效.

除了物化視圖相關(guān)的工作,關(guān)于區(qū)塊鏈數(shù)據(jù)管理方面的研究工作涉及得很廣泛,文獻(xiàn)[35?37]是關(guān)于區(qū)塊鏈技術(shù)和可信數(shù)據(jù)管理方面的探討.為了提高區(qū)塊鏈系統(tǒng)的擴(kuò)展性和并發(fā)性,文獻(xiàn)[39]提出一種智能合約并發(fā)執(zhí)行的方法.

7 結(jié)束語(yǔ)

本文針對(duì)區(qū)塊鏈系統(tǒng)中,面向區(qū)塊數(shù)據(jù)的查詢響應(yīng)太慢的問(wèn)題,提出了一套面向區(qū)塊鏈中區(qū)塊數(shù)據(jù)查詢的物化視圖構(gòu)建、維護(hù)和訪問(wèn)機(jī)制:首先,本文選擇合適的時(shí)機(jī)進(jìn)行視圖維護(hù),使得視圖維護(hù)過(guò)程隱藏于共識(shí)過(guò)程中,并以區(qū)塊為粒度,采用字典樹(shù)的元數(shù)據(jù)存儲(chǔ)方式加快了視圖維護(hù)的過(guò)程;其次,本文采用混合式的多種維護(hù)策略相結(jié)合的視圖維護(hù)方式,降低了查詢的延遲;最后,本文提出默克爾樹(shù)驗(yàn)證方法使得本地物化數(shù)據(jù)不會(huì)被惡意篡改,進(jìn)而保證了查詢結(jié)果的有效性.

本文提出的面向區(qū)塊鏈中區(qū)塊數(shù)據(jù)查詢的物化視圖機(jī)制,實(shí)現(xiàn)在一個(gè)真實(shí)的區(qū)塊鏈平臺(tái)[4]中.實(shí)驗(yàn)結(jié)果表明,本文的方法高效可行.但是和關(guān)系模型相比,對(duì)于區(qū)塊鏈中數(shù)據(jù)的鏈?zhǔn)酱鎯?chǔ)模型,針對(duì)復(fù)雜查詢的物化視圖創(chuàng)建和維護(hù)面臨著更多的挑戰(zhàn).比如:對(duì)于復(fù)雜的業(yè)務(wù)場(chǎng)景,為了保證查詢效率,區(qū)塊鏈需要?jiǎng)?chuàng)建的物化視圖更多.因此,我們將繼續(xù)探究物化視圖的更新、選擇在區(qū)塊鏈中與關(guān)系數(shù)據(jù)庫(kù)的不同之處,動(dòng)態(tài)地為每個(gè)智能合約精準(zhǔn)預(yù)創(chuàng)建物化視圖,在保證系統(tǒng)查詢性能下的同時(shí),使得物化視圖所占空間盡可能小.我們下一步的工作重點(diǎn)是研究支持復(fù)雜查詢,例如多表連接、聚集查詢等的有效物化視圖維護(hù)機(jī)制,我們也將進(jìn)一步探討將基于物化視圖的可信查詢與可信硬件SGX 結(jié)相合,使得可驗(yàn)證查詢的響應(yīng)時(shí)間更短.

我們的服務(wù)類型

公開(kāi)課程

人工智能、大數(shù)據(jù)、嵌入式? ? ? ? ? ? ??? ?? ?

內(nèi)訓(xùn)課程

普通內(nèi)訓(xùn)、定制內(nèi)訓(xùn)? ? ? ? ? ? ? ?? ??? ? ??

項(xiàng)目咨詢

技術(shù)路線設(shè)計(jì)、算法設(shè)計(jì)與實(shí)現(xiàn)（圖像處理、自然語(yǔ)言處理、語(yǔ)音識(shí)別）

總結(jié)

以上是生活随笔為你收集整理的面向区块链的高效物化视图维护和可信查询的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。