主要观点总结
本文介绍了阿里云自主研发的下一代关系型分布式云原生数据库PolarDB，它在兼容传统数据库生态的同时，突破了传统单机硬件的限制，为用户提供大容量、高性能、高弹性的数据库服务。文章详细描述了PolarDB在TPC-C基准测试中的表现及其背后的技术原理，包括其核心技术之共享存储、性能链路、高并发优化、CPU和内存效率优化、IO链路优化、复制性能优化等。
关键观点总结
关键观点1: PolarDB的诞生背景
由于传统关系型数据库在面对快速膨胀和变化的业务场景时，对可扩展性（Scalability）以及可靠性（Reliability）的需求更加迫切，而NoSQL数据库又存在一致性及事务支持不足的问题。在此背景下，阿里巴巴自主研发的PolarDB出现，解决了这些痛点。
关键观点2: PolarDB的技术特点
PolarDB采用了共享存储的整体架构，通过RDMA高速网络互连的区块服务器一起向上层计算节点提供块设备服务。它兼具高性能、易用性和扩展性，通过软硬协同演进，提供了和本地盘一致的I/O时延能力和更强的IOPS能力。
关键观点3: PolarDB在TPC-C基准测试中的表现
PolarDB以超越原记录2.5倍的性能登顶TPC-C基准测试排行榜，以每分钟20.55亿笔交易（tpmC）和单位成本0.8元人民币（price/tpmC）的成绩刷新世界纪录。
关键观点4: PolarDB的优化策略
为了应对TPC-C基准测试中的挑战，PolarDB做了多方面的优化，包括高并发优化、CPU和内存效率优化、IO链路优化、复制性能优化等。这些优化策略极大地提升了PolarDB的性能和扩展性。
正文
高并发优化
高 CPU 占用和内存访问 →
CPU 和内存效率优化
高 IO 吞吐 →
IO链路优化
更长的日志写入链路 →
复制性能优化
这4个特征也是真实线上用户业务常见的性能瓶颈，下面我们将简述 PolarDB 的整体性能链路，再基于这4个典型特征，分别介绍单机性能链路上做的关键优化。
作为共享存储的云原生数据库，PolarDB 不仅提供了超强易用性（快速备份和恢复，高可用），以及超强弹性（存储/计算解耦）的能力，还通过软硬协同演进，提供了和本地盘一致的 I/O 时延能力和更强的 IOPS 能力，使得在性能、易用性、扩展性三方面都做到了极致。
传统部署在本地盘的 MySQL 架构，受益于本地盘的低 I/O 时延，但也存在着存储容量有限，弹升困难的限制，并且跨机主备复制的高时延，也掩盖了本地盘在性能上的收益。对于直接部署在云盘的 MySQL 架构，虽然能够利用云盘的存储资源的扩展性和高可用，但云盘的高时延又无法发挥 MySQL 的性能，并且无法做到计算资源的横向扩展。
为了解决性能和扩展性的问题，用户会考虑分布式数据库，但存在业务改造大，运维成本高等问题，PolarDB 通过 Proxy 到底层存储的全链路软硬协同优化，很好地解决了这三点。
图1：兼具高性能，易用性和扩展性的PolarDB
图2 展示了 PolarDB 的整个性能的优化链路概览，用户连接的 SQL 查询通过代理的转发，到达数据库内核，通过 SQL 解析、索引查找，最终通过文件系统到达磁盘存储。整个性能优化链路横跨了从上层的 Proxy 代理到底层存储，PolarDB 通过全链路的性能优化，使得在高压力的 tpcc 负载下，保持高效事务处理性能。
图2：PolarDB 性能链路概览
首先对于 TPC-C 基准测试负载的第一个典型特征：海量的用户连接，在 PolarDB 的集群测试中，客户端一共创建了 16 亿的用户连接，即便通过多级的连接池，到达单个数据库节点的用户连接仍然达到 7000+，这对数据库的并发处理能力提出了考验。
为了解决大量并发在索引写入上的锁瓶颈，PolarDB 提出了高性能的 Polar Index，以提升多线程并发的索引读写性能。
在 Polar Index 1.0 上，解决了因为全局索引锁而不允许并发分裂和合并（SMO）操作问题，每次遍历索引，遵循 latch coupling 的原则，即成功获取下个节点的写锁时才释放父节点写锁，将 SMO 分解为多个阶段，允许了 SMO 期间分裂节点的并发读取。
在 Polar Index 2.0 版本，PolarDB 进一步优化了索引的加锁粒度，和 latch coupling 相比，每次对 btree 的自上而下遍历，只拿一个节点的锁，同时优化 SMO 为自底向上的加写锁顺序，缩短了锁范围更大的上层节点加锁时间，允许更高的并发读写操作。
PolarIndex 的高性能读写使得 TPC-C 基准测试中，索引的并发读写不再是写入的瓶颈。
