企业官网建设流程全解析

简介：《VASTDATA Vastbase G100 V2.2用户手册》面向数据库管理员、开发人员及信创项目技术选型人员，系统讲解基于openGauss开发的国产数据库Vastbase G100的使用方法。手册从数据库逻辑结构图、数据查询请求处理过程与管理事务等基础概念入手，逐步展开连接数据库（配置服务端远程连接、使用vsql连接、应用程序接口）、关闭数据库、创建和管理数据库、规划存储模型、列存数据压缩及表空间管理等实操内容，目录层级清晰，便于按模块查阅。资源包共1个PDF文件，约8.76MB，内容完整、结构分明，适合作为日常操作参考与入门学习材料。目前已有198人学习，读者可借此快速建立对Vastbase G100整体架构的认知，掌握从连接到建库建表的完整流程，并了解信创数据库在信息安全与数据主权方面的设计取向。

1. 信创数据库落地第一课：这份 Vastbase G100 V2.2 手册到底能帮你解决什么

上周有个做政务系统迁移的朋友半夜发消息，说甲方要求把一套跑了七八年的业务库切到国产数据库上，选型定了 Vastbase G100，结果团队里没人碰过这套东西，连怎么连上去都摸不着门路。这种场景在信创数据库替换里太常见了——产品选型拍板很快，真正落到开发和管理员手里，缺的是一份能照着敲命令、能查到参数、能解释报错的手册。这份 Vastbase G100 V2.2 用户手册就是干这个的：它基于 openGauss 内核体系，把从连接数据库、建库建表、分区表设计、列存压缩，到 JDBC/ODBC/libpq 三种应用开发接口、客户端认证、SSL 证书、三权分立权限模型这一整条链路都铺开了。适合两类人：一是正在做信创数据库迁移、需要快速把业务跑通的开发和 DBA；二是要评估这套库能不能扛住现有业务的技术负责人。手册不是营销材料，是操作底稿，下面我按实际落地顺序把它拆开讲。

2. 从连上到建表：把手册里的操作链路跑通

拿到一份几百页的数据库手册，最容易犯的错是从第一页开始顺序读，读到第三章连接数据库的时候已经忘了第二章讲的逻辑结构。我的习惯是先锁定一条最小可用链路：连上库、建库、建表、插数据、查出来，这条链路跑通了，再回头补事务模型、存储模型这些理论。Vastbase G100 的手册结构恰好支持这种读法，第 3 章「数据库使用」基本就是一条从连接到建表的完整路径。

2.1 连接数据库的三条路：vsql、JDBC、ODBC 怎么选

手册 3.2 节把连接方式分成服务端远程连接配置、vsql 命令行连接、应用程序接口三类。选型逻辑其实很直接：vsql 是运维和排障用的，类似其他数据库的 CLI 客户端，适合快速验证、跑 DDL、看执行计划；JDBC 是 Java 业务系统的标准入口，手册 4.2 节专门讲了驱动版本与 JDK 的兼容性对照；ODBC 则面向 C/C++ 或者一些老系统的数据源接入，4.3 节从安装 unixODBC 到配置数据源、替换客户端驱动、测试数据源一路写下来。libpq 是更底层的 C 接口，4.4 节有涉及，一般业务开发用不到，但做深度定制或者写中间件的时候绕不开。

远程连接第一步不是敲 vsql，而是改服务端的监听配置。手册 3.2.1 节点明了要配置服务端远程连接，实际落地时对应的是监听地址和认证配置文件两处，改完必须重启或者 reload 才生效。这一步翻车率极高，后面避坑章节会细说。

vsql 连接的基本形态是这样：

# 以数据库管理员身份连接本地实例，-d 指定库名，-p 指定端口 vsql -d postgres -p 5432 -U vastbase -W # 远程连接时显式指定主机，-h 后跟服务端地址 vsql -h 192.168.10.21 -p 5432 -d business_db -U app_user -W

