關於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的記憶體就能滿足目標了。