5 ms·

This is something you heard from people who never really used it I used it at a previous job. Project to move a multi-tera dataset from an Oracle box (24 CPUs,

by gaius 9y ago

This is something you heard from people who never really used it I used it at a previous job. Project to move a multi-tera dataset from an Oracle box (24 CPUs, 24G RAM, SAN) to a MongoDB cluster (10 boxes, each with 48 cores, 96G RAM and internal SSD). MongoDB couldn't perform for shit, and it couldn't stay up in a usable state for more than a few hours at a time. This is with 20x the processors and 40x the memory of the system it was replacing. It's a complete joke of a product, sold on the basis of outright lies as far as what they told us and what it could actually do. Having been that badly burned I consider it an act of selfless public service to warn people off it. If you're just using it for a personal blog that gets 10 views a day, sure it might be barely adequate for that. But I'd still use Postgres.

threeseed 9y ago
See this is the sort of crazy things I used to see people do and wonder why they had problems. MongoDB is a document database. You can't just take relational database tables, move them across and expect it to behave the same. And frankly I don't feel sympathy for bad engineering practice. You don't do system migrations without fully testing and understanding all of the systems. But for those of us that had document orientated data models it allowed for performance that was orders of magnitude faster than any SQL database.
- btilly 9y ago
  If you never tracked what happened in production, it may have worked most of the time well enough that you never saw how bad it was. But read https://aphyr.com/posts/284-call-me-maybe-mongodb https://aphyr.com/posts/284-call-me-maybe-mongodb and https://aphyr.com/posts/284-call-me-maybe-mongodb https://aphyr.com/posts/284-call-me-maybe-mongodb for an idea of how the promises in MongoDB documentation compared to the reality of the software under stress. And it wasn't just hypothetical either - there are plenty of horror stories floating around from people who ran into those problems in production for uses cases that were supposed to be a fit for MongoDB. And the performance argument didn't hold water either. As benchmarks like https://www.enterprisedb.com/node/3441 https://www.enterprisedb.com/node/3441 showed, decent relational databases consistently beat MongoDB on the same hardware. Yes, lots of people rewrote bad relational models and saw performance improve. But apples to apples, writing an application against a relational databases in the same way you would against MongoDB resulted in a win for the relational database. So yes, there were lots of people saying exactly what you are saying now. But the ones who actually tested their systems and ran performance tests came to a very, very different conclusion.
  - metheus 9y ago
    The EnterpriseDB benchmark is just a hit piece. See https://newbiedba.wordpress.com/2017/05/26/thoughts-on-postgresql-json-vs-mongodb-json-performance/ https://newbiedba.wordpress.com/2017/05/26/thoughts-on-postg...
    - btilly 9y ago
      From your link, go to https://newbiedba.wordpress.com/2017/11/27/thoughts-on-postgresql-json-vs-mongodb-json-performance-part-iii-final/ https://newbiedba.wordpress.com/2017/11/27/thoughts-on-postg... for the followup after he wrote those benchmarks. When he ran his benchmarks, he indeed got better throughput on MongoDB. But the 99% performance was massively worse - in fact slow enough to be unacceptable. To an extent that he concluded that you'd be better off using PostgreSQL. And he's right. As pages like http://latencytipoftheday.blogspot.com/2014/06/latencytipoftheday-most-page-loads.html http://latencytipoftheday.blogspot.com/2014/06/latencytipoft... make clear, we have a lot of calls back to the application happening. Users will notice the occasional slow load surprisingly quickly, and it is worth a lot to get rid of them. So even your chosen source agrees. A relational database is not orders of magnitude slower. In fact, a relational database is probably a better fit.
    - takeda 9y ago
      > It is benchmarking PostgreSQL psql against MongoDB Javescript shell (SpiderMoney/v8). That’s not a very fair benchmark is it? Isn't javascript engine used whenever you interact with MongoDB?
      - metheus 9y ago
        Goodness, no.
  - threeseed 9y ago
    Again. I have been personally involved the deployment and support of MongoDB clusters for very large datasets at very large companies. It does work if you use it for the right task i.e. highly nestable data not relational data. And let's be clear that if MongoDB was unusable then the company wouldn't still be here as successful as they are. That EnterpriseDB link is completely ridiculous. Firstly, it predates WiredTiger which replaced the entire storage layer. Secondly, doing one for one comparisons with relational systems doesn't make sense. MongoDB is a document database. Compare it with other document databases.
- gaius 9y ago
  See this is the sort of crazy things I used to see people do and wonder why they had problems. Financial time series data is exactly one of the use cases Mongo claimed to be for. Seems you’re the one who can’t tell good engineering practice from bad. And yes, they also pitched themselves as a direct replacement for Oracle. That was highly disingenuous.

by gaius 9y ago

threeseed 9y ago

See this is the sort of crazy things I used to see people do and wonder why they had problems. MongoDB is a document database. You can't just take relational database tables, move them across and expect it to behave the same. And frankly I don't feel sympathy for bad engineering practice. You don't do system migrations without fully testing and understanding all of the systems. But for those of us that had document orientated data models it allowed for performance that was orders of magnitude faster than any SQL database.

btilly 9y ago
If you never tracked what happened in production, it may have worked most of the time well enough that you never saw how bad it was. But read https://aphyr.com/posts/284-call-me-maybe-mongodb https://aphyr.com/posts/284-call-me-maybe-mongodb and https://aphyr.com/posts/284-call-me-maybe-mongodb https://aphyr.com/posts/284-call-me-maybe-mongodb for an idea of how the promises in MongoDB documentation compared to the reality of the software under stress. And it wasn't just hypothetical either - there are plenty of horror stories floating around from people who ran into those problems in production for uses cases that were supposed to be a fit for MongoDB. And the performance argument didn't hold water either. As benchmarks like https://www.enterprisedb.com/node/3441 https://www.enterprisedb.com/node/3441 showed, decent relational databases consistently beat MongoDB on the same hardware. Yes, lots of people rewrote bad relational models and saw performance improve. But apples to apples, writing an application against a relational databases in the same way you would against MongoDB resulted in a win for the relational database. So yes, there were lots of people saying exactly what you are saying now. But the ones who actually tested their systems and ran performance tests came to a very, very different conclusion.
- metheus 9y ago
  The EnterpriseDB benchmark is just a hit piece. See https://newbiedba.wordpress.com/2017/05/26/thoughts-on-postgresql-json-vs-mongodb-json-performance/ https://newbiedba.wordpress.com/2017/05/26/thoughts-on-postg...
  - btilly 9y ago
    From your link, go to https://newbiedba.wordpress.com/2017/11/27/thoughts-on-postgresql-json-vs-mongodb-json-performance-part-iii-final/ https://newbiedba.wordpress.com/2017/11/27/thoughts-on-postg... for the followup after he wrote those benchmarks. When he ran his benchmarks, he indeed got better throughput on MongoDB. But the 99% performance was massively worse - in fact slow enough to be unacceptable. To an extent that he concluded that you'd be better off using PostgreSQL. And he's right. As pages like http://latencytipoftheday.blogspot.com/2014/06/latencytipoftheday-most-page-loads.html http://latencytipoftheday.blogspot.com/2014/06/latencytipoft... make clear, we have a lot of calls back to the application happening. Users will notice the occasional slow load surprisingly quickly, and it is worth a lot to get rid of them. So even your chosen source agrees. A relational database is not orders of magnitude slower. In fact, a relational database is probably a better fit.
  - takeda 9y ago
    > It is benchmarking PostgreSQL psql against MongoDB Javescript shell (SpiderMoney/v8). That’s not a very fair benchmark is it? Isn't javascript engine used whenever you interact with MongoDB?
    - metheus 9y ago
      Goodness, no.
- threeseed 9y ago
  Again. I have been personally involved the deployment and support of MongoDB clusters for very large datasets at very large companies. It does work if you use it for the right task i.e. highly nestable data not relational data. And let's be clear that if MongoDB was unusable then the company wouldn't still be here as successful as they are. That EnterpriseDB link is completely ridiculous. Firstly, it predates WiredTiger which replaced the entire storage layer. Secondly, doing one for one comparisons with relational systems doesn't make sense. MongoDB is a document database. Compare it with other document databases.
gaius 9y ago
See this is the sort of crazy things I used to see people do and wonder why they had problems. Financial time series data is exactly one of the use cases Mongo claimed to be for. Seems you’re the one who can’t tell good engineering practice from bad. And yes, they also pitched themselves as a direct replacement for Oracle. That was highly disingenuous.