Hadoop是否适合用作键值存储?

时间:2014-09-23 22:33:34

标签: hadoop key-value-store

问题

Hadoop是否适合以下用例:

  • 简单的键值存储(主要需要按键GETSET
  • 非常小"行" (32字节键值对)
  • 重删除
  • 重写
  • 按1亿到10亿个键值对的顺序
  • 大多数数据可以包含在SSD(固态驱动器)中,而不是RAM中。

更多信息

我问的原因是因为我不断看到对Hadoop文件系统的引用,以及Hadoop如何被用作许多其他数据库实现的基础,这些实现不一定是为Map-Reduce设计的。

目前,我们将这些数据存储在Redis中。 Redis表现很好,但由于它包含RAM中的所有数据,我们必须使用内存高达128GB的昂贵机器。相反,使用依赖SSD的系统会更好。这样我们就可以自由地构建更大的哈希表。

我们也使用Cassandra存储了这些数据,但是Cassandra倾向于"打破"如果删除变得太重。

2 个答案:

答案 0 :(得分:4)

Hadoop(与流行的媒体观点不同)不是数据库。你描述的是一个数据库。因此Hadoop不适合你。以下帖子也是自以为是的,所以请随意用基准来证明我的错误。

如果您关心" NoSql DB"在Hadoop之上:

  • HBase适用于大量写入,但糟透了大量删除
  • Cassandra同样的故事,但写不像HBase那样快
  • Accumulo可能对非常频繁的更新很有用,但也会删除删除

他们都没有真正的"真实"使用SSD,我认为他们所有人都没有获得巨大的加速。

如果您开始破坏平板电脑(在BigTable演讲中),所有这些都会遭受代价高昂的压缩,因此删除是一个相当明显的限制因素。

您可以采取哪些措施来缓解删除问题,只需使用常量"已删除"价值,解决压缩问题。但是,增加你的桌面也会增加SSD的成本。此外,您还需要进行过滤,这可能会影响读取延迟。

根据您的描述,亚马逊的DynamoDB架构听起来像是这里的最佳候选者。虽然这里的删除费用也很高 - 可能没有上述替代品那么多。

顺便说一句:从上述任何一个数据库的表中删除大量行的推荐方法是完全删除该表。如果你可以将你的设计融入这个范例,那么任何一个都可以。

答案 1 :(得分:1)

虽然这不是你问题的答案,但是与你所说的相关

  

相反,使用依赖SSD的系统会更好。这条路   我们可以自由地构建更大的哈希表。

您可以考虑查看Project Voldemort。 特别是当你说Its the compaction and the tombstones that are a problem时我知道的Cassandra用户。我自己遇到了TombstoneOverwhelmingException几次并且遇到了死胡同。

您可能想要查看此article by Linked In 它说:

  

Memcached全部在内存中,因此您需要将所有数据压缩到内存中   记忆能够为它服务(这可能是一个昂贵的主张   如果生成的数据集很大)。

最后

  

我们所做的只是将整个数据集mmap到进程地址中   空间并访问它。这提供了最低开销缓存   可能,并利用非常有效的查找结构   操作系统。

我不知道这是否适合你的情况。但你可以考虑一次评估Voldemort!祝你好运。