4 ms·
Three warnings when using mongodb. None of these are enough to say not to use it, but they're things you need to watch out for: 1. Don't run javascript on a pr
by rabidsnail 16y ago
Three warnings when using mongodb. None of these are enough to say not to use it, but they're things you need to watch out for:
1. Don't run javascript on a production db node. db.eval locks the node it's running on until it finishes, so the performance of that node will go down the tubes. Mapreduce is less bad in this regard because it does yield, but it does so too infrequently. If you want to use mongo's built-in javascript interpreter for anything other than development and administration, set up a slave to run your scripts on.
2. Don't use 1.6.1. If you're using 1.6.1 right now, upgrade to 1.6.2. 1.6.1 has a nasty crashing bug that had my mongo node going down about once a day and not coming up without running --repair.
3. Evaluate how much data loss costs you. Mongo stages writes in memory, and so if the db crashes hard it's likely that there will be some data that hasn't made it to disk yet. If you're building a social network the cost of some potential data loss is probably much less than the savings in hardare, admin costs, development costs, etc. But if you're a payment processor or a gambling site, stick with postgres.
- houseabsolute 16y ago> If you're building a social network the cost of some potential data loss is probably much less than the savings in hardare, admin costs, development costs, etc. This also depends on what is being stored. I would be unhappy if Facebook lost any of my data, and my understanding is that they use safe storage mechanisms (ones where the commit goes all the way to disk before returning) for everything except transient views like the news feed and search. Also, I don't think it's clear that MongoDB has significantly improved either admin or development costs over its safe competition, so we probably only need to look at performance wins.
- angilly 16y ago#3: You can force flush any write that needs to go straight to disk. insertion & update commands (at least in JS and Ruby) take an argument allowing you specify "safe_mode: true"
- mark_l_watson 16y agore: potential data loss: I typically run 1 master and one read-only slave on another server. Replication of writes from the master to the read-only slave is very fast. Sure, there is a window for data loss, but for crucial data use a relational database. Also, it is great to be able to really load down the read-only slave for analytics, etc.