在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操作的數量。因此不僅對讀寫比不大的情形需要著重進行寫操作的優化，對讀寫比大的情況下，仍舊需要優化寫性能而非讀性能。