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 DB”：

• HBase 适合大量写入，但不适合大量删除
• Cassandra 同样的故事，但写入速度不如 HBase
• Accumulo 对于非常频繁的更新可能很有用，但也会对删除产生影响

他们都没有“真正”使用SSD，我认为他们都没有获得巨大的加速。

如果您开始对平板电脑进行碎片化（在 BigTable 中），那么所有这些都会遭受代价高昂的压缩，因此删除是一个相当明显的限制因素。

为了缓解删除问题，您可以采取的方法是用常量“已删除”值进行覆盖，从而解决压缩问题。但是，增加表的大小对于 SSD 来说也可能成本高昂。此外，您还需要进行过滤，这可能会影响读取延迟。

根据您的描述，Amazon 的 DynamoDB 架构听起来像是这里的最佳候选者。尽管这里的删除成本也很高——可能没有上面的替代方案那么高。

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