本月围绕数据库Mysql与 Redis与MongDB应用和理论，撰写了 多篇技术博客，内容涵盖原理讲解、部署实操、架构对比及高阶用法，适合有一定开发经验的同学系统性提升。具体内容如下：MongoDB Schema设计进阶https://bbs.huaweicloud.com/forum/thread-0242186151481963009-1-1.htmlRedis缓存三大经典问题：穿透、击穿、雪崩的防御体系与实践方案https://bbs.huaweicloud.com/forum/thread-0270186151287006008-1-1.htmlMySQL Online DDL演进https://bbs.huaweicloud.com/forum/thread-0270186149379800007-1-1.htmlMongoDB分片集群设计精要https://bbs.huaweicloud.com/forum/thread-0245186146589994004-1-1.htmlRedis Pipeline与事务https://bbs.huaweicloud.com/forum/thread-0270186139908337005-1-1.htmlGaussDB全局事务管理https://bbs.huaweicloud.com/forum/thread-0265186139485857004-1-1.htmlMySQL主从复制延迟：深度剖析与全方位优化指南https://bbs.huaweicloud.com/forum/thread-0270186139258938004-1-1.htmlMongoDB聚合框架https://bbs.huaweicloud.com/forum/thread-02111186137859433003-1-1.htmlRedis内存淘汰策略深度解析https://bbs.huaweicloud.com/forum/thread-0270186135899969003-1-1.html📌 本月技术内容聚焦 Redis、Mysql、MongDB，既有底层原理的讲解，也有实战落地的操作方案，欢迎阅读、收藏、转发，如有问题欢迎留言交流，下月见！🚀

【技术干货】6月13日直播回顾丨HCCDA-GaussDB认证考试辅导 本次直播为HCCDA-GaussDB认证考试提供全面辅导，旨在帮助学员深入了解数据库技术原理与应用实践。我们将详细解析考试大纲，分享高效备考策略，并讲解关键知识点。 GaussDB入门级开发者认证分为理论考试和实验考试两部分，60分为通过。理论考试时间为60分钟，试题分为判断：单选：多选，比例为3:4:3（考试题量50）；实验考试共120分钟，以GaussDB实例部署、数据导入、数据库连接配置、在Java代码程序中调用SQL语句实验为重点考点。直播链接：cid:link_0 Q：GaussDB默认的事务隔离级别是什么？A: GaussDB默认的事务隔离级别Read Committed（已提交读）。 Q：开启了三权分立后，系统管理员的权限被进行限制，具体是哪些权限被限制？A： ①系统管理员将不再具有CREATEROLE权限②系统管理员将不再具有AUDITADMIN权限③系统管理员只有对自己作为所有者的对象有权限 Q ： copy工具适用的场景是什么？A： ①小数据量表以文本数据作为来源导入②小数量表的导出③查询结果集导出 Q：可以自己下载安装包么？ A：可以自己下载JDBC驱动包。 Q：请问实验考试前是要自己配置环境吗？ A：不需要，沙箱会预置gsql和ECS。 Q：哪个数据模型以树形结构来描述数据，并且数据结构简单清晰？A: 层次模型使用树形结构简单清晰。 Q：GaussDB支持的三权分立权限访问控制模型中的角色是？A：系统管理员、安全管理员、审计管理员。 Q：怎么获取考试券呢?A：可以关注开发者学堂官网，定期在官网上线活动。 

最近系统经常出现事务超时等待，但是显示的锁全表语句不知道是如何产生的。

在Gaussdb的参数配置中，random_page_cost参数是设置随机扫描一个数据页的代价。这个代价的值应该参考了很久之前postgresql的参数值。这个值设置为4，而对应的顺序扫描页面的值seq_page_cost值是1。刚开始random_page_cost这个值设置为4的原因大概是基于HHD盘，随机扫描代价比较大的考虑。但是如今数据库应该很少用HHD盘的了。所以这个参数的初始值，是不是得进行修改。基于实际磁盘随机读和物理读的代价，修改得稍微比seq_page_cost的值大一点。1.1,1.2左右？这样可以让优化器正确的计算出实际上代价最小的路径。避免多余的消耗。

