开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共880人左右 1 + 2 + 3）新人会进入3群

摘要

在当前的数据库环境中，需要高可用性、资源弹性和成本效益，云原生数据库已成为云上关键应用程序的大多数选择的数据库产品。同时，由于数据与分析之间的连接不断增加，用户更喜欢使用单个数据库高效地处理OLTP和OLAP工作负载，这增强了数据及时性并降低了数据同步和整体业务成本的复杂性。在本文中，我们总结了基于我们的经验和客户反馈的云原生HTAP数据库的五个关键设计目标，即透明度、竞争性的OLAP性能、对OLTP工作负载的最小干扰、高数据鲜度和出色的资源弹性。为了实现这些目标，我们提出了一种解决方案：PolarDB-IMCI，这是一种在阿里云上设计和部署的云原生HTAP数据库系统。我们的评估结果表明，PolarDB-IMCI能够有效地处理HTAP实验和生产工作负载；值得注意的是，它在TPC-H（100GB）上的分析查询速度提高了多达149倍。PolarDB-IMCI在OLTP工作负载上引入了低可见度延迟和较小的性能干扰（<5%），并且通过几十秒的扩展来实现资源弹性。

最近几年，云原生数据库在数据库行业成为了不可避免的趋势[8，20，25，52]。不同于本地数据库，云原生数据库将其架构分解成两层：计算层和存储层，允许资源独立扩展。配备磁盘的节点(在存储层)构成了一个共享存储池，作为计算层节点的统一数据接口。这种分解架构使数据库系统能够为客户提供极端的弹性、灵活的按需计费模型和低操作成本。因此，云原生数据库市场迅速蓬勃发展[36]。

同时，我们也注意到经典 OLTP 和 OLAP 数据库之间的界限开始模糊：在商业智能、社交媒体、欺诈检测和营销等领域，数据库需要提供足够的支持，既支持事务处理，也能支持分析处理。为了提供这样的功能，传统的解决方案通常将数据和应用逻辑部署到两个数据库中，一个专门用于 OLTP，另一个专门用于 OLAP (例如，MySQL  用于 OLTP，ClickHouse 用于 OLAP)，并依赖数据同步技术(例如，抽取-转化-加载 (ETL) 工作流程) 来确保它们之间的一致性，如图1所示。根据我们的数据，近30%的 PolarDB(一个 OLTP 数据库) 的客户需要将数据同步到独立的数据仓库系统中进行数据分析。

这种解决方案是昂贵的，因为它会对 OLTP 性能产生负面影响，并引入耗时的数据同步过程，进而导致 TP/AP 数据库中维护的数据之间出现延迟甚至不一致。在实践中，这些问题导致了次优的用户体验和大量的用户咨询。为了解决这些问题，需要设计一种云原生混合事务分析处理(HTAP) 数据库。在本文中，我们介绍了阿里云部署的云原生 HTAP 数据库 PolarDB-IMCI。我们总结了 PolarDB-IMCI 的关键设计目标，这些目标也适用于一般的云原生 HTAP 数据库设计:

• G#1: 透明查询执行。为了在单个数据库中服务于混合负载，数据库用户无需知道他们的查询在哪个层或节点上执行。一个云原生 HTAP 数据库应该为用户提供统一的 SQL 接口，并自动分发和优化查询，透明地跨计算和存储层分布。

• G#2: 一致性和并发控制。云原生 HTAP 数据库必须保证事务一致性，并为 OLTP 和 OLAP 工作负载提供高效的并发控制。它应该支持多种隔离级别，并为分析查询提供强一致性，同时保持 OLTP 操作的高事务吞吐量。

• G#3: 弹性扩展。为了提供灵活性和成本效益，云原生 HTAP 数据库应该能够根据工作负载需求动态扩展其计算和存储资源。它应该允许用户轻松地扩展或缩小资源，而不会影响服务。

• G#4: 高可用性和灾备恢复。云原生 HTAP 数据库必须在各种故障情况下保证高可用性和灾备恢复，包括节点故障、网络中断和自然灾害。它应该提供自动切换和恢复机制，并允许用户将数据库部署在多个地区进行数据冗余。

• G#5: 管理和运维简便。云原生 HTAP 数据库应提供简单直观的管理界面，并从用户方面尽量减少维护工作。它应该自动化例行管理任务，如备份、恢复和软件升级，并提供全面的监控和警报功能，以确保系统的健康和性能。

PolarDB-IMCI满足所有期望的目标（即G＃1-5），采用以下创新。首先，为了满足G＃1和G＃2，我们实现了内存列索引（IMCI作为补充存储。PolarDB-IMCI吸收了OLAP社区的各种先进优化，并推导出一个新的SQL引擎来匹配列的执行模式。此外，PolarDB-IMCI提出了一种新的查询路由机制，可以透明地分发查询。

