由来：
在传统的运营商领域，能追溯IT信息化开始大搞建设的应该是从97工程开始的，那个时候为了改变电信局人工接线、人工计价的局面，开发推广了一套软件系统，用于信息化管理电信业务的支撑，从业务开展到最后收费全面自动化处理。
从那个时期后，计费处理就慢慢演进为我们今天称为的计费系统。经过这么些年运营商领域分分合合，中国移动抓住了无线发展契机，迅速增长了用户，到写这篇文章为止，全国号称7亿手机客户，成为一家独大的运营商。
行业领域的系统演进也伴随着用户一路高涨增加，不断的改变系统的架构来适应业务的支撑。这里纯粹探讨技术思路，就不多说这些年系统架构演进了，那是另一个领域话题。
内存数据库在计费系统中的应用雏形是为了提升系统处理性能，通过将系统中实时计算使用记录信息的价格+套餐优惠产生的账单、用户的资料、用户的订购产品信息加载到内存中进行统一管理，避免系统直接操作物理数据库，解决系统计算量巨大情况下单笔与物理数据库交互的性能开销问题。
最初的内存数据库是计费系统应用程序自我管理的内存结构组织；但是这种实现思路存在几点问题：
1、普通内存管理，通过库的方式定义内存结构，嵌入到具体应用进程中进行API调用处理；
2、普通内存管理，各自进程负责加载各自的数据量，有部分数据信息因为业务夸地市、夸域的问题需要共享，因此重复冗余加载存在，浪费内存资源；
3、普通内存管理，事务的控制都是各自程序自我控制，对于应用开发来讲不够通用，没有提供基于关系型数据库操作，对于跨事务操作存在一定复杂性。
基于上述几个原因，又考虑到计费系统实时性的苛刻要求，催生了内存数据库的研发。同时一些商业软件如韩国的altibase、Oracle的TT也应运而生，迅速切入电信领域，结合自己的物理数据库产品。
从移动运营商自主研发的角度出发，我们这些支撑厂商还是在基础软件领域投入了研发，即自主研发贴合电信行业的内存数据库产品，用于帮助系统架构演进，后面会讲到，为什么自主研发对于系统架构的演进的重要性，这对系统演进不受制于人有非常大的关系，相信这点互联网企业的从业者应该深有体会。
数据量和实时性要求：
前面提到中移动用户7亿，从它分拆出来起步到达到这个用户规模，是飞速增加的。因此支撑全国7亿用户的计费系统面临的客户数据计算量巨大。所幸中移动针对这种情况在早期规划系统支撑，就将系统定位为两级架构，即分省为单位集中建设一套系统，同时全国总部建设一套系统负责各省业务的统一仲裁和全国性业务支撑。
一个2500万用户的省份，月产生用户通话等业务记录（简称话单）大约是500多亿条。我们支撑的省份2500万的比较多，其中马云故乡有超过5000万的规模，因此每月、每天计费系统处理数据量可想而知。运营商提供的各类优惠套餐，要求计费系统在一次标准计价后，再进行二次计算优惠，复杂的优惠还需要额定量、时间段、月结等多次计算。
大量计算，又要求用户能够实时查询到使用业务，结余、账单、话单变化的结果，同时针对每个用户使用记录的计价优惠到结余的计算要求控制在500-1000条/s以上的苛刻性能指标，这就要求系统处理数据一定不能够基于传统的物理库这种IO开销较大的存储模式。内存数据管理要求应运而生。
内存数据库：
引入内存数据库技术，运营商针对这种基于内存管理的技术提出具体要求。
1、高性能
(1) 提供内存数据访问机制，如通过HASH、T-tree索引访问；
(2) 采用多线程或者多进程架构最大程度的提高并发响应能力，降低系统负载；
(3) 采用锁机制，解决高并发情况下的锁冲突问题；
(4) 提供批量数据加载功能。
2、高可用性
(1) 提供7×24不间断服务，系统具有容错处理能力；
(2) 支持系统故障时服务的快速切换；
(3) 提供检查点的功能，定期备份，实现内存数据的快速恢复。
3、高可靠性
(1) 支持事务控制，提供事务提交、事务回滚机制；
(2) 支持内存到磁盘的同步与异步的写机制。
4、安全性
(1) 提供权限认证功能，防止非法访问内存数据；
(2) 提供同步数据包的合法性检测功能，防止系统异常；
主机间传递重做日志时，能够保障数据的安全性。
5、可扩展性
(1) 支持进行分布式部署；
(2) 支持负载均衡。
6、可维护性
(1) 提供维护工具，辅助管理员对内存数据进行各种操作；
(2) 提供维护工具，监控死锁、连接、系统资源等信息；
(3) 提供数据导入、导出工具，支持多种格式。
7、易用性
(1) 提供二次开发接口，快速响应业务需求；
(2) 支持跨主机、跨平台进行数据交换。
技术指标。
1、数据加载性能
(1)预置条件
表1-1 内存数据管理数据加载预置条件列表
| 项目 | 预置条件 |
| 服务器性能 | TPMC 200,000以上 |
| 数据量 | 表中所含数据500万条记录以上 |
| 索引 | 至少包括一个索引 |
| 数据行尺寸 | 大于128字节 |
（2）技术指标
表1-2 内存数据管理数据加载技术指标
| 指标项 | 要求 |
| 文本文件加载性能 | 大于50000条/秒 |
| 从商业数据库系统加载的性能 | 大于5000条/秒 |
| 从内存数据管理模块加载性能 | 大于10000条/秒 |
2、数据访问响应时间
在计费业务中，其数据访问绝大多数是按键值操作的方式，本节所描述的技术指标均为按键值操作的方式。
预置条件
表1-3 内存数据管理数据访问预置条件列表
| 项目 | 预置条件 |
| 服务器性能 | TPMC 200,000以上 |
| 数据量 | 表中所含数据500万以上 |
| 索引 | 至少包括一个索引 |
| 数据行尺寸 | 大于128字节 |
技术指标
表1-4 内存数据管理数据访问技术指标
| 指标项 | 要求 |
| 按键值查询 | 小于40微秒 |
| 数据插入 | 小于80微秒 |
| 按键值更新 | 小于60微秒 |
| 按键值删除 | 小于50微秒 |
3、并发访问能力
在计费业务中，其数据访问绝大多数是按键值操作的方式，本节所描述的技术指标均为最高并发能力下按键值操作的方式。
(1)预置条件
表1-5 内存数据管理并发访问能力预置条件列表
| 项目 | 预置条件 |
| 服务器性能 | TPMC 200,000以上 |
| 数据量 | 表中所含数据500万以上 |
| 索引 | 至少包括一个索引 |
| 数据行尺寸 | 大于128字节 |
| 每操作记录行数 | 1条 |
(2)技术指标
表1-6 内存数据管理并发访问能力技术指标
| 指标项 | 要求 |
| 按键值查询 | 大于80000次/秒 |
| 数据插入 | 大于40000次/ 秒 |
| 按键值更新 | 大于30000次/ 秒 |
| 按键值删除 | 大于30000次/ 秒 |
4、异常恢复时间
异常恢复指从内存数据的备份文件中恢复到内存中的过程，需要异常恢复的场景一般为通过磁盘镜像文件无法正常恢复数据的情况下，需要从备份文件中恢复数据。异常恢复的时长在系统实现、机器性能一定的情况下，和备份文件的大小有关。
(1) 预置条件
表1-7 内存数据管理异常恢复时间要求预置条件列表
| 项目 | 预置条件 |
| 服务器性能 | TPMC 200,000以上 |
(2) 技术要求
表1-8 内存数据管理异常恢复时间要求
| 指标项 | 要求 |
| 数据恢复的性能 | 大于15M/秒 |
| 重做日志恢复的性能 | 大于5M/秒 |
5、掉电恢复的时间
掉电恢复指从镜像文件恢复数据，并应用重做日志和清理掉电时的未提交事务。
(1)预置条件
表1-9 内存数据管理掉电恢复时间要求预置条件列表
| 项目 | 预置条件 |
| 服务器性能 | TPMC 200,000以上 |
(2)技术要求
表1-10 内存数据管理掉电恢复时间要求
| 指标项 | 要求 |
| 数据恢复的性能 | 大于20M/秒 |
| 重做日志恢复的性能 | 大于5M/秒 |
6、无差错工作时间
技术要求：大于6个月。
第二篇开始，将会结合支撑系统提出对于基于内存管理的内存数据库技术的要求，逐步整理出内存数据库的基本构成和技术选型。
总结：
一个复杂的生产支撑系统中，数据如何存放、系统计算中如何使用数据存储策略，一直是系统设计中很重要的部分。到现如今、各种缓存服务、内存数据库、非关系型数据库、开源存储项目，已经决定了一个系统存储策略不再单一，一定是根据数据需要的场景，混合完成支撑。
内存数据库是系统特殊场景的需要，因此在是否选择使用内存数据库作为系统关键业务支撑的方式，一定需要结合业务场景来决策。本文先起一个头，下篇开始正式介绍设计一个内存数据库基本构成、具备的功能特点，初步的技术选型，一步步开放经过5年实际生产系统运行支撑，并持续演进的自主研发内存数据库产品。