-W表示强制交互式输入密码，避免密码出现在命令历史里；-h不写默认走本地 socket。这里有个容易忽略的点：手册里连接参数那一节列了 host、port、dbname、user 之外还有连接超时和字符集相关参数，字符集不一致会导致中文乱码，建库时如果没指定编码，后面插数据才发现就得多走一轮导出导入。

JDBC 侧的关键是驱动加载和连接串。手册 4.2.5 节给了导入、加载驱动、连接数据库的完整顺序，连接串里除了常规的地址端口库名，还要注意是否开启 SSL——如果服务端强制了 SSL 而客户端没配，报错信息往往指向认证失败而不是 SSL 握手失败，很容易误判成密码错了。

// 加载 Vastbase JDBC 驱动，类名与 openGauss 体系保持一致 Class.forName("org.opengauss.Driver"); // 连接串：关闭 SSL 时显式写 ssl=false，避免服务端强制 SSL 时握手失败 String url = "jdbc:opengauss://192.168.10.21:5432/business_db?ssl=false"; Connection conn = DriverManager.getConnection(url, "app_user", "******");

驱动类名和 URL 前缀是这套库从 openGauss 继承下来的，别按其他商业库的习惯去猜。连接池部分手册 4.2.9 节有提，但没展开具体池化框架的配置，实际项目里用 HikariCP 或者 Druid 都行，注意把连接校验语句设成这套库支持的语法，否则池子里的空闲连接被服务端断开后取出来就是坏的。

2.2 建库建表与存储模型：行存、列存、分区表怎么定

连上之后第一件事是建库。手册 3.4 节讲创建和管理数据库，3.7 节讲表空间，这两步的顺序有讲究：生产环境一般先规划表空间，把数据文件、索引、临时数据分开放，再建库时指定默认表空间。表空间对应的是操作系统目录，建之前目录必须存在且属主正确，否则建表空间直接失败。

存储模型的选择是这套库比较有特色的地方。手册 3.5 节「规划存储模型」和 3.6 节「列存下的数据压缩」放在一起看就明白了：行存适合 OLTP 那种按行读写、频繁更新的场景；列存适合宽表分析、大批量扫描聚合，配合压缩能显著降低存储占用。选错的代价不小——把一张天天按主键更新的订单表建成列存，更新性能会难看到让你怀疑人生。

-- 行存表：面向事务，适合高频点查和更新 CREATE TABLE orders ( order_id BIGINT PRIMARY KEY, customer_id BIGINT NOT NULL, amount NUMERIC(12,2), created_at TIMESTAMP DEFAULT now() ); -- 列存表：面向分析，适合大范围扫描和聚合，可指定压缩级别 CREATE TABLE order_analysis ( order_id BIGINT, customer_id BIGINT, region_code VARCHAR(16), amount NUMERIC(12,2) ) WITH (ORIENTATION = COLUMN, COMPRESSION = HIGH);

ORIENTATION = COLUMN是列存的开关，COMPRESSION控制压缩级别，手册 3.6 节有说明不同级别对 CPU 和存储的权衡，HIGH 省空间但写入和查询的 CPU 开销更高，冷数据归档场景可以拉满，热数据建议用默认或者 LOW。分区表在 3.8.8 节，支持 default 分区这个特性值得单独提——业务上经常出现分区键值超出预期范围导致插入失败，有了 default 分区至少数据不会丢，事后可以再 split 出来。

建表之后是索引、视图、序列、约束这一套，手册 3.11 节按对象类型逐个展开。约束部分 3.11.5 节把检查约束、非空、唯一、主键、外键分开讲，还专门有一小节讲约束的启用禁用——批量导入数据前临时禁用约束、导完再启用，是提速的常规手段，但禁用期间的数据质量得自己兜底。

2.3 事务与查询处理：理解请求怎么走完整个链路

手册第 2 章「概述」里那几张图别跳过。2.1 节数据库逻辑结构图讲的是库、schema、表、表空间之间的层级关系，2.2 节数据查询请求处理过程讲的是客户端请求进来之后经过解析、优化、执行几个阶段，2.3 节管理事务讲事务的提交回滚和隔离。这些内容看着像理论，实际排障时全靠它定位问题在哪一层。

