内存数据库的基本原理与应用

内存数据库是以牺牲内存资源为代价换取数据处理实时性的，内存数据库和磁盘数据库都是当今信息社会里每个企业所必须的关系型数据库产品，磁盘数据库解决的是大容量存储和数据分析问题，而内存数据库解决的是实时处理和高并发问题。两者的存在是相辅相成的，内存数据库的事务实时处理性能要远强于磁盘数据库。但是相对的，他的数据安全方面还没有达到磁盘数据库比肩的地步。

内存数据库将物理内存作为数据的第一存储介质，而将磁盘作为备份。随着电信业务的发展，系统对实时性的要求和对业务灵活修改的要求非常高，在此种情况下对于内存数据库的需求也越来越高。磁盘数据库的做法是将数据存入内存中进行处理，这种方式的可管理性及数据安全可靠性都没有保障。而内存数据库正是针对这一弱点进行了改进。

实际上，内存数据库并不是一项时髦技术，其出现于上世纪60年代末，但由于市场的需求原因在90年代后期才开始发展。作为新一代数据库，Altibase产品已经走向混合型数据库，其版本Altibase4.0已经有一套自带的磁盘数据库，用户一旦购买了Altibase的内存数据库，就无须再购买磁盘数据库。它把热数据(经常被使用的、访问比较高的、经常要运算的数据)放在内存数据库里，而把历史性数据放在磁盘数据库里，可为用户进一步减少投资。

对于内存数据库而言，可以将同样数据库的部分内容存放于磁盘上，而另一部分存放于内存中。用户可以选择将数据存储在内存表中以提供即时的数据访问。若访问时间不紧急或数据存于内存中所占空间过大时，用户可将这些数据存入磁盘表中。

比如，在手机用户开始拔打电话时，如果应用基于内存数据库技术的混合数据管理引擎，就通过内存表检索其服务选项并立即验证用户身份，而将通话清单和计费清单归档到磁盘表中。从而，达到了速度与资源使用的平衡。

内存数据库的技术，一个很重要的特点，是可以对内存中的数据实现全事务处理，这是仅仅把数据以数组等形式放在内存中完全不同的。并且，内存数据库是与应用无关的，显然这种体系结构具有其合理性。内存引擎可以实现查询与存档功能使用的是完全相同的数据库，同时内存表与磁盘表也使用的是完全相同的存取方法。存储的选择，对于应用开发者而言是完全透明的。

对于内存数据库而言，实现了数据在内存中的管理，而不仅仅是作为数据库的缓存。不像其它将磁盘数据块缓存到主存中的数据库，内存数据库的内存引擎使用了为随机访问内存而特别设计的数据结构和算法，这种设计使其避免了因使用排序命令而经常破坏缓存数据库性能的问题。通过内存数据库，减少了磁盘I/O，能够达到了以磁盘I/O为主的传统数据库无法与其相比拟的处理速度。

因此，内存数据库技术的应用，可以大大提高数据库的速度，这对于需要高速反应的数据库应用，如电信、金融等提供了有力支撑。

由于把大多数数据都放在内存中进行操作，使得内存数据库有着比磁盘数据库高得多的性能表现，这一特点非常契合电信企业运营支撑系统对实时性的要求。

电信业的竞争正在全方位地展开，这种竞争必然带来新的价值链模式以及新的计费方式，这些变化对目前的电信运营支撑系统是一个挑战。比如，多种业务的计费环节将不再是单一的按照时长或通信距离收取费用，而可能是根据时长、内容、使用量等多种参数的组合计费。为了应对这些挑战，电信企业先后引入了内存数据库，以提高后台数据管理的实时性、精确性和灵活性。

尽管内存数据库已不是传统磁盘数据库的概念，但是内存数据库本质上还是数据库，它也具有一般数据库的基本功能:

■永久数据的管理，包括数据库的定义、存储、维护等;

■完成各种数据操作，如查询处理、存取、完整性检查;

■事务管理，包括调度与并发控制等;

■对存取的控制和安全性检验;

■具有数据库的可靠性恢复机制。

相对于利用程序开发手段调用内存处理来说，内存数据库自有其优势。首先，内存数据库是产品化的数据库管理软件，极大缩短了开发周期;其次，内存数据库有着开放的平台和接口，程序开发和移植更加灵活便捷，也便于维护和二次开发;第三，可以通过使用统一的SQL语言方便地查询内存中的数据;最后，能在数据库中保障数据的安全性和完整性。这些优势，对于快速部署和简化维护都是有利的。

但内存数据库也有其不可避免的缺点，比如:不容易恢复，内存数据库中的数据不总是永久的，为了保证实时，也不一定是一致和绝对正确的，有的是短暂的，有的是暂时不一致或非绝对正确的。

