控件中国网现已改版,您看到的是老版本网站的镜像,系统正在为您跳转到新网站首页,请稍候.......
中国最专业的商业控件资讯网产品咨询电话:023-67870900 023-67871946
产品咨询EMAIL:SALES@COMPONENTCN.COM

关于NoSQL的思考:为什么我们要优化存储的写性能

作者:佚名 出处:互联网 2010年10月18日 阅读:

 关于NoSQL的思考:为什么我们要优化存储的写性能

 
在NoSQL的许多产品中,我们通过benchmark可以看到的都是写性能极度提升,而读性能并没有太大的涨幅甚至相对传统RDBMS还有下降。比如Cassandra,MongoDB这两个NoSQL的杰出代表。究其原因,我们可能会想到是因为当前UGC模式已经发展到白热化,用户产生内容导致读写比已经接近或者说小于1:1。
 
但是我认为这绝不是个中真实原因。
 
1. 缓存导致存储的raw read效率不再重要
 
真实原因是我们对读的优化已经做得足够多了,数据存储我们使用Memcached,TokyoTyrant/TokyoCabinet等缓存存储,页面及文件缓存我们使用squid,nginx proxy_cache等存储,都可以达到非常好的读缓存效果,如果数据即时性要求不高,或者说缓存设计合理(读写皆缓存),缓存命中率会足够的高,因此我们无需再过分优化底层存储的raw read效率。
 
试想缓存层如果有高达99%以上的命中率,那么相对于raw read设备,我们的亿级的数据读取请求就轻松的变成百万级请求,上千并发轻松变成数十并发。当然,这需要我们的缓存层足够靠谱。比如 nginx proxy_cache 可以多较多,这时候宕掉一台不至于使全部读请求穿透到底层存储。至于多了之后purge等操作如何全面的执行,不在本文讨论之列。
 
综上,raw read效率不需要再提升,因为其需求已经被缓存层大量取代。
 
2. 无法取代的rawwrite功能
 
看到缓存减轻raw read的工作量,我们可以在想是否有方法可以减轻rawwrite的工作量。答案是不可以的。如果您认为可以。可以留言探讨。既然rawwrite的工作量是不可取代的,那么我们大概可以有两种方法提升写操作的性能。
 
3.1 sharding
 
通过对数据的分区,我们可以将数据进行分布式的存储,于是每个结点只会分配到一部分的rawwrite请求。这样相当于公司员工效率不变,多招了人。但由于结点的增多,其中有结点出问题的效率也大大增加。于是我们不得不做一些replication操作来提供HA方案。
 
3.2 提升rawwrite效率
 
如上面的举例,我们只能选择提升rawwrite效率来实现总体(包括cache层)更好的读写效率。这里通常使用的方法就是将随机的写操作在内存中进行序列化,并在一定量后进行顺序的flush到磁盘操作。所谓将内存当成硬盘,将硬盘当作磁带就是这个意思。(可参见我更早的一篇文章:《NoSQL理论之-内存是新的硬盘,硬盘是新的磁带》)所以我们看到前面说到的很多NoSQL产品着重对写操作进行了优化,而对读性能提升并不明显,甚至不惜以更慢的读作为提升写操作性能的代价。
 
4. 总结
 
由于读性能可以通过设置合理的缓存策略来减少raw read操作的数量。因此不仅对读写比不大的情形需要着重进行写操作的优化,对读写比大的情况下,仍旧需要优化写性能而非读性能。

热推产品

  • ActiveReport... 强大的.NET报表设计、浏览、打印、转换控件,可以同时用于WindowsForms谀坔攀戀Forms平台下......
  • AnyChart AnyChart使你可以创建出绚丽的交互式的Flash和HTML5的图表和仪表控件。可以用于仪表盘的创......
首页 | 新闻中心 | 产品中心 | 技术文档 | 友情连接 | 关于磐岩 | 技术支持中心 | 联系我们 | 帮助中心 Copyright-2006 ComponentCN.com all rights reserved.重庆磐岩科技有限公司(控件中国网) 版权所有 电话:023 - 67870900 传真:023 - 67870270 产品咨询:sales@componentcn.com 渝ICP备12000264号 法律顾问:元炳律师事务所 重庆市江北区塔坪36号维丰创意绿苑A座28-5 邮编:400020
在线客服
在线客服系统
在线客服
在线客服系统