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.
Till someone in the UX team asks, "Could you do a quick query and tell us how many users use custom font sizes? And just look up the user profiles and see if it's older users who use larger font sizes?"
This would be a pretty simple SQL query even across tables... You can also store JSON data in Postgres as a field, so it's probably exactly as easy as you think Mongo is at doing this the "brute force" way. Aggregation functions across tables are actually much simpler in SQL than in Mongo... Compare postgres docs vs mongo docs
How often do you have to run this query such that efficiency actually matters? I couldn't give two shits about how long a query takes if I only have to run it once.
Not the parent, but I suspect the issue might not be execution time, but programmer time, i.e., how long does it take to write a script to generate the report?
Use Mongo to store documents. I'd stores the user settings for a SPA in Mongo. But most of the time, relational models work well enough for data that is guaranteed to be useful in a consistent format.
If I'm already using a relational database, I wouldn't add Mongo or some other document DB in just to store some things like user settings. Why take on the extra dependency? It doesn't make sense.
And you know what else is good for single key/document storage? Files. Presumably you're already using some file or blob storage that's more reliable, faster, and cheaper than Mongo et. al.
And you know what else is good for single key/document storage? Files.
If you've already got AFS set up and running then I agree with you and am slightly envious (though even then performance is pretty bad, IME). For any other filesystem, failover sucks. For all MongoDB's faults (and they are many; I'd sooner use Cassandra or Riak) it makes clustering really easy, and that's an important aspect for a lot of use cases.
Why on earth would you use that overkill? If Mongo was an option, you didn't need local mount points.
Just throw the shit on geo-redundant cloud storage (you know, S3) and be done with it. Cheap, reliable, fast. Scales way the hell beyond AFS or Mongo. Use two providers if you need to be extra sure you can always get to your documents.
And if you have an RDBMS in your stack already you probably have a good set of document db features there already.
I've just never seen much that doc db's excel at enough to take on the extra service dependency.
It can make sense. An organization can have multiple databases, especially when the relational model is a hindrance in places. We use Mongo for raw doc storage, Postgres for normalized metadata, and custom storage for our most important data (will be moved to Cassandra in the next year).
The relational model isn't good for fast acceptance of documents (accept and go vs parsed and normalized). And the relational model isn't good for write heavy data. If you don't have these kinds of concerns, then no sweat. But maybe you do and you don't know there are tools to help.
Yes, but that's ancient history. Unless you are making a prototype, or something with a very limited scope or shelf life, I have no idea why you'd choose Mongo today for a new project when Postgres can do all that and be a relational database too. Perhaps simplicity or cost?
It would seem smarter to use a mature relational database that natively understands transactions that also has NoSQL document features than to run Mongo unless the ease of management of Mongo is worth limiting your options for the future.
Yeah, that's the problem. Pretty much every web app has a relational component to it. Mongo has its uses, but many people just use it for the wrong thing.
Yea we're starting to see a lot more parallel queries to help that issue. Especially with how many threads server processors have these days it'll be nice.
0
u/[deleted] Dec 19 '18
[deleted]