面向区块链的高效物化视图维护和可信查询

面向区块链的高效物化视图维护和可信查询

人工智能技术与咨询 

来源：《软件学报》 ，作者蔡 磊等

摘 要:区块链具有去中心化、不可篡改和可追溯等特性,可应用于金融、物流等诸多行业.由于所有交易数据按照交易时间顺序存储在各个区块,相同类型的交易数据通常会散布在诸多区块之中,降低了面向历史区块的追溯查询的处理效率.索引构建和物化视图是提升查询性能的两种典型方法,但当待处理数据分布于多个区块时,使用索引无法改善I/O 访问效率,而物化视图可有效应对这个问题.然而,由于区块链系统的特点明显区别于关系数据库,传统的面向关系数据库的物化视图技术无法被直接应用到区块链之中.鉴于此,首次提出一种面向区块链的高效物化视图机制,具有如下特征:(1)将视图维护操作与共识过程同时执行,降低该操作对系统性能的影响;(2)使用字典树加快以区块为单位的多物化视图维护进程;(3)以默克尔验证的方式确保物化结果不被恶意篡改,进而确保查询结果可信.所提出的物化视图维护机制已经被集成到一个区块链系统中,并通过实验来验证该机制的高效性.

关键词:物化视图;区块链;增量更新;视图维护;默克尔树

作为一种在不可信环境中由多方共同维护的分布式账本,区块链已被应用在金融、物流等领域.然而,当前的区块链技术在数据管理方面存在着无法支持复杂查询、查询接口单一和响应太慢等局限性.

为了弥补现有区块链平台在数据管理性能方面的不足,一些课题组尝试融合数据管理和区块链技术,例如ChainSQL[1],BigchainDB[2],FlureeDB[3],SEBDB[4]等.ChainSQL 将关系数据库和Ripple 区块链网络相结合,借助关系数据库的访问接口为链上数据访问提供便利,并使用区块链技术来提升数据异地多活的容错能力.BigchainDB 是一种添加了区块链特征的数据库,它集成了MongoDB 和Tendermint 区块链网络.FlureeDB 将区块链技术中不可篡改和高容错特性集成到图形数据库.以上工作尽管提供了更丰富的查询功能,但是并未聚焦查询性能优化.SEBDB[4]在面向传统行业的联盟链背景下,为区块数据添加了关系语义,将每种交易类型转化为一张关系表,将该交易类型的参数转化为相应关系表的列,从而有效融合关系语义和区块数据.

在区块链中,区块包括区块头(block header)和区块体(block body),如图1(a)所示:区块头由前一个区块的哈希值、区块ID、区块生成时间、交易默克尔树根、签名和本区块的哈希值组成;区块体包含多个交易,每个交易由交易ID(TxID)、交易签名(TxSig)、智能合约调用者(TxCaller)、交易时间(TxTime)、交易表名(TxName)和表数据(TxData)组成.图1(b)为一个交易示例,表示用户Alice 调用智能合约中的donate 函数向教育基金项目Edu Fund 捐助了100 元.在SEBDB[4]中,交易表名相当于关系数据库中的表名,表数据包含若干列,相当于关系数据库中的一行记录.

Fig.1 Structure of block and transaction
图1 区块和交易结构

由于交易数据在区块中以交易提交的时间顺序依次存储,属于同一关系表的交易数据往往会分散在不连续的多个区块中,这会降低针对区块数据的查询的执行效率.SEBDB[4]通过在区块链上建立B+树、位图等索引提高查询性能,但是当查询涉及到多个区块时,使用索引无法持续降低I/O 访问开销,因而无法进一步改善查询处理效率.在数据库中,建立物化视图是另一种提高查询效率的方法,物化视图通过物化查询结果来提高特定查询的处理效率.因此,如何在区块链中使用物化视图也值得思考.

