LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 区块链资产 > 一文了解Turbo-Geth客户端最新改进

一文了解Turbo-Geth客户端最新改进

2020-02-28 以太坊爱好者 来源:火星财经

编者按:本文来自:以太坊爱好者(ID:ethfans),作者:GiulioRebuffo,翻译:阿剑,Odaily星球日报经授权转载。

几个月以前,我加入了Turbo-Geth团队,开始主动给Trubo-Geth客户端贡献代码。Turbo-Geth客户端是Geth客户端的一个另类版本(当前仍在开发),其目标是做得比原有的客户端运行速度更快、更高效。那么Turbo-Geth实现这个目标的办法包括下面几项:

进一步优化数据库结构

在需要与状态数据交互的场合,减少对数据库的读、写操作

优化状态树操作的效率(有可能需要改变现有状态树的数据结构)

在本文中,我会着重指出Turbo-Geth和Geth在数据库上的不同之处。主要的区别在于:

不同的数据库(使用Bolt,而非LevelDB)

按桶(bucket)来细分数据库

那么,本文的主要内容也就跟这两点相关。

什么是Bolt,它跟LevelDB的区别在哪里?

Bolt和LevelDB其实非常相似,两者都是“键-值对”(key-value)存储,设计目标都是为不需要完整数据库服务器的项目提供简单、快捷且可靠的数据库。Geth选用的数据库是LevelDB,而Turbo-Geth选用的是Bolt。

但两者也有一个关键区别:组织数据的方式。LevelDB是一个LSM(Log-StructuredMerged-Tree)数据库,而Bolt使用bucket,而且每一个bucket都包含着一个B+-Tree结构。我们可以把一个bucket当作“大数据库里的一个小数据库”。

那么,两者之间的主要区别在于:LSM数据库是为重度添加操作(appending)和范围扫描操作(rangescanning)优化的,而不是为随机读取的性能优化的;为了提供一致性,它不允许同时对数据库执行读、写操作。也是出于性能考虑,这种数据库是没有实现原子性的。Bolt则反之,插入操作(inserting)速度较慢,但是随机读取速度较快,实现了原子性,而且可以同时对数据库读写。

我们再稍微解释一下原子性:

原子性:“原子”意味着不可分割。假设现在我们要给一个数据库存储多个哈希值,而其中一个在插入数据库时失败了,如果此时所有哈希值的操作都会同时撤销,这就叫做原子性。Turbo-Geth就有这样的特性,只有所有哈希值的插入操作都成功时,这个操作才能成功。而没有实现原子性的数据库(比如LevelDB)则意味着,必须使用一个workaround以安全地将数据插入数据库。换句话来说,在这个点上,我们觉得Bolt更好,因为他在给数据库添加数据时更安全。

数据库的组织

如前所述,Turbo-Geth是切分成多个bucket的。每个bucket都是大数据库中的一个小数据,各自包含了一个B+-Tree结构。

下面便是Turbo-Geth数据库在区块高度9,346,492处的切分:

-Turbo-Geth的Archive节点的数据区分(区块高度为9,346,492)-

Geth客户端的Archive大小(区块高度9346492):3.7TB

Parity客户端的Archive大小(区块高度9346492):3.6TB

Turbo-Geth客户端的Archive大小(区块高度9346492):652.62GB

每一个部分都存储在一个bucket里面。其中主要部分的简要解释如下:

原象(preimage):哈希值与地址之间的管理,以及存储位置哈希值与存储位置之间的关联

收据(receipt):交易收据

合约存储内容的历史(HistoryofStorage):合约存储内容的变更历史

账户历史(HistoryofAccounts):账户的变更历史

区块头:每个区块的区块头

区块体:每个区块的区块体

合约存储内容(ContractStorage):就是合约存储内容

ChangeSet:数据库变更历史

账户:账户

使用这么多bucket,是为了让构成大数据库的各B+-Tree树高不至于太高,这样跟数据库的交互就会比较容易。换句话说,这是在使用多个bucket来提高读取数据库的性能。

另一种备选方案:BadgerDB

在切换到Bolt之后,Turbo-Geth在处理随机键(比如交易哈希值)时遇到了一些问题,因为Bolt会在提交数据之前对这些键进行排序(sort),又因为这些哈希值都是随机的,而且数量很多,所以产生了大量的排序需求,然后导致大量的写入放大现象(writeamplification,实际写入的物理数据量是写入数据量的多倍)。而BadgerDB使用log-structured-merge(LSM)模式,似乎是一个更好的选择。这个问题仍在研究当中,不过,我们已经实现了一个workaround来解决这个问题。

这里有一个图表,显示了BadgerDB和BoltDB在整体性能上的对比(感谢AlexeyAkhunov制图):

结语

Turbo-Geth客户端通过下列(数据库)手段来优化以太坊的性能:

使用多个bucket,以更迅速地检索某些数据片

使用B+-Tree而非LSM

如果你想给我们捐赠,可以通过Gitcoin。

本文来源:以太坊爱好者
原文标题:一文了解Turbo-Geth客户端最新改进

—-

编译者/作者:以太坊爱好者

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...