面向区块链的数据管理中间件

邓思佳 佟兴 唐海波 张召 金澈清

摘要：作为一种去中心化的分布式账本，区块链被广泛应用于互不可信的多方之间共享数据.相比于发展 多年的传统数据库，区块链存在无法支持丰富查询、对外提供查询接口单一和查询响应慢的问题.简单的 组织结构和离散的存储方式是限制交易数据表达的主要原因.为了弥补现有区块链系统的不足，构建抽象 模型、封装易于使用的接口以及提升查询效率是实现基于区块链的高效应用开发的主要方式.鉴于此，提 出一种面向区块链的通用数据管理中间件，具有如下特征：①支持自定义构建数据模型，灵活地为交易数 据抽象新模型;②提供多种数据访问接口支持丰富查询并采用同步缓存机制等优化方式提升查询效率; ③设计提前哈希计算和异步批处理策略优化交易的延迟和吞吐.提出的数据管理中间件已集成于开源区 块链CITA中，并通过实验验证其易用性与高效性.

关键词：区块链;数据管理;交易数据;抽象模型

中图分类号：TP302       文献标志码：A       DOI： 10.3969/j.issn.1000-5641.2021.05.006

Blockchain-oriented data management middleware

DENG Sijia， TONG Xing， TANG Haibo， ZHANG Zhao， JIN Cheqing

（School of Data Science and Engineering， East China Normal University， Shanghai 200062， China）

Abstract： As a decentralized distributed ledger， blockchain technology is widely used to share data between untrusted parties. Compared with traditional databases that have been refined over many years， blockchains cannot support rich queries， are limited to single query interfaces， and suffer from slow response. Simple organizational structures and discrete storage limits are the main barriers that limit the expression of transaction data. In order to make up for the shortcomings of existing blockchain technology and achieve efficient application development， users can build abstract models， encapsulate easy-to-use interfaces， and improve the efficiency of queries. We also propose a general data management middleware for blockchain， which has the following characteristics：① Support for custom construction of data models and the flexibility to add new abstractions to transaction data;② Provide multiple data access interfaces to support rich queries and use optimization methods such as synchronous caching mechanisms to improve query efficiency;③ Design advance hash calculation and asynchronous batch processing strategies to optimize transaction latency and throughput. We integrated the proposed data management middleware with the open source blockchain CITA and verified its ease of use and efficiency through experiments. Keywords： blockchain; data management; transaction data; abstract model

收稿日期：2021-08-04

基金項目：国家自然科学基金（U1811264， U1911203， 6197215（2）

通信作者：张召，女，教授，博士生导师，研究方向为区块链系统研发、海量数据管理与分析

E-mail： zhzhang@dase.ecnu.edu.cn

0引 言

在多方参与的交易、物流、金融服务等业务场景中，传统集中式服务的弊端逐渐显露，各个参与 系统较中心化，难以实现信息安全共享和跨机构可信验证.区块链作为一种去中心化、不可篡改、可 追溯的分布式账本，在没有第三方中介机构协调的条件下，支持互不可信的参与方之间的数据共享， 为数据协作带来了新机遇.例如，在基于区块链的钢铁交易系统中，如图1所示，在钢铁交易场景下以 钢厂、交易中心、物流平台和监管机构为核心节点搭建的许可链中，钢厂、交易中心、物流平台的大量 业务人员通过这些平台存证订单发售、订单成交、订单定货、仓库入库等数据来共享订单的全周期状 态信息.同时区块链的完整性、不可篡改等特性保证了政府组织的监管人员对订单流程的有效跟踪， 形成了钢材交易的全流程监管体系，助力金融交易模式的创新发展.

尽管区块链系统吸引了广泛的关注，但是和发展已趋成熟的传统数据库相比，区块链技术尚处于 初期阶段，正面临着多方面的挑战.其中，无法支持复杂查询、对外提供接口单一以及延迟高是限制区 块链被大规模应用于实际生产开发的主要因素.

在区块链中，交易是指操作区块链的日志数据，其内部没有严格的数据模型，典型的交易为包含 多个属性值的结构化数据.一段时间内一定数量的交易被打包为区块并在多个节点间达成共识，因此， 逻辑上属于同一类型的交易数据，往往分布在不同的区块中;交易数据物理存储在Key-Value数据库， 如LevelDB，甚至文件系统中，仅对外提供有限的数据访问方法;除此之外，为了节省空间，数据通常 会被高度压缩后同步到存储磁盘，这种处理不利于用户对区块数据的訪问.正是这种简单的数据结 构、离散的组织形式以及不易索引的底层存储，限制了交易数据的语义表达，导致区块链具备的数据 管理功能非常有限.

