摘要：数据库存储引擎是数据库管理系统中用于处理存储任务和管理数据的核心组件。LSM-TREE和BTREE/HEAP两种分别适用于分布式数据库和传统通用型数据库的存储组织结构也都并非完美。LSM-TREE适合高并发写入，但读性能可能受影响；而BTREE/HEAP结构在数据读取和复杂查询上表现更好，但并发写入性能有瓶颈。而针对不同形式的数据库系统：单机集中式数据库、分布式数据库和共享存储多读多写架构的数据库，有点的背后往往也是缺陷所在，目前而言Oracle RAC这种共享存储对等读写架构依然是对应用最为友好的。华为开源的Cantian引擎是一个能让单机数据库具备类似Oracle RAC能力的中间件，目前支持InnoDB存储引擎，参天为数据库实现类RAC架构提供一条便捷的途径。

正文

数据库的存储引擎是数据库管理系统中用于处理不同类型的存储任务和管理数据的核心组件。它负责数据的存储、检索、更新和删除等操作。不同的存储引擎具有不同的特点和性能，以满足各种应用场景的需求。存储引擎是数据库的核心组件，存储引擎的一些特性决定了数据库的一些基本性能特性。

根据底层数据结构和数据组织方式来划分，目前数据库中使用最为广泛的存储引擎结构不外乎两个系列三种，分布式数据库喜欢采用的LSM-TREE存储，以及普通通用型数据库常用的BTREE/HEAP存储。BTREE和HEAP存储是两种十分相近的存储引擎结构，很多场合下，被看做是同一种存储结构。Oracle，PostgreSQL，MySQL等数据库都使用BTREE/HEAP结构。BTREE是一个泛称，实际上数据结构是一棵增强的B+TREE。

数据库存储引擎的量大阵营

这是一张来自网上的两大阵营的一些数据库产品的清单，我们可以看出传统数据库、集中式数据库使用B-TREE结构的比较多，而分布式数据库往往使用LSM-TREE。LSM-TREE是Log-Structured Merge Tree的简称，是一种典型的不可变结构的存储结构，其目的是为了降低可变结构存储结构中写入数据需要先找到已经存在的PAGE，然后再进行修改的成本，从而实现更高并发的写入。因此使用LSM-TREE的数据库天生对高并发写入/修改操作十分友好。不过LSM-TREE结构也不是完美的，在读性能上需要在多个副本之间做协同，因此读性能会受到一定的影响。

Oracle块结构，典型的slotted page结构（HEAP）

HEAP/BTREE存储结构虽然从结构上来说比较接近，不过依然存在一定的差异。在我们常见的数据库中，Oracle、PostgreSQL等是采用HEAP结构的，这种结构的页和不同的BTREE页不同，采用slotted page。Mysql、达梦等数据库使用的是传统的BTREE存储结构。

MySQL的BTREE存储结构

上面是MySQL innodb存储引擎的一个逻辑示意图，这是一种典型的BTREE结构存储引擎。BTREE结构的存储引擎也不是完全相同的。主要的区别是leaf node segment是否和数据存储在一个段里。和MySQL不同，达梦明显是分开的。实际上BTREE结构的存储结构，所有的数据存储都是按照主键的顺序存储的。

实际上这么说也不是很准确，只能说这些数据库的默认存储引擎是使用这种数据组织方式的。实际上Oracle中有heap表，有簇表，有混合列压缩的表。其中簇表是BTREE结构的。达梦的存储引擎有多种数据组织方式：B树数据、堆表数据、列存数据、位图索引，其中B树数据是普通的达梦表的默认组织方式。

一说到存储引擎的结构，就会有某某结构技术比较先进，比传统数据库的好这种说法。实际上再先进的存储引擎也有其缺点，某些人眼中的先进只是指出现的较晚而已。数据库的存储引擎经过数十年的发展，实际上到现在为止也并没有出现特别多的流派。

LSM-TREE的大量使用是在内存成本大幅下降之后，基于memtab可以大幅优化高并发写入的性能，同时SSTABLE可以更加充分的利用持久化存储，更加有利于数据压缩。LSM-TREE被大规模应用到OLTP关系型数据库上则是SSD逐渐普及后才出现的，因为开销巨大甚至可能导致系统不稳定的后台压缩让对于延时十分敏感的OLTP系统无法承受。而SSD可以缓解这种问题。

B-TREE/HEAP存储结构（以下简称B树引擎）一般采用IN-PLACE-REPLACE（PostgreSQL的ASTORE是个特例），所以其性能相对稳定，虽然会因为页碎片而导致一些浪费，但是总体来说是较为均衡的。与LSM-TREE相比，因为B树的这个特点导致并发写入的性能是会遇到瓶颈的。测试每隔5分钟有数亿条数据并发写入，并需要进行实时统计分析的场景，在Oracle数据库上在每秒写入1000万条以后明显就很难提升了，而在使用LSM-TREE的分布式数据库中，很轻松就超过2000万/秒。虽然在写入上B树存储结构的性能无法与LSM-TREE相媲美，不过B树存储结构在数据读取上有着明显的优势。在MVCC的实现上，以及对数据的复杂查询上面，B树都比LSM-TREE有明显的优势。

