Thursday, Jan 6th, 2011 by Tim |
18 Comments
Filed under:
data | Tags:
Mongo,
MongoDB,
redis
Redis作者antirez是一个非常勤奋的开发者，在Redis性能已经非常惊人的情况下持续不断开发新的特性，比如从新的cluster源代码看到，作者已经把Dynamo及Paxos一些核心的思想考虑进去并进行了一些简洁的实现。相比其它产品如Memcached则几年没什么大变化，在Web 2.0时代，Memcached已经非常不够用，技术人员需要考虑做很多额外工作才能让Memcached适应新的变化和需求。
antirez在1月5日Google Groups发表了一篇Redis diskstore文章，对Redis VM方式进行了反省，思考是否有更好的方式来大数据的Redis访问。
a few months after VM started to work my feeling about it started to be not very good… that VM was not the way to go for the future of Redis
适合Web 2.0数据访问最佳的方式就是完全基于内存，比如用Memcached或者Redis snapshot方式。但是更多的业务场景是数据规模会超过RAM容量，因此有几种不同的设计模式。
1. VM方式。将数据分页存放，由应用(如Redis)或者操作系统(如Varnish)将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中。应用实现VM缺点是代码逻辑复杂，如果业务上冷热数据边界并不分明，则换入换出代价太高，系统整体性能低。不少抢鲜的网友在微博上也反馈过使用VM种种不稳定情况。操作系统实现VM的缺点前文Redis几个认识误区已经有介绍。
2. 磁盘方式，所有的数据读写访问都是基于磁盘，由操作系统来只能的缓存访问的数据。由于现代操作系统都非常聪明，会将频繁访问的数据加入到内存中，因此应用并不需要过多特殊逻辑。MongoDB就是这种设计方式。这种方式也有一些已知的缺点，比如操作MMap写入磁盘由操作系统控制，操作系统先写哪里后写哪里应用并不知情，如果写入过程中发生了crash则数据一致性会存在问题。这个也是MongoDB饱受争议的单机Durability问题，
MongoDB is not designed around single-server durability, but rather multi-server durability.
不过MongoDB自己并不觉得这是一个问题，他们的意见是，在目前时代有必要考虑单机完全可靠吗？有必要吗？
3. 硬盘存储 + cache方式。实际原理和mysql+memcache方式类似，只不过将两者功能合二为一到一个底层服务中，简化了调用。
在上面几种方式中，除去VM，antirez觉得MongoDB方式也不太适合，因此选择了disktore方式来实现新的磁盘存储，具体细节是
1) 读操作，使用read through以及LRU方式。内存中不存在的数据从磁盘拉取并放入内存，内存中放不下的数据采用LRU淘汰。
2) 写操作，采用另外spawn一个线程单独处理，写线程通常是异步的，当然也可以把cache-flush-delay配置设成0，Redis尽量保证即时写入。但是在很多场合延迟写会有更好的性能，比如一些计数器用Redis存储，在短时间如果某个计数反复被修改，Redis只需要将最终的结果写入磁盘。这种做法作者叫per key persistence。由于写入会按key合并，因此和snapshot还是有差异，disk store并不能保证时间一致性。
由于写操作是单线程，即使cache-flush-delay设成0，多个client同时写则需要排队等待，如果队列容量超过cache-max-memory Redis设计会进入等待状态，造成调用方卡住。
Google Group上有热心网友迅速完成了压力测试，当内存用完之后，set每秒处理速度从25k下降到10k再到后来几乎卡住。 虽然通过增加cache-flush-delay可以提高相同key重复写入性能；通过增加cache-max-memory可以应对临时峰值写入。但是diskstore写入瓶颈最终还是在IO。
3) rdb 和新 diskstore 格式关系
rdb是传统Redis内存方式的存储格式，diskstore是另外一种格式，那两者关系如何？
- 通过BGSAVE可以随时将diskstore格式另存为rdb格式，而且rdb格式还用于Redis复制以及不同存储方式之间的中间格式。
- 通过工具可以将rdb格式转换成diskstore格式。
当然，diskstore原理很美好，但是目前还处于alpha版本，也只是一个简单demo，diskstore.c加上注释只有300行，实现的方法就是将每个value作为一个独立文件保存，文件名是key的hash值。因此diskstore需要将来有一个更高效稳定的实现才能用于生产环境。但由于有清晰的接口设计，diskstore.c也很容易换成一种B-Tree的实现。很多开发者也在积极探讨使用bdb或者innodb来替换默认diskstore.c的可行性。
在Redis几个认识误区中也介绍过，Redis优势是丰富的内存数据结构，这个特性和数据持久保存天生是矛盾的，如用diskstore保存大list/set(如排行榜)性能会很差，每修改一个list元素则需要将整个大list重新保存，开销比使用传统RDBMS高很多。
用MongoDB的一句设计哲学结尾
Databases are specializing – the “one size fits all” approach no longer applies.
最近用Cassandra的又逐渐多了，除了之前的360案例，在月初的QCon Shanghai 2013 篱笆网也介绍了其使用案例。而这篇百万用户时尚分享网站feed系统扩展实践文章则提到了Fashiolista和Instagram从Redis迁移到Cassandra的案例。考虑到到目前仍然有不少网友在讨论Redis的用法问题，Redis是一个数据库、内存、还是Key value store?以及Redis和memcache在实际场景的抉择问题，因此简单谈下相关区别。