2013年12月21日 星期六 18:04
根据官方文档(http://docs.mongodb.org/manual/faq/concurrency/):
MongoDB uses a readers-writer lock that allows concurrent reads access to a database but gives exclusive access to a single write operation.
When a read lock exists, many read operations may use this lock. However, when a write lock exists, a single write operation holds the lock exclusively, and no other read or write operations may share the lock.
Locks are “writer greedy,” which means writes have preference over reads. When both a read and write are waiting for a lock, MongoDB grants the lock to the write.
MongoDB使用了粒度非常粗(database级别)的读写锁,多个读操作可以并发执行,但如果有写操作,就需要独占整个database,导致其他线程既不能读也不能写,并且写操作的优先级更高。
可见MongoDB的读写并发能力确实不如人意,习惯了InnoDB的并发读写表现,再来看MongoDB,简直不忍直视。
在MongoDB的官方白皮书中特别指出:
MongoDB performs best when the working set fits in RAM. Sufficient RAM is the most important factor for hardware; other optimizations may not significantly improve the performance of the system if there is insufficient RAM. If your working set exceeds the RAM of a single server, consider sharding your system across multiple servers.
也就是说,一定不要让MongoDB的常用数据集大于内存,否则性能表现会急剧下降。
MongoDB的一些设计还是非常先进和好用的,比如Replica Set,比如Auto Sharding等等,但存储引擎是其重要缺陷。
这就让我我不得不再推广一下TokuMX,TokuMX的锁粒度是Document级别,在性能表现方面秒杀MongoDB。具体性能对比可以参考:
http://www.tokutek.com/resources/benchmark-results/tokumx-benchmark-hdd/
Zeuux © 2024
京ICP备05028076号