技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> MySQL --> 关于NoSQL的思考:为什么我们要优化存储的写性能

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

浏览:3679次  出处信息

在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操作的数量。因此不仅对读写比不大的情形需要着重进行写操作的优化,对读写比大的情况下,仍旧需要优化写性能而非读性能。

原文地址:http://news.cnblogs.com/n/77216/

 

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/heiyeshuwu/archive/2011/02/16/6189621.aspx

建议继续学习:

  1. HFile存储格式    (阅读:14521)
  2. hbase运维    (阅读:13669)
  3. 我对技术方向的一些反思    (阅读:9851)
  4. 淘宝图片存储架构    (阅读:9809)
  5. 海量小文件存储    (阅读:7540)
  6. Key-Value小数据库tmdb发布:原理和实现    (阅读:7304)
  7. HBase技术介绍    (阅读:6737)
  8. SQL vs NoSQL:数据库并发写入性能比拼    (阅读:6610)
  9. 让Redis使用TCMalloc,实现高性能NOSql服务器    (阅读:6088)
  10. 存储基础知识之——硬盘接口简述    (阅读:6123)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1