最近花了些时间，将引擎的存储换成了mongodb。
私下，我觉得现有的存储机制极为落后。现在写数据的操作交由单独的进程完成，该进程兼当数据缓冲与持续化数据的责任。此次引擎的更换，只是简单的利用mongo的官方c驱动，将数据打到mongo里面，代替写文件的做法而已。该进程的数据缓冲角色，还是没有变化。mongodb的优势在于对内存的高效利用，增加一层作为中转，就会失去这个速度上的优势。
往引擎里添加mongo，比较头大的是跟引擎脚本的类型系统打交道。比较了一下BSON支持的数据格式，能够比较好的容纳引擎的数据。但是引擎的关联数组（类似python的dict）和异构数组，在C层用起来不太方便。引擎这边的类型，都是用一个svalue进行封装，里面用union包装int、float等基础类型，以及字符串指针和数组等引用类型。但是，svalue的打包却需要手工做，没有封装方便的打包函数。关联数组的使用还算方便，只要构造好key和value的svalue值，调用find_for_insert，然后assign_svalue就可以了。
bson到引擎和引擎到bson的格式转换搞定之后，就找了个开源的带锁队列，用来作数据库连接池的管理。目前有个问题未解决，如果连接不到数据库，程序就会崩掉。。然后测试了一下读写，基本没问题了。主要是有部分储存使用了整型的key，而mongodb不接受整型key。
剩下的主要是对象的生命周期管理。连接对象由数据库连接池进行管理，如果多线程读写时有线程hang住，该连接就不会被释放了。用于传送数据到数据库的bson对象，会在每次传送完成后被释放，这里应该没有问题。从数据库序列化为引擎的数据对象时，产生的关联数组等数据交由vm进行管理，这块是通过引用计数做的，要分析泄漏的问题，可能要结合具体的脚本进行分析了。
性能方面，还没有进行测量，打算通过Dtrace或者SystemTap进行，顺便用valgrind做做内存泄漏检测。瞎猜测一下，socket进行数据中转和序列化对象可能会是瓶颈。