 |
 |
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] >