为了弥补区块链在数据管理方面的不足，学术界和企业界在区块链和管理技术融合方面做了许 多努力，如 BigChainDB[1]、SEBDB间、BlockchainDB[3]和 EtherQL⑷.BigChainDB[1]是基于 MongoDB 构建的具有区块链特点的数据库的典型代表，但是，其查询方式依赖于MongoDB原生接口，查询性能 也受MongoDB制约.SEBDB[2]在区块链系统中添加了支持关系语义的查询处理引擎，并通过构造索 引结构加快查询速度，但是，其支持的查询功能有限，二次开发难度大.BlockchainDB[3]在区块链的上 层添加数据库层，对内在数据库层使用基于哈希的分片方式将读写请求分发到不同的数据节点上，对 外提供方便易用的查询接口，但是，其仅支持单一的PUT/GET操作.EtherQL[4]在以太坊的上层设计 查询层，将区块链数据拷贝到查询层中并通过查询层提供接口实现丰富查询，但是，其受限于底层存 储MongoDB的有限查询支持，并未充分发挥出区块链的全部潜力.以上工作尽管从某一方面优化了 区块链的数据管理，但是并未兼顾区块链应用开发的通用性和高效性.因此，实现对区块链的高效管 理具有重要的现实意义.

在传统数据库中，高效的数据管理离不开易于使用的抽象模型和丰富的语义描述.然而，区块链 系统与传统数据管理系统在体系结构和存储模型上存在显著不同，提升区块链的数据管理效率将面 临以下3个挑战.

（1）如何对交易数据抽象建模根据应用场景灵活地为交易数据添加抽象模型，将无序离散的交 易构造成结构化或非结构化数据.

（2）如何减少用户的使用成本向上提供多种数据访问接口，向下抽象底层通信处理过程，降低 开发人员使用区块链共享数据的复杂度.

（3）如何优化数据管理性能优化区块链交易处理以及数据查询流程以提升基于区块链的开发应 用效率.

本文提出了基于区块链的数据管理架构，将现有的区块链系统作为防篡改和去中心化的存储层， 无须对其进行改动，并在上层添加了数据管理中间件，针对上述挑战提出相应解决方案，提升数据管 理效率.数据管理中间件提供以下功能.

（1）自定义数据模型通过灵活的Schema将区块链交易数据组织成各种抽象模型，同时，提供多 种数据访问接口支持丰富查询，包括方便使用的SQL接口以及低耦合的REST接口.

（2）数据高效查询查询引擎可以依据同步缓存机制高效处理不同类型的查询请求.另外，同步 缓存机制的持久化存储支持SQL数据库.

（3）交易处理优化采用提前计算哈希的处理方式降低交易延迟，并通过异步批处理策略提升交 易吞吐，最大化利用系统资源.

面向区块链的数据管理中间件具有通用性，为开发人员提供了灵活的数据模型和用户友好的访 问接口，并兼容多种区块链系统和数据库，降低对存储层的依赖.同时，数据管理中间件的维护开销不 会给整个架构带来额外影响.此外，数据管理架构具有可扩展性，开发人员可部署多服务，以支持高可 用的多方协作并通过反向代理实现负载均衡.

1系统架构概述

本文原型系统架构如图2所示，包括数据管理中间件和存储层.数据管理中间件由5个模块组成： 数据访问接口、数据管理器、交易处理器、查询引擎以及RPC连接器.其中，数据访问接口对外提供 SQL接口，与客户端进行交互;数据管理器负责命令解析以及数据建模;交易处理器负责构造交易和 优化交易处理流程;查询引擎提供索引和同步缓存机制，负责数据同步与交易解析;此外，RPC连接 器负责与区块链间的通信，数据的读写均来源于由区块链和外部存储组成的存储层.

在此架构下，数据管理中间件对外提供SQL接口与数据模型交互，封装复杂的内部实现，支持包 括关系模型在内的多种抽象数据的构造与维护，并且依据Schema检查或解析交易字段，执行来自应用程序的读写请求.当数据管理中间件接收到客户端发来的查询请求时，直接调用查询引擎中同步缓 存到外部数据库的结构化数据加速读取;当数据管理中间件接收到客户端发来的上链请求时，交易处 理器采用的提前哈希计算以及异步批处理的优化策略会大大加快整个交易执行过程，进一步提高效 率.此外，数据管理中间件还设计了 RPC连接器抽象化与RPC接口的通信过程，以减少对存储层的 依赖性.存储层采用现有的区块链系统来存储数据，保留区块链系统基本的安全性特征，如不可篡改 和去中心化等，同时提供数据管理中间件的数据持久化存储，通过简单配置实现伸缩性.

