[StavrosK]

This is the first time I've ever heard any criticism for redis. As far as I know, everyone loves it, it's a great tool for many jobs and it's amazingly written and solid to boot. I think many of the critics are trying to apply it in ways it wasn't meant to be used.

As far as I know, its main purpose is non-critical data that needs to be accessed as quickly as possible in various different ways, and that's where redis shines.

[tptacek]

I don't pay super close attention to this stuff, but it's very obvious to me that not everyone likes Redis; in particular, the kinds of people who have problems with Mongodb tend also to have the same problems with Redis; long-term operational reliability is a big question mark with it.

For my part: on only a few occasions (mostly fuzzer farm stuff) have I ever used Redis and been happy with the decision. I usually regret using it. I always regret using it as an alternative to SQL.

[bsg75]

I would hope this is not the case, because it means the nay-sayers are careless developers, or simply internet-attention-seeking by criticizing instead of contributing.

Mongo has taken a lot of knocks in part because its write ack behavior was (initially) documented in a way that not everyone felt was sufficient, but also because it is marketed as a universal solution for RDBMS woes.

Redis has never been touted as a replacement for a primary data store, but more of a "toolbox" in some cases, or "middleware" in others. To apply the same criticisms to Redis and Mongo implies those users did not research their platform decisions at all.

[StavrosK]

I don't know, I don't think it should be compared (or considered as an alternative to) MongoDB, and certainly never SQL. I use it to store cached keys, session data and similar other data that I can always regenerate. I've also had great success using it as a message queue on multiple projects.

What was your use case, and what was your experience with it?

[meritt]

Agreed. If Redis is an acceptable alternative to MongoDB you're using one of the two very incorrectly.

[lmm]

Use case: I want to store some json values against some string keys. Which would be very incorrect to use for this?

[jjirsa]

How often are you updating the json values? 10/s? 100/s? 1M/s?

How many string keys? Millions? Billions? What happens if you lose an update?

Redis great for lots of rapid reads and moderate write speed for data that fits on a single server or can be manually sharded well (if it's straight k=>v, as you describe, that basically means your json fits in RAM; if you're using larger objects like sets/zsets/etc, it becomes a slightly different discussion), as long as your application can lose a few seconds without killing you (BGSAVE isn't instantaneous, of course).

[StavrosK]

If the data is critical and you must keep them, both. If not, either.

[webtrill]

MongoDB is not significantly better at any particular thing so yes, Redis can be used as an alternative for the things I may use MongoDB for. Keep a close eye on http://www.amisalabs.com

[swah]

Redis people think it could be used instead of SQL for some designs:

http://redis.io/topics/twitter-clone

I want to use it in a small project so I can learn the design patterns associated with key-value stores. I'm sure there are good and bad things about using Redis vs Postgres.

But it has to hold my data, so... does it hold my data or not? I'm talking about single box stuff here, of course.

(Of course, I'll just use it and find out myself).

[StavrosK]

That's supposed to showcase redis' features, not to tell you that you should dump Postgres for redis.

[bsg75]

Which is a mistake a lot of developers make - trying to replace one data store for another wholesale, and then being surprised when problems arise.

[swah]

But why not?

Is all data in a database that important? Maybe alternative databses would generate new webapp patterns, like dynamic languages do.

[mtrimpe]

Anecdotes don't make data but I dislike Mongodb but love Redis.

Mongodb seems like a solution that was optimized for a certain performance sweet spot that, post-SSD and huge RAM, hardly anybody ever really encounters and 99% of the times it's used you would be better off with Postgres.

Redis on the other hand hits a (probably permanent) sweet spot of ultra-high performance one level of abstraction lower than your usual database; which is a use case everyone trying to saturate metal and squeeze out the last bit of performance on a minimal budget has.

[crdoconnor]

As an alternative to SQL it's pretty awful (it's explicitly not ACID, for one).

As an alternative to an in-memory cache or (occasionally) a DB de-normalization, on the other hand, it works amazingly well for me.

I see the persistence is basically just a backup that helps your system get back up to speed quickly after a crash or systems' restart. It's not something that should ever be treated as reliable.

I wonder how many people who use it under this or similar use cases have an issue with it.

[seiji]

What went wrong? What's the Redis K/V model for it being used as a fuzzer farm data thing?

[ghayes]

It would be great to also enumerate other examples where it shines.

I've used it for caching, session and transient objects connected to Rails without issue for the last two years.

Additionally, I've been looking at it recently for a simple database to perform fast matches on sorted data (E.g. get me the lowest number in this set).

[sehugg]

For three years we've been using it as message bus, statistics tracker, and storing medium-term data (expires after 1 month). We've up/downgraded multiple times without issue.

[smtddr]

>>We've up/downgraded multiple times without issue.

Why would you need to downgrade if you didn't have issues? ;) ...kinda joking, kinda honest curiosity.

[sehugg]

Sorry, I meant up/downgraded the server. We stopped upgrading software at Redis 2.6 :)

[nathanhammond]

I've used it as you have for two things: - Storing user session data for high-use web applications. - High score tables.

And one more: - Storing diffs like those used for Google Docs (literally every change) for a real-time communication system.

The last one works by the client not getting a response and continuing to queue up its diff and send it once the server is back up. Manual conflict resolution is likely necessary after a drop in availability, but consistency is easy to figure out with monotonically increasing IDs.