MongoDB and Redis: a different interpretation of what's wrong with Relational DBs

Wednesday, 03 June 09
Working to Redis is a good feeling for me: it's not something about money, or deadlines, or customers not agreeing with me, but about trying to do my 2 cents in order to help the field to go forward. It's a joy to work to things you love, especially if you have the feeling that you don't want to win: even if a few ideas of your work will be useful for another experiment or implementation it is already worth it. It's like science, what matters is to know more, to find better solutions to problems, and so on.

So I check other work on other key value databases, and suggest this databases to people interested in something different than Redis. For instance this MongoDB slides are good and worth a look. MongoDB seems an interesting project to me, and the interesting thing is how Redis and MongoDB try to solve the same problem in theory but with a very different analysis of it.

Both the projects are about there is something wrong if we use an RDBMS for all the kind of works. Not all the problems look like a nail but too much databases look like an hammer, the slide says, and indeed it's a colorful imagine to communicate. But it is remarkable how, in response to the same non-nail problems, this two tools taken different paths.


Before to continue I want to spend some word about how MongoDB works. The idea is to have objects, that are actually a sum of named fields with values. A Mongo DB object looks like this:
Name: Salvatore
Surname: Sanfilippo
Foo: yes
Bar: no
age: 32
That is, actually, very similar to an RDBMS table. Then you can run interesting queries against your object collections:
db.collection.find.({'Name':'John'}) # Finds all Johns
db.collection.find.({$where:'this.age >= 6 && this.age <= 20'})
You can have indexes in given fields, like in RDBMS, and can sort your queries against some field, order it, get a range using LIMIT, and so on. Basically the data model is the same as an RDBMS, so the MongoDB developers main idea is the following, in my opinion:
What's wrong with RDBMS when used for (many) tasks that don't need all this complexity? They are bloated, thus slow and a pain to replicate, shard, ... But the data model is right, to have tables and index and run complex queries against data.

The Redis path

Redis tries to solve non nail problems too indeed. But in a different way: what Redis provides are data structures much more similar to the data structures you find in a computer science book, liked lists, Sets, and server side operations against this kind of values. Programming with Redis is just like doing everything with Lists and Hashes inside memory with your favorite dynamic programming language, but the dataset is persistent and of course not as fast as accessing directly to your PC's memory (there is a networking layer in the middle).

So what's the Redis point of view?
What's wrong with RDBMS when used for (many) tasks that don't need all this complexity? The data model: non scalable, time complexity hard to predict, and can't model many common problems well enough.
I expect that in a few years what was the real problem with RDBMS is going to be very clear, even if now it can look confusing enough and there are different alternatives and it is very hard to meter the relative value of the different solutions proposed. This kind of changes appear to be very fast, with all the key-value hype growing every week, but actually it's going to take much more time before to start considering RDBMS alternatives as conceptually mature as we look at RDBMS today.
Posted at 16:26:15 | permalink | 8 comments | print
Do you like this article?
Subscribe to the RSS feed of this blog or use the newsletter service in order to receive a notification every time there is something of new to read here.

Note: you'll not see this box again if you are a usual reader.


Brian Ketelsen writes:
03 Jun 09, 17:28:56
Well thought out discourse on relational and non-relational data stores, it's pleasant to see such a post free of the typical "Mine is better than yours" ego that is so rampant in the technical community today.
dm writes:
03 Jun 09, 17:30:33
exactly - what we need is the right tool for a particular job. Sometimes that is RDBMS. But doesn't have to be for 100% of problems. We don't use one programming language for everything.
Leandro writes:
04 Jun 09, 09:00:53
So much misunderstanding... first, ðe problems you aßume are not problems of relational databases, but of SQL implementations; second, many of ðem would probably be solved by relational implementations such as Alphora Dataphor.

Þird, ðese problems aren t to be solved by object orientation, which has even worse problems ðan even SQL.

One must understand whatever one wants to criticise.
jimmybot writes:
19 Feb 10, 15:23:22
My understanding of redis is that there is no built-in easy index for <i>values</i>. No index means slow queries/searches. I think that is a very big difference as well, though not something that can't be changed.
antirez writes:
19 Feb 10, 15:24:45
@jimmybot: search Redis "Sorted Sets". It's our Index.
jimmybot writes:
19 Feb 10, 15:29:40
Well, I mean you can just store the value as a key and the key as a value, but I think it's one more thing to think about and possibly get wrong.
antirez writes:
19 Feb 10, 15:31:42
@jimmybot: ah ok, got it, indeed it is true. In Redis you have to build all your "views" by hand. But this also means you don't have surprises. Most SQL troubles come from the fact you ask queries that are processed inside a black box. With Redis you have to handle more carefully your model, but you end up with something really predictable.
jimmybot writes:
19 Feb 10, 15:50:35
Wow you are fast. Thanks. I think you are right that SQL can be unpredictable, though *if* there was some kind of index on value functionality, it could be implemented in a way with predictable performance. At any rate, Redis looks to be shaping up very interestingly. Props on a great project.
comments closed