krproject开发进展(五)

在记流水账之前,我还是想先记录一下昨晚和同事的一个讨论,也是关于krproject存在的意义:

Question

krproject <= 内存数据库(redis、memcached……)+ 规则引擎(drools、jrules……) ?

Description

不可否认,无论从代码质量、程序健壮性、配套工具等诸多方面上:krdb << redis, krrules << drools

实际上要自己写krdb的想法在我脑中诞生的时候,我还不知道有redis和memcached等内存数据库,那时候我搜索“内存数据库”出来的是sqlite……,然后当我写完并成功完成项目投产后,我发现了redis……,其实当时就有想过将krdb换成redis,可是实际项目中有关于多维度的需求,而这一点在目前的nosql内存数据库实现里做的都不是很好或者说实现会比较复杂(参考我之前写的
HyperDex浅析之hyperspacehashing

而krrules的诞生,要追溯到我们在某个项目中的具体实施,应对方强制要求,使用了X产品做规则引擎,可是它很难做到多数据源、多统计维度的时间窗口统计,于是X的输入就是krdb的输出……。这样带来的问题就是无论规则是否需要,krdb需要将所有统计量计算完成,组成接口传递至X,因为太多无谓的计算导致CPU消耗严重。

于是我想到自己用C来实现这样一个规则引擎解决这个问题,即要能做到当遇到类似A > 500 && B < 3000这样的规则,在A < 500时,能够不再需要计算B的值,这样便可以省去很多不必要的性能开销。

Challenge

而昨天同事的问题及方案则是:在规则引擎前挂一个内存数据库,他们的交互接口不再是规则用到的统计值,而是所有相关的原始交易数据列表,规则引擎自己完成对原始交易的加工统计和规则运算。

这样能够通过规则解决统计量的运算优化,可是带来的一个很大问题是:数据接口内容的庞大!这样规则引擎和数据存储统计层的交互接口显然会成为很大的瓶颈。

当然,这么一个简单的问题,昨晚辩论的时候,我居然没有想到……,关键在于分成两个部分以后的交互接口:krproject是在同一个进程中,无需额外的数据拷贝,而内存数据库+规则引擎则需要不必要或者大量的数据拷贝!这真是krproject的性能所在和存在意义。

Conclusion

是的,在很多方面:krdb < redis, krrules < drools,可是krproject并不是内存数据库+规则引擎就大于的,至少不是简单的组合!:-P

我并不只想将krproject做成自己的一个小玩具,我还希望它能发点光、发点热,哪怕只有一点点!我想每个开源软件作者大概都有类似这样的期望或想法吧!

回到krproject的开发流水账上来:

这段时间除了上篇博客记录的写了一个对unixODBC的包装rapodbc并完全替换掉之前krproject的Embedded SQL数据库接口层,这不仅让krproject支持的数据库扩展开来(测试时,我起了三个krserver,分别连我本地的db2、mysql和sqlite3……),还有个额外的好处是数据库的多线程操作变得容易、标准了很多,这对于krrules的线程池处理实在是个好消息,再不用为各个数据库的多线程接口不一致而头疼了;

另外我还将example的数据交换格式改成了json(嵌入了parson的两个文件,实现对json格式的解析处理),之前C的结构体并不是一个很好、通用的接口……(无法与其他语言交互,另外同是C语言,也存在编译位数差异与字节对齐的问题),后面会尝试写一写xml、protobuf格式的接口处理案例。

后面打算学习下web编程,目前为止krproject还没有给人很直观的感受,和它还没有提供一个试玩操作界面有关,计划尝试借着tornado框架来写,希望一切顺利吧~