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 Serverless会在易用性方面持续迭代,内核智能地适配用户负载,避免客户需要主动跟踪IMCI的功能发布才能发挥业务的最佳实践。
我们以一个简单的SysBench write-only场景为例,对比了固定规格列存节点和Serverless列存节点在压力下的复制延迟表现,展示了Serverless节点在成本和性能方面的优势。测试中,SysBench的更新流量打向PolarDB主节点,列存节点通过回放主节点的redo日志,同步数据更新到列索引。我们购买了16c64g规格的主节点,并分别增加了一个8c32g固定规格的列存节点和Serverless列存节点。
在预热后增加流量压力,并在一段时间后减小流量,我们观察固定规格节点和Serverless节点的统计差异。可以看到,由于固定规格列存节点的资源配置只有主节点的一半,它的处理能力跟不上主节点的写入能力,在回放过程中堆积了越来越多待处理的事务,在减小流量前最高堆积达到了13万,产生较大的主从复制延迟。反观Serverless节点,在增加流量前是8PCU资源(8c16g),内存比固定规格列存节点更小,但在增加流量后,通过感知负载并逐步弹升资源,期间没有产生事务堆积,避免了事务堆积造成的查询延迟。在减小流量后,Serverless节点的资源逐步释放。
通过压力测试的对比可以看到,Serverless节点在流量低峰期使用更少的资源成本,在流量高峰期以弹性的能力保证业务无损,实现了降本增效,也减轻了用户评估流量的运维负担。
IMCI Serverless的演进目标是在业务无感的前提下,进一步提升资源弹性的幅度和灵敏度。
[1]《400倍加速,PolarDB HTAP实时数据分析技术解密》
[2] Serverless
[3] 什么是热备切换,有什么技术原理
[4] 列存节点开启Serverless
[5] 《PolarDB:这5年,我是如何“进化”的?》[5] 《PolarDB:这5年,我是如何“进化”的?》[5] 《PolarDB:这5年,我是如何“进化”的?》
阿里云PolarDB开发者大会高能来袭
2024年1月17日
北京市朝阳区「北京嘉瑞文化中心」
本次大会集结多位行业大咖,超多干货分享
更有超多精美周边好礼等你来拿
扫码下方二维码or点击「报名」即可免费报名
了不起的数据库开发者们,请上车