2自定义数据模型

2.1数据建模

图3给出了一般区块链的链式结构，区块链的基本单位是区块，区块由区块头和区块体组成，其 中，区块头记录了前一区块的哈希值、区块生成时间、交易默克尔树根等信息.每个区块都包含前块 哈希，一旦一个区块的内容被篡改，就需要更改所有后续的区块哈希，区块链通过这种链式结构保证 了数据的防篡改特性.区块体内包含一组以默克尔树的结构组织的交易，其中，默克尔树根是对区块 内所有交易的证明，保证了数据的可验证.交易记录了用户的更新操作，以比特币为例，交易中包含了 转账信息，包括转账接收者、交易金额等.对于支持智能合约的以太坊，交易中还记录了智能合约的调 用参数.

在区块链中，交易可以视为包含多个属性值的结构化数据，除交易ID、交易生成时间、交易签名 等系统属性值外，与实际应用相关的参数都记录于数据（Data）字段中，而且调用同一智能合约生成的 交易具有相同的数据结构.因此，数据管理中间件采用统一的语义——Schema声明来描述这种交易 关系，根据交易中数据字段的属性值与Schema中的属性名，将交易数据抽象为逻辑数据模型，这种建 模大大降低了区块链的应用开发难度.同时，数据建模十分灵活，交易数据可以抽象为关系模型，支 持SQL语言对区块链做丰富查询;也可以抽象为键值对形式，其中键表示主键，值表示元组的有效负载.

图4所示为发票数据建模示例，开发人员将应用信息组织成关系模型写入Schema，构造为一张由 票头（InvoiceNo）、客户名称（ClientName）、金额（Amount）以及开票日期（Date）等属性名组成的关 系表Invoice，并调用智能合约将发票上链存证，具体发票信息存储在区块^的交易m和区块^的交 易n中.交易经过Schema检查后，Data字段中的属性值逻辑映射为表Invoice的元组.Invoice_Table表中的两行记录分别表示交易m中的一张2021年1月1日由Alice开具的票头为IN00001、交 易金额为10000的发票信息和交易W中的一张2021年2月2日由Allen开具的票头为IN00002、交易 金额为20000的发票信息.

Schema

TR交易

TA 表

Id， Time， Signature， Data

m 2020-01-01  0x123456789a..

... IN00001Alice100002020-01-01..

n 2020-02-02   0xfedcba9876...

... IN00002Allen200002020-02-02...

Date

2.2 SQL与数据处理

区块链的底层存储形式十分简单（例如，以太坊使用键值数据库LevelDB存储交易数据），而且仅 向上层应用提供RPC接口，支持简单的查询逻辑.因此，基于区块链的数据查询十分受限于其底层原 生支持，不仅支持的查询功能有限，对开发人员也有更高的技术要求.

SQL查询是一种高效的查询方法，通过SQL接口可以支持复杂的查询逻辑，也能有效解决区块 链在数据管理方面存在的无法支持复杂查询和查询接口单一两大问题.因此，数据管理中间件利用区 块链系统提供的基于RPC的接口封装了一组SQL接口支持丰富高效的查询操作.开发人员可以使 用SQL语言管理区块链，无须考虑区块链的底层存储细节，即可进行便捷的上层应用开发.表1列出 了开发人员能够对数据模型执行的3种主要管理操作CREATE/ALTER、INSERT和SELECT以及 它们在数据管理中间件内部的主要处理流程.

图5展示了 SQL请求在数据管理中间件中的数据处理流程，该流程可分为数据建模、数据上链以 及数据查询3步.当上层应用发起CREATE/ALTER请求与数据管理中间件进行建模交互时，数据 管理器在解析请求后，将表名、属性约束等信息组织成数据模型的结构，并将结构体中的有效数据写入Schema文件中.Schema通常很小且更新频率低，一次更新可以处理多次读写，因此Schema的存 储和维护不会给整个系统架构带来额外影响.此外，数据管理中间件用字典树对Schema名进行索引， 这种组织方式可以加速在需要多种Schema的业务场景下的Schema快速匹配.