如下图，安装完TPOPS之后，检查安装包上传进度，结果任务中心啥也没有。安装包是上传成功了。添加主机的时候任务中心也没有数据，主机能初始化成功。请问我该怎么排查？

华为HDC2025大会发布的信息，你都有哪些感受

复杂一点的范围比较cid:link_5Analyze 使用功能cid:link_0统计信息分类cid:link_1采样方法cid:link_2自动收集场景cid:link_6LLVM 技术解析cid:link_7如何使用 LLVMcid:link_3LLVM 适用场景cid:link_8Shared nothing的分布式架构cid:link_9Stream 算子相关的节点cid:link_10向量化执行引擎详解cid:link_11执行框架cid:link_4向量化执行引擎的性能cid:link_12向量化的演进cid:link_13索引解析https://bbs.huaweicloud.com/forum/thread-0241186375247007007-1-1.html

索引能干什么呢？一言以蔽之：查询加速。常见的索引有下面几种：索引类型 描述 B-tree 行存默认使用的索引，综合性索引，特别适用于点查、主键Psort 列存默认使用的索引，存储空间小，导入性能影响小，查询提升效果比较中庸Gin基于 B-tree 树结构的倒排索引，存储被索引字段的 VALUE 或 VALUE 的元素，主要适用于数组过滤、全文检索的场景Gist 一个通用的索引接口，不同的类型支持不同的检索方式，主要适用于位置搜索Hash存储的是被索引字段 VALUE 的哈希值，只支持等值查询，特别适用于字段VALUE 非常长的场景特殊类型 表达式索引、部分索引、唯一索引B-tree 是平衡树，有序存储索引 KEY 值和 TID；对于索引上的过滤条件，通过 KEY 快速找到对应的叶子节点，然后再通过 TID找到实际记录；索引中的数据以非递减的顺序存储（页之间以及页内都是这种顺序），同级的数据页由双向链表连接；支持单列索引和复合（多列）索引，多列复合索引适用于多列组合查询，B-tree索引对于查询条件的顺序有要求；B-tree 索引可以处理等值和范围查询；索引页面不存储事务信息。Psort 索引本身是个列存表，包含索引列和 tid，在索引列上局部排序，利用MIN/MAX 块过滤加速 TID 获取；Psort 索引本身有可见性，但删除、更新数据不会作用到 Psort 索引；Psort 索引更适合做范围过滤，点查询速度较差；批量导入场景下有效，对于单条导入无效。如对于查询“select * from test1 where lower(col1) = ‘value’;”可以建立在Lower 表达式之上的索引“create index on test1(lower(col1));”，后续对于类似在lower(col1)表达式上的过滤条件，就可以直接使用这个索引加速，对于其他表达式该索引不会对查询生效。但需要注意的是：索引表达式的维护代价较为昂贵，因为在每一个行被插入或更新时都得为它重新计算相应的表达式。

在第一代向量化引擎之后，GaussDB(DWS)演化出具有更高性能的向量化引擎：Sonic 向量化引擎和 Turbo 向量化引擎。GaussDB(DWS)为了 OLAP 执行性能提升，在列存+向量化执行引擎、批量计算的路上不断演进：Stream 算子+分布式执行框架，支持数据在多节点间流动；SMP，节点内多线程并行，充分利用空闲硬件资源；LLVM 技术，全新的代码生成框架，JIT(just in time)编译器，消除 tuple deform瓶颈；Sonic 向量化引擎，对 HashAgg、HashJoin 算子进一步向量化，根据每列不同类型实现不同 Array 来对数据做计算；新一代 Turbo 向量化引擎，对大部分算子做进一步向量化，在 Sonic 引擎的基础上，新增了 Null 优化、大整数优化、Stream 优化、Sort 优化等，进一步提升了性能。物化算子是一类可缓存元组的节点。在执行过程中，很多扩展的物理操作符需要首先获取所有的元组才能进行操作（例如聚集函数操作、没有索引辅助的排序等），这是要用物化算子将元组缓存起来。连接算子对应了关系代数中的连接操作，以表 t1 join t2 为例，主要的集中连接类型如下：inner join、left join、right join、full join、semi join、 anti join，其实现方式包括 Nestloop、HashJoin、MergeJoin。 扫描算子用来扫描表中的数据，每次获取一条元组作为上层节点的输入， 存在于查询计划树的叶子节点，它不仅可以扫描表，还可以扫描函数的结果集、链表结构、子查询结果集。

