依靠内存来存储数据的数据库管理系统，也称为内存数据库，成为了解决高并发、低时延数据管理需求的技术路线。近年来，随着动态随机存储器（DRAM）容量的上升和单位价格的下降，使大量数据在内存中的存储和处理成为可能，Redis、Memcached等内存数据库管理软件逐渐成熟，应用范围越来越广。
未来几年，随着非易失性存储器件（NVM）逐步投入商用，新硬件将会给内存数据库带来更大的发展机遇。
本白皮书阐述了内存数据库的概念，梳理了内存数据库的发展历史和核心属性，分析了在电商、直播和电信行业的典型应用场景，并对主流的内存数据库进行了介绍和对比，从技术和管理两个角度提出了产品选型和硬件选型建议，并总结了内存数据库的发展趋势：
内存数据库又称主存数据库（In-memory或main memory database），是一种主要依靠内存来存储数据的数据库管理系统。
在数据库技术中，有一类内存优化技术，是在传统的磁盘数据库中，增加内存缓冲池，也就是常说的共享内存技术，其主要目的是最小化磁盘访问。
而内存数据库技术，几乎把整个数据库放进了内存中，相较于传统数据库使用的磁盘读写机制，内存具备更极致的读写速度，性能会比传统的磁盘数据库有数量级的提升。因此内存数据库通常被用于对性能要求较高的场景中。
1.内存技术的成熟
内存器件的容量密度在快速上升。最早期的内存和今天常见的内存条不同，是直接焊接在主板上的内存芯片，容量普遍在64KB以下。
- 1982年之后，随着80286芯片的推出，开始出现30线（Pin）256KB的SIMM内存条，被认为是内存领域的开山鼻祖；
- 在80年代末，386和486时代的PC向16位发展，出现了72线的SIMM内存，单条容量可达512KB-2MB；90年代初，EDODRAM开始盛行，单条容量在4MB-16MB；
- 在1995年，计算机系统进入图形界面时代，内存技术也发生了重要变革，支持64位的SDRAM成为一代经典，在性能上有极大提升，容量也达到了64MB；
- 随后的十几年，内存容量开始稳定地遵循摩尔定律翻倍，持续到2019年，DDR3内存的容量已经可以达到16GB。
内存器件的单位价格也在逐年快速下降。从1970年代至今，内存每兆字节的价格下降了近9个数量级，根据2019年最新的统计数据，平均花费3-5美元就可以购买到1GB的内存。内存容量的持续上涨以及价格的下降，使大量数据在内存中进行存储和操作成为可能。
针对DRAM现存的一些硬件瓶颈，业界已经研发出了持久型内存（PM，Persistent Memory），学术名为存储级内存（SCM，Storage ClassMemory），和DRAM一样，都是安装在机器主板的内存槽接口中。
参考图2，DDRDRAM及以上的易失性存储CPU可以通过load/store指令直接访问，而NANDSSD及以下的非易失性存储CPU无法直接访问，需要先加载到易失性存储中，可以看出DRAM与SSD之间存在巨大的性能鸿沟，在访问时延上出现了跳变。
而持久型内存位于DRAM与SSD之间，以load/store指令的方式访问并支持数据的持久化，也填补了DRAM与SSD在时延上存在的鸿沟。相比DRAM，持久型内存在性能上处于劣势，但容量和价格均占据优势；相比NANDSSD，持久型内存在性能上处于优势，但容量和价值处于劣势。
3.内存数据库的发展历程
内存数据库的发展主要经历了雏形期、理论成熟期、市场成长期及高速发展期四个阶段。
7.内存数据库选型建议
技术服务于业务，内存数据库的选型应首先遵循业务场景的需求。业务特性决定了数据的应用特性，包括数据量、并发度、读写特性、一致性、响应时间、操作复杂度、业务连续性等要求，对应数据库的一致性、容错性、扩展性、安全性等技术要求。在做内存数据库的选型前，建议先梳理业务需求并进行量化；再将核心数据应用特性映射成数据库技术要求；最后按筛选出的技术要求进行选型。
1).技术因素
按照技术要求进行内存数据库选型时，可主要考察业务的性能、一致性要求和 SQL 兼容性三个因素。
业务是否有很高的性能要求？一般有高并发、低时延读写要求的业务，如游戏实时排行、直播粉丝关注等，建议选择内存数据库。
业务数据是否要求强一致性？如果业务对数据的可靠性和一致性要求较高、需要 ACID 级别的事务支持，则建议使用 MySQL 等传统的关系型数据库。但需要注意的是，强一致性的要求会对数据库的性能造成一定的影响；如果需要兼具高性能和强一致性，则需要在应用架构层面进行优化，单靠数据库的能力还无法实现。
数据处理是否要求 SQL 兼容性？在高性能要求的场景下，业务中如果数据结构固定、有复杂的关联计算要求，或是需要 SQL 无法支持的情况，建议使用关系型内存数据库；对于数据结构多变、扩展性要求高、数据模型和操作简单的场景，建议使用键值对内存数据库。
除了这三条考察指标，还可以结合数据容量、成本、扩展性、可维护性等需求进行综合考量。
2).非技术因素
上述选型方法主要考量的是技术因素，除此以外还可以结合实际情况，引入一些其他维度的考量，进行综合评估，最终挑选出适合的产品。包括但不限于以下维度：
- 1）生态成熟度。指数据库产品的状态，包括各种配套工具、技术架构成熟度、代码质量、开发模式、社区建设、商业支持服务、版权协议等；
- 2）应用架构适配度。指应用架构对数据库架构的兼容性、以及适配改造友好度，包括技术架构适配、开发语言适配等；
- 3）团队适应度。指开发团队、维护团队对数据库的熟悉程度、偏好程度、学习成本以及配套运维工具等。
