互联网业务，绝大部分场景，会使用缓存服务。

但有时候，确实会使用到进程内存缓存/数据库，这个时候，LevelDB就能派上用场了。
啥是LevelDB？
LevelDB是Google开发的，一个速度非常块的KV存储库(storage library)，它支持字符串的key与字符串的value，并且这种映射关系按key排序(ordered mapping)。
LevelDB有什么特点？
（1）key和value可以是字符串或者字节流；
（2）数据默认按key排列，有序存储；
画外音：调用方可以重载排序方法，以实现自定义排序。
（3）简单易用，基本操作只有3种：
    - Put(key, value)
    - Get(key)
    - Delete(key)
（4）提供原子批量修改接口；
（5）支持数据快照；
（6）支持数据自动压缩；画外音：使用的是snappy压缩算法。
（7）开源，文档很详尽，Google出品很可靠；
LevelDB有什么局限？
（1）LevelDB不是一个SQL数据库，没有关系型的存储模型，不支持SQL语句，不支持索引；
（2）同时只能有一个进程（当然，这个进程可以是多线程的）访问一个特定的数据库；
（3）LevelDB只是一个lib库，没有实现什么client-server网络通讯什么的，当然用户可以自己将lib包装一层，实现自己的server；
LevelDB的性能如何？内存缓存的特点就是快。
Google也进行了一系列测试：测试库共100w行记录，每条记录16字节的key，100字节的value，压缩后的value大概50字节。
写性能
顺序写：平均每次操作耗时1.765微秒，即支持每秒大概55w次顺序写操作；
顺序写+每次都刷盘：平均每次操作耗时268.409微妙，即支持每秒大概3700次的刷盘写操作；
随机写：平均每次操作耗时2.460微秒，即支持每秒大概40w次随机写操作；
更新写：平均每次操作耗时2.380微秒，性能和随机写差不多；

读性能
随机读：平均每次操作耗时16.677微秒，即支持每秒大概6w次随机读操作；
顺序读：平均每次操作耗时0.476微秒，即支持每秒大概210w次顺序读操作；
逆序读：平均每次操作耗时0.724微秒，即支持每秒大概130w次逆序读操作；
上述性能都是在没有打开“压缩”功能下的结果，如果打开“压缩”选项，性能会有所提升。画外音：Google非常诚实的提到，由于100w行的数据量很小，这些数据是能够完全放入内存。
如果仅限于方案调研，上面的内容应该够用了；如果想了解LevelDB内部的细节，未来再撰文吧。

本文转自“架构师之路”公众号，58沈剑提供。