Arquitectura e implementación de PostgreSQL 9.3

43
PostgreSQL 9.3 Por Alexandra María Cañas Tovar y Bryan Josué Rodríguez Parada IBD115 2013

description

Resumen de la arquitectura interna, de objetos, de consultas, de administración de memoria y del Log de Transacciones de PostgreSQl y algunas concideraciones para implementar BD en él

Transcript of Arquitectura e implementación de PostgreSQL 9.3

Page 1: Arquitectura e implementación de PostgreSQL 9.3

PostgreSQL 9.3

PorAlexandra María Cañas

Tovar yBryan Josué Rodríguez

Parada

IBD115

2013

Page 2: Arquitectura e implementación de PostgreSQL 9.3

DESCRIPCIÓN DE POSTGRESQL

PostgreSQL 9.3 es un sistema de gestión de bases de datos objeto-relacional distribuido bajo la Licencia PostgreSQL:

“El permiso para usar, copiar, modificar y distribuir este software y su documentación para cualquier propósito, sin coste alguno, y sin que

se concede un contrato por escrito…”

Page 3: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA INTERNA

Page 4: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA INTERNA (2)

• PostgreSQL se maneja por medio de clúster (instancias) para lo cual posee un directorio en donde se almacenan los archivos de configuración del mismo, la data que se genera y otros archivos relevantes. El directorio por defecto es PGDATA. Dentro del directorio PGDATA se encuentra el directorio PGDATA/Base y es el directorio por defecto en donde se almacenan todos los objetos de una base de datos (tablas, índices, funciones, etc.).

• Además cada objeto se distingue mediante el OID ( el cual es un entero de 4 bytes sin signo) o mediante filenode. En el caso de las tablas y los índices poseen tres archivos asociados los cuales son: el mapa de espacio libre , el mapa de visibilidad y por último el de inicialización.

Page 5: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA INTERNA (3)

• PostgreSQL utiliza un tamaño de página fijo (normalmente 8 kB), y no permite que las tuplas abarquen varias páginas. Por lo tanto, no es posible almacenar directamente los valores de campo muy grandes. Para superar esta limitación, los valores de campo grandes se comprimen y / o rompen en múltiples filas físicas. Dicha técnica es conocida como TOAST. En el encabezado de fila se coloca el puntero hacia una tabla del tipo TOAST. Y se ocupa en tipos de datos variables. Los datos pueden comprimirse para guardarse y se colocan en tantas filas como el tamaño del dato lo demande.

• El código TOAST se activa sólo cuando un valor de fila (campo) para ser almacenado en una tabla es más ancho que TOAST_TUPLE_THRESHOLD (normalmente de 2 kB). El código TOAST comprime y / o mueve los valores de campo (out-of-line) fuera de línea hasta que el valor de la fila es más corta que TOAST_TUPLE_TARGET.

• Cada tipo de datos TOAST table específica una estrategia por defecto para las columnas de ese tipo de datos, pero la estrategia para una columna de tabla determinada se puede modificar con ALTER TABLE SET STORAGE.

8 kb8 KB

Page 6: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA INTERNA (4)

FREE SPACE MAP (MAPA DE ESPACIO LIBRE)

VISIBILITY MAP (MAPA DE VISIBILIDAD)

INICIALIZACIÓN FORK

Page 7: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA INTERNA (5)

Estructura de una página

Page 8: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DEL LOG DE TRANSACCIONES

WAL o Escritura de Registro Anticipada

La regla principal de WAL es asegurar que los registros se escriben en el WAL antes de que los registros de la base de datos sean alterados en disco

ATOMICIDAD y DURABILIDAD

Page 9: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DEL LOG DE TRANSACCIONES (2)IDENTIFICADOR DE SEGMENTOS

Actividad Normal: Checkpoint_segments + wal_keep_segments + 1En PICOS: 3 * checkpoint_segments + 1

pg_xlog/

Page 10: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DEL LOG DE TRANSACCIONES (3)

CHECKPOINT garantizan que todo los cambios realizados por las transacciones han sido llevados a disco duro (Flush del WAL). También escribe un registro en WAL que indica que todo segmento anterior a él puede ser borrado o reciclados.

* checkpoint_segments* checkpoint_timeoout* SQL CHECKPOINT

* full_page_written por defecto ON

TAMBIEN CONOCIDO COMO LOG REDO O LOG DE TRANSACCIONES ……… y Fue introducido desde PostgreSQL 7.1

Page 11: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DEL LOG DE TRANSACCIONES (4)

ESCRITURA SINCRONA Y ASINCRONAsynchronous_commit.

