DBeaver是一个通用的数据库客户端，可以通过配置不同驱动连接各种不同的数据库。本章介绍如何通过DBeaver连接GaussDB实例。步骤一：获取驱动包获取驱动包和驱动包校验包。根据不同版本的实例，下载对应版本的驱动包和驱动包校验包到本地任意目录校验驱动包。为了防止驱动包在传递过程或存储期间被恶意篡改，需要对驱动包进行校验，校验方法如下：使用快捷键“Win+R”打开“运行”窗口。 在“打开”栏，输入“cmd”，按“Enter”回车，打开命令行页面。执行以下命令，获取驱动包的Hash值。certutil -hashfile {驱动包本地目录}{驱动包名} sha256{驱动包本地目录}：请根据实际下载目录进行替换。例如：C:\Users{驱动包名}：请根据实际下载的驱动包名进行替换。例如：GaussDB_driver.zip示例：certutil -hashfile C:\Users\GaussDB_driver.zip sha256将2.b获取到的Hash值和1中获取到的驱动包校验包的Hash值进行比较。若一致则通过校验。若不一致，请重新下载驱动包，重复2.a~2.c进行校验。解压驱动包，获取gsjdbc4.jar包。将1中获取到的驱动包解压到本地， 根据您需要连接的实例类型，进入驱动包对应类型目录下的任意一个操作系统目录，找到GaussDB-Kernel_数据库版本号_操作系统版本号_64bit_Jdbc.tar.gz包后进行解压，获取到gsjdbc4.jar包，放在本地任意目录下。例如：需要连接分布式版实例，您可以进入到GaussDB_driver\Distributed\Euler2.5_X86_64路径下，找到GaussDB-Kernel_503.1.0.SPC2300_Euler_64bit_Jdbc.tar.gz包进行解压，获取到gsjdbc4.jar包。说明：JDBC驱动包不区分操作系统和架构。因此，在获取gsjdbc4.jar包时，只需要关注实例类型即可。步骤二：获取DBeaver客户端安装包DBeaver官网提供了针对不同操作系统的客户端安装包，单击此处访问DBeaver官网下载系统对应的DBeaver客户端安装包并完成安装 。步骤三：创建新驱动打开DBeaver客户端。单击“数据库 > 驱动管理器”，打开驱动管理器界面。单击“新建”，打开创建新驱动界面。在“设置”页签中，正确输入驱动名称、类名、URL模板、默认端口、Default Database、Default User，选择驱动类型，单击“确定”创建驱动。在“库”页签中，单击添加文件，选择步骤一第3步中的gsjdbc4.jar。添加后驱动类为空，需要单击“找到类”，选择识别出来的驱动类。驱动类需要与“设置”页的“类名”一致。单击“确定”，驱动设置完成。步骤四：连接数据库在DBeaver客户端单击，打开创建连接界面。搜索步骤三中创建的驱动，选中驱动，单击“下一步”。点击放大输入主机IP地址，端口，数据库名，用户名和密码。单击“测试链接”。若弹框中显示“已连接”，则说明可正常连接，单击“确定”。单击“完成”，即可连接到数据库。在“数据库导航”栏可查看到连接的数据库信息。

华为GaussDB(DWS)的优势有哪些

Psort 索引cid:link_1 索引的利与弊cid:link_2GaussDB(DWS)查询提速cid:link_3PCK(partial cluster key)cid:link_4VACUUM的作用cid:link_5行存VACUUM主要做的三件事cid:link_6VACUUM FULL执行流程cid:link_7GaussDB(DWS) IO框架解析cid:link_8IO 管理框架：读取cid:link_9行存插入操作到提交的流程cid:link_10WAL（Write-Ahead Logging）cid:link_11列存的IO管理框架cid:link_0IO 管理读取过程cid:link_12GaussDB(DWS) IoT数仓解析cid:link_13时序数据库应用场景https://bbs.huaweicloud.com/forum/thread-0201189181473510046-1-1.html

典型时序数据库主要服务两类业务场景，应用性能监控（Application Performance Management, APM）和物联网（Internet of Things, IoT）。 商业零售：电商系统订单交易金额，支付金额数据，尚品库存，物流数据； 金融交易：股票交易系统持续记录股票价格，交易量等； 社会生活：智能电表会实时记录每个小时的用电量数据等； 工业领域：工业机器数据例如风力发电机，获取实时转速、风速数据、发电量数据等； 系统监控：IT基础设施的负载和资源使用率，DevOps监控数据、移动/Web应用程序事件流等； 环境监测：自然环境（如温度、空气、水文、风力等）的监测，科学测量结果等； 城市管理：城市交通的监测（车辆、人流、道路等）； 自动驾驶：自动驾驶汽车持续收集所处环境中的变化数据等。

