6

我正在寻找一种简单的方法来存储和检索数百万个 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 的开销实施/管理/资源是否明智?
4

2 回答 2

6

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

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


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

于 2011-05-15T14:28:56.140 回答
4

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

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

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

于 2011-05-17T06:03:05.473 回答