Bitcoin Core LevelDB dbcache 中有什麼？是完整的記錄還是元數據？
Bitcoin Core LevelDB dbcache中有什麼？是完整的記錄還是元數據？
這個問題是匿名在 IRC 上提出的。
Bitcoin Core文件將 dbcache 描述為 UTXO 數據庫的記憶體。
維基百科將記憶體描述為：
儲存數據的軟體組件，以便可以更快地處理未來對該數據的請求；儲存在記憶體中的數據可能是較早計算的結果，也可能是儲存在其他地方的數據的副本。
Greg Maxwell 在 IRC 上補充說：
基本上有兩種不同的用途：本質上是元數據的塊索引和 UTXO 數據庫。
dbcache 並不是真正的記憶體，它是一個寫入緩衝區，它可以防止需要同步磁碟或進行隨機寫入。作為記憶體，它不會做很多事情，也不需要這樣做。它也可以作為記憶體，但是如果你取消了這個好處，即使有一個巨大的 dbcache，它也只會降低大約 10% 的速度。
對於快速 SSD（例如 NVMe），我認為 400MB 記憶體和 5GB 記憶體之間的區別“僅”是 IBD 時間的一半（從 LAN 對等點同步時）。
為了防止損壞，數據庫更新必須涉及同步寫入。
我們更改了 dbcache 刷新的工作方式，其明確意圖是使後台刷新成為可能，以便它可以不斷地同時刷新和處理塊，而不是在磁碟上等待的地方插入這些氣泡。即使一致性要求現在使這成為可能（UTXO 數據庫不必是一致的，除非有一條記錄表明它之前的所有塊都絕對肯定地應用於數據庫），但實際上進行更改仍然非常複雜.
每次處理一個塊時，一旦記憶體填滿，您就可以將最舊的剩餘塊的剩餘臟條目刷新到磁碟，直到它再次回到限制之下。所以基本上在後台刷新每個塊。然後每隔一段時間，您執行一次磁碟同步並更新說明完全一致點所在位置的記錄，而無需刷新任何其他內容。所以在執行時幾乎沒有延遲峰值。
這對挖礦很有好處，但是這樣做需要一堆機器來有效地跟踪事物，並且可能同時用某種開放的雜湊表替換 dbcache 的映射以將 malloc 流量減少 10 倍。我預計這些更改會等待 2 倍的 IBD 加速。我不確定它是否會發生，這是一項非常複雜的任務，任何錯誤都是共識錯誤。
您甚至可以通過替換最舊的 UTXO 並在“足夠遠”刷新後做一些簡潔的事情，例如解決開放雜湊表中的衝突。桌子可以在任何時候都非常接近完全滿。
我個人喜歡布穀鳥桌。每個項目都有少量可能的位置，例如兩個隨機儲存桶，每個儲存桶包含 4 個項目，如果這些位置已滿，您選擇一個，將項目插入那裡，將該插槽中的內容撞到其替代位置之一。
如果桌子有一點鬆弛（例如，2 桶 4 件物品的裝滿不超過 ~ 95%），那麼在踢幾腳之後它總是能成功找到一個空槽。查找速度非常快，因為您只需要進行兩次隨機記憶體訪問。有很多不同的設計，但大多數是最好的，當你可以保持桌子 <50% 滿時，但布穀鳥設計很容易達到任意高的飽腹感。
比特幣使用的 STL 集是一個雜湊表，但是通過將雜湊表中的每個條目都設為鍊錶來解決衝突，因此每次訪問都涉及多個指針追逐，並且每次插入都需要一個 malloc。