Bitcask ok适用于简单且高性能的文件存储？
我正在寻找一种存储和检索数百万个xml文件的简单方法。 目前一切都在文件系统中完成，这有一些性能问题。
我们的要求是：
- 能够在批处理过程中存储数百万个xml文件。 XML文件可能高达几兆，大多数在100KB范围内。
- 通过id进行非常快速的随机查找（例如文档URL）
- Java和Perl都可以访问
- 适用于最重要的Linux-Distros和Windows
我确实看过几个NoSQL平台（例如CouchDB， Riak等），虽然这些系统看起来很棒，但它们看起来几乎像过度杀戮：
- 无需群集
- 不需要守护进程（“服务”）
- 不需要聪明的搜索function
深入研究Riak之后，我找到了Bitcask（见介绍 ），这看起来就像我想要的那样。 介绍中描述的基础知识非常有趣。 但不幸的是，没有办法通过java访问bitcask repo（或者在那里？）
所以，我的问题归结为
- 以下假设是正确的：Bitcask模型（仅附加写入，内存中密钥管理）是存储/检索数百万个文档的正确方法
- 通过Java可以获得Bitcask的任何可行替代方案吗？ （BerkleyDB浮现在脑海中……）
- （对于riak专家）与“裸体”Bitcask相比，Riak实施/管理/资源方面的开销是多少？
我不认为Bitcask能够很好地适应你的用例。 看起来Bitcask模型是针对每个值的大小相对较小的用例而设计的。
问题出在Bitcask的数据文件合并过程中。 这涉及将所有实时值从多个“旧数据文件”复制到“合并数据文件”中。 如果你在每个100Kb的区域内有数百万的值，这是一个疯狂的数据复制量。
Bitcask可以适用于这种情况（大值），具体取决于是否有大量的覆盖。 特别是，除非存在大量浪费的空间，否则没有理由合并文件，只有当新值以与旧值相同的密钥到达时才会发生。
Bitcask特别适合这种批量加载情况，因为它会将输入数据流直接写入磁盘。 在大多数情况下，查找将采用一次搜索，但如果存在任何时间局部性，文件缓存将帮助您。
我不确定Java版本/包装器的状态。