电信企业一直是内存数据库的主要用户，近几年来，随着计算机硬件技术的飞速发展、内存容量的提高、价格下跌以及计算机进入64位时代操作系统后可以支持更大的地址，为内存数据库的实现提供了可能。目前内存数据库在电信行业的应用也日趋成熟，已有超过90G的电信系统案例，能自动扩展内存空间，不需要重启数据库，提供ESOL自定义存储过程，支持多线程，开发效率高，程序移植容易等等。

下面以两个例子来介绍内存数据库的应用。

电信计费数据的加载

电信的二次批价和实时累账是计费系统中的两个必备功能。

所谓二次批价是相对于一次批价来说的。

一次批价是按照国家标准资费来进行价格计算，比如:全球通每分钟本地通话为0.4元，在一次批价完成后，会根据这个用户的套餐进行再一次的计算。以北京全球通用户接听4分钟的电话为例，一次批价完成后，这条话单的价格是1.6元，如果这个用户参加了10元包月接听套餐，那么在二次批价后，这次通话的费用就为0元。

一次批价是用于各大运营商之间结算的，而二次批价是针对用户个人的。

实时累账是将用户从每月1号到目前为止的所有费用累加起来，也就是用户目前可以通过10086查到截止到前一天的实时话费。累账值可以帮助用户控制高额话费或是供用户即时查询消费信息。

二次批价和实时累账过程涉及用户资料、用户套餐等与用户相关的信息，电信支撑系统在开始批价时必须加载这些数据。稍大一点的省级运营商的这些数据就会超过1000万条，计费处理模型也由于套餐的组合、产品的组合以及不同的优惠规则变得相当复杂，加载这部分数据对系统而言是一笔不小的开销，这就使得现在的计费处理速度比较慢，而且很难做到对数据的实时更新。内存数据库的引入在一定程度上解决了这个问题。

在计费二次批价过程中数据量最大的是详单数据，这部分数据不用放在内存数据库中，每处理完一个话单文件或达到设定的提交记录数时直接操作磁盘数据库，不会影响系统性能。最急切的是将用户资料、套餐、营业套餐和计费套餐对应关系数据、计费套餐模型数据及用户累计数据放到内存数据库中，这部分数据查询操作远比数据新增和更新操作要频繁。除了这些数据外，当然还有应用需要的其他数据也都可以加载到内存数据库。

在采用内存数据库后，用户通过营业部或客户查询实时话费的时候完全可以做到实时，比目前只能提供查询到前一天的实时话费在业务上有了质的飞跃。因为系统在处理这部分数据时查询流程和以前的完全一样，但系统省去了以往内存中的数据和磁盘数据库数据同步的环节，所以就能做到了实时查询。对于信控来说也同样，以往系统在累完账后要按照一定周期刷新信控数据，这就存在一个时间差，不能够完全做到实时。

而采用内存数据库后，信控可以直接取得内存数据库中的实时话费累计表中的数据，完全实现实时预警、停机。二次批价和累账中采用内存数据库后，对防欺诈、收入保障系统也有相当大的好处，这样能够充分保证运营商的切身利益。

另外，在采用内存数据库后，整体提高了系统批价、累账的处理速度，大大缓解访问磁盘数据库的压力，提高数据查询、修改、删除的效率，也为后付费和预付费的融合提供了可能。

电信计费数据的同步

电信营业数据和计费系统中的数据总是在不断的变化中，这就涉及内存数据库中的数据和磁盘数据库数据的同步问题(为了描述清楚，这里的磁盘数据库以OracleDB为例来说明)。数据同步包括两部分:从内存数据库到OracleDB数据同步和从OracleDB到内存数据库的同步。

1.OracleDB到内存数据库同步

这部分数据同步采用增量表的方式，营业系统或CRM新增或更新的数据将生成到Oracle的增量表中，计费后台程序先到这些增量表中查询数据。如果能在这些增量表中查到数据就把这些数据更新到内存数据库对应表中，如果查不到，就直接从内存数据库中直接查询，从而保证了数据的完整性和实时性。由于增量表的数据量一般会很小，所以这部分操作不会影响系统的性能。

2.内存数据库到OracleDB同步

由于Oracle的计费后台批价、累账数据几乎都加载到了内存数据库中，所以Oracle数据库对应的数据表将主要用于对内存数据库的数据备份。

用户最新的实时话费等信息都保存在内存数据库中，实时话费查询将直接连接到内存数据库中查询，保证用户得到最新的费用信息。信控也直接从内存数据库查询数据，因此对Oracle中的这部分数据已经没有实时性的要求。这时内存数据库到Oracle的同步可以由应用程序生成文件，定时地往Oracle数据库中同步备份，或者采用Oracle存储过程在系统相对空闲时间段进行数据导入就可以了。

总体而言，由于市场与技术的快速发展，电信业务在不断扩充，其运营和管理不断优化，传统的一些支撑系统的架构已经逐渐不能满足日益增长的业务要求和客户需求，引入一些新的技术来解决我们生产中遇到的问题是必然的。比如采用内存数据库来代替以前的共享内存技术，使得原来在内存中不标准的东西，包括接口、格式和管理都标准化了。

