我需要存储一个大哈希集，最多可以包含大约 2 亿个 40 位值。将其存储为 2 亿个 64 位值是可以接受的（尽管有 2 亿 * 16 位丢失）。
要求是：
很小的内存占用（磁盘空间不是问题，内存是）
快速contains(long l)和add(long l)方法（比 SQL 快得多）
嵌入式
免费且没有令人讨厌的许可（没有 Berkeley DB）。LGPL 很好。
没有误报也没有误报，所以像基于磁盘的布隆过滤器之类的东西不是我想要的
SQL不是我在这里所追求的。
因为我真的认为我更喜欢这样的快速（注意解决方案比 SQL 解决方案快得多）：
Google 有这样的 Java API 吗？
我只使用“键”的快速基于磁盘的键/值对实现会起作用吗？
或者是其他东西？
我宁愿不重新发明轮毂。
If you can afford 128 GB of disk, you could store one bit per 40 bit value. You could then use a random access file to check a bit is set or to change it. You wouldn't have to insert any values or maintain an index.
尝试 sg-cdb（djb 的 cdb 的奇怪 gizmo 端口），然后将 RandomAccessFile 换成 BufferedRandomAccessFile（在 jai-imageio 代码中有一个很好的）。
我得到了令人兴奋的写入性能。通过屋顶（因为它全部缓冲然后一举提交）。但是，缓冲 RAF 的读取性能没有改变。
我可以花时间与 H2 批量导入进行比较，虽然不确定，但可能具有可比性。
数据库很简单：key => value。仅在键上支持查找。就我而言，密钥是（base32 编码的随机整数 + base32 编码的唯一整数），所以本地化应该不会有太大帮助。这些值是 120 个随机字节的数组。
2011 年 5 月 4 日晚上 11:45:10 测试。TestH2Simple main：插入执行添加时间：101625 毫秒
数据库大小：约 140 MB
批量大小：2000：插入执行添加时间：116875 毫秒
批量大小：10000：insertsperformed 添加时间：70234 ms
使用 RandomAccessFile：插入不刷新：21688 毫秒，刷新：30359 毫秒，总计：52047 毫秒磁盘上的文件大小：66.1 MB（69,315,632 字节）
使用 BufferedRandomAccessFile：大约 6.5 秒
当然，这并不是一个真正公平的比较，因为 H2 在插入期间不断刷新数据，而 sg-cdb 则不是。在进行比较时必须牢记这一点。比较 sg-cdb insert 和 H2 bulk insert 可能是公平的
：搜索：490000 完成时间：1304544550439 耗时：17547 毫秒，计数器：0
：选择在：19579 毫秒内执行
关于内存映射文件：它们似乎不是您要寻找的。MMap 文件的出色性能是当您将大约 100MB 或更多的内存映射到内存中时（我的经验）。
I believe you will need to use a B-tree rather than a hash table. Hash tables do not have good locality for secondary storage, so you will lose too much time to disk I/O.
Most databases -- relational or not -- implement their indexes as a B-tree, so you are talking about the equivalent of storing an index with no other data attached to it.
Will you have multiple processes concurrently updating this data store?