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

Question

题

Hadoop是否适合以下用例：

• 简单的键值存储（主要需要通过键进行GET和SET ）
• 非常小的“行”（32字节的键值对）
• 大量删除
• 大量写
• 大约1亿到10亿个键值对
• 大多数数据可以包含在SSD（固态驱动器）中，而不是包含在RAM中。

更多信息

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

目前，我们正在将此数据存储在Redis中。 Redis的性能很好，但是由于它的所有数据都包含在RAM中，因此我们必须使用价格超过128GB的昂贵机器。 相反，最好使用依赖SSD的系统。 这样，我们将可以自由地构建更大的哈希表。

我们还使用Cassandra存储了此数据，但是如果删除内容变得过多，Cassandra往往会“中断”。

Answer 1

Hadoop（与流行的媒体意见不同）不是数据库。 您描述的是一个数据库。 因此，Hadoop不是您的理想选择。 另外，下面的帖子是自以为是的，请随时向我证明基准测试有误。

如果您关心Hadoop之上的“ NoSql数据库”：

• HBase适用于繁重的写入操作，但是删除操作比较麻烦
• 卡桑德拉（Cassandra）的故事是一样的，但是写的速度不如HBase
• Accumulo可能对于非常频繁的更新很有用，但也会在删除时产生缺陷

它们都不是“真正”使用SSD的设备，我认为它们并没有获得极大的提速。

如果您开始对平板电脑进行碎片整理（使用BigTable语言），那么所有这些文件都将遭受昂贵的压缩，因此删除是一个相当明显的限制因素。

您可以采取的措施来缓解删除问题，即仅使用恒定的“已删除”值覆盖即可，这可以解决压缩问题。 但是，增加您的桌子，这在SSD上也可能会造成高昂的成本。 另外，您将需要过滤，这可能会影响读取延迟。

根据您的描述，Amazon的DynamoDB架构听起来像是这里的最佳人选。 尽管这里的删除操作也很昂贵-可能不如上述替代方法那么多。

顺便说一句：从上述任何一个数据库的表中删除很多行的推荐方法是完全删除该表。 如果您可以将设计适合此范例，那么任何一个都可以。

Answer 2

虽然这不是您问题的答案，但是在您所说的情况下

相反，最好使用依赖SSD的系统。 这样，我们将可以自由地构建更大的哈希表。

您可以考虑看看Voldemort项目 。 特别是作为Cassandra用户，当您说到Its the compaction and the tombstones that are a problem时，我知道。 我几次遇到TombstoneOverwhelmingException并陷入僵局。

您可能想看看Linked In It的这篇文章，其中说：

Memcached全部存储在内存中，因此您需要将所有数据压缩到内存中才能提供服务（如果生成的数据集很大，这可能是一个昂贵的提议）。

最后

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

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