¿Cómo implementa GaussDB(DWS) el aislamiento de la carga de trabajo?

Aislamiento de la carga de trabajo

En GaussDB(DWS), puede aislar cargas de trabajo con configuraciones de bases de datos y esquemas. Sus diferencias son las siguientes:

• Las bases de datos no pueden comunicarse entre sí y compartir muy pocos recursos. Sus conexiones y permisos pueden ser aislados.
• Los esquemas comparten más recursos que las bases de datos. Los permisos de usuario en esquemas y objetos subordinados se pueden configurar de forma flexible mediante la sintaxis GRANT y REVOKE.

Base de datos

Una base de datos es una colección física de objetos de base de datos. Los recursos de las bases de datos diferentes están completamente aislados (excepto algunos objetos compartidos). Las bases de datos se utilizan para aislar cargas de trabajo. Los objetos de diferentes bases de datos no pueden tener acceso entre sí. Por ejemplo, no se puede tener acceso a los objetos de la base de datos B en la base de datos A. Por lo tanto, al iniciar sesión en un clúster, debe conectarse a la base de datos especificada.

Esquema

En una base de datos, los objetos de base de datos se dividen y se aíslan lógicamente en función de los esquemas.

Con la gestión de permisos, puede acceder y operar objetos en diferentes esquemas en la misma sesión. Los esquemas contienen objetos a los que las aplicaciones pueden acceder, como tablas, índices, datos de diversos tipos, funciones y operadores.

Los objetos de base de datos con el mismo nombre no pueden existir en el mismo esquema, pero los nombres de objetos en diferentes esquemas pueden ser los mismos.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

gaussdb=> CREATE SCHEMA myschema;
CREATE SCHEMA
gaussdb=> CREATE SCHEMA myschema_1;
CREATE SCHEMA

gaussdb=> CREATE TABLE myschema.t1(a int, b int) DISTRIBUTE BY HASH(b);
CREATE TABLE
gaussdb=> CREATE TABLE myschema.t1(a int, b int) DISTRIBUTE BY HASH(b);
ERROR:  relation "t1" already exists
gaussdb=> CREATE TABLE myschema_1.t1(a int, b int) DISTRIBUTE BY HASH(b);
CREATE TABLE

Los esquemas dividen lógicamente las cargas de trabajo. Estas cargas de trabajo son interdependientes con los esquemas. Por lo tanto, si un esquema contiene objetos, eliminarlo causará errores con la información de dependencia mostrada.

1
2
3
4

gaussdb=> DROP SCHEMA myschema_1;
ERROR: cannot drop schema myschema_1 because other objects depend on it 
Detail: table myschema_1.t1 depends on schema myschema_1 
Hint: Use DROP ... CASCADE to drop the dependent objects too.

Cuando se elimina un esquema, se utiliza la opción CASCADE para eliminar los objetos que dependen del esquema.

1
2
3

gaussdb=> DROP SCHEMA myschema_1 CASCADE;
NOTICE:  drop cascades to table myschema_1.t1
gaussdb=> DROP SCHEMA

Usuario/Rol

Los usuarios y los roles se utilizan para implementar el control de permisos en el servidor de base de datos (clúster). Son los propietarios y ejecutores de las cargas de trabajo de clúster y gestionan todos los permisos de objetos en clústeres. Un rol no está limitado a una base de datos específica. Sin embargo, cuando inicia sesión en el clúster, debe especificar explícitamente un nombre de usuario para garantizar la transparencia de la operación. Los permisos de un usuario para una base de datos se pueden especificar mediante la gestión de permisos.

Un usuario es el sujeto de permisos. La gestión de permisos es en realidad el proceso de decidir si un usuario puede realizar operaciones en objetos de base de datos.

Gestión de permisos

La gestión de permisos en GaussDB(DWS) se divide en tres categorías:

• Permiso del sistema

  Los permisos del sistema también se denominan atributos de usuario, incluidos SYSADMIN, CREATEDB, CREATEROLE, AUDITADMIN y LOGIN.

  Solo se pueden especificar mediante la sintaxis CREATE ROLE o ALTER ROLE. El permiso SYSADMIN se puede conceder y revocar usando GRANT ALL PRIVILEGE y REVOKE ALL PRIVILEGE respectivamente. Los permisos del sistema no pueden ser heredados por un usuario de un rol y no se pueden conceder mediante PUBLIC.

