对MongoDB有所了解的人都知道,MongoDB有一个让人头疼的全局锁(读写锁,允许并发读,而写会阻塞所有的读写),要命的是这个锁不是表级的,不是库级的,而是整个Server级别的,这让人听起来是不是非常的蛋疼。 在2.0版本以前,这一问题一直没有得到解决,于是有人提出,在可预见某个update操作的记录可能在磁盘上时,为了减少写锁占用的时间,可以采 用先读后写的方式,通过先读一次,将要操作的记录加载到内存中,再进行内存中的update,这样写锁就不包括将数据从磁盘加载到内存的时间了。 在可预见数据冷热的情况下,这种操作能够有一定的效果,但是很明显,这种变态的方法不应该是一个终极解决方案。 值得庆幸的是,在2.0版本中,MongoDB宣称有很大程度的并发性能提升,而这一提升的基础正是解决了这个全局锁的问题。 解决的方法并不是通过减少锁粒度来解决,虽然collection级别的锁机制也正在开发中。(SERVER-1240) 解决方法是通过对一些可能造成长时间锁占用的操作进行锁抑制。比如和我们上面的方法类似,在进行update操作时,如果发现需要更新的记录在磁盘上,那么这个锁就不会一直占用,而是等到将数据从磁盘加载到内存后再添加写锁进行update。 而同理,对于其它一些可能耗时比较长的操作也可以采用类似的方法,通过将长时间占用的全局锁拆分成多个细粒度的小锁来使需要获取锁来进行的操作能够交错的执行,从而避免一夫当关万夫莫开的情况,主要包括下面一些操作:
出处: nosqlfan
mongodb,目前正在考虑试用,不过,这新出的玩意儿,不怎么好使也很正常。######这个锁不是表级的,不是库级的,而是整个Server级别的,这让人听起来是不是非常的蛋疼######mongodb的路还很长啊,测试了一周了,光是一个海量数据插入,就让人蛋疼。。。。######测试过千万级别的(约4000万)。没有问题。######几十万级和几百万级的好像还可以的吧......######我目前在测试亿级数据的存取,计划的压力大概是,每秒10000个1-50K的文件的插入,总容量大致44亿条,每天存储225G,读取90G 稍后把测试结果发布出来######關注你的測試結果啊,記住:你有一個觀眾啊
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。