
MongoDB vs Redis, a different interpretation of what's wrong with Relational DBs - davidw
http://antirez.com/post/MongoDB-and-Redis.html
======
davidmathers
_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._

I expect that in a few years antirez will study relational theory and conclude
that he's been incrementally, unknowingly, implementing an RDBMS this whole
time.

~~~
antirez
Redis can be the most useless piece of code in the world but it is very hard
looking at the command reference to state that Redia is going to be an rdbms
in my humble opinion

~~~
davidmathers
I'm not 100% sure, but it looks like redis might already have the low level
building blocks of a relational dbms. The relational model is: relations +
relational operators + boolean logic.

A relation is just a special kind of set construction and redis has sets, so
relations can be built. All of logic and operations can be built from either
(not + and) or (not + or). You have SISMEMBER (not), SUNION (and), and SINTER
(or).

That might be enough.

~~~
kragen
You can't get select, project, or cartesian product out of ismember, union,
and intersection. Also, union corresponds to and and intersection corresponds
to or, not the other way around as your comment has it.

~~~
davidmathers
_You can't get select, project, or cartesian product out of ismember, union,
and intersection._

Sorry, I didn't mention that redis has SADD and SREM for implementing
projection. I'm not sure what you mean by select. You're right about product.
I think that's what's missing.

 _Also, union corresponds to and and intersection corresponds to or_

That's exactly what I said. We both got it backwards.

~~~
kragen
Haha! You're right.

"Select" is the SPC-algebra operation which gives you the subset of a relation
whose tuples satisfy some Boolean condition, e.g. firstname='bob'.

------
liuliu
The problem about RDBMS in web world is that it just don't fit the scenario.
When RDBMS was born, it deal with large, relational, but relatively static
data. You can use whatever query to get the organized result. But today's web
world is very different. We have relatively static queries (get top 10
stories, get account XXX most recent posts etc.), but the data are changing
all the time. Consistent query may be a good start to solve the problem.

~~~
zzzeek
this is an insane statement. High transactional capability is _exactly_ what
you'd use RDBMS for. Or are there not that many credit card transactions per
hour ?

------
gisborne
Far too many people are confusing problems with SQL with problems with the
relational model.

SQL != relational database

~~~
antirez
Indeed. But for this to be fully in context add this: 99.99% of relational
databases user base is using SQL databases.

------
bdfh42
In my experience there are two sources of problems with Relational databases.
They are either designed by Programmers or they are designed by DBAs. They
both make a complete and utter mess of the task almost every time.

Programmers design databases to make their programs simpler and DBAs seem to
design databases to make programming near impossible.

The most amazing thing is that Relational databases are simple things to
understand and design - when you understand the data. That is probably where
the trouble lies - neither of my two design groups understand the data - they
both have entirely different agendas.

To get to the point - Relational Databases are fantasticly flexible high
performance tools - it is just that so many examples of poorly designed
databases abound that people get the idea that they are a less than ideal
tool.

~~~
silentbicycle
> DBAs seem to design databases to make programming near impossible.

Have you ever been in a situation where a C buffer overrun caused a data
structure to get scribbled over, and instead of crashing, the program just
started passing around corrupt data? In a long-running application, that
eventually died for a reason that made no sense whatsoever? To the point where
you know that noise got in the system, but you don't know _where or when_ ,
and everything is now suspect?

Imagine that happening to a hospital's medical records. _That's_ a DBA's
nightmare scenario. They're not trying to "make programming near impossible",
they're trying to systematically prevent (potentially incompetent) programmers
from corrupting the data. Databases are good at including internal consistency
checks into the schema design itself.

If a programmer new to your project got mad because they kept making asserts
or unit tests all over the place fail, _and decided to delete them_ , how
would you react?

------
moe
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.

~~~
antirez
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.

~~~
moe
_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.

