CMU15-445 数据库系统播客：Oracle In-Memory 数据库揭秘 - 双格式架构如何驱动实时企业

为了满足这一需求，数据库技术必须进化。传统磁盘数据库的 I/O 瓶颈使其难以胜任， 内存数据库（In-Memory Database） 因此应运而生，成为推动这场变革的核心技术。

需求：实时企业的速度渴求

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

在当今数据驱动的世界里，“实时”不再是加分项，而是必需品。无论是保险公司需要秒级评估风险调整保费，零售商希望在顾客离店前推送个性化优惠，还是金融机构必须即时识别并拦截欺诈交易，这些场景都对数据处理速度提出了前所未有的要求。企业需要一个能够即时响应数据变化并迅速做出决策的强大引擎。

为了满足这一需求，数据库技术必须进化。传统磁盘数据库的 I/O 瓶颈使其难以胜任，内存数据库（In-Memory Database）因此应运而生，成为推动这场变革的核心技术。

创新的基石：飞速发展的硬件趋势

Oracle In-Memory 技术的诞生并非空中楼阁，而是建立在坚实的硬件发展之上。以下几大趋势为其提供了可能性：

海量廉价的内存：DRAM 乃至新兴的持久化内存（Persistent Memory, PMEM），为将海量数据置于内存中提供了经济可行性。多级高速缓存：现代 CPU 拥有越来越大的 L3 缓存（例如 32MB），能极大加速热点数据的访问。众核处理器：拥有数十个核心的 CPU 提供了强大的并行处理能力。SIMD 向量处理：单指令多数据（Single Instruction, Multiple Data）技术，如 AVX-512，允许 CPU 在一个时钟周期内对多个数据单元执行相同操作，是实现数据扫描加速的“核武器”。高速网络与 NUMA 架构：100Gb/s RoCE 等技术加速了节点间数据传输，但也带来了对 NUMA（Non-Uniform Memory Access）架构下内存访问延迟差异的关注。

在这些趋势中，Oracle 尤其将持久化内存（PMEM）视为“游戏规则的改变者”。它容量远大于 DRAM，速度远快于闪存，且数据在断电后不丢失。这意味着不仅可以将整个工作负载放入内存，还能极大提升数据库的可用性和重启速度。

核心架构：两全其美的“双格式”设计

传统数据库设计面临一个经典的二选一难题：行式存储还是列式存储？

行式存储 (Row Format)：数据按行连续存放。这非常适合事务处理 (OLTP)，例如更新一名用户的个人信息，因为所有相关字段都在一起，一次 I/O 即可完成。但对于分析查询（如计算所有用户的平均年龄），则效率低下，因为它需要读取大量无关数据。列式存储 (Column Format)：数据按列连续存放。这天然适合分析查询 (Analytics)，计算平均年龄只需读取“年龄”这一列，数据紧凑，缓存效率极高。但对于 OLTP 操作，更新一行数据则可能需要修改多个分散的文件，效率很低。

Oracle 的天才之处在于它没有选择，而是全都要。其双格式架构 (Dual-Format Architecture)在内存中同时维护了两种数据表示：

行式存储：存在于传统的缓冲区缓存 (Buffer Cache) 中，用于服务高速的 OLTP 操作。列式存储：存在于全新的内存列存储 (In-Memory Column Store) 中，用于服务闪电般的分析查询。

这两种格式同时活跃且事务一致。最妙的是，数据库的查询优化器会自动判断查询类型，智能地选择最佳路径——OLTP 查询走行存储，分析查询走列存储，整个过程对应用透明，无需任何代码修改。

关键挑战：如何维持数据实时一致？

双格式架构面临的最大挑战是数据一致性。当一行数据被修改（UPDATE或DELETE）时，如何高效地同步到列存中而不拖垮性能？

Oracle 的解决方案非常巧妙：

DML 操作优先在行存中进行，这沿用了 Oracle 数据库数十年的成熟机制，确保了事务的稳定和高效。操作完成后，系统仅通过行 ID 在列存中将受影响的行标记为“无效”。这是一个极轻量的元数据操作，几乎不产生开销。后续的分析查询在扫描列存时，会自动跳过这些被标记为无效的行。如果查询确实需要这些行的最新数据，系统会智能地从行存（Buffer Cache）中获取，确保结果的实时一致性。

但如果无效行越积越多，性能终将下降。为此，Oracle 引入了快速后台数据重填充 (Fast Background Repopulation)机制，它像一个智能的垃圾回收器：

智能监控：系统持续跟踪每个内存压缩单元 (IMCU) 的“脏”数据比例和访问频率。双缓冲无缝切换：当一个 IMCU 需要刷新时，系统会在后台创建一个全新的、干净的副本。在此期间，旧的 IMCU 仍然可以服务查询。待新副本准备就绪后，系统会原子地将请求切换过去，整个过程对用户查询零中断。增量与列级优化：重填充过程是增量的，可以复用旧列的元数据（如字典编码），避免从零开始的昂贵计算。如果 DML 只修改了少数几列，那么未受影响的列无需重填充，访问它们的查询性能丝毫不受影响。