一旦数据管理器成功创建或更新Schema，就可以基于抽象模型处理应用场景下的一系列数据管 理请求.当处理数据上链情况时，数据管理器根据Schema规则检查INSERT请求的完整性和准确性， 只有符合Schema描述的所有约束条件的数据才能被验证为合法数据并转发到交易处理器中，交易处 理器将其构造成交易并插入交易队列中.当处理数据查询情况时，查询引擎直接查取按照Schema规 则解析为抽象模型并存入同步缓存中的交易数据.Schema机制在整个处理过程中不但可以灵活地抽 象应用场景，不需要考虑数据模型结构化与否，而且可以将数据模型组织成任意区块链系统的交易结 构，对底层没有依赖性，具有通用价值，是实现通用高效的区块链数据管理的核心.

3高效查询处理

区块链系统与传统数据库在数据存储方面存在巨大差异.从打包方式来看，区块链中的数据以交 易的形式存放，交易通过共识方可生效，共识通过的一些交易在某个时间点被打包成区块.由于交易 是按照时间顺序被打包到区块中的，因此单个区块内可能含有不同类型（调用了不同的智能合约函 数）的交易，即相同类型的交易数据通常分布在不同区块，当查询同一类型的交易时需要遍历整个账 本才能确保查询结果的完整性，这种离散的数据分布降低了区块链I/O访问效率.随着区块链系统的 运行，交易的不断产生会导致区块链越来越长，因此查询单一类型交易的时间也会越来越久;从底层 存储来看，区块数据物理存放在简单的Key-Value数据库中，如LevelDB，这类数据库会定期将数据 同步到磁盘，同时为了节省存储开销将对这些数据进行自适应压缩，数据的实际组织变得难以预测. 这种方式不利于对区块链进行复杂查询，因为访问区块中的交易数据十分耗时，往往需要从散布在整 个磁盘上的数十万个文件中随机读取.

为解决交易离散式分布存储带来的查询效率低下问题，数据管理中间件在查询引擎模块中设计 了索引结构和同步缓存机制，并且可以根据不同应用场景的安全要求和工作负载灵活使用优化方法， 在提升查询性能的同时，减少数据更新对整个架构存储带来的影响.在某些期望使用豐富的查询和统 计功能（如聚集查询等）的场景下，同时允许适当放宽安全性级别的要求，那么考虑到兼容性以及查询 效率，相比索引等优化方法，更通用的一种方式是采取同步缓存机制.

数据管理中间件主动地将最新区块数据实时同步，并调用Schema将交易构造为数据模型的结构 存储于数据库中，从根本上优化了在物理存储上的查询性能，确保查询既准确又高效.同步缓存机制 设置一个独立的配置文件负责维护当前区块高度信息，查询引擎仅允许开发人员通过指定的SQL-like 请求UPDATE HEIGHTSCAN更新配置，不设置其他配置更改方式，以保证其安全性.当区块链运行 时，启动单独工作的同步监听线程读取配置文件中的块高作为初始值扫描区块（系统刚启动时初始值 为O，确保同步完整的历史区块），每扫描况个区块周期触发检查点，更新配置信息，重复上述过程直 到请求到最高块.同步任务设置空闲检测来保证实时通信，并保持每3 s请求一次区块高度的轮询.

目前大多数区块链均采用虚拟机（Ethereum Virtual Machine， EVM）来屏蔽节点底层的实现差 异，向上层只提供RPC接口完成与节点的交互.在数据管理中间件中，交易管理器将成功通过 Schema检查的数据构造成交易的形式并对其签名，随后通过RPC连接器访问区块链.RPC连接器的 功能是为数据管理层封装一个抽象存储接口，减少对底层区块链类型的依赖.如表2所示，RPC连接 器实现的3种主要方法为Read、Write和Check.

Read方法根据交易哈希或块高读取交易数据并将其以字节形式反序列化后转发给数据管理中间 件.Write方法将交易数据序列化为字节形式，再将其发送到区块链进行处理，并返回唯一交易哈希 值tx-hash到数据管理中间件.此外，RPC连接器通过Check方法查询交易哈希为tx-hash的交易的 上链状态.

数据管理中间件将最新交易数据从区块链同步到缓存后，对缓存中的数据进行处理并将其持久 化.这一同步过程中存在两个问题：①中间件可能缓存或者持久化了没有上链成功的交易，造成读取 不正确;②中间件中并未缓存最新的交易数据，导致读取不到最新数据.

为了解决上述问题，查询处理器与交易处理器进行协调处理.具体处理过程：当中间件处理 INSERT请求进行数据上链后，交易处理器调用RPC接口的Check函数检查交易数据是否上链.如 果上链则表示交易成功，此时在同步缓存机制下，数据管理中间件通过RPC接口的Read方法扫描区 块，将交易数据同步到查询引擎的缓存中，然后利用Schema解析交易数据，按抽象的数据模型对交易 数据进行持久化.这样既保证了缓存中不会出现未上链的交易又保证了最新数据的同步，同步之后的 查询请求就可以根据持久化的数据模型进行相应的SELECT操作.

