3 ms·

At this point in time, making a statement about MongoDB on HN should almost be considered trolling. We already know about the short-comings of that code-base. I

by mack73 10y ago

At this point in time, making a statement about MongoDB on HN should almost be considered trolling. We already know about the short-comings of that code-base. It will work fine until it doesn't and you'll loose some of your data. Some folks are using it and enjoying it. Others aren't. "Your shouldn't use it" is like saying you shouldn't use javascript for things other than UI. Noone cares anymore.

brandur 10y ago
To be fair, I think your comment shows why this sort of post _can_ still be useful. You're very unlikely to lose data on a modern Mongo system using default configuration (their troubles with durability have largely been solved), but there are many other good reasons not to use it, and it's enlightening to read about and understand what they are.
- mack73 10y ago
  If "their troubles with durability have largely been solved" were true then I'm sure HN would be flooded with posts about "MongoDB solves durability with an entirely new architecture". I might be wrong here. How did they solve the "your data is lost when a disk fails"?
  - brandur 10y ago
    I'm talking about "durability" here in the context of the "D" in "ACID". Previously, Mongo had very serious problems in that are because its client would assume that any message sent to the outgoing socket buffer was persisted "well enough", which was an obvious untruth [1]. This was also one of the somewhat underhanded techniques they used to achieve their early benchmarks. As of version 3, they have defaulted their client's "write_concern" value to "1", which means that it will wait for confirmation from a replica set's primary before considering a value persisted [2]. This puts Mongo roughly on the same level as any other database in terms of durability guarantees. Disk failure is entirely tangential to your original premise that "Mongo loses data". I'm not getting into it, but there a variety of techniques that Mongo (and every other known database) can use to protect against that. [1] http://hackingdistributed.com/2013/01/29/mongo-ft/ http://hackingdistributed.com/2013/01/29/mongo-ft/ [2] https://docs.mongodb.com/manual/reference/write-concern/ https://docs.mongodb.com/manual/reference/write-concern/
    - mack73 10y ago
      MongoDB was initially designed to beat other nosql systems in benchmarks, is what I take away from reading about it. Someone took issue with that and wrote an article. "MongoDB lies" and "is slow" were some of the claims made from your link #1. Now that these issues are gone, by having reasonable default settings for write concern and journaling, how well does MongoDB do in the benchmarks today? Rewgarding default settings, how is "w=1" considered a safe write? The data exists in a single node and has not been propagated. If you only have one node then I guess it's as safe as can be. Is MongoDB suitable as a single node installation though? I would have thought "w=2" or "w=majority" would be the "safe" setting.
      - brandur 10y ago
        > Now that these issues are gone, by having reasonable default settings for write concern and journaling, how well does MongoDB do in the benchmarks today? Reports differ by benchmark, but the answer can be summarized as "not well". From [1] above: > MongoDB is now a lot slower compared to v2.0. On the industry-standard YCSB benchmark, MongoDB used to be competitive with Cassandra, as seen in the performance measurements we did when benchmarking HyperDex. Ever since the change, MongoDB can no longer finish the entire benchmark suite in the time allotted. I'm not sure I'd call what they were doing "cheating" per se because I honestly don't think they understood what they were doing, but it's fair to say that even if performance has improved since those benchmarks were run, Mongo definitely doesn't have any secret sauce.

by mack73 10y ago

brandur 10y ago

To be fair, I think your comment shows why this sort of post _can_ still be useful. You're very unlikely to lose data on a modern Mongo system using default configuration (their troubles with durability have largely been solved), but there are many other good reasons not to use it, and it's enlightening to read about and understand what they are.

mack73 10y ago
If "their troubles with durability have largely been solved" were true then I'm sure HN would be flooded with posts about "MongoDB solves durability with an entirely new architecture". I might be wrong here. How did they solve the "your data is lost when a disk fails"?
- brandur 10y ago
  I'm talking about "durability" here in the context of the "D" in "ACID". Previously, Mongo had very serious problems in that are because its client would assume that any message sent to the outgoing socket buffer was persisted "well enough", which was an obvious untruth [1]. This was also one of the somewhat underhanded techniques they used to achieve their early benchmarks. As of version 3, they have defaulted their client's "write_concern" value to "1", which means that it will wait for confirmation from a replica set's primary before considering a value persisted [2]. This puts Mongo roughly on the same level as any other database in terms of durability guarantees. Disk failure is entirely tangential to your original premise that "Mongo loses data". I'm not getting into it, but there a variety of techniques that Mongo (and every other known database) can use to protect against that. [1] http://hackingdistributed.com/2013/01/29/mongo-ft/ http://hackingdistributed.com/2013/01/29/mongo-ft/ [2] https://docs.mongodb.com/manual/reference/write-concern/ https://docs.mongodb.com/manual/reference/write-concern/
  - mack73 10y ago
    MongoDB was initially designed to beat other nosql systems in benchmarks, is what I take away from reading about it. Someone took issue with that and wrote an article. "MongoDB lies" and "is slow" were some of the claims made from your link #1. Now that these issues are gone, by having reasonable default settings for write concern and journaling, how well does MongoDB do in the benchmarks today? Rewgarding default settings, how is "w=1" considered a safe write? The data exists in a single node and has not been propagated. If you only have one node then I guess it's as safe as can be. Is MongoDB suitable as a single node installation though? I would have thought "w=2" or "w=majority" would be the "safe" setting.
    - brandur 10y ago
      > Now that these issues are gone, by having reasonable default settings for write concern and journaling, how well does MongoDB do in the benchmarks today? Reports differ by benchmark, but the answer can be summarized as "not well". From [1] above: > MongoDB is now a lot slower compared to v2.0. On the industry-standard YCSB benchmark, MongoDB used to be competitive with Cassandra, as seen in the performance measurements we did when benchmarking HyperDex. Ever since the change, MongoDB can no longer finish the entire benchmark suite in the time allotted. I'm not sure I'd call what they were doing "cheating" per se because I honestly don't think they understood what they were doing, but it's fair to say that even if performance has improved since those benchmarks were run, Mongo definitely doesn't have any secret sauce.