For next time someone asks "what's the deal with MongoDB?"
-
MongoDB: The Frankenstein Monster of NoSQL Databases
Disclaimer: This opinion-piece reflects my own personal views, and does not reflect the views of my employer. NoSQL databases are on a collision course for decades-old relational technology.
We get that question like once a month or so, so here's an answer.
MongoDB does not have a single, unified data access layer. It actually has three completely different layers, each introduced at a different time, and each piling new capabilities onto the core database.
As we shall see, these layers bear no evidence of being the product of a principled, unified, and well-engineered design. Rather, they address rather ad hoc requirements in totally ad hoc ways; they are tangled together; and they overlap in functionality.
They are, in analogy, the ragged dismembered pieces of various bodies that are sewn together in haphazard fashion to create something that never should have been created.
-
For over two years now, I’ve watched MongoDB query questions on StackOverflow, as well as subscribed to mongodb-user. Many of the questions on StackOverflow are about how to query oddly-shaped data for some specific use case. MongoDB’s stock answer to all these questions is, “Don’t do that!” It’s as if MongoDB cannot conceive of a composable query language that can handle arbitrary queries over JSON data, so instead, MongoDB tells people to change their data model. Well, in my opinion, if the answer to every query question is, “Change your data model to fit our limitations!” then your database is broken by design.
-
But... it's WebScale !
-
Just three months ago, I exposed the fact that MongoDB packaged up a competing database as a “BI connector” (one with horrendous performance, since it pulled all queried data out of MongoDB to perform anyanalytics).
?Opinions expressed are solely my own, and do not express the views or opinions of my employer. When I finally pieced together all the clues, I was shocked.
If you can't beat 'em, ship their product inside your own I guess?
-
Well, in my opinion, if the answer to every query question is, “Change your data model to fit our limitations!” then your database is broken by design.
But... don't standard SQL databases require the data to be in a very precise model? I don't think tables and joins come naturally to most data.
-
Queries are slow but memory is fast. Micro$oft encrypts files instead of plaintext. new db scheme:
database_user.txt
id|name|login|email 1|Lorne Kates|lorne_kates|lkates@example.comand to query:
user.phpfunction LoadUsersIntoMemory() { if($MEM["users"] == null) { $MEM = array(); $fhandle = f_open('database_user.txt'); while($row = $fhandle->next()) { $MEM[$row("id")] = explode($row, "|"); } } } function getUserByID($id) { $return = null; LoadUsersIntoMemory() if(array_key_exists($MEM, $id)) { $return = $MEM[$id]; } return $return; }perfect database in lightning fast memory and unencrypted non-DRM$ file format
-
I don't think tables and joins come naturally to most data.
They, uh... kinda do. I mean, I guess naturally data is a bit more denormalized, but "a bunch of identically-structured records" has been around since the first form was invented.
-
Am I damaged or does this article read "This nonrelational database sucks at doing relational queries. They should fix it so it can do relational queries."
Except the relations can be fuzzy, and only resolved at runtime using rules specified in the query!
I mean, I've been saying all along that pretending your data doesn't have relations when your problem set is basically "I want to know what the relationships are" is an awfully stupid way of going about things.
-
The author's field of expertise is analytics. His job is to help businesses find relationships in their data when their data is in a NoSQL database. That explains the tone of his article, but I can't explain why he chose that line of work.
-
It's complicated.
If you don't know what the relationships are, you can't really create sensible key fields to join on. What would their data type be? And how would you enforce things like key relationships?
So you end up with lots of "little" tables, and no clear picture of how they are related, except for things like dates and other "natural" (but not primary) keys. You'd presumably have to keep your own primary key field, by UUID (for sanity/some semblance of type safety).
Also, there can be algorithmic reasons to want to store relational data in a non-relational store. But I'd suggest storing in a relational store, and exporting the data to a non-relational store when you need to process the data.
But it really sucks when you have to make a long-running query in order to pull data for a long-running algorithm. I've had algorithms that run for a day, but the query behind it ran for a week. (This was in 2006 or so)
-
FUCK THAT VIDEO UP THE ASS.
So sick of people posting that shitty awful video. At least re-record it with a HUMAN VOICE or something, it sounds like ear-rape.
-
FUCK THAT VIDEO UP THE ASS.
So sick of people posting that shitty awful video. At least re-record it with a HUMAN VOICE or something, it sounds like ear-rape.
Fifteen seconds until the above quote is recorded in a robot voice.
-
In that case, couldn't you create a layer that returns JSON from the results of a MySQL call and get what you want more simply, and still have the flexibility of references?
-
I think what he was getting at is the Postgres JSON layer they've added in the last couple years is so good at querying JSON that even MongoDB, the database who's ONLY SELLING POINT IS QUERYING JSON ships it as part of their BI software.
You have to admit that's kind of embarrassing for Mongo.
-
But it doesn't surprise me.
I mean, I could see a software package potentially being more efficient if it strips away was SQL can do and sticks only to document based, but Postgres and SQL in general have been around a lot longer.
-
these layers bear no evidence of being the product of a principled, unified, and well-engineered design. Rather, they address rather ad hoc requirements in totally ad hoc ways; they are tangled together; and they overlap in functionality
DiscoDB
-
If you can't beat 'em, ship their product inside your own I guess?
You know what's funny? We have a need to store/query some JSON for the next version of our application here. Plan: Use PostgreSQL's JSONB data type and be done with it.
Apparently, even the great NoSQL gurus that are MongoDB devs can't find a better solution...
-
But... don't standard SQL databases require the data to be in a very precise model?
Yes!
I don't think tables and joins come naturally to most data.
Disagree, but maybe I've just been thinking relationally for too long. I think there certainly are data that are a PITA to make sanely relational, but most stuff works quite well.
-
So sick of people posting that shitty awful video. At least re-record it with a HUMAN VOICE
The whole point of XtraNormal was that it used speech synthesis. If you hate it so much, re-record it yourself and get a billion hits.
-
The whole point of XtraNormal was that it used speech synthesis.
... because?
The creators just hated everybody's ears?
-
The creators just hated everybody's ears?
No. You could upload a text script for two actors, and specify a scene, like two people in an office break room, or two bears in a forest, and it would use speech synth to produce a mini-movie for you for free.
It wasn't intended to be professional or anything.
-
But WHY would you do that?
If you have a script, which this guy did, why the fuck would you present it in the worst possible manner?
-
If you have a script, which this guy did, why the fuck would you present it in the worst possible manner?
Because "a normal sounding voice" IIRC wasn't an option at the time. Plus, this was a joke video. XN was used to make a lot of those. I don't think people cared much that the voice was robotic.
-
Because "a normal sounding voice" IIRC wasn't an option at the time.
It was made by a mute without any friends?
-
It was made by a mute without any friends?
Probably not, given how widely it was used, 8-9 years ago or whenever the heyday of XN was.
-
If you have a script, which this guy did, why the fuck would you present it in the worst possible manner?
It was funny to hear what would usually be passionate arguments or whatever turned into the robotic monotone. Also, it forced you to concentrate on the words, not the emotion of an actor's portrayal, which was also interesting and different.
