NOSQL、IO事務、階段化、內存與硬盤資源權衡

在有些應用中，寫操作不能忽視。緩存雖然解決了RAW READS的效率問題，但留下了RAW WRITES沒有解決。這在web2.0時代以前好象不成問題，但現在成了問題。并且這個問題以后還會變得更大。最終逼迫所有的數據操作全在內存完成或者 更甚，全在處理器的高速緩存完成（is it possible?）。

RDBMS是一個面向正確性的方案。而正確性與性能存在沖突（傳說是根據一名著名教授的言論，CAP不可兼得）。所以才產生了NOSQL這種拋棄正確性而面向性能的方案。

雖然CAP否認的只是在分布式情況下的正確性與可用性同時獲得。它并沒有反對同一個實例中的正確性與可用性。但是在現實應用中，有時候正確性的確是可以為性能小小地讓一下步這個倒是實際情況。

NOSQL核心技術還是異步，內存與并發優化。其實如果再歸納一下的話，幾乎所有性能技術的最后標的只有一個，那就是內存。因為只要處理器在不停地 工作，處理器的性能就已經最大化。而在現行的調度與調用系統下，處理器在這一點上基本上沒有太大的問題。但現行的調度與調用系統和DBMS對內存資源的利 用一直存在很大的問題。NOSQL正是一個逐個逐個解決這些東西的方案。比如，異步就極大地提高了內存的利用效率，如果能在同時處理好多任務的問題。

五分鐘法則是指：

在內存中保持1KB數據的成本相當于硬盤中存放400 秒的開銷。

這里其實有點小問題。因為一方面這樣單獨以內存空間的大小來度量內存資源是不正確的，另一方面如果硬盤訪問引起了延遲（即其它線程或任務被影響了） 的話，這樣的比較根本就沒有任何意義。所以這個數據只應該被限制在不引起任何延遲的情況下使用，但如果沒有延遲的話為什么還要對系統進行優化呢？

對內存資源的度量必須同時加上時長。

硬盤訪問是IO事務，會引起處理器的狀態切換與現場切換，緩存清除，在使用異步I/O的情況下還會引起亂序失效，如果有數據爭用的話可能還會引起內 存屏障，進（線）程自旋等處理器資源開銷以及完成I/O操作所需要的緩存、系統工作空間等內存資源的開銷。這個開銷不小。能不I/O當然更好。但是如果把 一些不常用的數據長期放在內存顯然更不好。那么多常用才應該擺在內存呢？五分鐘法則嘗試回答的就是這個問題。

如果不算時長，那么顯而易見應該把數據永遠放在內存，因為從硬盤讀取數據顯然需要更多的內存空間與處理器周期，以及其它很多看不到的無法用處理器周 期來衡量的處理器資源如亂序失效情況下指令的重新排序與內存屏障引起的其它線程的延遲。但算上時長以后，把數據放在內存則是個非常壞的主意。因為從硬盤讀 取的方案顯然可以以更少的資源完成同樣的服務（如果把數據長期地放在內存是個好主意，那怎么會有的硬盤呢？硬盤的出現，正是一種以（硬盤）空間換（內存） 時間的做法---這正說明內存時間是值錢的？！）。這種方案只在一種情況下帶來好處那就是內存資源并不緊缺的情況下，那么在它無活可干的情況下，幫一下硬 盤當然就成了好主意了。 

，，，

這個問題太復雜。

它到底有沒有可能被最終歸結為一個線性規劃問題呢？只能對它進行動態規劃？

Feel really frustrated...