Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
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:


  1. 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.


  2. 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.


  3. 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.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
NoSQL
o Good 28%
o Wack 28%
o Nigger nigger nigger 57%

Votes: 7
Results | Other Polls

Related Links
o Scoop
o ksandstr's Diary


Display: Sort:
NoSQL is a pile of crap | 17 comments (17 topical, editorial, 0 hidden)
we all agree with you here, move along (3.00 / 2) (#1)
by GrubbyBeardedHermit on Sun Feb 28, 2010 at 06:58:57 AM EST

seriously though, what surprises me in this whole story (and other recurring ones like ORM and stored-procedures) is how there seem to be so many people out there who only want to do either the database, or the application, but NEVER both. WTF? i find it hard to imagine anything get built properly when there is one bunch building the db and another building the app. Both abstractions are massively leaky - not understanding one or the other is bound to end in a fuck up somewhere along the line. As a skilled developer, it's your responsibility to be able understand the whole fucking stack, from the SQL up to the UI. Stereotypes like pubescent web devs who close their eyes and push the Hibernate button (boohoo, why should I have to think about that boring stuff??) and grizzly database-profiling gurus who grump about crazy application data needs (as if the database is somehow intrinsically worth something without an application pointed at it) are ridiculous. Sure, there are people like that out there, and they're all fucking shit up instead of building things. This is because, as a skilled developer, it's your responsiblity to know WHEN to use which tool. Sometimes it's an RDBMS, sometimes it's a persistent hash table. Without understanding the options, how can you choose between them?

GBH

Never heard about them; dr. (none / 0) (#5)
by Vampire Zombie Abu Musab al Zarqawi on Sun Feb 28, 2010 at 08:02:55 AM EST



gee that's so *fascinating* (3.00 / 4) (#6)
by lostincali on Sun Feb 28, 2010 at 08:50:58 AM EST

you must be a riot at parties

"The least busy day [at McDonalds] is Monday, and then sales increase throughout the week, I guess as enthusiasm for life dwindles."

Also: no relationships. (none / 0) (#7)
by claes on Sun Feb 28, 2010 at 09:21:59 AM EST

Which is pretty much point 3.

Yet another example of re-inventing the wheel because you're too lazy to use the wheels that already exist, or don't even know they were invented 50 years ago. Like "binary xml" too lazy to read about ASN1 I guess.

no shit (none / 0) (#8)
by horny smurf on Sun Feb 28, 2010 at 10:44:00 AM EST

I occasionally work with a multi-node B-tree key-value store database

eg

DATA("KEY")="VALUE"
DATA("KEY","CHILD")="VALUE"
DATA("KEY","CHILD","CHILD")="VALUE"

If it was invented today, it would qualify as no-sql, but it was invented in the late 60s so it's legacy.

Whenever possible, I use the sql front end because the alternative is to manually write a routine to do what the generated sql code does.

tell me why this is not in the queue (1.50 / 1) (#9)
by Morally Inflexible on Sun Feb 28, 2010 at 12:15:23 PM EST

"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."  

+1 fp.  

many webapps never really get complex though (none / 0) (#12)
by Delirium on Sun Feb 28, 2010 at 05:13:49 PM EST

I see NoSQL as something intermediate between, "fuck it, we'll just use flat text files" and "ok we'll shovel this crap into a db". It's also easier to get distributed processing essentially for free than with either flat files or SQL. Do you suggest Google should actually put their data into an SQL database? Even Oracle would fall over.

Sure told me there /nt (none / 0) (#16)
by ksandstr on Mon Mar 01, 2010 at 07:40:49 AM EST



Fin.
It's for teh speedz!! (none / 0) (#17)
by Pentashagon on Mon Mar 01, 2010 at 02:19:38 PM EST

The punchline is that they're mostly using interpreted languages to get at the key-value store.

Actually there is a third way out (none / 0) (#18)
by Michael David Crawford on Tue Mar 02, 2010 at 01:45:48 AM EST

Just use assembly code.



NoSQL is a pile of crap | 17 comments (17 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest © 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!