jdbm

jdbm4也发布部分代码了, 从作者的描述来看, 作者在多线程方面不是很精通, 可能是作者自谦吧. 不知道什么时候可以看到他的jdbm4正式版本.

强烈推荐使用 jdbm3. 虽然还在alpha4, 不过已经很稳定了. 这些天在项目中使用, 达到了极好的性能, 非事务性写入, 在我的电脑上可以达到 每秒 13w条(每条记录 一个long, 二个int). 在写入时, cpu使用为50%. 用两个线程进行写入, 速度反而慢了. 据说在jdbm4会解决这个锁的问题. 让我们一起期待jdbm4.

Announcing JDBM4


jdbm3 github: https://github.com/jankotek/JDBM3
maven引用:

<dependency>
    <groupId>org.apache.jdbm</groupId>
    <artifactId>jdbm</artifactId>
    <version>3.0-alpha4</version>
</dependency>

转自:http://christmaslin.iteye.com/blog/1395651

jdbm的架构比较清晰，分为2层，RecordManager和BTree/HTree。



底层的ReocrdManager封装了IO，事务，提供record的put_record，update_record，get_record，remove_record，commit_record，rollback_record等操作。



BTree和HTree相当于kv的索引层。提供通过key去定位对应的record的功能。



RecordManager也相当于一个kv store，不过它的key固定是一个long值，在put_record是由RecordManager生成。update/get/romve _record都是通过该key去完成。这个key值包含了value在文件中的位置信息，这种处理方

式简化了如何在RecordManager对Record索引的处理。



RecordManager大体上的实现也是把file 划分固定大小的page来管理。事务是通过WAL来实现。在这里不对RecordManage的实现进行分析。





HTree

jdbm提供通过hash的方式索引kv。htree的子结点要么是hashBucket(hb)，要么是hashDirectory(hd).hb是存放element的容器，hd则所存放hb或下一层的hd。hb如果是leaf-node则没有元素数目上限，否则最多存放8个element。hd和hb作为一个record保存在RecordManager里。



htree的最大层数是3(从0开始)，共4层。每个节点最多有2^8=256个子节点。初始化时root是一个hd，指向256个hb，当某个hb的element数目达到上限时，用hd代替hb，把hb的element迁移到hd所指向的hb上。

在定位一个key的位置时，先计算32bit的hash value.因为子节点数是256，所以每8bit用于树的一层定位。写进disk时，每个hd或hb都是一个record，hd只包含所引用的hd或hb的record_id,每次更新的代价比较小。但是对于leaf-node的hb，如果element数目过多，那么每次更新的代价非常大，全部重写整个hb(包括里面的所有的element)。





BTree

BTree通过b+树索引kv。每个节点是BPage，作为1个record保存。当BPage 分裂合并，增删element时重写受影响的Bpage。



总结：

提到的3个dbm，w3c-dbm,sdbm,jdbm都是相对简单的实现，对并发的处理也比较简单(不支持并发或全局锁)。bdb,bdb-je,Kyoto Cabinet,Tokyo Cabinet都是更强大的dbm实现。此外：jdbm还有2个分支，jdbm2和jdbm3，提供更强的功能和性能优化。