其次，为了满足G＃3，PolarDB-IMCI将列索引放置在独立的只读（RO）节点上，具有共享存储架构，以在OLTP和OLAP请求之间提供有效的资源隔离。通过重用REDO日志（即行存储的差分日志记录）将更新传播到RO节点，而不是运输其他逻辑日志（即MySQL Binlogs）。

第三，为了满足G＃4，我们使用日志前提交集装箱（CALS）和2阶段无冲突日志重演（2P-COFFER，§5.2）增强了我们的更新传播框架。CALS在提交之前运输事务日志。2P-COFFER有效地解析和应用REDO日志到RO节点。此外，我们将列索引实现为追加式存储：记录按照插入顺序而不是主键顺序组织。因此，对列索引的更新是在原地和快速执行的。

最后，为了满足G＃5，列索引的检查点机制无缝地构建在PolarDB的原始存储引擎中。因此，快速拉起RO节点使用共享存储上的检查点可以实现快速的扩展能力。

2 背景和相关工作

2.1 混合事务/分析处理长达几十年的时间里，OLTP 和 OLAP 数据库分别专为它们的工作负载设计。例如，OLTP 引擎（例如 MySQL）偏好基于行的数据格式、逐行操作符，以支持数据修改和随机查询。相反，OLAP 引擎（例如 ClickHouse）使用基于列的数据格式、批量操作符和延迟化策略，以支持扫描密集的分析查询。因此，现代数据库管理员常常需要部署 OLTP 和 OLAP 数据库，并在两种数据库之间进行数据传输。HTAP 数据库的出现消除了维护多个数据库的负担，并简化了数据传输。我们将现有的 HTAP 解决方案分为两类（即单实例和多实例），并分别讨论每个类别。单实例的 HTAP。SAP HANA [47] 通过引入三层合并树来支持混合工作负载，这是一个分层的内存存储，支持行和列格式。Oracle Dual  允许将关系表构建为内存列单元（IMCU），以提供快速的列扫描。IMCU 的新更新由元数据临时记录，当累积了更多的更新时，IMCU 可以从内存缓冲区中重新填充。与 Oracle Dual 不同，SQL Server CSI  支持列存储和列存储索引（CSI），并定期将新的更新合并到 CSI 中，从而消除了重建的需要。PolarDB-IMCI 遵循类似的原则，但通过解决后面章节详细介绍的一些关键挑战，将此设计引领到云本地架构中。多实例的 HTAP。另一种 HTAP 数据库利用复制技术维护多个实例。因此，事务和分析查询可以路由到不同的实例，以实现高效的性能隔离。此外，每个实例都可以根据工作负载来定制其架构。SAP HANA 的较近作品提出异步表复制（ATR），用于主要实例和副本之间的数据同步。复制日志异步地提供给副本，以会话粒度并行回放。与 ATR 不同，Google F1 Lightning[54] 使用 Change Data Capture（CDC），一种更松散的机制，通过 BigTable 调换数据。TiDB 使用 Raft 连接行存储引擎（TiKV）和列式引擎（TiFlash）。TiFlash 表现为Raft 学习器，异步地从领导者接收日志，并不参与领导人选举。IBM DB2 Analytics Accelerator（IDAA） 通过集成同步来维护基于行的表数据副本，以支持增量更新。Oracle Dual 的新版本[43] 支持将只读工作负载卸载到同构实例（备用），并通过 REDO 日志同步数据。ByteHTAP 使用分离存储，通过 Binlog 同步异构引擎（ByteNDB 用于 OLTP 和 Apache Flink[18] 用于 OLAP）。Wildfire [2] 是一个兼容 Spark 的数据库，也利用分离存储进行数据同步。与这些工作不同，PolarDB-IMCI直接重用 REDO 日志进行异构数据复制。据我们所知，PolarDBIMCI 是第一个使用物理日志有效地同步异构存储的工业数据库。

2.2 云本地数据库云原生数据库的关键技术是将计算和存储解耦。一个典型的云原生数据库经常在其存储引擎下采用云存储，利用另一层虚拟化提供弹性存储服务。云原生架构使客户获得高弹性资源和按需计费模式的好处，也减少了服务提供商的维护和开发成本。云原生的 OLTP/OLAP。Aurora  是一种云原生 OLTP数据库，部署在定制的云存储层上。Taurus  使用基于分离的持久化机制的不对称复制，数据库日志和页面分别被复制。除了 OLTP 系统，OLAP 数据库的存储分离也受益。一些传统的数据仓库系统适应了云计算环境 (例如 Vertica 、Eon )，还有一些 OLAP 数据库是专为云环境本地开发的(例如 Snowflake 、Redshift 、AnalyticDB )。云本地 HTAP。SingleStore 是第一个走向云本地 HTAP数据库的产品。它将计算和存储解耦，并支持在计算节点的本地磁盘上提交事务，并将数据异步推送到其 blob 存储器。与 SingleStore 不同，PolarDB-IMCI 将所有持久化数据卸载到共享存储层中，因此，计算节点的所有状态都可以直接从共享存储中重建，有利于恢复和弹性。