Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What are the operations of Bytom persistent storage LevelDB

2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

Shulou(Shulou.com)06/01 Report--

This article introduces the relevant knowledge of "what are the operations of Bytom persistent storage LevelDB". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

LevelDB introduction

The leveldb database is used by default than the original chain. Leveldb is a very efficient kv database implemented by google. LevelDB is a single-process service with very high performance. On a 4-core Q6600 CPU machine, data is written more than 40w per second, while the performance of random reads is more than 10w per second. Because Leveldb is a single-process service, you cannot have multiple processes reading and writing to a database at the same time. Only one process can read and write at a time, or one process can read and write concurrently. The original chain stores all chain addresses, asset transactions, and other information on the data storage layer.

The operation of adding, deleting, changing and searching LevelDB

LevelDB is a high-performance LevelDB V storage developed by google. In this section, we introduce how to add, delete, modify and query LevelDB.

Package mainimport ("fmt" dbm "github.com/tendermint/tmlibs/db") var (Key = "TESTKEY" LevelDBDir = "/ tmp/data") func main () {db: = dbm.NewDB ("test", "leveldb", LevelDBDir) defer db.Close () db.Set ([] byte (Key), [] byte ("This is a test.")) Value: = db.Get ([] byte (Key)) if value = = nil {return} fmt.Printf ("key:%v, value:%v\ n", Key, string (value)) db.Delete ([] byte (Key))} / / Output// key:TESTKEY, value:This is a test.

The above Output is the output obtained by executing the program.

This procedure has carried on the addition, deletion, modification and search operation to leveld. Dbm.NewDB gets the db object and generates a directory called test.db under the / tmp/data directory. The directory stores all the data in the database. Db.Set sets the value of key. If key does not exist, it will be new, and if key exists, it will be modified. Db.Get gets the value data in key. Db.Delete deletes key and value data.

Than the database of the original chain

By default, the data storage directory is in the data directory under the-- home parameter. Taking the Darwin platform as an example, the default database is stored in $HOME/Library/Bytom/data.

Accesstoken.db token information (wallet access control rights) core.db core database to store data related to the main chain. Including block information, transaction information, asset information and other end-to-end node information in discover.db distributed network

Trusthistory.db txdb.db stores transaction-related information txfeeds.db currently does not use this feature compared to the original chain code version, so we will not introduce the wallet.db local wallet database for the time being. Store information about users, assets, transactions, utox, etc.

All the above databases are managed by the database module

Compared to the original database interface

In the original chain, the data persistence storage is managed by the database module, but the persistence-related interfaces are in protocol/store.go.

Type Store interface {BlockExist (* bc.Hash) bool GetBlock (* bc.Hash) (* types.Block, error) GetStoreStatus () * BlockStoreState GetTransactionStatus (* bc.Hash) (* bc.TransactionStatus, error) GetTransactionsUtxo (* state.UtxoViewpoint, [] * bc.Tx) error GetUtxo (* bc.Hash) (* storage.UtxoEntry, error) LoadBlockIndex () (* state.BlockIndex, error) SaveBlock (* types.Block * bc.TransactionStatus) error SaveChainStatus (* state.BlockNode, * state.UtxoViewpoint) error}

BlockExist judges whether the block exists according to hash.

GetBlock acquires the block according to hash

GetStoreStatus acquires the storage status of store

GetTransactionStatus gets the status of all transactions in the block based on hash

GetTransactionsUtxo caches all utxo associated with the input txs

GetUtxo (* bc.Hash) gets all the utxo in the block according to hash

LoadBlockIndex loads the block index, reads all block header information from db and caches it in memory

SaveBlock storage blocks and transaction status

SaveChainStatus sets the status of the main chain. When the node starts for the first time, the node will determine whether to initialize the main chain based on the content of key as blockStore.

Than the original chain database key prefix

* * database/leveldb/store.go * *

Var (blockStoreKey = [] byte ("blockStore") blockPrefix = [] byte ("B:") blockHeaderPrefix = [] byte ("BH:") txStatusPrefix = [] byte ("BTS:"))

BlockStoreKey main chain status prefix

BlockPrefix block information prefix

BlockHeaderPrefix block information prefix

TxStatusPrefix deal status prefix

Process Analysis of GetBlock query Block

* * database/leveldb/store.go * *

Func (s * Store) GetBlock (hash * bc.Hash) (* types.Block, error) {return s.cache.lookup (hash)}

* * database/leveldb/cache.go * *

Func (c * blockCache) lookup (hash * bc.Hash) (* types.Block, error) {if b, ok: = c.get (hash) Ok {return b, nil} block, err: = c.single.Do (hash.String (), func () (interface {}, error) {b: = c.fillFn (hash) if b = nil {return nil, fmt.Errorf ("There are no block with given hash% s") Hash.String ()} c.add (b) return b, nil}) if err! = nil {return nil, err} return block. (* types.Block), nil}

The GetBlock function eventually executes the lookup function. The total operation of the lookup function is two steps:

Query the hash value from the cache and return if found

The fillFn callback function is called back if it is queried from the cache. The fillFn callback function stores the block information obtained from disk into the cache and returns the block information.

The fillFn callback function actually calls the GetBlock under database/leveldb/store.go, which gets the block information from disk and returns it.

This is the end of the content of "what are the operations of Bytom persistent storage LevelDB". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report