|
If you were using MongoDB prior to 1.8 on a single server, it's your own fault if you lost data. To me, replication as a means to provide durability never seemed crazy. It just means that you have to understand what's going on. Well, except for that thing where the replication decided that the empty set was the most recent and blew everything else away. And those cases where keys went away. Losing data, particularly when the server goes down, is fine. Even not writing data isn't terrible, though his points about not knowing whether it has been written in case of failure are really good ones. But corrupting data and then replicating that corrupted data is really, really bad. Often unfixably bad. They didn't act responsibly, and now they aren't being accountable. For the complaints about the default write stuff, sure. For everything else... Dunno. He brought up a lot of real, actual issues which were not documented MongoDB behavior. Yes, there's also a fair bit of complaining about the documented bits, and sure, boo-hoo, whatever. But the idea that 10gen is shipping stuff with serious data integrity bugs, and doing so knowing, doesn't seem out of line here. And while MySQL also has some bad stuff, sure, it has nothing like as many data integrity bugs as MongoDB. And I say all of this as a serious fan of MongoDB. |