6 ms·
I've been using Redis for 2 months now. It's a real pleasure to use. I especially like the simple protocol. It's possible to write a simple client without any
by henryprecheur 16y ago
I've been using Redis for 2 months now. It's a real pleasure to use.
I especially like the simple protocol. It's possible to write a simple client without any external libraries within days --maybe hours if you're really good ;). Try to do that with SQL or MongoDB (Javascript parser anyone?).
- catch23 16y agoi think mongodb fills a need that isn't covered by redis or sql -- people still need semi-relational data that can scale beyond 100M rows. redis is a nice memcached or scalable data structures replacement. we use it as a simple rabbitmq replacement.
- henryprecheur 16y agoYes. I didn't want to criticize MongoDB or SQL based databases. Just point out that Redis' protocol is small and easy to implement.
- riffraff 16y agowhy did you have the need to replace rabbitmq at all? (I love redis, but I'd expect using something designed specifically for X is better than using something else that also kind of does X)
- moe 16y agoRabbitMQ is a complex beast and was, last time I used it at scale, ridden with problems under load. We had extremely serious issues like spontaneous lockups. We eventually abandoned it when we realized our queueing needs could be modeled in Redis. In a way that we fully control, understand and can debug. And it wasn't even much work! I'd argue this is highly preferable unless your project really needs complex routing of the kind that only AMQP can provide. Most projects don't.
- StavrosK 16y agoI use redis to replace RabbitMQ as well, but it's all abstracted away in Celery. A question: Don't you need polling when you use redis in this way? Does it have some sort of notification functionality, apart from the recently added pubsub?
- JulianMorrison 16y agohttp://code.google.com/p/redis/wiki/BrpoplpushCommand http://code.google.com/p/redis/wiki/BrpoplpushCommand
- moe 16y agoOur queues are implemented using BLPOP which blocks until items arrive, so no polling is needed. The newer pub/sub stuff promises to be very useful, too, but we didn't have a use-case for that, yet. Our app generally needs messages to persist until they are consumed. What I can say however is that none of the concerns we initially had about performance/scalability held any water. We are still running on a single redis instance (plus a slave) on a moderately sized server and it happily processes 100 messages/sec average between 4 producers and a varying number of consumers (20-100). To add insult to injury our monitoring metrics show that this isn't even a worthwhile load for redis. The server is nowhere near breaking a sweat, the CPUs barely drop below 90% idle, there's no disk i/o to speak of, and the memory usage is more than reasonable (plenty headroom for our purposes). Thus "just throw it at redis" has long become a common stopgap meme in this particular project. And so far we didn't have to replace any of these supposed stopgaps with something else.