1、导出 [omm@gauss001 user1]$ gs_dump -U user1 -W User01#123 -f /home/omm/backup/user1.tar -p 30100 db1 -F t gs_dump[user='user1'][localhost][port='30100'][db1][2024-04-09 14:53:54]: The total objects number is 449.gs_dump[user='user1'][localhost][port='30100'][db1][2024-04-09 14:53:54]: [100.00%] 449 objects have been dumped.gs_dump[user='user1'][localhost][port='30100'][db1][2024-04-09 14:53:54]: dump database db1 successfullygs_dump[user='user1'][localhost][port='30100'][db1][2024-04-09 14:53:54]: total time: 3785 ms2、恢复db1=> truncate table test1; TRUNCATE TABLEdb1=> truncate table test2;TRUNCATE TABLE--这里不做清理也是可以的。恢复时自动删除。 gs_restore -U user1 -W User01#123 /home/omm/backup/user1.tar -p 30100 -d db1 -e -c[omm@gauss001 user1]$ gs_restore -U user1 -W User01#123 /home/omm/backup/user1.tar -p 30100 -d db1 -e -cstart restore operation ...table test1 complete data imported !table test2 complete data imported !Finish reading 8 SQL statements!end restore operation ...restore operation successfultotal time: 46 ms db1=> select * from test1; 1 2 3 db1=> select * from test2; 1 | 薛双奇1 2 | 薛双奇2

