[转]关于NoSQL的思考：为什么我们要优化存储的写性能 NoSQLnginxMongoDBTokyoCabinetCassandra

在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/