对比行列存引擎对同一表达式x*(1-y)计算的性能，可以看到列存引擎的Cstore Scan算子相比行存引擎的 Seq Scan 算子，耗时减少了 85%。向量计算的特点是：一次计算多个值，减少函数调用和上下文切换，尽量利用 CPU 的缓存以及向量化执行指令提高性能。向量化执行引擎的性能优势：一次一 Batch，读取更多数据，减少 IO 读次数；由于 Batch 中记录数多，相应的 CPU 的 cache 命中率提升；Pipeline 模式执行过程中的函数调用次数减少；与列存表配套，减少 tuple deform，即列存数据重构 tuple 的时间开销。向量化引擎的执行算子类似于行执行引擎，包含控制算子、扫描算子、物化算子和连接算子。同样会使用节点表示，继承于行执行节点，执行流程采用递归方式。主要包含的节点有：CStoreScan（顺序扫描），CStoreIndexScan（索引扫描），CStoreIndexHeapScan（利用 Bitmap 获取元组），VecMaterial（物化），VecSort（排序），VecHashJoin（向量化哈希连接）等，下面将逐一介绍这些执行算子。扫描算子用来扫描表中的数据，每次获取一条元组作为上层节点的输入， 存在于查询计划树的叶子节点，它不仅可以扫描表，还可以扫描函数的结果集、链表结构、子查询结果集。

执行器是优化器与存储引擎的交互枢纽。以优化器生成的执行计划树为输入，从存储引擎访问数据，并按照计划，操作各种执行算子，从而实现数据的处理。采用 Pipeline 模式, 行执行器一次一 tuple，列执行器一次一 batch。上层驱动下层，使得数据在执行树上流动。提供各种数据处理的执行算子。下图展示了自上而下的控制流和自下而上的数据流。执行器的执行过程可分为这三个步骤：1) 执行器初始化：构造执行器全局状态信息 estate、递归遍历计划树各节点，初始化其执行状态信息 planstate 2) 执行器的执行：行引擎和向量化引擎入口独立开，从计划树根节点开始，递归遍历到叶节点获取一个 tuple/batch，经过逐层节点算子的处理，返回一个结果tuple/batch，直到再无 tuple/batch。3) 执行器的清理：回收执行器全局状态信息，清理各 plan node 的执行状态。行执行器的问题是：CPU 大部分处理在遍历 Plan Tree 过程，而不是真正处理数据，CPU 有效利用率低。列存表独有的应用场景，需要配套的向量化引擎，才能真正发挥其在OLAP 场景下提升性能的优势。因此，列执行器的改造基本思路为：一次处理一列数据。和行执行器一样，向量化执行引擎调度器，遵循 Pipeline 模式，但每次处理及在算子间传递数据为一次一个 Batch（即 1000 行数据），CPU 命中率提高，IO 读操作减少。

GaussDB(DWS)包含三大引擎，一是 SQL 执行引擎，用来解析用户输入的 SQL 语句，生成执行计划，供执行引擎来执行；二是执行引擎，其中包含了行执行引擎和列执行引擎，执行引擎即查询的执行者，位于优化器和存储引擎之间，负责将数据从存储引擎中读取出来，并根据计划将数据处理加工后返回给客户端，执行引擎的目标是为了更好地利用计算资源，更快地完成计算。三是存储引擎，决定了数据库数据的存取方式，直接影响了数据库的读写性能。其中行执行引擎应用于行存表中，传统的 OLTP（OnLine Transaction Processsing 联机事务处理）场景与功能、业务强相关，数据需要进行频繁的增删改查，这时比较适合使用行存储式。行存储的优势主要有两个方面：首先是点查性能好，在点查场景下可以直接索引到某行数据的元组位置；其次就是更新效率高，行存储在实时并发入库，并发更新方面依然有着比较大的优势。行执行引擎的关键就是：一次处理一行数据，即一 tuple，适合数据频繁更新，增删改操作多，且查询结果涉及表的多列的场景。传统的行执行引擎大多采用一次一元组的执行模式，这样在执行过程中 CPU 大部分时间并没有用来处理数据，更多的是在遍历执行树，就会导致 CPU 的有效利用率较低。而在面 对 OLAP 场景巨量的函数调用次数，需要巨大的开销。为了解决这一问题，GaussDB(DWS)中增加了向量化引擎。向量化引擎使用了一次一批元组的执行模式，能够大大减少遍历执行节点的开销。同时向量化引擎还天然对接列存储，能够较为方便地在底层扫描节点装填向量化的列数据。列存+向量化执行引擎，是打开 OLAP 性能之门的金钥匙之一。

