5 ms·
Why would you say duped? Is there some major problem with mongoDB? The way you've stated this makes it sound like there's some common knowledge I should be awar
by computerliker69 5y ago
Why would you say duped? Is there some major problem with mongoDB? The way you've stated this makes it sound like there's some common knowledge I should be aware of.
- marcosdumay 5y ago> Is there some major problem with mongoDB? Yes, plenty. It's mostly useless for relational data. Nowadays that's clear on the documentation and you won't get loud people proclaiming that it's useful there, but there was a time when both of those were false.
- redwood 5y agoBy relational data do you mean data that has no nesting or arrays? Or data that you always want to query with a join? Something else?
- marcosdumay 5y agoThat that you would want to query with a join and have invariants that spread through those places you would want to join. Just keeping invariants of any kind is already non-trivial and will probably break at some point in a long lived system.
- redwood 5y agoI see so reference data that you want included in an object for which you're willing to pay the performance overhead of a join rather than denormalize across many object representions in your database. This model has some downsides when it comes to reasoning about scale and denormalization isn't necessarily a consistency quagmire when you can use transactions to keep multiple objects in sync. More generally you can absolutely do this types of queries in modern data systems whether or not they are "relational".
- marcosdumay 5y agoYeah, I guess I should retract my claim that people aren't claiming it's useful for relational data anymore. Anyway, I was focusing on invariants. But yes, destroying your performance every time you need an atomic change or joining values also makes it bad for relational data. That doesn't mean it's useless, just that it should not be used on the most common problem people have with their data.
- HideousKojima 5y agoPostgres literally beats MongoDB at JSON in benchmarks. Y'know, the thing that's supposed to be Mongo's bread and butter?
- jd_mongodb 5y agoWhich benchmark is that?
- HideousKojima 5y agohttps://www.enterprisedb.com/news/new-benchmarks-show-postgres-dominating-mongodb-varied-workloads https://www.enterprisedb.com/news/new-benchmarks-show-postgr...
- ghartnett 5y agoUnfortunately that benchmark was very inaccurate. They tuned the postgres configuration and didn't tune MongoDB. They also used an unsupported, experimental driver without connection pooling on MongoDB. For example: they measured Query B execution time on postgres: 41m3s, mongodb: 1h13m3s. When MongoDB measured Query B with a supported driver, the execution time was only 3m30s more than 10x faster than postgres! You'll find details here: https://www.mongodb.com/blog/post/benchmarking-do-it-right-or-dont-do-it-at-all https://www.mongodb.com/blog/post/benchmarking-do-it-right-o...
- gqewogpdqa 5y agoThanks for that info. Statistics, misunderstandings, lies, benchmarks, database benchmarks...
- toqy 5y agoMongodb was a lot easier to manipulate json in for a while vs postgres, but once postgres got json path support it evened out a bit imo. Say you have some json and nested in it somewhere is an array of objects, and you want to just map over that and update those objects. I was writing a migration to do that in Postgres <11 once and it was not fun to try and figure out how to do it. I haven't worked with Mongo in years though, so no clue how it has evolved since like 2015.