This is the 9th day of my participation in the November Gwen Challenge. See details: The Last Gwen Challenge 2021.

Talk about LevelDB, the database used by blockchain projects

This article appears in my column: Blockchain in Detail

This column will describe the blockchain consensus algorithm, ethereum smart contract, super ledger smart contract, EOS smart contract related knowledge, and also introduce several practical projects in detail. If possible, we can also read the source code of Ethereum together. If you are interested, let’s learn block chain technology together

Why use LevelDB

The first is because blockchain writes far more data than queries to the database, and LevelDB has high-performance writes. In addition, compared with Redis, each of the Redis persistent data files is larger, so there are more problems in synchronization.

What is LevelDB

LevelDB is a key-value database engine that is persistent. Like many databases, it is written in C++. It was developed by Google’s Jeff Dean and Sanjay Ghemawat and is open source.

Its key-value pairs can be arbitrary and there is no required byte array. It supports both in-memory and persistent storage. It periodically persists data in memory.

The data in LevelDB is sorted by key, but we can rewrite the sorting function to suit our needs.

It consists of three basic operations: Put(key,value), Get(key), and Delete(key).

Blockchain requires transactions, and this database is transaction-enabled, turning multiple operations into a single atomic operation.

LevelDB’s disadvantages

It is a non-relational database, it cannot perform SQL queries, and it does not provide indexing.

Its multithreading is weak, with only one thread accessing the database at a time.

C/S (client/server) communication model is not supported.

LevelDB storage medium

As we mentioned earlier, LevelDB storage media has memory and hard disk. Memtables and IMmutable memtables are available in memory. The hard disk contains log files, manifest files, current files, and sstable files.

Memtable is readable and writable, so when we write a memtable, it stores some data to immutable, which is not writable.

The data in memory is persisted to the hard disk, first to the log file. Manifest then records what key-value pairs the file stores, and Current helps manifest record those key-value pairs.