此外，数据管理中间件使用Schema解析交易为抽象数据类型后可以根据配置进行全量同步或部 分同步，如在上文提到的发票数据上链场景中，用户可以选择仅同步开票时间为2020年以后的发票 信息，以减少冗余写入，更灵活地适应多方协作下的业务场景.同步缓存机制保证绝大多数区块仅需 被扫描一次，实质上，是对数据管理中间件中的持久化的数据进行查询，从而避免重复冗余扫描，降低 通信开销和区块读取延迟，在读密集型工作负载下，数据管理中间件的查询性能将得到显著提升.

4交易处理优化

当数据管理中间件执行来自应用程序的INSERT请求时，调用Write方法访问区块链并等待交易 哈希tx-hash返回，这个过程会阻塞系统其他读写操作，从而导致整个系统响应缓慢.基于此，我们提 出一种提前计算哈希的优化策略加速交易处理过程，在调用Write方法后立即使用与上链过程相同的 哈希算法计算tx-hash值并返回上层.对于数据管理中间件而言，在交易上链阶段主要消耗网络带宽， 而CPU资源相对空闲，因此提前计算哈希与交易上链可以并行执行.与原始的高延迟低吞吐的串行化 处理相比，提前进行哈希计算大大缩短了上层响应时间.然而，异步处理方式不能保证所有INSERT 请求的交易成功上链，在此基础上，为了确保异步通信数据的完整性，交易处理器将提前计算哈希值 tx-hash放入交易队列中，检查线程轮询交易队列并调用Check方法检查交易状态，判断交易数据是 否上链.

为了提升数据管理中间件与存储层之间的吞吐，采用工业生产常用处理方式，对交易进行异步批 量处理.批处理在写密集型工作负载下对数据管理中间件到区块链节点的吞吐提升效果显著，但这可 能会导致两个问题：首先，在读密集型工作负载下，批处理方式可能导致交易队列一段时间内处于休 眠状态;其次，当对INSERT的数据立即执行SELECT操作时，区块链可能返回的不是完整的数据集.

数据管理中间件的优化方式是在交易处理器中定义队列最大等待长度以及最长等待时间，采用 计数器和计时器动态设置队列长度从而控制等待延迟.具体批处理策略与区块链的交易打包策略保 持一致，这样的好处是当同一类型的交易大规模上链时，经过交易管理器处理后可以打包为同一区块， 在提高资源利用率的同时，大大降低交易离散程度，这些交易密集分布在同一个或相邻的几个区块， 降低了后续查询处理过程中扫描区块的开销.虽然这种最终一致性的处理方式不能保证开发人员实 时查询到交易最新值，但是它比同步阻塞查询延迟要低很多，在实际应用环境中更有生产价值，具体 描述如算法1所示.

算法1提前哈希计算和异步批处理

输人：Metadata交易数据，Tx交易 输出：Txhash交易哈希，Txset交易集合

1： Function EARLYHASHCOMPUTE （Metadata）

2：      If check （Metadata）==true then//通过Schema機制验证为合法交易数据

3：      Tx — construct （Metadata）//构造交易并签名

4：      Txhash —prehash （Tx）//提前计算哈希名

5：      End if

6：      Return Txhash//将交易哈希值返回客户端

7： End function

8： Function BATCHPROCESSING Tx 9：      O — Counter//批处理策略计数器

10：   O —T皿er//批处理策略计时器

11：   While Counter <=WriteQueue.maxsize and Timer <= WriteQueue.maxtime do

12：   Tx — Writequeue.push（）

13：   End while

14：   If Counter == WriteQueue.maxsize or Timer == WriteQueue.maxtime then

15：   Txhead — WriteQueue.front（）

16：   While WriteQueue.empty（）        do

17：   Txset — WriteQueue.pop（）

18：   End while

19：   0 — Counter

20：   0 ^ Timer

21：   End if

22：   Return Txset//將交易集发送到区块链

23： End function