举个实际场景：一条查询突然变慢，你得先判断是解析慢、优化器选错计划、还是执行阶段 IO 打满。手册 2.2 节的流程告诉你优化器在哪个环节介入，配合执行计划就能判断是不是统计信息过期导致走了错误的连接方式。事务部分则关系到锁等待——长事务不提交会阻塞 DDL，这个坑在任何关系库上都存在，但这套库的锁视图和等待事件名称跟其他产品不一样，得对着系统表那一节（3.9 节）去查。

schema 的管理在 3.11.1 节，多租户或者按业务模块隔离的场景，用 schema 做逻辑隔离比建多个库更轻量，权限也好管。序列在 3.11.4 节，自增主键依赖序列，注意序列的缓存值设置——缓存大了重启会跳号，业务对连续性有要求的话得把 cache 调小。

3. 应用开发接口落地：JDBC、ODBC、libpq 的实操细节

业务系统不可能只用命令行，最终都要落到应用代码里。手册第 4 章「应用程序开发教程」是整份文档里最贴近开发日常的部分，从开发规范到三种接口的完整示例都有。这一章的价值在于它给了可运行的代码骨架，而不是只列 API 签名。

3.1 JDBC 开发：从驱动版本到结果集处理

手册 4.2.1 和 4.2.2 节先讲驱动版本和 JDK 兼容性，这一步选错后面全是白费功夫。驱动版本要和数据库服务端版本匹配，JDK 版本又限制了能用哪个驱动版本，三者对不上时的报错往往很隐晦，比如类找不到或者方法不存在。我的做法是先确认服务端版本，再倒推驱动版本，最后核对项目 JDK。

设置类路径（4.2.4.1 节）是把驱动 jar 放进 classpath，Maven 项目直接引依赖即可，但要注意别同时引了多个来源的驱动包导致类冲突。连接数据库之后，执行 SQL 和处理结果分查询和更新两条线：查询用 Statement 或 PreparedStatement 拿 ResultSet，手册 4.2.6.2 节专门讲了用游标获取结果——大数据量查询时一次性把结果全拉到内存会 OOM，游标是分批取的标准做法。

// 游标方式分批取结果，避免大结果集撑爆内存 conn.setAutoCommit(false); Statement stmt = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY); stmt.setFetchSize(1000); // 每批取 1000 行 ResultSet rs = stmt.executeQuery("SELECT order_id, amount FROM orders WHERE created_at > '2024-01-01'"); while (rs.next()) { // 逐行处理，内存占用与 fetchSize 挂钩而非结果集总大小 } conn.commit();

setFetchSize是游标生效的关键，不设或者设成 0 会退化成一次性拉取。另外自动提交必须关掉，否则游标在部分驱动实现下不生效。存储过程调用在 4.2.7 节，获取结果集的方式和普通查询不同，得用 CallableStatement 注册输出参数。大数据类型处理在 4.2.8 节，二进制用 bytea 对应，字符串大字段有单独的流式读写方式，别用普通 getString 去读一个几百 MB 的字段。

3.2 ODBC 与 libpq：老系统接入和底层定制

ODBC 的落地步骤比 JDBC 繁琐，手册 4.3.2 节把它拆成安装数据库客户端、安装 unixODBC、替换客户端驱动、配置数据源、配环境变量、测试数据源六步。顺序不能乱：unixODBC 先装好，驱动文件放对位置，odbc.ini 和 odbcinst.ini 两个配置文件都要写对，环境变量里 ODBCINI 和 LD_LIBRARY_PATH 少一个都连不上。测试数据源那一步用 isql 跑一条select 1，通了再往应用里接。

# 配置完数据源后用 isql 验证，-v 打开详细输出便于排错 isql -v vastbase_dsn app_user password # 环境变量示例，写进 profile 或服务启动脚本 export ODBCINI=/etc/odbc.ini export LD_LIBRARY_PATH=/opt/vastbase/odbc/lib:$LD_LIBRARY_PATH