万物互联的时代，最不缺少的就是海量数据，爆炸性增长的数据能给我们带来什么价值，我们如何通过这些海量数据看清事物的本质，甚至能够预测事物的发展趋势，这些是我们面对的挑战和需要解决的问题。时序数据库是这个时代的产物，也不断驱动着这个世界向万物互联不断迈进。 随着5G技术的不断成熟，物联网技术得到了快速发展，万物互联的场景在我们身边也越来越触手可及。我们身边的电子设备变得越来越多，手机、电脑、智能手表、全屋智能、自动驾驶汽车等等，承载的信息量成倍增加，数以亿计的信息昼夜不停地描绘着这个世界。 物联网时代，每个物体每时每刻都在产生各种维度的数据信息，这些信息尽可能全面的刻画我们所生活的世界，这些采集到的数据信息，帮助我们更好的生活，不断改变我们的生活方式。例如当下非常火热的自动驾驶，需要在汽车上配备各种传感器，用以实时采集运行时汽车的各项监控数据，采集的维度包括：坐标、速度、方向、温度、功率等等。每辆汽车上的传感器每天采集数据的数量级可能达到TB级。 这些采集到的数据和时间强相关，采样时间间隔固定，描述了物体在历史时刻中测量数据的变化，我们将这种类型的数据统称为时间序列（Time Series）数据。我们将这些时序数据存储起来，这些海量数据不仅帮助我们了解物体的实时状态，通过多个维度的分析，更能够帮助数据使用者更好的指定策略，分析目标对象的趋势和规律等，甚至能够帮助我们预测不确定的未来。 我们将时序数据列做了以下三种分类： 1) Tag列：通常将表征数据源来源或者属性信息的列作为Tag列，该列的数值通常相对稳定，不随时间变化而变化； 2) Field列：一般将采样的维度作为数据列，因为该列的数据一般随时间变化而变化，存储各个指标的value； 3) Time列：表示采样时刻的时间戳。 

读取过程： 根据where条件，做MIN/MAX过滤的谓词条件； 加载CUDesc； MIN/MAX过滤； 读取CU到CU Cache中； 解析并填充。 2) CacheMgr: 用来缓存CU到内存中，可以提高重复查询的性能。 3) CU的物理文件： CStore_1.0: 当前基本不怎么实用； CStore_2.0: 重整了CU的文件结构，避免列数过多导致文件结构复杂。列存的插入要分两种情况，少量的插入和大量的插入，列存主要是对大批量数据设计的，因此为了弥补小量插入的打包CU性能开销，设计了一个delta行存表，用来记录插入结果，可以减少膨胀和提升性能，最后定期的整理。列存的删除比较简单，如果是delta表，先从delta表中删除满足谓词条件的记录，然后在CUDesc表中更新待删除CU的delete_bitmap。行存列存的设计结构，以行存和列存为例对GaussDB(DWS)的IO方面的主要机制做了梳理。分别对行存和列存和IO的读写做了解释。行存和列存由于组织方式不同，适合不同的场景，GaussDB(DWS)现在也有HStore。解决了 CU上并发更新的锁冲突问题。

列存的存储单元为CU（CStore Unit)； CU的大小为8k对齐； 适合大批量导入的场景； 同一列的CU存在一个新文件中，大于1GB时，切换到新文件中； 列存用一个CUDesc的行存表描述CU的相关信息，可以理解成为一个Toast表； CUDesc：行存表，记录CU的相关信息, 主要属性如下： col_id,cu_id: 第col_id 列，第cu_id个CU； min, max, row_count, size； cu_mode: information mask(RLE,LZ4,Delta表等）； cu_pointer:指向每一个CU,记录delete bitmap； magic：和CU头部的magic相同，校验使用。 索引结构和行存无差别，同样以行存形式存储； C-Btree可以提升点查效率； 存储key->ctid（cu_id, offset)； 过程： 根据B-tree索引找到ctid集合； 对集合进行批量排序（减少IO开 销 ）； 在CUDesc找到对应的cu_id，根据offset找到数据。PSort 是一个聚簇索引，对索引进行排序，然后将排序后的索引和行号存入一个新的表，用单独的列存表存储。

