Vite儲存層設計詳解之indexDB索引系統設計

買賣虛擬貨幣

indexDB主要透過k-v資料庫levelDB來儲存賬本的索引,索引物件包括賬戶(Account)、交易(Transaction/AccountBlock)、快照(SnapshotBlock)、SendBlock/ReceiveBlock對映,在levelDB之外還新增了hot cache、memory cache兩種型別的快取提升讀取效能,系統整體架構如下。

1.讀寫流程

資料寫入時,資料會先寫入memory cache,然後週期性(當snapshot block插入時)地將部分資料從memory cache複製到pending area中,pending area儲存的是待寫入levelDB的資料集合,在下次”非同步批次Flush“時,會將資料從pending area寫入levelDB。
在資料讀取時,資料可能存在於hot cache、memory cache、levelDB中,資料讀取的效率是hot cache > memory cache > levelDB。

2.levelDb索引

levelDB作為一個位元組序的kv儲存結構,簡潔的實現對於固定型別的儲存資料來說非常便於最佳化。透過預定義的key位元組結構,有效的將同一型別的資料進行物理的排序,能夠充分發揮底層硬體效能。
具體實現是透過定義不同的位元組字首將不同的資料型別進行物理的分段,需要的話每個型別的資料還可以在這個基礎上定義自己的子字首,從而實現不同子型別資料結構的有序聚簇儲存。

3.hot cache與memory cache快取

hot cache是一個高速讀快取,經常讀取到的熱資料會快取於hot cache中,以提高整體的讀效能。memory cache是一個寫暫存區,會暫存最近寫入的資料,因而在memory cache中的部分資料可能還未寫入levelDB,而透過一定的設計,使得無論資料儲存在memory cache還是levelDB中,插入、刪除、讀取、更新、迭代等操作都是一致的,因而對於上層模組而言,寫入memory cache資料即是可讀的。

4.pending area與redo log

pending area暫存準備寫入levelDB的資料。”非同步批次Flush“觸發時,資料會從pending area寫入levelDB,先寫redo log再寫入levelDB,redo log在邏輯上記錄的是資料操作順序,如"put k1 v1; put k2 v2; put k1 v2; delete k3...",多次執行同一個redo log是冪等的。

5.索引維度

透過分析每種型別的資料讀寫場景,並有針性的定義最適合的維度,在資料寫入時多個維度的索引會分別寫入,這樣每個場景的的讀取效率都會因為有了最優的索引而得到保證。

免責聲明:

  1. 本文版權歸原作者所有,僅代表作者本人觀點,不代表鏈報觀點或立場。
  2. 如發現文章、圖片等侵權行爲,侵權責任將由作者本人承擔。
  3. 鏈報僅提供相關項目信息,不構成任何投資建議

推荐阅读

;