数据库内核那些事｜PolarDB HTAP Serverless：打造经济易用的实时分析系统

2023-12-27
陕西
本文字数：3655 字
阅读完需：约 12 分钟

前言

In Memory Column Index（IMCI）是云原生数据库 PolarDB MySQL 的 HTAP 技术方案，可以通过列存索引优化复杂查询的执行性能，透明地提升了 PolarDB MySQL 实时分析的能力。关于 PolarDB HTAP 和 IMCI 的详细介绍可以参考《400倍加速，PolarDB HTAP实时数据分析技术解密》。[1]

HTAP 可以在一套系统中同时高效地处理事务（TP）请求和分析（AP）请求，在提供便利的同时，也对资源调度提出了挑战：HTAP 系统的负载存在着典型的分时特点，TP 和 AP 的负载大多发生在不同时段，在处理 TP 请求时，AP 资源可能闲置浪费，反之亦然。因此，HTAP 系统更应该感知负载变化，合理调整资源，HTAP 系统有着很大的降本增效空间。

PolarDB MySQL Serverless 功能已经发布，具有高可用、高弹性、免运维、业务无感等核心优势，该功能可以使数据库集群资源随客户业务负载动态调整规格，在低负载时自动降低规格、节约成本，在高负载时自动提高规格应对流量压力、保障业务稳定，将客户从复杂的业务资源评估和运维工作中解放出来[2][3]。IMCI Serverless 在 PolarDB MySQL Serverless 功能的基础上，针对 AP 场景在列存节点弹性的及时性、准确度和稳定性等方面做了大量优化，进一步节约列存节点使用成本，提升易用性，提高用户体验。开启 IMCI Serverless 的用户参考官网手册[4]。下文从 IMCI Serverless 核心优势角度的介绍各优化工作内容。

核心优势

弹得快

当负载增加，列存节点资源压力会随之增加。压力超过警戒线时，列存节点会在宿主机上申请资源，这个过程是原地纵向弹升。大多情况下，本地资源可以满足弹性需求，原地弹可以轻松地做到秒级响应，但是当本地资源不足时，需要在资源充足的其他机器上构建列存节点，这个过程是跨机横向弹。横向弹的挑战点在于业务无感，要求新节点快速冷启动加载数据，并在提供服务时不会因为处于缓存缺页等冷却状态而造成业务性能抖动，即需要同时做好数据迁移和状态迁移。下图展示了原地弹和跨机弹的过程，图中 PCU（PolarDB Capacity Unit）是 PolarDB 弹性资源的基本单位，1PCU 约等于 1 核 2GB 内存的标准服务能力。

IMCI 存储是 Delta-Main 结构，在 PolarDB 计算存储分离的架构下，可以很自然地实现数据迁移。Delta 部分数据代表增量的数据，定期合入 Main 部分，Main 持久化在远端共享存储，因此新节点启动只需要从 redo log 中恢复出少量 Delta 数据，即可完成全量数据的加载并提供服务，迁移的过程可以在秒级

为了优化状态迁移，IMCI 存储做了缓存预热。Main 的更新模型是 Copy-On-Write，结合 Main 数据本身 immutable 的特点，让缓存预热更加便利：IMCI 在切换前 Dump 了老节点中的热点数据，在新节点加载热点并完成预热后再提供服务，从而避免了大批缓存失效的抖动。通过快速启动和缓存预热技术，IMCI 可以做到及时、业务无感地完成弹升规格。

弹得准

在解决了快速弹资源后，IMCI 需要充分利用弹升的资源，将新分配的资源用到提升性能的“刀刃”上。IMCI 为此做了一套内部资源调度系统，资源调度系统会评估处理当前负载的瓶颈，按需分配列存节点所有可用的计算资源、IO 资源至各个模块，最大化发挥资源，提高系统吞吐。

一个典型的调度场景是 HTAP 系统中 TP 与 AP 流量的分时，例如在白天跑事务写入数据的时段，IMCI 会回收查询执行的计算和 IO 资源，分配给写入模块；在晚上跑分析请求的时段，IMCI 会回收写入资源，分配给查询模块，更精准地使用可用资源。

此外，除了在写入场景和查询场景之间做资源调度，IMCI 还在写入和查询场景内部做了更细节的调度。比如，写入会区分是灌库场景还是批量更新场景，在不同场景下，系统调整写缓存、行列映射缓存、回放线程、刷盘线程等资源的分配，以期更好地适配写入负载；查询则会根据查询请求的复杂度、并发度、排队情况，配置处理每个查询请求可用的资源，以期尽可能打满可用资源，提高查询性能。

IMCI 资源调度系统是 IMCI Serverless 的核心功能，会持续打磨调度规则提高资源分配的合理度，让更少的资源发挥更好的效果。调度系统后续会和行存引擎资源打通，更好地支持行列混合执行，并向多机并行任务调度方向演进，从集群整体资源的角度挖掘更准的调度策略。