libpq 在 4.5 节，是 C 语言层面的接口，连接参数通过连接字符串或者 PGconn 结构体传。做中间件、代理层或者需要精细控制连接行为的场景才用得上，普通业务开发用 JDBC/ODBC 就够了。调试部分手册 4.5 节（原文编号如此）给了日志和断点相关的建议，实际排障时打开驱动日志往往比猜快得多。

4. 安全与权限：客户端认证、SSL、三权分立怎么配

信创场景对安全的要求通常比普通项目高一档，手册第 5 章「管理数据库安全」基本是围绕这个展开的。这一章内容密度大，我挑三个落地时绕不开的点讲：客户端接入认证、SSL 加密连接、用户权限模型。

4.1 客户端认证配置：pg_hba 风格的规则怎么写

手册 5.1.1 节配置客户端接入认证，5.1.2 节是配置文件参考。这套库的客户端认证沿用 openGauss 体系的 hba 配置思路：按「连接类型、数据库、用户、来源地址、认证方法」五元组写规则，从上往下匹配，命中第一条就生效。最常见的翻车是规则顺序写反——先写了一条宽泛的 trust 或者 md5 规则，后面精细的规则永远匹配不到。

# 认证配置片段示例：允许应用网段用密码认证，本机管理用 trust # 格式：连接类型 数据库 用户 来源地址 认证方法 host business_db app_user 192.168.10.0/24 sha256 host all all 127.0.0.1/32 trust

sha256是密码认证方法，比 md5 更稳；来源地址支持 CIDR 写法。改完配置要 reload 服务端，不 reload 不生效，而且写错语法可能导致服务起不来，改之前先备份原文件是血泪经验。5.1.5 节查看数据库连接数，配合连接数上限参数，能快速判断是不是连接池泄漏把连接占满了。

4.2 SSL 证书与加密连接：生成、配置、验证三步

手册 5.1.3 节讲 SSL 证书管理，5.1.4 节讲用 SSL 进行安全的 TCP/IP 连接。落地顺序是：先生成服务端和客户端证书，服务端配置里打开 SSL 并指定证书路径，客户端连接时带上 SSL 参数。证书生成那一步有自签和 CA 签发两种，测试环境自签够用，生产环境建议走内部 CA。

# 生成服务端私钥和自签证书（测试环境示例，生产建议走 CA 签发） openssl req -new -x509 -days 3650 -nodes -text \ -out server.crt -keyout server.key \ -subj "/CN=vastbase-server" # 权限收紧，私钥权限过宽服务端会拒绝加载 chmod 600 server.key

私钥权限是高频坑点，权限不对服务端启动时直接报错退出，日志里会明确提示权限问题。客户端连接时如果服务端要求 SSL 而客户端没开，报错可能表现为连接被重置而不是明确的 SSL 错误，得对着服务端日志看。5.1.4 节给了 SSL 连接串的写法，JDBC 侧对应ssl=true加证书路径参数。

4.3 用户权限与三权分立：角色、schema、行级控制

手册 5.2 节从默认权限机制讲到管理员、三权分立、用户、角色、schema、权限设置、行级访问控制、安全策略。三权分立（5.2.3 节）是这套库在安全合规上的一个卖点：把管理权限拆成系统管理员、安全管理员、审计管理员，互相制约，满足等保和信创审计要求。落地时要注意，开了三权分立之后，原来一个超级用户能干的事现在要分角色操作，迁移脚本里如果有越权操作会直接失败。

行级访问控制（5.2.8 节）适合多租户场景，同一张表不同用户只能看到自己租户的行，靠策略表达式实现。安全策略（5.2.9 节）里账户安全策略涉及密码复杂度、登录失败锁定、密码有效期这些，生产环境基本都要配，配之前先确认业务系统能不能处理密码过期强制改密的流程，否则半夜批量任务全挂。

5. 避坑与排查：五条踩过的坑和对应解法

手册再全，也覆盖不到现场环境的千奇百怪。下面五条是我在实际迁移里反复遇到的，按「现象 → 原因 → 解决」写，照着排查能省不少时间。

