内存数据库及技术选型

浅浅的花香味﹌ 2022-09-17 03:22 199阅读 0赞

> 开发者（KaiFaX）  
> 
> 
> **面向全栈工程师的开发者**  
>  专注于前端、Java/Python/Go/PHP的技术社区

来源 | 网络

依靠内存来存储数据的数据库管理系统，也称为内存数据库，成为了解决高并发、低时延数据管理需求的技术路线。近年来，随着动态随机存储器（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的内存。内存容量的持续上涨以及价格的下降，使大量数据在内存中进行存储和操作成为可能。

![60a916ff0ed737c992390edc7b3935d9.png][]

**2.内存技术的瓶颈与突破**

过去几十年，计算机系统的存储体系结构被设计成如图2的金字塔形模型。这样的存储结构利用局部性原理尽量将热数据存储在靠近CPU的地方。在传统模式中，内存数据库的所有数据都保存在DRAM介质中。

虽然DRAM的价格已经大幅下降，但在海量数据存储的需求下，内存的成本依然是很大的问题；另外由于DRAM属于易失性介质，掉电后所有数据都会丢失，需要额外考虑数据持久化的方案，会极大的限制内存数据库的性能和使用场景。

![dd46c0b6400d05f8188b1c24c0d1b1ec.png][]

针对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.内存数据库的发展历程**

内存数据库的发展主要经历了雏形期、理论成熟期、市场成长期及高速发展期四个阶段。

![60643bc0d19adeabe63d16a968ebfb14.png][]

**4.内存数据库的优势与挑战**

内存数据库在提供高性能读写能力的同时，也存在由于器件导致的数据易失问题，需要在应用中引起注意。

**1).优势：高性能读写**

由于省去了磁盘I/O的开销，在数据访问的时延上内存型数据库可以达到传统关系型数据库无法达到的微秒级别，单机内存数据库的QPS也可以达到10万以上，配合上用户态协议栈、内存大页等技术之后，更是可以轻松达到几十万QPS的量级，这是传统的关系型数据库很难做到的。

**2).挑战：内存数据易失**

内存数据库当前主要使用DRAM作为存储介质，DRAM属于掉电易失性介质，为了保证数据的可靠性，内存数据库需要考虑持久化方案。现阶段主流的键值对内存数据库对于持久化的支持较为薄弱，持久化性能也不如传统数据库。

内存型数据库中克服掉电易失性来保障数据可靠性的方法主要是以下两种：

*  一是每次操作都进行数据持久化，这种方式势必会大幅降低内存数据库的性能；
 *  二是按照一定的策略进行操作的持久化，这样可以达到一定程度的优化和缓解，但极端情况下数据丢失的情况仍不可避免。

现阶段新型的非易失性存储器件已经发布但尚未规模化商用。相信解决了存储易失性的难题后，内存数据库会具备更多的应用。

**5.内存数据库的分类**

主流的内存数据库可分为键值对内存数据库、关系型内存数据库以及其他数据库，用户可根据自身的业务需求选择适合自己的内存数据库类型。

**1).键值对内存数据库**

键值对（KV, Key-Value）内存数据库指的是一种以键值对为主要存储结构的内存数据库。键值对内存数据库通常按键进行数据存取操作，值通常支持各种数据类型，使用键值存储的数据模型相对简单，更适合要求性能高、计算简单的一些场景。键值对内存数据库的典型代表为 Redis、Memcached 和 Aerospike。

**2).关系型内存数据库**

关系型内存数据库是一种基于数据关系模型的内存数据库。关系型内存数据库将传统的关系型数据库表搬到内存中，支持通过 SQL语句的方式实现对内存数据的访问，在实现复杂分析功能的同时，提升数据访问速度。关系型内存数据库的典型代表软件为 Oracle TimesTen、SAP HANA、MemSQL 和 SQLite。

**3).其他类型的内存数据库**

除键值对内存数据库、关系型内存数据库之外，其他比较小众的内存数据库称为其他内存数据库，比如图内存数据库 RedisGraph 等。

**6.内存数据库产品现状**

DB-Engines Ranking 是公认较权威的数据库排行，我们选取了其中最为活跃的 10 款典型内存数据库进行对比。开源产品中，Redis 和 Memcached 是最受欢迎的两款键值对内存数据库；而 SQLite 是最受欢迎的关系型内存数据库。表中大部分的关系型内存数据库为商用数据库，其中热度最高的是 SAP HANA。