1.导出gs_dumpall -U user1 -W User01#123 -f /home/omm/backup/MPPDB_backup.sql -p 30100 [omm@gauss001 backup]$ gs_dumpall -U user1 -W User01#123 -f /home/omm/backup/MPPDB_backup.sql -p 30100 -cgs_dump[user='user1'][localhost][port='30100'][dbname='db1'][2024-04-09 15:13:15]: The total objects number is 449.gs_dump[user='user1'][localhost][port='30100'][dbname='db1'][2024-04-09 15:13:15]: [100.00%] 449 objects have been dumped.gs_dump[user='user1'][localhost][port='30100'][dbname='db1'][2024-04-09 15:13:15]: dump database dbname='db1' successfullygs_dump[user='user1'][localhost][port='30100'][dbname='db1'][2024-04-09 15:13:15]: total time: 3791 msgs_dump[user='user1'][localhost][port='30100'][dbname='drs'][2024-04-09 15:13:20]: The total objects number is 1219.gs_dump[user='user1'][localhost][port='30100'][dbname='drs'][2024-04-09 15:13:20]: [100.00%] 1219 objects have been dumped.gs_dump[user='user1'][localhost][port='30100'][dbname='drs'][2024-04-09 15:13:20]: dump database dbname='drs' successfullygs_dump[user='user1'][localhost][port='30100'][dbname='drs'][2024-04-09 15:13:20]: total time: 5290 msgs_dump[user='user1'][localhost][port='30100'][dbname='postgres'][2024-04-09 15:13:24]: The total objects number is 451.gs_dump[user='user1'][localhost][port='30100'][dbname='postgres'][2024-04-09 15:13:24]: [100.00%] 451 objects have been dumped.gs_dump[user='user1'][localhost][port='30100'][dbname='postgres'][2024-04-09 15:13:24]: dump database dbname='postgres' successfullygs_dump[user='user1'][localhost][port='30100'][dbname='postgres'][2024-04-09 15:13:24]: total time: 4057 msgs_dumpall[user='user1'][localhost][port='30100'][2024-04-09 15:13:24]: dumpall operation successfulgs_dumpall[user='user1'][localhost][port='30100'][2024-04-09 15:13:24]: total time: 13249 ms 可以看出，导出的内容:db1/drs/postgres三个数据库。 --近导出元数据。即结构定义。gs_dumpall -U user1 -W User01#123 -f /home/omm/backup/MPPDB_backup.sql -p 30100 -s2、本地原地还原gaussdb=> \i /home/omm/backup/MPPDB_backup.sqlSETSETgsql:/home/omm/backup/MPPDB_backup.sql:12: ERROR: Database "db1" is being accessed by other users. You can stop all connections by command: "clean connection to all force for database XXXX;" or wait for the sessions to end by querying view: "pg_stat_activity".DETAIL: There is 1 other session using the database.gsql:/home/omm/backup/MPPDB_backup.sql:13: ERROR: Database "drs" is being accessed by other users. You can stop all connections by command: "clean connection to all force for database XXXX;" or wait for the sessions to end by querying view: "pg_stat_activity".DETAIL: There are 8 other sessions using the database.gsql:/home/omm/backup/MPPDB_backup.sql:22: ERROR: Permission denied.gsql:/home/omm/backup/MPPDB_backup.sql:23: ERROR: role "drs" cannot be dropped because some objects depend on itDETAIL: privileges for database drsowner of schema drs101 objects in database drsgsql:/home/omm/backup/MPPDB_backup.sql:24: ERROR: Permission denied.gsql:/home/omm/backup/MPPDB_backup.sql:25: ERROR: Permission denied.gsql:/home/omm/backup/MPPDB_backup.sql:26: ERROR: Permission denied.gsql:/home/omm/backup/MPPDB_backup.sql:27: ERROR: current user cannot be droppedgsql:/home/omm/backup/MPPDB_backup.sql:28: ERROR: role "user1" cannot be dropped because some objects depend on itDETAIL: owner of database db1owner of schema user13 objects in database db1gsql:/home/omm/backup/MPPDB_backup.sql:37: ERROR: role "backupUser" already existsgsql:/home/omm/backup/MPPDB_backup.sql:38: ERROR: Permission denied.gsql:/home/omm/backup/MPPDB_backup.sql:39: ERROR: role "drs" already existsALTER ROLEgsql:/home/omm/backup/MPPDB_backup.sql:41: ERROR: role "metricUser" already existsgsql:/home/omm/backup/MPPDB_backup.sql:42: ERROR: Permission denied.gsql:/home/omm/backup/MPPDB_backup.sql:43: ERROR: role "rdsAdmin" already existsgsql:/home/omm/backup/MPPDB_backup.sql:44: ERROR: Permission denied to change privilege of the initial account.gsql:/home/omm/backup/MPPDB_backup.sql:45: ERROR: role "repUser" already existsgsql:/home/omm/backup/MPPDB_backup.sql:46: ERROR: Permission denied.gsql:/home/omm/backup/MPPDB_backup.sql:47: ERROR: role "root" already existsALTER ROLEgsql:/home/omm/backup/MPPDB_backup.sql:49: ERROR: role "user1" already existsALTER ROLEgsql:/home/omm/backup/MPPDB_backup.sql:51: NOTICE: SET "search_path" TO "core" will only take effect after restarting session.ALTER ROLEgsql:/home/omm/backup/MPPDB_backup.sql:52: NOTICE: SET "current_schema" TO "core" will only take effect after restarting session.ALTER ROLEgsql:/home/omm/backup/MPPDB_backup.sql:59: NOTICE: role "root" is already a member of role "gs_role_account_lock"GRANT ROLEgsql:/home/omm/backup/MPPDB_backup.sql:60: NOTICE: role "root" is already a member of role "gs_role_copy_files"GRANT ROLEgsql:/home/omm/backup/MPPDB_backup.sql:61: NOTICE: role "root" is already a member of role "gs_role_pldebugger"GRANT ROLEgsql:/home/omm/backup/MPPDB_backup.sql:62: NOTICE: role "root" is already a member of role "gs_role_replication"GRANT ROLEgsql:/home/omm/backup/MPPDB_backup.sql:63: NOTICE: role "root" is already a member of role "gs_role_signal_backend"GRANT ROLEgsql:/home/omm/backup/MPPDB_backup.sql:64: NOTICE: role "root" is already a member of role "gs_role_tablespace"GRANT ROLEgsql:/home/omm/backup/MPPDB_backup.sql:73: ERROR: database "db1" already existsREVOKEREVOKEGRANTGRANTGRANTgsql:/home/omm/backup/MPPDB_backup.sql:79: ERROR: database "drs" already existsREVOKEREVOKEGRANTGRANTGRANTGRANTREVOKEREVOKEGRANTGRANTGRANTGRANTGRANTGRANTREVOKEREVOKEGRANTGRANT作者：薛双奇

 1.密码安全策略   用户密码存储在系统表 pg_authid 中，为防止用户密码泄露，GaussDB对用户密码进行加密存储， 所采用的加密算法由配置参数 password_encryption_type 决定。 •当参数password_encryption_type设置为0时，表示采用MD5方式对密码加密。     MD5加密算法安全性低，存在安全风险，不建议使用。 •当参数password_encryption_type设置为1时，表示采用sha256和MD5方式对密码加密。     MD5加密算法安全性低，存在安全风险，不建议使用。 •当参数password_encryption_type设置为2时，表示采用sha256方式对密码加密，为默认配置。 •当参数password_encryption_type设置为3时，表示采用sm3方式对密码加密。 2.查看已配置的加密算法。  gaussdb=# SHOW password_encryption_type;  password_encryption_type --------------------------  2 (1 row) 3.修改密码加密算法。  --0/1都不安全。 gs_guc reload -Z datanode -N all -I all -c "password_encryption_type=2" 4.账户密码的复杂度及长度要求如下  ◾包含大写字母（A-Z）的最少个数（根据GUC参数password_min_uppercase配置）。 ◾包含小写字母（a-z）的最少个数（根据GUC参数password_min_lowercase配置）。 ◾包含数字（0-9）的最少个数（根据GUC参数password_min_digital配置）。 ◾包含特殊字符的最少个数（根据GUC参数password_min_special配置，特殊字符的列表请参见表1）。 ◾密码的最小长度（根据GUC参数password_min_length配置）。 ◾密码的最大长度（根据GUC参数password_max_length配置）。 5.关于若口令的说明。  ◾弱口令指的是强度较低，容易被破解的密码，对于不同的用户或群体，弱口令的定义可能会有所区别，     用户需自己添加定制化的弱口令。 ◾弱口令字典中的口令存放在 gs_global_config 系统表中，当创建用户、修改用户需要设置密码时，     将会把用户设置口令和弱口令字典中存放的口令进行对比，如果命中，则会提示用户该口令为弱口令，设置密码失败。 ◾弱口令字典默认为空，用户通过以下语法可以对弱口令字典进行增加和删除 --示例如下： CREATE WEAK PASSWORD DICTIONARY WITH VALUES ('oracle'), ('mysql123'),('gaussdb001'); DROP WEAK PASSWORD DICTIONARY;   --由此可见，我们可以通过创建弱口令字典来加强密码的管理。不让设置太简单容易被猜到的密码。 6.密码重用问题   不可重用天数默认值为60天，不可重用次数默认值是0。这两个参数值越大越安全 --查看已配置的参数。 gaussdb=# SHOW password_reuse_time;  password_reuse_time ---------------------  60 (1 row)   密码过期后，60天以内不能设置和以前相同的密码。 不建议设置为0，即使需要设置也要将所有数据库节点中的password_reuse_time都设置为0才能生效。   数据库用户的密码都有密码有效期（password_effect_time）， 当达到密码到期提醒天数（password_notify_time）时， 系统会在用户登录数据库时提示用户修改密码。     gs_guc reload -Z datanode -N all -I all -c "password_reuse_time=60"   --0表示不能重用。每次设置必须不同。 gaussdb=# SHOW password_reuse_max;  password_reuse_max --------------------  0 (1 row)   --修改密码可以重用的次数。 gs_guc reload -Z datanode -N all -I all -c "password_reuse_max = 0"  7.密码有效期   gaussdb=# SHOW password_effect_time;  password_effect_time ----------------------  90 (1 row) --设置密码有效期。 gs_guc reload -Z datanode -N all -I all -c "password_effect_time = 90"   这里需要注意账号(用户)有效期和密码有效期可以不同。从两个不同的维度进行约束。 gaussdb=# SHOW password_notify_time;  password_notify_time ----------------------  7 (1 row)   --当达到密码到期提醒天数:过期前一个礼拜通知。 gs_guc reload -Z datanode -N all -I all -c "password_notify_time = 7"  8.修改密码。  gaussdb=# ALTER USER user1 IDENTIFIED BY 'NewPasswd' REPLACE 'OldPasswd'; ALTER ROLE   gaussdb=# ALTER USER joe IDENTIFIED BY "********"; ALTER ROLE

 1. 示例查询 1.在PG_TABLES系统表中查看public schema中包含的所有表。  SELECT distinct(tablename) FROM pg_tables WHERE SCHEMANAME = 'public';  2.通过PG_USER可以查看数据库中所有用户的列表，还可以查看用户ID（USESYSID）和用户权限。  SELECT * FROM pg_user;  3.通过视图PG_STAT_ACTIVITY可以查看正在运行的查询语句。 a.当此参数为on时，数据库系统才会收集当前活动查询的运行信息。  SET track_activities = on; b.查看正在运行的查询语句。以查看正在运行的查询语句所连接的数据库名、执行查询的用户、查询状态及查询对应的PID。  SELECT datname, usename, state,pid FROM pg_stat_activity; 如果state字段显示为idle，则表明此连接处于空闲，等待用户输入命令。 c.若需要取消运行时间过长的查询，通过PG_TERMINATE_BACKEND函数，根据线程ID结束会话。  SELECT PG_TERMINATE_BACKEND(139834759993104); 1 显示类似如下信息，表示结束会话成功。  PG_TERMINATE_BACKEND ----------------------  t (1 row) 显示类似如下信息，表示用户执行了结束当前会话的操作。  FATAL:  terminating connection due to administrator command FATAL:  terminating connection due to administrator command The connection to the server was lost. Attempting reset: Succeeded. gsql客户端使用PG_TERMINATE_BACKEND函数结束当前会话后台线程时，客户端不会退出而是自动重连。即还会返回“The connection to the server was lost. Attempting reset: Succeeded.”  2. 系统表和系统视图概述 一般非管理员无权查看系统表和视图，用户应该禁止对系统表进行增删改等操作，人为对系统表的修改或破坏可能会导致系统各种异常情况甚至集群不可用。  3. 常见系统表 1. PG_ATTRDEF PG_ATTRDEF系统表存储列的默认值  2. PG_ATTRIBUTE PG_ATTRIBUTE系统表存储关于表字段的信息。  3. PG_AUTH_MEMBERS PG_AUTH_MEMBERS系统表存储显示角色之间的成员关系。  4. PG_CLASS PG_CLASS系统表存储数据库对象信息及其之间的关系。  5. PG_CONSTRAINT PG_CONSTRAINT系统表存储表上的检查约束、主键、唯一约束和外键约束。  6. PG_DATABASE PG_DATABASE系统表存储关于可用数据库的信息。  7. PG_DEFAULT_ACL PG_DEFAULT_ACL系统表存储为新建对象设置的初始权限。  8. PG_EXTENSION PG_EXTENSION系统表存储关于所安装扩展的信息。  9. PG_EXTENSION_DATA_SOURCE PG_EXTENSION_DATA_SOURCE系统表存储外部数据源对象的信息。  10. PG_FOREIGN_TABLE PG_FOREIGN_TABLE系统表存储外部表的辅助信息。  11. PG_INDEX PG_INDEX系统表存储索引的一部分信息，其他的信息大多数在PG_CLASS中。  12. PG_INHERITS PG_INHERITS系统表记录关于表继承层次的信息。数据库里每个直接的子系表都有一条记录。间接的继承可以通过追溯记录链来判断。  13. PG_JOB PG_JOB系统表存储用户创建的定时任务的任务详细信息，定时任务线程定时轮询pg_job系统表中的时间，当任务到期会触发任务的执行，并更新pg_job表中的任务状态。该系统表属于Shared Relation，所有创建的job记录对所有数据库可见。  14. PG_JOB_PROC PG_JOB_PROC系统表对应PG_JOB表中每个任务的作业内容（包括：PL/SQL代码块、匿名块）。将存储过程信息独立出来，是因为Oracle中这个字段是varchar(4000)的，如果放到PG_JOB中，被加载到共享内存的时候，会占用不必要的空间，所以在使用的时候再进行查询获取。  15. PG_NAMESPACE PG_NAMESPACE系统表存储名字空间，即存储schema相关的信息。  16. PG_PARTITION PG_PARTITION系统表存储数据库内所有分区表(partitioned table)、分区(table partition)、分区上toast表和分区索引(index partition)四类对象的信息。分区表索引(partitioned index)的信息不在PG_PARTITION系统表中保存。  17. PG_PROC PG_PROC系统表存储函数或过程的信息。  18. PG_RESOURCE_POOL PG_RESOURCE_POOL系统表提供了数据库资源池的信息。  19. PG_STATISTIC PG_STATISTIC系统表存储有关该数据库中表和索引列的统计数据。需要有系统管理员权限才可以访问此系统表。  20. PG_TABLESPACE PG_TABLESPACE系统表存储表空间信息。  21. PG_TRIGGER PG_TRIGGER系统表存储触发器信息。  22. PG_TYPE PG_TYPE系统表存储数据类型的相关信息。  23. PG_USER_STATUS PG_USER_STATUS系统表提供了访问数据库用户的状态。需要有系统管理员权限才可以访问此系统表。  24. PGXC_CLASS PGXC_CLASS系统表存储每张表的复制或分布信息。  25. PGXC_GROUP PGXC_GROUP系统表存储节点组信息。  26. PGXC_NODE PGXC_NODE系统表存储集群节点信息。 

 什么是数据库 数据库是按照数据结构来组织、存储和管理数据的仓库，用户可以通过数据库管理系统对存储的数据进行增删改查操作。  数据库实际上是一个文件集合，本质就是一个文件系统，以文件的方式，将数据保存在电脑上。  什么是数据库管理系统 数据库管理系统(Database Management System)是一种操纵和管理数据库的大型软件，是用于建立、使用和维护数据库，简称DBMS。它对数据库进行统一的管理和控制，以保证数据库的安全性和完整性。  数据库、数据库管理系统、数据库管理工具之间的关系 数据库是存储和管理数据的仓库；而这个“数据库”是理论上的 要在计算机上实现存储和管理数据的操作靠的是数据库管理系统，MySQL就是其中一款 SQL是我们用来和数据库管理系统对话的语言 Workbench是MySQL的官方数据库管理工具，能让对数据库管理系统的操作更简单。 为什么使用数据库 从数据存储方式比较  优点：  相比内存，数据库中的数据可以永久保存 相比文件（Excel），海量数据存储时，提供不错的查询效率 缺点 ：占用资源(重型武器) ，有些数据库需要付费  使用数据库可以高效且条理分明地存储数据，它使人们能够更加迅速和方便地管理数据，主要体现在以下几个方面。  1、数据库可以结构化存储大量的数据信息，方便用户进行有效的检索和访问。 数据库可以对数据进行分类保存，并且能够提供快速的查询。例如，我们平时使用百度搜索内容时，百度也是基于数据库和数据分类技术来达到快速搜索的目的。  2、数据库可以有效地保持数据信息的一致性、完整性、降低数据冗余。 可以很好地保证数据有效、不被破坏，而且数据库自身有避免重复数据的功能，以此来降低数据的冗余。  3、数据库可以满足应用的共享和安全方面的要求，把数据放在数据库中在很多情况下也是出于安全的考虑。 例如，如果把所有员工信息和工资数据都放在磁盘文件上，则工资的保密性就无从谈起。如果把员工信息和工资数据放在数据库中，就可以只允许查询和修改员工信息，而工资信息只允许指定人（如财务人员）查看，从而保证数据的安全性。  4、数据库技术能够方便智能化地分析，产生新的有用信息。 例如，超市中把物品销售信息保存在数据库中，每个月销售情况的排名决定了下半月的进货数量。数据库查询的结果实际上产生了新的数据信息。 