非即时写入：WAL 记录首先写入 WAL 缓冲区，并不是立即写入硬盘。这是为了减少磁盘 I/O，优化性能。 定期写入：由后台线程 WAL Writer 负责定期将 WAL 缓冲区中的记录刷新到磁盘。 事务提交时确保写入： 事务在 COMMIT 时，必须确保该事务的所有 WAL 记录已经写入硬盘，从而保证事务的持久性； GuassDB(DWS) 通过 synchronous_commit 参数来保证事务提交的持久性； 当 synchronous_commit 为 on，提交事务会等待所有 WAL 记录写入后才返回成功； 用户在收到 COMMIT 命令的成功响应后，可以确信事务已经安全提交； 在系统故障的情况下，GaussDB(DWS) 的恢复机制会使用 WAL 来保证事务的完整性； 这个机制确保了用户在事务级别上的数据持久性，即使用户无法直观感知 WAL 的具体写入细节。CLOG（Commit Log）记录事务是否提交或回滚，而 WAL（Write-Ahead Logging）记录了事务的具体修改操作。两者的作用虽然相似，都是为了保证事务的持久性和数据库的恢复能力，但它们的设计和写入时机有所不同。 可能延迟写入：CLOG 记录事务的提交状态，可能不会在每次事务提交时立即写入硬盘。 由 Checkpointer 处理：CLOG 的写入通常在检查点时由 Checkpointer 或其他后台进程执行，确保所有已提交事务的 CLOG 记录被写入硬盘。 

共享缓冲池（Shared Buffer Pool）： 插入操作开始时，元组首先被写入内存中的共享缓冲池。这是所有后台进程共享的内存区域； WAL（Write-Ahead Logging）缓冲区：元组写入共享缓冲池的同时，相关更改的WAL记录被写入WAL缓冲区； LSN(Logic Sequence Number): WAL记录包含一个逻辑序列号（LSN）， 确保每条记录的位置唯一； 物理文件: 虽然元组已经在共享缓冲池中，但尚未写入磁盘上的物理文件。这个写入动作依赖于后续的刷新或检查点操作。需要说明的是，GuassDB(DWS)依赖linux 系统的写入（例如fwrite），所以仍然会有一定的延迟； WAL写入者（WAL Writer）：负责定期将 WAL 缓冲区中的记录写入磁盘上的WAL文件； 后端（Backend）：后端线程处理客户端请求，在这里是执行插入操作的进程； Bgwriter 和 Checkpointer： 这些后台线程负责将共享缓冲池中的数据定期写入磁盘。Bgwriter 可以异步写入，而 Checkpointer 则在检查点发生时写入； CLOG（Commit Log）缓冲区：事务提交时，其状态被写入 CLOG 缓冲区。CLOG 记录了事务的提交或回滚信息； 检查点（Checkpoint）：数据库执行的定期操作，确保所有之前的事务修改都已经写入磁盘。

读取的过程相对简单，就是从物理文件先装到 shared_buffer 中，然后从shared_buffers 返回相关的结果。shared_buffers 中就是以 Page 为单位进行存储的，因为每个Page的大小是固定的，所以shared_buffers 能存放的 page 个数也就是确定的。这里面就需要考虑一个问题，因为这个资源是共享的，如果一个线程读取了大量的文件，这样势必会使得其他线程的缓存命中率下降。 GaussDB(DWS)在这引入了 Ringbuffer 的机制，可以限制一个线程所使用的shared_buffers 的大小，从而解决掉这个问题。写入操作是增加的新的元组，Update操作相当于先Delete,再Insert。将旧元组标记为Dead，然后插入新的元组，由VACUUM负责清理。当然，这里面Data 变为DELETE只是用来描述删除的是此Tuple，实际上Data当中的值是不变的。 

数仓的IO结构一直是影响性能的关键部分，数据库的操作最终还是要体现在最后的物理文件上，那么了解整个 IO 模型对于数仓的调优，索引的使用等都具有很好的指导作用。每个表的读取写入以页（文件块）为基本单位，页的大小是一个BLCKSZ，默认8KB。Tuple保存了当前一行的数据，分为Header和Data两块，头部保存元组的相关信息（列数，事务信息，是否有Toast表 等 ）； 每个Tuple最大为2kb，若Data过大无法压缩至2KB，则采用额外的Toast表存储，此时Tuple内的Data保存Toast表的相关信息。  共享内存：可由整个Gaussdb共享，包括shared_buffer 和wal_buffer, 分别用来存放Page和Clog，Wal Segment。 1) WalWriter，BgWriter：主要是将共享内存的内容落盘，WalWriter一般是在事务提交时就需要落盘，但是有时候可以放弃一定的事务一致性原则，从而让WalWriter 异步落盘加快速度。BgWriter负责将shared_buffer中的内容落盘。 2) 外存管理：负责上层与外存之间的文件交互。 

