NoSQL: If only it was that easy

I'll be honest (and chances are I'll get a great explanation as to why I'm wrong), I don't understand the whole YeSQL-NoSQL argument.<p>Relational databases, such as MySQL and PostgreSQL, are great for some things -- especially when you need to (put simply) divide and recombine various pieces of information easily. JOINs. UNIONs, etc. are fantastic when you need them, and it's where relational databases excel.<p>On the other side of the equation are hash and "document" databases, which are mostly key-value stores with some unique functionality (e.g. the indexing feature of Tokyo Cabinet Tables). These are great when you need to store a large volume of data, but don't need to frequently recombine the stored data in many different ways. You can run simple queries with some hash DBs and retrieve specific data, by key, at the drop of a hat; this is where (for the most part) key-value stores win out over relational databases.<p>It is clear, at least to me, that these two classes of DB serve two different purposes, with some overlap. By that logic, I see no reason why they can't happily co-exist in a single project. In fact, I'm using multiple database formats in a single application without any problem. Sure, there is a little more management and some extra logistics involved, but the point is that each type of database is used with its strengths in mind.<p>I'm not going to force MySQL to be a giant hash table when something else will do the job better, and I'm not going to force Tokyo Tyrant to try and be a relational database (not that I really could).<p>Am I wrong in finding a happy medium between multiple technologies?

The subjunctive: if only it were that easy. Actually, it is in English because we only ever really notice it in a few places...<p>Grammar nitpickery aside, good article. Is client-side hashing really that big a deal? I don't know from first hand experience because I've never bothered with these things yet.

I thing there's an explanation to the NoSQL movement and why non-rdbms are gaining popularity these days.<p>Not a long time ago, if you had to handle 1 billion records then you were already big with piles of $ sitting beside you. Then you would just call Oracle or Greenplum (or whatever) and say "Hey, I've got some million $ here, care for it? I just want to be fast(tm)"<p>Lately it is quite possible to be small and forced to handle millions of records daily or struggle with new technologies that require less man power for development but need scaling a lot earlier (e.g Rails). You have limited resources and if you can get away with Tokyo Cabinet on a single machine instead of a 100k mysql cluster then you get to live longer.<p>As any new cool technology it'll get some hype and then fall back to being the right tool for the job. It's good to have some alternatives to RDBMS, some problems are really not relational.

Before relational databases, you know what was the standard? Hierarchical databases, aka key-value stores. <a href="http://en.wikipedia.org/wiki/Database_management_system#History" rel="nofollow">http://en.wikipedia.org/wiki/Database_management_system#Hist...</a> Since then, object oriented databases have come and gone - another hierarchical DB.<p>I wasn't there when it happened in the 70's, but I think it's essential to understand why relational beat hierarchical then; and to understand what has changed since; because only then can we make an informed prediction.<p>I think the issues were efficiency and ability to analyze the data. Anybody know what the actual reasons were?

Why doesn't Oracle Coherence ever come up in these discussions of RDBMS alternatives?<p>I've been going over its documentation, and it looks like the cat's meow in getting rid of the database scalability bottleneck. Think of it as memcached done right. Coherence has automatic clustering, needs almost no configuration, supports many flexible distributed schemes, easy API. With Clojure and Scala, you don't even have to use Java to use it.<p>Has no one heard of it? Does it get no love because it's commercial and (probably) expensive?

Peer pressure. I have never seen this in any other light.<p>The "versus" mentality of this stupid meme comes from those either proselytizing or stubborn. Plain and simple.<p>If you're too ignorant to understand what is the appropriate tool for your situation, or offended by the perceived alternatives, then you should withdraw from this topic.

Great post. NoSQL seems to be a band-aid. And for some problems, the best solution is to rip off the band-aid :)<p>My thoughts at <a href="http://hypecycles.wordpress.com/2009/08/05/look-ma-nosql/" rel="nofollow">http://hypecycles.wordpress.com/2009/08/05/look-ma-nosql/</a><p>SQL has survived because it is reasonably portable, is descriptive and has a rich ecosystem. NoSQL is a response to a problem but it is one that will not get mainstream adoption because it is non-standard.<p>It is a great stepping stone; what comes out of it is hopefully a standards based scalable data storage and retrieval system.

Coincidence... I'm looking for some simple caching layer right now. But what I need is that data is distributed to all server nodes. I don't care about insert time that much. And the only thing I need to store is a 'unique string -&#62; string' map. (very short strings)<p>Can someone recommend any solution? I'd be perfectly happy with a "replicating memcached"...

"What am I going to build my next app on? Probably Postgres. Will I use NoSQL? Maybe"<p>I just spent some time evaluating several k/v stores for a new project. My conclusion: These things may be useful when I'm ready to optimize. Until then, I'll put everything in postgres.

Most of the noSQL information I've read appears to be more focused on caching, speed, scalability, distribution, etc. To me SQL is a query language, not an RDBMS. "noSQL" is unfortunately misnamed (and rhetorically loaded) although it's much catchier than "noRDBMS".

I stopped reading as soon as he posted something looking like a dictionary definition.

im sure people affiliated with or users of the respective projects will take issue with points made. all told, however, the main takeaway for me is what i already knew and which the author mainly drives home in the last paragraph. specifically, use and take advantage of all the tools out there including the ones in the nosql camp and the more mature rdbms camp. and simply, get started already!<p>projects im working on now sometimes have the same data represented differently in different systems to take advantage of what those systems have to offer. many of them mentioned in the article.

I don't think the primary drive or hype behind NoSQL is <i>performance</i>. I think it is that SQL has become some sort of norm for data persistance, when in many cases a SQL database isn't necessary, or even optimal.