I agree largely with this post. I'm tired of hearing the same arguments the author has. This technology we use is hardly infallible and as programmers and system administrators of these systems the defects should be obvious! Yet somehow people still think that the "clueless users" are to blame for these "defects."<p>Sure, we all know the saying about assumptions. But why are we at a point where it's cool to use a data persistance layer that assumes it doesn't have to live up to any of those assumptions? It's why we have things like ACID, the LSB, etc. Contracts about how these systems should work for the end user.<p>It's hard to get all that stuff right off the bat, sure. But losing the entire database when a few bytes land in the wrong place? Yikes. Hardly something I'd trust real data to.<p>This stuff can always get better. Of course the solution as pointed out is tried and true. Glad to see that the developers aren't covering their ears...
I read once that every developer ought to use 'kill -9' as their method of stopping services they are writing, then ensure that doing so never causes a problem. Even if you can keep people from executing 'kill -9' (hint: you can't), there are always cases that you can't control that can stop a box in its tracks. By developing explicitly for this, you save you and your customer a lot of pain.<p>Honestly, I would never use a database that doesn't make safeguarding my data as its number one priority. Even if I'm just dumping logs in it, the time I really need to know what's going on is likely the time those safeguards are put to the test.
This is exciting. MongoDB (and the suite of libraries building up around it) has made prototyping web applications an order of magnitude easier than using SQL. Lack of single-server durability, however, is a showstopper in production, before you've grown enough to justify scaling the database beyond one machine.<p>In my case, that meant going back to MySQL once our schema was finalized (sadly). Looks like that won't be necessary in the not-so-near future, which means MongoDB is usable in new projects without worrying about replication before otherwise necessary.
I'm pleased Mongo is getting single server durability. I have never understood why it got so popular without this feature. I'd love to know why people choose Mongo over say, Riak, or CouchDB, as the majority of projects don't need more than one server.
I am never sure what niche MongoDB is supposed to fill.<p>If I want a large cluster to handle "big data" Riak or Cassandra seem to fit the bill better.<p>If I want speed Redis is great.<p>If I want a schema-less SQL-like (but not SQL) database, MongoDB?