3 ms·
we also need the datastore to be highly available and limit the risk of data loss as much as possible: MongoDB has this area covered really well Ahem, don't wa
by moe 17y ago
we also need the datastore to be highly available and limit the risk of data loss as much as possible: MongoDB has this area covered really well
Ahem, don't want to rain on anyone's parade but I'd be very careful with such claims (which the mongo guys don't make!). The risk of data-loss is pretty high with mongo (when compared to a traditional RDBMS) as there are no defined sync points or a WAL - it only syncs to disk on shutdown. That means when your machine crashes you're almost guaranteed to lose the last n changes where n can be a very large figure depending on your usage.
In reality that means you can only rely on the contents of your last mongodump to be truly persisted. Everything else is to be considered volatile.
- DEinspanjer 17y agoI'd also question the validity of claiming limited risk of data loss when using sharding considering it is still considered alpha although I know for a fact that 10gen is kicking butt to try to make it certified production worthy ASAP.
- moe 17y agoYes, I didn't mean to narrow their achievement. MongoDB is shaping up amazingly and I can see it becoming the MySQL of the k/v world within a year. Just as of today I'd still refrain from using it for mission critical stuff. Let it collect a few more battle scars before betting your money on it.
- stingraycharles 17y agoYou are correct: a single server indeed has a high risk of losing data for the reasons you describe. I was talking about replication: by making sure all data is replicated, for example, 4 times across 2 datacenters, you limit that risk a lot. There is a small timespan between writing data and all replicas picking it up, but if you make sure your servers aren't overloaded, this usually is very small. Having said that, I agree that there is room for improvement, for example using WAL and sync points like you describe.