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

Question

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

我们的要求是:

1. 能够在批处理过程中存储数百万个xml文件.XML文件可能高达几兆,大多数在100KB范围内.
2. 通过id进行非常快速的随机查找(例如文档URL)
3. Java和Perl都可以访问
4. 可在最重要的Linux-Distros和Windows上使用

我确实看过几个NoSQL平台(例如CouchDB,Riak等),虽然这些系统看起来很棒,但它们看起来几乎像过度杀戮一样:

1. 不需要群集
2. 不需要守护进程("服务")
3. 不需要聪明的搜索功能

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

所以,我的问题归结为

• 以下假设是正确的:Bitcask模型(仅附加写入,内存中密钥管理)是存储/检索数百万个文档的正确方法
• 有没有可用的替代Bitcask可通过Java？(BerkleyDB浮现在脑海中......)
• (对于riak专家)与"裸"Bitcask相比,Riak实施/管理/资源方面的开销是多少？

Answer 1

我不认为Bitcask能够很好地适应你的用例.看起来Bitcask模型是针对每个值的大小相对较小的用例而设计的.

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

Answer 2

Bitcask 可能适合这种情况（较大的值），具体取决于是否存在大量覆盖。特别是，除非存在大量浪费的空间，否则没有理由合并文件，这种情况仅在新值与旧值具有相同键的情况下出现。

Bitcask 特别适合这种批量加载情况，因为它将按顺序将传入数据流直接写入磁盘。在大多数情况下，查找将进行一次查找，但如果存在任何时间局部性，文件缓存将帮助您。

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