一，为什么我们要使用规则引擎
在电信行业中，我们做的最多的工作是在比较数据，话单的海量数据处理，无非就是将数据比较，去重，入库，汇总。为了在有限时间内实现数千万话单的逻辑，我们一遍一遍的用C实现简单教科书重复了一遍一遍的算法，list，tree，hash，几乎一个业务就衍生出一个独立程序。
所以我们看到我们的业务支撑上的服务器上，基本就是进程管理器，加一堆杂乱无章的独立程序，构成我们的系统。
我们在想，我们能不能用数据库，内存数据库，文件数据库，把话单变成能用Sql解析的数据，我们只用动态sql，去处理任意的数据形式，去重，汇总，比对，完成所有c程序要完成的工作。
1， 我们应该怎么使用数据库来实现，我们能不能用Oracle生产库，能不能用TimesTen。
不能，使用Oracle,TimesTen会加大我们项目的预算，使我们的项目用很赚钱，变成赚一点钱的项目，要在我们所有业务支撑系统中推广，每一个实例30W$东西我们坚决不用，所以数据库的机制由我们自己实现，那么必须是开源的，可改造的。
2， 我们自己实现的数据库，有什么技术需求，他与普通的数据库用什么区别。
*我们在计费，账务过分的依赖于共享内存，它必须小心的使用，因为你如果将未知大小销账列表都装进内存，当系统迅速吃光所有服务器的内存时，我们只好等着工程人员骂着娘帮我们重启机器。
用了数据库来运行就不一样了，当我们设定一个地市的pagecache是5G是，那么20个地市就是100G，消耗资源的大小是我们心中有数的。
*我们需要将千万级以上的数据快速的转换成B-tree的数据结构，我们不能忍受我们入库Oracle是每秒几千条入库效率，由话单文件，生成数十G数据库文件必须在二十分钟以内。
*转换后的文件形式不能过分的膨胀，XX省移动的话单在300G左右，我们不能再转换后将其变成几个T的容量，那样会使到我们又必须拉下面子求客户买机器。
*数据库索引的建立必须是快速的，自发的，能够依照我们sql里的条件，自动的创建需要的索引，由于他不是在线数据库，那么我们不用当心建立索引后，数据操作过慢的问题。我们是在所有数据转换成B-tree后，根据sql批量的建立我们需要的索引。
*业务对应的逻辑的实体，我们称之为规则RULE。
*规则可以拆分成可重用的逻辑粒度，我们称之为规则细项RULEITEM
*多个sql处理逻辑的过程我们称之为处理逻辑handle
*以上这些特征，我们称之为规则引擎。
*最后一点是，我们不需要再养一大批c算法高手了，业务人员根据业务的需要制定对应的SQL，我们的规则引擎自动帮我们处理数以亿万级的数据。
目前该方案已经在支撑系统的一个子系统中慢慢成形，数据量在千万级以上，并用于日常生产环境中，极大的降低开发成本，想与各位行业内外探讨下方案，
该方案是否与数据挖掘和数据仓库学科有共通的地方，这个可以请BI或NCR的朋友看看？
除了电信，金融以外行业，海量数据处理对于游戏，网站等其他行业有无相关需求？
再来是介绍我们实现这个方案的技术背景。
一，我们要先弄懂我们怎么去写这样一个规则引擎数据库。
我们先通过一个个问题来探讨什么是数据库，他是怎么实现的。有人说软件科学最精美方向有3个方向，操作系统，数据库，编译器。我们现在朝着其中一个去探究，看看前边有什么绮丽的风景。
我在这里先简单介绍下我所理解的数据内核，
1， 数据库是怎么读懂Sql，为什么数据库能将Sql自动转化为高效的算法。
2， 为什么数据库能用有限的内存处理无限外存数据，数据库怎么处理内存与外存的交换关系。
3， Page是什么东西，B-tree与Page是怎么联系起来的。
4， Index是什么东西，它是怎么添加上去的，为什么加上它sql就查的特别快。
