Re:3 reasons to use MongoDB
by houseabsolute on Thursday September 09, 2010 @01:08PM
(#1676034)
> 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.
#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"
Re:3 reasons to use MongoDB
by mark_l_watson on Thursday September 09, 2010 @03:50PM
(#1676664)
re: 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.
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.