在GaussDB中，database是对业务的物理隔离，不同database的之间的对象不能相互访问。比如在databaseA中无法访问databse B中的对象。因此登录集群的时候必须显示指定要连接的databse。  在GaussDB中创建database时，需要重点关注字符集编码(ENCODING)和兼容性(DBCOMPATIBILITY)两个配置项。ENCODING指明了数据库存储的数据的编码格式，为了适应全球化，创建DATABASE的时候建议使用UTF-8编码。DBCOMPATIBILITY 指明了DATABASE的兼容性选项，GaussDB支持Oracle、Teradata和MySQL三种兼容模式，分别兼容Oracle、Teradata和MySQL语法；若不指定DBCOMPATIBILITY，则默认为ORA。需要注意的是, 数据库一旦创建，这两个属性就不能修改，甚至语法层就没有提供修改这两个属性的接口  SCHEMA 在GaussDB(DWS)中，schema是DATABASE下一个特殊的对象，实现对数据库对象的逻辑隔离，从功能上类似于一些编程语言中namespace的概念。同一个schema下，不能存在同名的数据库对象；但是不同scheam下的对象名可以重复。  SEARCHPATH search_path又称之为模式搜索路径，本身是一个guc参数。对于未定义schema的对象，会根据search_path的配置赋予默认的schema或者默认的schema搜索范围  1）创建对象时，会在search_path指定的schema列表中的第一个schema下创建对象  USER 查询对象时，如果对象没有显式指明schema，GaussDB(DWS)会按照search_path中指明的schema列表，顺序查找指定名称的对象。如果遍历完所有的schema都没有查找到同名对象，数据库会直接报错。  系统表 pg_users pg_database pg_tables pg_tablespace pg_statistic  在PG_TABLES系统表中查看public Schema中包含的前缀为search_table的表 gaussdb=#   SELECT distinct(tablename) FROM pg_tables WHERE SCHEMANAME = 'public' AND TABLENAME LIKE 'search_table%';  查看和停止正在运行的查询语句 通过视图PG_STAT_ACTIVITY可以查看正在运行的查询语句。方法如下：  设置参数track_activities为on。  SET track_activities = on; 当此参数为on时，数据库系统才会收集当前活动查询的运行信息。  查看正在运行的查询语句。以查看正在运行的查询语句所连接的数据库名、执行查询的用户、查询状态及查询对应的PID为例： SELECT datname, usename, state,pid FROM pg_stat_activity; 如果state字段显示为idle，则表明此连接处于空闲，等待用户输入命令。 如果仅需要查看非空闲的查询语句，则使用如下命令查看： SELECT datname, usename, state, pid FROM pg_stat_activity WHERE state != 'idle'; 若需要取消运行时间过长的查询，通过PG_TERMINATE_BACKEND函数，根据线程ID（即2中查询结果的pid字段）结束会话。 SELECT PG_TERMINATE_BACKEND(12800); 查看最耗时SQL SELECT current_timestamp - query_start AS runtime, datname, usename, query FROM pg_stat_activity where state != 'idle' ORDER BY 1 desc;  使用gsql的\d+命令查询表的属性 gaussdb=# \d+ customer_t1;  执行如下命令将搜索路径设置为myschema、public，首先搜索myschema。 gaussdb=#              SET SEARCH_PATH TO myschema, public; 撤销PUBLIC在public模式下创建对象的权限，下面语句中第一个“public”是模式，第二个“PUBLIC”指的是所有角色。 gaussdb=#              REVOKE CREATE ON SCHEMA public FROM PUBLIC; 执行如下命令查询系统和用户定义的所有索引。 gaussdb=#              SELECT RELNAME FROM PG_CLASS WHERE RELKIND='i';  更新统计信息 ANALYZE tablename;                        --更新单个表的统计信息  ANALYZE;                                  --更新全库的统计信息   表的选择 1.行存储 默认创建表的类型。数据按行进行存储，即一行数据是连续存储。适用于对数据需要经常更新的场景  gaussdb=# CREATE TABLE customer_t1 (   state_ID   CHAR(2),   state_NAME VARCHAR2(40),   area_ID    NUMBER );  --删除表 gaussdb=# DROP TABLE customer_t1; 2列存储 数据按列进行存储，即一列所有数据是连续存储的。单列查询IO小，比行存表占用更少的存储空间。适合数据批量插入、更新较少和以查询为主统计分析类的场景。列存表不适合点查询。  gaussdb=# CREATE TABLE customer_t2 (   state_ID   CHAR(2),   state_NAME VARCHAR2(40),   area_ID    NUMBER ) WITH (ORIENTATION = COLUMN);  --删除表 gaussdb=# DROP TABLE customer_t2;   3行存表和列存表的选择 更新频繁程度 数据如果频繁更新，选择行存表。  插入频繁程度 频繁的少量插入，选择行存表。一次插入大批量数据，选择列存表。  表的列数 表的列数很多，选择列存表。  查询的列数 如果每次查询时，只涉及了表的少数（<50%总列数）几个列，选择列存表。  压缩率 列存表比行存表压缩率高。但高压缩率会消耗更多的CPU资源。 

