我也还增加了较小记录（size 8）的测试，因为它们含有主键时，通常会被用于辅助索引。两个机器分别使用了不同硬盘：HDD（Core i7-950 8核和8MB缓存）和一个SSD（Core i5-3550 4核和8MB缓存），下面是部分基准测试结果，详情可以看这里。 持续写；键大小：16；日志大小：100（HDD，1 GB缓存）
连续读；键大小：16；日志大小：100（HDD，1GB缓存）
随机写；键大小：16；日志大小：100（HDD，1GB缓存）
随机读；键大小：16；日志大小：100（HDD，1GB缓存）
计算所有键的综合（HDD，4MB缓存）
计算末尾是“77”的键（SSD，1GB缓存）
对于随机读，Hamsterdb的性能要好于LevelDB。对于随机写，只要数据量不是太大的时候，Hamsterdb 要快于LevelDB。而从1千万键以上开始，hamsterdb就会遭受BTree数据库的传统问题：大量的非序连续I/O的高磁盘寻道延迟。 话虽这么说，这个测试也很好地证明了Hamsterdb的分析能力。尤其是sum和count运算都可以很好地扩展。连续插入和扫描也是Hamsterdb的亮点，且不管数据量多大，它都可以非常快。 未来的工作 这个基准测试让我们发现了很多问题：通过并行hamsterdb，优化随机读/写。这将成为我工作的主要部分，而且我已经草拟一个设计方法，以及在产品发布前进行重构。 原文链接： Hamsterdb: An Analytical Embedded Key-Value Store（翻译/童阳） |
