在有些应用中，写操作不能忽视。缓存虽然解决了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...