NoSQL is a pile of crap By ksandstr in ksandstr's Diary Sun Feb 28, 2010 at 05:33:47 AM EST Tags: nosql, sodomy, horsecock, crack-smoking horse-riding bandit monkeys, pole (all tags)
	You've all heard of the so-called NoSQL movement. They reject relational databases and substitute retro 1960s key-value stores from the dark ages of practical computing, before we had things like hierarchical file systems. The popular reason being that the Intarwebs 2.0 demand it, and JSON, and writing javascript to query unstructured tuples in a dynamically sharded key-value store, or some hand-wavey generic horse like that.

It's all crap, of course. I shall now enumerate the ways: In your average NoSQL key-value store, to perform a query that's more complex than "here key, gief value plz" in Enterprise LOLCODE, the programmer must write code to perform a sequential scan of the entire data store's big-ass hash table or its equivalent in a map/reduce access model. That sort of code will appear in tens of places in any non-trivial application, and is very easy to get wrong either out of incompetence, copy-pasting or plain boredom. To contrast, executing a SQL query is quite hard to mess up. The interface is simple: submit query, receive N result tuples in order given after the SELECT but before the FROM. SQL doesn't fuck around. NoSQL is not convenient. Design and implementation of complex persistent data structures in the key-value paradigm is left up to the application programmer. (If you, the reader, have enough beard on your chin to stroke, you may skip straight to point 3 now after emitting an audible guffaw.) Let's charitably assume that the application programming team is able to implement a data structure, with reasonable performance characteristics, for recording hierarchical comments (as in Scoop). Nevermind that the toolkit for implementation is something like "compare and exchange", bane of all threading-naïve programmers everywhere (even moreso than mutexes or ABA race conditions), Team Cowboy is Just That Good. Now you have your data structure, and that's fine. Three months down the line a fresh off the boat social media company on the interblorp invents and publishes a new way to cross-reference user data with other user data, which produces a new requirement for Team Cowboy's application. The data structure described above does not trivially support the new feature, but another data structure would. This one is available as a Free software library, but sadly the two were developed separately and therefore have clashing views of atomicity. Team Cowboy, despite all their brilliance, is screwed. In another company entirely the SQL haxxers set up a couple of tables more after two days' careful data modeling and bumble off into front-end implementation without a care in the world. Unlike atomic operations, transactions are composable and any halfway sane SQL database will pop a deadlock-or-serialization-failure status when transaction promises couldn't be kept after all. Certainly, having to restart a transaction on some by definition entirely impredictable condition inspires some whining, but that's very little compared to the same for what's at its core a compare-and-exchange on persistent data: Team Cowboy is stuck rewriting all of their code that even as much as looks at their previously sophisticated and cutting-edge key-value data management strategy. NoSQL is not flexible. NoSQL databases have no schema. That's what makes them so revolutionary. (Like having granny glasses and a Mao suit and radical ideas about LSD and body hair.) No schema means no consistency checks beyond one key, one value. No consistency checks leaves the system wide open to violations of referential integrity, i.e. the disappearing key problem where everyone knows that data was lost at some point, but there's little idea what it was or where it went or whether it was inserted into the database at all. This was the sort of thing that brought down "my first PHP/MySQL program!" type web forums by the dozen as late as five years ago. What you'd hear from the admins was "all forums crash eventually". Correct use of SQL foreign keys forbids disappearing references. Or permits them, if you like -- ON DELETE SET NULL keeps you from chasing down pointers that don't go anywhere anymore. This prevents subtle breakage that only comes to light when someone attempts to access archived material from, say, three months back. NoSQL is brittle. In short: buckle down and learn SQL, you ignorant chucklefucks. Otherwise you'll spend the next five to twenty years of your life trying to reimplement it.

Poll

NoSQL Good 28% Wack 28% Nigger nigger nigger 57% Votes: 7 Results | Other Polls

Related Links

Scoop ksandstr's Diary