News for hackers. Stuff that matters.
Re:MongoDB vs Redis, a different interpretation of what's wr... by moe on Thursday June 04, 2009 @07:19AM (#641221)
My problem with redis is that it is permanently advertised as a "Database". It is not, it is a persistent cache with some nice query functionality. But all your data must fit in RAM. Otherwise bad things™ happen.

Some may consider this a small terminology glitch but for me it's quite a fundamental issue.

Re:MongoDB vs Redis, a different interpretation of what's wr... by antirez on Thursday June 04, 2009 @07:42AM (#641236)
Even without the persistence you can say something is a database. It's not a coincidence that the term "in memory database" exists for example.

Btw everything is used to store data permantly, reliably or not for your specific needs/tastes, is a database.

Also you can use Redis in append mode if you wish, this will sync your data ASAP on disk. For now in order to do this you need to use netcat, but this will be supported with ad-hoc tools in the future. Still this will be the discuoraged way to do things.

And about reliability, it's worth to note that with Redis there is a delay between the memory copy and the persistent copy of the dataset, but this is not about reliability of the whole dataset, all your data that is not about the latest few minutes is stored on disk permanently without any kind of risk.

Also, you appear to claim that if a database for design limits the amount of data it can hold to the amount of free ram, it is a cache. This is not the case IMHO.

Re:MongoDB vs Redis, a different interpretation of what's wr... by moe on Thursday June 04, 2009 @10:30AM (#641428)
Even without the persistence you can say something is a database. It's not a coincidence that the term "in memory database" exists for example.

Then why is redis not advertised as an "in memory database"? It likes to be compared with MongoDB or TokyoTyrant but is clearly not playing in the same league.

Moreover it glosses over this issue in quite a self-righteous fashion almost everywhere. One example of many would be this gem from the "TwitterAlikeExample":

This means you can serve millions of users every day with just a single Linux box, and this one was monkey asses slow!

That's just false advertising if your "millions of users" actually use the service. Just storing the plain account data for 1 million users would push the database into the 1GB realm. Go figure what happens when these users actually begin to leave a footprint.

Btw everything is used to store data permantly, reliably or not for your specific needs/tastes, is a database.

I'm not normally nitpicking about terminology. It just left a bad taste in my mouth in this particular case because the redis homepage doesn't bother to mention this critical difference to most similar offerings. The current blurb is highly deceptive.

Re:MongoDB vs Redis, a different interpretation of what's wr... by eelco on Thursday June 04, 2009 @08:59AM (#641288)
Yes, but consider the Prevalent Hypothesis (http://prevayler.org/wiki/Prevalent%20Hypothesis):

"That all your business data fits in the RAM you can afford"

I believe this is true in many, not say most, cases. If not, don't use an in-memory "database", "persistent cache", "prevalence layer", or whatever you want to call it.

Re:MongoDB vs Redis, a different interpretation of what's wr... by moe on Thursday June 04, 2009 @10:48AM (#641461)
Sorry, but that's the most idiotic hypothesis I've heard in a while. ;-)

Being able to guarantee that all your data will always fit in as much RAM as you can afford is a luxury that almost nobody has. There's still an order of magnitude between common disk and DIMM sizes.

Re:MongoDB vs Redis, a different interpretation of what's wr... by wlievens on Friday June 05, 2009 @05:00AM (#642932)
I think I agree. I'd call something a database only when it's capable of transparently managing a quantity of data significantly larger than your RAM storage.