SEBDB: Semantics Empowered BlockChain DataBase（ICDE‘2019）

目录 Abstract4.实验

---

Abstract

区块链的缺点
数据语义缺失
查寻表达有限（Hyperledger Fabric ）底层数据可以选用LevelDB和CouchDB
数据集成受阻。直接线上查寻受限于区块链网络简单的存储和表达能力，能实现的 *** 作有限，需要编制复杂的中间件来实现查寻。数据导入到线下的方案存在空间的冗余浪费和数据一致性上的阻碍。

4.实验

所有实验均在一个集群上进行，其中每个节点运行 CentOS 7 *** 作系统，配备两个 16 核 2.10GHz Intel Xeon CPU、96GB RAM、3TB Raid 5 磁盘空间和 1 Gbps 网络吞吐量。 所有代码均使用 C++ 编写，使用 MySQL Community Server 5.7.21 存储链下数据。 我们采用 KAFKA4 1.0.0 和 Tendermint5 0.19.3 作为共识组件。

BChainBench：区块链数据库的迷你基准 由于从系统的角度来看，到目前为止还没有区块链数据库的基准，我们定义了一个新的迷你基准，称为 BChainBench，以适应该场景。 回想一下，BLOCKBENCH 主要关注联盟区块链 [30]。 区块链数据库模式：图 6 介绍了一个由捐赠系统中的 7 个表组成的模式，其中 Donate、Transfer 和 Distribute 是主要的链上表，其余四个是链下表。 Donate、Transfer 和 Distribution 分别记录捐赠、汇款和捐赠分配。 链下表存储相应参与者的私人信息。 由慈善机构维护的表 DonorInfo 存储了捐赠者的详细信息。 由学校维护的表 Donee-Info 存储被授权人的私人数据，例如家庭收入等。由福利维护的表ChildrenInfo存储孤儿的私人数据。 由疗养院维护的 Table Customer 存储老人的私人数据。 这些表用于不同的应用。 由于on-off chain join的处理过程类似，我们以查询donees的详细信息为例来说明on-off chain join的性能。
自己做的数据生成器
数据生成器： 我们实现了一个数据生成器，从两个维度模拟真实场景，包括时间维度和属性中数据分布的维度。 时间维度描述了交易的频率，即交易区块中的物理分布（即元组）。 属性中的数据分布决定了查询结果的大小。 该数据生成器支持事务的均匀分布和高斯分布。
工作负载： 工作负载包括表 II 中列出的七个查询。 Q1 发送类型为 Donate 的事务以测试写入性能。 Q2 和 Q3 测试跟踪查询的性能。 Q2 从一个维度跟踪慈善组织 org1 的所有交易，而 Q3 在一个时间窗口内从两个维度跟踪 org1 的汇款 *** 作。 Q4 和 Q5 测试查询表的性能。 Q4 是关于 Donate 的基本范围查询。Q5 连接链表以显示捐赠的分配方式。 Q6 整合链上和链下数据，展示被授权人的详细信息。 Q7 是区块链的基本 *** 作，它找到一个指定的块。

数据集：我们更改结果大小或区块链大小以进行测试。 为了测试不同区块链大小下的性能，我们固定结果大小并将块数从 500 变化到 2,500。 为了测试不同结果大小下的性能，我们将区块链大小固定为 1000 个块并改变结果大小。 产生的交易要么遵循均匀分布，要么遵循高斯分布（均值等于块的中间，并且

示例：pandas 是基于NumPy 的一种工具，该工具是为了解决数据分析任务而创建的。