大家现在都在用哪些数据库？一起来分享一下当前最热门的数据库以及使用他们的原因？

select '20241204'||lpad(row_number()over(partition by '1' order by '1'),10,0) as a  from test1;'20241204'||lpad(row_number()over(partition by '1' order by '1'),10,0)生成值类似日期加序列，是否有更高效率的替代方式？

高斯数据库安装直接就是分布式的库吗？有没有单机版本的。

趋势预测功能模块主要实现基于历史时序数据预测未来时序变化趋势。该模块框架解耦，可以实现不同预测算法的灵活替换，并且该模块功能可以实现不同特征时序的算法自动选择，支持线性特征时序预测LR回归算法和非线性特征预测ARIMA算法。目前该模块可以覆盖线性时序、非线性时序和周期时序的准确预测。  时序预测模块和异常检测模块作为自监控的两个核心组件，通过采集程序获取数据后，在检测器阶段进行时序预测及异常检测，数据流转的流程如下：   数据获取和数据分析是一个相对于数据库环境独立的工具组件，包括Agent、检测器等子模块。其中Agent是部署在数据库主机环境上的，用于采集数据库中的性能指标，并通过网络，将其传送给远端检测器模块，远端检测器模块负责对采集到的性能指标数据进行收集、存储与检测。  Agent模块分为三个子模块，分别是Source、Channel以及Sink，各个组件之间可插拔、可扩展。其中数据收集端Source，用于直接监控数据库系统，并从数据库系统中采集信息；数据缓存器Channel，可以理解为缓存区，用来保存Source处捕获的数据，是一个FIFO的队列。Source捕获的数据会Push到Channel中，而后Sink组件消费由Source产生的数据。Channel缓存在内存中，为了防止OOM，具有容量上限，当超过容量上限时，过多的元素会被禁止放入队列。数据处理及外发Sink，负责从Channel消费数据，然后将数据从Channel中清除，以指定数据格式进行外发，将数据存储到外部存储系统。在数据从Channel端到Sink端的过程中，加入了JSON wrapper 和flow controller两个中间件，分别对应了JSON格式封装、流量控制功能。其中，由于Agent架构对限流功能天然友好，Channel充当缓存功能，实现漏桶算法进行限流。Sink上支持类似这种pipeline模式，以便后续对上传过程进行控制，提供可扩展能力。  从Agent发送到检测器的网络通信协议默认为https，默认证书在部署时由部署脚本生成。  检测器主要包括三个部分，分别是存储模块、时序预测模块、异常检测模块。本章节重点描述时序预测模块，异常检测模块在后续单独描述。  时序预测模块的执行流程如下：   时序预测模块提供了两种基本的预测模型，分别是线性模型和深度学习模型。另外系统给用户指定了三种预测模式，分别是decompose、ensemble、hybrid。Decompose代表分解预测模式，ensemble代表整体预测模式，hybrid代表混合预测模式，算法步骤为：  1. 首先获取训练数据，算法会判断数据的线性相关系数是否大于指定的阈值（系统默认0.9），如果大于阈值，则会选择线性预测模型（linear regressor），否则会选择循环神经网络预测模型（RNN）。  2. 如果用户选择decompose预测模式，系统会调用是时序分解算法将序列分解成周期项、趋势项、残差项，然后调用模型对趋势项进行训练，得到趋势的预测结果。对于周期不需要预测，可以根据周期性递推得到未来周期项。对于残差，系统基于统计学原理，取25%和75%分位作为残差项的上下限。最终预测结果为趋势项、周期项和残差项的和。  3. 如果用户选择ensemble预测模式，系统会直接对数据进行训练，然后进行预测，得到预测结果和模型评分。  4. 如果用户选择的hybrid模式，系统会串行的执行decompose和ensemble两种预测模式流程，同时根据它们最终模型评分的高低选择最优的预测结果。如果用户真实采集到的信息与时序预测的结果出现较大偏差（大于预设阈值），则认为当前情况出现异常，执行报警逻辑。 

 GaussDB提供500+指标的智能监测，通过对数据库指标、操作系统指标和运行日志的采集，拉取采集数据至时序数据库存储，便于后续进行异常侦测和问题定位。为了快速支撑各粒度的多维度指标采集，部署多个采集程序，例如数据库指标采集程序openGauss-exporter、操作系统指标采集程序node-exporter、本地执行采集程序cmd_exporter以及数据二次处理程序reprocessing-exporter等。  GaussDB智能监测程序采取服务化方式部署，通过RPC通道（默认Https协议，且校验数据库用户名密码，不存在空密码访问情况）实现，可以获取数据库的即时信息，也可以向数据库下发执行动作（需要用户提供的用户具备执行权限，具体数据库用户由用户指定）。时序数据处理支持多种时序库存，例如普罗米修斯、Influxdb等，尽管对接接口协议不同，但实现方式类似。后面以普罗米修斯时序库和采集程序进行举例，说明智能监控的方法和实现方案。下图为智能监测方案的执行时序图。   数据采集的实现过程：  （1）Exporter 的数据采集原理如上图所示，采集过程是pull的形式，即由Prometheus 主动发起数据刮取（scrape）请求，而后exporter再想被监控服务（可以是数据库服务、Linux等）发起查询请求，由其通过http(s) 协议展示给Prometheus；  （2）通过Prometheus 框架，按照Prometheus协议即可实现对应的exporter，该实现过程类似一个插件，通过Prometheus 提供的SDK（如prometheus-client库）即可完成开发过程；  （3）所采集的指标项通过用户给定的配置文件解析获得，不需要在exporter中固化；  （4）实现的exporter主要有两个，一个是openGauss-exporter，用于监控数据库实例，从其上面抓取数据；另一个是reprocessing-exporter, 用于对Prometheus已经采集到的数据进行二次加工。两个exporter是各自独立的进程。  （5）openGauss-exporter 是需要输入待监控数据库的登录密码的，该密码通过shell命令的配置参数输入。其中，在命令行中通过内存覆盖的技术擦除了命令行中的密码，避免了通过 ps –ux 等泄漏密码的可能。  （6）为进一步保障采集数据的安全性，exporter采集的数据源由用户手动配置，默认配置文件不涉及敏感数据，仅采集数据库性能相关指标；在网络协议方面，默认支持采用https协议，用户显性给定证书文件路径，并在Prometheus-server侧进行配置exporter采集工具和用户不涉及交互，所有SQL执行都有程序本身实现，不涉及SQL注入问题。  数据采集存储在时序数据库后，将进入趋势预测和异常检测模块，便于客户提前发现潜在问题或者实时发现系统中的异常问题。 

