 |
 |
The thing is, the NoSQL stuff is pretty much just a key-value store. There's generally no way to "query" the store, instead you can simply look up a document by ID. If this meets the needs of your application, all you need is a key-value store, and not any kind of query, then it's definitely going to be a lot less overhead than an actual SQL rdbms, and simpler to manage, with advantages for scalability and replication etc. The reason it's simpler and more performant, is well, because it's _simpler_, you don't actually have querrying or joining abilities. But if you are actually going to need querrying on values other than ID... SQL rdbms is a pretty standardized, well understood way to do this. There are certainly other ways -- you could combine a "noSQL" key-value store with Solr/Lucene, for instance. Which in some cases may get you even better performance and more flexiblity than an rdbms solution. But it's (IMO) going to be a bit harder to set up and manage and use in your favorite development environment, precisely because rdbms is such a time-tested standardized mature approach. So, as usual, the right tool for the job. If all you really need is a key-value store on ID, then a "NoSQL" solution may be the right thing. But if you need actual querrying and joining, then personally I'd stick with rdbms unless I had some concrete reason to think a more complicated "nosql"+solr solution was required. Certainly if you are planning on using Solr _anyway_ because your application is a search engine of some type, that would lessen the incremental 'cost' of a nosql+solr solution. [ Note that if all you want is a "schemaless" storage, you CAN just stick large chunks of binary or text in an rdbms 'blob' or 'text' column. You won't be able to efficiently search on these -- but you aren't able to efficiently search in a 'nosql' solution either. So you _can_ use an rdbms like a "nosql" solution to store arbitrary data, no problem. If you're using an rdbms, you can have _other_ columns in addition to your blob/text one, that you can populate for select and join. If you _aren't_ going to need those -- then there's be no reason to do it in an rdbms (even though you could), you would indeed then just want to use a 'nosql' key-value store solution which will be higher performance. So the conclusion again I think is that rdbms is _more powerful_ than nosql, but that power comes with a performance cost. If you don't need it, nosql. If you do need it -- there's no reason you can't store "structureless" units of data in text/blob in an rdbms too. ] Peter Schlumpf wrote: > I'd opt for the first response. I hope NoSQL is not flash in the pan. It makes eminent sense to me. SQL is just one way of looking at data. A level of abstraction. What authority says that SQL is the only or the best way of looking at a dataset? Or the MARC record format for that matter? They certainly weren't inscribed on stone tablets. These things can become mind prisons. I think it's refreshing that there are those willing to look at databases beyond SQL. > > Peter Schlumpf > www.avantilibrarysystems.com > > > -----Original Message----- > >> From: Thomas Dowling <[log in to unmask]> >> Sent: Apr 12, 2010 10:55 AM >> To: [log in to unmask] >> Subject: [CODE4LIB] NoSQL - is this a real thing or a flash in the pan? >> >> 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] >>