最新打算写一个小的通用爬虫，爬行队列的存储是一个比较麻烦的问题，以前用过mysql，但是当数据量大到一定程度，速度就不可以忍受了。由于这种数据没什么关系在里面，自然选用NoSQL会带来更高的性能。当前有很多选择，考虑到爬虫还是比较注重性能的，我就把以性能出众为特色的Redis作为第一个考虑对象。今天总算得到一个可以休息的周末，赶紧研究了一下。其实最后结果还是有些失望的，这里简单说一下试用感受。
既然这么新潮的东西，当然直接上官网看资料，地址是http://redis.io/，比较有意思的是有个在线版本命令行可以玩，地址是http://try.redis-db.com/。后来发现mongodb也有这样的在线命令行，但是ubuntu装软件太方便了，等发现的时候都已经装好了，汗！这里不得不称赞一下Redis，Server端真的很小，真是短小精悍型的。
它非常有特点的就是有多种数据结构，这相比EHCache就灵活多了，当然他们也不是用来干一样的事情，没太多可比性。主要的数据结构有LinkedList、Set、SortedSet、Hash，提供的command也非常方便，比如lpush就是从头插入链表，rpush就是从尾插入链表。我个人感觉就是一个加强版的单机Memcached，直接对数据结构进行操作也能够让自己的应用非常灵活。
但是话说回来，灵活是有代价的，用起来真是够麻烦的，只要有一点关系型操作就折腾死了。就拿官方给的例子来说吧，像mysql一样插入一个的用户注册信息就得这样：
- INCR global:nextUserId => 1000
- SET uid:1000:username antirez
- SET uid:1000:password p1pp0
- SET username:antirez:uid 1000
这个还是一行数据，没涉及到复杂的关联关系。这要是取用户名和密码还要写两个语句，要是参数再多一点不累死人了？要不就把字符串拼接起来，取出来以后切分，我看官方给的例子里面也有这么用的，但是这也太土了吧！？key也完全是为了自己的应用拼出来的，内部使用的时候还得统一规范。难道这个value就不能像EHCache一样存个序列化的对象么，这个想法或许真的可以。另外由于只能对key查询，所以如果需要查询key还要再建一个反过来的映射。最后还要抱怨一句，命令行下面居然没有help，找了半天也没找到类似man的命令，难道以后还要对着手册操作么...
其实说是可以用非关系型的存储方式，但是真实用起来发现还是很多不一样，偶尔还是希望用类sql的方式去查询。我在想如果真的用Redis，那代码维护难度要提升不少，为了这点性能值得么。其实Redis的关注点还是在高性能和数量级不是特别大的情况，特别是需要自己控制数据结构的时候。刚才又试用了一下mangodb，他的类sql方式查询还是很容易上手的，我在想可不可以用他来做爬行队列，如果用熟练了还可以去解决海量存储的问题。
本文转自passover 51CTO博客，原文链接：http://blog.51cto.com/passover/487411，如需转载请自行联系原作者
