Bitcask ok适用于简单且高性能的文件存储？

Question

我正在寻找一种存储和检索数百万个xml文件的简单方法。目前一切都在文件系统中完成，这有一些性能问题。

我们的要求是：

1. 能够在批处理过程中存储数百万个xml文件。 XML文件可能高达几兆，大多数在100KB范围内。
2. 按ID快速随机查找（例如文档网址）
3. Java和Perl都可以访问
4. 适用于最重要的Linux-Distros和Windows

我确实看过几个NoSQL平台（例如CouchDB，Riak和其他），虽然这些系统看起来很棒，但它们看起来几乎像过度杀伤一样：

1. 无需群集
2. 不需要守护进程（“服务”）
3. 不需要聪明的搜索功能

深入研究Riak之后，我找到了Bitcask（见intro），这看起来就像我想要的那样。介绍中描述的基础知识非常有趣。但不幸的是，没有办法通过java访问bitcask repo（或者在那里？）

所以我的问题归结为

• 是以下假设权利：Bitcask模型（仅附加写入，内存中密钥管理）是存储/检索数百万个文档的正确方法
• 有没有可通过Java提供的Bitcask替代方案？ （BerkleyDB浮现在脑海中......）
• （对于riak专家）与“裸”Bitcask相比，Riak是否有很多开销实施/管理/资源明智？

Answer 1

我认为Bitcask不会对你的用例有用。看起来Bitcask模型是针对每个值的大小相对较小的用例而设计的。

问题出在Bitcask的数据文件合并过程中。这涉及将所有实时值从多个“旧数据文件”复制到“合并数据文件”中。如果你在每个100Kb的区域内有数百万的值，那么这是一个疯狂的数据复制量。

Answer 2

Bitcask可能适用于这种情况（大值），具体取决于是否存在大量覆盖。特别是，除非存在大量浪费的空间，否则没有理由合并文件，只有当新值以与旧值相同的密钥到达时才会出现。

Bitcask特别适合这种批量加载情况，因为它会将输入数据流直接写入磁盘。在大多数情况下，查找将采用一次搜索，但如果存在任何时间局部性，文件缓存将对您有所帮助。

我不确定Java版本/包装器的状态。