3 ms·

Reminder: they shipped with the defaults which basically would throw the data over the wall and never acknowledge it back to the user (because speed and such).

by rdtsc 9y ago

Reminder: they shipped with the defaults which basically would throw the data over the wall and never acknowledge it back to the user (because speed and such). Interestingly enough it still called itself a database, and that right there is the power of marketing.

gaius 9y ago
And the dodgy benchmarks comparing their ability to write to memory with Postgres ability to write to disk! Fact: Postgres with its JSONB datatype is a better Mongo than Mongo...
- daenney 9y ago
  Source for that fact?
  - takeda 9y ago
    This is around the time JSONB was introduced[1]. There was also (not sure if still developed) an interface called ToroDB, which allows you to plug in a MongoDB application to store data in Postgres. The interface provides Mongo compatible layer and the application still thinks it talks with Mongo. Even with the extra translation layer, ToroDB was faster than original MongoDB[2]. [1] https://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality https://www.enterprisedb.com/postgres-plus-edb-blog/marc-lin... [2] https://www.slideshare.net/8kdata/torodb-internals-how-to-create-a-nosql-database-on-top-of-sql-55275036 https://www.slideshare.net/8kdata/torodb-internals-how-to-cr...
    - metheus 9y ago
      That EnterpriseDB benchmark is a comically inept 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...
- metheus 9y ago
  What you wrote isn't a fact, it's a claim, and a shoddy one at that. If you're basing it on anything other than hearsay, I'd love to see your proof.
nemild 9y ago
My own research doesn't back up that this "unsafe write" was done by 10gen for benchmarking reasons, but rather due to an early expected use case (from a footnote in part 1 of my series): Waiting for writes was off by default: > This "unchecked" type of write is just supposed to be for stuff like analytics or sensor data, when you're getting a zillion a second and don't really care [if] some get lost [or] if the server crashes. This was rarely the typical use case in most startups - even though the defaults were based on it for a long time. It’s unclear to me how long this was the top Google result, and it was earlier in Mongo’s life (2009). This may be one of the benchmarks that led to anger at competing NoSQL vendors - and seems to me like a mistake rather than a malevolent effort. https://www.nemil.com/mongo/1.html#fn2 https://www.nemil.com/mongo/1.html#fn2 _____________________ MongoDB's CTO has also mentioned that if he could go back and change anything it would be this early default, as his earliest customers valued it - but he quickly realized that it caused issues for others. (Throughout this series, my goal has been to be tough, but fair to both sides)
- concede_pluto 9y ago
  If your monitoring can't handle your what system is doing, aggregate locally until it can. Having systematically incorrect stats (because loss is correlated with load) is worse than having none.
- wmf 9y ago
  The real question is how many years they left the unsafe default after people pointed out that it was a problem.
  - nemild 9y ago
    It took a little while (say 1.5ish year from when they realized it was causing issues). According to MongoDB's CTO, this was because they couldn't quickly move their early users from the behavior they were used to.

by rdtsc 9y ago

gaius 9y ago

And the dodgy benchmarks comparing their ability to write to memory with Postgres ability to write to disk! Fact: Postgres with its JSONB datatype is a better Mongo than Mongo...

daenney 9y ago
Source for that fact?
- takeda 9y ago
  This is around the time JSONB was introduced[1]. There was also (not sure if still developed) an interface called ToroDB, which allows you to plug in a MongoDB application to store data in Postgres. The interface provides Mongo compatible layer and the application still thinks it talks with Mongo. Even with the extra translation layer, ToroDB was faster than original MongoDB[2]. [1] https://www.enterprisedb.com/postgres-plus-edb-blog/marc-linster/postgres-outperforms-mongodb-and-ushers-new-developer-reality https://www.enterprisedb.com/postgres-plus-edb-blog/marc-lin... [2] https://www.slideshare.net/8kdata/torodb-internals-how-to-create-a-nosql-database-on-top-of-sql-55275036 https://www.slideshare.net/8kdata/torodb-internals-how-to-cr...
  - metheus 9y ago
    That EnterpriseDB benchmark is a comically inept 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...
metheus 9y ago
What you wrote isn't a fact, it's a claim, and a shoddy one at that. If you're basing it on anything other than hearsay, I'd love to see your proof.

nemild 9y ago

My own research doesn't back up that this "unsafe write" was done by 10gen for benchmarking reasons, but rather due to an early expected use case (from a footnote in part 1 of my series): Waiting for writes was off by default: > This "unchecked" type of write is just supposed to be for stuff like analytics or sensor data, when you're getting a zillion a second and don't really care [if] some get lost [or] if the server crashes. This was rarely the typical use case in most startups - even though the defaults were based on it for a long time. It’s unclear to me how long this was the top Google result, and it was earlier in Mongo’s life (2009). This may be one of the benchmarks that led to anger at competing NoSQL vendors - and seems to me like a mistake rather than a malevolent effort. https://www.nemil.com/mongo/1.html#fn2 https://www.nemil.com/mongo/1.html#fn2 _____________________ MongoDB's CTO has also mentioned that if he could go back and change anything it would be this early default, as his earliest customers valued it - but he quickly realized that it caused issues for others. (Throughout this series, my goal has been to be tough, but fair to both sides)

concede_pluto 9y ago
If your monitoring can't handle your what system is doing, aggregate locally until it can. Having systematically incorrect stats (because loss is correlated with load) is worse than having none.
wmf 9y ago
The real question is how many years they left the unsafe default after people pointed out that it was a problem.
- nemild 9y ago
  It took a little while (say 1.5ish year from when they realized it was causing issues). According to MongoDB's CTO, this was because they couldn't quickly move their early users from the behavior they were used to.