Depends on the sort of features required, in particular the access
patterns, and the hardware it's going to run on.

In my experience, NoSQL systems (for example apache's Cassandra) have
extremely good distribution properties over multiple machines, much
better than SQL databases.  Essentially, it's easier to store a bunch
of key/values in a distributed fashion, as you don't need to do joins
across tables (there aren't any) and eventually consistent systems
(such as Cassandra) don't even need to always be internally consistent
between nodes.

If many concurrent write accesses are required, then NoSQL can also be
a good choice, for the same reasons as it's easily distributed.
And for the same reasons, it can be much faster than SQL systems with
the same data given a data model that fits the access patterns.

The flip side is that if later you want to do something that just
requires the equivalent of table joins, it has to be done at the
application level.  This is going to be MUCH MUCH slower and harder
than if there was SQL underneath.


Rob


On Mon, Apr 12, 2010 at 7:55 AM, Thomas Dowling <[log in to unmask]> wrote:
> So let's say (hypothetically, of course) that a colleague tells you he's
> considering a NoSQL database like MongoDB or CouchDB, to store a couple
> tens of millions of "documents", where a document is pretty much an
> article citation, abstract, and the location of full text (not the full
> text itself).  Would your reaction be:
>
> "That's a sensible, forward-looking approach.  Lots of sites are putting
> lots of data into these databases and they'll only get better."
>
> "This guy's on the bleeding edge.  Personally, I'd hold off, but it could
> work."
>
> "Schedule that 2012 re-migration to Oracle or Postgres now."
>
> "Bwahahahah!!!"
>
> Or something else?
>
>
>
> (<http://en.wikipedia.org/wiki/NoSQL> is a good jumping-in point.)
>
>
> --
> Thomas Dowling
> [log in to unmask]
>