Hacker News Reader

Comment by threeseed | Hacker News Reader

You know what I don't like. People who complain about technologies they've never used.

1. This was NEVER an issue for 99.999% of people. The drivers all had the default set to FSYNC_SAFE.

2. It DOES scale the way it claims. It just doesn't have unlimited scalability and guess what no product does.

1. So then the problem they had was they didn't get the performance they expected since the benchmarks were done with different settings to juice the numbers? There is no upside to arguing this one, Mongo loses one way or the other. Can't play them both.

2. I haven't seen anyone say that Mongo scales in an unlimited fashion. You said that. I think what they might be saying is that it doesn't scale well enough to pay for the trade-offs from using it. If you aren't running a system that can be composed of somewhat-interrelated documents, you're gonna have a bad time.

All the drivers default to FSYNC_SAFE? Maybe the Java one didn't get the memo. It's set to ACKNOWLEDGED by default.

https://github.com/mongodb/mongo-java-driver/blob/master/src...

I like Mongo. And until I really learned about it, I got bitten by the default a few times. Personally I use REPLICA_ACKNOWLEDGED when running in a cluster and FSYNC when writing to a single node.

At the time when the big uproar of the lack of fsyncing by default the Java driver had it set as FSYNC_SAFE (there was no ACKNOWLEDGED).

2 is wrong. Mongos shits all over itself after only a few nodes and moderate traffic. It's balancing is incredibly broken and will kill a small cluster very quickly.

Source: tried to use it at scale

The balancing is broken if you use an inappropriate sharding key. Which is no different to every other system.

And I've used it under very high load with zero problems other than data model changes.

I think we had one of the larger mongo installs around, so you just might not have been at the scale to see these issues.

Reply on news.ycombinator.com