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

原文链接:http://lgone.com/html/y2010/823.html

在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 无法取代的raw write功能

看到缓存减轻raw read的工作量,我们可以在想是否有方法可以减轻raw write的工作量。答案是不可以的。如果您认为可以。可以留言探讨。既然raw write的工作量是不可取代的,那么我们大概可以有两种方法提升写操作的性能。

3.1 sharding

通过对数据的分区,我们可以将数据进行分布式的存储,于是每个结点只会分配到一部分的raw write请求。这样相当于公司员工效率不变,多招了人。但由于结点的增多,其中有结点出问题的效率也大大增加。于是我们不得不做一些replication操作来提供HA方案。

3.2 提升raw write效率

如上面的举例,我们只能选择提升raw write效率来实现总体(包括cache层)更好的读写效率。这里通常使用的方法就是将随机的写操作在内存中进行序列化,并在一定量后进行顺序的flush到磁盘操作。所谓将内存当成硬盘,将硬盘当作磁带就是这个意思。(可参见我更早的一篇文章:《NoSQL理论之-内存是新的硬盘,硬盘是新的磁带》)所以我们看到前面说到的很多NoSQL产品着重对写操作进行了优化,而对读性能提升并不明显,甚至不惜以更慢的读作为提升写操作性能的代价。

4 总结

由于读性能可以通过设置合理的缓存策略来减少raw read操作的数量。因此不仅对读写比不大的情形需要着重进行写操作的优化,对读写比大的情况下,仍旧需要优化写性能而非读性能。

anyShare据说看到好文章不转的人,服务器容易宕机!
          

无觅相关文章插件,快速提升流量

  1. 需要写性能很高的时候,都是先写入队列,在同时做个内存缓冲区,和磁盘的数据进行merge