關于內存數(shù)據(jù)庫
最近要將一些數(shù)據(jù)放到內存里面做很高的并發(fā)操作，考慮了很多方案，
1、 簡單點使用map hash_map等自己管理。
2、 用sqlite內存表。
3、 用fastdb內存數(shù)據(jù)庫。
4、 用ExtremeDb，TimesTen等。
比較測試了一下123，發(fā)現(xiàn)還是自己實現(xiàn)速度最快，比fastdb模式快3-5倍，fastdb模式比sqlite內存表模式快10倍左右，由于自己實現(xiàn)不具有典型通用性，多線程下訪問效率會下降，要管理多線程下各種更新查找等還是比較麻煩的，所以在1和3方案之間糾結。
為了使得決策更好一些，暫時還沒做決定，順便到萬方等上面搜索了一些論文來看，看來看去看得真來氣啊，雖然都叫內存數(shù)據(jù)庫但各種實現(xiàn)的都有，有用gdbm來做的，有直接map管理的，有hash管理數(shù)據(jù)的，有t樹管理的，有數(shù)組隊列管理的，有的明顯就是個不大變的東西還弄個啥事務的，靠，剛剛居然還看到一篇鳥文《電網(wǎng)監(jiān)控系統(tǒng)實時數(shù)據(jù)庫的設計與實現(xiàn)》里面的測試居然是1000條，插入時間80毫秒，真可笑啊，區(qū)區(qū)這么點數(shù)據(jù)也好意思測，還要花80毫秒，還自以為很快，這個速度至少可提高1000倍以上啊，這幫垃圾，寫的啥鳥文章，研究個屁啊。
看完這十來篇論文，俺的思緒又回到1999年，當年我給別人優(yōu)化過一個電信計費的軟件（看的論文里面有好幾篇講電信計費的），當時有個朋友的朋友拿了個需求過來，7000萬條記錄，原來計算費單要花十幾個小時吧，我?guī)退牧讼?，十來分鐘就算完了，朋友很滿意，當時的做法很簡單，就是弄了個mmtable，大體就是跟map類似的東西吧，那個時候map還沒流行起來，俺也不知道，所以就自己弄了個內存表，內部基本就是二分查找了，那個時候我對hash都不大熟悉，B樹之類的算法剛接觸也不會用，就這么個東西當時的電腦也只要花十來分鐘，我估計就算是那個老程序放在現(xiàn)在的普通臺式機上要不了幾秒鐘就可算完。也不知道這么幾千萬條記錄的小需求怎么在這幫人眼里就成了什么海量數(shù)據(jù)，對俺來說跟玩似的，區(qū)區(qū)幾千萬嘛，不過是俺拿來測試用的。
去年中做了個md5 hash反查的東西，數(shù)據(jù)都是幾百億到幾萬億的，后來的效果就是一個文件可存萬億記錄，一次查詢平均1.2次IO，即使全放在SATA磁盤上也就十來毫秒而已。
區(qū)區(qū)幾千萬條記錄咋就叫什么海量數(shù)據(jù)呢，海量個毛啊，內存都放得下的叫什么海量，現(xiàn)在服務器動不動都是幾十G內存，區(qū)區(qū)千萬根本算不上什么，查詢定位都可到微妙了，1秒插入至少千萬條了，居然還看到1000條插入的測試，真是不得不佩服國內這幫垃圾研究生的水平，也不知道這種論文咋就能通過審查，只能得出結論他們的老師也都是豬。
罵歸罵自己的問題還需要繼續(xù)努力，對咱目前的需求來說自己管理數(shù)據(jù)，即使一個線程都搞得定，因為不過區(qū)區(qū)幾個表，幾十萬條記錄而已，不過這種10年前咱就會的技術還真是拿不出手，怎么的也得做得更好一點，呵呵，繼續(xù)研究吧，多線程下內存數(shù)據(jù)庫，從概念上看的確是個很有吸引力的東西，要是性能跟得上，其實在很多地方可以取代普通的數(shù)據(jù)結構用法了，可以大大減少編程難度，甚至我在想如果有個支持事務的內存數(shù)據(jù)庫，之前設計的cad類軟件的undo/redo都可以用事務來實現(xiàn)，完全可以拋棄先前設計的復雜結構，其實這種東西即使不用內存數(shù)據(jù)庫就算是用個sqlite都完全能搞定，唉，往事不堪回首啊，看來數(shù)據(jù)庫方面的確得多花功夫，特別是多線程和分布式模式下的內存數(shù)據(jù)庫。