Sunday
Sep052010
Hilarious Video: Relational Database vs NoSQL Fanbois
Sunday, September 5, 2010 at 9:47AM This is so funny I laughed until I cried! Definitely NSFW. OMG it's hilarious, but it's also not a bad overview of the issues. Especially loved: You read the latest post on HighScalability.com and think you are a f*cking Google and architect and parrot slogans like Web Scale and Sharding but you have no idea what the f*ck you are talking about. There are so many more gems like that.
Thanks to Alex Popescu for posting this on MongoDB is Web Scale. Whoever made this deserves a Webby.
Reader Comments (50)
Genius!
Sheer work of genius, this has been going around Hacker News, proggit and IRC like mad. Unfortunately the other two in the series aren't as good :(
agreed. genius!
You can apparently work on a farm and still be a software developer :D .
Funny stuff :D
does MongoDB scale or what!
OMG, Laughed until I cried! Major ab workout!!
Web gem! Must tweet this... now.
It wasn't that long ago that MySQL was a laughing-stock amongst databases because they were the ones ignoring durability in the quest for better benchmark numbers. Now they're the poster-child of ACID?
The old software engineer needs to retire to the farm already. Last weekend on his ipad, while he played an online game, the kid probably built a more complex database than the old software engineer ever has.
Two years from now that kid will be an expert at a technology that the old software engineer has never heard of and refuses to accept. Meanwhile the software engineer is convincing a company to invest a ton of money in obsolete technology because that's the way they did it ten years ago.
This gives me an idea for a technological solution to the economic downturn. All debts must be stored in NoSQL, while all credits are stored in a real database. Boom, easy money!
echo super fast > /dev/null
LOL :)
Smige - you have no idea. I use both MongoDB and MySQL and Oracle regularly. Mongo has failed me on multiple occasions including an outage of over 80% of my data.
Charles Miller - great point. All the things people talk about with MongoDB is what we said about mysql 10 years ago. Back then, no transactions no foreign key constraints and no real backups. SQL allowed for joins though ;)
There are two types of fool in the world - those who say "This is old and therefore good" and those who say "This is new and therefore better".
Smidge: s/ten years ago/since before the young software dev was born/. There is something to be said for maturity in technology, something the young software dev would not get, seeing as they glom onto every shiny thing they see. In ten years, SQL / RDBMS will still be around and storing more data than the current crop of 'NoSQL' databases, and those current NoSQL databases will be long forgotten and the even younger software developer will be playing with the latest version of CODASYL/XML Databases/Flat files.
It's called "right tool for the job" -- sometimes a highly complicated relational database is NOT the right tool, and sometimes a braindead key/value store is a bad idea too. You have to put some thought into how you're storing your data and pick a solution that makes sense in the situation, and there's no single "right" answer.
If your RDBMS schema consists of two columns called "key" and "value", and all you're storing is a bunch of web forum comments or something equally unimportant, you're doing it wrong.
If you're writing the same data to 20 different systems and running a backup every five minutes to make sure that you don't lose any invoices or credit card numbers, you're doing it wrong.
Smidge,
Although it would be entirely possible that the kid could produce such a complex database (using his new and magical toolkit), the odds are overwhelmingly in the favor of him never being able to produce ANYTHING useful (much less complex) with that toolset. This is the real par-for-the-course. In many cases, that magical new technology dies a quiet death before the first production application ever emerges. This is the nature of our business, always has, always will be. People are generally attracted to ANYTHING that promises to make a complex problem simple, regardless of how ludicrous the "solution" is. This is true for an obvious reason. A rookie software engineer has little context on which to draw his/her conclusions. If they did, they wouldn't be a rookie. Speaking as an "old" software engineer, it's this sort of silliness that would have driven me to work on a farm years ago ... if farm work only paid a little better ;)
Impotence mismatch. Too funny! These kinds of arguments were once used to advocate object databases.
A plague upon streaming-only videos. It is impossible to watch them without a high-bandwidth connection. If it at least allowed downloads I could watch... but no. May the fleas of a thousand sewer rats infest the genitals of those who develop streaming-only formats. I wanna see the funnies.
Oh, and 'anonymous' above was right that it pays to choose the right tool for the job. Monolithic relational databases are absolutely the wrong tool for certain tasks, just as nosql is not appropriate for others... otherwise you are simply pounding screws in with hammers.
For me this is as much about people in our industry that drop the latest buzz words into conversation to gain the perceived intellectual high ground, as it is noSQL vs. Relational. Brilliantly done.
Hahahaha, is great! :) let's pipe all the data to /dev/null
hahahaha
MySQL transactions?! HAHAHAHAHA
"if there's a problem writing your data, you're f*****. Does that sound like a good design to you?"
Exactly! When MySQL silently truncates data, it makes my loins quiver in delight.
mysql> CREATE TABLE table1a (number int(20) DEFAULT NULL) ENGINE=MyISAM;
Query OK, 0 rows affected (0.06 sec)
mysql> insert into table1a values (19.54);
Query OK, 1 row affected (0.00 sec)
mysql> select * from table1a\G
*************************** 1. row ***************************
number: 20
1 row in set (0.00 sec)
CheechAndChongDB doesn't scale because of the overuse of joints.
you think you'll trap us with that? Lame :)
Does /dev/null support sharding ...
Nice work, really liked it, lol
It's a shame this parrots a few of the myths. Safe writes in MongoDB are trivial to implement, they're just not switched on by default. You have the choice between unsynced writes to memory for performance, or safe writes for, well, safety.
I had to snicker - thinking that i wouldn't laugh as hard as you would... but i found myself at 2 minutes in... laughing outloud so hard, my wife came into my office to ask what was so funny! Nice find!