influxdb
influxdb是最新的一个时间序列数据库，最新一两年才产生，但已经拥有极高的人气。influxdb 是用Go写的，0.9版本的influxdb对于之前会有很大的改变，后端存储有LevelDB换成了BoltDB，读写的API也是有了很大的变化，也将支持集群化，continuous query，支持retention policy,读写性能也是哇哇的，可以说是时间序列存储的完美方案，但是由于还很年轻，可能还会存在诸多的问题，就像现在正在开发的0.9一样，发布一拖再拖，就是由于还有些技术壁垒没有攻陷。
对于influxdb我不想多说些什么，之后打算开一个专题，专门详细来说一说这个玩意，因为我看国内几乎没有详细的文章来讲influxdb的。
如果你想让你的Go应用中的数据持久化，大多数人会使用一些数据库。最简单最方便的选择是嵌入式数据库，有很多嵌入式数据库都是C写的，然而对于Go开发者来说，更希望使用纯粹的Golang的解决方案。
Bolt就是这么一个纯粹的Go语言版的嵌入式key/value的数据库，而且在Go的应用中很方便地去用作持久化。Bolt类似于LMDB，这个被认为是在现代kye/value存储中最好的。但是又不同于LevelDB，BoltDB支持完全可序列化的ACID事务，也不同于SQLlite，BoltDB没有查询语句，对于用户而言，更加易用。
BoltDB将数据保存在一个单独的内存映射的文件里。它没有wal、线程压缩和垃圾回收；它仅仅安全地处理一个文件。
LevelDB和BoltDB的不同
LevelDB是Google开发的，也是一个k/v的存储数据库，和BoltDB比起起来有很大的不同。对于使用者而言，最大的不同就是LevelDB没有事务。在其内部，也有很多的不同：LevelDB实现了一个日志结构化的merge tree。它将有序的key/value存储在不同文件的之中，并通过“层级”把它们分开，并且周期性地将小的文件merge为更大的文件。这让其在随机写的时候会很快，但是读的时候却很慢。这也让LevelDB的性能不可预知：但数据量很小的时候，它可能性能很好，但是当随着数据量的增加，性能只会越来越糟糕。而且做merge的线程也会在服务器上出现问题。LevelDB是C++写的，但是也有些Go的实现方式，如syndtr/goleveldb、leveldb-go。
BoltDB使用一个单独的内存映射的文件，实现一个写入时拷贝的B+树，这能让读取更快。而且，BoltDB的载入时间很快，特别是在从crash恢复的时候，因为它不需要去通过读log（其实它压根也没有）去找到上次成功的事务，它仅仅从两个B+树的根节点读取ID。
按照官方说法，boltDB特点：
Comparison with other databases
Postgres, MySQL, & other relational databases
Relational databases structure data into rows and are only accessible through the use of SQL. This approach provides flexibility in how you store and query your data but also incurs overhead in parsing and planning SQL 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 support for joining values together.
Most relational databases (with the exception of SQLite) are standalone servers that run separately from your application. This gives your systems flexibility to connect multiple application servers to a single database server but also adds overhead in serializing and transporting data over the network. Bolt runs as a library included in your application so all data access has to go through your application‘s process. This brings data closer to your application but limits multi-process access to the data.
LevelDB, RocksDB
LevelDB and its derivatives (RocksDB, HyperLevelDB) are similar to Bolt in that they are libraries bundled into the application, however, their underlying structure is a log-structured merge-tree (LSM tree). An LSM tree optimizes 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 have trade-offs.
If you require a high random write throughput (>10,000 w/sec) or you 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 is that LevelDB does not have transactions. It supports batch writing of key/values pairs and it supports read snapshots but it will not 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 is architecturally similar. Both use a B+tree, have ACID semantics with fully serializable transactions, and support lock-free MVCC using a single writer and multiple readers.
The two projects have somewhat diverged. LMDB heavily focuses on raw performance while Bolt has 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 in Bolt is DB.NoSync.
There are also a few differences in API. LMDB requires a maximum mmap size when opening an mdb_env whereas Bolt will handle incremental mmap resizing automatically. LMDB overloads the getter and setter functions with multiple flags whereas Bolt splits these specialized cases into their own functions.
参考：
http://www.opscoder.info/boltdb_intro.html
https://github.com/boltdb/bolt