NoSQL Misconceptions

Ben Scofield, Technology Director, October 21, 2009 13

I wanted to clear up a couple of misconceptions about NoSQL that I've seen much too often lately (what can I say – I watch the Twitter results for 'nosql' obsessively).

Scalability/Performance

NoSQL is just about scalability and/or performance.

This is a particularly attractive claim for the traditionalists because it allows for the hope that these alternatives could be made obsolete in the future by making your RDBMS of choice faster or more scalable.

Unfortunately (for the traditionalist), there's a lot more to NoSQL than just performance and scaling. Most importantly (for me, at least) is that NoSQL DBs often provide better substrates for modeling business domains. I've spent more than two years struggling to map just part of the comic book business onto MySQL, for instance, where something like a graph database would be a vastly better fit.

Database Types

NoSQL is just document databases, or key-value stores, or ...

Most of the anti-NoSQL articles I've seen have addressed only document-oriented databases or key-value stores (though recently, column-oriented databases have started to show up as well). Good arguments can be made against each of those solutions for specific circumstances, but those are arguments against a specific type of storage engine. The problem with pointing to those articles as rebutting the utility of NoSQL in general is that the label is much broader than traditionalists usually understand.

"NoSQL" covers a vast set of applications, from Redis all the way up to Neo4J. Any argument that shows that, say, document-oriented databases fail in a set of situations may very well not apply to key-value stores or graph databases, and the further arguments required to make those cases are rarely (if ever) provided.

FriendFeed & MySQL

I can do NoSQL just as well in a relational database.

Well, sure, you can (and FriendFeed did, apparently) – but you shouldn't. I could roll my own relations in MongoDB, but that doesn't make it a good idea. Different applications are good for different things; relational databases are great for relational data, but why would you want to use them for non-relational data?

Never SQL

NoSQL is a wholesale rejection of relational databases.

Happily, this claim is becoming less common; many proponents of NoSQL have softened their rhetoric, and the traditionalists have become a little less defensive. It seems that we're moving towards a pluralistic approach to storing our data, and that's a good thing. I've suggested 'polyglot persistence' for this approach (though I didn't coin the term), but I also like Ezra Zygmuntowicz's 'LessSQL' as a label, too.

Posted in Trends on 10/21/09 13 comments

bill shelton said on 10/21 at 11:17 AM

