引子:
在大数据时代,总希望存在一个Key-value存储机制,像HashMap一样在内存中处理大量(千万数量级)的key-value对,以便提高数据查找、修改速度。
所以,我们会想到,Memcached和Redis这两个NoSQL数据库(严格来讲二者都不可以算作数据库)。
1、Memcached是一个cache机制,当内存不足时会采用LRU机制,替换出陈旧数据,因此他不能保证我们的数据像在HashMap中一样不丢失,且没有数据持久化机制;
2、Redis克服了这一缺点,采取磁盘存储机制实现数据持久化。但是,当数据量达到1千万左右时,由于内存中不能存储如此大量数目的数据,频繁同磁盘进行数据交换,导致数据查询、存储性能的急剧下降,将导致服务不可用。
结论:当前还没有好的产品可以实现key-value保证数据完整性,千万级条数量级的,高效存储和查询支持产品。
附录一:如下是转自其它网友的测试数据:
附录二:memcached 和redis的比较,和各自用途
附录一:
从图中可以猜测到还会有Redis 2.2.1 的测试,相同的测试环境,1K的数据量,使用ServiceStack.Redis客户端进行如下测试:
1) Set操作
2) Get操作
3) Del操作
每一套测试分别使用三个配置进行测试:
1) 绿色线条的是开启Dump方式的持久化,5分钟持久化一次
2) 蓝色线条是开启AOF方式的持久化,每秒写入磁盘一次
3) 红色线条是关闭任何的持久化方式
对于每一个配置都使用相同的其他配置:
1) 开启VM 最大内存10GB(128字节一页)之后开始换出,VM空间160GB
2) 最大使用内存15GB,确保在Dump的时候有足够的剩余内存
3) 开启压缩,没有配置主从
现在来看一下测试结果:
从这个图中可以看出:
1) 对于没有持久化的方式,读写都在数据量达到800万的时候,性能下降几倍,此时正好是达到内存10G,Redis开始换出到磁盘的时候。并且从那以后再也没办法重新振作起来,性能比Mongodb还要差很多。
2) 对于AOF持久化的方式,总体性能并不会比不带持久化方式差太多,都是在到了千万数据量,内存占满之后读的性能只有几百。
3) 对于Dump持久化方式,读写性能波动都比较大,可能在那段时候正在Dump也有关系,并且在达到了1400万数据量之后,读写性能贴底了。在Dump的时候,不会进行换出,而且所有修改的数据还是创建的新页,内存占用比平时高不少,超过了15GB。而且Dump还会压缩,占用了大量的CPU。也就是说,在那个时候内存、磁盘和CPU的压力都接近极限,性能不差才怪。
总结一下:
1) Redis其实只适合作为缓存,而不是数据库或是存储。它的持久化方式适用于救救急啥的,不太适合当作一个普通功能来用。对于这个版本的Redis,不建议使用任何的持久化方式。否则到时候可能会死的比较难看。说白了,期望Redis是memcached的升级版,带有各种数据结构,但是不要期望Redis来和Mongodb/Kt等来比。
2) 对于VM其实也是不建议开启,虽然开启VM可以让Redis保存比内存更多的数据,但是如果冷热数据不是很明显的话性能会非常差(我的测试都是随机查询Key,冷热不明显)。当然,对于冷热明显的情况下可以设置200% - 400%的内存作为VM空间,也不建议设置10倍的内存空间作为VM(像我的配置一样)。
3) ServiceStack.Redis客户端好像有几个Bug,首先RedisTypedClient的Dispose居然没有实现,应该是要调用client.Dispose(),其次RedisNativeClient的Info属性不是每次都获取最新值的,第三PooledRedisClientManager的WritePoolIndex和ReadPoolIndex只看到加没看到减的地方,也不知道这是干啥的,其实每次都取第一个不是Active的Client就可以了,PooledRedisClientManager也没有把超时使用的Active的Client强制回收(避免使用的时候忘记Dispose占用过多的连接)。有关这几点,我会尝试联系ServiceStack.Redis的作者。
附录二:
这两年Redis火得可以,Redis也常常被当作Memcached的挑战者被提到桌面上来。关于Redis与Memcached的比较更是比比皆是。然而,Redis真的在功能、性能以及内存使用效率上都超越了Memcached吗?
下面的内容是来自Redis作者在stackoverflow上的一个回答,对应的问题是《Is memcached a dinosaur in
comparison to Redis?》(相比Redis,Memcached真的过时了吗?)
Redis VS Memcached 转载,布布扣,bubuko.com
原文地址:http://www.cnblogs.com/jimingsong/p/3761066.html