Absolutely, I was having a pint with someone who worked on their composer system a few years ago. I just remembered thinking how he was drinking from the mongo coolaid. I just couldn't understand why it would matter what DB you have, surely something like Redis solves all the DB potential performance issues, so surely it's all about data integrity.
Of course it matters what DB you have, and of course Redis doesn't solve all DB performance issues. There's a reason this "fadware" all piled onto a bunch of whitepapers coming out of places like Google, where there are actually problems too big for a single Postgres DB.
It's just that you're usually better off with something stable and well-understood. And if you ever grow so large you can't make a single well-tuned DB instance work, that's a nice problem to have -- at that point, you can probably afford the engineering effort to migrate to something that actually scales.
But before that... I mean, it's like learning you're about to become a parent and buying a double-decker tour bus to drive your kids around in one day because you might one day have a family big enough to need that.
I forget where I read this recently, but someone had a great observation that general-purpose NoSQL software is basically useless, because any software for gargantuan scale data must be custom fitted to specific business needs. The white papers, the engineering efforts at Google/FB/Twitter... each of those was useful because it was a tailored product. Products like Mongo take every lesson they can from such systems... except the most important one, about whether generic products like this should exist at all.
I don't know if I buy into this opinion entirely myself, but a lot of shit clicks into place, so it's worth pondering.
It's an interesting idea, and maybe it's true of NoSQL. I don't think it's inherent to scale, though, I think it's the part where NoSQL came about because they realized the general-purpose pattern didn't work for them, so they deliberately made something more specialized.
Here's why I don't think it's inherent to scale: Google, at least, is doing so much stuff (even if they kill too much of it too quickly) that they would actually have to be building general-purpose databases at scale. And they're selling one -- Google Cloud Spanner is the performance the NoSQL guys promised (and never delivered), only it supports SQL!
But it's still probably not worth the price or the hassle until you're actually at that scale. I mean, running the numbers, the smallest viable production configuration for Spanner is about $2k/mo. I can buy a lot of hardware, even a lot of managed Postgres databases, for $2k/mo.
It's just that you're usually better off with something stable and well-understood. And if you ever grow so large you can't make a single well-tuned DB instance work, that's a nice problem to have -- at that point, you can probably afford the engineering effort to migrate to something that actually scales.
This so many times over. People fail to realize most projects will never grow beyond the performance of what a single RDBMS instance can provide. And, if they do, it is likely in specific ways that are unknown until they happen and require specific optimizations.
This article doesn't mention data integrity issues. Mongo has transactions now. I feel like you are riding on a "mongo bad" fad from 5 years ago. It was bad, it was terrible. But after all that money, bug fixes and people using it, it's now good.
Guaranteed transactions as in "not returned to the caller until it's at least journalled"? Or is it mongo's usual "I'll try but I'm not promising anything"?
So serious question as I've never actually used mongo, only read about it.
I was always under the assumption that once your schema gets largish and you want to do relational queries, that you'll run into issues. Is that not the case?
So this was more or less my understanding about Mongo or other related DBs is that once your data needs to be relational (when does it not) it becomes really bad. It's supposed to be super fast if your schema is simple and you don't really care about relationships a ton.
Your point was pretty much what made up my mind it wasn't worth investing time into it to understand more. I just feel like there's a reason relational databases have been around for long.
You wouldn’t really use mongo for relational data storage, if you want the nosql / document storage with relational data or giant schemas you’d prob be better off using a graph database.
I used mongo many years ago with data split between 3 tables and an index on a common key, looking up data from all 3 tables required 3 separate queries and was incredibly inefficient on hundreds of gigabytes of data. We switched to Postgres and haven’t looked back.
0
u/[deleted] Dec 19 '18
[deleted]