• Permisos

  Otorgar los permisos de un rol o usuario a uno o más roles o usuarios. En este caso, cada rol o usuario puede considerarse como un conjunto de uno o más permisos de base de datos.

  Si se especifica WITH ADMIN OPTION, el miembro puede a su vez conceder permisos en el rol a otros y revocar permisos en el rol también. Si se cambia o revoca un rol o usuario a quien se conceden ciertos permisos, los permisos heredados del rol o usuario también cambian.

  Un administrador de base de datos puede concederles permisos y revocarlos de cualquier rol o usuario. Los roles que tienen permiso CREATEROLE pueden conceder o revocar la membresía en cualquier rol que no sea un administrador.

• Permiso de objeto

  Los permisos de un objeto de base de datos (tabla, vista, columna, base de datos, función, esquema o espacio de tabla) se pueden conceder a un rol o usuario. El comando GRANT se puede utilizar para conceder permisos a un usuario o rol. Estos permisos concedidos se agregan a los existentes.

Ejemplo de aislamiento de esquema

Ejemplo 1:

De forma predeterminada, el propietario de un esquema tiene todos los permisos sobre los objetos del esquema, incluido el permiso de eliminación. El propietario de una base de datos tiene todos los permisos sobre los objetos de la base de datos, incluido el permiso de eliminación. Por lo tanto, se recomienda controlar estrictamente la creación de bases de datos y esquemas. Cree bases de datos y esquemas como administrador y asigne permisos relacionados a los usuarios.

1. Asigne el permiso para crear esquemas en la base de datos testdb al usuario user_1 como usuario dbadmin.

   1 2	testdb=> GRANT CREATE ON DATABASE testdb to user_1; GRANT

2. Cambiar al usuario user_1.

   1 2	testdb=> SET SESSION AUTHORIZATION user_1 PASSWORD '********'; SET

   Cree un esquema denominado myschema_2 en la base de datos testdb como user_1.

   1 2	testdb=> CREATE SCHEMA myschema_2; CREATE SCHEMA

3. Cambiar al administrador dbadmin.

   1 2	testdb=> RESET SESSION AUTHORIZATION; RESET

   Cree table t1 en el esquema myschema_2 como administrador dbadmin.

   1 2	testdb=> CREATE TABLE myschema_2.t1(a int, b int) DISTRIBUTE BY HASH(b); CREATE TABLE

4. Cambiar al usuario user_1.

   1 2	testdb=> SET SESSION AUTHORIZATION user_1 PASSWORD '********'; SET

   Eliminar la tabla t1 creada por el administrador dbadmin en el esquema myschema_2 como usuario user_1.

   1 2	testdb=> drop table myschema_2.t1; DROP TABLE

Ejemplo 2:

Debido al aislamiento lógico de los esquemas, los objetos de base de datos deben verificarse tanto en el nivel de esquema como en el nivel de objeto.

1. Conceda el permiso en la tabla myschema.t1 a user_1.

   1 2	gaussdb=> GRANT SELECT ON TABLE myschema.t1 TO user_1; GRANT

2. Cambiar al usuario user_1.

   1 2	SET SESSION AUTHORIZATION user_1 PASSWORD '********'; SET

   Consultar la tabla myschema.t1.

   1 2 3

   gaussdb=> SELECT * FROM myschema.t1; ERROR: permission denied for schema myschema LINE 1: SELECT * FROM myschema.t1;

3. Cambiar al administrador dbadmin.

   1 2	gaussdb=> RESET SESSION AUTHORIZATION; RESET

   Otorgar el permiso de la tabla myschema.t1 al usuario user_1.

   1 2	gaussdb=> GRANT USAGE ON SCHEMA myschema TO user_1; GRANT

4. Cambiar al usuario user_1.

   1 2	gaussdb=> SET SESSION AUTHORIZATION user_1 PASSWORD '********'; SET

   Consultar la tabla myschema.t1.

   1 2 3 4

   gaussdb=> SELECT * FROM myschema.t1; a | b ---+--- (0 rows)