POLARDB IMCI 白皮书 云原生HTAP 数据库系统 一 主体架构与接口

开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共880人左右 1 + 2 + 3）新人会进入3群

3 概述
在本节中，我们首先概述PolarDB-IMCI的体系结构，接着总结驱动前面设计目标的设计理念，并简要描述用户界面。
3.1 PolarDB-IMCI的体系结构
图2显示了PolarDB-IMCI的体系结构，遵循将计算和存储架构分离的关键设计原则。存储层是一个具有高可用性和可靠性的用户空间分布式文件系统PolarFS [8]。计算层包含多个计算节点，包括用于读写请求的主节点（RW节点）、用于只读请求的多个节点（RO节点）以及多个无状态代理节点用于负载均衡。有了这些，PolarDB-IMCI可以提供高资源弹性性（§7）。此外，存储和计算层中的所有节点都通过高速RDMA网络连接以实现数据访问的低延迟。
为加快分析查询速度，PolarDB-IMCI支持在RO节点的行存储上建立内存列索引（§4）。列索引按插入顺序存储数据，并执行位于原位置之外的写操作以实现高效更新。插入顺序意味着列索引中的行可以通过其行ID（RID）而不是主键（PK）快速定位。为支持基于PK的点查找，PolarDB-IMCI实现了一个RID定位器（即两层LSM树）用于PK-RID映射。
PolarDB-IMCI使用一个异步复制框架（§5）进行RO和RW之间的同步。即，RO节点的更新不包含在RW的事务提交路径中，以避免对RW节点的影响。为增强RO节点上的数据新鲜度，PolarDB-IMCI在日志应用方面使用了两个优化，预提交式日志传送和无冲突并行日志重播算法。RO节点通过行存储的REDO日志进行同步，这比其他稻草人方法（例如使用Binlog）对OLTP造成的干扰要小很多。需要注意的是，将物理日志应用到列索引中并不是微不足道的，因为行存储和列索引的数据格式是异构的。
每个RO节点中都使用两个相互共生的执行引擎（§6）：PolarDB的常规基于行的执行引擎来处理OLTP查询，以及一个新的基于列的批处理模式执行引擎用于高效运行分析查询。批处理模式执行引擎借鉴了列式数据库处理分析查询的技术，包括管道执行模型、并行运算符和矢量化表达式评估框架。常规基于行的执行引擎通过增强优化可进行列引擎不兼容或点查询。PolarDB-IMCI的优化器自动为两个执行引擎生成和协调计划，此过程对使用者透明。
3.2 设计理念
我们以下面突出PolarDB-IMCI的设计理念，这也适用于其他云本地HTAP数据库。
存储计算分离。同时作为云本地数据库的关键设计原则，存储计算分离架构在没有数据移动的情况下实现了适应性计算资源配置，这已经成为主流架构的替代方案。PolarDB-IMCI采取此决策以自然地达成我们的设计目标G＃5（高资源弹性）。
单个RW节点和多个RO节点。实践中，单写架构已经通过[52] 确认拥有卓越的写性能并显着降低系统复杂性。我们观察到单个RW节点足以为95%的客户提供服务。此外，所有RO节点都具有与RW节点同步的一致数据视图。大型OLAP查询被路由到RO节点上以实现有效的资源隔离，RO节点可以快速扩展以处理激增的OLAP查询，这符合设计目标G＃3（对OLTP的最小干扰）和G＃5（资源弹性）。
RO节点内的混合执行和存储引擎。从OLAP社区的经验中得出，列式数据布局和矢量化的批处理执行对于OLAP查询来说是显著的优化。然而，对我们而言，直接使用现有的列式系统（例如ClickHouse）作为RO节点是不明智的决定。有两个原因支持这个论点。首先，在创建表方面，实现RW节点和RO节点之间的全兼容是耗时的。在云服务环境中，即使存在微小的不兼容性，也会在巨大的客户量下被显著放大并压垮开发人员。其次，纯基于列的RO节点对于被归类为OLTP工作量的点查找查询仍然效率低下。因此，我们开始设计一个扩展PolarDB原始执行引擎的新基于列的执行引擎，以满足目标G＃1（透明度）。列式执行引擎的设计旨在满足G＃2（先进的OLAP性能）。而基于行的执行引擎处理不兼容和点查询，前者无法处理。RO节点具有基于行和基于列的执行和存储引擎。
双格式RO节点通过物理REDO日志进行同步。在共享存储架构上，新RO节点可以快速启动以处理激增的只读查询，以满足设计目标G＃5，并可以保持数据新鲜度（即G＃4）通过不断应用RW节点的REDO日志。然而，将异构存储与原始物理日志（即REDO日志）同步是具有挑战性的，因为日志与底层数据结构（例如页面）密切相关。因此，稻草人方法是使RW节点记录用于列存储的附加逻辑日志（例如Binlog）。缺点是，当提交事务时触发额外的fsyncs，从而对OLTP造成非常大的性能干扰。因此，我们专门设计了一种新的同步方法，通过重用REDO并使RO节点上的逻辑操作由物理日志组成。之所以可行是因为PolarDB-IMCI在RO节点上维护基于行的缓冲池和列索引。逻辑操作可以通过在行缓冲池上的应用进程中获得。我们的评估显示，重用REDO日志的开销明显低于使用Binlog。

3.3 用户界面
PolarDB-IMCI中的列存储作为一种新的索引类型公开，即列索引。应用程序可以根据需要为表创建列索引。由于PolarDB-IMCI完全兼容MySQL，因此应用程序可以使用带有MySQL语法的SQL语句来创建列索引。示例如图3所示。它创建了一个具有五个列的表，主键索引在列C1上创建，次要索引在列C2上创建，并在列C3、C4和C5上创建了列索引。
此外，在创建表时指定包含在列索引中的列时，应用程序还可以使用ALTER状态将列索引添加到后来。当应用程序在具有大量行的表上执行数据定义语言(DDL)来添加列索引时，RO节点将在PolarDB-IMCI的行存储上发出一致性读取，扫描检查点，并在并行转换为列索引。请注意，向PolarDB-IMCI添加列索引是一项在线操作：在DDL操作进行时，表上的查询和DML操作可以同时处理。并发DML操作所做的更改将记录在缓冲区中，并在过程结束时应用于新的列索引。