内存数据库是以牺牲内存资源为代价换取数据处理实时性的，内存数据库和磁盘数据库都是当今信息社会里每个企业所必须的关系型数据库产品，磁盘数据库解决的是大容量存储和数据分析问题，而内存数据库解决的是实时处理和高并发问题。两者的存在是相辅相成的，内存数据库的事务实时处理性能要远强于磁盘数据库。但是相对的，他的数据安全方面还没有达到磁盘数据库比肩的地步。
内存数据库将物理内存作为数据的第一存储介质，而将磁盘作为备份。随着电信业务的发展，系统对实时性的要求和对业务灵活修改的要求非常高，在此种情况下对于内存数据库的需求也越来越高。磁盘数据库的做法是将数据存入内存中进行处理，这种方式的可管理性及数据安全可靠性都没有保障。而内存数据库正是针对这一弱点进行了改进。
实际上，内存数据库并不是一项时髦技术，其出现于上世纪60年代末，但由于市场的需求原因在90年代后期才开始发展。作为新一代数据库，Altibase产品已经走向混合型数据库，其版本Altibase 4.0已经有一套自带的磁盘数据库，用户一旦购买了Altibase的内存数据库，就无须再购买磁盘数据库。它把热数据（经常被使用的、访问比较高的、经常要运算的数据）放在内存数据库里，而把历史性数据放在磁盘数据库里，可为用户进一步减少投资。
对于内存数据库而言，可以将同样数据库的部分内容存放于磁盘上，而另一部分存放于内存中。用户可以选择将数据存储在内存表中以提供即时的数据访问。若访问时间不紧急或数据存于内存中所占空间过大时，用户可将这些数据存入磁盘表中。
比如，在手机用户开始拔打电话时，如果应用基于内存数据库技术的混合数据管理引擎，就通过内存表检索其服务选项并立即验证用户身份，而将通话清单和计费清单归档到磁盘表中。从而，达到了速度与资源使用的平衡。
内存数据库的技术，一个很重要的特点，是可以对内存中的数据实现全事务处理，这是仅仅把数据以数组等形式放在内存中完全不同的。并且，内存数据库是与应用无关的，显然这种体系结构具有其合理性。内存引擎可以实现查询与存档功能使用的是完全相同的数据库，同时内存表与磁盘表也使用的是完全相同的存取方法。存储的选择，对于应用开发者而言是完全透明的。
对于内存数据库而言，实现了数据在内存中的管理，而不仅仅是作为数据库的缓存。不像其它将磁盘数据块缓存到主存中的数据库，内存数据库的内存引擎使用了为随机访问内存而特别设计的数据结构和算法，这种设计使其避免了因使用排序命令而经常破坏缓存数据库性能的问题。通过内存数据库，减少了磁盘I/O，能够达到了以磁盘I/O 为主的传统数据库无法与其相比拟的处理速度。
因此，内存数据库技术的应用，可以大大提高数据库的速度，这对于需要高速反应的数据库应用，如电信、金融等提供了有力支撑。
（以上引自 http://hi.baidu.com/bluesky0205/blog/item/2dde5d08df57fe9f0b7b8258.html）
由于把大多数数据都放在内存中进行操作，使得内存数据库有着比磁盘数据库高得多的性能表现，这一特点非常契合电信企业运营支撑系统对实时性的要求。
电信业的竞争正在全方位地展开，这种竞争必然带来新的价值链模式以及新的计费方式，这些变化对目前的电信运营支撑系统是一个挑战。比如，多种业务的计费环节将不再是单一的按照时长或通信距离收取费用，而可能是根据时长、内容、使用量等多种参数的组合计费。为了应对这些挑战，电信企业先后引入了内存数据库，以提高后台数据管理的实时性、精确性和灵活性。
尽管内存数据库已不是传统磁盘数据库的概念，但是内存数据库本质上还是数据库，它也具有一般数据库的基本功能:
■ 永久数据的管理，包括数据库的定义、存储、维护等;
■ 完成各种数据操作，如查询处理、存取、完整性检查;
■ 事务管理，包括调度与并发控制等;
■ 对存取的控制和安全性检验;
■ 具有数据库的可靠性恢复机制。
相对于利用程序开发手段调用内存处理来说，内存数据库自有其优势。首先，内存数据库是产品化的数据库管理软件，极大缩短了开发周期; 其次，内存数据库有着开放的平台和接口，程序开发和移植更加灵活便捷，也便于维护和二次开发; 第三，可以通过使用统一的SQL语言方便地查询内存中的数据; 最后，能在数据库中保障数据的安全性和完整性。这些优势，对于快速部署和简化维护都是有利的。
但内存数据库也有其不可避免的缺点，比如: 不容易恢复，内存数据库中的数据不总是永久的，为了保证实时，也不一定是一致和绝对正确的，有的是短暂的，有的是暂时不一致或非绝对正确的。
电信企业一直是内存数据库的主要用户，近几年来，随着计算机硬件技术的飞速发展、内存容量的提高、价格下跌以及计算机进入64位时代操作系统后可以支持更大的地址，为内存数据库的实现提供了可能。目前内存数据库在电信行业的应用也日趋成熟，已有超过90G的电信系统案例，能自动扩展内存空间，不需要重启数据库，提供ESOL自定义存储过程，支持多线程，开发效率高，程序移植容易等等。
下面以两个例子来介绍内存数据库的应用。
电信计费数据的加载
电信的二次批价和实时累账是计费系统中的两个必备功能。
所谓二次批价是相对于一次批价来说的。
一次批价是按照国家标准资费来进行价格计算，比如: 全球通每分钟本地通话为0.4元，在一次批价完成后，会根据这个用户的套餐进行再一次的计算。以北京全球通用户接听4分钟的电话为例，一次批价完成后，这条话单的价格是1.6元，如果这个用户参加了10元包月接听套餐，那么在二次批价后，这次通话的费用就为0元。
一次批价是用于各大运营商之间结算的，而二次批价是针对用户个人的。
实时累账是将用户从每月1号到目前为止的所有费用累加起来，也就是用户目前可以通过10086查到截止到前一天的实时话费。累账值可以帮助用户控制高额话费或是供用户即时查询消费信息。
二次批价和实时累账过程涉及用户资料、用户套餐等与用户相关的信息，电信支撑系统在开始批价时必须加载这些数据。稍大一点的省级运营商的这些数据就会超过1000万条，计费处理模型也由于套餐的组合、产品的组合以及不同的优惠规则变得相当复杂，加载这部分数据对系统而言是一笔不小的开销，这就使得现在的计费处理速度比较慢，而且很难做到对数据的实时更新。内存数据库的引入在一定程度上解决了这个问题。
在计费二次批价过程中数据量最大的是详单数据，这部分数据不用放在内存数据库中，每处理完一个话单文件或达到设定的提交记录数时直接操作磁盘数据库，不会影响系统性能。最急切的是将用户资料、套餐、营业套餐和计费套餐对应关系数据、计费套餐模型数据及用户累计数据放到内存数据库中，这部分数据查询操作远比数据新增和更新操作要频繁。除了这些数据外，当然还有应用需要的其他数据也都可以加载到内存数据库。
在采用内存数据库后，用户通过营业部或客户查询实时话费的时候完全可以做到实时，比目前只能提供查询到前一天的实时话费在业务上有了质的飞跃。因为系统在处理这部分数据时查询流程和以前的完全一样，但系统省去了以往内存中的数据和磁盘数据库数据同步的环节，所以就能做到了实时查询。对于信控来说也同样，以往系统在累完账后要按照一定周期刷新信控数据，这就存在一个时间差，不能够完全做到实时。
而采用内存数据库后，信控可以直接取得内存数据库中的实时话费累计表中的数据，完全实现实时预警、停机。二次批价和累账中采用内存数据库后，对防欺诈、收入保障系统也有相当大的好处，这样能够充分保证运营商的切身利益。
另外，在采用内存数据库后，整体提高了系统批价、累账的处理速度，大大缓解访问磁盘数据库的压力，提高数据查询、修改、删除的效率，也为后付费和预付费的融合提供了可能。
电信计费数据的同步
电信营业数据和计费系统中的数据总是在不断的变化中，这就涉及内存数据库中的数据和磁盘数据库数据的同步问题（为了描述清楚，这里的磁盘数据库以Oracle DB为例来说明）。数据同步包括两部分: 从内存数据库到Oracle DB数据同步和从Oracle DB到内存数据库的同步。
1. Oracle DB到内存数据库同步
这部分数据同步采用增量表的方式，营业系统或CRM新增或更新的数据将生成到Oracle的增量表中，计费后台程序先到这些增量表中查询数据。如果能在这些增量表中查到数据就把这些数据更新到内存数据库对应表中，如果查不到，就直接从内存数据库中直接查询，从而保证了数据的完整性和实时性。由于增量表的数据量一般会很小，所以这部分操作不会影响系统的性能。
2. 内存数据库到Oracle DB同步
由于Oracle的计费后台批价、累账数据几乎都加载到了内存数据库中，所以Oracle数据库对应的数据表将主要用于对内存数据库的数据备份。
用户最新的实时话费等信息都保存在内存数据库中，实时话费查询将直接连接到内存数据库中查询，保证用户得到最新的费用信息。信控也直接从内存数据库查询数据，因此对Oracle中的这部分数据已经没有实时性的要求。这时内存数据库到Oracle的同步可以由应用程序生成文件，定时地往Oracle数据库中同步备份，或者采用Oracle 存储过程在系统相对空闲时间段进行数据导入就可以了。
总体而言，由于市场与技术的快速发展，电信业务在不断扩充，其运营和管理不断优化，传统的一些支撑系统的架构已经逐渐不能满足日益增长的业务要求和客户需求，引入一些新的技术来解决我们生产中遇到的问题是必然的。比如采用内存数据库来代替以前的共享内存技术，使得原来在内存中不标准的东西，包括接口、格式和管理都标准化了。
内存数据库只是多种新技术中有代表性的一种而已，只要解放思想、选用得当，完全可以在投入不大的情况下克服系统中的瓶颈，以最小的代价获得最大回报。