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

Question

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

我们的要求是：

1. 能够以批处理方式存储数百万个 xml 文件。XML 文件可能高达几兆，大部分在 100KB 范围内。
2. 通过 id 快速随机查找（例如文档 URL）
3. Java 和 Perl 都可以访问
4. 适用于最重要的 Linux 发行版和 Windows

我确实看过几个 NoSQL 平台（例如 CouchDB、Riak和其他），虽然这些系统看起来很棒，但它们似乎有点矫枉过正：

1. 无需聚类
2. 不需要守护程序（“服务”）
3. 无需智能搜索功能

在深入研究了 Riak 之后，我发现了 Bitcask（参见简介），这似乎正是我想要的。简介中描述的基础知识非常有趣。但不幸的是，没有办法通过 java 访问 bitcask repo（或者有吗？）

所以我的问题归结为

• 以下假设是否正确：Bitcask 模型（仅追加写入，内存中密钥管理）是存储/检索数百万个文档的正确方法
• 有没有可通过 Java 获得的 Bitcask 的可行替代方案？（想到 BerkleyDB……）
• （对于 riak 专家）与“裸”Bitcask 相比，Riak 的开销实施/管理/资源是否明智？

Answer 1

我不认为 Bitcask 适合您的用例。看起来 Bitcask 模型是为每个值的大小相对较小的用例设计的。

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

---

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

Answer 2

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

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

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