本文探讨了Hyperledger Fabric区块链系统如何借鉴数据库系统的并发控制技术，尤其是事务重新排序和早期中止策略，以提高事务处理效率。通过对Fabric的工作流程分析，发现其与传统分布式数据库系统的相似之处，并揭示了其在事务处理中的局限性。通过引入数据库领域的技术，作者实现了Fabric++，在实验评估中，成功事务的吞吐量提高了12倍，同时降低了平均延迟。研究表明，区块链系统与数据库系统之间的界限正逐渐模糊，有望通过技术融合提升性能。
Blurring the Lines between Blockchains and Database Systems: the Case of Hyperledger Fabric
ABSTRACT(摘要)
在过去的几年里，市场上出现了不计其数的区块链系统，每个区块链系统都声称要以这样或那样的方式彻底改变分布式交易处理的方式。许多区块链特性，例如拜占庭容错，在现代环境中确实是有价值的补充。然而，尽管围绕着技术的炒作，区块链系统必须面对的许多挑战是基本的事务管理问题。这在很大程度上是与已经存在了几十年的传统数据库系统共享的。
对于那些模糊了区块链系统和传统数据库系统之间界限的系统来说，这些相似之处尤其明显。一个很好的例子就是Hyperledger Fabric，这是一个由IBM开发的开源区块链系统。通过实现并行的交互处理，Fabric的工作流是由传统数据库系统中的乐观并发控制机制高度驱动的。这就提出了两个问题:(1)像Fabric这样的系统和一个经典的分布式数据库系统之间究竟存在哪些概念上的相似点和不同之处?(2)是否有可能通过将数据库技术转移到区块链来提高数据库的性能，从而进一步模糊这两种类型系统之间的界限?为了解决这些问题，我们首先从数据库研究的角度探讨Fabric，在数据库研究中我们观察到事务管道中的弱点。然后，我们通过将理解良好的数据库概念转换到Fabric来解决这些问题，即事务重新排序和事务早期中止。我们在Smallbank基准测试和特定工作负载下的实验评估表明，我们的改进版本Fabric++比普通版本显著提高了成功事务的吞吐量12倍，同时将平均延迟降低了近一半。
CCS CONCEPTS（ccs 的概念）
信息系统→分布式数据库操作;
ACM参考格式:
Ankur Sharma, Felix Martin Schuhknecht, Divya Agrawal和JensDittrich。2019. 区块链和数据库系统之间的界限变得模糊:超级账本结构的例子。2019年数据管理国际会议(SIGMOD ' 19)， 2019年6月30日至7月5日，荷兰阿姆斯特丹。ACM，荷兰阿姆斯特丹，18页。https://doi.org/10.1145/3299869.3319883
1 介绍
区块链是现代分布式事务处理中最热门的话题之一。然而，从数据库研究的角度来看，人们可能会提出这样一个问题:是什么使这些系统比已经存在了很长时间的传统分布式数据库如此特别?
答案在于拜占庭式容错:虽然分类分布式数据库系统需要一组可信的参与者，但区块链系统能够处理一定数量的恶意行为节点。这个特性使许多新的应用程序领域，比如组织之间的事务，不完全信任彼此。
在拜占庭式容错方面，区块链系统比分布式数据库系统有明显的优势。不幸的是，就事务处理的其他本质方面而言，经典的数据库系统要比区块链系统领先几十年。
这方面的一个很好的例子是订单-执行交易处理模型，像比特币[1]和Ethereum[2]这样的杰出系统实现了这个模型:在订单阶段，所有的同行首先同意一个全局交易订单，通常使用一个共识机制。然后，每个对等点在状态副本上按该顺序本地执行事务。虽然这种方法很简单，但它有两个严重的缺点:首先，事务的执行是按顺序进行的。其次，由于每个事务都必须在每个对等点上执行，所以系统的性能不会随对等点的数量而变化。当然，并行执行和可伸缩性都是分布式数据库系统多年来已经确立的特性。
1.1 Catching up （赶上）
不过，仍有一些区块链系统试图迎头赶上。一个突出的例子是Hyperledger Fabric [10]， IBM推出的一个流行的开源区块链系统。它没有实现订单-执行模型，而是遵循复杂的 模拟-订单-验证-提交 模型。该模型受到数据库系统中乐观并发控制机制的高度影响:在对事务进行实际排序之前，会对其进行并行模拟。然后，在订购之后，Fabric在验证阶段检查订单是否与之前计算的模拟效果不冲突。最后，提交非冲突事务的影响。这种模式的优势是显而易见的:并行交易执行以及因此而产生的大规模交易能力——这些特性对于任何即将到来的区块链系统来说都是强制性的，以高性能为目标。我们坚信Fabric将技术从数据库世界转向区块链的雄心是朝着正确方向迈出的一步。然而，其并行事务处理的实现仍存在一些问题，极大地限制了并发所能获得的收益。这些问题可以通过两个简单的实验很容易地识别出来。
最上面的是（有意义的交易）红色的代表的是流产的内容，下面的内容代表（空白的交易）
图1:在配置BS=1024、RW=8、HR=40%、HW=10%、HSS=1%的情况下，如第6节所述触发有意义的事务时，普通Fabric的每秒事务数。此外，我们还显示了启动空白事务时的吞吐量
在第一个实验中(图1，顶部的条)，我们提交了一组有意义的事务，它们来自于一个资产转移场景，并报告吞吐量，分为失败的和成功的事务。这个实验揭示了织物的一个严重问题:大量的操作最终被中止。所有这些中止的原因都是序列化冲突，这是并发执行的一个负面副作用。如果我们希望增加成功事务的数量，我们基本上有两种选择:要么(a)增加系统的总体吞吐量，要么(b)将被Fabric中止的事务转换为成功的事务。不幸的是，选项(a)几乎不适用于织物。我们可以在第二个实验中看到这一点(图1，底部栏)，其中我们提交没有任何逻辑的空白事务。实际上，空白事务和有意义事务的总吞吐量本质上是相等的。这表明，系统的总体吞吐量不是由事务处理的核心组件所控制的，而是由其他辅助因素所控制的:加密计算和网络开销。
1.2 Fabric++
因此，选项(b)是关键:我们必须将被Fabric中止的事务转换为成功的事务。我们通过将一个众所周知的技术从数据库系统转换到Fabric来实现这一点:事务重新排序。我们检查事务语义并以一种大大减少序列化冲突数量的方式安排事务，而不是任意地对事务排序。此外，我们尽可能早地从管道中删除那些不再有机会提交的事务。事务的这种早期中止进一步改善了这种情况，因为没有机会提交的事务不考虑重新排序。
总的来说，我们采取了以下步骤来进一步“数据库化”fabric:
(1)为了为讨论提供基础，我们首先从一个总体的角度考察了Hyperledger Fabric 1.2版本的交易流程。(第二节)。
(2)我们仔细检查并发控制领域的相关工作，并讨论哪些技术与fabric相关，哪些没有考虑。(第3节).这直接将我们引向我们正在集成的技术。
(3)在分析Fabric事务流的基础上，详细讨论了其不足之处，并描述了如何利用数据库技术来解决这些问题。(第四节)。
(4)将数据库技术过渡到Fabric的事务管道。准确地说，我们首先改进交易订单。默认情况下，系统在模拟后任意订购事务，导致不必要的序列化冲突。为了解决这个问题，我们引入了一种高级事务重排序机制，旨在减少一个块内事务之间的序列化冲突数量。这种机制显著地增加了通过系统的有效事务的数量，从而增加了总体吞吐量(5.1节)。
(5)接下来，我们推进事务的中止。默认情况下，Fabric在合并前检查事务是否有效。这种延迟中止不必要地使系统因处理没有机会提交的事务而受到惩罚。为了解决这个问题，我们在管道的各个阶段引入了早期中止的概念。我们尽可能早地识别出无效的操作并中止它们，以确保管道不会被那些最终没有机会提交的事务所限制。这个概念需要一种细粒度并发控制机制，我们也可以通过它扩展Fabric(第5.2节)。这些修改极大地扩展了香草结构，将其变成了我们所说的Fabric++。
(6)我们对Smallbank基准测试和自定义工作负载下的Fabric++的优化进行了广泛的实验评估。我们表明，与普通版本相比，我们能够显著增加成功事务的数量。此外，
最低0.47元/天 解锁文章
扫一扫
2778
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