性能引擎：每秒数十亿行的向量化分析

如果说双格式架构是骨架，那么向量化分析 (Vectorized Analytics)就是让 Oracle In-Memory 快如闪电的肌肉。它充分榨干了现代 CPU 的SIMD能力，实现了单核每秒处理数十亿行的惊人吞吐量。

SIMD 扫描：传统扫描是逐行比较。而 SIMD 扫描可以将几十个数据（如“州”名）一次性加载到 512 位宽的向量寄存器中，然后用一条指令完成所有比较操作。判断 64 个州是否为“加利福尼亚”只需一个 CPU 周期，效率提升数十倍。SIMD 连接 (Joins)：通过引入连接组 (Join Groups)的概念，用户可以提示数据库哪些列常用于连接。Oracle 会使用相同的字典对这些列进行编码，使得昂贵的哈希连接退化为简单的数组索引匹配，性能可再提升 2-3 倍。SIMD 聚合 (Aggregations)

聚合下推 (Aggregation Push-Down)：将SUM,COUNT等聚合计算直接下推到数据扫描层，在压缩的、SIMD 友好的列格式上直接完成。这极大地减少了需要向上传递到 SQL 执行层的数据量，性能提升可达 2-10 倍。

大数求和优化：针对 Oracle 特有的NUMBER类型（可表示极大或极高精度的数字），传统的逐个加法非常耗时。Oracle 通过构建频率表，将多次加法操作巧妙地转换为一次乘法，可将复杂算术聚合性能提升高达 20 倍。

超越内存：与 Exadata 集成，容量无限扩展

尽管内存越来越大，但总有数据放不下的情况。Oracle 通过其工程系统Exadata完美解决了这个问题，将内存处理能力延伸到了存储层。

智能闪存缓存 (CellMemory)：Exadata 的存储节点配备了大量闪存。这部分闪存可以被配置为列式缓存。数据库会自动将次热点数据以列式格式缓存于此。存储分层：由此形成了一个自动化的数据分层体系：

最热数据：驻留在 DRAM 的内存列存储中。

温数据：驻留在 Exadata 闪存的列式缓存中。

冷数据：保留在磁盘上。

存储层计算：最关键的是，在闪存中也可以执行向量化扫描、连接和聚合等操作。查询可以直接在存储节点上完成大部分过滤和计算工作，只将最终的少量结果集返回给数据库节点，极大地减轻了网络负担和 CPU 压力，实现 5-10 倍的智能扫描加速。

迈向未来：自驱动的智能自动化

手动管理哪些数据应该放入内存是一项极其复杂的任务，因为业务的访问模式总是在变。Oracle 的最终目标是实现“自驱动数据库 (Self-Driving Databases)”。

热力图 (Heat Map)：系统在后台持续监控数据块级别的访问模式，精准地识别出数据的“热度”。自动填充与驱逐：根据热力图，数据库会自动将热点数据加载到内存中，同时将长期无人问津的冷数据移除，动态优化内存使用。列级别粒度：这种智能管理甚至可以细化到列级别。例如，系统可以识别出 TPCH 基准测试中的L_COMMENT列很少被查询，从而选择不将它加载到内存，或使用更高的压缩比，为更有价值的列腾出空间。混合扫描 (Hybrid Scans)：允许查询在扫描内存列存的同时，从行存中获取那些被排除在内存外的大列（如图片、文档），兼顾了性能和成本。

终极愿景：一站式的融合分析平台

Oracle 致力于将自身打造为一个“一站式 (One-Stop Shop)”的融合数据库。用户无需为了处理 JSON、空间地理、图、文本等不同类型的数据而购买、集成和维护多个专门的数据库。所有数据都可以存放在 Oracle 中，并享受 In-Memory 带来的极致加速。

JSON 加速：对 JSON 文档的查询性能可提升 20-60 倍。空间分析加速：通过内存中的空间摘要，空间查询速度可提升高达 10 倍。文本分析加速：融合了关系型数据和文本的查询速度可提升 3 倍。

这种融合架构不仅提升了效率，更重要的是增强了安全性，避免了将数据在不同系统间迁移所带来的风险。

结论

Oracle Database In-Memory 并非简单地将数据放入内存，而是一套围绕“双格式架构”构建的、深度整合了最新硬件特性和智能化管理思想的复杂系统。它通过向量化处理、与 Exadata 的软硬一体化设计、以及迈向自驱动的自动化管理，成功地解决了传统数据库在混合负载下的性能难题，为要求极致响应速度的实时企业提供了强有力的技术支撑。