If they are always under 16MB, you'll be fine, though if you could stream them out of GridFS using a chunked encoding or something like that, you might save a bit of RAM.

I guess it depends on what % of your writes were simply updating a boolean or integer value. My benchmark shows that simple updates like that don't affect query performance much. Writes that take longer probably have different performance characteristics, YMMV, etc.

Glad to help! 10gen actually has a policy of never sharing benchmarks so that explains why they never said anything.

There are a number of MongoDB shared hosts listed at http://www.mongodb.org/display/DOCS/Hosting+Center that you might want to check out.

MongoDB has single server durability since 1.8 with the journal. If you put the journal on an SSD, you can even get it almost for free performance-wise.

Yeah, I guess I should make the point that if you don't put the journal on SSD (and you only need a few gigs of SSD to journal terabytes of spinning disk storage), you will see significant slowdown.

You could say that about any database, though - nothing special about mongo's journaling that makes it "for free" wit h an SSD.

Writing does lock the database (or at least the shard), but if the page is in RAM, that means you're locked for the duration of a write to memory, which is inconsequential. The problem comes when you try to write to a page that's not resident. In that case, you can end up (worst case) having to write a dirty page to disk to free up a slot, load the page you want to write, and then write it.

This can be really time-consuming, so one "fix" is to retrieve a document before writing it (thus guaranteeing it will be resident in RAM). More recent versions of MongoDB (2.0 on IIRC) also try to yield the write lock before faulting on write to avoid this problem (though it doesn't work 100% of the time).

Oh, and one other thing to be aware of is that anything that uses the Javascript engine in MongoDB is going to use the spidermonkey global interpreter lock, so you probably want to avoid those things if performance is a concern ($where, .group(), .mapreduce(), etc.)

> This can be really time-consuming, so one "fix" is to retrieve a document before writing it (thus guaranteeing it will be resident in RAM).

On a high traffic site does this guarantee that it will be in RAM? Couldn't it get swapped out pretty easily if you have a lot of read traffic?

I guess on an extremely high traffic site running with a relatively small amount of RAM you could cycle through the whole LRU cache in the VM between operations, but I'd expect the probability to be vanishingly small.

It's worth noting that the Spidermonkey engine does not have a global interpreter lock, but it may be true that MongoDB uses SpiderMonkey in a way similar in effect.

True, but since the current version of SM that we use (1.7) isn't thread-safe all calls to it need to be inside of a mutex to prevent trashing global state. It is possible that with a switch to V8 or upgrade to the lastest SM (1.8.5?) it is possible to execute JS without a GIL, however that is something that will need extensive testing to make sure that it works properly.

PS - It is important to note that the jslock is completely separate from the dblock and it is rare to hold both simultaneously. This means that if you are running multiple Map Reduces, one can be fetching or writing data to the DB while the other is processing the objects in JS.

In your best and worst case scenarios for the lock you forgot that MongoDB will also need to write a journal entry by default (1.9.2+).

Writing to the journal is actually done outside of the write lock most of the time. It does hold a readlock, however as of 2.0 most commits will release the lock before doing any disk I/O.