<i>NoSQL will never die, but it will eventually get marginalized, like how Rails was marginalized by NoSQL.</i><p>Is it just me, or does this statement make absolutely no sense whatsoever?
AdWords implemented on top of MySQL? Perhaps the CRM portion of AdWords (i.e., where the advertisers submit their ads and publishers view their balances) is -- it's fairly easy to partition by functionality and doesn't have extremely tight latency bounds. This isn't where real time auctions (what really distinguishes AdWords from what came before) happen.<p>You can be <i>sure</i>, however that the data used for real time ad auctions is extracted out of MySQL and into a <i>highly</i> customized data store (likely, a pure in memory one). It's all about using a right tool for the job. You can also be sure that you'll never see a paper on that data store, as that's their competitive edge. If you could duplicate it with off the shelf components (whether MySQL <i>or</i> Cassandra), Google would be toast.<p>Likewise, I am sure Amazon uses Oracle for their billing system and catalog submission interface, but they use specialized systems for search, shopping cart and recommendations.<p>For a business app that only needs to scale to the amount of <i>paying</i> customers (i.e., advertisers, account managers and customer support) and has no real time constraints -- but on the other hand involves complex and frequently changing business logic (e.g., where altering tables may be required) an RDBMS is the right tool for the job.<p>Where latency matters, data grows much faster than Moore's law (in relational to main memory size), Amdahl's law starts to matter in regards to computation (computation work load needs to be partitioned to take advantage of parallelism), and traditional caching strategies simply don't work, something else is. That situation is starting to become more and more common across web companies. You can also be sure that places like Wallmart and the like employ plenty of non-relational technologies (my personal bet would be is that they're likely using Coherence or Terracotta): usually, however, they're expensive and are built/configured by field-engineers to be custom tailored for their workloads. When you employ a world-class engineering team, "build" starts to make more sense than buy when you're solving a very specific and constrained problem (e.g., fault tolerant shopping cart system).<p>You don't need to be of Google's size to be at that stage. Talking about scalability and performance without taking the workloads into account (e.g., "Google Facebook or Amazon" as if e-commerce, search and social networking were compatible) is also an anti-pattern: I am sure engineers at Google would laugh when you compare Facebook's scale to theirs; likewise Facebook's engineers would laugh when you compare the real time aggregation that happens on their site to what happens at Amazon; Amazon's engineers would likely tell you holiday season pager duty horror stories that would scare Facebook <i>or</i> Google engineers.
There are a rash of these articles popping up. While there are usually valid points in urging people to avoid the hype of the "next big thing", a lot of these guys seem to be bitching that they might have to learn a new skill set.<p>I have been in this business long enough to remember Clipper and FoxPro devs bitching about SQL when it was on the rise. This sounds about the same to me.
Ted's point may be valid for BigTable-like databases. (I'm not saying it is, but I don't know enough about those to say so.) Those are designed for scalability and if you don't need the scalability you probably <i>should</i> use a RDBMS instead.<p>But there are other advantages of SQL-less databases that don't deal with scale. I deployed my first MongoDB app a couple weeks ago. Even though it was a small (~1 developer month) project, and neither myself nor the other developer had used MongoDB before, I still think we finished faster than if we'd used MySQL. Just like Cassandra is a premature optimization if you just need an RDBMS, an RDBMS is a premature optimization if you only need an object store.
It occurs to me that MySQL started off as a thin SQL wrapper on a NoSQL database: here, have a SELECT and WHERE, but you'd best not JOIN, and forget about transactions or referential integrity.<p>Then, over time, they tacked on a few more relational features, but they had yet to solve the hard problems of relational databases.<p>Meanwhile, the people who were originally drawn to MySQL as a dumb-and-quick datastore got frustrated with this line of development and christened the NoSQL movement. It's not so much a departure from relational databases (they were never really there), but a return to <i>MySQL</i> basics, w/out the SQL.
"Did you know that Cassandra requires a restart when you change the column family definition? Yeah, the MySQL developers actually had to think out how ALTER TABLE works, but according to Cassandra, that's a hard problem that has very little business value. Right."<p>Really did the MySQL people think about it? because it takes ages to do an ALTER. Even when you are doing something like <i>dropping</i> an index it can lock up for hours, where no one can do any inserts. In contrast restarting a service is no big deal.
I can't believe some of what is said by people on both sides of the NoSQL arguments. Discounting use of RDF data stores, almost all of my recent work involves PostgreSQL and MongoDB. I think that it is blatantly obvious which to use in specific circumstances. I have not had to do this yet, but using Datamapper.setup, you can integrate the use of both in the same application by storing some model data in a relational database and some in MongoDB, as it makes sense to do so.
As is to be expected from this author, this is definitely on the flame-bait side of things. I submit it because I believe there is an important point here: for the vast majority of startups, going with a relatively unproven "NoSQL" database is a premature optimization and an unneeded technical risk. I disagree with the author that these databases are a flash in the pan, but their over-application is.
No one has ever explained this to me: why are we partitioning this space? Why can't a single database management system:<p>* have individual tables, indeces and views that are <i>either</i> relational <i>or</i> document-oriented, <i>or</i> graph- or object-based while we're at it, on a case-by-case basis,<p>* manage them all in a single, well-known distributed pool,<p>* and present a unified API to access all of them (e.g. a Structured Query Language of some sort)<p>* that allows tables of disjoint types to be joined in queries, with appropriate warnings when it creates non-optimized query plans?<p>In other words, why can't I say that my reports table should use the "relation" backend, while my messages table should use the "document" backend, and be done with it?<p>It's as if, when you went to a car dealership, they asked you whether you wanted to see the "cars with cigarette lighters" or "cars with automatic windows" section. Why can't my car do both?
NoSQL might be hype. Let's get specific. Cassandra eliminates the SQL database single point of failure and hard to replace masters via a lose sync, "eventually consistent" protocol.<p>Is there some startup offering a web service that doesn't need that?<p>And have you ever tried to deploy an SQL database capable of thousands of miles apart syncing?<p>Eventually consistent is quite a different model than ACID. If you accept that, and accept that you can't rely on networks to always be up, you'll live comfortably and cost effectively.
I recorded a list of issues that may prevent you from using Cassandra as a general purpose website storage right now.<p><a href="http://www.codexon.com/posts/is-cassandra-ready-yet" rel="nofollow">http://www.codexon.com/posts/is-cassandra-ready-yet</a><p>It appears as though Ted's complaint about needing to restart Cassandra to modify ColumnFamilies (tables) is nearly obselete. A patch for the last remaining subtask has been submitted.
I'm getting tired of both sides of this argument, I'll be happy when the whole back and forth dies :). Rarely do you see a balanced opinion. Sometimes it's people that are fanatical about the new-ish NoSQL idea. Other times, like this, it's someone so stuck in their ways they think that everything but what they like is a fad and nothing will ever change.<p>One of the key things I look for when I interview developers is that they can recognize the right tool for the job. Potentials that get married to a technology or language are shown the door pretty quickly.<p>Also, as others have pointed out, this particular article seems to not quite understand the decisions involved, to the point of getting some things backwards.
I myself am not actually sold on the noSQL movement, at least not on the idea of ditching SQL entirely. It has its place, but may not be the best solution for every problem.<p>That said, on the authors complaint about having to restart cassandra when doing the equivalent of an alter table: lately every time we do an alter table in MySQL (which takes hours on large tables, during which time you can do nothing with them), when the alter finally finishes, MySQL mysteriously crashes. MySQL may have given more thought to the problem, but their solution obviously has problems too.
Macs are better than Pc, C# is better than Java, Unix is better than Windows, RDBMS are better than NoSQL databases...<p>Why can't people just use the best tool for the job and move on...<p>From a personal stand-point we've switched from MySQL to Google AppEngine (and BigTable). Although I find there are some major drawbacks (e.g. joining tables) not having to worry about database servers and scalability is a major advantage. That said, if MySQL becomes the best tool for a particular feature, then let it be...
The scalability aspect of "NoSQL" is interesting, but I think possibly the more interesting part is the wide diversity of data models (key value, schema-less tables, document databases, etc)<p>True, some of these models are more restrictive than traditional RDBMSs to provide scalability, but I think some of them will often be useful even if scalability isn't initially a concern.<p>In fact the term "NoSQL" itself is more relevant to the data models than the scalability.
The author makes some very valid points, but I will retort that RDBMS are overused as well.<p>Sometimes you just want to store data on the disk in a safe and language agnostic way.<p>You don't care about relations.<p>In that case, many "NoSQL" engines are really great.
I found the comparison with 'Real Businesses' particularly funny, given Wal-mart have have 2.1 million employees worldwide and Twitter has 75 million users...their scaling requirements are different by a factor of 35.