当全网都在用Macmini养虾时，我却用它干了件“疯狂”的大事！深度测试海量数据库Vastbase G100
当全网都在用Macmini养虾时，我却用它干了件“疯狂”的大事！深度测试海量数据库Vastbase G100
用户4035096
发布于 2026-07-10 08:46:10
发布于 2026-07-10 08:46:10
最近openClaw火爆全网，连我桌上的Macmini都差点沦为“养虾专业户”。但今天，我偏要拿它来“不务正业”一回 —— 硬扛一款企业级国产数据库Vastbase G100！
就在所有人质疑“ARM芯片跑企业库行不行”时，我搞到了它的3.0.8 PSU4鲲鹏版镜像，决定在M2芯片上给它来一场“极限施压”。
结果 …… 第一个命令就踩坑，文档居然“翻车”了？性能测试更是惊现“心电图”式抖动，直接让我怀疑人生！
这到底是“神坑”还是“真香”？国产数据库在苹果芯片上，究竟能爆发出多少战力？
我把整个“蹂躏”过程，包括5大核心模块的血泪测试和最后发现的“国密”黑科技，全都整理在了下面👇 是惊喜还是惊吓，你自己来看！
Vastbase G100 可能很多人不知道是啥, 简单介绍一下. 它是海量的一款企业级关系型数据库，旨在提供强竞争力的事务型、集中式高可用数据库。
- 支持 SQL2003 标准语法。
- 对Oracle、MySQL、Postgres、SQL Server 做了大量的兼容性支持，同时，提供高效的异构数据库迁移工具exBase，实现应用平滑迁移。
- 多种存储模式支持复合业务场景，新引入提供原地更新存储引擎。
- Paxos一致性日志复制协议，主备模式，CRC校验支持高可用。
- NUMA-AWARE、日志无锁并行写入、线程池、CSN事务快照技术合力构筑高性能。
- 支持全密态计算、账本数据库等安全特性，提供全方位端到端的数据安全保护。
- 支持向量数据存储和检索，通过特征提取和向量化技术将文本、图像、音频等不同类型的非结构化数据转换为向量并存储在Vastbase G100中，为AI应用提供了向量运算支持。
现在国产数据库的文档确实越来越好了, 我在测试过程中, 完全独立完成, 没有和厂家有任何交流.
下面的测试包含了五个模块(镜像加载、性能、列存储对比行存储、in-place 原地更新存储引擎、国密功能), 我也会备注用到的手册URL. 有兴趣的小伙伴可以和我一起跑一跑看看.
1、加载镜像
https://docs.vastdata.com.cn/zh_CN/VastbaseG100/V3.0.9/1/be9d6c2eac154b92a0efaef9e8c6d88a
docker load -i vastbase-g100-single-v1.4-3.0.8.29407-linux-kunpeng920-20260119165657.tar
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
vastbase-g100-single-v1.4-3.0.8.29407-linux-kunpeng920 20260119165657 72f431ca8842 7 weeks ago 4.44GB
踩到的第一个坑:
文档有一处小错误, 也可能是 macOS 中不需要这么做? 反正一旦修改了owner, 会导致权限错误, 容器无法启动
容器中运行数据库的用户为 vastbase 且 uid:gid 为 1000:1000，为保证容器中有权限访问被挂载的目录，宿主机中需要将被挂载的目录和文件的属性 uid:gid 修改为 1000:1000。
mkdir -p ~/vastbase/license
mkdir -p ~/vastbase/data
mkdir -p ~/vastbase/backup
mkdir -p ~/vastbase/backup_log
# 所以不需要执行这一步
# sudo chown -R 1000:1000 ~/vastbase
# 下面的所有变量, 请从手册了解具体含义
LICENSE_VDIR=$(cd ~/vastbase/license; pwd)
DATA_VDIR=$(cd ~/vastbase/data; pwd)
BACKUP_VDIR=$(cd ~/vastbase/backup; pwd)
BACKUP_LOG_VDIR=$(cd ~/vastbase/backup_log; pwd)
VB_USERNAME="postgres"
VB_PASSWORD="Vbase@123"
VB_DBCOMPATIBILITY="PG"
docker run -d --privileged=true \
-v ${LICENSE_VDIR}:/home/vastbase/vastbase/lic \
-v ${DATA_VDIR}:/home/vastbase/data \
-v ${BACKUP_VDIR}:/home/vastbase/backup \
-v ${BACKUP_LOG_VDIR}:/home/vastbase/backup_log \
-e VB_USERNAME=${VB_USERNAME} \
-e VB_PASSWORD=${VB_PASSWORD} \
-e VB_DBCOMPATIBILITY=${VB_DBCOMPATIBILITY} \
--name g100 -p 25432:5432 \
vastbase-g100-single-v1.4-3.0.8.29407-linux-kunpeng920:20260119165657
就这样就可以正常进入数据库了
digoaldeMac-mini-2:vastbase digoal$ docker exec -ti g100 bash
[vastbase@15915f435e87 ~]$ psql
psql ((Vastbase G100 V3.0 (Build 8) Release) compiled at 2025-12-07 20:42:33 commit 29407 last mr )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.
vastbase=#
但我有洁癖, 所以先看看日志有没有什么告警或异常, 还真发现了一些warning, 虽然前面说了, 数据库能正常连, 不过我看不得一点点warning.
digoaldeMac-mini-2:vastbase digoal$ docker logs g100
Single instance mode.
directory successfully created: /tmp/corefile
directory successfully created: /home/vastbase/data/nmon
directory successfully created: /home/vastbase/data/archive
directory successfully created: /home/vastbase/data/pg_log
directory successfully created: /home/vastbase/data/vastbase_log
directory successfully created: /home/vastbase/data/vastbase
directory successfully created: /home/vastbase/data/vastbase_log/bin
directory successfully created: /home/vastbase/backup/probackup
directory successfully created: /home/vastbase/backup_log/probackup
directory successfully created: /home/vastbase/backup/dumpall
directory successfully created: /home/vastbase/backup_log/dumpall
Reinitialize the database!
Message: The supplied VB_PASSWORD is meet requirements.
Specify database compatibility as: PG
The files belonging to this database system will be owned by user "vastbase".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.UTF-8".
The default text search configuration will be set to "english".
fixing permissions on existing directory /home/vastbase/data/vastbase ... ok
creating subdirectories ... in ordinary occasionok
creating configuration files ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 1024MB
Begin init undo subsystem meta.
[INIT UNDO] Init undo subsystem meta successfully.
creating template1 database in /home/vastbase/data/vastbase/base/1 ... setting _JAVA_SR_SIGNUM=14 success.
2026-03-11 03:00:16.623 [unknown] [unknown] localhost 281472625844240 0[0:0#0] [BACKEND] WARNING: macAddr is 13952/1551680356, sysidentifier is 914381948/3278127743, randomNum is 636437119
ok
initializing pg_authid ... ok
setting password ...
system admin[vbadmin] initial password: F_0590e3
security admin[vbsso] initial password: X3b6d!b5
audit admin[vbaudit] initial password: D29e5e)4
Please change your initial password immediately after your first successful login.
ok
initializing vb_user_profiles ... ok
initializing dependencies ... ok
loading PL/pgSQL server-side language ... ok
creating system views ... ok
creating performance views ... ok
loading system objects' descriptions ... ok
creating postgresql object ... ok
creating collations ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
initialize global configure for bucketmap length ... ok
creating information schema ... ok
loading security plugin ... ok
update system tables ... ok
creating snapshots catalog ... ok
vacuuming database template1 ... ok
cleaning temporary schema ... ok
copying template1 to template0 ... ok
copying template1 to vastbase ... ok
copying template1 to postgres ... ok
freezing database template0 ... ok
freezing database template1 ... ok
freezing database postgres ... ok
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run gs_initdb.
Success. You can now start the database server of single node using:
vastbase -D /home/vastbase/data/vastbase
or
vb_ctl start -D /home/vastbase/data/vastbase -Z single_node -l logfile
Default way to set parameters!
Database starts in background mode.
[2026-03-11 03:00:23.652][110][][gs_ctl]: gs_ctl started,datadir is /home/vastbase/data/vastbase
[2026-03-11 03:00:23.705][110][][gs_ctl]: waiting for server to start...
.setting _JAVA_SR_SIGNUM=14 success.
0 LOG: [Alarm Module]can not read GAUSS_WARNING_TYPE env.
0 LOG: [Alarm Module]Host Name: 15915f435e87
0 LOG: [Alarm Module]Host IP: 15915f435e87. Copy hostname directly in case of taking 10s to use 'gethostbyname' when /etc/hosts does not contain <HOST IP>
0 LOG: [Alarm Module]Get ENV GS_CLUSTER_NAME failed!
0 LOG: [Alarm Module]Invalid data in AlarmItem file! Read alarm English name failed! line: 57
0 WARNING: failed to open feature control file, please check whether it exists: FileName=gaussdb.version, Errno=2, Errmessage=No such file or directory.
0 WARNING: failed to parse feature control file: gaussdb.version.
0 WARNING: Failed to load the product control file, so gaussdb cannot distinguish product version.
0 [BACKEND] LOG: the config file /home/vastbase/data/vastbase/postgresql.conf verify start.
2026-03-11 03:00:23.816 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: the config file /home/vastbase/data/vastbase/postgresql.conf verify success.
0 LOG: License info: Customer:'temporary license', Begins On:'2026-03-11 03:00:23', Expires On:'2026-06-09 03:00:23', MAC:'', Model:'G100', Support Module:'BASIC, VECTOR'
2026-03-11 03:00:23.817 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: when starting as multi_standby mode, we couldn't support data replicaton.
2026-03-11 03:00:23.817 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: base_page_saved_interval is 400, ori is 400.
gaussdb.state does not exist, and skipt setting since it is optional.2026-03-11 03:00:23.826 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]can not read GAUSS_WARNING_TYPE env.
2026-03-11 03:00:23.826 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Host Name: 15915f435e87
2026-03-11 03:00:23.826 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Host IP: 15915f435e87. Copy hostname directly in case of taking 10s to use 'gethostbyname' when /etc/hosts does not contain <HOST IP>
2026-03-11 03:00:23.826 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Get ENV GS_CLUSTER_NAME failed!
2026-03-11 03:00:23.826 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Invalid data in AlarmItem file! Read alarm English name failed! line: 57
2026-03-11 03:00:23.841 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: Create JVM with option：-Djava.class.path=/home/vastbase/vastbase/lib/postgresql, -Xmx512m, -Xms256m, -XX:PermSize=16m, -XX:MaxPermSize=64m, --Xss256k, -Xrs, -server, -XX:+UseG1GC, -Djava.ext.dirs=/home/vastbase/vastbase/lib/postgresql
2026-03-11 03:00:23.895 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: loaded library "jdbc_fdw"
2026-03-11 03:00:23.896 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: loaded library "pg_stat_statements"
2026-03-11 03:00:23.897 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] WARNING: could not create any HA TCP/IP sockets
2026-03-11 03:00:23.897 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] WARNING: could not create any HA TCP/IP sockets
2026-03-11 03:00:23.898 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: reset_shared: base (nil)
2026-03-11 03:00:23.899 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: InitNuma numaNodeNum: 1 numa_distribute_mode: none inheritThreadPool: 0.
2026-03-11 03:00:23.899 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: reserved memory for backend threads is: 220 MB
2026-03-11 03:00:23.899 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: reserved memory for WAL buffers is: 128 MB
2026-03-11 03:00:23.899 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: Set max backend reserve memory is: 348 MB, max dynamic memory is: 8015 MB
2026-03-11 03:00:23.899 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: shared memory 3412 Mbytes, memory context 8363 Mbytes, max process memory 12288 Mbytes
2026-03-11 03:00:23.924 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [CACHE] LOG: set data cache size(402653184)
2026-03-11 03:00:23.940 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [SEGMENT_PAGE] LOG: Segment-page constants: DF_MAP_SIZE: 8156, DF_MAP_BIT_CNT: 65248, DF_MAP_GROUP_EXTENTS: 4175872, IPBLOCK_SIZE: 8168, EXTENTS_PER_IPBLOCK: 1021, IPBLOCK_GROUP_SIZE: 4090, BMT_HEADER_LEVEL0_TOTAL_PAGES: 8323072, BktMapEntryNumberPerBlock: 2038, BktMapBlockNumber: 25, BktBitMaxMapCnt: 512
2026-03-11 03:00:23.947 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: reset_shared: base 0xfffe6bde7000
2026-03-11 03:00:23.947 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: vastbase: fsync file "/home/vastbase/data/vastbase/gaussdb.state.temp" success
2026-03-11 03:00:23.947 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: create gaussdb state file success: db state(STARTING_STATE), server mode(Normal), connection index(1)
2026-03-11 03:00:24.013 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: max_safe_fds = 971, usable_fds = 1000, already_open = 19
2026-03-11 03:00:24.014 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: user configure file is not found, it will be created.
2026-03-11 03:00:24.048 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: the configure file /home/vastbase/vastbase/etc/gscgroup_vastbase.cfg doesn't exist or the size of configure file has changed. Please create it by root user!
2026-03-11 03:00:24.048 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [BACKEND] LOG: Failed to parse cgroup config file.
2026-03-11 03:00:24.052 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] WARNING: Failed to obtain environment value $GAUSSLOG!
2026-03-11 03:00:24.052 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] DETAIL: N/A
2026-03-11 03:00:24.052 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] CAUSE: Incorrect environment value.
2026-03-11 03:00:24.052 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] ACTION: Please refer to backend log for more details.
2026-03-11 03:00:24.053 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] WARNING: Failed to obtain environment value $GAUSSLOG!
2026-03-11 03:00:24.053 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] DETAIL: N/A
2026-03-11 03:00:24.053 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] CAUSE: Incorrect environment value.
2026-03-11 03:00:24.053 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] ACTION: Please refer to backend log for more details.
2026-03-11 03:00:24.054 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] WARNING: Failed to obtain environment value $GAUSSLOG!
2026-03-11 03:00:24.054 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] DETAIL: N/A
2026-03-11 03:00:24.054 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] CAUSE: Incorrect environment value.
2026-03-11 03:00:24.054 [unknown] [unknown] localhost 281472574341136 0[0:0#0] 0 [EXECUTOR] ACTION: Please refer to backend log for more details.
[2026-03-11 03:00:24.713][110][][gs_ctl]: done
[2026-03-11 03:00:24.713][110][][gs_ctl]: server started (/home/vastbase/data/vastbase)
Database starts in background mode successfully.
VB_DB = vastbase
Execute SQL: gsql -v ON_ERROR_STOP=1 --username vastbase --password Vbase@123 --dbname postgres --set db=vastbase --set passwd=Vbase@123 --set user=postgres --set privilege=login
CREATE ROLE
default no repuser created
/home/vastbase/scripts/entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
[2026-03-11 03:00:24.756][200][][gs_ctl]: gs_ctl stopped ,datadir is /home/vastbase/data/vastbase
waiting for server to shut down..... done
server stopped
No need to set k8s entry for connections.
vastbase init process complete; ready for start up.
Start generating encryption key file.
The vb_guc run with the following arguments: [gs_guc -S ******** -D /home/vastbase/vastbase/bin -o usermapping generate ].
gs_guc encrypt -S ***
The vb_guc run with the following arguments: [gs_guc -S ******** -D /home/vastbase/vastbase/bin -o server generate ].
gs_guc encrypt -S ***
The vb_guc run with the following arguments: [gs_guc -S ******** -D /home/vastbase/vastbase/bin -o obsserver generate ].
gs_guc encrypt -S ***
End generating encryption key file.
Start the database in foreground mode.
Start cmd: vastbase
setting _JAVA_SR_SIGNUM=14 success.
0 LOG: [Alarm Module]can not read GAUSS_WARNING_TYPE env.
0 LOG: [Alarm Module]Host Name: 15915f435e87
0 LOG: [Alarm Module]Host IP: 15915f435e87. Copy hostname directly incase of taking 10s to use 'gethostbyname' when /etc/hosts does not contain <HOST IP>
0 LOG: [Alarm Module]Get ENV GS_CLUSTER_NAME failed!
0 LOG: [Alarm Module]Invalid data in AlarmItem file! Read alarm English name failed! line: 57
0 WARNING: failed to open feature control file, please check whether it exists: FileName=gaussdb.version, Errno=2, Errmessage=No such file or directory.
0 WARNING: failed to parse feature control file: gaussdb.version.
0 WARNING: Failed to load the product control file, so gaussdb cannot distinguish product version.
0 [BACKEND] LOG: the config file /home/vastbase/data/vastbase/postgresql.conf verify start.
2026-03-11 03:00:26.924 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: the config file /home/vastbase/data/vastbase/postgresql.conf verify success.
0 LOG: License info: Customer:'temporary license', Begins On:'2026-03-11 03:00:23', Expires On:'2026-06-09 03:00:23', MAC:'', Model:'G100', Support Module:'BASIC, VECTOR'
2026-03-11 03:00:26.925 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: when starting as multi_standby mode, we couldn't support data replicaton.
2026-03-11 03:00:26.925 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: base_page_saved_interval is 400, ori is 400.
2026-03-11 03:00:26.933 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]can not read GAUSS_WARNING_TYPE env.
2026-03-11 03:00:26.933 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Host Name: 15915f435e87
2026-03-11 03:00:26.933 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Host IP: 15915f435e87. Copy hostname directly in case of taking 10s to use 'gethostbyname' when /etc/hosts does not contain <HOST IP>
2026-03-11 03:00:26.933 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Get ENV GS_CLUSTER_NAME failed!
2026-03-11 03:00:26.933 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: [Alarm Module]Invalid data in AlarmItem file! Read alarm English name failed! line: 57
2026-03-11 03:00:26.937 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: Create JVM with option：-Djava.class.path=/home/vastbase/vastbase/lib/postgresql, -Xmx512m, -Xms256m, -XX:PermSize=16m, -XX:MaxPermSize=64m, --Xss256k, -Xrs, -server, -XX:+UseG1GC, -Djava.ext.dirs=/home/vastbase/vastbase/lib/postgresql
2026-03-11 03:00:26.960 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: loaded library "jdbc_fdw"
2026-03-11 03:00:26.960 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: loaded library "pg_stat_statements"
2026-03-11 03:00:26.961 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] WARNING: could not create any HA TCP/IP sockets
2026-03-11 03:00:26.961 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] WARNING: could not create any HA TCP/IP sockets
2026-03-11 03:00:26.962 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: reset_shared: base (nil)
2026-03-11 03:00:26.962 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: InitNuma numaNodeNum: 1 numa_distribute_mode: none inheritThreadPool: 0.
2026-03-11 03:00:26.962 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: reserved memory for backend threads is: 220 MB
2026-03-11 03:00:26.962 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: reserved memory for WAL buffers is: 128 MB
2026-03-11 03:00:26.962 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: Set max backend reserve memory is: 348 MB, max dynamic memory is: 8015 MB
2026-03-11 03:00:26.962 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: shared memory 3412 Mbytes, memory context 8363 Mbytes, max process memory 12288 Mbytes
2026-03-11 03:00:26.989 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [CACHE] LOG: set data cache size(402653184)
2026-03-11 03:00:27.005 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [SEGMENT_PAGE] LOG: Segment-page constants: DF_MAP_SIZE: 8156, DF_MAP_BIT_CNT: 65248, DF_MAP_GROUP_EXTENTS: 4175872, IPBLOCK_SIZE: 8168, EXTENTS_PER_IPBLOCK: 1021, IPBLOCK_GROUP_SIZE: 4090, BMT_HEADER_LEVEL0_TOTAL_PAGES: 8323072, BktMapEntryNumberPerBlock: 2038, BktMapBlockNumber: 25, BktBitMaxMapCnt: 512
2026-03-11 03:00:27.013 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: reset_shared: base 0xfffe6fbe7000
2026-03-11 03:00:27.013 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: vastbase: fsync file "/home/vastbase/data/vastbase/gaussdb.state.temp" success
2026-03-11 03:00:27.014 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: create gaussdb state file success: db state(STARTING_STATE), server mode(Normal), connection index(1)
2026-03-11 03:00:27.030 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: max_safe_fds = 972, usable_fds = 1000, already_open = 18
2026-03-11 03:00:27.031 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: the configure file /home/vastbase/vastbase/etc/gscgroup_vastbase.cfg doesn't exist or the size of configure file has changed. Please create it by root user!
2026-03-11 03:00:27.031 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [BACKEND] LOG: Failed to parse cgroup config file.
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] WARNING: Failed to obtain environment value $GAUSSLOG!
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] DETAIL: N/A
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] CAUSE: Incorrect environment value.
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] ACTION: Please refer to backend log for more details.
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] WARNING: Failed to obtain environment value $GAUSSLOG!
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] DETAIL: N/A
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] CAUSE: Incorrect environment value.
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] ACTION: Please refer to backend log for more details.
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] WARNING: Failed to obtain environment value $GAUSSLOG!
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] DETAIL: N/A
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] CAUSE: Incorrect environment value.
2026-03-11 03:00:27.034 [unknown] [unknown] localhost 281472646422544 0[0:0#0] 0 [EXECUTOR] ACTION: Please refer to backend log for more details.
从上面的日志可以发现似乎少了几个环境变量未设置, 于是搜索手册中的关键字, 通过手册了解到
alarm告警会按照环境变量GAUSS_WARNING_TYPE的配置进行输出：
1、输出到alarm_component指定的告警组件，由组件进行进一步处理和输出。
2、输出到操作系统 syslog。
于是我补齐下面这几个变量后, 重新创建了容器
GAUSSLOG
GAUSS_WARNING_TYPE
GS_CLUSTER_NAME
新增变量重新来一遍
docker stop g100
docker rm g100
rm -rf ~/vastbase
mkdir -p ~/vastbase/license
mkdir -p ~/vastbase/data
mkdir -p ~/vastbase/backup
mkdir -p ~/vastbase/backup_log
LICENSE_VDIR=$(cd ~/vastbase/license; pwd)
DATA_VDIR=$(cd ~/vastbase/data; pwd)
BACKUP_VDIR=$(cd ~/vastbase/backup; pwd)
BACKUP_LOG_VDIR=$(cd ~/vastbase/backup_log; pwd)
GAUSSLOG="/home/vastbase/data/vastbase_log"
VB_USERNAME="postgres"
VB_PASSWORD="Vbase@123"
VB_DBCOMPATIBILITY="PG"
GAUSS_WARNING_TYPE="2"
GS_CLUSTER_NAME="vastbase_test"
docker run -d --privileged=true \
-v ${LICENSE_VDIR}:/home/vastbase/vastbase/lic \
-v ${DATA_VDIR}:/home/vastbase/data \
-v ${BACKUP_VDIR}:/home/vastbase/backup \
-v ${BACKUP_LOG_VDIR}:/home/vastbase/backup_log \
-e VB_USERNAME=${VB_USERNAME} \
-e VB_PASSWORD=${VB_PASSWORD} \
-e VB_DBCOMPATIBILITY=${VB_DBCOMPATIBILITY} \
-e GAUSSLOG=${GAUSSLOG} \
-e GAUSS_WARNING_TYPE=${GAUSS_WARNING_TYPE} \
-e GS_CLUSTER_NAME=${GS_CLUSTER_NAME} \
--name g100 -p 25432:5432 \
vastbase-g100-single-v1.4-3.0.8.29407-linux-kunpeng920:20260119165657
最后这个WARNING日志还是像牛皮癣一样的存在
2026-03-11 03:24:51.691 [unknown] [unknown] localhost 281472702423056 0[0:0#0] 0 [EXECUTOR] CAUSE: Incorrect environment value.
2026-03-11 03:24:51.691 [unknown] [unknown] localhost 281472702423056 0[0:0#0] 0 [EXECUTOR] ACTION: Please refer to backend log for more details.
2026-03-11 03:24:51.691 [unknown] [unknown] localhost 281472702423056 0[0:0#0] 0 [EXECUTOR] WARNING: Failed to obtain environment value $GAUSSLOG!
虽然在容器中已有此环境变量
[vastbase@3f628a7168d3 ~]$ echo $GAUSSLOG
/home/vastbase/data/vastbase_log
[vastbase@3f628a7168d3 ~]$ ll -R /home/vastbase/data/vastbase_log
/home/vastbase/data/vastbase_log:
total 0
drwxr-xr-x 4 vastbase vastbase 128 Mar 11 03:24 bin
/home/vastbase/data/vastbase_log/bin:
total 0
drwx------ 4 vastbase vastbase 128 Mar 11 03:24 gs_ctl
drwx------ 4 vastbase vastbase 128 Mar 11 03:24 vb_initdb
/home/vastbase/data/vastbase_log/bin/gs_ctl:
total 4
-rw------- 1 vastbase vastbase 452 Mar 11 03:24 gs_ctl-2026-03-11_032448-current.log
-rw------- 1 vastbase vastbase 0 Mar 11 03:24 gs_ctl.lock
/home/vastbase/data/vastbase_log/bin/vb_initdb:
total 4
-rw------- 1 vastbase vastbase 219 Mar 11 03:24 vb_initdb-2026-03-11_032438-current.log
-rw------- 1 vastbase vastbase 0 Mar 11 03:24 vb_initdb.lock
不管了, 手册中已经找不到解决办法, 我们进行后续的测试.
2、vastbase g100 似乎是线程模型
通过top看到只有一个进程, 在top命令中输入H可用看到各个线程.
top -c
top - 10:33:07 up 2:43, 0 users, load average: 2.94, 2.38, 2.47
Tasks: 5 total, 1 running, 4 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.7 us, 0.0 sy, 0.0 ni, 93.5 id, 0.0 wa, 0.0 hi, 0.7 si, 0.0 st
MiB Mem : 7937.4 total, 5090.5 free, 1112.9 used, 1734.0 buff/cache
MiB Swap: 2048.0 total, 1564.8 free, 483.2 used. 5535.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 vastbase 20 0 17.8g 1.9g 1.2g S 23.9 24.5 34:00.24 vastbase
132 vastbase 20 0 214592 2260 1968 S 0.0 0.0 0:00.04 bash
输入 H
top - 10:33:36 up 2:43, 0 users, load average: 2.82, 2.41, 2.47
Threads: 66 total, 1 running, 65 sleeping, 0 stopped, 0 zombie
%Cpu(s): 6.0 us, 0.2 sy, 0.0 ni, 93.3 id, 0.0 wa, 0.0 hi, 0.5 si, 0.0 st
MiB Mem : 7937.4 total, 5091.7 free, 1111.7 used, 1734.0 buff/cache
MiB Swap: 2048.0 total, 1564.8 free, 483.2 used. 5536.5 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
113 vastbase 20 0 17.8g 1.9g 1.2g S 22.6 24.5 11:00.62 vastbase
80 vastbase 20 0 17.8g 1.9g 1.2g S 0.7 24.5 0:02.51 vastbase
92 vastbase 20 0 17.8g 1.9g 1.2g S 0.7 24.5 0:19.27 vastbase
94 vastbase 20 0 17.8g 1.9g 1.2g S 0.3 24.5 0:00.13 vastbase
107 vastbase 20 0 17.8g 1.9g 1.2g S 0.3 24.5 0:08.27 vastbase
108 vastbase 20 0 17.8g 1.9g 1.2g S 0.3 24.5 0:16.75 vastbase
116 vastbase 20 0 17.8g 1.9g 1.2g S 0.3 24.5 0:16.35 vastbase
1 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.68 vastbase
47 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
50 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
57 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
58 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
59 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
60 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
61 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.49 vastbase
62 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
63 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
64 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
65 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
66 vastbase 20 0 17.8g 1.9g 1.2g S 0.0 24.5 0:00.00 vastbase
...
3、测试 tpc-b 性能
pgbench -i -s 100
pgbench -M prepared -n -r -P 1 -c 8 -j 8 -T 120
不知道为什么中间卡了一下? 我发现IO高时抖动就非常严重
progress: 45.0 s, 4164.1 tps, lat 1.940 ms stddev 1.433
progress: 46.0 s, 4879.6 tps, lat 1.640 ms stddev 1.096
progress: 47.0 s, 4933.4 tps, lat 1.620 ms stddev 0.889
progress: 48.0 s, 4908.1 tps, lat 1.632 ms stddev 1.151
progress: 49.0 s, 3263.4 tps, lat 2.449 ms stddev 1.727
progress: 50.0 s, 4275.1 tps, lat 1.870 ms stddev 1.246
progress: 65.6 s, 191.4 tps, lat 21.883 ms stddev 543.281
progress: 65.6 s, 11049.7 tps, lat 14843.573 ms stddev 0.449
progress: 65.6 s, 3533.6 tps, lat 14843.279 ms stddev 0.000
progress: 65.6 s, 0.0 tps, lat nan ms stddev nan
progress: 65.6 s, 0.0 tps, lat nan ms stddev nan
progress: 65.6 s, 0.0 tps, lat nan ms stddev nan
progress: 65.6 s, 0.0 tps, lat nan ms stddev nan
progress: 65.6 s, 27.4 tps, lat 74.243 ms stddev 0.002
progress: 65.6 s, 40816.3 tps, lat 2548.106 ms stddev 5531.694
progress: 65.6 s, 0.0 tps, lat nan ms stddev nan
progress: 65.6 s, 0.0 tps, lat nan ms stddev nan
progress: 65.6 s, 0.0 tps, lat nan ms stddev nan
progress: 65.6 s, 0.0 tps, lat nan ms stddev nan
progress: 65.7 s, 0.0 tps, lat nan ms stddev nan
progress: 65.7 s, 2176.8 tps, lat 3.285 ms stddev 0.067
progress: 66.0 s, 2703.4 tps, lat 2.966 ms stddev 2.125
progress: 67.0 s, 3975.7 tps, lat 2.012 ms stddev 1.793
progress: 68.0 s, 4150.1 tps, lat 1.927 ms stddev 1.396
progress: 69.0 s, 3654.0 tps, lat 2.190 ms stddev 1.483
transaction type: TPC-B (sort of)
scaling factor: 100
query mode: prepared
number of clients: 8
number of threads: 8
duration: 120 s
number of transactions actually processed: 464528
latency average: 2.149 ms
latency stddev: 82.389 ms
tps = 3721.161028 (including connections establishing)
tps = 3721.772869 (excluding connections establishing)
statement latencies in milliseconds:
0.000428 \set nbranches 1 * :scale
0.000220 \set ntellers 10 * :scale
0.000222 \set naccounts 100000 * :scale
0.000252 \setrandom aid 1 :naccounts
0.000203 \setrandom bid 1 :nbranches
0.000235 \setrandom ttid 1 :ntellers
0.000200 \setrandom delta -5000 5000
0.068997 START TRANSACTION;
0.135186 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
0.075694 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
0.079164 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE ttid = :ttid;
0.161304 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
0.113091 INSERT INTO pgbench_history (ttid, bid, aid, delta, mtime) VALUES (:ttid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
1.512970 END;
纯查询也有严重抖动, 可能磁盘比较差劲. IO高时抖动就非常严重
progress: 78.0 s, 139813.8 tps, lat 0.057 ms stddev 0.052
progress: 79.0 s, 135331.2 tps, lat 0.059 ms stddev 0.087
progress: 80.0 s, 141697.0 tps, lat 0.056 ms stddev 0.056
progress: 81.0 s, 150054.4 tps, lat 0.053 ms stddev 0.045
progress: 82.0 s, 151656.0 tps, lat 0.053 ms stddev 0.049
progress: 83.0 s, 147398.5 tps, lat 0.054 ms stddev 0.061
progress: 84.0 s, 151886.5 tps, lat 0.052 ms stddev 0.048
progress: 85.0 s, 148705.9 tps, lat 0.054 ms stddev 0.060
progress: 86.0 s, 143549.0 tps, lat 0.056 ms stddev 0.050
progress: 87.0 s, 138139.0 tps, lat 0.058 ms stddev 0.061
progress: 88.0 s, 131134.5 tps, lat 0.061 ms stddev 0.056
progress: 89.0 s, 147663.2 tps, lat 0.054 ms stddev 0.036
progress: 90.0 s, 138192.0 tps, lat 0.058 ms stddev 0.075
progress: 91.0 s, 142606.3 tps, lat 0.056 ms stddev 0.074
progress: 92.0 s, 142730.3 tps, lat 0.056 ms stddev 0.076
progress: 93.0 s, 144253.0 tps, lat 0.055 ms stddev 0.063
progress: 94.0 s, 145893.0 tps, lat 0.055 ms stddev 0.050
transaction type: SELECT only
scaling factor: 100
query mode: prepared
number of clients: 8
number of threads: 8
duration: 120 s
number of transactions actually processed: 10944873
latency average: 0.088 ms
latency stddev: 0.621 ms
tps = 91205.529934 (including connections establishing)
tps = 91216.003136 (excluding connections establishing)
statement latencies in milliseconds:
0.000242 \set naccounts 100000 * :scale
0.000170 \setrandom aid 1 :naccounts
0.087026 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
果然, 1000万数据量超过了shared buffer, 不管是查询还是正常读写事务, 抖动都很严重
[vastbase@3f628a7168d3 ~]$ psql
psql ((Vastbase G100 V3.0 (Build 8) Release) compiled at 2025-12-07 20:42:33 commit 29407 last mr )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help"forhelp.
vastbase=# show shared_buffers ;
shared_buffers
----------------
1GB
(1 row)
vastbase=# \dt+
List of relations
Schema | Name | Type | Owner | Size | Storage | Description
--------+------------------+-------+----------+---------+-------------------------------------------------+-------------
public | pgbench_accounts | table | vastbase | 1302 MB | {orientation=row,fillfactor=100,compression=no} |
public | pgbench_branches | table | vastbase | 896 kB | {orientation=row,fillfactor=100,compression=no} |
public | pgbench_history | table | vastbase | 29 MB | {orientation=row,compression=no,fillfactor=80} |
public | pgbench_tellers | table | vastbase | 272 kB | {orientation=row,fillfactor=100,compression=no} |
(4 rows)
下面减少 scale , 把数据量弄到 buffer 以内再试试看.
速度快了很多, 也稳定了.
pgbench -i -s 50
transaction type: TPC-B (sort of)
scaling factor: 50
query mode: prepared
number of clients: 8
number of threads: 8
duration: 120 s
number of transactions actually processed: 820072
latency average: 1.170 ms
latency stddev: 0.737 ms
tps = 6833.850416 (including connections establishing)
tps = 6834.656668 (excluding connections establishing)
statement latencies in milliseconds:
0.000352 \set nbranches 1 * :scale
0.000182 \set ntellers 10 * :scale
0.000189 \set naccounts 100000 * :scale
0.000203 \setrandom aid 1 :naccounts
0.000169 \setrandom bid 1 :nbranches
0.000189 \setrandom ttid 1 :ntellers
0.000166 \setrandom delta -5000 5000
0.049455 START TRANSACTION;
0.077462 UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid;
0.049603 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
0.064494 UPDATE pgbench_tellers SET tbalance = tbalance + :delta WHERE ttid = :ttid;
0.136528 UPDATE pgbench_branches SET bbalance = bbalance + :delta WHERE bid = :bid;
0.098617 INSERT INTO pgbench_history (ttid, bid, aid, delta, mtime) VALUES (:ttid, :bid, :aid, :delta, CURRENT_TIMESTAMP);
0.691710 END;
纯查询如下
transaction type: SELECT only
scaling factor: 50
query mode: prepared
number of clients: 8
number of threads: 8
duration: 120 s
number of transactions actually processed: 20833273
latency average: 0.046 ms
latency stddev: 0.080 ms
tps = 173607.120277 (including connections establishing)
tps = 173639.029606 (excluding connections establishing)
statement latencies in milliseconds:
0.000223 \set naccounts 100000 * :scale
0.000160 \setrandom aid 1 :naccounts
0.045434 SELECT abalance FROM pgbench_accounts WHERE aid = :aid;
4、列存储
vastbase g100 支持列存储, 应用场景是分析型场景, 所以这里仅对比行列存储的空间、统计分析性能.
又踩到一个坑, 单条SQL写入数据量较大时, 会把内存打爆, 这个确实有点那啥了, PG上随便搞.
CREATE TABLE test_col
(
id int,
info text,
ts timestamp
)
WITH (ORIENTATION = COLUMN);
CREATE TABLE test_row
(
id int,
info text,
ts timestamp
)
WITH (ORIENTATION = ROW);
insert into test_col select generate_series(1,10000000), md5(random()::text), clock_timestamp();
insert into test_row select generate_series(1,10000000), md5(random()::text), clock_timestamp();
ERROR: memory is temporarily unavailable
DETAIL: Failed on request of size 36 bytes under queryid 1407374883553312 in varlena.cpp:224.
CONTEXT: referenced column: md5
ERROR: memory is temporarily unavailable
DETAIL: Failed on request of size 20 bytes under queryid 1407374883553313 in varlena.cpp:224.
CONTEXT: referenced column: md5
所以把单条SQL的写入量降低到100万条, 这下OK了.
insert into test_col select generate_series(1,1000000), md5(random()::text), clock_timestamp();
insert into test_row select generate_series(1,1000000), md5(random()::text), clock_timestamp();
空间占用上, 列存储肯定是占优的, 即使只用了低压缩比.
vastbase=# \dt+ test*
List of relations
Schema | Name | Type | Owner | Size | Storage | Description
--------+----------+-------+----------+-------+------------------------------------------------+-------------
public | test_col | table | vastbase | 37 MB | {orientation=column,compression=low} |
public | test_row | table | vastbase | 92 MB | {orientation=row,compression=no,fillfactor=80} |
(2 rows)
对比列存和行存分析查询的性能提升表现, 列存这里还用到了向量化执行, 所以会快很多, 速度提升达到10倍.
vastbase=# explain analyze (select avg(id) from test_col);
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------
Row Adapter (cost=9093.01..9093.01 rows=1 width=36) (actual time=13.196..13.197 rows=1 loops=1)
-> Vector Aggregate (cost=9093.00..9093.01 rows=1 width=36) (actual time=13.193..13.193 rows=1 loops=1)
-> CStore Scan on test_col (cost=0.00..6593.00 rows=1000000 width=4) (actual time=0.060..4.764 rows=1000000 loops=1)
Total runtime: 13.770 ms
(4 rows)
vastbase=# explain analyze (select avg(id) from test_row);
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=24265.00..24265.01 rows=1 width=36) (actual time=149.441..149.441 rows=1 loops=1)
-> Seq Scan on test_row (cost=0.00..21765.00 rows=1000000 width=4) (actual time=0.018..64.865 rows=1000000 loops=1)
Total runtime: 149.677 ms
(3 rows)
5、ustore (in-place update存储引擎)
https://docs.vastdata.com.cn/zh_CN/VastbaseG100/V3.0.9/1/4776d12b29fe4b7bbd3053b3f7b2c5fc
Vastbase G100提供了Ustore存储引擎，引入了原地更新（In-place Update）机制，相较于Astore行存储引擎所采用的追加更新（Append Update）模式，提供了显著的优势。追加更新对INSERT、DELETE操作以及热更新（即HOT Update，指页面内的数据更新）表现出色，但在处理涉及跨数据页面的非热更新时，其垃圾回收效率较低。而Ustore通过实现原地更新，优化了这一过程，使得在面对跨页更新场景时，能够提供更加高效的数据管理与垃圾回收能力，从而提升了整体性能和资源利用率。
下面来测试一下, 主要是在频繁的更新后, 膨胀的情况
建表并写入数据
CREATE TABLE test_ustore
(
id int primary key,
info text,
ts timestamp
)
WITH (storage_type=ustore);
insert into test_ustore select generate_series(1,1000000), md5(random()::text), clock_timestamp();
CREATE TABLE test_heap
(
id int primary key,
info text,
ts timestamp
)
WITH (storage_type=astore);
insert into test_heap select generate_series(1,1000000), md5(random()::text), clock_timestamp();
记录表的初始大小
vastbase=# \dt+
List of relations
Schema | Name | Type | Owner | Size | Storage | Description
--------+------------------+-------+----------+--------+--------------------------------------------------------------------+-------------
public | test_col | table | vastbase | 37 MB | {orientation=column,compression=low} |
public | test_heap | table | vastbase | 92 MB | {orientation=row,storage_type=astore,compression=no,fillfactor=80} |
public | test_row | table | vastbase | 92 MB | {orientation=row,compression=no,fillfactor=80} |
public | test_ustore | table | vastbase | 81 MB | {orientation=row,storage_type=ustore,fillfactor=80,compression=no} |
(8 rows)
频繁更新测试脚本 (注意, 需要使用早期PG版本的pgbench脚本语法)
echo "\\setrandom id 1 1000000
update test_heap set info=md5(random()::text), ts=now() where id=:id;" > ~/test_heap.sql
echo "\\setrandom id 1 1000000
update test_ustore set info=md5(random()::text), ts=now() where id=:id;" > ~/test_ustore.sql
更新200万次测试.
heap(astore)存储频繁更新测试, 记录更新后的表和索引大小
pgbench -M prepared -n -r -P 5 -f ~/test_heap.sql -c 8 -j 8 -t 250000
transaction type: Custom query
scaling factor: 1
query mode: prepared
number of clients: 8
number of threads: 8
number of transactions per client: 250000
number of transactions actually processed: 2000000/2000000
latency average: 1.021 ms
latency stddev: 0.310 ms
tps = 7833.664297 (including connections establishing)
tps = 7834.260266 (excluding connections establishing)
statement latencies in milliseconds:
0.000518 \setrandom id 1 1000000
1.019964 update test_heap set info=md5(random()::text), ts=now() where id=:id;
public | test_heap | table | vastbase | 92 MB | {orientation=row,storage_type=astore,compression=no,fillfactor=80} |
public | test_heap_pkey | index | vastbase | test_heap | 21 MB | |
ustore 存储频繁更新测试, 记录更新后的表和索引大小
pgbench -M prepared -n -r -P 5 -f ~/test_ustore.sql -c 8 -j 8 -t 250000
transaction type: Custom query
scaling factor: 1
query mode: prepared
number of clients: 8
number of threads: 8
number of transactions per client: 250000
number of transactions actually processed: 2000000/2000000
latency average: 1.087 ms
latency stddev: 0.634 ms
tps = 7355.478086 (including connections establishing)
tps = 7356.025112 (excluding connections establishing)
statement latencies in milliseconds:
0.000477 \setrandom id 1 1000000
1.086409 update test_ustore set info=md5(random()::text), ts=now() where id=:id;
public | test_ustore | table | vastbase | 81 MB | {orientation=row,storage_type=ustore,fillfactor=80,compression=no} |
public | test_ustore_pkey | index | vastbase | test_ustore | 30 MB | {storage_type=ustore} |
你会发现, 似乎两者都没什么变化, 难道ustore没有优势?
错了, 因为vacuum太快了, 而且heap(astore)本身就有hot技术(而且默认使用了fillfactor=80, 所以新纪录都在本页面内, 无需迁移, 空间未增加, 只要vacuum够快), 大幅度减少了正常情况下的膨胀, 但是一旦数据库中有长事务存在, 那就不一样了.
我们在数据库中开启一个10分钟的长事务, 再进行同样的测试.
这下astore扛不住了. 因为数据库不能回收集群中最早的未结束事务之后产生的垃圾记录, 所以你应该知道PG数据库的长事务监控为什么如此重要了吧.
vastbase=# begin;
BEGIN
vastbase=# select txid_current();
txid_current
--------------
1315664
(1 row)
vastbase=# select pg_sleep(1200);
有长事务的情况下, heap 存储频繁更新测试, 记录更新后的表和索引大小
transaction type: Custom query
scaling factor: 1
query mode: prepared
number of clients: 8
number of threads: 8
number of transactions per client: 250000
number of transactions actually processed: 2000000/2000000
latency average: 1.077 ms
latency stddev: 2.947 ms
tps = 7415.803663 (including connections establishing)
tps = 7416.341768 (excluding connections establishing)
statement latencies in milliseconds:
0.000521 \setrandom id 1 1000000
1.076369 update test_heap set info=md5(random()::text), ts=now() where id=:id;
vastbase=# \dt+
List of relations
Schema | Name | Type | Owner | Size | Storage | Description
--------+------------------+-------+----------+--------+--------------------------------------------------------------------+-------------
public | creditcard_info | table | vastbase | 497 MB | {orientation=row,compression=no,fillfactor=80} |
public | pgbench_accounts | table | vastbase | 652 MB | {orientation=row,fillfactor=100,compression=no} |
public | pgbench_branches | table | vastbase | 896 kB | {orientation=row,fillfactor=100,compression=no} |
public | pgbench_history | table | vastbase | 52 MB | {orientation=row,compression=no,fillfactor=80} |
public | pgbench_tellers | table | vastbase | 560 kB | {orientation=row,fillfactor=100,compression=no} |
public | test_col | table | vastbase | 37 MB | {orientation=column,compression=low} |
public | test_heap | table | vastbase | 226 MB | {orientation=row,storage_type=astore,compression=no,fillfactor=80} |
public | test_row | table | vastbase | 92 MB | {orientation=row,compression=no,fillfactor=80} |
public | test_ustore | table | vastbase | 81 MB | {orientation=row,storage_type=ustore,fillfactor=80,compression=no} |
(9 rows)
vastbase=# \di+
List of relations
Schema | Name | Type | Owner | Table | Size | Storage | Description
--------+--------------------------+-------+----------+------------------+--------+-----------------------+-------------
public | creditcard_info_name_idx | index | vastbase | creditcard_info | 235 MB | |
public | pgbench_accounts_pkey | index | vastbase | pgbench_accounts | 107 MB | |
public | pgbench_branches_pkey | index | vastbase | pgbench_branches | 16 kB | |
public | pgbench_tellers_pkey | index | vastbase | pgbench_tellers | 56 kB | |
public | test_heap_pkey | index | vastbase | test_heap | 83 MB | |
public | test_ustore_pkey | index | vastbase | test_ustore | 30 MB | {storage_type=ustore} |
(6 rows)
100万行, 但是有300万行占据了空间
3000000 nonremovable row versions
vastbase=# vacuum verbose test_heap;
INFO: vacuuming "public.test_heap"(vastbase pid=1)
INFO: index "test_heap_pkey" now contains 2451217 row versions in 10568 pages(vastbase pid=1)
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "test_heap": found 0 removable, 3000000 nonremovable row versions in 28852 out of 28891 pages(vastbase pid=1)
DETAIL: 2000000 dead row versions cannot be removed yet. There were 0 unused item pointers. 0 pages are entirely empty. 109 pages have dead items. OldestXid 8290651. CPU 0.00s/0.17u sec elapsed 0.17 sec.
INFO: index scan bypassed: 109 pages from table (0.38% of total) have 217 dead item identifiers(vastbase pid=1)
INFO: vacuuming "pg_toast.pg_toast_36660"(vastbase pid=1)
INFO: index "pg_toast_36660_index" now contains 0 row versions in 1 pages(vastbase pid=1)
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pg_toast_36660": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages(vastbase pid=1)
DETAIL: 0 dead row versions cannot be removed yet. There were 0 unused item pointers. 0 pages are entirely empty. 0 pages have dead items. OldestXid 8290651. CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
有长事务的情况下, ustore 存储频繁更新测试, 记录更新后的表和索引大小
transaction type: Custom query
scaling factor: 1
query mode: prepared
number of clients: 8
number of threads: 8
number of transactions per client: 250000
number of transactions actually processed: 2000000/2000000
latency average: 1.087 ms
latency stddev: 0.652 ms
tps = 7360.270653 (including connections establishing)
tps = 7360.733318 (excluding connections establishing)
statement latencies in milliseconds:
0.000506 \setrandom id 1 1000000
1.085919 update test_ustore set info=md5(random()::text), ts=now() where id=:id;
vastbase=# \dt+
List of relations
Schema | Name | Type | Owner | Size | Storage | Description
--------+------------------+-------+----------+--------+--------------------------------------------------------------------+-------------
public | creditcard_info | table | vastbase | 497 MB | {orientation=row,compression=no,fillfactor=80} |
public | pgbench_accounts | table | vastbase | 652 MB | {orientation=row,fillfactor=100,compression=no} |
public | pgbench_branches | table | vastbase | 896 kB | {orientation=row,fillfactor=100,compression=no} |
public | pgbench_history | table | vastbase | 52 MB | {orientation=row,compression=no,fillfactor=80} |
public | pgbench_tellers | table | vastbase | 560 kB | {orientation=row,fillfactor=100,compression=no} |
public | test_col | table | vastbase | 37 MB | {orientation=column,compression=low} |
public | test_heap | table | vastbase | 226 MB | {orientation=row,storage_type=astore,compression=no,fillfactor=80} |
public | test_row | table | vastbase | 92 MB | {orientation=row,compression=no,fillfactor=80} |
public | test_ustore | table | vastbase | 81 MB | {orientation=row,storage_type=ustore,fillfactor=80,compression=no} |
(9 rows)
vastbase=# \di+
List of relations
Schema | Name | Type | Owner | Table | Size | Storage | Description
--------+--------------------------+-------+----------+------------------+--------+-----------------------+-------------
public | creditcard_info_name_idx | index | vastbase | creditcard_info | 235 MB | |
public | pgbench_accounts_pkey | index | vastbase | pgbench_accounts | 107 MB | |
public | pgbench_branches_pkey | index | vastbase | pgbench_branches | 16 kB | |
public | pgbench_tellers_pkey | index | vastbase | pgbench_tellers | 56 kB | |
public | test_heap_pkey | index | vastbase | test_heap | 83 MB | |
public | test_ustore_pkey | index | vastbase | test_ustore | 30 MB | {storage_type=ustore} |
(6 rows)
100万记录, 还是100万记录.
vastbase=# vacuum verbose test_ustore;
INFO: vacuuming uheap "public.test_ustore" oldestXmin:8290651
INFO: index "test_ustore_pkey" now contains 1000000 row versions in 3863 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.01u sec elapsed 0.01 sec.
INFO: "test_ustore": found 0 removable, 1000000 nonremovable row versions in 10310 out of 10310 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 8290651
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.26u sec elapsed 0.26 sec.
INFO: vacuuming uheap "pg_toast.pg_toast_36668" oldestXmin:8290651
INFO: index "pg_toast_36668_index" now contains 0 row versions in 1 pages
DETAIL: 0 index row versions were removed.
0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO: "pg_toast_36668": found 0 removable, 0 nonremovable row versions in 0 out of 0 pages
DETAIL: 0 dead row versions cannot be removed yet, oldest xmin: 8290651
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
VACUUM
在有长事务的情况下, ustore优势非常明显.
6、使用加密列
vastbase 提供了符合国密标准的加密功能, 下面测试一下列加密, 并测试列加密后的索引、排序等功能.
https://docs.vastdata.com.cn/zh_CN/VastbaseG100/V3.0.9/1/03c79cc54f0f49dbb25f5ab6479c1460
首先要创建本地kms, 所有的加密功能必须在支持加密的客户端中进行
vsql -d vastbase -C
CREATE CLIENT MASTER KEY imgcek1 WITH (KEY_STORE = localkms, KEY_PATH = "key_path_value1", ALGORITHM = RSA_2048);
CREATE CLIENT MASTER KEY imgcek WITH (KEY_STORE = localkms, KEY_PATH = "key_path_value2", ALGORITHM = RSA_2048);
./vastbase/etc/localkms:
total 32
-rw------- 1 vastbase vastbase 1752 Mar 11 10:03 vastbase_key_path_value1.priv
-rw------- 1 vastbase vastbase 84 Mar 11 10:03 vastbase_key_path_value1.priv.rand
-rw------- 1 vastbase vastbase 536 Mar 11 10:03 vastbase_key_path_value1.pub
-rw------- 1 vastbase vastbase 84 Mar 11 10:03 vastbase_key_path_value1.pub.rand
-rw------- 1 vastbase vastbase 1752 Mar 11 10:03 vastbase_key_path_value2.priv
-rw------- 1 vastbase vastbase 84 Mar 11 10:03 vastbase_key_path_value2.priv.rand
-rw------- 1 vastbase vastbase 536 Mar 11 10:03 vastbase_key_path_value2.pub
-rw------- 1 vastbase vastbase 84 Mar 11 10:03 vastbase_key_path_value2.pub.rand
然后创建列加密密钥
CREATE COLUMN ENCRYPTION KEY imgcek1 WITH VALUES (CLIENT_MASTER_KEY = imgcek1, ALGORITHM = AEAD_AES_256_CBC_HMAC_SHA256);
CREATE COLUMN ENCRYPTION KEY imgcek WITH VALUES (CLIENT_MASTER_KEY = imgcek, ALGORITHM = AEAD_AES_256_CBC_HMAC_SHA256);
vastbase=# SELECT * FROM GS_CLIENT_GLOBAL_KEYS;
global_key_name | key_namespace | key_owner | key_acl | create_date
-----------------+---------------+-----------+---------+----------------------------
imgcek1 | 2200 | 10 | | 2026-03-11 10:03:21.973896
imgcek | 2200 | 10 | | 2026-03-11 10:03:22.288289
(2 rows)
vastbase=# SELECT column_key_name,column_key_distributed_id ,global_key_id,key_owner FROM GS_COLUMN_KEYS;
column_key_name | column_key_distributed_id | global_key_id | key_owner
-----------------+---------------------------+---------------+-----------
imgcek1 | 760411027 | 36833 | 10
imgcek | 3618369306 | 36839 | 10
(2 rows)
创建带有加密列的表
CREATE TABLE creditcard_info (
id_number int,
name text encrypted with (column_encryption_key = ImgCEK, encryption_type = DETERMINISTIC),
credit_card varchar(19) encrypted with (column_encryption_key = ImgCEK1, encryption_type = DETERMINISTIC)
);
vastbase=# \d creditcard_info
Table "public.creditcard_info"
Column | Type | Modifiers
-------------+-------------------+------------
id_number | integer |
name | text | encrypted
credit_card | character varying | encrypted
写入一些测试数据
vastbase=# INSERT INTO creditcard_info VALUES (1,'joe','6217986500001288393');
INSERT 0 1
vastbase=# INSERT INTO creditcard_info VALUES (2, 'joy','6219985678349800033');
INSERT 0 1
vastbase=# select * from creditcard_info where name = 'joe';
id_number | name | credit_card
-----------+------+---------------------
1 | joe | 6217986500001288393
(1 row)
vastbase=# select id_number,name from creditcard_info;
id_number | name
-----------+------
1 | joe
2 | joy
(2 rows)
使用非密态客户端查看该加密表数据时是密文
[vastbase@3f628a7168d3 ~]$ psql
psql ((Vastbase G100 V3.0 (Build 8) Release) compiled at 2025-12-07 20:42:33 commit 29407 last mr )
Non-SSL connection (SSL connection is recommended when requiring high-security)
Type "help" for help.
vastbase=# select id_number,name from creditcard_info;
id_number | name
-----------+------------------------------------------------------------------------------------------------------------------------------------------------------
1 | \x011aefabd7f6a71822815c2fd97a473fe139c6d137fd42ce05d26c80b6f15ebffc496346ea31000000d73e70c394cca14065d314e9489e80887770e130ed1b0b9c54b7482513acc3e5
2 | \x011aefabd7724efd00260ce86860f12d90726f93a9e284186f15d2a7a37b94510f80d4270c3100000078a870c20edc7360da3dff29abbd41b35ff995995150f4030faa5a464c041d6c
(2 rows)
各位可以试试加密列是否支持排序、比较, 是否支持索引加速, 我试了似乎是可以的
vastbase=# create index on creditcard_info (name);
CREATE INDEX
vastbase=# explain select * from creditcard_info order by name;
QUERY PLAN
----------------------------------------------------------------------
Sort (cost=1.03..1.03 rows=2 width=68)
Sort Key: name
-> Seq Scan on creditcard_info (cost=0.00..1.02 rows=2 width=68)
(3 rows)
vastbase=# set enable_sort=off;
SET
vastbase=# explain select * from creditcard_info order by name;
QUERY PLAN
--------------------------------------------------------------------------------------------------
[Bypass]
Index Scan using creditcard_info_name_idx on creditcard_info (cost=0.00..12.28 rows=2 width=68)
(2 rows)
.....
vastbase=# insert into creditcard_info select * from creditcard_info ;
INSERT 0 1048576
Time: 6253.179 ms
vastbase=# explain select name from creditcard_info order by name limit 10;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------
[Bypass]
Limit (cost=0.00..13.03 rows=10 width=74)
-> Index Only Scan using creditcard_info_name_idx on creditcard_info (cost=0.00..2732966.88 rows=2097183 width=74)
(3 rows)
Time: 0.456 ms
vastbase=# select name from creditcard_info order by name limit 1;
name
------
joy
(1 row)
Time: 0.408 ms
vastbase 还提供了其他非常企业级的能力, 有兴趣的朋友, 特别是对国产信创数据库有兴趣的朋友, 可以多测试一下看看.
我就先写这些, 抛砖引玉吧, 有坑, 也有惊喜.
本文参与 腾讯云自媒体同步曝光计划，分享自微信公众号。
原始发表：2026-03-11，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
目录
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号