回到顶部 发表评论 网友评论，共 14 条

• 1楼：tony_jane 发表于 2012-08-29 21:48 回复此评论 好像已经 拆掉了 全家锁了

• 2楼：NDZhuangy 发表于 2012-08-30 08:07 回复此评论 引用来自“tony_jane”的评论 好像已经 拆掉了 全家锁了 好像是，改成了collection level lock

• 3楼：LinkerLin 发表于 2012-08-30 10:04 回复此评论 引用来自“NDZhuangy”的评论 引用来自“tony_jane”的评论 好像已经 拆掉了 全家锁了 好像是，改成了collection level lock mongodb的js引擎还是比较慢。

• 4楼：tony_jane 发表于 2012-08-30 11:00 回复此评论 是 db level lock 据说 collection level lock 要到 2.4

• 5楼：shol 发表于 2012-08-30 12:16 回复此评论 还是不太敢用，总觉得使用内存映射文件不保险，这种方法真偷懒，把责任都推给操作系统了

• 6楼：树相马 发表于 2012-08-30 15:02 回复此评论 引用来自“shol”的评论 还是不太敢用，总觉得使用内存映射文件不保险，这种方法真偷懒，把责任都推给操作系统了 说不定系统比数据库处理更好

• 7楼：hokim 发表于 2012-08-30 17:42 回复此评论 引用来自“tony_jane”的评论 是 db level lock 据说 collection level lock 要到 2.4 哎，盼星星盼月亮啊。。。

• 8楼：zhaoyou 发表于 2012-08-30 22:23 回复此评论 引用来自“hokim”的评论 引用来自“tony_jane”的评论 是 db level lock 据说 collection level lock 要到 2.4 哎，盼星星盼月亮啊。。。 system level lock, 现有的实现，给生产环境带来了哪行问题呢？

• 9楼：NDZhuangy 发表于 2012-08-31 08:09 回复此评论 引用来自“shol”的评论 还是不太敢用，总觉得使用内存映射文件不保险，这种方法真偷懒，把责任都推给操作系统了 确实是比较偷懒的一种做法，但设计中也体现了了缓存重建服务的思想。。。

• 10楼：阿喀琉斯之盾 发表于 2012-08-31 15:36 回复此评论 引用来自“LinkerLin”的评论 引用来自“NDZhuangy”的评论 引用来自“tony_jane”的评论 好像已经 拆掉了 全家锁了 好像是，改成了collection level lock mongodb的js引擎还是比较慢。 可以用v8引擎，增速不少

• 11楼：蝙蝠 发表于 2012-09-01 10:44 回复此评论 2.2.0 较之前版本，有什么新特性？

• 12楼：刘海洋2 发表于 2012-09-02 01:55 回复此评论 mysql + memcache吧, 新项目用mongodb的后悔中。

• 13楼：郑树新 发表于 2012-09-02 20:52 回复此评论 引用来自“shol”的评论 还是不太敢用，总觉得使用内存映射文件不保险，这种方法真偷懒，把责任都推给操作系统了 这种方式确实太偷懒，而且极可能在某种条件对于整体性能是致命的，可谓是 mongodb最大的设计弊端

• 14楼：hokim 发表于 2012-09-05 12:38 回复此评论 引用来自“zhaoyou”的评论 引用来自“hokim”的评论 引用来自“tony_jane”的评论 是 db level lock 据说 collection level lock 要到 2.4 哎，盼星星盼月亮啊。。。 system level lock, 现有的实现，给生产环境带来了哪行问题呢？ 那就像。。你上厕所的时候不能同时看报纸了，郁闷不？