Your SlideShare is downloading. ×
0
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Arquitectura e implementación de PostgreSQL 9.3
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Arquitectura e implementación de PostgreSQL 9.3

4,528

Published on

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

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

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,528
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
193
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×