虽然这不是对你问题的回答，但与你所说的有关
相反，使用一个依赖于ssd的系统会更好。这样我们就可以自由地构建更大的哈希表。
你可以考虑看看伏地魔计划。特别是作为一个Cassandra用户我知道当你说 Its the compaction and the tombstones that are a problem . 我自己也遇到过 TombstoneOverwhelmingException 好几次，都是死路一条。
你可能想看看这篇文章，其中的链接是：
memcached都在内存中，因此您需要将所有数据压缩到内存中，以便能够为其提供服务（如果生成的数据集很大，这可能是一个昂贵的建议）。
最后呢
我们所做的只是将整个数据集Map到进程地址空间并在那里访问它。这提供了尽可能低的开销缓存，并利用了操作系统中非常有效的查找结构。
我不知道这是否适合你的情况。但是你可以考虑评估伏地魔一次！祝你好运。

hadoop（与流行的媒体观点不同）不是一个数据库。你所描述的是一个数据库。因此，hadoop对您来说不是一个好的候选者。另外，下面的帖子是固执己见，所以请随时证明我的基准错误。
如果您关心hadoop之上的“nosqldb”：
hbase将适合于大量的写操作，但会导致大量的删除
Cassandra也有同样的故事，但写的速度不如hbase
accumulo可能对非常频繁的更新有用，但也会吸收删除
他们都没有“真正”使用固态硬盘，我认为他们并没有得到一个巨大的加速。
如果你开始分割你的平板电脑（在bigtable语言中），那么所有的平板电脑都会遭受昂贵的压缩，因此删除是一个相当明显的限制因素。
您可以做什么来减轻删除问题，就是用一个常量“deleted”值覆盖，这可以解决压缩问题。但是，增加您的表，这可能是昂贵的固态硬盘以及。您还需要进行筛选，这可能会影响读取延迟。
从您所描述的内容来看，amazon的dynamodb体系结构听起来像是这里最好的候选者。虽然这里的删除也很昂贵-也许没有上面的替代品那么多。
顺便说一句：从上述任何数据库的表中删除大量行的建议方法是完全删除表。如果你能将你的设计融入这个范例，任何一个都可以。