降得稳

在流量结束后，回收系统资源可以降低使用成本。但回收策略不当，可能会引起业务抖动。比如一段时间内，查询请求间歇到来，当资源回收时机与查询请求处理时间错位，可能会因为 Cache Miss 造成间歇性地性能抖动，如下图。

IMCI Serverless 在内核层面做了防抖动功能，资源调度系统会参考近期缓存命中的统计信息，自适应地修正资源规格变更的幅度。此外，在资源回收时，IMCI 会以更谨慎的策略，逐步放大回收资源的粒度，降低可能的抖动。

更易用

IMCI 期待 Serverless 能力可以减轻客户使用列存索引的运维负担，不必评估购买规格，不必关心哪些表需要建列索引，不必探索列存运行期间各种参数应该如何设置才能发挥最佳效果，彻底从规格评估和运维工作中解脱。为此 IMCI 做了以下完善：

优化无负载时规格的下限，尽可能降低闲时的用户成本：当前 IMCI 所有数据相关的组件已经全部支持弹降到底，元数据相关的组件弹性优化完毕后，IMCI Serverless 会在闲时以最低规格计费；

自动调整内核参数配置，提供最佳的开箱实践：IMCI 资源调度系统可以根据负载瓶颈，自适应地调整各组件的参数配置，比如存储各模块缓存配比、缓存淘汰算法、执行物化策略等，降低用户的学习、测试和运维负担；

优化索引推荐功能：IMCI 会根据查询请求，给出索引建议，目前已经完成根据查询 SQL 建议列索引的功能，后续从内容层面在自动分区、排序键、过滤索引和流计算虚拟列等功能方面进行推荐，把最适合的功能主动“推”给客户。

IMCI Serverless 会在易用性方面持续迭代，内核智能地适配用户负载，避免客户需要主动跟踪 IMCI 的功能发布才能发挥业务的最佳实践。

测试效果

我们以一个简单的 SysBench write-only 场景为例，对比了固定规格列存节点和 Serverless 列存节点在压力下的复制延迟表现，展示了 Serverless 节点在成本和性能方面的优势。测试中，SysBench 的更新流量打向 PolarDB 主节点，列存节点通过回放主节点的 redo 日志，同步数据更新到列索引。我们购买了 16c64g 规格的主节点，并分别增加了一个 8c32g 固定规格的列存节点和 Serverless 列存节点。

在预热后增加流量压力，并在一段时间后减小流量，我们观察固定规格节点和 Serverless 节点的统计差异。可以看到，由于固定规格列存节点的资源配置只有主节点的一半，它的处理能力跟不上主节点的写入能力，在回放过程中堆积了越来越多待处理的事务，在减小流量前最高堆积达到了 13 万，产生较大的主从复制延迟。反观 Serverless 节点，在增加流量前是 8PCU 资源（8c16g），内存比固定规格列存节点更小，但在增加流量后，通过感知负载并逐步弹升资源，期间没有产生事务堆积，避免了事务堆积造成的查询延迟。在减小流量后，Serverless 节点的资源逐步释放。

通过压力测试的对比可以看到，Serverless 节点在流量低峰期使用更少的资源成本，在流量高峰期以弹性的能力保证业务无损，实现了降本增效，也减轻了用户评估流量的运维负担。

演进计划

IMCI Serverless 的演进目标是在业务无感的前提下，进一步提升资源弹性的幅度和灵敏度。

资源弹升更加及时：当前资源分配策略，是宿主机上的负载监控程序驱动内核资源变化，被动驱动的方式或多或少会出现分配延迟、分配资源不到位的问题；实际上，内核感知负载更加准确，IMCI 从内核出发反向资源驱动的方式，可以更加及时并一步到位的反映出需要的全部资源；

跨机横向弹的速度更快，降低切换窗口的影响：IMCI 会结合 PolarDB 云原生三层解耦的技术[5]，将热点数据缓存在分布式内存节点中，消除状态迁移、预热的过程，进一步加速跨机弹性；

资源提前弹，做到 100%的业务无损：用户突发流量时，若备用资源池不足，需要临时的跨机资源调度；支持用户自定义的定时弹性，可以在一定程度上减少临时调度，系统可以在定义时间前准备好用户定义的资源规格；此外，IMCI 也计划通过历史流量预测未来流量，做到提前调度；

多机弹性与资源隔离：复杂分析的 SQL 需要多机并行执行来加速，IMCI Serverless 后期会感知负载，弹出多个节点临时处理复杂 SQL，面向典型的 OLAP 负载做优化；此外，考虑到复杂 SQL 的处理可能会消耗大量计算资源，为确保资源隔离，IMCI 会通过 proxy 划分资源组，多机执行不会跨资源组，比如离线分析的资源组，可以与组内节点多机执行任务，不会占用在线分析组的资源；