Good post, Ben. As a noob to nosql, I find the schema-free approach appealing for a number of reasons. However, the one social semantic issue that struck me right off the bat was the generic name for the concept - “No SQL”. I wonder if that antagonistic term (like “No Smoking” or “No Dogs Allows") simply just irritates relationalists and contributes to controversy?

Ben Scofield said on 10/21 at 12:07 PM

@Bill: I’m sure that it doesn’t help, but it looks like that’s what we’re stuck with. There’ve been some attempts to move to altdb, but at this point NoSQL has a lot of momentum.

Anders Nawroth said on 10/21 at 04:16 PM

Excellent post! Really good point regarding the modeling of business domains. There’s an argument that goes “you can model anything in a RDBMS” (so from this viewpoint, non-relational data wouldn’t exist). This may be true, but doesn’t take ease of use or performance into account.

Walter McGinnis said on 10/21 at 05:32 PM

My perspective:

I’m in the “wait and see what rises to the top and why” crowd. Basically, at the next point I begin a project or an addition to a project that requires a data store aspect, I’ll evaluate what my options are and choose what I think is the best tool for the job. NoSQL or an RDBMS? I’ll consider what best suits the project.

All common sense, but often people latch onto trends or defend their previous perspectives despite their common sense.

My question about NoSQL:

Where is the Open Standard for the community?

I’m might have missed it because I haven’t done a lot of homework on this, but the beauty of SQL is its relative interoperability. Yes, there are vendor specific extensions that can bite you if you want to change software, but if you forego those it ain’t that hard to move between the various RBDMS programs at this point. This boils down to a vendor independent standard that is ubiquitous.

At this point when considering a tool I always ask “how do I get my data in and how can I get it out again if I want to move it somewhere else?”

Cheers,
Walter

Ben said on 10/21 at 09:42 PM

@Walter: Asking for an open standard for NoSQL is just falling into the trap of thinking that all NoSQL systems are the same - they aren’t. There’s no way a single standard could cover all of the fundamentally different types of alternative storage.

To answer your question for a couple of cases, though: CouchDB and MongoDB both store their data as JSON (or binary JSON), which is about as simple an export format as you can get.

Walter McGinnis said on 10/21 at 10:49 PM

@Ben: Thanks for the reply. I think that maybe you misunderstood my intention because of poor writing on my part. I probably came off as a troll. I definitely shouldn’t have set up the question as though only a single standard is acceptable.

I don’t really care whether there is one or many open standards relevant to NoSQL, as long as any given flavor makes data portability through an open standard possible. So it is good to hear (and I probably had read that previously and just forgotten it) that CouchDB and MongoDB data can be grabbed with JSON easily.

I guess I just mean to raise data portability as something people should choose when considering various data store solutions…

Cheers,
Walter

Kyle Banker said on 10/22 at 05:28 PM

Great post, Ben. I especially appreciated your first point, that NoSQL isn’t just about performance gains, because, honestly, many applications will never need to scale.

On the other hand, plenty of apps could use a simpler data model. What initially excited me about document-oriented, schema-less databases was that data modeling could become much more sane. Applications that might require dozens or hundreds of relational tables can typically be modeled with many fewer different document collections.

Austin King said on 10/22 at 05:53 PM

@Walter makes a good point about an open standard.

I’m not a fan of the term NoSQL as a blanket term.

This post seems to broaden the scope of the movement to include RDBMS and SQL… kind of makes for a confusing flag to wave…

Throwing away relational, graph, and hierarchical database theory is a bad idea.

Your NoSQL is a bit like the Structured programming movement (late 60s)… who is going to disagree if NoSQL means “use the right db theory for the job”.

NoSQL should live or die by the merit of distributed key-value stories, neo4j and other DBs that take advantage of CS theory shouldn’t be considered NoSQL.

BJ Clark said on 10/22 at 06:00 PM

Good post Ben. The only part I disagree with is your argument against using MySQL as a key/value store.

You say “why would you want to use them for non-relational data?”. MySQL has a blazingly fast network protocol, as well as being able to write data to disk super fast (comparable to Tokyo Tyrant and Redis). It has great libraries for interacting with in almost every programming language, a massive user base, robust replication, and almost everyone that has every written a web app has experience with it. I’ve yet to see any concrete evidence (sorry if I don’t take your word for it being a “bad idea") as to why it’s not a good key/value store. Just because it has more features doesn’t mean that you have to use them nor does it mean it’s a bad piece of software.

Ben said on 10/22 at 09:31 PM

@Walter: No worries! I think I understand your point a little better now, and I totally agree.

@Austin: I’m not sure where in the post I argued that traditional RDBMSs should be included under the NoSQL banner. I totally agree, however, that we shouldn’t abandon the advances that RDBMSs (and graph databases, and other tools) have made over the last thirty+ years. Unfortunately, however, there *are* people who disagree with the principle of using the right DB for the job – or more accurately, think that RDBMSs are *always* the right DB, regardless of the job. That’s the crowd I’m arguing against here (well, technically I’m also arguing against the much smaller crowds that say ‘always use a document DB,’ too, but I don’t know if those parties attract anyone.)

@BJ: I love MySQL, and you’ve certainly got a good point that extra features don’t disqualify it from being a great K-V store. My intuition is that an application dedicated to being a K-V store will be superior to something that’s not so dedicated, but I’m betting that somebody out there is benchmarking this even as we speak. It might turn out that MySQL is better than [insert flavor-of-the-month K-V store here], but at this point that’s an open question. I’m happy to admit that using the right DB for the job depends on knowing (with empirical backing) *which* DB is the right one :)

Rich Collins said on 10/23 at 05:25 AM

Steve Derkote and I have just related a new graph database with a filesystem like REST API:

VertexDB: http://github.com/stevedekorte/vertexdb

bill shelton said on 11/05 at 07:05 AM

Ben,

You’ve probably seen this, but it speaks to my original comment about the term “nosql” -
http://blog.sym-link.com/2009/10/30/nosql_whats_in_a_name.html

To quote Eric Evans, “My regret however isn’t about what the name says, it’s about what it doesn’t. “

thanks,
bill

Ben said on 11/05 at 09:59 AM

@bill: Thanks for the pointer! There’ve been a number of great articles popping up lately - it might be nice if there were a central place to see them all (heck, maybe I’ll do that if I can find the time over the weekend).

Next entry: (re)-Introducing simple_importer

Previous entry: My Tools of the Trade

Development Blog: Viget Labs