02.28 一文了解Turbo-Geth客戶端最新改進

一文了解Turbo-Geth客戶端最新改進

免責聲明:本文旨在傳遞更多市場信息,不構成任何投資建議。文章僅代表作者觀點,不代表火星財經官方立場。

原文標題:一文了解Turbo-Geth客戶端最新改進

幾個月以前,我加入了 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-Structured Merged-Tree)數據庫,而 Bolt 使用 bucket,而且每一個 bucket 都包含著一個 B+- Tree 結構。我們可以把一個 bucket 當作 “大數據庫裡的一個小數據庫”。

那麼,兩者之間的主要區別在於:LSM 數據庫是為重度添加操作(appending)和範圍掃描操作(range scanning)優化的,而不是為隨機讀取的性能優化的;為了提供一致性,它不允許同時對數據庫執行讀、寫操作。也是出於性能考慮,這種數據庫是沒有實現原子性的。Bolt 則反之,插入操作(inserting)速度較慢,但是隨機讀取速度較快,實現了原子性,而且可以同時對數據庫讀寫。

我們再稍微解釋一下原子性:

  • 原子性:“原子” 意味著不可分割。假設現在我們要給一個數據庫存儲多個哈希值,而其中一個在插入數據庫時失敗了,如果此時所有哈希值的操作都會同時撤銷,這就叫做原子性。Turbo-Geth 就有這樣的特性,只有所有哈希值的插入操作都成功時,這個操作才能成功。而沒有實現原子性的數據庫(比如 LevelDB)則意味著,必須使用一個 workaround 以安全地將數據插入數據庫。換句話來說,在這個點上,我們覺得 Bolt 更好,因為他在給數據庫添加數據時更安全。

數據庫的組織

如前所述,Turbo-Geth 是切分成多個 bucket 的。每個 bucket 都是大數據庫中的一個小數據,各自包含了一個 B+-Tree 結構。

下面便是 Turbo-Geth 數據庫在區塊高度 9,346,492 處的切分:

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

- Turbo-Geth 的 Archive 節點的數據區分(區塊高度為 9,346,492)-

  1. Geth 客戶端的 Archive 大小(區塊高度 9346492): 3.7 TB

  2. Parity 客戶端的 Archive 大小(區塊高度 9346492): 3.6 TB

  3. Turbo-Geth 客戶端的 Archive 大小(區塊高度 9346492): 652.62 GB

每一個部分都存儲在一個 bucket 裡面。其中主要部分的簡要解釋如下:

  • 原象(preimage):哈希值與地址之間的管理,以及存儲位置哈希值與存儲位置之間的關聯

  • 收據(receipt):交易收據

  • 合約存儲內容的歷史(History of Storage):合約存儲內容的變更歷史

  • 賬戶歷史(History of Accounts):賬戶的變更歷史

  • 區塊頭:每個區塊的區塊頭

  • 區塊體:每個區塊的區塊體

  • 合約存儲內容(Contract Storage):就是合約存儲內容

  • ChangeSet:數據庫變更歷史

  • 賬戶:賬戶

使用這麼多 bucket ,是為了讓構成大數據庫的各 B+-Tree 樹高不至於太高,這樣跟數據庫的交互就會比較容易。換句話說,這是在使用多個 bucket 來提高讀取數據庫的性能。

另一種備選方案:Badger DB

在切換到 Bolt 之後,Turbo-Geth 在處理隨機鍵(比如交易哈希值)時遇到了一些問題,因為 Bolt 會在提交數據之前對這些鍵進行排序(sort),又因為這些哈希值都是隨機的,而且數量很多,所以產生了大量的排序需求,然後導致大量的寫入放大現象(write amplification,實際寫入的物理數據量是寫入數據量的多倍)。而 BadgerDB 使用 log-structured-merge(LSM)模式,似乎是一個更好的選擇。這個問題仍在研究當中,不過,我們已經實現了一個 workaround 來解決這個問題。

這裡有一個圖表,顯示了 BadgerDB 和 BoltDB 在整體性能上的對比(感謝 Alexey Akhunov 製圖):

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

結語

Turbo-Geth 客戶端通過下列(數據庫)手段來優化以太坊的性能:

  • 使用多個 bucket,以更迅速地檢索某些數據片

  • 使用 B+-Tree 而非 LSM

如果你想給我們捐贈,可以通過 Gitcoin。


分享到:


相關文章: