POLARDB 是阿里云自主研发的下一代云原生分布式数据库，兼容MySQL、PostgreSQL等开源数据库，高度兼容Oracle语法，使用RDS服务的客户不需要修改应用代码，可以一键迁移到POLARDB，体验更大的容量，更高的性能，更低的成本，和更灵活的弹性。
目前，POLARDB是阿里云增速快的数据库产品，广泛应用于互联网金融、政府便民工程、新零售、教育、游戏、社交直播等行业。
作为基于计算与存储分离架构的新一代云原生数据库，POLARDB的计算节点里主要实现了 SQL 解析和优化、以及查询并行执行与无锁高性能事务处理，计算节点之间通过高吞吐的物理复制协议同步内存状态。
而存储层基于分布式文件系统PolarFS，通过Parallel Raft共识算法实现多数据副本间的强一致性，在存储层进行存储引擎的多版本页管理来支持全集群跨计算节点的Snapshot Isolation隔离级别。
01基于计算与存储分离的先进架构
计算节点与存储节点之间通过理解数据库语义的智能互联协议将filter和projection等算子从计算层下推到存储层执行。为了保证事务和查询语句的低延迟，同时降低计算节点之间状态同步的延迟，计算节点和存储节点之间使用25Gb高速RDMA网络互联，采用Bypass kernel的用户态网络协议层进行通讯。
基于计算与存储分离的先进架构，POLARDB可以从1个计算节点（2个CPU核）弹性伸缩到16个计算节点（高达到1000核）的事务扩展能力，单实例存储容量从10GB按使用量弹性扩展到100TB。
计算节点与存储节点分离的架构设计给POLARDB带来了实时的水平扩展能力。由于单个数据库实例的计算能力有限，传统的做法是通过搭建多个数据库副本来分担压力，从而提供数据库Scale out 的扩展能力。
然而，这种做法需要存储多份全量数据，并且频繁同步日志数据造成了过高的网络开销。此外，在传统数据库集群上，增加副本需要同步所有增量数据，这带来了同步延迟上涨的问题。
POLARDB将数据库文件以及Redo log 等日志文件存放在共享存储设备上，确保主实例和所有副本共享同一份全量数据和增量日志数据。节点间只需要同步内存里的元数据信息，通过MVCC机制的保证，就能支持跨节点读取数据的一致性，非常巧妙地解决了主实例和副本之间的数据同步问题，大大节约了跨节点的网络开销，降低副本间的同步延迟。
02提升事务性能 POLARDB内核层面优化揭秘
为了提高事务性能，POLARDB 在内核层面进行了大量优化。把一系列性能瓶颈用无锁（lockless）算法以及各种并行优化算法进行改造，减少甚至消除各种锁之间的相互冲突，大大增加了系统的scalability 能力。
同时，我们依托处理双十一这种大规模高并发场景下的经验, 在 POLARDB 上实现了对库存等热点数据进行优化的功能。对于简单重复的查询，POLARDB支持直接从存储引擎获取结果，从而减少了优化器及执行器的开销。
此外，进一步优化已经高效的物理复制。比如，我们在重做日志加了一些元数据，以减少日志解析CPU开销. 这个简单优化减少了60%日志解析时间。我们也重用 一些数据结构，以减少内存分配器的开销。
POLARDB运用了一系列算法来优化日志应用，比如只有在buffer pool中的数据页面 才需要日志应用。同时我们也优化了page cleaner and double write buffer，大大减少这些工作的成本. 这一系列优化使得在性能上 POLARDB 远超 MySQL ，在sysbencholtp_insert等大量并发写入的基准评测中达到高6倍于MySQL 的性能。
03支持并行查询（Parallel Query）
为了提高子查询和join等复杂查询（例如TPC-H基准评测）的能力，POLARDB的查询处理器支持并行查询（parallel query），可以将一个查询同时在多个或所有可用CPU核上进行执行。并行查询能够将一个查询任务（当前只支持SELECT语句）划分为多个子任务，多个子任务可以并行进行处理，整体采用Leader-Worker的并发模型。
Leader线程负责生成并行查询计划，协调并行执行过程的其他组件，并行执行计划会包括并行扫描、多表并行连接、并行排序、并行分组、并行聚集等子动作。
Message queue是leader线程和worker线程的通讯层，worker线程通过message queue向leader线程发送数据，而leader线程也会通过message queue向worker线程发送控制信息。
Worker线程负责真正的执行任务。Leader线程解析查询语句生成并行计划，然后同时启动多个worker线程进行并行任务处理，为了高效的执行查询，Worker上的执行不需要进行再次优化，而是直接从Leader上来拷贝生成好的计划分片。这需要实现执行计划树上所有节点的拷贝。
worker线程在进行扫描，聚集，排序等操作后将中间结果集返回给leader，leader负责收集来自worker的所有数据集，然后进行适当的二次处理（比如merge sort，二次group by 等操作），后将终结果返回给客户端。
Parallel Scan层会结合存储引擎的数据结构特征来实现工作负载的均衡。如何将扫描数据划分成多个分区，使得所有的工作线程尽可能的均匀的工作是数据分区划分的目标。在以B+树作为存储结构的存储引擎里，划分分区的时候，是先从根上来划分，如果根上不能划分出足够多的分区（>= 并行度），将会继续从下一层进行划分。
而如果我们需要6个分区的话，根节点多分出4个分区，所以就需要继续搜索下一层来进行分区，以此类推。在实际实现并行查询的过程中，为了能让多个工作线程更加均匀的分配扫描段，会在B+树里尽可能的多划分分区，这样如果某个工作线程由于过滤性比较高会优先完成当前分区，那么它会自动attach下一个分区继续执行，通过自动attach的方式来实现所有线程的负载均衡。
04新一代基于代价的优化器
云上客户的业务是多样化的，如果执行计划选错会导致慢查询。为了系统性地解决这些问题，POLARDB推出了新一代的基于代价的优化器。POLARDB里实现新的直方图Compressed Histogram对高频率数据进行自动探测并构建描述，在选择率计算时考虑数据频率和取值空间，解决实际应用中普遍存在的数据倾斜场景。
POLARDB大量基于改良的直方图进行代价估算，比如估算表和表join的结果大小，是join代价和join order优化的决定性因素，MySQL只能根据经验公式粗略的估算，无论是有索引时的rows_per_key,还是无索引时的默认参数值，估算的误差都较大，这些误差会在多表连接的过程中不断放大，导致生成效率低下的执行计划。
在POLARDB中使用直方图对重合部分进行合并计算，并根据不同的直方图类型适配不同的estimation算法，大大提高了估算精度，帮助优化器做出更优的join order选择。在随机生成的正态分布数据测试中，多表联合查询优化后可提速2.4-12倍，TPC-H测试中多个查询的join order发生变化，性能提升77%-332%。
POLARDB也使用直方图优化了record_in_range的逻辑，MySQL对于有索引的过滤条件采用index dive来估算区间的记录数，这个操作在OLTP短查询中CPU占比较高。在使用基于直方图估算替换index dive后，在淘宝电商核心业务中，绝大多数的查询查询响应时间减少一半。
05、自研分布式文件系统PolarFS：高可靠、高可用、与数据库协同设计
POLARDB的存储层采用的是阿里云自主研制的分布式文件系统PolarFS。PolarFS是国内面向DB应用设计的采用了全用户空间I/O栈的低延迟高性能分布式存储系统（参见VLDB 2018 上的文章 PolarFS: An Ultra-low Latency and Failure Resilient Distributed FileSystem for Shared Storage Cloud Database），其具备与本地SSD硬盘架构相当的低延迟高性能I/O能力，同时也以分布式集群的方式提供了优异的存储容量与存储性能的扩展能力。
而PolarFS作为一款与POLARDB深度协同的存储基础设施，其核心的竞争力不仅体现在性能和扩展性方面，更深层次的则是在面临有许多挑战性的POLARDB客户业务需求和规模化的公有云研发运维过程中而长期积累形成的一系列高可靠、高可用、与数据库协同设计的存储技术。
为了支持POLARDB在多个计算节点之间分发查询且保持全局的Snapshot Isolation语义，PolarFS支持存储POLARDB存储引擎B+树动态生成的多版本（Multi-version page）。
为了减少读写冲突，现代数据库一般都通过以MVCC并发控制为框架来提供RC、SI、SSI等不同的事务隔离级别，在MVCC机制下，B+树的每个页面会动态维护一系列的版本，并发执行中的多个事务允许各自访问一个页面的不同版本。
在POLARDB集群里，由于跨节点复制同步延迟的存在，每个计算节点B+树的页面可能是不同版本的，这时多版本存储可以为各节点提供其所对应版本。在POLARDB中，计算节点向PolarFS写入一个页面的同时要提供该数据页的版本信息（LSN），PolarFS不仅存储数据页的同时还要存储数据版本元信息；计算节点读取数据页时，也会提供版本信息从存储获取相应的数据页（历史）版本。
POLARDB数据库层定期会将集群所有计算节点版本号的低水位线发送给PolarFS，PolarFS会基于此版本号清理不再使用的历史版本。
保证数据可靠性是POLARDB所有设计的底线。在实际的分布式系统中，硬盘、网络与内存等硬件、固件或软件的bug等问题可能会造成数据错误，从而给数据可靠性保障带来各种挑战。存储端的可靠性问题来自静默错误（lost write、misdirected write，block corruption等），网络和内存主要来自于比特反转和软件bug。
为了确保各种异常情况（包括：硬件故障，软件故障，人工操作故障）发生时的数据可靠性，POLARDB和PolarFS提供了端到端全链路数据校验保障。
在数据写入时，POLARDB 从计算节点的存储引擎开始，一直到PolarFS存储节点的数据落盘，经过的中间链路，都会对数据的正确性做校验，防止异常数据写入。
在数据读取时，PolarFS和POLARDB存储引擎都会对读取到的数据做checksum校验，准确地识别磁盘静默错误的发生，防止静默错误扩散。
在业务流量低峰时，还会在后台持续性的做数据一致性扫描，用于检查单副本数据的checksum是否正确以及各个副本间的数据是否一致。数据迁移过程中的正确校验性也非常重要：POLARDB在执行任何形式的数据迁移动作时，除了副本自身数据的 checksum 校验，还会对多个副本数据的一致性做校验；当这两个校验都通过，才会将数据迁移到目标端；大限度的防止由于迁移动作，导致单副本上的数据错误扩散，避免数据损坏问题。
PolarFS还支持对POLARDB做快速的物理快照备份与还原。快照是一种流行的基于存储系统的备份方案。其本质是采用Redirect-On-Write 的机制，通过记录块设备的元数据变化，对于发生写操作的存储卷进行写时复制，将写操作内容改动到新复制出的存储卷上，来实现恢复到快照时间点的数据的目的。
快照是一个典型的基于时间以及写负载模型的后置处理机制。也就是说创建快照时，并没有备份数据，而是把备份数据的负载均分到创建 快照之后的实际数据写发生的时间窗口，以此实现备份、恢复的快速响应。
POLARDB通过底层存储系统的快照机制以及Redo log增量备份，在按时间点恢复用户数据的功能上，比传统的全量数据结合逻辑日志增量数据的恢复方式更加高效。
06高度兼容Oracle语法 成本是商业数据库的1/10
除了兼容MySQL和PostgreSQL这两个流行的开源数据库生态， POLARDB还高度兼容Oracle语法，为传统企业上云提供成本是商业数据库1/10的方案。
通过用DMS替换Oracle的GUI管理工具OEM，以及用POLARDBPlus替换命令行工具SQL Plus，沿袭了OracleDBA的使用习惯；客户端SDK可以从OCI和O-JDBC Driver替换成libpq和JDBC Driver，只需要做so和jar包的替换，程序主体代码不需要修改；
对Oracle的SQL普通DML语法都能支持，对几乎所有语法如connect by、pivot、listagg等也都全面支持；对PL/SQL存储过程、以及存储过程用到的内置函数库也能做到全面覆盖支持；
对一些功能（如安全管理、AWR等）提供完全相同的格式布局和操作语法，所以综合看来，POLARDB对Oracle的操作方法、使用习惯、生态工具、SQL语法、格式布局等都做到了全面的兼容和替换，结合迁移评估工具ADAM，应用可以做到少量改动甚至无改动。
07提前看：更多新技术和企业级特性即将上线
除了上面介绍的技术，POLARDB还有大量新技术和企业级特性在2019下半年陆续发布，这些技术会全面提升POLARDB的可用性、性能，降低POLARDB的使用成本：
1）从弹性存储到弹性内存，热缓冲池（warm buffer pool）技术
POLARDB即将支持和计算节点进程解构的“热”缓冲池，这将大大减少用户业务在计算节点重启时受到的影响。在进行机型替换规格升降级的时候（serverless），对业务的影响更小。同时，一个独立的内存也使得其动态按需扩展或收缩成为可能。
2） 性能数倍增长，更好的DDL支持（FAST DDL）
POLARDB即将支持并行DDL，这将大大缩短表级别的DDL延迟。这个功能把并行化做到，可以把建索引等DDL的时间减少近10倍。同时，POLARDB还进行了大量的DDL复制层面的优化，这使得DDL可以进行跨区域的大批量复制，速度更加迅速，资源的消耗更少。
3） 支持跨地域的全球数据库（Global Database）
POLARDB 支持跨地域、长距离的物理复制，帮助用户建立其全球数据库的部署。通过物理复制，数据可以实时复制到全球各个机房，使得全球用户的查询在当地机房就得到响应，反应更迅速。
4）分区表的支持
POLARDB支持100T的存储容量。但是随着表的大小的增长，单表索引的层次也增加，导致数据的查找定位也变得更慢，一些单表上的物理锁也导致并行DML碰到天花板。
所以进行合理的分区变得更加紧迫。之前不少用户依赖数据库外部中间件的分库分表的来减少单表的压力。
但是，随着POLARDB在各方面比如并行查询的发展，我们可以把这些分库分表的功能通过分区表的形式在数据库内更有效的实现。
有效的分区不但使我们能够支持更大的表，而且它减少了一些数据库索引的全局物理锁的冲突，从而提高整体DML的性能。
同时，这种形态之后可以更好的支持冷热数据分离，把不同“温度“的数据存放在不同的存储介质中，在保证数据access的性能的同时，减少数据存放的成本。
POLARDB在增强分区表的一系列功能，包括全局索引（Global Index），分区表的外键（Foreign Key Constraint），自增分区表（Interval Partition）等，使得POLARDB更好的应对特大表
5） 行级压缩
POLARDB即将推出行级压缩功能。业界通常的做法是在数据页级别通过通用压缩算法（比如LZ77、Snappy）进行压缩，但页级压缩会带来CPU开销过大的问题，因为改动一行数据，也要把整个数据页解压，改动，再压缩。
此外，有些场景下数据页压缩后反而变大（bloat），还会导致多重索引页分裂 （multiple splits）。POLARDB采用细粒度（fine-grain）行级压缩技术，对不同的数据类型采用特定的压缩方式。
数据以压缩的方式同时存在于外存及内存中，只有在要查询的时候才进行行级数据的解压，而不用解压整个数据页。由于数据除查询外都是以压缩方式存储，所以日志也记录了压缩的数据，这个进一步减少了日志的大小，以及在网络传输的数据/日志的压力。同时其相对应的索引也只存储压缩的数据。
整体数据量的减少足以抵消解压所引起的额外开销，使得这种压缩在大大减少数据存储的同时并不会引起性能衰退。
6）In-Memory的列存（HTAP）
在传统的数据库领域，分析数据库和在线事务处理是分隔开来的。因此通常需要在一天的经营结束后将在线事务处理的数据与往期分析处理的数据一起导入至数据仓库后运行分析，以生成相应的报表。
在HTAP数据库中，则省去了大规模数据搬移的时间与运营成本，一站式解决大部分企业级应用的需求，并在交易结束当天同步出具T+0的分析报告。
在这种需求下，POLARDB在实现in-memory的列存数据表。通过物理逻辑日志直接和POLARDB行存数据同步。这样通过特定适合分析的算子可以对这些列存数据进行实时的大数据分析。使得用户可以一站式的得到分析结果。
7）冷热分离存储引擎X-Engine
存储数据的规模越来越庞大，但不是所有的数据访问频率都相同，实际上数据访问总是呈现比较明显的冷热分布特征，基于这一特征，X-Engine设计了冷热分层的存储架构，根据数据访问频度(冷热)的不同将数据划分为多个层次，针对每个层次数据的访问特点，设计对应的存储结构，写入合适的存储设备。
不同于传统的B+树技术，X-Engine使用了LSM-Tree作为分层存储的架构基础，使用多事务处理队列和流水线处理技术，减少线程上下文切换代价，并计算每个阶段任务量配比，使整个流水线充分流转，极大提升事务处理性能。数据复用技术减少数据合并代价，并且因为数据复用减少缓存淘汰带来的性能抖动。进一步利用FPGA硬件加速compaction过程，使得系统上限进一步提升。
相对于其他类似架构的存储引擎比如RocksDB，X-Engine的事务处理性能有10倍以上提升。
X-Engine的详细技术参考SIGMOD 2019的论文X-Engine: An Optimized StorageEngine for Large-scale E-Commerce Transaction Processing。
目前，POLARDB不仅支撑阿里巴巴集团淘宝、天猫、菜鸟等业务场景，还广泛应用于政务、零售、金融、电信、制造等领域，目前已经有40万个数据库迁上阿里云。
基于POLARDB分布式数据库，北京的公交系统快捷、流畅地安排着全市2万多辆公交车，方便每天800万人次出行；
众安保险使用该数据库处理保单数据，效率提升25%。
本文为云栖社区原创内容，未经允许不得转载。
