做网站带来好处,给人做ppt的网站,百度搜索风云榜游戏,应用软件的开发过程GaussDB关键技术原理#xff1a;高性能#xff08;三#xff09;从查询重写RBO、物理优化CBO、分布式优化器、布式执行框架、轻量全局事务管理GTM-lite等五方面对高性能关键技术进行了解读#xff0c;本篇将从USTORE存储引擎、计划缓存计划技术、数据分区与分区剪枝、列式存…GaussDB关键技术原理高性能三从查询重写RBO、物理优化CBO、分布式优化器、布式执行框架、轻量全局事务管理GTM-lite等五方面对高性能关键技术进行了解读本篇将从USTORE存储引擎、计划缓存计划技术、数据分区与分区剪枝、列式存储和向量化引擎、SMP并行执行等方面继续介绍GaussDB高性能关键技术。
目录
3.6 USTORE存储引擎
3.7 计划缓存计划技术
3.8 数据分区与分区剪枝
3.9 列式存储和向量化引擎
向量化执行引擎
3.10 SMP并行执行 3.6 USTORE存储引擎
GaussDB新增的Ustore存储引擎相比于Append Update追加更新行存储引擎Ustore存储引擎可以提高数据页面内更新的HOT UPDATE的垃圾回收效率有效减少多次更新元组后存储空间占用的问题。设计原理上Ustore存储引擎采用NUMA-aware的Undo子系统设计使得Undo子系统可以在多核平台上有效扩展同时采用多版本索引技术解决索引清理问题有效提升了存储空间的回收复用效率。Ustore存储引擎结合Undo空间可以实现更高效、更全面的闪回查询和回收站机制能快速回退人为“误操”为GaussDB Kernel提供了更丰富的企业级功能。Ustore基于Undo回滚段技术、页面并行回放技术、多版本索引技术、xLog无锁落盘技术等实现了高可用高可靠的行存储引擎。 USTORE存储引擎作为原有ASTORE存储引擎的替代者其核心目标定位于
1针对OLTP场景实现Inplace-update利用Undo实现新旧版本分离存储降低类似于AStore存储引擎由于频繁更新或闪回功能开启导致的数据页空间膨胀以及相应的索引空间膨胀。
2通过在DML操作过程中执行动态页面清理去除VACUUM依赖减少由于异步数据清理产生的大量读写I/O。通过Undo子系统实现事务级的空间管控旧版本集中回收。
3对插入、更新、删除等各种负载的业务性能和资源使用表现相对平衡。在频繁更新类的业务场景中更新操作采用原地更新模式可以获得更高、更平滑的性能表现。适合“短”(事务短)、“频”(更新操作频繁)、“快”(性能要求高)的典型 OLTP类业务场景
3.7 计划缓存计划技术
数据库接收到SQL语句后通常要经过如下处理词语法解析-优化重写-生成执行计划- 执行从开始解析到计划生成其实是一个比较耗时的过程一个常用的思想就是将计划缓存下来当执行到相似的SQL时从而可以复用计划跳过SQL语句生成执行计划的整个过程在一般OLTP业务负载中由于涉及到的数据量较少同时借助索引技术能够大大加速数据的访问路径因此查询的解析、重写、优化阶段占比会比价高如果能够讲一些模板性质的语句计划缓存起来每次设置不同的参数那么点查询的处理流程能够大大简化提升查询时延和并发吞吐量。 计划缓存技术当数据库收到一条 SQL 请求后首先会通过查询即系模块对 SQL 文本做一次快速参数化处理参数化处理的作用是把 SQL 文本中的常量参数替换成通配符 ?例如 SELECT * FROM t1 WHERE c1 1 会被替换为 SELECT * FROM t1 WHERE c1 ?。接着数据库会从计划缓存中查看有没有已经生成好的计划给这条参数化后的 SQL 使用。如果找到了可用的计划数据库就会直接执行这个计划。如果没有找到可用的计划数据库会重新为这条 SQL 生成执行计划并把生成好的计划保存到计划缓存中以备后续的 SQL 使用。通常情况下从计划缓存中直接获取执行计划相比于重新生成执行计划耗时通常会低至少一个数量级因此使用计划缓存可以大大降低获取执行计划的时间从而减少 SQL 的响应时间。 上图为对比走计划缓存、不走计划缓存的SQL执行过程可以看到执行待计划缓存的查询语句可以规避掉大量的处理逻辑在OLTP并发负载场景下提升效果镜像首先事务型负载单条查询执行时间本身就在毫秒级ms查询解析、RBO/CBO优化等一些列过程也是毫秒级往往会超过查询本身的执行时间另一方面查询解析、RBO/CBO本身是消耗CPU计算资源的操作这对事务型高并发、高吞吐的事务型复杂起来说非常明显的资源占用如果能将这部分资源剩下、同时将查询解析的时延消减为0对整体性能是非常明显的提升
3.8 数据分区与分区剪枝
在数据系统中数据分区是在一个实例内部按照用户指定的策略对数据做进一步的数据切分将表按照指定规则划分为多个数据互不重叠的部分。从数据分区的角度来看是一种水平分区horizontal partition分区策略方式。分区表增强了数据库应用程序的性能、可管理性和可用性并有助于降低存储大量数据的总体拥有成本。分区允许将表、索引和索引组织的表细分为更小的部分使这些数据库对象能够在更精细的粒度级别上进行管理和访问。GaussDB Kernel提供了丰富的分区策略和扩展以满足不同业务场景的需求。由于分区策略的实现完全由数据库内部实现对用户是完全透明的因此它几乎可以在实施分区表优化策略以后做平滑迁移无需潜在耗费人力物力的应用程序更改
1改善查询性能对分区对象的查询可以仅搜索自己关心的分区提高检索效率
2增强可用性如果分区表的某个分区出现故障表在其他分区的数据仍然可用。
3方便维护如果分区表的某个分区出现故障需要修复数据只修复该分区即可。 常见数据库支持的分区表为范围分区表、列表分区表、哈希分区表、间隔分区、组合分区a.w.k 组合分区。
1范围分区Range Partition将数据基于范围映射到每一个分区这个范围是由创建分区表时指定的分区键决定的。这种分区方式是最为常用的。范围分区功能即根据表的一列或者多列将要插入表的记录分为若干个范围这些范围在不同的分区里没有重叠然后为每个范围创建一个分区用来存储相应的数据。
2列表分区List Partition将数据基于各个分区内包含的键值映射到每一个分区分区包含的键值在创建分区时指定。列表分区功能即根据表的一列将要插入表的记录中出现的键值分为若干个列表这些列表在不同的分区里没有重叠然后为每个列表创建一个分区用来存储相应的数据。
3哈希分区Hash Partition将数据通过哈希映射到每一个分区每一个分区中存储了具有相同哈希值的记录。
4间隔分区Interval Partition可以看成是范围分区的一种增强和扩展方式相比之下间隔分区定义分区时无需为新增的每个分区指定上限和下限值只需要确定每个分区的长度实际插入的过程中会自动进行分区的创建和扩展。间隔分区在创建初始时必须至少指定一个范围分区范围分区键值确定范围分区的高值称为转换点数据库为值超出该转换点的数据自动创建间隔分区。每个区间分区的下边界是先前范围或区间分区的非包容性上边界。
5二级分区Sub Partition也叫组合分区是基本数据分区类型的组合将表通过一种数据分布方法进行分区然后使用第二种数据分布方式将每个分区进一步细分为子分区。给定分区的所有子分区表示数据的逻辑子集。常见的二级分区组合由Range、List、Hash组成。
分区表对查询性能最大的贡献是分区剪枝优化技术数据库SQL引擎会根据查询条件只扫描特定的部分分区。分区剪枝是自动触发的当分区表查询条件符合剪枝场景时会自动触发分区剪枝。根据剪枝阶段的不同分区剪枝分为静态剪枝和动态剪枝静态剪枝在优化器阶段进行在生成计划之前数据库已经知道需要访问的分区信息动态剪枝在执行器阶段进行执行开始/执行过程中在生成计划时数据库并不知道需要访问的分区信息只是判断“可以进行分区剪枝”具体的剪枝信息由执行器决定。 注意分区表由于相比普通表多了一层分区选择的处理逻辑一般而言在数据导入场景下会有一定的性能损耗。
3.9 列式存储和向量化引擎
传统关系型数据库中对数据模式都是以元组记录的形式进行理解和存取但是在大数量偏分析类的OLAP应用场景中属于以列方式存储能够获得更高的执行效率GaussDB Kernel支持行存储和列存储两种存储模型用户可以根据应用场景建表的时候选择行存储还是列存储表。一般情况下如果表的字段比较多大宽表查询中涉及到的列不是很多适合列存储如果表的字段个数比较少查询大部分字段那么选择行存储比较好以下是行存表、列存表在存储模型上的对比。 可以看到通常在大宽表、数据量比较大的场景中查询少数特定的列、行时行存引擎查询性能比较差。例如单表有200~800个列经常查询访问的仅其中10个列在这种情况下向量化执行技术和列存储引擎可以极大地提升性能减少存储空间。
向量化执行引擎
针对数据的列式存储GaussDB在执行层改进了传统的执行引擎数据流遵循一次一元组的VectorBatch模式而向量化引擎VectorEngine将这个执行器算子数据传递、计算模型改成VectorBatch模式这种看似简单的修改却带来非常明显的性能提升。 其中的主要提升原因可以应对上面介绍的CPU架构里影响性能的几个关键因素
1Batch模式的函数模型在控制流的调动下每次都需要进行函数调用调用次数随着数据增长而增长而一批元组的模式则大大降低了执行节点的函数调用开销如果我们设定Batch元组数量为1000函数调用相对于一次一元组能减少三个数量级。
2VectorBatch模式在内部实现通过数组来表达数组对于CPU的预取非常友好能够让数组在后续的数据处理过程中大概率能够在CACHE中命中。比如对于下面这个简单计算两个整形加法的表达式函数其代码仅为了展示不代表真实实现下面展示了单元组和VectorBatch元组的两种写法。
单元组的整形加法
int int4addint4(int4 a, int b)
{
return ab;
}
VectorBatch模式的整型加法
void int4addint4(int4 a[], int b[], int res[])
{
for(int i 0; i N; i)
{
res[i] a[i] b[i];
}
} 3VectorBatch模式计算函数内部因为CPU CACHE的局部性原理数据和指令的cache命中率会非常好极大提升处理性能同时也为数据数组化的组织方式为利用SIMD特性带来了非常好的机会SIMD能够大大提升在元组上的计算性能还是以刚才上述整形加法的例子我们可以重写上述的函数如下。可以看到由于SIMD可以一次处理一批数据循环的次数衰减性能能得到进一步提升。
void int4addint4SIMD(int4 a[], int b[], int res[])
{
for(int i 0; i N/SIMDLEN; i)
{
res[i..iSIMDLEN] SIMDADD(a[i..iSIMDLEN], b[i..i SIMDLEN];
}
} 在当前GaussDB里向量化引擎和普通行存引擎共存对上上层用户透明行引擎处理单元TupleSlot与向量化引擎处理单元VectorBatch通过行转列Row2Vec、列转行Vec2Row进行在线转换因此在复杂查询中涉及到行存、列存表时优化器能够结合代价模型并针对一些典型场景判断使用向量化引擎、行存引擎进行处理将资源利用最大化。
3.10 SMP并行执行
GaussDB Kernel的SMP并行技术是一种利用计算机多核CPU架构来实现多线程并行计算以充分利用CPU资源来提高查询性能的技术。在复杂查询场景中单个查询的执行较长系统并发度低通过SMP并行执行技术实现算子级的并行能够有效减少查询执行时间提升查询性能及资源利用率。SMP并行技术的整体实现思想是对于能够并行的查询算子将数据分片启动若干个工作线程分别计算最后将结果汇总返回前端。SMP并行执行增加数据交互算子Stream实现多个工作线程之间的数据交互确保查询的正确性完成整体的查询。
并行技术是提升数据库处理能力的有效手段关于并行技术GaussDB总体升分成了两个大类
1提升单节点ScaleUp决定整体系统的理论性能上限充分发挥单节点CPU、内存资源的对业务输出的贡献程度。
2提升分布式ScaleOut决定整体系统的实际性能上限分布式实现的好坏决定了横向的线性扩展比。 SMP对称多处理的实现过程
1SMP计划生成一阶段计划生成在路径生成阶段加入并行路径最终根据代价决定所选择的计划两阶段计划生成第一步生成原有的串行计划第二步在将串行计划改造成适应并行的计划。
2SMP执行过程为并行执行线程之间进行数据分配、交换和汇总(Scan类磁盘stream网络)。 SMP对称多处理自适应选择
SMP优化执行对当前执行的资源环境因素相关因此 不同的硬件环境、不同系统负载的情况下可用的计算资源存在差异不同时刻特定查询复杂度需要的计算资源也存在不同自适应SMP目标在于基于当前系统可用资源以及可生成SMP计划的情况综合判定查询的执行计划。SMP自适应分为两个阶段第一阶段确定初始dop第二阶段对基于初始dop生成的计划进行优化。在第一阶段考虑CPU资源、串行还是并发。在第二阶段考虑计划复杂程度。
1资源情况CPU core服务器CPU core 数量 / 服务器部署DN数量串行/并发可用CPU core * 1 – CPU usage。
2查询复杂度执行计划被stream算子拆分成多个片段每个片段由一个线程执行。该计划中有多少stream可以无阻塞的运行决定了整个计划的最大并行线程数。采用特征匹配来识别查询复杂度。 以上内容从USTORE存储引擎、计划缓存计划技术、数据分区与分区剪枝、列式存储和向量化引擎、SMP并行执行等五方面对高性能关键技术进行了分享下篇将从LLVM动态查询编译执行、SQL-BYPASS执行优化、线程池化、多核处理器优化、日志无锁刷新与多级流水等方面继续解读GaussDB高性能关键技术并对高斯数据库性能优化进行总结敬请期待