算法1描述了提前哈希计算和异步批处理策略的过程，输入参数为交易数据Metadata，输出参数 为交易哈希Txsethash.算法第1 一2行描述了数据管理器将Schema检查的合法交易数据Metadata 转发到交易处理器，第3—7行表示对经过交易处理器签名后的交易数据Tx执行提前哈希计算并将 哈希值Txhash返回上层，哈希计算延迟远远小于数据管理中间件与区块链之间的通信延迟，因此提 前哈希计算可以提高应用开发效率.第8—11行将交易数据加入交易队列，计时器/计数器负责动态 评测当前队列的负载.第12—17行表示一旦发现计时器或计数器达到阈值，从交易队列中依次调度 任务并将其批量处理打包为交易集合Txset.第18—21行表示数据管理器将交易集合发送到区块链， 区块链对交易进行处理并将哈希Txsethash返回至数据管理中间件，批处理策略在保证延迟低的前提 下极大地提升了系统吞吐.

5实验评估

5.1实验环境

本文将提出的数据管理中间件应用到开源区块链CITA中，实现了数据管理架构SQL-CITA以 验证本文所提出方法的有效性.实验在配备Intel Xeon（R） 3.00 GHz的CPU、16 G的RAM和1 TB 的硬盘上进行，运行在Ubuntu16.04上，CITA默认3 s出一个块，启动4个节点.另外，我们基于数据 管理中间件开发了一个客户端，其他系统也可以通过POST请求访问SQL-CITA.

以钢铁期限联动场景为例：钢铁交易中心将数据上链存证实现信息安全共享;商委监管平台对链 上数据进行查询实现钢材交易全流程监管.如图6所示，Invioce表记录了期现联动场景下订单的发票 信息，原型支持数据表创建与修改、表数据的添加及查询.通过演示SQL-CITA的上链存证和数据查 询功能，展现面向区块链的通用高效数据管理架构在金融产业链服务中的价值.

由于系统原型的局限性，这里工作负载涉及的创表、上链和查询执行的相关语句均为表3所示的 形式.为了构造大量的测试数据，我们设计并实现了一个数据生成器，模拟真实场景下随机生成的发 票信息.将从SQL-CITA的整体读写性能以及数据管理中间件中的Schema建模、同步缓存机制以及 交易优化处理技术多个角度进行实验对比，从而论证数据管理中间件的有效性.

5.2读写性能对比

本节将数据管理中间件与CITA工具cita-sdk-java进行上链与查询性能对比，其中，cita-sdk-java 集成了与CITA客户端交互的功能，两者皆采用相同的数据集.交易个数从1000笔增长到10000笔. 图7显示，对于I形式的上链，SQL-CITA处理上链操作的时延高于CITA，造成高时延的原因可以从 SQL-CITA为了支持复杂查询在数据管理中间件中引入的数据管理器和交易处理器两个方面去分析. 虽然SQL-CITA采用了交易优化处理手段减少延迟，但数据上链过程中的网络通信、请求解析和交易 构造均需要额外的时间开销.从图中可以看出，使用SQL-CITA工具的上链时间增长缓慢，与使用CITA 工具链的上链时间相比也没有逊色很多，从开发人员的角度来看，在可接受的额外开销内SQL-CITA 大大提升了用户体验，因此SQL-CITA具有更好的实际应用性.

图8显示，对于Q形式的查询，使用SQL-CITA工具的查询响应时间远远小于直接使用CITA工 具的响应时间，且SQL-CITA增长缓慢，而使用CITA客户端的查询响应时间增长迅速.这是因为 SQL-CITA使用的同步缓存机制有效降低了查询延迟，使基于CITA的数据查询性能得到显著提升.

5.3 Schema维护性能

我们通过创建C形式的Schema来比较上链过程与Schema检查所需要的时间.图9显示了数据 量规模在1万?2万条记录的情况下的整个数据上链过程和Schema检查过程的时间开销.如图9 所示，对于I形式上链的交易，Schema检查在数据上链中所占时间非常有限，即使系统一次上链2万 条数据记录，也仅需要2 s的时间，因此，Schema检查过程对SQL-CITA数据上链的时间影响非常小， 在5.2节的上链性能对比实验中，导致SQL-CITA略高于CITA的延迟的瓶颈并不是Schema处理与 维护.

图10显示了数据量规模在1万?2万条记录的情况下的数据同步和Schema解析的时间开销. 如图10所示，Schema解析的时间开销不足整个数据同步的时间开销的一半，即使系统同步2万条数 据，也仅需要3500 ms的时间.因此，Schema解析过程对SQL-CITA同步缓存机制的影响非常小，结 合本节的两个实验可得，在整个数据管理中间件的执行过程中Schema处理与维护并不会造成系统的 性能瓶颈.

5.4同步缓存机制性能

