Live data from Hacker News

New MongoDB alerts and advisories page

alerts.mongodb.org

11–13 of 13 posts

Re: New MongoDB alerts and advisories page

#12
post #9
post #7

Earlier quoted context omitted.

You can read concurrently, but the write lock will block read locks. http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...

If you have a lot of writes, this is a KILLER. You need to be very careful here. Note, even with Read-Slaves, you are STILL blocked, since each write replicates to each Read-Slave, and counts as a blocking-write on that slave while it replicates in. We dramatically increased application performance when we refactored to remove a lot of little writes for things like caching, and moved them to memcache.

Does this make mongo a bad choice for storing real time statistics?

Re: New MongoDB alerts and advisories page

#13
post #12
post #9

Earlier quoted context omitted.

If you have a lot of writes, this is a KILLER. You need to be very careful here. Note, even with Read-Slaves, you are STILL blocked, since each write replicates to each Read-Slave, and counts as a blocking-write on that slave while it replicates in. We dramatically increased application performance when we refactored to remove a lot of little writes for things like caching, and moved them to memcache.

Does this make mongo a bad choice for storing real time statistics?

You always have to benchmark for your own use-case.

This is even more true for mongo than for other databases because mongo doesn't degrade very well; when you overload it with writes it will effectively grind to a halt.

This is documented e.g. in the clustrix benchmark: http://sergei.clustrix.com/2011/01/mongodb-vs-clustrix-compa...

Post reply on HN