关于内存数据库
最近要将一些数据放到内存里面做很高的并发操作，考虑了很多方案，
1、 简单点使用map hash_map等自己管理。
2、 用sqlite内存表。
3、 用fastdb内存数据库。
4、 用ExtremeDb，TimesTen等。
比较测试了一下123，发现还是自己实现速度最快，比fastdb模式快3-5倍，fastdb模式比sqlite内存表模式快10倍左右，由于自己实现不具有典型通用性，多线程下访问效率会下降，要管理多线程下各种更新查找等还是比较麻烦的，所以在1和3方案之间纠结。
为了使得决策更好一些，暂时还没做决定，顺便到万方等上面搜索了一些论文来看，看来看去看得真来气啊，虽然都叫内存数据库但各种实现的都有，有用gdbm来做的，有直接map管理的，有hash管理数据的，有t树管理的，有数组队列管理的，有的明显就是个不大变的东西还弄个啥事务的，靠，刚刚居然还看到一篇鸟文《电网监控系统实时数据库的设计与实现》里面的测试居然是1000条，插入时间80毫秒，真可笑啊，区区这么点数据也好意思测，还要花80毫秒，还自以为很快，这个速度至少可提高1000倍以上啊，这帮垃圾，写的啥鸟文章，研究个屁啊。
看完这十来篇论文，俺的思绪又回到1999年，当年我给别人优化过一个电信计费的软件（看的论文里面有好几篇讲电信计费的），当时有个朋友的朋友拿了个需求过来，7000万条记录，原来计算费单要花十几个小时吧，我帮他改了下，十来分钟就算完了，朋友很满意，当时的做法很简单，就是弄了个mmtable，大体就是跟map类似的东西吧，那个时候map还没流行起来，俺也不知道，所以就自己弄了个内存表，内部基本就是二分查找了，那个时候我对hash都不大熟悉，B树之类的算法刚接触也不会用，就这么个东西当时的电脑也只要花十来分钟，我估计就算是那个老程序放在现在的普通台式机上要不了几秒钟就可算完。也不知道这么几千万条记录的小需求怎么在这帮人眼里就成了什么海量数据，对俺来说跟玩似的，区区几千万嘛，不过是俺拿来测试用的。
去年中做了个md5 hash反查的东西，数据都是几百亿到几万亿的，后来的效果就是一个文件可存万亿记录，一次查询平均1.2次IO，即使全放在SATA磁盘上也就十来毫秒而已。
区区几千万条记录咋就叫什么海量数据呢，海量个毛啊，内存都放得下的叫什么海量，现在服务器动不动都是几十G内存，区区千万根本算不上什么，查询定位都可到微妙了，1秒插入至少千万条了，居然还看到1000条插入的测试，真是不得不佩服国内这帮垃圾研究生的水平，也不知道这种论文咋就能通过审查，只能得出结论他们的老师也都是猪。
骂归骂自己的问题还需要继续努力，对咱目前的需求来说自己管理数据，即使一个线程都搞得定，因为不过区区几个表，几十万条记录而已，不过这种10年前咱就会的技术还真是拿不出手，怎么的也得做得更好一点，呵呵，继续研究吧，多线程下内存数据库，从概念上看的确是个很有吸引力的东西，要是性能跟得上，其实在很多地方可以取代普通的数据结构用法了，可以大大减少编程难度，甚至我在想如果有个支持事务的内存数据库，之前设计的cad类软件的undo/redo都可以用事务来实现，完全可以抛弃先前设计的复杂结构，其实这种东西即使不用内存数据库就算是用个sqlite都完全能搞定，唉，往事不堪回首啊，看来数据库方面的确得多花功夫，特别是多线程和分布式模式下的内存数据库。