Nosql membase key与redis相比内存使用量大

Nosql membase key与redis相比内存使用量大,nosql,redis,membase,Nosql,Redis,Membase,我最近用membase运行了一个测试,增加了6000万个键,每个键的大小为20-30字节,值小于一个整数的值。该集群跨越3个16 GB机箱,15 GB专用于membase中的单个bucket复制=1。构建版本是64位ubuntu lucid Box上的membase-server-community_x86_64_1.7.1.1 结果: 最初,1000万个密钥驻留在3 GB内存中。3mil密钥/GB @6000万个密钥驻留在45 GB的内存中。1.33密耳钥匙/GB 相比之下,redis每GB可

我最近用membase运行了一个测试,增加了6000万个键,每个键的大小为20-30字节,值小于一个整数的值。该集群跨越3个16 GB机箱,15 GB专用于membase中的单个bucket复制=1。构建版本是64位ubuntu lucid Box上的membase-server-community_x86_64_1.7.1.1

结果:

最初,1000万个密钥驻留在3 GB内存中。3mil密钥/GB @6000万个密钥驻留在45 GB的内存中。1.33密耳钥匙/GB

相比之下,redis每GB可处理900-1000万个密钥,处理6000万个密钥。无论数据集大小如何,每GB密钥的比率都是一致的

问题:

当面对重要的数据集时,Membase似乎无法很好地扩展。在这个用例中,是否有任何调优/配置可以帮助Membase

谢谢


p.S.I从redis迁移到membase,因为后者似乎提供了更高的可靠性来防止缓存故障。但是,这种大数据集性能的下降有点太痛苦了。

奇怪的是,您在哪里发现Redis缺乏可靠性或从故障中恢复的能力。主->从复制、使用仅附加文件进行持久化以及使用事务或管道等方法应该可以降低大多数使用情况下数据丢失的实际风险。如果主复制失败,redis应该重新平衡到其他服务器的复制。理想情况下,集群应该失败,因为它没有足够的资源来处理所有盒子上的负载,而不是因为从盒子和主盒子上都发生了不幸的故障。如果人们想要更多信息,我也在couchbase.org论坛上发布了一个类似的问题:虽然线程上似乎没有太多活动,但不确定支持会有多好。现在我又回到了redis。线性规模成本和非线性规模成本之间有很大的不同。Membase有,Redis没有。如果你正在构建任何大的东西,Redis看起来就像一个玩具,尽管它很闪亮。@yhm似乎Redis是一个构建大东西的好玩具,例如基本上,运行在Redis 300000次查询/秒上的非常大的网站,巨大的数据集。