在数据库自治运维技术领域，主要分为两条技术路线。其一是以Oracle为主的老牌数据库厂商，构建运维及生命周期管理统一逃课，实现大规模的数据库智能化管理能力；对用户通过运维工具指导业务快速升级和排障，对业务通过内置的优化诊断套件和多维度报表，快速定位性能瓶颈问题和实现SQL的快速优化。这种方案在单一集群或小规模集群是高效的，通过DBA能力复制，可快速完成运维技术的应用。另一种是以新兴云厂商为主，构建基于云化设施和环境的自治运维技术。尽管各家的技术不近统一，主体思路是一致的，即尽可能通过一套运维管理系统，纳管云化多套环境，通过机器学习技术和海量数据，训练高效诊断和优化模型，形成标准化运维套路。  GaussDB基于机器学习技术和云上海量数据信息，构建领先的自治运维管理系统，通过成熟算法实现负载感知、环境感知和数据感知，为数据库提供自监控、自诊断、自调优、自安全的能力，为客户和DBA提供极佳的运维管理体验。   上图为GaussDB的自治运维系统整体框图。数据采集层实现多维指标的数据采集，采集频率根据内容不同可分为秒级采集和分钟级采集。其中秒级采集包括操作系统资源信息采集和数据库实例信息采集，例如操作系统层面CPU、内存、IO读写、网络资源信息采集，数据库实例状态、数据库内关键指标（内存、连接数、TPS、QPS、读写频率等）；分钟级采集包括审计日志采集、数据库日志采集和全量SQL流水采集等。  自治运维平台提供采集程序（Agent进程），可部署在数据库服务侧或者远端，连接数据库实例或所在服务器，采集上述指标；若客户系统配置普罗米修斯进行信息采集，可实现相应的exporter，在其中内置数据库多维度指标采集方法以及数据清理方案，实现与普罗米修斯平台对接。  数据库采集端程序需要部署在同数据库进程所在物理节点时，若数据库为多节点集群环境，每个物理节点可部署一个Agent进程采集端（或者普罗米修斯采集端）。数据库采集端程序通常占用资源很少，通过配置文件可以制定不同指标采集频率，以免占用资源影响数据库业务正常运行。  数据计算层提供数据存储、数据分析及元数据管理能力。其中数据存储用于接收来自数据采集层发生来的数据，存储数据源可以是多种维度或者类型，包括普罗米修斯、时序数据库（OpenTSDB等）、MongoDB、SQLite等，自治运维服务内置对接接口，每个自治服务模块与存储数据源的交互，获取数据并进行分析处理。在企业实际应用时，可根据需要选择不同的存储组件和大数据处理组件，例如普罗米修斯+时序数据库，或者kafka+时序数据库等方案。  在数据计算层除了时序存储数据库外，还可以设计其他存储单元，例如算法模型库和故障规则库。其中算法模型库存储自治管理服务生成的AI模型，例如参数推荐训练模型；在算法模型库中，可以存储传统机器学习（例如监督学习）模型、强化学习模型。故障规则库是记录数据库常见故障案例，将这些案例通过拆解和分析，生成规则引擎。  自治服务层在用户维度，可以分为SQL诊断和调优、自治安全、数据库运维。其中SQL诊断和调优提供多种SQL治理和调优能力，包括慢SQL诊断、SQL表现评估、智能索引推荐、智能查询重写等服务。自治安全通过AI技术实现敏感信息发觉、SQL注入检测和异常行为分析。数据库运维能力实现在数据库系统、OS系统和数据库集群层面的运维和调优，其中数据库系统服务包括数据库参数智能推荐、智能巡检、数据库分布键推荐和智能业务调度；在操作系统层面，实现慢盘检测和恢复、网络丢包检测；在数据库集群层面，基于故障或者负载需求，提供自动扩缩容、异常节点修复服务。  自治运维服务最终需要通过管控网页界面形式对外呈现，方便用户直观感受运维管理带来的效果。在展示界面方面，多指标结合AI趋势预测，可给出后续时段的数据走向。同时为方便用户系统观察集群状态，提供健康指数报告和详细综合报告。健康指数报告给出当前系统的健康评分等级，默认80分以上属于运行健康状况，小于60分则存在严重隐患，急需修复。综合报告详细描述系统各维度信息，包括集群状态、负载运行情况、常见数据库指标项信息。 

