prevayler：彻底颠覆你的数据库情结

我差点把水喷到到笔记本的液晶屏上。思考问题投入到坐在马桶上，有趣。

其实我对prevayler不是很看好，只是一种直觉，还说不上来为什么，只是觉得他无法取代数据库，之所以无法取代，是觉得持久对象的存储不是光持久化到硬盘上那么简单。我现在对prevayler还不了解，所以还不方便发言，等我春节抽空研究一下再说。考虑到对象只需要在JVM的heap里面操作，而不需要持久化，感觉会有很多新的问题冒出来：例如你想要操作的对象，被GC回收了怎么办？你怎么保证那些对象是你想要的，那些是你不想要的？传统的做法很简单的，不持久化的对象就让GC自己去回收，持久的对象你就保存到硬盘，然后再取得。但是这种情况下你怎么办？设定策略让GC永远不回收PO对象？恐怕不现实吧。还有，如何处理对象的查询？例如我需要根据某些条件获得一个对象集合，传统的sql很简单的处理了。而你现在可能根本没有很好的办法去处理，甚至要自己去遍历整个对象集合一个个拎出来，然后再根据其他条件再过滤。

反正我简单的想了一下，就想出一大堆问题，关系模型对于存储和查询来说，那时有坚实的数学理论基础的，我总觉得你彻底抛弃了似乎有不妥之处。

这些问题待我研究过以后，大概就有一个清晰的想法了。

这个冬冬optian在某些帖子里面就提到了，我也稍微看了一下，了解不多。
不过很感兴趣，robbin说得是不错，或许理论完善程度，和动能强大都不如rdbms，但是想想很多中小型的应用到的只是rdbms强大功能的一小部分如果够用而且能够很大程度大上的提高哦开发效率，执行性能，让设计更自由的话，还是有吸引力的。

你说的是potian吧，我也是看了这个非常火的帖子才出于好奇Google了一下。
我非常非常欣赏potian的OO思想，可惜他好像最近不来了。

不好意思，我写错了是potian。
很hot的帖子，我猜他还是回来的。我很喜欢看这个论坛里面人长篇大论的留言。
：）

robbin，数据库可以不再虚拟机上运行，所以GC的问题不大
只要手工管理持久性就可以了

关系代数解决的是数据的组织和操作方式，与存储无关
本质上外存储和内存是一样的，都是连续的随机访问空间，只是速度相差太远，还有一个数据易失性的问题

存储相关的那部分是散列和动态树，这些东西复杂的要命，如果把数据都丢进内存，那确实简单好多

我只是担心数据安全性的问题能不能解决好
我倒是希望内存有个革命，不至于掉电就啥都不剩了

内存本来就是要求快速，持久数据可不是内存干的活啊。
我觉得调电数据丢失是很正常的。大不了恢复最后一次commit的数据。

首先我先前就听说过很多产品具有这个功能，为什么不看好，原因很简单
数据库是做什么的？
当然是存取数据，但是注意这个数据一定是大量数据，小规模（现在的看法小余1G就不能称大量），为什么？原因更简单，小规模数据用不着数据库，你完全可以自己放在内存里，弄个线程监视，如果掉电，用简单的Undo,Redo日志就能恢复，这种自己写的效率绝对不会差。（这就是prevayler的生存空间，这种产品到最后只能开源。）
为什么它不适用于大量数据的情况？
主要就是内存不够，然后为了在内存不足的情况下能够保存大量数据当然效率低了（IO和算法）

所以如果你能保证你的数据不多，prevayler当然适用，其实相当于一个Cache。

prevayler好像一直是开源的

喷...昨天晚上偶然看到这个冬冬，高兴的很，没想到今天就看到你们在年前就开始讨论了.....

google据说早就是把所有的数据都跑在内存中了吧？

之前也听说过prevayler,不过感觉确如jacobmee所说的，就是一个大Cache,而Cache服务其他很多也提供,
至于Prevayler所鼓吹的东东，
我有些疑问：
1.说是只记录必要Log,而真正内容更新定期写磁盘：
   问题是现在数据库也是这样的阿，比如Oracle,对于每一个Commit,
也只是写Log,然后积累了一定数量的脏块，才一并Flush到磁盘。
Prevayler凭什么就说好呢？（除非是Oracle的默认3s一Flush
比起Prevayler的Flush来说仍然太快，不过Prevayler如果Flush
间隔时间大了就意味着Recovery时间长)--（ps,不晓得Oracle有没有
调那个默认多少时间Flush的。）
2.Prevayler说鼓吹的性能比较，说是比Oracle等数据库快上千倍。
问题是这些比较数据到底是在一种什么环境下出来的，
如果是Prevayler的在内存查询速度和别人的到磁盘上查询比较的话，
那根本比的不是一档子事，出来千倍自然很正常。
Anyway,我对Prevayler持怀疑态度，静观事态发展。