wal_writter_delayIntervalo entre

flushing del buffer de WAL al

disco.

Page 12: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DE PROCESAMIENTO DE CONSULTAS

1EL CAMINO DE UNA CONSULTA

Page 13: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DE PROCESAMIENTO DE CONSULTAS (2)

2EL CAMINO DE UNA CONSULTA

Page 14: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DE PROCESAMIENTO DE CONSULTAS (3)

3EL CAMINO DE UNA CONSULTA

Page 15: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DE PROCESAMIENTO DE CONSULTAS (4)

4EL CAMINO DE UNA CONSULTA

ANALIZE

VACUUM ANALIZE

No hay planes q se ejecuten en paralelo en PostgreSQL

Page 16: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DE PROCESAMIENTO DE CONSULTAS (5)

5EL CAMINO DE UNA CONSULTA

Page 17: Arquitectura e implementación de PostgreSQL 9.3

• SCHEMA: contienen una colección de objetos: tablas, funciones, vistas, tipos de datos, etc. Una base de datos puede contener uno o más esquemas. Por defecto las tablas (y otros objetos) se ponen automáticamente en un esquema denominado "público". Cada nueva base de datos contiene ese esquema. El usuario puede crear esquemas. Desde la perspectiva de seguridad todos los objetos creados dentro de un esquema pertenecen a él.

• De forma predeterminada, los usuarios no pueden tener acceso a los objetos de los esquemas que no poseen. Para permitir el propietario del esquema debe otorgar el privilegio para usar el esquema a los demás usuarios. Para permitir a los usuarios que utilicen los objetos del el esquema, privilegios adicionales podrían necesitarse que se otorgaran, Tomando en Cuenta si es apropiado para el objeto.

ARQUITECTURA DE OBJETOS

Page 18: Arquitectura e implementación de PostgreSQL 9.3

VISTAS

Existen dos tipos de vistas

• No materializadas => definida a partir de una consulta. En cambio, la consulta se ejecuta cada vez que se hace referencia a la vista en una consulta.

• Materializadas => define a partir de una consulta y permite que la vista se rellene con datos en el momento en que se emitió su ejecución. Es similar a CREATE TABLE AS

ARQUITECTURA DE OBJETOS (2)

Page 19: Arquitectura e implementación de PostgreSQL 9.3

PostgreSQL implementa la herencia de tablas, que puede ser una herramienta útil para los diseñadores de bases de datos; esto es permitido debido a que PostgreSQL es un gestor relacional orientado a objetos.

CREATE TABLE cities (

name text,

population float,

altitude int -- in feet);

CREATE TABLE capitals (

state char(2)

) INHERITS (cities);

ARQUITECTURA DE OBJETOS (3)

En este caso, la tabla capitales hereda todas las columnas de la tabla principal (ciudades). La tabla capitales también tienen una columna adicional (estado) que muestra su estado.

Page 20: Arquitectura e implementación de PostgreSQL 9.3

PARTICIONES

Particionamiento se refiere a la división de lo que es lógicamente una tabla grande en pedazos más pequeños físicamente. Actualmente, PostgreSQL soporta particiones mediante herencia de tablas. Cada partición debe ser creada como una tabla hija de una única tabla padre. La tabla padre existe sólo para representar a todo el conjunto de datos, mientras que las tablas hijas no poseen atributos pero en ellas se generan las restricciones de rangos. Usted debe estar familiarizado con la herencia antes de intentar configurar particiones.

Las siguientes formas de particionamiento pueden ser implementadas en PostgreSQL:

• Particionamiento Range: La tabla se divide en "rangos", definidos por una columna de clave o un conjunto de columnas. Por ejemplo, uno podría particionar en intervalos de tiempo, o en rangos de identificadores para determinados objetos de negocio. 

• Particionamiento de lista: La tabla se divide en forma explícita en el listado de valores clave que aparecen en cada partición.

ARQUITECTURA DE OBJETOS (4)

Page 21: Arquitectura e implementación de PostgreSQL 9.3

• TABLESPACE O ESPACIOS DE TABLA