尽管物化视图已被研究多年,如何维护物化视图仍旧是一个开放问题.在关系数据库中,增量刷新的物化视图维护策略可划分为立即维护[5]和延迟维护[6]两大类.立即维护策略的优点是实现较为简单,在单数据源下不存在一致性问题;然而该策略将物化视图维护过程嵌入到更新事务之中,延长了更新事务的提交时间,这在高并发的情况下易发生死锁.延迟维护策略解耦合视图维护和更新事务,在OLTP 场景下,可以通过合并无关更新[6]的方法缩短视图维护时间;但是此策略存在一致性问题,若视图未更新完毕则不可使用.在延迟维护策略的诸多实现方法中,按需维护[7]较为常见,即:等待查询到来之后,只维护与查询相关的物化视图.由此可见,各种策略的优缺点显著,如何合理选择视图维护策略非常重要.

面对被赋予了关系语义的区块数据,采用关系数据库中普遍使用的建立物化视图的方式来提升查询性能是一种可行的方法.在区块链中,系统查找某张表的数据需要扫描所有的区块,当数据量庞大时,即使扫描索引也会产生非常大的开销.鉴于此,如果将物化视图运用于区块链,将会优化查询的处理效率.

然而,关系数据库与区块链系统在存储模型和更新操作上有显著不同,区块链系统以区块为单位进行更新,单个区块包含多条交易,并且区块链系统中的交易需要通过共识来完成.区块链系统和关系数据库相比,在区块链上建立、维护物化视图将面临以下3 个挑战.

(1)如何选择物化视图的写入时机.区块链的写入性能受到分布式共识、智能合约执行限制,而物化视图的维护开销对系统的性能带来额外影响.因此,如何合理选择视图维护的时机来降低视图维护对系统整体性能的影响,是一个需要考虑的问题;

(2)如何以区块为单位维护视图.区块是区块链的基本数据追加单位,各区块包含多种类型的交易,对于一个区块可能需要同时维护多个视图.因此,设计的方案必须支持批量的物化视图维护,并且使得物化视图维护的开销尽可能小;

(3)如何确保查询结果的可信性.由于数据上链需要经过较为昂贵的共识过程,为了提升查询效率,物化视图并不保存在区块链上.与此同时,将物化视图保存在本地会面临数据被篡改的风险,需要实施相应措施来确保查询结果可信.

针对以上挑战,本文的主要贡献包括:首次将物化视图运用于区块链,提出了一种视图维护和共识过程并行的方法,降低物化视图的维护开销.区块链的共识过程主要消耗网络带宽,在此期间,CPU 和I/O 资源消耗相对较少,而视图维护过程却主要消耗CPU 和I/O 资源.因此,将视图维护和共识过程并行执行可减少视图维护对写入性能的影响.提出了基于字典树的方法,以区块为单位批量维护视图,并且支持多种维护策略.本文使用字典树作为索引加快查找不同表名的更新记录,可对相同表名的更新记录只进行一次视图维护操作.并且本文支持闲时维护和按需维护的维护策略.提出了基于默克尔树的查询结果验证方法,确保结果可信.为物化视图构造默克尔树.当查询使用物化视图时,系统扫描物化视图建立默克尔树,并与预先保存的默克尔树根进行比较,以此确保物化视图的正确性与完整性.

本文第1 节说明本文的系统架构.第2 节阐述物化视图的维护时机.第3 节描述物化视图维护的具体过程.第4 节详述基于默克尔树的查询验证方法.第5 节展示实验结果.第6 节回顾与本文相关的研究工作.最后,第7节给出简短总结.

1 系统架构

本文原型系统架构如图2 所示,包括应用层、查询层、存储层、共识层和网络层:应用层包括查询API、访问控制和智能合约;查询层具有查询引擎,负责对查询的解析、优化、执行,包括物化视图的维护;存储层包括区块链和链下数据(物化视图、索引等);共识层负责交易的共识,运用的协议为PBFT[8];最后,网络层采用Gossip协议.本文专注于查询层、存储层和共识层:物化视图的更新记录来自于共识返回的结果,查询层负责物化视图的维护工作,并将更新后的物化视图存于存储层.此外,查询的结果来源于存储层的区块数据或物化视图.