对于使用SQL-CITA的数据查询请求，我们在SQL-CITA中实现了通用的同步缓存机制.实验设 置单个区块包含的交易笔数，固定交易集为20000个，其中通过配置CITA单个区块内可消耗的 Quota值动态设置区块大小从包含50笔交易、100笔交易到包含150笔交易，每笔交易均为通过I形 式上链的交易.交易个数从2000笔到20000笔增长，以对比单个区块不同大小下的同步缓存机制性能. 如图11所示，在Q查询形式下，随着单个区块存放的交易笔数的增加，同步的响应时间减少.这是因为同步缓存机制通过实时跟踪区块块高、同步最新交易以减少数据查询时扫描整个区块造成的 延迟，在待上链交易数量相同的情况下，单个区块可存放的交易数越多，最后共识生成的区块越少，因 此同步缓存机制扫描区块的延迟越低.

5.5交易优化处理性能

在数据管理中间件中，我们使用了提前哈希计算和批处理的方法来优化数据插入过程，以减少频 繁网络通信所带来的开销.本节对I形式上链的交易分别使用SQL-CITA的同步处理和异步处理，固 定交易集为20 000笔，交易笔数从2000笔增长到20000笔.图12显示，同步处理上链的响应时间一 直高于异步处理上链的响应时间，这是因为同步处理通信时，数据管理中间件要等待交易上链并返回 结果后才能继续执行下一笔交易，这种处理方式执行效率低，而提前哈希计算大大缩短了上层响应时间.

总结以上实验，本文提出的面向区块链的数据管理中间件不仅降低了区块链的使用成本，而且很 好地优化了区块链数据管理性能，大大提升了区块链的应用开发效率.

6相关工作

随着区块链在金融、供应链等数据密集型应用中被广泛采用，对存储在区块链中的数据的查询需 求日益增长[5].早期的区块链所支持的数据管理能力有限[6]，通常只在银行金融系统中被大量使用.为 了扩展区块链平台上的数据管理功能，学术界越来越多的专家学者开始对区块链进行深入研究，尝试 将传统数据库和区块链的优点结合起来，设计出一个兼具安全可信性和管理高效性的系统.

区块链技术与数据管理工作融合的一个方向是向现有的分布式数据库中添加区块链的功能.基 于MongoDB构建的BigChainDB[1]是一个典型的具有区块链特点的数据库，但是，其查询方式依赖 于MongoDB原生接口，查询性能也受限于MongoDB. ChainSQL构建了一种基于区块链网络的日志 数据库，丰富了区块链的查询接口，但其仅对外提供直接的函数方法而不是易于使用的接口.除此之 夕卜，还有Blockchain Relational Database161及FalconDB171等，这些区块链数据库虽然一·定程度上提升 了原区块链的数据管理能力，但是其受限于底层存储的有限查詢支持，未充分发挥出区块链的全部 优势.

区块链与数据库相结合的另一条探索路线是直接在区块链系统及其可信赖的执行模型之上建立 数据管理优化技术.相比前者，在区块链的基础上添加传统数据库的优势是提升数据管理性能更直接 的办法，但将区块链系统作为底层数据存储平台也会带来新的问题.其大体可分为两种类型.第一种 类型的方法是采用分层架构.例如，BlockchainDB[3]在区块链的上层添加了数据库层，对内提升区块 链系统性能，对外提供方便易用的查询接口，但是，其仅支持单一的PUT/GET操作.EtherQL[4]在底 层以太坊的上层设计了查询层，将区块链数据拷贝到查询层中，通过查询层提供的API接口实现查 询功能，但是查询层仅支持MongoDB作为外部数据存储，不支持MySQL等关系数据库.第二种类型 的方法则是将数据库核心技术集成到区块链系统中.SEBDB[2]是该类方法的典型代表之一，在区块链 系统中添加支持关系语义的查询处理引擎，将交易数据组织成关系表的形式，并在区块数据内部添加 了索引结构来加快查询速度，但SEBDB[2]所支持的查询功能有限，对其二次开发难度大.

关于区块链数据管理方面的研究工作涉及很广泛，文献[8-11]是关于区块链在可信环境下的数据 管理问题.除了数据管理的工作，区块链系统在性能[12-15]、安全[16-18]和存储[19-21]方面都取得了一定的发展.

7结束语

本文针对区块链系统无法支持复杂查询、对外提供查询接口单一以及延迟高的问题，提出了面向 区块链的通用高效数据管理中间件.首先，本文采用自定义构建数据模型的方式处理交易数据并对外 提供灵活的数据访问接口;其次，本文实现了同步缓存机制提升查询效率;最后，本文设计异步批量处 理策略和提前哈希计算方法优化吞吐和延迟.