Los espacios de tabla en PostgreSQL permiten a los administradores de bases de datos definir las ubicaciones en el sistema de archivos donde se almacenan los archivos que representan objetos de la base. Una vez creado, un espacio de tabla puede ser referido por su nombre al crear objetos de base de datos. Dos espacios de tablas se crean automáticamente cuando se inicia el clúster de base de datos. El espacio de tablas pg_global se utilizan para los catálogos del sistema compartidos. El espacio de tablas pg_default es el espacio de tabla por omisión del template1 y template0 de bases de datos (y, por lo tanto, será el espacio de tabla por defecto para otras bases de datos. La creación del espacio de tabla en sí debe hacerse como superusuario de base de datos

ARQUITECTURA DE OBJETOS (5)

Page 22: Arquitectura e implementación de PostgreSQL 9.3

INDICES

Todos los índices en PostgreSQL son lo que se conoce técnicamente como índices secundarios, es decir, el índice se encuentra físicamente separado del archivo de la tabla que describe. Cada índice se almacena con su propia relación física y así se describe por una entrada en el catálogo pg_class. El contenido de un índice está enteramente definido bajo el control de su método de acceso al índice. En la práctica, todos los métodos de acceso de índice dividen los índices en páginas de tamaño estándar para que puedan utilizar el almacenamiento regular y el administrador de búfer para acceder al contenido del índice.

ARQUITECTURA DE OBJETOS (6)

Page 23: Arquitectura e implementación de PostgreSQL 9.3

VACUUM

El VACUUM reclama el almacenamiento ocupado por las tuplas muertas. En funcionamiento normal en PostgreSQL, las tuplas que se eliminan u obsoletas por una actualización no se eliminan físicamente de su tabla, sino que siguen presentes hasta que se haga el vacuum (vacío). Por lo tanto es necesario hacer el VACÍO periódicamente, especialmente en tablas de actualización frecuente.

ARQUITECTURA DE OBJETOS (7)

Page 24: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DE MEMORIA

• El STORAGE MANAGER es el encargado de administrar la memoria, administración del buffer, archivos, bloqueos y control de la consistencia de la información.

• Entre las funciones del STORAGE MANAGER está proveer Memoria Compartida a los que sirve a los buffers y para el acceso a la base de datos.

Sistema V IPC

Page 25: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DE MEMORIA (2)

SHARED_BUFFERS

shmmax

Page 26: Arquitectura e implementación de PostgreSQL 9.3

ARQUITECTURA DE MEMORIA (3)

USO DE MEMORIA

Page 27: Arquitectura e implementación de PostgreSQL 9.3

TEMPLATE1: CREATE DATABASE realmente funciona copiando una base de datos existente. Por defecto, copia de la base de datos del sistema estándar llamado template1. Por lo tanto esta base de datos es la "plantilla" del cual se hacen nuevas bases de datos. Si usted agrega objetos a template1, estos objetos serán copiados a las bases de datos de usuario que se creen posteriormente.

TEMPLATE0: Hay una segunda base de datos del sistema estándar llamada template0. Esta base de datos contiene los mismos datos que el contenido inicial de template1, es decir, sólo los objetos estándar predefinidos por su versión de PostgreSQL. Template0 nunca debe ser cambiada después que el cluster de base de datos se haya inicializado.

POSTGRES: La base de datos postgres también se crea cuando se inicializa un clúster de bases de datos. Esta base de datos pretende ser una base de datos por defecto para los usuarios y las aplicaciones para conectarse. Es simplemente una copia de template1 y se puede quitar y volver a crear si es necesario.

BASE DE DATOS DEL SISTEMA

Page 28: Arquitectura e implementación de PostgreSQL 9.3

CATALOGO

DEL

SISTEMA

BASE DE DATOS DEL SISTEMA (2)

Page 29: Arquitectura e implementación de PostgreSQL 9.3

MODELOS DE RESPALDO Y RESTAURACIÓN

SQL DUMP (VOLCADO)

La idea detrás de este método de volcado es generar un archivo de texto con los comandos SQL que, cuando se alimente de nuevo al servidor, este volverá a crear la base de datos (una base de datos en particular) en el mismo estado en que se encontraba en el momento del volcado. PostgreSQL proporciona el programa de utilidad pg_dump para este propósito.

Page 30: Arquitectura e implementación de PostgreSQL 9.3

MODELOS DE RESPALDO Y RESTAURACIÓN (2)

COPIA DE SEGURIDAD A NIVEL DE SISTEMA DE ARCHIVOS

Una estrategia de copia de seguridad alternativa es copiar directamente los archivos que PostgreSQL usa para almacenar los datos en la base de datos (dichos archivos se encuentran en el directorio que se especificó al momento de instalar el clúster de base de datos). Usted puede utilizar cualquier método que prefiera para hacer copias de seguridad del sistema de archivos, por ejemplo:

tar -cf backup.tar / usr / local / pgsql / data

Page 31: Arquitectura e implementación de PostgreSQL 9.3

MODELOS DE RESPALDO Y RESTAURACIÓN (3)

ARCHIVADO CONTINUO Y RECUPERACIÓN POINT-IN-TIME (PITR)

En todo momento, PostgreSQL mantiene una write ahead log (WAL) en el pg_xlog / subdirectorio del directorio de datos del clúster. El log registra cada cambio realizado en los archivos de datos de la base de datos. Este registro existe principalmente para fines de seguridad de choque: si el sistema se bloquea, la base de datos se pueden restaurar a la consistencia en que quedo, "reproduciendo" las entradas del registro realizadas desde el último punto de control. Sin embargo, la existencia del registro hace que sea posible el uso de una tercera estrategia de copias de seguridad de bases de datos: podemos combinar un backup del nivel de sistema de archivos con un backup de los archivos de WAL.

pg_basebackup

Page 32: Arquitectura e implementación de PostgreSQL 9.3

MODELOS DE RESPALDO Y RESTAURACIÓN (4)

Para configurar este tipo de backup debemos modificar el archivo postgresql.conf los

parámetros de archive_command, wal_level = archive, archive_mode = on,

max_wal_senders >= 1, pg_hba.conf y reiniciar el servidor

Page 33: Arquitectura e implementación de PostgreSQL 9.3

DESCRIPCIÓN DEL NEGOCIO• La base de datos a implementar es adquirida de un trabajo de

graduación de la Facultad de Ingeniería de Sistemas Informáticos de la Universidad de El Salvador; cuyo título es: “Sistema Informático para la gestión de procesos de la unidad de transporte y combustible del Ministerio de Gobernación” año de realización 2011. El sistema informático desarrollado tiene como abreviatura SIGEP.

• La institución que solicito los requerimientos fue el ministerio de gobernación. La unidad en la cual se desarrollaría el trabajo fue la UNIDAD DE TRANSPORTE Y COMBUSTIBLE. Dicha unidad es la encargada de realizar diversos procesos en conjunto con las entidades (Correos de El Salvador, Cuerpo de Bomberos, Imprenta Nacional, Protección Civil y Otros) que se encuentran realizando sus gestiones en todo el país, además la UTYC controla el recurso de combustible para todos los equipos ya sean vehículos automotores o accesorios que requieren este servicio, para que los empleados puedan realizar sus actividades laborales sin presentar atrasos.

Page 34: Arquitectura e implementación de PostgreSQL 9.3

DESCRIPCIÓN DE LA BASE DE DATOS IMPLEMENTADA• La base de datos SIGEP contiene 65 tablas , 42 sequencias, 5

funciones, 5 triggers y 5 funciones de triggers. Por lo cual describiremos ciertos objetos.Nombre Función Objetivo

fn_registrar_auditoria

Registra el detalle de auditoria para cada usuario. Almacena información referente a las modificaciones realizadas por los usuarios durante el periodo de sesión.

fn_registrar_ingreso

Registra el inicio de sesión del usuario desde la aplicación de php.

fn_registrar_salida Registra la finalización de sesión del usuario desde la aplicación php.

fn_insertar_discupon

Ingresa el registro de los cupones otorgados a cada vehiculo y el estado de los mismo. Además modifica el estado de las requisiciones otorgadas a una entidad y el rango de cupones otorgados a la misma.

fn_eliminar_discupon

Elimina el detalle de cupón asignado a cada vehículo y regresa el estado de los cupones a su estado anterior de ser entregado. Además modifica el estado de la requisición otorgada a la entidad.

Page 35: Arquitectura e implementación de PostgreSQL 9.3

DESCRIPCIÓN DE LA BASE DE DATOS IMPLEMENTADA (2)

Nombre del Trigger Objetivo Tabla que Modifica

tr_tb_acta_traslado Ayudar en la auditoría de la BD, sobre cual usuario autorizo el traslado de vehículos a otras entidades.

tb_auditoria_db

tr_tb_bitacora Ayudar en la auditoría de la BD, a controlar las bitácoras que registran los usuarios sobre el itinerario asignado

tb_auditoria_db

tr_tb_entregado_requisicion

Ayudar en la auditoría de la BD, a monitorear la cantidad de cupones entregados a una entidad especifica de un tipo de combustible. Y que usuario fue el responsable de hacerlo

tb_auditoria_db

tr_tb_detalle_liquidacion

Ayudar en la auditoría de la BD, a conocer los detalles de factura realizados por el intercambio de los cupones otorgados

tb_auditoria_db

tr_tb_grupo_roles Ayudar en la auditoría de la BD, a verificar que usuario modifico los permisos de roles en la aplicación

tb_auditoria_db

tr_tb_grupo_proceso Ayuda en la auditoría de la BD, a verificar que usuario agrego una nueva serie de actividades a un proceso

tb_auditoria_db

Page 36: Arquitectura e implementación de PostgreSQL 9.3

DESCRIPCIÓN DE LA BASE DE DATOS IMPLEMENTADA (3)

UN NUEVO TABLESPACE DENOMINADO DISCO_2

SEGURIDAD A NIVEL DE USUARIOS Y ROLES

Page 37: Arquitectura e implementación de PostgreSQL 9.3

INSTALACIÓN

• POSTGRESQL 9.3 FUE INSTALADO EN DEBIAN 7.2 GNU/LINUX y en WINDOWS SERVER 2008 R2 STANDAR EDITION en ambos sistemas operativos se instaló de manera desatendida y por medio de un archivo de configuración y utilizando en cada caso la respectiva consola de administración

• Básicamente para realizar la instalación debemos de estar dentro de la carpeta donde se encuentra el paquete de instalación en nuestro caso postgresql-9.3.1-1-windows-x64.exe WINDOWS y postgresql-9.3.1-1-linux-x64.run en el caso de DEBIAN y colocando la opción --optionfile config.txt se ejecuta el archivo de configuración

DEBIAN WINDOWSmode=unattendedsuperaccount=postgreCL012013superpassword=clustpgba2013servicename=Cluster01pg9.3.1serverport=5432prefix=/usr/local/PostgreSQL/9.3datadir=/usr/local/PostgreSQL/9.3/data

mode=unattendedsuperaccount=postgreCL012013superpassword=clustpgba2013servicename=Cluster01pg9.3.1serverport=5432prefix=C:\PostgreSQL\9.3datadir=C:\PostgreSQL\9.3\data

Page 38: Arquitectura e implementación de PostgreSQL 9.3

CONFIGURACIÓN

La configuración se realizó por medio de dos archivos los cuales son:

• Archivo postgresql.conf: Es el principal archivo de configuración que determina como funciona PostgreSQL. Los parámetros modificados dentro de postgresql.conf fueron los siguientes:

listen_addresses= '*'max_connections = 22superuser_reserved_connections = 2shared_buffers (8KB)= 512MBwork_mem (KB)= 5MBmantenience_work_mem = 256MBsynchronous_commit = onwal_buffers = -1

checkpoint_segment = 10checkpoint_timeout = 900effective_cache_size (8KB)= 580MBlog_line_prefix = '%t:%r:%u@%d[%p]: ' timestamp, hostIP, user, database, PIDlog_statement = 'DDL'Autovacuum = on

Page 39: Arquitectura e implementación de PostgreSQL 9.3

CONFIGURACIÓN (2)

La configuración se realizó por medio de dos archivos los cuales son:

• Archivo pg_hba.conf

El archivo hba (host based authentication: autenticacion basada en host) le dice al servidor PostgreSQL como autenticar usuarios, basado en una combinación de su localización, tipo de autenticación y la base de datos que desea acceder. Ahora veremos cómo permitir conexiones remotas, primero recordemos que listen_adress permita IP que nosotros sabes q son remotas, luego abrimos pg_hba.conf y agremos la siguiente linea.

host all all 0.0.0.0/0 md5

Page 40: Arquitectura e implementación de PostgreSQL 9.3

ADMINISTRACIÓN

• La base de datos SIGEP contiene los siguientes scripts, los cuales denotan la estructura de la base, los privilegios y usuarios, los triggers, las funciones y la data.

Page 41: Arquitectura e implementación de PostgreSQL 9.3

ADMINISTRACIÓN (2)

• Para administrar la base de dato nos auxiliamos de la herramienta pgAdmin y de algunas vistas que permiten realizar el monitoreo de la base de datos como:Vista Que realiza

pg_roles: Información sobre todos los roles y usuarios definidos en la base de datos.

pg_database Información sobre todas las bases de datos definidas en nuestro sistema.

pg_stat_activity Información sobre todos los procesos clientes conectados a la base de datos.

pg_stat_database Información global de uso de todas las bases de datos.

pg_stat_user_tables

Información de uso de todas las tablas de usuario en una base de datos

pg_statio_user_tables

Información de acceso a disco y memoria cache de todas las tablas de usuario en una base de datos.

Page 42: Arquitectura e implementación de PostgreSQL 9.3

HERRAMIENTA DE ADMINISTRACIÓN PGADMIN III

CARGA MASIVA DE DATOSSuperusuario de BDcheckpoint_segment = 100Autovacuum = offwal_level = minimalarchive_mode = offmax_wal_sender = 0Quitar índices y Constraints

Page 43: Arquitectura e implementación de PostgreSQL 9.3

PREGUNTAS Y RESPUESTAS