索引结构|每秒14亿次PolarDB如何应对双11“尖峰时刻”( 二 ) 事务|id|io|索引|尖峰时刻

对此，我们将事务系统中的这个活跃事务列表改造成无锁Hash实现，写事务添加ID以及读事务拷贝到ReadView都可以并发进行。
大大提升了性能。
全球数据库技术
诸如AliExpress这一类针对海外消费者的购物大促，业务遍及各个大洲和国家等等。
因此数据库的异地可读，数据同步有非常高的要求。在过去DTS承载了区域间数据同步任务，DTS订阅了二进制日志然后分发到不同的区域并进行高速应用以实现区域间数据状态一致性。今年PolarDB集成了全新的全球数据库技术来解决跨域访问以及容灾的问题，PolarDB全球数据库（PolarDB Global Database Network，PolarDB-GDN）采用了数据库物理日志异步复制的方案。但是达成以上目标需要解决几个关键难点：高网络延迟下的数据同步问题和跨Region的数据读写问题。
针对这两点问题，PolarDB-GDN通过高并发流水线技术将同步速度提升7倍，将数据跨大洲同步延迟控制在2秒内。全局读写分离技术结合多级别的一致性能力，让业务不用做任何的改造的前提下降低整体的访问延迟。

文章插图
热缓存技术
双十一对数据库的可用性要求非常高，核心应用在大促期间处于高负载的状态，长时间高负荷的运行不可避免会存在单一节点的故障，如何能快速恢复成为了一个重要的课题。过去的节点故障恢复需要经历相当长的时间的恢复时间，而重启拉起后的系统还需要缓存预热后才能达到最佳访问性能。
PolarDB今年在存储计算分离架构上继续往前迈进一大步，实现了计算和内存的分离。通过将内存缓冲池从计算节点剥离，让计算节点状态最小化。
计算节点重启后可以快速恢复到重启前的状态，避免大量耗时的缓存预热。
传统数据库的错误恢复需要检查点开始扫描所有的redo日志、回放日志、事务恢复等步骤，该过程涉及大量磁盘IO、CPU计算等工作量，其时间往往很长。使用了热缓存技术的PolarDB在计算节点崩溃后，需要恢复的是缓存可能处于不一致的状态，如部分尚未修改完成的缓存页面以及内存结构等。而在CPU缓存分离的架构下只需要新的计算节点来根据各种控制信息和redo日志将这些被污染的内存恢复到一致的状态。
因为无需重新构建缓存池，修复工作量小。在常规读写负载下，重启后的数据库最大吞吐下降到原来的5%以下，并在200秒后逐渐恢复正常水平，而利用了热缓存技术的实例几乎无任何性能下降。
跨AZ容灾能力
双十一的核心业务必须要能够跨AZ的容灾， PolarDB提供了跨AZ容灾RPO为0的方案。PolarDB 在存储层（PolarStore）提供3副本的同时，还可以通过自研的 X-Paxos 库提供跨节点、跨机房、跨 AZ 级别的数据同步能力，提供 RPO = 0 的容灾解决方案。这个方案利用 PolarDB 经过多年验证的物理复制技术和 X-Paxos 一致性协议库，提供高可靠、低延迟的数据复制技术。相比于 RDS/MySQL 的逻辑日志复制，PolarDB 在节点切换时，受大事务/DDL 的影响更小，RTO 小于1分钟。
同时，这个方案在保证数据冗余的同时，尽量减少部署成本。
PolarDB 跨AZ版可以部署Leader，Follower 和 Log 节点。其中 Log 节点只记录日志，不参与选主，不存储数据，部署成本相比于现有架构只增加了 active redo log ，显著降低了部署成本。
并行查询增强
双十一不仅是消费者的盛宴，也是众多卖家的狂欢。卖家经常需要实时的查询自己的销售数据以及做一些快速的分析。PolarDB拥有查询引擎，在众多场景下能满足一些即时查询的需求，它充分利用硬件多核优势，并基于COST自动选择并行查询引擎，显著提升了查询性能。今年PolarDB在该方向并没有停止脚步，利用并行查询引擎了优化更多的应用场景。在大规格的实例中，并行的提升效果尤为显著。
在今年， PolarDB的并行查询新增加了众多场景的覆盖，有联合(Union)子查询的并行优化，扩展并行查询引擎对联合(Union)子查询的支持；派生表(Derived Table)的并行优化；用户自定义临时表的并行优化；Count的并行优化；Limit的并行优化；条件下推优化，减少数据汇总代价；HASH JOIN 的并行优化，同时优化算子和执行的并行度。
除此之外， POLARDB对GROUP BY / Distinct / SEMI-JOIN / 常量表以及包含Window函数的子查询也做了并行优化，通过利用更多的CPU资源，有效降低了这些场景下的查询耗时。
【 索引结构|每秒14亿次PolarDB如何应对双11“尖峰时刻”】在标准的TPC-H场景下，POLARDB的并行查询框架取得了非常好的表现。