实际上两种存储结构的一些优缺点也并不容易区分清楚，如果站在某个立场上，就会有不同的分析结论。比如写放大的问题上，LSM-TREE的支持者会说LSM-TREE结构更加紧凑，数据没有碎片，而B树存储引擎经常会出现某个PAGE中只写了很少一部分数据，导致写被放大了。实际上LSM-TREE虽然不存在这种写放大，但是在大吞吐量写的场景下底层的SSTABLE可能会频繁的进行合并，也会造成写放大现象。但由于现代硬件对于写IO的能力已经极大提高了，这个问题其实并不会对绝大多数场景造成影响。

决定存储引擎技术能力的因素不只是取决于底层数据的组织方式，作为数据库中的量大核心引擎之一，从广义上讲，存储引擎的主要作用包括：

• 数据存储：将数据物理地存储在磁盘或其他存储介质上。
• 数据检索：根据查询条件快速高效地检索数据。
• 数据更新：处理数据的插入、更新和删除操作。
• 事务管理：保证数据的一致性和完整性，通过支持事务实现原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），即ACID属性。
• 并发控制：在多个用户并发访问时保证数据的一致性和完整性。
• 数据备份和恢复：支持数据的备份和恢复，保障数据的安全性。

因此一个优秀的数据库对存储引擎的要求不仅仅限于存储组织形式，目前的数据库有单机集中式数据库、共享存储读写分离数据库、共享存储多读多写数据库和分布式数据库等多种形式。不同形式的数据库系统，其存储引擎都各有特点。

其中单机集中式数据库架构比较简单，适合场景比较丰富，运维也比较简单，颇受用户青睐。但是因为其单机架构，因此只能SCALE-UP，无法横向扩展，对于业务发展比较迅速的客户来说，有时候不敢选择。再加上单机集中式数据库只能通过主从复制构建高可用复制组，当主库故障时切换比较麻烦，自动化程度较低，切换速度也无法支撑某些核心业务系统。

分布式数据库虽然解决了单机集中式数据库的部分痛点问题，但是因为其分布式架构带来的大型化、复杂性等问题，再加上集群网络延时对某些特性的应用的性能影响（比如存储过程性能下降的问题），因此往往只能在一些经费相对比较充裕的系统中使用。

实际上对于用户来说，类似Oracle RAC的共享存储多读多写架构的数据库是目前而言应用最为广泛的。多个计算节点共享一个集中式的存储系统，不会带来过多的资源浪费。通过横向扩展集群节点可以较为线性地扩充业务负载能力，某个节点故障时应用可以秒钟级自动切换到活着的其他节点，这些特性都为企业应用提供了足够的能力保障。同时因为数据库从本质上还是集中式数据库，对于应用开发也比较友好，运维的难度也不会很大。

不过因为共享存储多读多写架构对存储引擎的整体要求较高，需要解决缓冲区融合、全局锁管理、全局资源目录、全局事务管理、全局一致性恢复等重大难题，因此目前除了Oracle之外，能够提供此架构的优秀数据库产品十分稀缺。

DTCC 2023上，华为团队发布了一个Mysql的共享存储并发读写的解决方案，其核心技术就是华为Cantian引擎，该项目已经在木兰社区开源，名称是openEuer/Cantian。用最简单的一句话来描述：“Cantian是一个能让普通的单机数据库变成具有类似Oracle RAC能力数据库的中间件，目前支持innodb，今后将支持更多的数据库存储引擎。” Cantian引擎采用了存算分离架构，通过分布式缓存技术、事务MVCC机制、多主集群高可用等关键技术，使得普通的单机数据库能够具有类似Oracle RAC的多读多写能力，可以以无侵入的方式被MySQL等数据库加载运行，无需修改已有数据库的实现。Cantian问世一年多时间以来，在金融行业、运营商均有头部客户进行了业务验证，凭着其业务创新，Cantian引擎荣获IT168 2024年度技术卓越奖。

上图是Cantian的一个逻辑架构图，基于华为的OceanStor Dorado高端存储系统，Cantian引擎在MySQL的SQL引擎与innodb存储引擎之间构建了一个中间层，这个中间层可以模拟innodb的行为，因此MySQL的SQL引擎可以十分方便的与之对接。因为innodb和事务控制是紧密相关的，因此Cantian里除了包含MySQL的存储层外还包含了MySQL的事务管理层。在MySQL中引入Cantian引擎的好处是，加入这个中间层后，MySQL就具备了多节点并发读写的能力，摇身一变就变成了MySQL RAC了。作为开源引擎，Cantian大量参考了Oracle RAC的成功实践，比较好地解决了跨实例一致性读写问题，可以为目前想做共享存储多读多写架构的国产数据库厂商的重要参考。

从上面的分析来看，作为RDBMS的核心组件，存储引擎确实决定了数据库的很多能力特性。不过目前还没有完美的存储引擎，每个引擎都有其优点，也同时必然有其缺点。数据库系统走到今天，已经不是简单的一个软件系统了。我们要做的实际上是利用现代硬件的特点，尽可能的弥补其缺点，发扬其优点，从而让存储引擎的优点得到发挥，缺点得到掩盖。在这方面，Cantian的思路其实是可以借鉴的。另外一方面，用户在为其应用选择数据库产品的时候，也需要充分了解到某个存储引擎的优点和缺点，从而判别该数据库是否适合他们的应用场景。