比特卡可以用于简单和高性能的文件存储吗？

Question

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

我们的要求是：

1. 能够在批处理中存储数百万个xml文件。XML文件可能会大一些，大多数在100 in范围内。
2. 按id快速随机查找(例如，文档URL)
3. Java和Perl都可以访问
4. 可以在最重要的Linux发行版和Windows上获得

我确实看过几个NoSQL平台(例如CouchDB、里克和其他平台)，虽然这些系统看上去很棒，但它们看起来几乎像过度杀戮：

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

在深入研究了Riak之后，我找到了Bitcask (参见简介)，这似乎正是我想要的。介绍中描述的基本知识非常有趣。但不幸的是，没有办法通过java访问位桶回购(或者有吗？)

我的问题归结为

• 以下假设是正确的: Bitcask模型(仅追加写入、内存中密钥管理)是存储/检索数百万文档的正确方法。
• 有没有任何可行的替代比特查克可用的Java？(想到BerkleyDB.)
• (对于riak专家来说)与“裸露的”Bitcask相比，Riak的实现/管理/资源方面的开销大吗？

Answer 1

我不认为Bitcask对你的用例会有很好的效果。它看起来像Bitcask模型是为用例设计的--每个值的大小相对较小。

问题在于Bitcask的数据文件合并过程。这包括将所有活动值从多个“旧数据文件”复制到“合并数据文件”中。如果您在100 If的范围内有数百万的值，这是一个疯狂的数据复制量。

注意，上述假设假设XML文档的更新频率相对较高。如果更新很少，并且/或您可以处理大量的空间“浪费”，那么合并可能只需要很少完成，或者根本不需要。

Answer 2

Bitcask可以适用于这种情况(大值)，这取决于是否有大量的覆盖。特别是，除非存在大量浪费空间，否则没有理由合并文件，只有当新值以与旧值相同的键到达时才会发生这种情况。

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

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