DBPA · 17.2

内存数据库实现、恢复与异构展望

内存布局、并发恢复和异构执行需要协同设计

VER. 2608.3 Built with impress.js

学习目标

完成本节后，你应该能够

01比较行、列、向量化和实时编译四种处理模型
02解释 CSB+、Radix 分区和 NUMA-aware 排序合并分别优化哪些硬件代价
03区分锁、乐观并发控制、无锁结构和快照隔离 snapshot isolation 的协调方式
04解释日志、检查点、重做、热点优先和并行恢复的关系
05按迁移成本、负载边界和硬件条件比较三类实现路线
06分析异构硬件与 HTAP 的同步、调度和资源隔离边界

2/14

LEARNING OBJECTIVES

内存布局的三种方式

同一 ORDER 表可以用不同布局服务事务、分析和追加

同一 ORDER 表的三种存储布局对照：磁盘 page-slot、内存列存储，以及列存储中的可增长行组 — 行组是列存储中的一种可增长组织方式；三种布局都仍需配合日志、恢复和持久化路径

ORDER 表的三种布局：磁盘页槽、内存列存与列存中的可增长行组

行存储与列存储是典型适配，具体结构取决于负载；行组属于列存储，是可增长的组织单元

3/14

MEMORY STORAGE

同一表达式可采用多种处理模型

行处理、列处理、向量化和实时编译分别摊薄不同的重复开销

Price、Quantity 和 Tax 表达式在行处理、列处理和向量化模型中的执行差异；实时编译由正文另行说明 — 行、列和向量化是图示的处理模型；向量大小按 Cache 与工作负载调优，实时编译属于另一类执行优化

01行处理逐条访问记录属性并计算；它重复的是记录迭代、属性定位和函数调用，不是 SQL 语法解析
02列处理批量访问整列，减少重复函数调用，但可能产生较大的临时列空间
03向量化按 Cache 与工作负载选择连续数据块，保留列处理批量优势并降低中间结果代价
04实时编译把热点表达式编译为机器码或中间级字节码，减少记录解析和函数调用；是否采用取决于系统实现

4/14

QUERY MODELS

硬件敏感的数据结构与算法

等价算法的硬件代价可能不同

技术	关注的硬件问题	直观收益
CSB+ 树	按 Cache line 连续组织节点组，减少指针和地址跳转	缓存友好的索引访问
Radix 哈希连接	分区后让哈希表更接近 Cache 容量，减少 Cache 和 TLB 失效	分区探测局部性更好；付出分区时间和空间
NUMA-aware 排序合并	先在节点内局部排序，再处理跨节点归并	减少远程访问；仍需承担归并协调

Takeaway

硬件敏感算法通过布局、分区和归并改善局部性；收益取决于数据规模、带宽和跨节点竞争

5/14

HARDWARE CONSCIOUS

内存事务的并发取舍

锁粒度、乐观并发控制、无锁结构和快照隔离分别改变协调方式

锁粒度

较大粒度可减少锁管理元数据，但可能扩大冲突范围；短事务不等于低冲突

乐观并发控制

乐观并发控制在低冲突负载下可减少等待；提交检查失败时需要重试或回滚

无锁结构

无锁结构用原子操作降低锁竞争，但仍需处理同步、可见性和内存回收成本

快照隔离

快照隔离为 OLAP 只读查询提供一致视图；它是并发隔离机制，不是恢复快照

Takeaway

当订单更新与长分析共享数据时，需要同时判断冲突范围、读视图、提交检查和资源占用

6/14

CONCURRENCY

日志、检查点与并行恢复

快照隔离处理并发读视图；恢复根据日志和检查点重建可用状态

01日志写入非易失性介质，为后续重做提供依据
02检查点保存恢复基线，仍需结合日志重做；它不一定是完整可重启状态
03预提交或组提交降低提交等待，但不消除日志成本
04崩溃后可按策略优先恢复热点数据，其他数据随后装载
05数据分区与日志分区保持对应，多核心才能更安全地并行恢复

