关于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操作的数量。因此不仅对读写比不大的情形需要着重进行写操作的优化,对读写比大的情况下,仍旧需要优化写性能而非读性能。
原文地址:http://news.cnblogs.com/n/77216/
本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/heiyeshuwu/archive/2011/02/16/6189621.aspx
建议继续学习:
- HFile存储格式 (阅读:14521)
- hbase运维 (阅读:13669)
- 我对技术方向的一些反思 (阅读:9851)
- 淘宝图片存储架构 (阅读:9809)
- 海量小文件存储 (阅读:7540)
- Key-Value小数据库tmdb发布:原理和实现 (阅读:7304)
- HBase技术介绍 (阅读:6737)
- SQL vs NoSQL:数据库并发写入性能比拼 (阅读:6610)
- 让Redis使用TCMalloc,实现高性能NOSql服务器 (阅读:6088)
- 存储基础知识之——硬盘接口简述 (阅读:6123)
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:heiyeluren 来源: heiyeluren的Blog
- 标签: NoSQL 写性能 存储
- 发布时间:2011-02-16 22:17:22
- [67] Go Reflect 性能
- [67] Oracle MTS模式下 进程地址与会话信
- [67] 如何拿下简短的域名
- [61] IOS安全–浅谈关于IOS加固的几种方法
- [60] 图书馆的世界纪录
- [59] 【社会化设计】自我(self)部分――欢迎区
- [58] android 开发入门
- [56] 视觉调整-设计师 vs. 逻辑
- [49] 给自己的字体课(一)——英文字体基础
- [47] 界面设计速成