1.前言
In Memory Column Index（IMCI）是云原生数据库PolarDB MySQL的HTAP技术方案，可以通过列存索引优化复杂查询的执行性能，透明地提升了PolarDB MySQL实时分析的能力。关于PolarDB HTAP和IMCI的详细介绍可以参考《400倍加速，PolarDB HTAP实时数据分析技术解密》。[1]
图1：PolarDB MySQL HTAP架构
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核心优势角度的介绍各优化工作内容。
2.核心优势
2.1弹得快
当负载增加，列存节点资源压力会随之增加。压力超过警戒线时，列存节点会在宿主机上申请资源，这个过程是原地纵向弹升。大多情况下，本地资源可以满足弹性需求，原地弹可以轻松地做到秒级响应，但是当本地资源不足时，需要在资源充足的其他机器上构建列存节点，这个过程是跨机横向弹。横向弹的挑战点在于业务无感，要求新节点快速冷启动加载数据，并在提供服务时不会因为处于缓存缺页等冷却状态而造成业务性能抖动，即需要同时做好数据迁移和状态迁移。下图展示了原地弹和跨机弹的过程，图中PCU（PolarDB Capacity Unit）是PolarDB弹性资源的基本单位，1PCU约等于1核2GB内存的标准服务能力。
图2：实例原地弹和跨机弹的过程
IMCI存储是Delta-Main结构，在PolarDB计算存储分离的架构下，可以很自然地实现数据迁移。Delta部分数据代表增量的数据，定期合入Main部分，Main持久化在远端共享存储，因此新节点启动只需要从redo log中恢复出少量Delta数据，即可完成全量数据的加载并提供服务，迁移的过程可以在秒级完成。
图3：IMCI 跨机弹的实现
为了优化状态迁移，IMCI存储做了缓存预热。Main的更新模型是Copy-On-Write，结合Main数据本身immutable的特点，让缓存预热更加便利：IMCI在切换前Dump了老节点中的热点数据，在新节点加载热点并完成预热后再提供服务，从而避免了大批缓存失效的抖动。通过快速启动和缓存预热技术，IMCI可以做到及时、业务无感地完成弹升规格。
2.2弹得准
在解决了快速弹资源后，IMCI需要充分利用弹升的资源，将新分配的资源用到提升性能的“刀刃”上。IMCI为此做了一套内部资源调度系统，资源调度系统会评估处理当前负载的瓶颈，按需分配列存节点所有可用的计算资源、IO资源至各个模块，最大化发挥资源，提高系统吞吐。
一个典型的调度场景是HTAP系统中TP与AP流量的分时，例如在白天跑事务写入数据的时段，IMCI会回收查询执行的计算和IO资源，分配给写入模块；在晚上跑分析请求的时段，IMCI会回收写入资源，分配给查询模块，更精准地使用可用资源。
图4：IMCI资源调度系统
此外，除了在写入场景和查询场景之间做资源调度，IMCI还在写入和查询场景内部做了更细节的调度。比如，写入会区分是灌库场景还是批量更新场景，在不同场景下，系统调整写缓存、行列映射缓存、回放线程、刷盘线程等资源的分配，以期更好地适配写入负载；查询则会根据查询请求的复杂度、并发度、排队情况，配置处理每个查询请求可用的资源，以期尽可能打满可用资源，提高查询性能。
IMCI资源调度系统是IMCI Serverless的核心功能，会持续打磨调度规则提高资源分配的合理度，让更少的资源发挥更好的效果。调度系统后续会和行存引擎资源打通，更好地支持行列混合执行，并向多机并行任务调度方向演进，从集群整体资源的角度挖掘更准的调度策略。
2.3降得稳
在流量结束后，回收系统资源可以降低使用成本。但回收策略不当，可能会引起业务抖动。比如一段时间内，查询请求间歇到来，当资源回收时机与查询请求处理时间错位，可能会因为Cache Miss造成间歇性地性能抖动，如下图。
图5：固定弹性规则下业务受损
IMCI Serverless在内核层面做了防抖动功能，资源调度系统会参考近期缓存命中的统计信息，自适应地修正资源规格变更的幅度。此外，在资源回收时，IMCI会以更谨慎的策略，逐步放大回收资源的粒度，降低可能的抖动。
图6：动态弹性规则下业务无损
2.4更易用
IMCI期待Serverless能力可以减轻客户使用列存索引的运维负担，不必评估购买规格，不必关心哪些表需要建列索引，不必探索列存运行期间各种参数应该如何设置才能发挥最佳效果，彻底从规格评估和运维工作中解脱。为此IMCI做了以下完善：
- 优化无负载时规格的下限，尽可能降低闲时的用户成本：当前IMCI 所有数据相关的组件已经全部支持弹降到底，元数据相关的组件弹性优化完毕后，IMCI Serverless会在闲时以最低规格计费；
- 自动调整内核参数配置，提供最佳的开箱实践：IMCI资源调度系统可以根据负载瓶颈，自适应地调整各组件的参数配置，比如存储各模块缓存配比、缓存淘汰算法、执行物化策略等，降低用户的学习、测试和运维负担；
- 优化索引推荐功能：IMCI会根据查询请求，给出索引建议，目前已经完成根据查询SQL建议列索引的功能，后续从内容层面在自动分区、排序键、过滤索引和流计算虚拟列等功能方面进行推荐，把最适合的功能主动“推”给客户。
IMCI Serverless会在易用性方面持续迭代，内核智能地适配用户负载，避免客户需要主动跟踪IMCI的功能发布才能发挥业务的最佳实践。
3.测试效果
我们以一个简单的SysBench write-only场景为例，对比了固定规格列存节点和Serverless列存节点在压力下的复制延迟表现，展示了Serverless节点在成本和性能方面的优势。测试中，SysBench的更新流量打向PolarDB主节点，列存节点通过回放主节点的redo日志，同步数据更新到列索引。我们购买了16c64g规格的主节点，并分别增加了一个8c32g固定规格的列存节点和Serverless列存节点。
在预热后增加流量压力，并在一段时间后减小流量，我们观察固定规格节点和Serverless节点的统计差异。可以看到，由于固定规格列存节点的资源配置只有主节点的一半，它的处理能力跟不上主节点的写入能力，在回放过程中堆积了越来越多待处理的事务，在减小流量前最高堆积达到了13万，产生较大的主从复制延迟。反观Serverless节点，在增加流量前是8PCU资源（8c16g），内存比固定规格列存节点更小，但在增加流量后，通过感知负载并逐步弹升资源，期间没有产生事务堆积，避免了事务堆积造成的查询延迟。在减小流量后，Serverless节点的资源逐步释放。
图7：列存节点的事务堆积
图8：Serverless节点资源的弹性
通过压力测试的对比可以看到，Serverless节点在流量低峰期使用更少的资源成本，在流量高峰期以弹性的能力保证业务无损，实现了降本增效，也减轻了用户评估流量的运维负担。
4.演进计划
IMCI Serverless的演进目标是在业务无感的前提下，进一步提升资源弹性的幅度和灵敏度。
- 资源弹升更加及时：当前资源分配策略，是宿主机上的负载监控程序驱动内核资源变化，被动驱动的方式或多或少会出现分配延迟、分配资源不到位的问题；实际上，内核感知负载更加准确，IMCI从内核出发反向资源驱动的方式，可以更加及时并一步到位的反映出需要的全部资源；
- 跨机横向弹的速度更快，降低切换窗口的影响：IMCI会结合PolarDB云原生三层解耦的技术[5]，将热点数据缓存在分布式内存节点中，消除状态迁移、预热的过程，进一步加速跨机弹性；
- 资源提前弹，做到100%的业务无损：用户突发流量时，若备用资源池不足，需要临时的跨机资源调度；支持用户自定义的定时弹性，可以在一定程度上减少临时调度，系统可以在定义时间前准备好用户定义的资源规格；此外，IMCI也计划通过历史流量预测未来流量，做到提前调度；
- 多机弹性与资源隔离：复杂分析的SQL需要多机并行执行来加速，IMCI Serverless后期会感知负载，弹出多个节点临时处理复杂SQL，面向典型的OLAP负载做优化；此外，考虑到复杂SQL的处理可能会消耗大量计算资源，为确保资源隔离，IMCI会通过proxy划分资源组，多机执行不会跨资源组，比如离线分析的资源组，可以与组内节点多机执行任务，不会占用在线分析组的资源；
- 资源弹降下限更低，帮助用户节约更多成本：IMCI会继续优化存储组件的常驻资源，最终期望在零流量时，实例资源零消耗，不做计费。