早在 1995 年就发布第一版的Oracle TimesTen 仍然在榜上活跃；2014 年新发布 Apache Ignite 兼容键值和关系型数据结构，热度正稳步攀升。事务支持方面，大部分的关系型内存数据库称可以支持 ACID，但都需要在性能上作出妥协。

![0131ea616d2230d1edd4e21fcb6f2928.png][]

**7.内存数据库选型建议**

技术服务于业务，内存数据库的选型应首先遵循业务场景的需求。业务特性决定了数据的应用特性，包括数据量、并发度、读写特性、一致性、响应时间、操作复杂度、业务连续性等要求，对应数据库的一致性、容错性、扩展性、安全性等技术要求。在做内存数据库的选型前，建议先梳理业务需求并进行量化；再将核心数据应用特性映射成数据库技术要求；最后按筛选出的技术要求进行选型。

**1).技术因素**

按照技术要求进行内存数据库选型时，可主要考察业务的性能、一致性要求和 SQL 兼容性三个因素。

![50f11424f7f068201cbdd8b38ad10b14.png][]

**业务是否有很高的性能要求？**一般有高并发、低时延读写要求的业务，如游戏实时排行、直播粉丝关注等，建议选择内存数据库。

**业务数据是否要求强一致性？**如果业务对数据的可靠性和一致性要求较高、需要 ACID 级别的事务支持，则建议使用 MySQL 等传统的关系型数据库。但需要注意的是，强一致性的要求会对数据库的性能造成一定的影响；如果需要兼具高性能和强一致性，则需要在应用架构层面进行优化，单靠数据库的能力还无法实现。

**数据处理是否要求 SQL 兼容性？**在高性能要求的场景下，业务中如果数据结构固定、有复杂的关联计算要求，或是需要 SQL 语法支持的情况，建议使用关系型内存数据库；对于数据结构多变、扩展性要求高、数据模型和操作简单的场景，建议使用键值对内存数据库。

除了这三条考察指标，还可以结合数据容量、成本、扩展性、可维护性等需求进行综合考量。

**2).非技术因素**

上述选型方法主要考量的是技术因素，除此以外还可以结合实际情况，引入一些其他维度的考量，进行综合评估，最终挑选出适合的产品。包括但不限于以下维度：

*  1）生态成熟度。指数据库产品的状态，包括各种配套工具、技术架构成熟度、代码质量、开发模式、社区建设、商业支持服务、版权协议等；
 *  2）应用架构适配度。指应用架构对数据库架构的兼容性、以及适配改造友好度，包括技术架构适配、开发语言适配等；
 *  3）团队适应度。指开发团队、维护团队对数据库的熟悉程度、偏好程度、学习成本以及配套运维工具等。

--------------------

1. 回复“m”可以查看历史记录；

2. 回复“h”或者“帮助”，查看帮助；

开发者已开通多个技术群交流学习，请加若飞微信：1321113940 (暗号k）进开发群学习交流

说明：我们都是开发者。视频或文章来源于网络，如涉及版权或有误，请您与若飞（1321113940）联系，将在第一时间删除或者修改，谢谢！

![5f5629dbf23db20dda7495ef2ac38271.png][]

开 发 者 ： **KaiFaX**

**面向全栈工程师的开发者**  
专注于前端、Java/Python/Go/PHP的技术社区

[60a916ff0ed737c992390edc7b3935d9.png]: /images/20220828/62a0402635934da097a761f410bd0386.png
[dd46c0b6400d05f8188b1c24c0d1b1ec.png]: /images/20220828/545ac1ad19f3440fb9dc8f4e0e29ec20.png
[60643bc0d19adeabe63d16a968ebfb14.png]: /images/20220828/98ca5c7bc9304b08b76407259900c64d.png
[0131ea616d2230d1edd4e21fcb6f2928.png]: /images/20220828/e587d996aa04488f99f29b74a873d651.png
[50f11424f7f068201cbdd8b38ad10b14.png]: /images/20220828/0c67bd1fb3e2438fb9b60e0ebd827137.png
[5f5629dbf23db20dda7495ef2ac38271.png]: /images/20220828/47394213d3c04186aefc0e5fb5e5eb2f.png