既然Hibernate提供了缓存的支持，而且内存的速度比硬盘的IO快那么多
为什么不考虑把这个项目中的所有Domain都配置 读写缓存
这样所有的数据都是从cache里面走的，而且和DB同步，数据都是干净的
很多人认为有些经常变动的对象做cache没意义
但是如果你要修改一个对象，我们是不是先需要把他查出来一次，然后重新set 他修改的属性，最后update
其实在这次查询的时候我们的cache已经起了一定作用了
我希望各位大大们，在解答的时候能 有点可以参考的数据指标，比如大体积的cache经常write的性能消耗比走DB大
或者能有实际项目遇到这种情况的问题！
非常感谢！
是的，这实际就是现在NoSQL大多数基本原理。
感谢banq的回复！
其实我们现在已经有一套自己的类似于NOSQL的实现
我们将一些根对象在项目启动时候加载到cache，而且加载的都是完整的根
而且有效的保证了ROOT对象在cache中的唯一性
当业务有数据变更操作的时候，如果是根对象则直接从cache中取出来，如果是其他的那么用jxpath做内存筛选，然后set改变值，最后update ， 当数据库操作出现异常的时候，我们有一套内存中对象还原机制来将当前业务中操作的某个对象进行还原！
由于这套框架以前都是运用在一些小项目上面 ， 如今面临一个类似于SNS的站点，我们的设想是 面对海量的数据我们可以考虑分布式缓存， 但是因为欠缺经验，不清楚这种把数据库的数据全部映射到cache中去，是否会带来一些隐患！
因为这种cache不在只是针对不经常变化的数据
但是我们又觉得这种设计能到达SNS需要的高频率读的需求
请banq给一点参考意见。 十分感谢！
问题关键就是在这里，所以，推荐你使用HBase或Cassandran这些现成产品，否则你们又要自己做，重新发明轮子了。而且成熟度也不可知，何必那么累？