krproject开发进展（五）

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

Question

krproject <= 内存数据库（redis、memcached……）+ 规则引擎（drools、jrules……） ？

Description

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

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

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

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

Challenge

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

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

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

Conclusion

是的，在很多方面：krdb < redis， krrules < drools，可是krproject并不是内存数据库+规则引擎就大于的，至少不是简单的组合！😛

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

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

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

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

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