The NoSQL Hype Curve is Bending

Some NoSQL solutions are general purpose, and some aren't. I think the analysis is accurate for those which aren't (Cassandra), but way off for those which are.<p>The advantage of NoSQL for the average folk isn't their speed, but rather it's their dynamism. This is especially true if you're coding in a static language. You also gain from the shift to map-reduce vs group by.<p>There seem to be two other points to the argument. First, someone made a funny Youtube video (and it was funny!). Second some people failed with NoSQL. Not especially good arguments.

The author is an SQL language and MySQL database consultant, and he writes an article questioning NoSQL. Fair enough, and I agree with his point that different NoSQL datastores have different strengths and weaknesses and it can be difficult on a new project to know up front which CAP tradeoffs may be OK to make (e.g., HBase may have better tuning for faster consistency but Cassandra is likely easier to set up across different data centers; MongoDB is very easy to use in simple master slave or replica sets setups if no sharding is required; etc.)<p>Personally, I use PostgreSQL and MongoDB for most of my work but make a real effort keep up to speed on CouchDB (actually, BigCouch is more interesting), HBase, Cassandra and a few RDF datastores.

I've had a pretty good run at cleaning up after botched database jobs, so caveat emptor...<p>Two things:<p>1. Most day-to-day problems involve relationships among entities. It's not stodgy or wrong to use a good RDBMS when that's the problem you're dealing with.<p>2. Many NoSQL adopters wind up building a relational database on top of something else. That's a fun job, but not everyone can afford to ditch 40 years of R&#38;D and pretend they've invented something. I think a lot of the allure in implementing these solutions comes the hype, promise of a silver bullet-like solution, and the opportunity to dabble the intricacies of creating a database.

Does attention and interest == hype?<p>I've seen many articles about NoSQL, but few that insisted it was the shit and the True Path for all development.<p>Mostly the articles explained what this or that DB was, or how this or that company solved a problem using some NoSQL tool.<p>It's new (for many people), interesting, and worth talking about.<p>If anything seems over-inflated to the point of hype, it's the idea that there's all this hype about NoSQL.

One of the biggest costs of a NoSQL solution in an early-stage startup: what's hot today may be abandoned by everyone else by the time you're a real company, leaving lots of effort inventing clever solutions to novel problems created entirely by your data.<p>It's much more feasible to start with a solid database and add caching for hot data than it is to try to build a company and a brand new database technology at the same time.

I took me 3 months or so to finally grok CouchDB map/reduce queries. Now that I've seen the light, I'm not sure I'll go back to an RDBMS any time soon -- at least not for bread and butter webdev.<p>"...You must know what will be the questions that you will be asking upfront."<p>Even in SQL land you need to know your queries in advance. Sure you can do table scans on unindexed fields, but you're going to crush i/o.<p>With Couch you can always deploy new views during a maintenance window for queries you didn't anticipate. Same thing with adding indexes in an RDBMS to handle unanticipated/slow queries.<p>At least with Couch I know that my queries are more-or-less pre-computed in B-trees. I know I'm not scanning the same tables over and over.<p>Moreover, if you know what you're doing wrapping conflict handling around Couch's MVCC is straightforward.. and you get all the benefits of offline replication.<p>In my case, I've built a service that calculates utility-style usage based off Couch range queries that are reduced into a cost calculation. Given any date range I can reduce a utility fee an order of magnitude faster than I could in SQL land.<p>YMMV, etc.. but I'd say this is a case of "haters gonna hate".

It seems contradictory, since startups thrive on making radical departures from the status quo, but I think there's a strong case to be made to build your foundation (the stuff nobody sees, but plugs along silently in the background) on tried and true technologies, as opposed to the hot new thing.<p>Of course, in 5-10 years, some NoSQL solutions will be the tried and true tech, and we'll be arguing whether DoublePluSQL is really worth all the hype it's been getting.

This is a terrible article. His three main points:<p>1. "You find yourself writing lots of code to reinvent the wheels that SQL gives you for free, and before long you’ve unwittingly reinvented the relational database."<p>NoSQL came about because people were sharding their data and managing relationships outside of the data layer in custom code anyway, and they were well-served by putting some of that complexity back into the data layer. This wasn't a trend because people don't understand the mathematical beauty of normal forms. This was a trend because altering the schema of a heavily accessed MySQL table will bring your website down.<p>2. Digg<p>A Digg engineer on Quora recently said, "The whole 'Cassandra to blame' thing is 100% a result of folks clinging on to the NoSQL vs SQL thing. It's a red herring." (<a href="http://www.quora.com/Is-Cassandra-to-blame-for-Digg-v4s-technical-failures" rel="nofollow">http://www.quora.com/Is-Cassandra-to-blame-for-Digg-v4s-tech...</a>). Yup.<p>3. The MongoDB is Web Scale video<p>...really?

The irony is that most of the arguments for NoSQL have nothing to do with SQL itself and everything to do with the underlying storage mechanism and ACID semantics. A more accurate acronym would be NoB-tree or NoACID.

This is actually the first time I came across <a href="http://www.xtranormal.com/watch/6995033/" rel="nofollow">http://www.xtranormal.com/watch/6995033/</a><p>I have always seen the relational-databases-VS-nosql-databases as a false dichotomy. I think these systems serve different purposes. I use MySQL+memcache for a site now, but I'd have no hesitation to use CouchDB for another site if that's more suited for it. I'd even use them both if that's beneficial for the webapp.

NoSQL is a terrible name for a technology. Why define it by what it isn't, instead of what it is?<p>I've pretty much ignored NoSQL because of this, and because I haven't had any data storage problems that aren't easily solved with either a relational database or LDAP.

A chap named Brooks wrote an article a long time ago that went by the name "No Silver Bullet".<p>Sorta sad how the world keeps looking for the silver bullet to slay the vampires of software. You'd think by now we'd know...

Yep... I never quite bought the NoSQL hype.<p>The only valid point was to relax some of the guarantees (like consistency) in order to achieve better scalability.<p>In the end once cannot escape the CAP theorem (<a href="http://www.julianbrowne.com/article/viewer/brewers-cap-theorem" rel="nofollow">http://www.julianbrowne.com/article/viewer/brewers-cap-theor...</a>)

I'm one of those who dove head first into NoSQL primarily because of hype. I've learned better. Relational is now my default, and I identify specific cases, specific tables that I know for sure won't need complex querying, and move those to NoSQL.<p>Though the end effect is that NoSQL still stores 60+% of my data.