并行恢复可以缩短等待，但持久性写入、检查点、重做顺序和并行协调仍有代价

7/14

RECOVERY

三类内存实现路线

三种方案是并列的架构选择，适用条件取决于负载、迁移成本和硬件边界

方案	基础边界	迁移／同步代价	适用条件与限制
混合加速引擎	在传统系统旁增加内存行／列路径	接口复用；仍有副本、转换和资源竞争	适合渐进升级；仍需隔离事务与分析
独立内存数据库	重做存储、索引和执行底层	迁移与运维边界较大	适合愿意重做系统的低延迟事务或分析
GPU 数据库	CPU 与 GPU 异构执行	需要承担数据传输、恢复和控制流成本	适合规则、大批量、计算密集型分析

8/14

THREE OPTIONS

以订单系统判断三类路线的适用条件

判断路线时，要看数据放在哪里、各引擎执行什么，以及迁移和同步的代价

混合引擎

混合引擎保留已有订单系统接口，可增加内存行／列路径；副本同步和资源隔离仍有代价

独立系统

独立系统适合事务与分析都要求低延迟且愿意重做布局、索引和恢复的场景；迁移与运维边界更大

GPU 引擎

区域销售汇总等规则、大批量的分析适合 GPU；数据传输、控制流和恢复路径必须可控

Takeaway

方案选择取决于负载、数据规模、迁移成本和 CPU／GPU 边界，三类方案是并列路线

9/14

IMPLEMENTATION EXAMPLES

异构硬件的三层权衡

硬件机会需要数据库重新设计存储、执行和恢复，统一引擎并非必然结果

存储层

DRAM 与 NVM 按访问频率、容量、成本和持久性分工；数据放置本身有代价

计算层

CPU、GPU、FPGA 等处理器按算子和并行度分工；并非所有查询都适合加速

互连层

PCIe、RDMA、NVLink 等可降低传输代价，但不能消除数据移动、同步和恢复问题

异构数据库仍需同时优化数据放置、查询执行、恢复和资源调度

10/14

FUTURE HARDWARE

HTAP 展望：行列、同步与隔离需要协同

行列布局、数据可见性和资源隔离共同决定 HTAP 的实现边界

存储融合

事务行存与分析列存可以并存或转换；行列适配是典型路线，不是 HTAP 的唯一形式

数据可见性

日志、副本、提交语义和查询调度共同决定分析何时看到最新事实

资源隔离

长分析不能挤占短事务；CPU／GPU 调度能缓解冲突，但不保证零延迟

Takeaway

HTAP 的实现需要在存储、可见性和资源隔离之间做取舍，不保证单一物理存储、始终读取最新数据或自动消除资源竞争

11/14

HTAP OUTLOOK

内存数据库实现需要同时满足性能、可靠性与迁移边界

性能取决于硬件敏感优化，故障恢复取决于恢复设计，方案选择受迁移和负载边界约束

存储

行列布局与行组的选择取决于负载和增长方式

执行

列处理、向量化和实时编译降低重复执行与 Cache 访问代价

可靠性

并发控制、日志、检查点、热点优先和并行恢复共同决定故障后的恢复路径

方案

混合、独立和 GPU 方案都要处理 HTAP 的同步与资源隔离

Takeaway

性能优化和恢复设计必须同时考虑；方案选择还要看局部性、负载边界和迁移成本

12/14

RECAP

本节知识地图

13/14

KNOWLEDGE MAP

本节问题

01为什么把全部磁盘数据装入 DRAM 仍不自动等于内存数据库？
02向量化如何利用 Cache，为什么比整列处理更节省中间结果空间？
03CSB+、Radix 分区和 NUMA-aware 排序合并如何改善局部性，又付出什么成本？
04订单系统崩溃后，日志、检查点、热点优先和并行恢复如何接续？
05订单系统中的区域销售分析应如何在混合、独立和 GPU 路线之间选择？
06HTAP 的新鲜度、提交可见性和资源隔离分别受什么机制约束？

14/14

CHECK YOUR UNDERSTANDING