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

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

2. 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…”

3. ARQUITECTUR
A
INTERNA

4. 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.

5. ARQUITECTURA
88
kb
KB
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.

6. ARQUITECTURA
INTERNA (4)
FREE SPACE MAP (MAPA DE
ESPACIO LIBRE)
VISIBILITY MAP (MAPA DE
VISIBILIDAD)
INICIALIZACIÓN FORK

7. ARQUITECTURA
INTERNA (5)
Estructura de una página

8. 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

9. ARQUITECTURA DEL LOG DE
TRANSACCIONES (2) DE SEGMENTOS
IDENTIFICADOR
pg_xlog/
Actividad Normal: Checkpoint_segments + wal_keep_segments + 1
En PICOS: 3 * checkpoint_segments + 1

10. ARQUITECTURA DEL LOG DE
TRANSACCIONES (3)
TAMBIEN CONOCIDO COMO LOG REDO O LOG DE TRANSACCIONES
……… y Fue introducido desde PostgreSQL 7.1
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

11. ARQUITECTURA DEL LOG DE
TRANSACCIONES (4)
ESCRITURA SINCRONA Y ASINCRONA
synchronous_commit.
wal_writter_delay
Intervalo entre
flushing del buffer
de WAL al disco.

12. ARQUITECTURA DE PROCESAMIENTO DE
CONSULTAS
1
EL CAMINO DE UNA CONSULTA

13. ARQUITECTURA DE PROCESAMIENTO DE
CONSULTAS (2)
2
EL CAMINO DE UNA CONSULTA

14. ARQUITECTURA DE PROCESAMIENTO DE
CONSULTAS (3)
3
EL CAMINO DE UNA CONSULTA

15. ARQUITECTURA DE PROCESAMIENTO DE
CONSULTAS (4)
ANALIZE
VACUUM ANALIZE
4
No hay planes
q se ejecuten
en paralelo en
PostgreSQL
EL CAMINO DE UNA CONSULTA

16. ARQUITECTURA DE PROCESAMIENTO DE
CONSULTAS (5)
5
EL CAMINO DE UNA CONSULTA

17. ARQUITECTURA DE OBJETOS
• 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.

18. ARQUITECTURA DE OBJETOS (2)
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

19. ARQUITECTURA DE OBJETOS (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
population
altitude
text,
float,
int
-- in feet);
CREATE TABLE capitals (
state
char(2)
) INHERITS (cities);
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.

20. ARQUITECTURA DE OBJETOS (4)
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.

21. ARQUITECTURA DE OBJETOS (5)
•
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

22. ARQUITECTURA DE OBJETOS (6)
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

23. ARQUITECTURA DE OBJETOS (7)
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.

24. 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

25. ARQUITECTURA DE MEMORIA (2)
SHARED_BUFFERS
shmmax

26. ARQUITECTURA DE MEMORIA (3)
USO DE MEMORIA

27. BASE DE DATOS DEL SISTEMA
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.

28. BASE DE DATOS DEL SISTEMA (2)
CATALOGO
DEL
SISTEMA

29. 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.

30. 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:

31. 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
pg_basebackup

32. 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

33. 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.

34. 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.

35. DESCRIPCIÓN DE LA BASE DE DATOS
IMPLEMENTADA (2)
Nombre del Trigger
tr_tb_acta_traslado
tr_tb_bitacora
Objetivo
Tabla que
Modifica
Ayudar en la auditoría de la BD, sobre cual usuario tb_auditoria_d
autorizo el traslado de vehículos a otras entidades.
b
Ayudar en la auditoría de la BD, a controlar las bitácoras tb_auditoria_d
que registran los usuarios sobre el itinerario asignado
b
tr_tb_entregado_requisicio Ayudar en la auditoría de la BD, a monitorear la cantidad
n
de cupones entregados a una entidad especifica de un
tipo de combustible. Y que usuario fue el responsable de
hacerlo
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
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
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_d
b
tb_auditoria_d
b
tb_auditoria_d
b
tb_auditoria_d
b

36. DESCRIPCIÓN DE LA BASE DE DATOS
IMPLEMENTADA (3)
UN NUEVO TABLESPACE
DENOMINADO DISCO_2
SEGURIDAD A NIVEL DE
USUARIOS Y ROLES

37. 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 DEBIAN
WINDOWS
-optionfile config.txt se ejecuta el archivo de configuración
mode=unattended
superaccount=postgreCL012013
superpassword=clustpgba2013
servicename=Cluster01pg9.3.1
serverport=5432
prefix=/usr/local/PostgreSQL/9.3
datadir=/usr/local/PostgreSQL/9.3/data
mode=unattended
superaccount=postgreCL01201
3
superpassword=clustpgba2013
servicename=Cluster01pg9.3.1
serverport=5432
prefix=C:PostgreSQL9.3
datadir=C:PostgreSQL9.3data

38. 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= '*'
checkpoint_segment = 10
max_connections = 22
checkpoint_timeout = 900
superuser_reserved_connections = 2 effective_cache_size (8KB)= 580MB
shared_buffers (8KB)= 512MB
log_line_prefix = '%t:%r:%u@%d[%p]: '
work_mem (KB)= 5MB
timestamp, hostIP, user, database, PID
mantenience_work_mem = 256MB log_statement = 'DDL'
synchronous_commit = on
Autovacuum = on
wal_buffers = -1

39. 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

40. 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.

41. 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:
pg_stat_database
Información sobre todos los roles y usuarios definidos en la base de
datos.
Información sobre todas las bases de datos definidas en nuestro
sistema.
Información sobre todos los procesos clientes conectados a la base de
datos.
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_database
pg_stat_activity
pg_statio_user_table Información de acceso a disco y memoria cache de todas las tablas de

42. HERRAMIENTA DE ADMINISTRACIÓN
PGADMIN III
CARGA MASIVA DE DATOS
Superusuario de BD
checkpoint_segment = 100
Autovacuum = off
wal_level = minimal
archive_mode = off
max_wal_sender = 0
Quitar índices y Constraints

43. PREGUNTAS Y RESPUESTAS