| I'm the author of the blog post, and just saw this resubmission on HN. Just wanted to quickly touch upon some of these points: * "It lies." Mongo lied at the time I wrote the post, and while the default has been changed, the "this entire point is no longer a concern" seems overly optimistic. See here for further details where successful writes are lost: http://aphyr.com/posts/284-call-me-maybe-mongodb * "It's slow." We have indeed benchmarked Mongo's behavior, and, even though developers give up on consistency and fault-tolerance by using MongoDB, they don't get high performance in return for their tradeoff:
http://hyperdex.org/performance/ * "It doesn't work pipelined / it doesn't work multithreaded." I don't quite see a correctness argument here. I read through the sources of the Java driver at the time I wrote the blog post. If you follow the pattern described in the link you provided (java-concurrency), you will find that thread A can issue getLastError and receive results for thread B's operations. That is broken. The word "thread-safe" does not mean what you think it means. "People use it without ill effects" isn't as strong an argument as "I read through the code and it looks broken." Further, when 10gen responded to this blog post, they were unable to refute the technical point:
http://hackingdistributed.com/2013/02/07/10gen-response/ * "WriteConcerns are broken." Check out the Jepsen test, the last subsection: http://aphyr.com/posts/284-call-me-maybe-mongodb Agreed that Mongo's simplicity is a big draw for many developers new to NoSQL. Sadly, the system provides very weak properties, and applications built on top end up having even weaker properties still. |