3 ms·
Unfortunately I didn't find much information in the article. Basically I got out of it: - he likes JS, and was comfortable with MEAN-stack (MongoDB/Express we
by nchelluri 12y ago
Unfortunately I didn't find much information in the article.
Basically I got out of it:
- he likes JS, and was comfortable with MEAN-stack (MongoDB/Express web framework/AngularJS/Node.js)
- he found that for document oriented purposes MongoDB could sometimes be a nice fit
- he found that replacing MongoDB with the drop-in replacement TokuMx (seems like a MySQL/MariaDB type of idea), he could get a big performance increase
- he found that with Postgres 9.2+ using the JSON/document storage there he could get some of the relational benefits and some of the document benefits, and ACID
- he likes ACID because of transactions/handling multiple documents at once
Ok, so I guess I was wrong, there is a bit there. But: this is all stuff that I've heard several times about MongoDB.
One of the things he got into was that he learned when MongoDB was appropriate and when it wasn't -- but IMO he didn't really go into detail here other than to say: joins and transactions. I wish there was more substance than that.
I also seem to recall reading recently that even supposedly ACID compliant databases have problems with transactions under load and that the only way to really get full ACID compliance is to treat transactions as serializable - perhaps I am wrong but I think this is the gist of what I've learned.
Personally, I'm working on a project right now that uses MongoDB and I definitely do miss joins, transactions, and schemas. I am not even remotely sure where one would benefit from a system that had documents with arbitrary fields in it. (I didn't pick the technologies for my project.)
I would really like to know when to choose which database - I feel like I know the bare basics of several, and none of them in depth. I really don't have time to learn them all. I feel like even when I'm building one application it's only some months after deployment that if I'm lucky or made a mistake that I will run into some actual performance constraint.
- crdoconnor 12y ago>I would really like to know when to choose which database I have asked this question before - under what situations is Mongo not just equally good as Postgres - but actually better? The only really coherent answer was that it was easier to configure replication (presumably because it chooses a lot of defaults for you). I'm not even sure that was a good thing given the number of obscure bugs that can arise from incorrectly configured replication. Postgres even seems to be more performant at NoSQL use cases (using the JSON store) than Mongo, which is frankly embarrassing.