坑一：远程连不上，报连接被拒绝。现象是 vsql 从另一台机器连过来直接 connection refused。原因通常是服务端监听地址只绑了 localhost，或者防火墙没放行端口。解决：查服务端监听配置改成对外地址，确认端口监听状态，再核对防火墙规则，改完 reload 服务端。

坑二：认证规则改了不生效。现象是 hba 配置里明明加了规则，连接还是走老的认证方式。原因一是没 reload，原因二是规则顺序问题——宽泛规则写在前面把后面的精细规则挡住了。解决：先 reload，再按「越精细越靠前」重排规则，用不同来源地址实测验证。

坑三：列存表更新性能断崖式下跌。现象是同一张表行存时更新毫秒级，改成列存后更新要几秒甚至超时。原因是列存面向批量扫描设计，单行更新要重写列块，代价极高。解决：把高频更新的表改回行存，分析类查询走列存宽表或者物化视图，别指望一种存储模型通吃。

坑四：JDBC 大结果集 OOM。现象是查询几百万行的报表任务跑着跑着堆内存爆了。原因是没开游标，驱动一次性把结果集全拉进内存。解决：关自动提交、设 fetchSize、用只进只读的结果集类型，分批处理。顺带检查连接池的最大连接数和 fetchSize 的乘积，别让单连接的内存放大到整个池子。

坑五：SSL 开了之后应用连不上。现象是服务端开了 SSL，应用侧报认证失败或者连接重置。原因多半是客户端没配 SSL 参数，或者证书路径、信任链不对。解决：客户端连接串显式开 SSL 并指定证书，先用 vsql 带 SSL 参数验证通，再改应用配置；证书过期也要查，自签证书设了有效期，到期前记得轮换。

6. 进阶用法：用系统表和参数配置把问题定位到根上

手册 3.9 节「查看系统表」和 3.10 节「配置数据库参数」这两节，新手容易一扫而过，熟手却会反复翻。原因很简单：出问题时日志只能告诉你现象，真正定位到根上得靠系统表和运行时参数。这套库的系统表体系继承自 openGauss，表名和字段跟其他商业库不一样，记不住没关系，关键是知道去哪查。

排查连接问题先看连接相关的系统视图，能拿到当前所有会话的来源地址、状态、执行的 SQL、等待事件。一条慢查询卡住，先看它在等什么——等锁、等 IO、还是等客户端发数据。锁等待就顺着锁视图找到阻塞源会话，必要时终止它。参数配置方面，手册 3.10 节列了常用参数的修改方式和生效范围，有的参数改完立即生效，有的要重启，改之前先确认生效级别，生产环境重启的代价不用多说。

-- 查看当前活跃会话及其等待状态，定位阻塞源 SELECT pid, usename, client_addr, state, wait_event_type, wait_event, query FROM pg_stat_activity WHERE state <> 'idle' ORDER BY query_start; -- 查看表的大小和膨胀情况，判断是否需要清理 SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) AS total_size FROM pg_stat_user_tables ORDER BY pg_total_relation_size(relid) DESC LIMIT 10;

这两条查询是我每次接手一个新实例必跑的：第一条看有没有长事务和异常等待，第二条看表和索引的体量分布，顺便判断统计信息是否该更新了。参数侧重点关注连接数上限、共享缓冲区、工作内存这几个，工作内存设太小会让排序和哈希操作落盘，执行计划里出现磁盘溢出的节点就是信号。

还有一个容易被忽略的技巧：手册里每个功能点后面往往跟着「其他操作」或者「相关概念」的小节，这些小节里藏着边界条件。比如分区表支持 default 分区那一小节，正文只说了支持，但实际用的时候得知道 default 分区不能随便再分区、split 的时候有约束。我现在的习惯是，任何要上生产的特性，先把手册对应小节连同它后面的注意事项读两遍，再在测试环境跑一遍异常路径——正常路径谁都能跑通，异常路径才是决定能不能上生产的关键。从那以后我每次做数据库迁移，都强制自己把避坑清单过一遍再动手，希望帮到你。

本文还有配套的精品资源，点击获取