本文还实现了以开源区块链系统CITA为底层的通用高效数据管理架构SQL-CITA.实验结果表 明，本文的方法高效可行.但是在采用账户模型的区块链中，除记录日志的交易数据外还有状态数据. 因此，我们下一步工作重点是基于状态数据优化区块链数据管理性能，并将继续深入探究数据管理与 区块链的融合，如统计计数、访问控制等技术的通用化设计开发，我们也将进一步探讨查询优化与多 重加密策略.

[参考文献]

[1]MCCONAGHY T，MARQUES R，MULLER A，et al. Bigchaindb： A scalable blockchain database [R]. White Paper，BigChainDB， 2016.

[2]ZHU Y，ZHANG Z，JIN C，et al. SEBDB： Semantics empowered blockchain database [C]//35th IEEE International Conference on Data Engineering. 2019： 1820-1831.

[3]ELHINDI M， BINNIG C， ARASU A， et al. Blockchaindb - A shared database on blockchains [J]. Proceedings of the VLDB Endowment，2019， 12（1（1）： 1597-1609.

[4] LI Y，ZHENG K，YAN Y，et al. Etherql： A query layer for blockchain system [C]//Database Systems for Advanced Applications 22nd International Conference. 2017： 556-567.

[5] LUU L，CHU D，OLICKEL H，et al. Making smart contracts smarter [C]//Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communi cations Security. 2016： 254-269.

[6] NATHAN S，GOVINDARAJAN C，SARAF A，et al. Blockchain meets database： Design and implementation of a blockchain relational

database [J]. Proceedings of the VLDB Endowment， 2019， 12（1（1）： 1539-1552.

[7] PENG Y， DU M， LI F， et al. Falcondb： Blockchain-based collaborative database [C]//Proceedings of the 2020 ACM SIGMOD International Conference on Management of Data. 2020： 637-652.

[8]邵奇峰，金澈清，张召，等.区块链技术：架构及进展[J].计算机学报，2018， 41（5）： 3-22.

[9]邵奇峰，张召，朱燕超，等.企业级区块链技术综述[J].软件学报，2019， 30（9）： 2571-2592.

[10]钱卫宁，邵奇峰，朱燕超，等.区块链与可信数据管理：问题与方法[J].软件学报，2018， 29（1）： 150-159.

[11]蔡磊，朱燕超，郭庆兴，等.面向区块链的高效物化视图维护和可信查询[J].软件学报，2020， 31（3）： 680-694.

[12]SHARMA A， SCHUHKNECHT F M， AGRAWAL D， et al. Blurring the lines between blockchains and database systems： The case of hyperledger fabric [C]//SIGMOD Conference. 2019： 105-122.

[13]RUAN P， CHEN G， DINH T T A， et al. Finegrained， secure and efficient data provenance on blockchain systems [J] . Proceedings of the VLDB Endowment， 2019， 12（1（1）： 975-988.

[14]WANG J， WANG H. Monoxide： Scale out blockchains with asynchronous consensus zones [C]//USENIX Symposium on Networked Systems Design and Implementation. 2019： 95-112.

[15]DANG H， DINH T T A， LOGHIN D， et al. Towards scaling blockchain systems via sharding [C]//SIGMOD Conference. 2019： 123140.

[16]WANG H， XU C， ZHANG C， et al. Vchain： A blockchain system ensuring query integrity [C]//Proceedings of the 2020 International Conference on Management of Data. 2020： 2693-2696.

[17]AMIRI M J， AGRAWAL D， ABBADI A E. CAPER： A cross-application permissioned blockchain [J]. Proceedings of the VLDB Endowment， 2019， 12（1（1）： 1385-1398.

[18]XU Z， HAN S， CHEN L. Cub， aconsensusunit-based storage scheme for blockchain system [C] //34th IEEE International Conference on Data Engineering. 2018： 173-184.

[19]ZHANG C， XU C， XU J， et al. Gem2-tree： A gas-efficient structure for authenticated range queries in blockchain [C]//35th IEEE International Conference on Data Engineering. 2019： 842-853.

[20]WANG S， DINH T T A， LIN Q， et al. Forkbase： An efficient storage engine for blockchain and forkable applications [J]. Proceedings of the VLDB Endowment， 2018， 11（10）： 1137-1150.

[21]AL-BASSAM M， SONNINO A， BANO S， et al. Chainspace： A sharded smart contracts platform [C] //25th Annual Network and Distributed System Security Symposium： abs/1708.03778. 2018.

（責任编辑：李万会）