2014-09-23 44 views
3

问题

无法找到容忍写入和删除的Key-Value存储。容忍写入和删除的键值存储

详情

需要一个很好的键值存储来存储非常大的哈希表。这些散列表被用作索引并且非常“活跃”。非常多的删除和写入都是针对它们执行的。

目前,我们正在将这些哈希表存储在大型(128GB RAM)Redis服务器中。 Redis的表现很棒。但考虑到Redis将所有内容存储在RAM中,这并不令人意外。我们尝试过的其他数据库(如Cassandra和MongoDB)在写入时尤其是删除变得过于沉重时会遭受巨大的性能提升。

我们推测应该有一个使用SSD(固态硬盘)的数据库,而不是依赖RAM来包含整个数据。

这是我们的准则:

  • 重写的宽容和删除
  • 执行以及使用SSD而不是含在RAM(如Redis的)一切
  • 并不需要很多的“搜索功能“,如创建有序索引。真的只需要按键GETSET

一直在四处搜寻,但我遇到的大多数信息似乎主要集中在功能(可分群,map-reduce等...)。有一些关于性能的参考信息,例如“低延迟”,我期望从关键值存储中获得。通过使用诸如“删除宽容键值存储”等术语进行搜索,我无法做出多大贡献。

问题

  • 我应该如何去寻找合适的数据库?
  • 我应该搜索哪些“关键”术语? (如“低等待时间”)
  • 是否有适合此用例的数据库类或多或少?
+0

问题,要求我们建议还是找一本书,工具,软件库,教程或其他异地资源是题外话了堆栈溢出他们倾向于吸引自以为是的答案和垃圾邮件。相反,请描述问题以及到目前为止解决问题所做的工作。 – Kermit 2014-09-24 12:04:11

+0

嘿Kermit,这个问题是寻求帮助与搜索正确的数据库的策略。这并不是要求具体的建议。例如,我应该搜索什么关键词?是否有一些数据库可以或多或少地适用于这个用例?我熟悉术语“低延迟”,但我不确定哪些术语适用于容忍删除的数据库。 – 2014-09-24 17:43:29

回答

2

你可能会考虑Chronicle Map

优点

  • 保存在磁盘上。专为繁重的写入速度而设计,如选项Opera Feed等高点市场数据。
  • 对于小条目,典型的延迟约为1微秒。读和写。
  • 比redis快得多。 http://vanillajava.blogspot.co.uk/2014/05/sharedhashmap-vs-redis.html约2个数量级。
  • 支持每秒超过2000万的写入速率,并在SSD存储器的128 GB计算机(我经常测试的东西)上存储500 GB的数据集。
  • 支持128 GB计算机上的5亿个键值的持久性。
  • Apache 2。0 OSS
  • GC免费设计。即可以使用而不会产生任何垃圾。

缺点

  • 只支持Java 7+
  • 测试2.5十亿条目128 GB的计算机上,但有在这一点上表现和上面不一致。例如写入速率从每秒2600万次下降到每秒130万次。

纪事地图没有墓碑或压实。一旦它增长到特定的大小,它不会缩小磁盘使用量,尽管它试图以有效的方式重用删除的条目。

更多链接