Introduction to Influxdb and BOLTDB--the underlying nature resembles lmdb,mvcc+b+ tree

Influxdb

Influxdb is the latest time-series database that has been in effect for the last year or two, but has a very high popularity. Influxdb is written with go, 0.9 version of the INFLUXDB for the previous will have a great change, back-end storage leveldb replaced by Boltdb, read and write API is also a great change, will support clustering, continuous Query, support retention policy, read and write performance is also Wah, can be said to be the perfect solution for time series storage, but because it is still very young, there may be many problems, as the 0.9 is now being developed, the release of a drag-and-drop, because there are still some technical barriers are not compromised.

For influxdb I do not want to say anything more, then plan to open a topic, specifically to say this thing, because I see there is almost no detailed article in the country to influxdb.

If you want to persist the data in your Go app, most people will use some databases. The simplest and most convenient choice is the embedded database, there are many embedded databases are written in C, but for go developers, more want to use pure Golang solution.

Bolt is such a pure go language version of the embedded Key/value database, and in the Go application is easy to use as a persistent. Bolts are similar to Lmdb, which is considered the best in modern Kye/value storage. But unlike Leveldb,boltdb, which supports fully serializable acid transactions, it is also more user-friendly than SQLLITE,BOLTDB without query statements.

Boltdb saves the data in a separate memory-mapped file. It does not have Wal, thread compression, and garbage collection; it only handles a file safely.

The difference between LEVELDB and Boltdb

LEVELDB is developed by Google and is also a k/v storage database, and Boltdb is a lot different than that. The biggest difference for a user is that LEVELDB has no business. Inside, there are a lot of differences:Leveldb implements a log-structured merge tree. It stores ordered key/value in different files and separates them by "hierarchy" and periodically merges small files into larger files. This makes it quick to write at random, but slow to read. This also makes Leveldb's performance unpredictable: But when the amount of data is small, it may perform well, but as the amount of data increases, performance will only get worse. And the thread that makes the merge will also have problems on the server. Leveldb is written in C + +, but there are some ways to implement it, such as Syndtr/goleveldb, Leveldb-go.

Boltdb uses a separate memory-mapped file to implement a B + tree that is copied at write time, which allows for faster reads. Moreover, the loading time of the boltdb is very fast, especially when recovering from crash, because it does not need to read the log (in fact it does not) to find the last successful transaction, it only reads the ID from the root node of two B + trees.

According to the official statement, BOLTDB features:

Comparison with other databasespostgres, MySQL, & other relational databases

relational databases structure data into rows and is only accessible through the use of SQL. This approach provides flexibility on how to store and query your data but also incurs overhead in parsing and planning S QL statements. Bolt accesses all data by a byte slice key. This makes Bolt fast-to-read and write data by key, but provides no built-in, for joining values together.

Most relational databases (with the exception of SQLite) is standalone servers that run separately from your application. This gives your systems flexibility-connect multiple application servers to a single database server but also adds Ove Rhead in serializing and transporting data over the network. Bolt runs as a library included in your application so all data access have to go through your application ' s process. T He brings data closer to your application and limits multi-process access to the data.

LevelDB, Rocksdb

LevelDB and its derivatives (ROCKSDB, hyperleveldb) is similar to bolts in that they is libraries bundled into the Applic ation, however, their underlying structure is a log-structured merge-tree (LSM tree). An LSM tree optimizes the random writes by using a write ahead log and multi-tiered, sorted files called Sstables. Bolt uses a b+tree internally and only a single file. Both approaches has trade-offs.

If you require a high random write throughput (>10,000 w/sec) or do need to use spinning disks then LevelDB could Be a good choice. If your application is Read-heavy or does a lot of range scans then Bolt could be a good choice.

One other important consideration are that LevelDB does does have transactions. It supports batch writing of key/values pairs and it supports read snapshots but it won't give you the ability to do a Compare-and-swap operation safely. Bolt supports fully serializable ACID transactions.

LMDB

Bolt was originally a port of LMDB so it's architecturally similar. Both use a b+tree, having ACID semantics with fully serializable transactions, and support Lock-free MVCC using a single Writer and multiple readers.

The projects has somewhat diverged. LMDB heavily focuses on raw performance while Bolt have focused on simplicity and ease of use. For example, LMDB allows several unsafe actions such as direct writes for the sake of performance. Bolt opts to disallow actions which can leave the database in a corrupted state. The only exception to this on Bolt is DB.NoSync .

There is also a few differences in API. LMDB requires a maximum mmap size when opening an mdb_env whereas Bolt would handle incremental mmap resizing automatically. LMDB overloads the getter and setter functions with multiple flags whereas bolts splits these specialized cases into their Own functions.

Reference:

Http://www.opscoder.info/boltdb_intro.html

Https://github.com/boltdb/bolt

Introduction to Influxdb and BOLTDB--the underlying nature resembles lmdb,mvcc+b+ tree