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

Question

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

我们的要求是：

1. 能够以批处理方式存储数百万个 xml 文件。 XML 文件可能高达几兆，大部分在 100KB 范围内。
2. 通过 id 快速随机查找（例如文档 URL）
3. Java 和 Perl 均可访问
4. 在最重要的 Linux 发行版和 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 左右，那么这就是疯狂的数据复制量。

---

请注意，以上假设 XML 文档更新相对频繁。如果更新很少，并且/或者您可以处理大量空间“浪费”，则可能只需要很少或根本不需要进行合并。

Answer 2

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

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

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