14 comments

[ 2.9 ms ] story [ 43.4 ms ] thread
Just wonder who have hosted data that is larger than RAM with MongoDB, and what's the performance characteristics?
As long as your working set of data and indexes fit in RAM then it should perform well.
I have not used mongodb for anything sensitive (just log and test analysis), but my experience is that while at least the index stays in ram, things go relatively well, and degrade much worse than mysql once it does not.
This happened to Foursquare, and resulted in a lengthy outage. See http://groups.google.com/group/mongodb-user/browse_thread/th... for the full details (including why recovery took so long).
FWIW, Foursquare's situation was kind of unique. They have a need for all of their data to be in RAM. In most applications, you can define a working set of data. As long as you can keep that working set and indexes in RAM, you'll be fine.
You could run into problems but one option to deal with this is to "scale out" to a larger number of machines and shard the data onto each separate machine (with their own RAM) as appose to one or two high RAM machines.
This bears repeating. Because MongoDB doesn't do joins, sharding is orders of magnitude easier than with an SQL system; if you run out of RAM, shard.
(comment deleted)
My experience with MongoDB (300GB database; most of which was insert-only, but some large chunk of it was being updated) under constant load was horrible: I would not go back there. I've since spent a lot of time learning more about PostgreSQL's implementation and figuring out how to tweak more performance out of it. At this point I no longer believe there is any benefit to using MongoDB at all.
This needs some serious proofreading.
At least a good spell check!
Sorry, it was posted before I actually finished due to a communication error. I tried to fix some of the problems & I apologize.
I graduated in 2010. I wonder how long it will be until they start teaching NoSQL in school.