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

Question

问题

Hadoop 是否适合以下用例:

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

更多信息

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

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

我们还使用 Cassandra 存储了这些数据，但如果删除变得过于繁重，Cassandra 往往会“中断”。

Answer 1

Hadoop(与流行的媒体观点不同)不是数据库。你描述的是一个数据库。因此，Hadoop 不适合您。此外，下面的帖子是自以为是的，所以请随时证明我的基准测试是错误的。

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

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

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

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

为了缓解删除问题，您可以做的就是用一个常量“已删除”值覆盖，这可以解决压缩问题。但是，增加您的表格，这在 SSD 上的成本也很高。您还需要过滤，这可能会影响读取延迟。

根据您的描述，Amazon 的 DynamoDB 架构听起来是这里的最佳选择。虽然这里的删除也很昂贵 - 可能不如上述替代方案那么多。

顺便说一句:从上述任何数据库的表中删除大量行的推荐方法是完全删除表。如果您的设计适合这种范式，那么任何一种都可以。