using other words:

does the one-write-lock-per-database policy (it's not a "bug" but a "feature" by design) affect contention making its usage in certain kind of workloads less then optimal?

if not how do you maintain that kind of workload?

would you use an async-write-queue at the application level? (roll-backing would be difficult with such a structure though)


MongoDB can survive high concurrency writes, so long as you engineer for it.

  • INSERTs are about the same size.
  • Very little UPDATE going on.
  • Shard to add write concurrency scalability.

The things that will kill you on write scalability will be updates that go past the built in padding factor, as that triggers a double write as the block is relocated to a larger free spot. If your document sizes are within a narrow range and updates don't change the size much, it can scale quite far.

| improve this answer | |
  • Thank you for your reply, it is the kind of answer I wanted, I will have to go more in detail on how updates work. Sorry but I can't upvote. – Antonio Dell'Elce Nov 27 '13 at 12:37

Not the answer you're looking for? Browse other questions tagged or ask your own question.