共计 7702 个字符，预计需要花费 20 分钟才能阅读完成。
POLARDB 是阿里云自主研发的下一代云原生分布式数据库，100% 兼容 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
除了 100% 兼容 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%。
原文链接
本文为云栖社区原创内容，未经允许不得转载。
