实现一个开源KV数据库的想法来源于对目前项目中所使用的K-V数据库使用情况的不满意。
先介绍一下我们的目前项目，作为本文的背景：
较为底层的分布式运行平台，使用C/C++实现的Actor模型（异步消息传递系统）
数据schema简单灵活，使用key-value能够很好表示。
数据库有大量的读写请求，有事务需求，数据丢失容忍度很低。
当前，从众多的KV和NOSQL存储产品中，我们使用了Berkeley DB作为底层的存储引擎。
为什么选择BDB呢？
1.与传统的RDBMS相比，简单K-V存储的Berkeley DB（再加入“嵌入式”直接库链接的特性）有着优越的性能，容易满足我们大量读写（尤其是大量写）的需求。
2.作为一个嵌入式的K-V数据库，Berkeley DB历史悠久（目前由Oracle所有），稳定且久经考验，文档丰富，辅助工具全面。这是我们之所以在众多的开源K-V(Nosql)数据库中选择BDB的首要原因：靠谱。
3.第三个选择BDB的原因是事务支持：作为为数不多的能够提供ACID事务支持的K-V数据库，BDB对事务支持提供了丰富的支持：从不同的隔离级别、不同的持久化保证以及分布式事务2PC的prepare模型等，可配置程度很高。
BDB哪些方面不能达到我们的需求？
1.仍然是性能。作为K-V数据库，BDB的性能依然达不到我们的目标：由于有足够大的内存作为缓存，读操作的性能基本没问题，但写操作（尤其是大量应用的事务写）的性能堪忧。
使用Auto-commit（每条写作为一个独立的事务），一条记录的写延时接近于1~10ms。
显示开启事务后，写操作有了极大改善：10~100us（因为不需要即时sync到硬盘），但事务提交操作依然极为耗时。
有人可能会说，你可以调节BDB事务的持久化保证的程度，比如在提交时设置：
DB_TXN_WRITE_NO_SYNC，在提交时只写log到硬盘，不sync（只有OS Crash才会丢数据）
或者更快一些，使用DB_TXN_NOSYNC，连同步调syscall write的开销都省下来（但App crash可能会丢数据）