Using a second database for write heavy data in MongoDB

As the title suggests, is using a second database for write heavy data a good option in Mongo? For example, for votes (voting on objects like stack overflow questions) and page views information would it make sense to keep a second database with documents that reference objects in the first database?

Or would it make more sense to just put everything in a single开发者_如何学运维 database?

I know that for writes that don't need to be immediately shown to the user (like writing and updating a pageview count) many applications write the data to a intermediate layer like memcache and then bulk update the database on an interval. I'd like to avoid creating a system like this for now.

---

If with "second database" you mean a second mongod process to reduce write lock contention then yes, your solution will help. Note that sharding basically offers additional write (and read) throughput as well but is much more flexible and application agnostic.

If you mean creating a second database on your single mongod process then that will not help at all. Mongo write locks are mongod process wide.

UPDATE : As of MongoDB 2.2 write locking happens at database rather than process level and this would result in write lock contention being reduced if you use multiple logical databases.

---

Mongod in 2.0 has what is called lock with yielding, meaning it looks if what you update is in memory and there is no page fault will update immediately if not will yield the lock. By design one mongod has a global lock, the only way to work around it is to shard hence you will have multiple mongod, however this introduces a new level of complexity. IF you manage to have all the active data set in memory you shall be fine but it depends entirely by your application needs and the data set. Be aware that is not a silver bullet for making mongo heavy writes.

I suggest you benchmark your application before you go to production.