1) 建立临时表：数据库创建一张临时表，该表继承老表的所有属性。该阶段会申请7级锁（ExclusiveLock），可以与select并发； 2) 数据复制：将原来表中的数据复制到临时表中。在该过程中完成对dead tuples的清理。该阶段申请的是访问排他锁AccessExclusiveLock； 3) 交换表：使用新表代替老表。交换的本质是物理文件的交换，即临时表拿老物理文件，老表拿新物理文件。该阶段会申请八级锁（AccessExclusiveLock）； 4) 重建索引：当交换完成后，会进行索引重建，并更新统计信息； 5) 删除临时表：索引重建完成后，会将带有老物理文件的临时表进行删除。影响VACUUM效果的因素1) Oldestxmin的推进 vacuum 只能清理掉当前全局存活的最老事务(OldestXmin)之前的事务所产生的垃圾数据，所以如果仍然存在老事务的话（比如长事务或者长sql 的存在）,新事务所产生的垃圾数据并不会被vacuum立即清理。元组被删除后，只有当VACUUM将元组的LinePointer(或者叫item pointer, 指向具体的元组)置为LP_UNUSED状态后，该LinePointer才有可能在新插入数据时复用。 2) Fsm还未生成插入数据时，依赖fsm文件来选择可用的page，如果fsm没有生成则会导致使用新的page而不是复用旧的。 

1) 移除死亡元组并对满足条件的老元组执行frozen操作； 2) 移除指向死亡元组的索引元组，更新对应表的fsm 和 vm 文件； FSM: free space map 空闲空间映射文件，插入数据时会根据该文件来选择合适的page； VM: visibility map 可见性映射文件，后续vacuum时会根据该文件来选择是否扫描某个page,提高VACUUM效率；同时在进行index-only-scan时也会使用该文件来提高可见性判断的效率）。 3) 更新统计数据pg_stat_all_tables。 Linepointer 不会被移除，用于在之后复用。 行存LAZY VACUUM执行流程1) 从指定的多张表中进行遍历，从而获取每一个表； 2) 获取遍历到表的共享锁，该锁允许其他事务读取； 3) 获取每个页面的dead tuples(死亡元组)，并freeze需要的元组； 4) 删除指向dead tuples的元组； 5) 删除dead tuples并重新分配live tuples(活动元组)； 6) 更新目标表的FSM（用于记录每个数据块的空闲空）和VM（标记数据块中是否存在需要清理的行）； 7) 重复5、6步骤直到遍历完该表的每一页； 8) 如果最后一页没有元组，则进行截断； 9) 更新与VACUUM有关的统计信息表和系统目录。 

在GaussDB(DWS)中，VACUUM的本质就是一个“吸尘器”，用于吸收“尘埃”。而尘埃其实就是旧版本数据，如果这些数据没有及时清理，那么将会导致数据库空间膨胀，性能下降，更严重的情况会导致宕机。1）空间膨胀问题：清除废旧元组以及相应的索引。包括提交的事务delete的元组（以及索引）、update的旧版本（以及索引），回滚的事务insert的元组（以及索引）、update的新版本（以及索引）、copy导入的元组（以及索引）； 2）freeze：防止因事务 ID 回卷问题（Transaction ID wraparound）而导致的宕机，将小于OldestXmin的事务号转化为freeze xid，更新表的relfrozenxid，更新库的relfrozenxid，truncate clog； 3）更新统计信息：VACUUM Analyze时，会更新统计信息，使得优化器能够选择更好的方案执行sql。VACUUM 命令存在两种形式，VACUUM和VACUUM FULL，VACUUM命令做的是LAZY VACUUM。从字面意思就可以看出来，LAZY VACUUM是VACUUM FULL的简化版。

PCK的本质就是通过排序提升查询过滤的效率，创建表时指定PCK列，该列上的数据会局部排序，有序的数据带来更好的数据聚簇性，每个数据块的min/max等稀疏索引就能更好的发挥作用，粗过滤掉大量的数据，提升IO效率，默认情况下420万行数据局部排序。 注意事项如下： 只有列存表支持PCK，局部排序对每次导入的批量数据生效，不会做全排序； PCK更适用于范围查询，点查场景下配套使用PCK和索引可以达到最佳效果； 带PCK导入因为排序的原因会使用更多的内存，影响导入速度，需要权衡导入和查询性能。举个例子，对于查询select * from tab where col > 65，如果不使用PCK，很可能一个CU都无法过滤掉，但如果使用了PCK，下图所示的5个CU就能过滤掉一半还多，提升查询性能至少50%PCK结合索引，可以将类似这种点查的性能提升100倍以上。