BadgerDB

Badger is a simple, fast embeddable database written purely in the Go language. It has been developed by Dgraph Labs and is available under the open source licence. It is compatible with BSD, Linux, OS X, Solaris and Windows operating systems. It is designed to be very powerful in writing and reading in the same time. Badger uses Multi-Version Concurrency Control (MVCC) and supports transactions. It triggers transactionally and competitively with the serial guarantee of isolated snapshots.

Badger uses the LSM tree and long valuables to distinguish keys from values. By using this feature, it achieves a lower amplification of both the writing and the size of the LSM tree. This allows the LSM tree to be operated exclusively from the RAM while values go from SSD.

Use

Badger uses following main types:

• DB
• Txn
• item
• Iterator

DB contains keys that are mapped to values. They must be opened using appropriate approaches. All the operations are happening at Txn. Txn represents a transaction that can be only for reading or for both reading and writing. Read-only transactions can read values for a specific key that are in the form of an output in an item or iterate a set of key-value pairs using an iterator which is in the form of an item output. Read and write transactions can update or delete keys from the database.

The advantages of using Badger

• Data download performance. Badger uses the design of separated keys and values, thus achieving a huge improvement of performance for a large number of values. For example, for values of 1 kB and 16 kB, Badger can reach 4.5x and 11.7x higher data flow than RocksDB. However, for smaller values, it may be 2 – 3 times slower.
• The size of the LSM tree. Badger generates a much smaller LSM tree and a larger log of values. Its size is only proportional to the number of keys and not to the number of values. Therefore, the size of the LSM Tree decreases if we rise from 128K to 16KB. This allows the LSM tree to fit to the RAM of the target server.
• The latency of reading. The latecny of Badger is only 18 % versus the 27 % latency of RocksDB. This is due to the fact that the entire Badger’s LSM tree fits to the RAM which significantly reduces the time needed to find the right tables, to check filters and to select the right blocks. On the contrary, RocksDB cannot save the entire LSM tree in the memory which means that it must retrieve whole blocks from the disk, decompress them and then assign values to the keys.

The inconveniences of the use of Badger

• Latency of the iteration. Badger has a much slower range of iteration than RockDB, for example, if values are obtained from SSD.
• Searching for values. The key-value iterations are slower than the optimized disk instance for random reading per second.
• Speed. Badger is slower if the data set contains only smaller values.