4 ms·
I once inherited a medium size python service and small front end at work that was primarily developed by someone that was super into Haskell. He chose to use m
by toqy 5y ago
I once inherited a medium size python service and small front end at work that was primarily developed by someone that was super into Haskell. He chose to use mongodb and built a lot of functionality around the constraint that he didn't know what an index was.
I'm very thankful his manager didn't let him write it in Haskell. Now he's where he belongs back in academia doing NLP research.
- benreesman 5y agoIn fairness, enthusiasts from lots of language communities got duped into using MongoDB.
- computerliker69 5y agoWhy 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.
- Tainnor 5y ago> He chose to use mongodb [...] I find it rather surprising that somebody who uses Haskell, i.e. clearly sees the value of types as an aid for reasoning about programs, would default to using a schemaless database which gives you essentially zero ways to reason about your data. It makes much more sense coming from someone who doesn't really like static typing and so prefers run-time, informal reasoning.
- toqy 5y agoHe was using python 2.7 so he would have lost the type safety after he fetched the data anyway
- Tainnor 5y agoThat's not the same thing. There's value in a schema even in a dynamically typed language. For example, if you have a bug in your codebase due to e.g. a runtime type error, you can generally troubleshoot and fix it, but if your data is in an inconsistent state, it may be impossible to fully recover.