金仓数据库作为国产数据库中非常重要的一员，其地位也非常的重要。尤其随着开源运动的兴起，KingbaseES在数据库领域显示出举足轻重的地位。这也很好地促进了金仓数据库的发展。
人大金仓数据库管理系统KingbaseES（简称：金仓数据库或KingbaseES）是北京人大金仓信息技术股份有限公司研制开发的具有自主知识产权的通用关系型数据库管理系统。
金仓数据库基于PostgreSQL开发构建，因此这里可以拿PostgreSQL来比较学习它的体系结构，这样比较容易理解，其主要结构如下图所示。
金仓数据库的体系架构中最重要的就是数据的存储结构，而数据存储结构分为逻辑存储结构和物理存储存储。其中，逻辑存储结构是数据库内部的组织和管理数据的方式；而物理存储结构是操作系统中组织和管理数据的方式。
视频讲解如下：
一、 逻辑存储结构
金仓数据库的逻辑存储结构主要是指数据库中的各种数据库对象，包括：数据库集群、数据库、表、索引、视图等等。所有数据库对象都有各自的对象标识符oid（object identifiers）,它是一个无符号的四字节整数，相关对象的oid都存放在相关的系统目录表中，比如数据库的oid和表的oid分别存放在sys_database,sys_class表中。下图展示了KingBaseES数据库的逻辑存储结构。
二、 物理存储结构
数据库实例初始化的时候会创建一个目录，通常都会在系统配置相关的环境变量$KINGBASEDATA来表示。当数据库初始化完成后，会在这个目录生成相关的子目录以及一些文件。下图就是金仓数据库的物理结构：
金仓数据库的物理存储结构主要是指硬盘上存储的文件，包括：数据文件、日志文件、参数文件、控制文件、WAL预写日志文件等等。下面分别进行介绍。
2.1 数据文件
顾名思义，数据文件用于存储数据，文件名以oid命名。对于超出1G的数据文件，KingBaseES会自动将其拆分为多个文件来存储，而拆分的文件名将由sys_class中的relfilenode字段来决定。通过下面的步骤可以确定表所对应的数据文件。
（1）查看数据库的oid。
kingbase=# select oid,datname from sys_database; # 输出的信息如下： oid | datname -------+----------- 14791 | test 14792 | kingbase 1 | template1 14790 | template0 14793 | security 16384 | scott (6 行记录) # 14792 是数据库kingbase的OID。
（2）查询前面创建的testtable1表的OID。
kingbase=# select oid,relname,relkind,relfilenode from sys_class where relname ='testtable1'; # 输出的信息如下： oid | relname | relkind | relfilenode -------+------------+---------+------------- 16428 | testtable1 | r | 16428 (1 行记录) # 16428 是表testtable1的OID。
（3）查看表空间mydemotbs对应的目录，如下图所示。
2.2 日志文件
金仓数据库的日志文分为运行日志、WAL预写日志、事务日志和服务器日志。
（*）运行日志（sys_log）
在默认的情况下，运行日志没有开启。通过查看主kingbase.conf文件的配置可以看到相关的参数设置，开启后会自动生成该日志文件。运行时日志一般是记录数据库服务器与数据库的状态，比如各种错误信息、定位慢查询SQL、数据库的启动关闭信息、发生检查点过于频繁等的告警信息等等。该日志有.csv格式和.log格式，建议使用.csv格式。因为.csv格式一般会按大小和时间自动切割。sys_log是可以被清理删除、压缩打包或者转移，同时不影响数据库的正常运行。当有遇到数据库无法启动或者更改参数没有生效时，第一步就可以查看运行时日志。下图展示了主参数文件kingbase.conf中关于运行日志的配置参数。
（*）WAL预写日志（sys_wal）
sys_wal 这个目录是记录的KingBaseES的WAL信息。WAL是Write Ahead Logging的缩写，即预写日志，它是保证数据完整性的一种标准方法。简单来说就是在KingBaseES数据库中要对数据文件进行修改时必须先写入WAL日志信息，即当WAL日志记录完成了持久化，刷新到永久储存之后才能更改数据文件。根据这个原则就不需要在每次提交事务的时候都刷新数据到磁盘。因为当数据库出现宕机发生数据丢失时，可以重新执行WAL日志来达到恢复数据库的目的。因此WAL日志也可以叫做redo重做日志，因为任何没有写到数据文件上的改动都可以根据日志记录进行重做。在默认的情况下，单个WAL预写日志文件的大小是16M，通过参数wal_segment_size决定。
kingbase=# show wal_segment_size; # 输出的信息如下： wal_segment_size ------------------ 16MB (1 行记录)
下图说明了数据提交与WAL日志写入时的关系。
（*）事务日志（sys_xact）
sys_xact是事务提交日志，记录了事务的元数据。默认开启。内容一般不能直接读。默认存储在目录$KINGBASE_DATA/sys_xact/。
（*）服务器日志
如果用sys_ctl启动的时候没有指定-l参数来指定服务器日志，错误可能会输出到cmd前台。下图展示了在启动数据库服务器时，使用“-l”参数生成的服务器日志文件，它记录了数据库的重要信息。
logfile文件的内容如下：
2025-09-11 12:04:10.504 CST [13066] LOG: sepapower扩展初始化完成 2025-09-11 12:04:10.521 CST [13066] LOG: 正在启动 KingbaseES V009R001C010 2025-09-11 12:04:10.521 CST [13066] LOG: 正在监听IPv4地址"0.0.0.0"，端口 54321 2025-09-11 12:04:10.521 CST [13066] LOG: 正在监听IPv6地址"::"，端口 54321 2025-09-11 12:04:10.522 CST [13066] LOG: 在Unix套接字 "/tmp/.s.KINGBASE.54321"上侦听 2025-09-11 12:04:10.773 CST [13066] LOG: 日志输出重定向到日志收集进程 2025-09-11 12:04:10.773 CST [13066] HINT: 后续的日志输出将出现在目录 "/home/kingbase/kdb/kes_oracle_instance/sys_log"中.
2.3 控制文件
控制文件记录了数据库运行时的一些信息，比如数据库oid、是否是打开状态、WAL的位置、检查点的信息等等。金仓数据库的控制文件是很重要的数据库文件。控制文件默认保存在文件$KINGBASE_DATA/global/sys_control，可以使用命令bin/sys_controldata查看控制文件的内容，具体的操作步骤如下：
（1）进入金仓数据库的Server目录。
cd /home/kingbase/kdb/Server/
（2）执行命令查看控制文件的内容。
[kingbase@kingbase Server]$ bin/sys_controldata ~/kdb/kes_oracle_instance/ # 输出的信息如下： sys_control版本: 1201 Catalog版本: 202502271 数据库系统标识符: 7548668357165694582 数据库簇状态: 在运行中 sys_control最后修改: 2025年09月11日 星期四 12时04分10秒 最新检查点位置: 0/8000130 最新检查点的REDO位置: 0/8000130 最新检查点的重做日志文件: 000000010000000000000008 最近检查点的WalTimeLineID: 1 最新检查点的PrevTimeLineID: 1 最新检查点的full_page_writes: 开启 最新检查点的NextXID: 0:1117 最新检查点的NextOID: 16400 最新检查点的NextMultiXactId: 1 最新检查点的NextMultiOffsetD: 0 最新检查点的oldestXID: 1064 最新检查点的oldestXID所在的数据库： 1 最新检查点的oldestActiveXID: 0 最新检查点的oldestMultiXid: 1 最新检查点的oldestMulti所在的数据库： 1 最新检查点的oldestCommitTsXid: 0 最新检查点的newestCommitTsXid: 0 最新检查点的时间: 2025年09月11日 星期四 12时04分05秒 不带日志的关系: 0/3E8使用虚假的LSN计数器 最小恢复结束位置: 0/0 最小恢复结束位置时间表: 0 开始进行备份的点位置: 0/0 备份的最终位置: 0/0 需要终止备份的记录: 否 wal_level设置： replica wal_log_hints设置： 关闭 max_connections设置： 100 max_worker_processes设置： 30 max_wal_senders设置: 10 max_prepared_xacts设置： 0 max_locks_per_xact设置: 64 track_commit_timestamp设置: 关闭 最大数据校准: 8 数据库块大小: 8192 大关系的每段块数: 131072 WAL的块大小: 8192 每一个WAL段字节数: 16777216 标识符的最大长度: 64 在索引中可允许使用最大的列数: 32 TOAST区块的最大长度: 1988 大对象区块的大小: 2048 日期/时间存储类型: 64位整数 正在传递Float4类型的参数: 由值 正在传递Float8类型的参数: 由值 数据页校验和版本: 0 数据页校验和算法设备: 0 当前身份验证: cc0df2ed4d3a338f6ae2838c46cc123e2634be5 数据库模式： 1 身份验证方法模式： 0
2.4 参数文件
金仓数据库的参数文件主要包括四个，它们分别是kingbase.conf、sys_hba.conf、sys_ident.conf和kingbase.auto.conf。下表对这四个参数文件的作用分别进行了介绍。
三、 进程结构
执行下面的命令列出所有的金仓数据库的进程。
[kingbase@kingbase ~]$ ps -ef | grep kingbase: # 输出的信息如下： ...... kingbase: kes_oracle_instance: logger ...... kingbase: kes_oracle_instance: checkpointer ...... kingbase: kes_oracle_instance: background writer ...... kingbase: kes_oracle_instance: walwriter ...... kingbase: kes_oracle_instance: autovacuum launcher ...... kingbase: kes_oracle_instance: stats collector ...... kingbase: kes_oracle_instance: kwr collector ...... kingbase: kes_oracle_instance: ksh writer ...... kingbase: kes_oracle_instance: ksh collector ...... kingbase: kes_oracle_instance: logical replication launcher # 注意：该命令最后有一个冒号。
下面分别介绍各个进程的作用。
3.1、 总控制进程kingbase
进程kingbase是整个数据库实例的总控制进程，负责启动和关闭数据库实例。用户可以运行kingbase命令，并加上合适的参数启动数据库。下面展示了该进程的相关信息：
kingbase 13066 1 0 13:21 ? 00:00:00 /home/kingbase/kdb/KESRealPro/V009R001C010/Server/bin/kingbase -D /home/kingbase/kdb/kes_oracle_instance
而更多时候使用sys_ctl启动数据库，sys_ctl也是通过运行kingbase命令来启动数据库实例，它只是做了一些包装，让用户更容易启动数据库，所以主进程kingbase实际是第一个金仓数据库进程，此进程会fork一些与数据库实例相关的辅助子进程，并管理他们。
当用户与KingBaseES数据库建立连接时，实际上是先与kingbase进程建立连接。此时，客户端程序会发出身份证验证的消息给kingbase进程，kingbase主进程根据消息中的信息进行客户端身份验证。如果验证通过，它会fork一个子进程kingbase为这个连接服务，fork出来的进程被称为服务进程。
通过查询sys_stat_activity表可以看到这些服务进程的pid，下面的步骤将要是如何查看服务进程。
（1）查询sys_stat_activity表获取服务进程的pid。
kingbase=# select pid,application_name from sys_stat_activity; # 输出的信息如下： pid | application_name -------+--------------------- 13073 | auto vacuum 13077 | sys_ksh collector 13078 | logical replication 13076 | ksh writer 13186 | ksql 13071 | background flush 13070 | check pointer 13072 | wal flush (8 行记录)
（2）在操作系统上查看对应的进程信息。
[kingbase@kingbase Server]$ ps -ef|egrep \ "13073|13077|13078|13076|13186|13071|13070|13072" # 输出的信息如下： kingbase 13070 13066 ... : checkpointer kingbase 13071 13066 ... : background writer kingbase 13072 13066 ... : walwriter kingbase 13073 13066 ... : autovacuum launcher kingbase 13076 13066 ... : ksh writer kingbase 13077 13066 ... : ksh collector kingbase 13078 13066 ... : logical replication launcher kingbase 13186 13066 ... : system kingbase [local] idle
3.2、 系统日志进程SysLogger
在kingbase.conf里启用运行日志后，会有SysLogger进程。SysLogger会在日志文件达到指定的大小时关闭当前日志文件，产生新的日志文件。
3.3、 写进程BgWriter
BgWriter是KingBaseES中在后台将脏页写出到磁盘的辅助进程，引入该进程主要为达到如下两个目的：
- 首先，数据库在进行查询处理时若发现要读取的数据不在缓冲区中时要先从磁盘中读入要读取的数据所在的页面，此时如果缓冲区已满，则需要先选择部分缓冲区中的页面替换出去。如果被替换的页面没有被修改过，那么可以直接丢弃；但如果要被替换的页已被修改，则必需先将这页写出到磁盘中后才能替换，这样数据库的查询处理就会被阻塞。通过使用BgWriter定期写出缓冲区中的部分脏页到磁盘中，为缓冲区腾出空间，就可以降低查询处理被阻塞的可能性。
- 其次，KingBaseES在定期作检查点时需要把所有脏页写出到磁盘，通过BgWriter预先写出一些脏页，可以减少设置检查点时要进行的I/O操作，使系统的I/O负载趋向平稳。通过BgWriter对共享缓冲区写操作的统一管理，避免了其他服务进程在需要读入新的页面到共享缓冲区时，不得不将之前修改过的页面写出到磁盘的操作。
下面展示了如何在ksql命令行工具中查看与BgWriter后台写进程相关的参数及其默认值。
--连续两次写数据之间的间隔时间 kingbase=# show bgwriter_delay; bgwriter_delay ---------------- 200ms (1 行记录) --每次写的最大数据量，默认值是100 kingbase=# show bgwriter_lru_maxpages; bgwriter_lru_maxpages ----------------------- 100 (1 行记录) --每次写入磁盘的数据块数 kingbase=# show bgwriter_lru_multiplier; bgwriter_lru_multiplier ------------------------- 2 (1 行记录) --当数据页大小达到bgwriter_flush_after时触发BgWriter，默认值为512KB kingbase=# show bgwriter_flush_after; bgwriter_flush_after ---------------------- 512kB (1 行记录)
3.4、 预写日志进程WalWriter
该进程用于保存WAL预写日志扫WAL预写日志文件。预写日志WAL的中心思想是对数据文件的修改必须是只能发生在这些修改已经记录到日志之后，也就是先写日志后写数据。如果遵循这个过程，那么就不需要在每次事务提交的时候都把数据块刷回到磁盘，这一点与Oracle数据库是完全一致的。kingbase.conf文件中与WalWriter进程相关的参数如下：
#------------------------------------------------------------------------------ # WRITE-AHEAD LOG #------------------------------------------------------------------------------ # - Settings - #wal_level = replica # minimal, replica, or logical # (change requires restart) #fsync = on # flush data to disk for crash safety # (turning this off can cause # unrecoverable data corruption) #synchronous_commit = on # synchronization level; # off, local, remote_write, remote_apply, or on #wal_sync_method = fsync # the default is the first option # supported by the operating system: # open_datasync # fdatasync (default on Linux) # fsync # fsync_writethrough # open_sync #full_page_writes = on # recover from partial page writes #wal_compression = off # enables compression of full-page writes; # off, kblz, lz4, zstd, or on #wal_log_hints = off # also do full page writes of non-critical updates # (change requires restart) #wal_init_zero = on # zero-fill new WAL files #wal_recycle = on # recycle WAL files #wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers # (change requires restart) #wal_writer_delay = 200ms # 1-10000 milliseconds #wal_writer_flush_after = 1MB # measured in pages, 0 disables #commit_delay = 0 # range 0-100000, in microseconds #commit_siblings = 5 # range 1-1000
3.5、 归档进程Archive Process
金仓数据库支持PITR（Point-In-Time-Recovery，基于时间点的恢复）技术，该技术支持将数据库恢复到其运行历史中任意一个有记录的时间点。PITR的另一个重要的基础就是对WAL文件的归档功能。归档进程的目标就是对WAL日志在磁盘上的存储形式进行归档备份。但在默认情况下，金仓数据库是非归档模式，因此看不到归档进程。归档进程通过kingbase.conf文件中的如下参数进行配置：
# - Archiving - archive_mode = off # enables archiving; off, on, or always # (change requires restart) archive_command = 'exit 0' # command to use to archive a logfile segment # placeholders: %p = path of file to archive # %f = file name only # e.g. 'test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f' #archive_timeout = 0 # force a logfile segment switch after this # number of seconds; 0 disables
3.6、 自动清理进程AutoVacuum
在金仓数据库数据库中，对数据进行UPDATE或者DELETE操作后，数据库不会立即删除旧版本的数据，而是标记为删除状态。这是因为金仓数据库数据库具有多版本的机制，如果这些旧版本的数据正在被另外的事务打开，那么暂时保留这些旧版本数据是很有必要的。而当事务提交后，旧版本的数据已经没有价值了，数据库需要清理垃圾数据腾出空间，而清理工作就是AutoVacuum进程进行的。kingbase.conf文件中与AutoVacuum进程相关的参数如下所示。
#------------------------------------------------------------------------------ # AUTOVACUUM #------------------------------------------------------------------------------ #autovacuum = on # Enable autovacuum subprocess? 'on' # requires track_counts to also be on. #log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and # their durations, > 0 logs only # actions running at least this number # of milliseconds. #autovacuum_max_workers = 3 # max number of autovacuum subprocesses # (change requires restart) #autovacuum_naptime = 1min # time between autovacuum runs #autovacuum_vacuum_threshold = 50 # min number of row updates before # vacuum #autovacuum_analyze_threshold = 50 # min number of row updates before # analyze #autovacuum_vacuum_scale_factor = 0.2 # fraction of table size before vacuum #autovacuum_analyze_scale_factor = 0.1 # fraction of table size before analyze #autovacuum_freeze_max_age = 200000000 # maximum XID age before forced vacuum # (change requires restart) #autovacuum_multixact_freeze_max_age = 400000000 # maximum multixact age # before forced vacuum # (change requires restart) #autovacuum_vacuum_cost_delay = 2ms # default vacuum cost delay for # autovacuum, in milliseconds; # -1 means use vacuum_cost_delay #autovacuum_vacuum_cost_limit = -1 # default vacuum cost limit for # autovacuum, -1 means use # vacuum_cost_limit
3.7、 统计信息收集进程：stats collector process
信息收集进程是金仓数据库的统计信息收集器，用来收集数据库运行期间的统计信息，如表的增删改次数、数据块的个数、索引的变化等等。收集统计信息主要是为了让优化器做出正确的判断，选择最佳的执行计划。Kingbase.conf文件中与统计信息收集进程相关的参数，如下：
#----------------------------------------------------------------- # STATISTICS #----------------------------------------------------------------- # - Query and Index Statistics Collector - #track_instance = off #track_sql = off #track_wait_timing = on #track_activities = on #track_counts = on #track_io_timing = off #track_functions = none # none, pl, all #track_activity_query_size = 1024 # (change requires restart) #stats_temp_directory = 'sys_stat_tmp'
3.8、 检查点进程CheckPoint
检查点是系统设置的事务序列点，设置检查点保证检查点前的日志信息已经成功写入到磁盘中。kingbase.conf文件中与之相关的参数有：
#checkpoint_timeout = 5min # range 30s-1d max_wal_size = 1GB min_wal_size = 80MB #checkpoint_completion_target = 0.5 # checkpoint target duration, 0.0 - 1.0 #checkpoint_flush_after = 0 # measured in pages, 0 disables #checkpoint_warning = 30s # 0 disables
四、 内存结构
金仓数据库的内存结构分为两种不同的类型，它们分别是本地内存和共享内存。它们的关系如下图所示：
4.1、本地内存
金仓数据库的本地内存是指每个后台进程（backend process）自己使用的内存区域，下表列举了KingBaseES中的本地内存以及它们的作用。
4.2、共享内存
金仓数据库的共享内存是指每个后台进程（backend process）共同使用的内存区域，下表列举了KingBaseES中的共享内存以及它们的作用。
