nagle at animats.com
Fri Mar 5 07:35:45 CET 2010
Xah Lee wrote:
> recently i wrote a blog article on The NoSQL Movement
> at http://xahlee.org/comp/nosql.html
> i'd like to post it somewhere public to solicit opinions, but in the
> 20 min or so, i couldn't find a proper newsgroup, nor private list
> that my somewhat anti-NoSQL Movement article is fitting.
Too much rant, not enough information.
There is an argument against using full relational databases for
some large-scale applications, ones where the database is spread over
many machines. If the database can be organized so that each transaction
only needs to talk to one database machine, the locking problems become
much simpler. That's what BigTable is really about.
For many web applications, each user has more or less their own data,
and most database activity is related to a single user. Such
applications can easily be scaled up with a system that doesn't
have inter-user links. There can still be inter-user references,
but without a consistency guarantee. They may lead to dead data,
like Unix/Linux symbolic links. This is a mechanism adequate
for most "social networking" sites.
There are also some "consistent-eventually" systems, where a query
can see old data. For non-critical applications, those can be
very useful. This isn't a SQL/NoSQL thing; MySQL asynchronous
replication is a "consistent-eventually" system. Wikipedia uses
that for the "special" pages which require database lookups.
If you allow general joins across any tables, you have to have all
the very elaborate interlocking mechanisms of a distributed database.
The serious database systems (MySQL Cluster and Oracle, for example)
do offer that, but there are usually
substantial complexity penalties, and the databases have to be carefully
organized to avoid excessive cross-machine locking. If you don't need
general joins, a system which doesn't support them is far simpler.
More information about the Python-list