内存数据库只是多种新技术中有代表性的一种而已，只要解放思想、选用得当，完全可以在投入不大的情况下克服系统中的瓶颈，以最小的代价获得最大回报。

通用数据库大家见的多了，Oracle、Db2、Sqlserver、Sybase、Informix还有最近比较火的Mysql、和Pqllite，当然还不能忘记开源的PostgreSQL。通常情况下这些数据库可以承担重要业务，但是在要求高性能方面还是略有不足。在计费系统中如果用户信息常常改变的话延迟方面就会产生比较大的影响，甚至能影响到计费系统的正常运行。

我接触到唯一的内存数据库就是亚信在中移动计费中心稽核系统中使用的。由于稽核系统需要实施同步用户状态信息和订购信息，然后对产生的话单进行稽核，如果响应速度较慢的话就会产生错误的结果。最初没有稽核系统的时候，计费的标准基本是sp发过来的，然而用户方面却经常发现自己没有实际使用或者已经取消这项业务的时候，自己的帐单中仍然收取了费用，因此中移动决心要对sp的话单进行稽核，以自己的数据为标准，彻底剪断sp乱收费的手段。

如果要取到用户状态信息和订购信息的话就要从多个系统中同步过来，同时对话单进行稽核，中间的处理时间要求比较严格(用户可能会在短时间内检查自己的话费信息)，对系统响应时间就要尽量短。

通用数据库在这方面处于劣势。亚信就以三台rx8420作为数据库主机，将31个省用户的信息按照数量的多少分担到三台主机，每个省至少有一个入库进程，对于用户比较多的就采用多个进程进行入库。数据的采集来源主要是通过BOSS和计费的一级系统。

由于数据是存储在内存中，所以存储的数据结构和通用数据库有所差异，同时为了保证数据的安全，在磁盘上有一个内存数据的镜像，每隔一定时间将内存中的数据同步到磁盘上，当主机故障时可以通过磁盘恢复数据。当主机故障时，会有备用主机通过HA接管。但是对于数据操作的日志和回滚就没有Oracle做的好了，只提供了简单的恢复机制。

在计费系统中首先要对sp发来的话单进行稽核，主要标准是用户状态和订购信息。例如用户最近7天一直处于关机状态，如果sp的话单中出现新的订购信息就将此条话单作为错单处理。移动通过这种方式在和sp的博弈中取得主动。稽核系统上线后用户对于sp的投诉问题明显减少。

链接一:内存数据库与传统数据库的异同

传统的数据库系统是关系型数据库，开发这种数据库的目的，是处理永久、稳定的数据。关系数据库强调维护数据的完整性、一致性，但很难顾及有关数据及其处理的定时限制，不能满足工业生产管理实时应用的需要，因为实时事务要求系统能较准确地预报事务的运行时间。

对磁盘数据库而言，由于磁盘存取、内外存的数据传递、缓冲区管理、排队等待及锁的延迟等使得事务实际平均执行时间与估算的最坏情况执行时间相差很大，如果将整个数据库或其主要的"工作"部分放入内存，使每个事务在执行过程中没有I/O，则为系统较准确估算和安排事务的运行时间，使之具有较好的动态可预报性提供了有力的支持，同时也为实现事务的定时限制打下了基础。这就是内存数据库出现的主要原因。

内存数据库所处理的数据通常是"短暂"的，即有一定的有效时间，过时则有新的数据产生，而当前的决策推导变成无效。所以，实际应用中采用内存数据库来处理实时性强的业务逻辑处理数据。而传统数据库旨在处理永久、稳定的数据，其性能目标是高的系统吞吐量和低的代价，处理数据的实时性就要考虑的相对少一些。实际应用中利用传统数据库这一特性存放相对实时性要求不高的数据。

在实际应用中这两种数据库常常结合使用，而不是以内存数据库替代传统数据库。

链接二:几款内存数据库产品

■OracleTimesTen

OracleTimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库，它为应用程序提供了实时企业和行业(例如电信、资本市场和国防)所需的即时响应性和非常高的吞吐量。OracleTimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中，它利用标准的SQL接口对完全位于物理内存中的数据存储区进行操作。

■Altibase

Altibase是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。它提供高性能、容错能力和事务管理能力，特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。Altibase能够最大限度地发挥数据库服务系统的潜力，增强数据服务器的处理能力。Altibase支持客户端/服务器架构或嵌入式架构。其中客户端/服务器架构非常适合一般的应用。而嵌入式架构将应用程序嵌入到数据库服务器，适合于有高时效要求的实时系统。

■eXtremeDB

eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库，只有50K到130K的开销，速度达到微秒级。eXtremeDB完全驻留在主内存中，不使用文件系统(包括内存盘)。eXtremeDB采用了新的磁盘融合技术，将内存拓展到磁盘，将磁盘当做虚拟内存来用，实时性能保持微秒级的同时，数据管理量在32BIT下能达到20G。