数据库智能化发展史 云原生为迎接智能化提供了基础条件，智能化是GaussDB的新的牵引方向，两者相辅相成，互相促进。在智能化出现之前，数据库的运维管理主要依赖分层解耦、化繁为简方式来治理，通过人工服务对单点的业务进行管理。但在云化环境中，一个Region纳管上万实例，仅靠人工很难满足业务诉求，这就促成智能与数据库在云原生的架构和应用中释放的新的研发方向。  GaussDB基于智能化（AI）技术，打造AI4DB和DB4AI两大技术高地，重构数据库内核核心组件，提升数据库管理和优化技术，满足数据库科学家对普惠AI的诉求。AI4DB技术利用机器学习，基于海量运行期数据及负载数据，形成智能解决方案，自动化处理各项任务，加速运维和诊断优化效率提升。DB4AI通过数据库使能AI，满足数据科学家在数据治理方面的诉求，仅通过简易SQL调用，即刻完成机器学习算法的训练和推荐，实现人人会AI，人人用AI的普惠应用。  如上图所示，GaussDB AI4DB领域包含两个方面的核心子系统：自治运维系统及智能优化器（ABO）。其中自治运维系统提供用户和DBA进行数据库系统的智能化运维管理能力，包括自监控、自诊断、自调优等方面端到端的运维管理能力，主要目标是提升系统的运维诊断效率，让数据库系统更高效和可靠。智能优化器是将AI技术嵌入到数据库内核优化器引擎，实现智能基数估计、智能计划管理和智能代价模型等功能，提升查询语句生成计划的准确性和提供查询语句的执行效率。  GaussDB DB4AI领域指在数据库内实现机器学习引擎，即库内AI引擎。通过在数据库内置常用机器学习算法，把AI算法作为执行器中的执行算子在语句执行中实现，对外提供训练和推理的简易SQL语法方便用户调用。同时，在数据库内置模型管理能力，用户训练好的模型可以存储在系统表中，方便快速推理调用。在训练数据准备阶段，通过数据集管理能力，分为多个版本来保证数据训练的一致性，便于训练算法的调优。 

 openGauss你计算的表大小，有包含toast表么？ 最近有一个同事问我说“openGauss中pg_relation_size函数在计算表的大小时是否包含了大字段的大小？”，经过思考后，自己觉得表的大小是不包含大字段的大小的，然后通过查看官网的文档说明，该函数含义为指定OID代表的表或者索引所使用的磁盘空间。如果只单独看这条定义，那么还是不清楚是否包含toast表，但是如果你看了数据库对象的其他函数，结合其他函数的解释应该可以得出结论在这里是不包含toast表的大小。即使知道结果了，还是想通过实际操作验证一下openGauss的pg_relation_size函数在计算表大小时未包含toast表大小。关于toast机制在这里就不做详细介绍，有兴趣的同学，可以自行查看相关资料。  准备测试用例 创建测试用例表  create table tbl_blog (id serial primary key,author varchar(50),title varchar(200),content text); 查看表结构  testdb=> \d+ tbl_blog                                                       Table "test.tbl_blog"  Column  |          Type          |                       Modifiers                       | Storage  | Stats target | Description ---------+------------------------+-------------------------------------------------------+----------+--------------+-------------  id      | integer                | not null default nextval('tbl_blog_id_seq'::regclass) | plain    |              |  author  | character varying(50)  |                                                       | extended |              |  title   | character varying(200) |                                                       | extended |              |  content | text                   |                                                       | extended |              | Indexes:     "tbl_blog_pkey" PRIMARY KEY, btree (id) TABLESPACE pg_default Has OIDs: no Options: orientation=row, compression=no 在这里我们可以看到author、title、content的storage列的值为extended，这是大多数toast数据类型的默认设置，表示允许行外存储和压缩，一般会先压缩，如果还是太大，就会行外存储。这里行外存储其实就是指，当行的记录的长度大于了TOAST_TUPLE_THRESHOLD（值为2KB）时，会触发TOAST，把大字段的列数据存储到TOAST表中。  查看tbl_blog关联的toast表的oid  testdb=> select oid,relname,reltoastrelid from pg_class where relname='tbl_blog';   oid  | relname  | reltoastrelid -------+----------+---------------  24608 | tbl_blog |         24612 (1 row) 查询关联的toast表的表名及表数据  --查看toast表名 testdb=# select relname from pg_class where oid = 24612;     relname ----------------  pg_toast_24608 (1 row) 在这里可以看到TOAST表名，其实就是pg_toast+表的oid。  查看toast表的信息  testdb=# select tableoid ,* from pg_toast.pg_toast_24608;  chunk_id | chunk_seq | chunk_data ----------+-----------+------------ (0 rows) --查看TOAST表结构 testdb=> \d+ pg_toast.pg_toast_24608 TOAST table "pg_toast.pg_toast_24608"    Column   |  Type   | Storage ------------+---------+---------  chunk_id   | oid     | plain  chunk_seq  | integer | plain  chunk_data | bytea   |  这里简单的对toast表的字段说明一下  chunk_id：普通表通过TOAST pointer关联到一个被TOAST的列  chunk_seq：同一个chunk_id如果大于TOAST_MAX_CHUNK_SIZE，将被切片存储。这里存储切片后的序号  chunk_data：真实的数据，但是在这里展示的都是二进制值  模拟数据验证 content字段插入少许值 执行命令插入数据  insert into tbl_blog(author,title,content) values('墨竹','推荐Postgresql中一些好用的psql命令','psql客户端工具应该是dba非常频繁使用的的工具。'); 查看表大小和toast表的大小  testdb=# select pg_relation_size(oid) as tb_size,pg_relation_size(reltoastrelid) as toast_size from pg_class where relname='tbl_blog';  tb_size | toast_size ---------+------------     8192 |          0 (1 row) --同样在toast表的数据仍然为空 testdb=# select * from pg_toast.pg_toast_24608;  chunk_id | chunk_seq | chunk_data ----------+-----------+------------ (0 rows) 在上面查询结果可以看到当插入的值比较小时，在toast表未查询到数据。然后我们再查看content列的长度，为46字节。  testdb=> select pg_column_size(id),pg_column_size(author),pg_column_size(title),pg_column_size(content) from tbl_blog;  pg_column_size | pg_column_size | pg_column_size | pg_column_size ----------------+----------------+----------------+----------------               4 |              5 |             35 |             46 (1 row)  content字段插入大量值 执行命令插入数据，在这里省略了大量的数据，自行测试的时候，找一些数据就行。  insert into tbl_blog(author,title,content) values('墨竹','推荐Postgresql中一些好用的psql命令','E.1.1. Overview  PostgreSQL 17 contains many new features and enhancements, including: ....省略大量文字 Add worker type column to pg_stat_subscription (Peter Smith) §'); 查看表大小和toast表的大小  testdb=# select pg_relation_size(oid) as tb_size,pg_relation_size(reltoastrelid) as toast_size from pg_class where relname='tbl_blog';  tb_size | toast_size ---------+------------     8192 |       8192 (1 row) --在这里由于chunk_data太大不方便展示，就截取了一部分 testdb=> select chunk_id,chunk_seq,substring(chunk_data,0,20) from pg_toast.pg_toast_24608;  chunk_id | chunk_seq |                substring ----------+-----------+------------------------------------------     24618 |         0 | \x3a35000000452e312e312e204f007665727669     24618 |         1 | \x219b6c75652066021387926b946a114457696e     24618 |         2 | \x015620ce63113712450475697383ae4380606f     24618 |         3 | \x2204a824e26d616e69e47075443a6f66710973 (4 rows) 当再次插入数据时，表的大小未变化，但是toast表的变为了8KB，说明这个时候已经出发toast机制，将content列的数据存储到toast表。当查看toast表中的数据时，发现已经有数据并且由于插入的太大，对插入的数据进行了切分。最后再来查看一下列的长度，为7286字节，确实是需要切分的。  testdb=# select pg_column_size(id),pg_column_size(author),pg_column_size(title),pg_column_size(content) from tbl_blog;  pg_column_size | pg_column_size | pg_column_size | pg_column_size ----------------+----------------+----------------+----------------               4 |              7 |             45 |             65               4 |              7 |             45 |           7286 (2 rows) 再次插入数据 再次把第2次的数据重新插入一次  insert into tbl_blog(author,title,content) select author,title,content from tbl_blog where id = 2; 查看表大小和toast表的大小  testdb=> select pg_relation_size(oid) as tb_size,pg_relation_size(reltoastrelid) as toast_size from pg_class where relname='tbl_blog';  tb_size | toast_size ---------+------------     8192 |      24576 (1 row) --在这里由于chunk_data太大不方便展示，就截取了一部分 testdb=> select chunk_id,chunk_seq,substring(chunk_data,0,20) from pg_toast.pg_toast_24608;  chunk_id | chunk_seq |                substring ----------+-----------+------------------------------------------     24618 |         0 | \x3a35000000452e312e312e204f007665727669     24618 |         1 | \x219b6c75652066021387926b946a114457696e     24618 |         2 | \x015620ce63113712450475697383ae4380606f     24618 |         3 | \x2204a824e26d616e69e47075443a6f66710973     24620 |         0 | \x3a35000000452e312e312e204f007665727669     24620 |         1 | \x219b6c75652066021387926b946a114457696e     24620 |         2 | \x015620ce63113712450475697383ae4380606f     24620 |         3 | \x2204a824e26d616e69e47075443a6f66710973 (8 rows)  当我们再次对content字段插入大量值时，发现表的大小未变化，但是toast表大小翻了3倍。  查看列的长度  testdb=>  select pg_column_size(id),pg_column_size(author),pg_column_size(title),pg_column_size(content) from tbl_blog;  pg_column_size | pg_column_size | pg_column_size | pg_column_size ----------------+----------------+----------------+----------------               4 |              5 |             35 |             46               4 |              5 |             35 |           7286               4 |              5 |             35 |           7286 (3 rows)  其实通过这三次的插入数据，观察pg_relation_size函数计算表的大小和toast表的大小，其中表的大小一直未变，toast表的大小从0->8192->24576，就可以判断出pg_relation_size函数计算表的大小时是不包含toast表的大小，如果你忽略这点的话，可能导致最终统计的数据不准确。  下面是计算数据库表/索引大小相关的函数。  pg_relation_size(oid) 描述：指定OID代表的表或者索引所使用的磁盘空间。  pg_indexes_size(regclass) 描述：附加到指定表的索引使用的总磁盘空间。  pg_table_size(regclass) 描述：指定的表使用的磁盘空间，不计索引（但是包含TOAST，自由空间映射和可见性映射）  pg_total_relation_size(regclass) 描述：指定的表使用的总磁盘空间，包括所有的索引和TOAST数据 总结 从这个测试实验中，我们就可以很清晰的知道，pg_relation_size函数只统计表对象的大小，未包含toast表大小，因此如果我们需要统计表大小，建议使用pg_total_relation_size函数更精确一点，该函数的统计包括了索引和toast表；另外如果你使用了pg_table_size来统计表大小，需要注意该统计不包含索引，可能需要使用pg_indexes_size来单独计算索引的大小。  参考 https://github.com/digoal/blog/blob/master/201103/20110329_01.md  

