| [2] When you look at [1] you'll notice that these exact problems are still prevalent. I'd in fact be curious how exactly did you work around the sharding issues at 4square? Remember I replied to someone who claimed it takes "no engineering effort" to scale MongoDB. That's not only obviously false, but last time I tried the sharding was so brittle that recommending it as a scaling path would border on malice. I ran a few rather simple tests for common scenarios; high write-load, flapping mongod, kill -9/rejoin, temporary network partition, deliberate memory starvation. MongoDB failed terribly in every single one of them. The behavior would range from the cluster becoming unresponsive (temporary or terminally), over data-corruption (collection disappears or inaccessible with error), silent data-corruption (inconsistent query-results), to severe cluster imbalance, to crashes (segfault, "shard version not ok" and a whole range of other messages). I didn't try very hard, it was terribly easy to trigger pathological behavior. My take-home was that I most certainly don't want to be around when a large MongoDB deployment fails in production. As such I'm a little disconcerted every time the Mongo scalability myth is reinstated on HN, usually by people who haven't even tried it beyond a single instance on their laptop. |
What other databases did you go to the same lengths to make fail which handled them gracefully?