POLARDB中物理复制的性能至关重要，我们不仅通过基于数据页维度的并行提高了性能，还对复制中的必要流程进行了优化，例如在MTR日志中增加了一个长度字段，从而减少了日志Parse阶段的CPU开销，这个简单的优化就能减少60%的日志Parse时间。我们还通过复用Dummy Index的内存数据结构，减少了其在Malloc/Free上的开销，进一步提高复制性能。
读节点性能
POLARDB的Replica节点，日志目前是一批一批应用的，因此当新的一批日志被应用之前，Replica上的读请求不需要重复创建新的ReadView，可以使用上次缓存下来的。这个优化也能提高Replica上的读性能。
三、为什么POLARDB能做到远低于商业数据库的成本
存储资源池化
POLARDB采用了一种计算和存储分离的架构，DB运行在计算节点，计算节点组成了一个计算资源池，数据都放在存储节点上，存储节点组成了一个存储资源池。如果CPU和内存不够了，就扩充计算资源池，如果容量或者IOPS不够了，就扩充存储资源池，两个池子都是按需扩容。而且存储节点和计算节点可以分别向两个方向优化，存储节点会选择低配的CPU和内存，提高存储密度，而计算节点可以选择小容量、低配的SSD作为操作系统和日志盘，上多路服务器增加CPU的核数。
而传统的数据库部署模型则是一种烟囱模型，一台主机既跑数据库又存数据，这带来两个问题。一个是机型难以选择，CPU和磁盘的配比主要取决于实际业务的需求，很难提前找到最优比例。第二是磁盘碎片问题，一个生产集群里，总有部分机器磁盘使用率是很低的，有的还不到10%，但出于业务稳定性要求，会要求独占主机的CPU，这些机器上的SSD其实是被浪费的。通过存储资源池化，这两个问题都能得到解决，SSD的利用率得到提高，成本自然也降低下来。
透明压缩
POLARDB的存储节点除了对ibd文件提供1MB的原子写，消除double write的开销，还支持对ibd文件的数据块进行透明压缩，压缩率可以达到2.4倍，进一步降低了存储成本。
而传统数据库在DB内进行压缩的方案相比，存储节点实现透明压缩不消耗计算节点的CPU，不影响DB的性能，利用QAT卡进行加速，以及在IO路径上用FPGA进行加速。POLARDB的存储节点还支持快照去重（dedup）功能，数据库的相邻快照之间，如果页面没有发生修改，会链接到同一份只读页面上，物理上只会存储一份。
存储成本的只读实例
传统数据库做只读实例，实施一写多读方案，是通过搭建只读副本的方案，先拷贝一个最近的全量备份恢复一个临时实例，再让这个临时实例连接主库或者其他binlog源同步增量数据，增量追上后，把这个临时实例加到线上升级为一个只读副本。这种方法一个是耗时，搭建一个只读实例需要的时间与数据量成正比；另一方面也很昂贵，需要增加一份存储成本，比如用户购买一个主实例加上五个只读实例，需要付7~8份存储的钱（7份还是8份取决于主实例是两副本还是三副本）。
而在PolarDB架构中，这两个问题都得到解决，一方面新增只读实例不需要拷贝数据，不管数据量有多大都可以在2分钟内创建出来；另一方面，主实例和只读实例共享同一份存储资源，通过这种架构去增加只读副本，可以做到零新增存储成本，用户只需要支付只读实例消耗的CPU和内存的费用。
POLARDB是未来云数据库的雏形（All in one），一个数据库即可满足现时多类数据库混合使用效果。阿里云发挥自身自研能力优势，以POLARDB为产品契机，实现数据库OLTP与OLAP的一体化设计，为企业的数字化升级所需的IT设施架构实现革命性进化。