Springboot项目集成OpenGauss使用教程安装 openGauss 数据库：首先，确保你已经在本地或服务器上安装并配置了 openGauss 数据库。你可以参考 openGauss 官方文档来完成安装和配置：官网：openGauss 官网安装文档：openGauss 安装手册配置 openGauss JDBC 驱动：对于 Maven 用户： <!-- openGauss JDBC 驱动 --> org.postgresql postgresql 42.5.0 <!-- 请使用最新版本 --> 对于 Gradle 用户：dependencies { implementation 'org.postgresql:postgresql:42.5.0' // 请使用最新版本}Spring Boot 通过 JDBC 驱动与数据库进行交互，因此，你需要在 pom.xml 或 build.gradle 文件中添加 openGauss JDBC 驱动依赖。目前，openGauss 是兼容 PostgreSQL 的，所以可以使用 PostgreSQL 的 JDBC 驱动来连接 openGauss。配置 application.properties 或 application.yml： 在 application.properties 或 application.yml 文件中配置数据库连接信息。openGauss 和 PostgreSQL 使用相似的连接 URL 格式。使用 application.properties 配置：spring.datasource.url=jdbc:postgresql://:/spring.datasource.username=spring.datasource.password=spring.datasource.driver-class-name=org.postgresql.Driverspring.datasource.jpa.database-platform=org.hibernate.dialect.PostgreSQL95Dialectspring.jpa.hibernate.ddl-auto=updatespring.jpa.show-sql=truespring.jpa.properties.hibernate.format_sql=true解释：使用 application.yml 配置：spring: datasource: url: jdbc:postgresql://<host>:<port>/<database> username: <your-username> password: <your-password> driver-class-name: org.postgresql.Driver jpa: database-platform: org.hibernate.dialect.PostgreSQL95Dialect hibernate: ddl-auto: update show-sql: true properties: hibernate: format_sql: true：openGauss 数据库的主机地址。：openGauss 数据库的端口，默认是 5432。：要连接的数据库名。：连接数据库的用户名。：连接数据库的密码。测试连接： 确保你的 Spring Boot 应用能够成功连接到 openGauss 数据库。你可以创建一个简单的 Spring Data JPA 实体类，并在 @SpringBootApplication 中进行数据库操作，确保连接是否成功。创建 Entity 类与 Repository： 创建 JPA 实体类（Entity）和仓库（Repository）来操作 openGauss 数据库。@Entitypublic class User { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) private Long id; private String name; private String email; // getters and setters}public interface UserRepository extends JpaRepository<User, Long> { List<User> findByName(String name);}在业务逻辑中使用 Repository： 可以通过 @Autowired 注解将 UserRepository 注入到你的服务类中，并进行数据库操作。@Servicepublic class UserService { @Autowired private UserRepository userRepository; public List<User> getUsersByName(String name) { return userRepository.findByName(name); }}启动项目并测试： 启动你的 Spring Boot 应用，检查数据库连接是否正常，执行数据库操作并查看结果。常见问题和解决方法：连接失败：确认 openGauss 数据库已经启动，且你的数据库地址、端口、用户名和密码正确。如果连接时出现 SSL 错误，可以尝试禁用 SSL：在 application.properties 中加入：spring.datasource.url=jdbc:postgresql://:/?sslmode=disable JPA 查询不生效：确保配置了正确的 JPA 方言。openGauss 基于 PostgreSQL，因此使用 org.hibernate.dialect.PostgreSQL95Dialect。性能问题：根据实际情况优化连接池配置，调整连接池的大小等参数，以应对高并发请求。