+
 新版
2012-09-05 12:38

引用来自“zhaoyou”的评论

引用来自“hokim”的评论

引用来自“tony_jane”的评论

是 db level lock 据说 collection level lock 要到 2.4

哎,盼星星盼月亮啊。。。

system level lock, 现有的实现,给生产环境带来了哪行问题呢?

那就像。。你上厕所的时候不能同时看报纸了,郁闷不?
2012-09-02 20:52

引用来自“shol”的评论

还是不太敢用,总觉得使用内存映射文件不保险,这种方法真偷懒,把责任都推给操作系统了

这种方式确实太偷懒,而且极可能在某种条件对于整体性能是致命的,可谓是 mongodb最大的设计弊端
2012-09-02 01:55
mysql + memcache吧, 新项目用mongodb的后悔中。
2012-09-01 10:44
2.2.0 较之前版本,有什么新特性?
2012-08-31 15:36

引用来自“LinkerLin”的评论

引用来自“NDZhuangy”的评论

引用来自“tony_jane”的评论

好像已经 拆掉了 全家锁了

好像是,改成了collection level lock

mongodb的js引擎还是比较慢。

可以用v8引擎,增速不少
2012-08-31 08:09

引用来自“shol”的评论

还是不太敢用,总觉得使用内存映射文件不保险,这种方法真偷懒,把责任都推给操作系统了

确实是比较偷懒的一种做法,但设计中也体现了了缓存重建服务的思想。。。
2012-08-30 22:23

引用来自“hokim”的评论

引用来自“tony_jane”的评论

是 db level lock 据说 collection level lock 要到 2.4

哎,盼星星盼月亮啊。。。

system level lock, 现有的实现,给生产环境带来了哪行问题呢?
2012-08-30 17:42

引用来自“tony_jane”的评论

是 db level lock 据说 collection level lock 要到 2.4

哎,盼星星盼月亮啊。。。
2012-08-30 15:02

引用来自“shol”的评论

还是不太敢用,总觉得使用内存映射文件不保险,这种方法真偷懒,把责任都推给操作系统了

说不定系统比数据库处理更好
2012-08-30 12:16
还是不太敢用,总觉得使用内存映射文件不保险,这种方法真偷懒,把责任都推给操作系统了
2012-08-30 11:00
是 db level lock 据说 collection level lock 要到 2.4
2012-08-30 10:04

引用来自“NDZhuangy”的评论

引用来自“tony_jane”的评论

好像已经 拆掉了 全家锁了

好像是,改成了collection level lock

mongodb的js引擎还是比较慢。
2012-08-30 08:07

引用来自“tony_jane”的评论

好像已经 拆掉了 全家锁了

好像是,改成了collection level lock
2012-08-29 21:48
好像已经 拆掉了 全家锁了
回复 @
{{emojiItem.symbol}}
返回顶部
顶部