关于ORM和内存数据库的遐想

最近有消息说韩国电信已经在新的3G 的BSS系统中开始使用内存数据库，而且还是基于对象的内存数据库，这个消息对于一直在做电信系统开发的我来说很是让我浮想联翩，很早前就想对一些老系统用ORM做一次重构了，但是因为种种原因和ORM的种种局限而未能最终走出这一步，对象化内存数据库的实用化让我看到了希望的曙光。
其实也不能说电信系统里就没有使用ORM的例子，其实很多系统已经在使用Hibernate了，不过很可惜的是，在很大一段时间内国内做.NET开发的人们都是处于邯郸学步的状态，JAVA里有了个Hibernate，于是有了NHibernate。拿来主义固然好，但是再好的框架也有遇到中国国情的时候（微软和中国果然很有缘份）。很多时候做.NET的人都有点对java有说不出的感觉，总觉得自己先进，但是每每看到用java的大型系统（特别是电信领域）的时候，总是存在很复杂的表情。可能是叫自惭形秽，因为我也是学.NET出身，又是在电信行业的环境内，所以感觉特别强烈，不过也不用妄自菲薄，电信里面也是有.NET一席之地的。
这里回到问题本身，为什么不用ORM?这里已开始我主要考虑的就是效率问题。现在的ORM框架基本原理无外乎都是通过万能的反射来实现映射的目的。不过众所周知的，反射就意味着百倍的性能下降（关于反射的效率问题网上文章多多，不再累述，前段时间和徐晓卓谈到这个问题的时候也是这个结论），还有一点就是成倍的增加了Call stack的长度，这个也是不小的开销。总之在这个时候，强调实时性的电信系统也别是VNET的计费系统在使用的时候不得不面对这个严峻的问题。第二点也是很多人想反驳我的观点的地方，很多ORM框架，比如NHibernate，iBaties.NET等都有缓存机制，也有的有LazyLoading，何来效率问题？这里强调一下，这两个框架的源码我没看完过，用法也不精通，所以说错了希望有大大出来纠正我，根据我现有有限的智慧发现，LazyLoading的效率问题依然严峻，因为就算是延迟了加载，但是总归是会加载的，当一个类的成员列表的长度达到几十万，或者上百万的级别的时候，你会发现，貌似一开始就加载和调用时加载没什么区别，而且就我有限的智慧发现这样子调用是无法对子列表进行分页处理的。老一辈无产阶级革命的程序员教导我们，读取大列表一定要分页，这里我们不得不违背了这个原则，但是就算是有缓存也不是万能膏药，举个实际的例子，一个大数据库的用户表数据量高达100W数量级，包括各类用户等等，100W的数据要占用1个多G的空间。这个时候我只能傻眼了（iBaties.NET对查询作缓存，空间浪费更加严重），一般的WEB服务器上只有2G的内存。
虽然说这是个硬件贬值比工资贬值都快的年代，但是在WEB Server用Cache未免开销过大，大型系统最小部署就需要4台PCServer做群集。同时升级4台Server的内存是用户所不能接受的。
这时候该我的救星，内存数据库粉墨登场拉，不过现在还只是在我的想象之中，最终的效果可能暂时还不会真正的使用
在我的设想中最终存储数据的还是物理磁盘作为最终的载体，不过所有的业务数据都由内存数据库Cache起来，对于用户的输入能够最快的作出反应，并且通过刷新机制，根据策略把数据永久性的写入磁盘，在这里比如用户数据，订购元数据，当月订购关系，当月详单全部load进内存，所有业务都在内存中展开，账期结束的时候再写入物理磁盘永久保存，如果中途掉电通还可以通过日志和物理磁盘里上次提交结果来恢复。这样子把这个内存数据库部署在两台接口机上，配制成群集，这个时候就只需要升级两台Server的内存就能满足目标了。