区块链VS分布式数据库：区别究竟在哪里？

    来源：RepChain
    导语
    随着区块链技术的逐步发展，区块链与分布式数据库的联系愈加紧密和微妙。2021年发表在SIGMOD会议（ACM Conference on Management of Data）上的这篇论文，从底层设计上对区块链与分布式数据库的分类方法以及两者的混合系统进行了分析。
    研究首先详细介绍了用于描述区块链、分布式数据库以及它们的混合系统的分类方法：从复制、并发、存储和分片四个方面考虑；然后使用许可链Quorum、Fabric以及数据库TiDB、etcd，设计性能实验并细致地分析了实验结果；最后，给出了一个可以用于解释和估计混合系统性能的框架。
    论文题目：Blockchains vs. Distributed Databases: Dichotomy and Fusion
    作者：Pingcheng Ruan, Tien Tuan Anh Dinh, Dumitrel Loghin, Meihui Zhang, Gang Chen,?Qian Lin,?Beng Chin Ooi
    论文链接：Blockchains vs. Distributed Databases | Proceedings of the 2021 International Conference on Management of Data (acm.org)
    ‖ 区块链与分布式数据库的介绍
    从数据结构的角度来看，区块链是一条由哈希指针串联起来的区块链表，每个区块中包含了一系列交易；从系统的角度来看，区块链是一个由多个互不信任的节点共同维护一个全网一致的账本的分布式系统。
    区块链可以分为许可链和非许可链。其中非许可链是完全开放的，每一个人都有资格记帐、读取数据，例如比特币、以太坊。而许可链则有一定的准入机制和权限控制，例如Hyperledger Fabric。尽管早期区块链的底层设计与数据库完全不同，但是智能合约应用到了区块链以后，用户能够自由地部署和运行图灵完备的代码，使得区块链与数据库之间产生了可比性。因此，论文将具有合约能力的区块链与数据库进行对比研究。
    分布式数据库是一种数据存储在不同物理位置的数据库。多年来，传统的关系型数据库一直是主流。由于大数据处理和硬件发展等等的现实原因，为了实现系统的高可用性和可扩展性，分布式系统开始进化，在这个新的设计趋势下，出现了NoSQL和NewSQL。
    NoSQL为了增强系统的可扩展性，抛弃了传统数据库的关系模型以及强ACID语义，NoSQL有着更加灵活的数据存储结构，例如Key-Value（键值）存储、列存储、文档存储等等。NoSQL的一致性较弱，可实现最终一致性、顺序一致性或因果一致性等等。NoSQL 的设计更加灵活，但加大了上层应用的复杂性。
    NewSQL是介于关系数据库与 NoSQL 之间的设计，它保留了关系数据库的数据模型以及对 ACID 语义的支持，同时具有NoSQL对海量数据的存储管理能力以及可扩展性。
    下图显示了分布式数据库与许可链、非许可链在安全与性能上的权衡。
    
    ‖ 分类法
    
    论文提出的分类方法如图所示。下面，从四个方面逐个进行介绍：
    复制是将数据的副本存放在系统中多个节点上的一种技术。
    从复制模型的角度来看，区块链复制了有序的事务（transaction）日志，复制的单位是事务，事务中包含交易上下文、签名、时间戳等应用级别的信息，且便于验证。“事务”一词无论在区块链还是数据库中都表达为对于底层数据执行的逻辑计算，是一个操作序列。在区块链中，事务表现为合约部署、调用这样的形式，可以看作我们通常所称的交易，例如，调用合约时将引起对数据的一个操作序列，这一序列操作具有原子性，要么执行完成，要么不执行，完成以后会使得系统的状态发生改变。
    分布式数据库则复制了读写操作的有序日志，每次复制一个操作。如图所示，需要一个可信的事务管理器进行协调，复制的单位是更细粒度的操作时，系统更便于实现并发。
    
    从复制方式的角度来看，区块链和分布式数据库可以选择不同的方式进行数据复制。论文将复制方式总结为主备份复制和状态机复制，其中状态机复制又分为共识协议和共享日志两种。
    主备份复制是指，副本中确定的某个主副本运行确定性状态机，而备份仅存储状态。主数据库通过处理操作计算一系列新的应用程序状态，并将这些状态按生成顺序转发给每个备份。也就是把主副本的整个状态实时地传输到备用服务器；而状态机复制则是让每个副本都实现一个确定性状态机。本质上是维护每个副本上操作或事务的有序日志。每个复制副本从相同的初始状态开始，然后以相同的顺序应用日志中的操作或事务。
    基于共识协议的复制和基于共享日志的复制区别在于，后者依赖于可信的外部服务提供一个共享日志，从而在每个副本上执行这个日志以改变状态。
    从故障模型来看，区块链和分布式数据库需要解决的故障问题不同，这决定了两者的共识层以及上层应用的不同特点。
    在分布式数据库当中，节点属于值得信任的内部系统，因而只需要容忍节点宕机，数据库通常使用CFT协议（Protocols that tolerate crash failures），例如Paxos、Raft；而在区块链中，各个节点需要在互不信任的情况下达成共识，因此需要容忍节点的恶意行为，因此区块链常常会使用代价更大的BFT协议（Protocols that tolerate Byzantine failures），例如PBFT、PoW等。
    如图是CFT与BFT协议在不同的网络模型当中所需要达到的网络规模，同步网络是延迟有界且已知的网络，而异步网络中的延迟可能是无限的。其中，f是故障节点的数目。
    
    并发指的是让交易或事务在同一时间执行。数据库领域中的并发控制技术一直是研究热点，好的并发优化能够使得数据库系统的性能大大提升。而区块链中的交易常常是串行执行的，并发技术用得不多，主要原因在于，交易执行在很多区块链系统中并非性能瓶颈，其次，由于交易常常会共用合约的状态数据，因而串行执行交易更加简单、保险。
    存储决定了系统中的数据存储的机制。
    在存储模型方面，大部分的数据库只存储最新的可供修改的数据信息，即便有历史信息，也只是作为节点故障恢复的日志；而区块链则存储了所有的历史数据，并且以只增的方式维护。
    在索引方面，区块链为了支持数据的正确性验证，会采用类似Merkle Tree这样的数据结构存储数据；而分布式数据库则更关注性能，在建立索引时根据硬件的性质进行特殊优化，例如，硬盘中的数据以B+树的数据结构存储，而内存中的数据则使用对于多核并行和缓存更加友好的 FAST 或 PSL 等结构进行存储。
    分片在数据库领域也是一种常用的技术，它将数据分布到不同的分片当中，由分片中的节点进行处理，从而达到扩展系统或提升处理性能的目的。
    分片形成协议决定了节点和数据应该分配到哪个分片。数据库中可以根据数据的哈希计算结果、数据的范围等进行分片，而区块链更关注安全性，分片必须足够大，从而避免恶意节点在分片中的数目超过安全假设，此外，分片的分配机制也不应该受到节点行为的影响。
    分片的原子性要求跨分片的事务在它涉及到的所有分片中要么都提交，要么都中止，表现出行为上的一致性。在分布式数据库中，原子性一般由两阶段提交协议（2 Phase Commit，2PC）保证，这需要依赖某个可信的协调者，而区块链中缺少这样的协调者，因此会引入BFT协议来协调跨分片交易。
    最后，根据所述的分类方法，论文还给出了一些系统设计的分析和对比。
    
    ‖性能实验
    性能实验主要选择了两个许可链系统Quorum、Fabric，两个分布式数据库TiDB、etcd。
    Quorum是以太坊的Go语言实现的一个分支，它在以太坊的基础上添加了交易与合约的隐私性、许可管理以及基于Raft的共识机制，它以order-execute形式的架构打包区块；Fabric是一个由 Linux 基金会主办的一个全球协作项目超级账本中的一个子项目，它的架构模型则是execute-order-validate；TiDB是NewSQL数据库，它继承了大部分MySQL的特性，并由三个独立的模块组成：PD用于协调集群管理，TiKV用于KV存储，server解析和调度SQL查询；etcd是NoSQL数据库，它使用kv数据模型，具有宽松的事务限制，侧重于可用性和一致性之间的权衡。
    为了公平比较，实验让所有系统中每个节点都有状态数据的完整副本。对于Fabric，交易由所有peer节点执行和背书，排序节点固定为三个。Quorum和Fabric使用Raft协议。
    实验从五个角度进行分析，分别是峰值性能，以及上述分类法的四个方面，即复制、并发、存储和分片。
    在峰值性能方面，区块链和分布式数据库之间的性能差距相当大。
    这里用100K记录填充每个系统，每条记录大小为1KB。记录仅更新和仅查询的工作负载下的吞吐量和延迟。TiKV作为TiDB底层的分布式数据库模块，也参与了比较。
    
    
    可以看出，NoSQL性能优于NewSQL，这是因为它们不会产生支持ACID事务的开销。此外，TiDB的吞吐量比性能较好的的区块链Fabric仍然高4倍。
    在复制方面，基于事务的复制模型影响了系统的并发能力，这对系统性能的影响是主要的。
    
    图7根据Fabric和TiDB的性能表现，比较了基于事务和基于操作的复制模型的影响。除了与TiDB相比具有更高的延迟之外，当系统饱和时，Fabric的延迟也会显著增加。而当请求速率超过系统容量时，验证阶段就会成为瓶颈。论文认为延迟增加归因于Fabric中的串行验证，区块和区块内的事务在提交以前是顺序验证的。
    
    图8给出了四个系统随节点数目增多而变化的吞吐量。其中Fabric的复制方法是基于共享日志的，其他则是基于共识协议的。Fabric的吞吐量随着节点数目增加而下降，在实验中观察到区块验证的延迟增加了，这是因为背书策略设置为所有peer节点都要对一笔交易进行背书。Quorum使用raft协议，但是性能对节点个数不敏感，这是因为Quorum的order-execute架构，打包区块的过程顺序进行。
    
    图8表示在Quorum中比较了Raft和IBFT共识协议的吞吐量，以分析不同故障模型的性能影响。在规模更大的网络中，IBFT的吞吐量方差更大，这是因为IBFT比起Raft，需要与更多的节点通讯以避免主节点切换，而恶意节点越多，重新选举主节点的概率越大，事务中断的概率就会变大。
    在并发方面，execute-order-validate架构的区块链在高竞争和高约束的工作负载下性能较低。
    
    图9给出了偏度对性能的影响。每个事务修改一项记录，记录的键值服从Zipfian分布，分布根据偏度系数θ变化，θ越大，表示修改冲突的可能性越大，竞争越大。可以看出，当竞争发生时，TiDB的吞吐量剧烈下降；etcd和Quorum串行执行事务，没有并发控制；而Fabric性能下降了31%，这是由于Fabric对读写冲突的乐观并发控制机制导致事务中止。此外，TiDB的吞吐量下降与事务中止率的增加不成比例，原因在于它的锁存机制耗费了更多的时间。
    
    图10增加每个事务中的操作数目以观察事务原子性对性能的影响。从左图可以看出，当每个事务的操作数增加时，Fabric、TiDB和etcd的性能有所下降。说明更多的操作导致了冲突，而且TiDB的事务还可能跨越多个分片；右图显示了TiDB和Fabric的随操作数变化的事务中止率。TiDB的事务中止主要是由于写写冲突，而Fabric中则来源于不一致的读以及读写冲突，而不一致的读可能是因为需要预执行和背书交易的peer节点提交区块的速率不同。
    
    图11显示了记录，即需要处理的数据的大小对于性能的影响，从左图可以看出，随着记录增大，所有系统的性能几乎都降低了。且Quorum的吞吐量显著下降。右图分析了Fabric和Quorum的事务延迟的细节。Quorum在Commit阶段由于重建MPT（Merkle Patricia Trie）数据结构而引入了哈希函数的成本，且Proposal阶段与Commit阶段的延迟同速增长。因为Quorum的order-execute架构使交易在打包区块的节点和共识后的其他节点处都要进行串行验证，相比之下，Fabric的串行处理只有一次。
    在存储方面，区块链中的账本抽象模型会带来很大的存储开销，此外，避免状态数据受到篡改所需的安全开销则很小。
    
    图中显示了记录大小对于存储开销的影响。Fabric的存储开销比TiDB高得多，这是因为Fabric中的区块链的账本链条抽象模型。右图比较了Fabric中的MBT（Merkle Bucket Trie）和Quorum的MPT，MBT的开销更小，因为它的树结构规模是固定的。
    在分片方面，由于分片的形成和周期性重新配置的安全要求，分片区块链的性能远远落后于分布式数据库。
    
    这里使用了TiDB，AHL，以及Spanner。AHL是基于Fabric的分片区块链，Spanner则是基于云的NewSQL数据库。如图14所示，当节点数目增加时，TiDB的吞吐量比Spanner更高，这是因为一旦检测到冲突，TiDB会立即中止事务，而Spanner使用了悲观并发控制机制，在事务冲突的情况下将争夺锁；与分片固定的AHL相比，定期重新配置分片的AHL为了实现更高的安全性，在性能上降低了30%。然而由于PBFT协议的高成本和其他安全开销，AHL和数据库之间的性能差距仍然很大。
    ‖ 分析框架
    根据上述的研究分析，论文在最后提出了一个可以用于分析和预测混合系统的框架，不过，仅以吞吐量作为评价指标。
    
    可以看到，复制模型和故障模型很大程度地影响了系统性能。基于事务的复制不像基于操作的复制那样有较好的并发性，因此吞吐量低。而比起BFT协议，CFT协议的网络开销更低。
    ‖ 总结
    这篇论文系统地探讨和总结了区块链和分布式数据库之间在设计上的差异，给出了由复制、并发、存储和分片四个维度构成的分类方法，利用这种方法，给出了现有一些系统的设计取向的分析，并进行了对应的性能测试，用实验结果说明了底层设计选择对性能的影响，最后，还提供了一个用于评价和估计系统吞吐量的框架。整篇文章的工作完整详实，有利于理解区块链和数据库之间的设计联系和区别，从更细致和有条理的角度认识目前的区块链与数据库相融合的研究工作。