Gather Stream，用于 CN 收集 DN 的结果；Redistribute Stream，用于将 DN 上的数据重分布给其他 DN 做 HashAgg。Q1 查询是一个单表查询，为什么需要在 DN 之间重分布数据呢？tpch 的 Q1 是对 lineitem 表的单表查询，进行分组聚集计算。因为 lineitem 表是按照 l_orderkey 列作为分布列，将数据分布到各 DN 的。而聚集操作分组键是l_returnflag 和 l_linestatus，而不是分布键 l_orderkey，所以，属于同一个分组的数据分布在不同的 DN 上，这就需要各 DN 重新按照分组键作为分布键，将数据分发给其他 DN，使得各 DN 上拥有相同分组键的数据完成聚集操作。从以上的计划中，可以看到在 DN 上先做了 hashagg，再又重分发给其他 DN，再次做 hashagg，如下图中的右侧。为什么不是先把数据重分布发给其他 DN 后，做一次 hashagg 即可。这两个计划的区别在于：如果 scan 后数据量非常大，而聚集后数据量比较小的情况，就适合用第二个计划，可以减少 DN 之间的数据流动，降低网络开销。从上面 Q1 的执行计划中，可以明显看到，Seq Scan on lineitem 对应的 E-rows 为 6001622，即 seqscan后的数据估计有 6001622 行，重分布之前 HashAggregate 的的结果数据估计只有 18行，数据量大大减少。根据代价估算，重分布前做一次 hashagg 的代价，比直接重分布scan 的结果的代价要小很多，故选择了重分布前先做一次 hashagg。在这个计划中我们看到对 region 表的扫描结果使用 Broadcast 方式广播给其他 DN节点，然后在各 DN 上和 nation 表做 Nestloop 连接。

CN(Coordinator Node)为对外服务和协调节点，负责接收客户端连接以及对用户 SQL 命令解析下发，并收集 DN 节点执行的结果进行汇总，将结果展现给客户端；DN(Datanode)为内部数据节点，承载内部数据存储及计算单元的功能；GTM(Global Transaction Manager)负责集群全局事务控制，其与 Datanode均有本地主备双机功能。对应于分布式架构， GaussDB(DWS) 提供了分布式执行框架，这也是GaussDB(DWS)中最核心的技术，旨在充分利用 DN 的资源，尽量将计算下推到 DN 进行，避免 CN 成为瓶颈，以提升查询效率和系统扩展性。分布式执行框架的技术特点如下：CN 负责查询请求的解析、基于代价进行优化以及向 DN 进行任务下发，并收集DN 节点执行的结果进行汇总；DN 上运行执行计划进程，基于本节点存储的数据执行任务；执行过程中每个算子都是接收下级算子的数据输入，并向上级算子输出数据。是一个生产者—消费者的流水线工作模型。首先从 id 为 6 的行开始，对 lineitem 表执行 seqscan；id 为 5 的行，对下层扫描得到的数据根据 GROUP BY 分组键执行hashaggregate 操作；id 为 4 的行，是一个 Redistribute Stream 算子，它将在 DN 上的 local 数据执行 agg 后结果，重分布给其他 DN；id 为 3 的行，各 DN 收到其他 DN 上的数据，重新做 agg；id 为 2 的行，对下层的 agg 结果进行排序；id 为 1 的行，是一个 Gather Stream 算子，CN 节点收到 DN 返回的结果，汇集后将最终结果展示给客户端

HCS8.3.1搭建Gauss DB24.1.30版本自动备份至OBS3.0对象存储失败，数据库备份的网络策略如何放通？需要放通的端口是什么？