PostgreSQL

PostgreSQL
Capacitación Nivel 1
Día 1
Agenda
• Introducción al Modelo Objeto-Relacional
• Introducción a la Arquitectura Cliente/Servidor.
Breves comparaciones.
• Introducción a PostgreSQL .
• Arquitectura
• Procesamiento interno
• Esquema Lógico
• Herramientas
• ACID en Pgsql
• MVCC
Introducción al Model ObjetoRelacional
¿Porqué Bases de datos?
Los SGBD nacieron con el propósito de solventar los
siguientes problemas de los antiguos sistemas:
• Redundancia e inconsistencia de Datos.
• Dificultad en el acceso concurrente.
• Aislamiento de datos.
• Problemas de integridad.
• Problemas de atomicidad.
• Anomalías en el acceso concurrente.
• Problemas de Seguridad.
Visión de Datos
– Nivel físico.
– Es como se guardan los datos en disco. Solo es
importante conocerlos si es DBA o desarrollador del
motor.
– Nivel Lógico.
– Es el nivel en el cual trabaja el DBA y el Arquitecto de
datos.
– Nivel de vistas.
– Es el nivel en el cual trabaja el desarrollador de la
aplicación final y el cual verá el usuario de la misma.
Independecia Física
• Físico
– Disposición de elementos del motor sobre los
sistemas de almacenamiento.
– Ayuda a mejorar la performance.
• Lógico
– Disposición de los objetos dentro de la base.
– Ayuda a mejorar la comprensión.
– Característica que puede adicionar seguridad
a nivel de gestor.
Modelos Lógicos
•
•
•
•
Modelo Entidad Relación (DER)
Modelo Orientado a Objetos.
Modelo de datos semántico.
Modelo de datos funcional.
Indican el diseño lógico de datos,
No indican datos reales o
ya implementados
Modelos lógicos basados en registros
• Ojeto-Relacional.
• Postgresql, Oracle
• Modelo relacional
• Mysql, DB2, SQLServer
• El modelo de red
• El modelo jerárquico
• Sistemas de Archivos (pueden ser
considerados Bases de Datos).
• Orientado a Objetos
• DB4O
Arquitecturas
Backend
Proceso
Archivo/s
Backend
Cliente
Cliente
...
Servidor /
Cluster de servidores
Servidor
Datos
Derby –
BerkeleyDB
Mysql – Postgresql Firebird
Oracle – DB2 - Greenplum
El punto de vista de Stonebraker
Capacidades
De búsqueda
/soporte
multiusuario
r
o
y
Ma
SGBD
relacional
SGBD
O-R
Mysql
Sistemas
De
archivos
ad
d
i
Derby
oc
l
e
v
Postgresql
SGBD
OO
d
DB4O ocida
vel
r
no
e
M
Complejidad de los datos y ampliabilidad
Principios de la integridad de datos
•
•
•
•
Atomicidad
Consistencia
Aislamiento (Isolation)
Durabilidad
NOTA: PostgreSQL es ACID
Transacciones
Colección de operaciones (sucesión de acciones) que forman una
unidad lógica de trabajo, y que posiblemente actualice varios
elementos de datos.
Transacción 1
Transacción 2
Base de
Datos
Log de
transacciones
Commit
Commit
Estados transaccionales
•
•
•
•
•
•
Activa
Parcialmente comprometida
Fallida
Abortada
Comprometida (COMMIT)
Rollback (No se aborta, se vuelve a un
determinado punto o inicio de transacción)
Introducción a Postgresql
Historia
1977-1985 Michael Stonebraker Inicia postgreSQL como
Ingres en la Universidad de Berkeley, California.
1986, comprado por Computer Associates.
1989, Liberada la primera versión como Postgres.
1994-95 dos estudiantes graduados de Berkeley Jolly Chen y
Andrew Yu añaden SQL a Postgres y lo llaman Postgres95.
1996, (1000 colaboradores) Se decidió quitar el 95 al nombre
para liberarse de la cronología y nace PostgreSQL.
Ultima version al momento 8.4 y 8.5 en desarrollo.
http://archives.postgresql.org/pgsql-advocacy/200412/msg00033.php
Historia (2)
• OMFG!
Su hermandad con Informix
Stonebraker empezó Ingres (1977). Luego de varias
empresas, desembarcó en Illustra.
Después (1995) unos estudiantes tomaron POSTGRES y
lo siguieron desarrollando, le pusieron Postgres95 y
después se pasó a llamar PostgreSQL.
En 1996 la empresa que hacía Informix compró Illustra y
dejaron de lado la base de datos Illustra, y en cambio
usaron los ingenieros y la tecnología para avanzar un poco
más con Informix.
En el 2001 la empresa Informix se dividió en dos y la parte
que tenía que ver con la base de
datos fue a parar a IBM.
Informix desde ECPG
Postgresql, descripción
• Es el SGBD Open Source mas potente del mercado.
• Posee casi 30 años de desarrollo.
• Licencia BSD de Berkeley.
• Esta en la vanguardia de la investigacion en al tecnología
transaccional.
• Es ACID.
• Es segura.
• Tiene alternativas comerciales de muchísima calidad. Ej:
EnterpriseDB, CyberTech(Alemania), etc.
• Tiene otras alernativas (forks) FastDB, Bizgres, etc.
Postgresql, descripción (2)
•
•
•
•
Es un motor Objeto-Relacional [*].
Cliente/servidor
Extensible
Multiples conectores desde lenguajes de
programación.
• Lenguaje procedimental propio (PL/pgsql)
y extendido (PL/PERL, PL/PYTHONu,
PL/JAVA, PL/RUBY, PL/R, C, C++...)
Postgresql, descripción (3)
SQL:2003
• El estandar SQL:2003 define las siguientes
características que se peuden implementar en las
bases Objeto relacionales:
– Rowtype
– Tipos definidos y rutinas por usuario.
– Poliformismo
– Herencia
– Tipos de referencia e identidad de objetos (el OID es uno de ellos)
– Tipos de colección (ARRAY, MULTISET, SET, LIST)
– Ampliación del SQL para hacerlo computacionalmente completo.
– Soporte para objetos de gran tamaño (BLOB y CLOB)
– Recursión.
Carácterísticas
•
El modelo es de cliente/servidor (hoy en día el más común, pero no
el único).
•
Su lenguaje procedimental es muy similar al PL de Oracle, logrando
una migración mas amena.
•
Se adapta a los standares SQL:2003.
•
Posee MVCC (Multi-Version Concurrency Control). Fue una de las
pioneras (la primera fue InterBase)
•
Posee WAL (Write Ahead LOG).
•
Herencia de tablas.
•
Puntos de recuperacion avanzados (savepoints, replicacion
asincronica)
•
Optimizador de consultas.
•
Juegos de caracteres UNICODE e internacionalización.
Características (2)
• Tipos de datos accesorios:
– Números de presición arbitraria (creando numeros
más complejos)
– Text de largo ilimitado.
– Figuras geometricas, con funciones asociadas.
(Cube, contrib)
– IpV4 y 6.
– Mac Address.
– Arrays (Nuevas funciones en 8.4)
– Postgis (necesita un capítulo aparte).
– Citext (insensitive case text type - 8.4)
Características - Límites
•
•
•
•
•
•
•
Maximo de la BD: ilimitado.
De Tablas: 32 TB.
De tupla: 1.6 TB.
De campo: 1 GB
Tuplas x tabla: ilimitado.
Índices por tabla: ilimitado.
Bloque: 8k
Características - Índices
• Pueden ser definidos por el usuario:
– Btree (por defecto y el más común), Hash, GIN
(Generalized Inverted , ex RTree) y Gist (Generalized
Index Storage).
• Basados en expresiones.
• Parciales
• Bitmaps.
• Gin es más lento para inserciones pero más rápido para
búsqueda de texto (se usa para Full Text Search).
• Gist es bueno para datos complejos o raros (figuras
geométricas, tsvector, etc)
Características - Avanzadas
• Restricciones Referential Integrity Constraints. Evita
eliminaciones accidentales.
• Transacciones BEGIN – END- SAVEPOINTS.
• Anidación de consultas avanzadas.
• Conexiones encriptadas vía SSL.
• Dominios, clustering, tablespaces, schemas y otros
objetos de agrupación.
• TOAST (atributos comprimidos largos, transparente al
usuario).
• Soporte de funciones de ventana y recursivas.
Vista lógica del funcionamiento
Aplicacion
Postgres
postmaster
psql
Postgres
Vista más detallada
Vista ++ detallada
• Acceso
desde
diversos
conectores.
Bloque I/O
Block 8k
Le
íd
o
Cache
Hit
Tabla
Block 8k
Block 8k
LRU
(Last Recently
Used)
Dentro de un bloque
Tupla
Tupla
Cache Pg + Kernel
• Se utiliza
gran parte
del cache de
buffer del
kernel.
• http://momjia
n.us/main/wri
tings/pgsql/h
w_performan
ce/
Autenticación – Saludo de 3 vías
postmaster
backend
backend
Servidor
Inicio de Conexion
Auth
Query's
frontend
frontend
frontend
Cliente
T
i
e
m
p
o
Listado de Procesos
Postmaster
• Proceso principal.
• Se maneja como un servicio de sistema.
• Levanta la memoria compartida.
• Vigila solicitudes y esta al tanto de los movimientos.
• Realiza el enlazado a los archivos de datos.
• puede manejar varias bases de datos y usuarios.
• Uno x CLUSTER.
Datos técnicos
• La comunicación entre Back y front se
realiza mediante sockets a través del
puerto 5432 (por defecto).
• Generalmente el archivo es
/tmp/s.PGSQL.5432.
Procesamiento Interno
Esquema Interno
Parseo de comando
Analizamiento de consulta
Ejecutor de consulta
La ruta de una consulta
1. Una conexión desde una aplicación al servidor Pgsql debe ser establecida.
La aplicación transmite la consulta y espera a los resultados.
2. El 'parseador' chequea que la consulta transmitida por la aplicación tenga
una sintaxis correcta y crea el árbol de consulta (ADC).
3. El sistema de reescritura(SDR) toma el ADC y busca cualquier regla
(almacenada en los catalogos de sistema) para aplicar el ADC. Ejecuta
transformaciones dadas en los cuerpos de las reglas. Una aplicación del SDR
es la realización de vistas. Cuando sea una consulta sobre una vista, el SDR
reescribe la consulta para acceder a la tabla.
4. El planeador/optimizador toma la reescrita consulta y crea un plan, el cual
será la entrada del ejecutor. Com primera instancia creará todas las posibles
rutas que tengan el mismo resultado. Seguido, el
costo por cada ejecución es estimado para elegir
el menos costoso. Ese mismo es expandido para
que el ejecutor pueda usarlo.
5. El ejecutor rescursivamente pasa a través del
árbol del plan y devuelve las filas. Hace uso del
sistema de almacenamiento mientras realiza las
tareas del plan y finalmente retorna los resultados.
Como se establecen conexiones
• Un proceso por usuario.
– Pro
» Esto es importante debido a que provee de
mayor estabilidad en ambientes muy
concurrentes.
» En mayor concurrencia hace mejor
aprovechamiento de multinucleos y
recursos.
– Contras
» Como contra, en ambientes de menor
concurrencia, suele tener menos
performance que varios usuarios por
proceso manejados por hilos.
Como se establecen conexiones (2)
• El proceso maestro (postgres) escucha su
socket a través de TCP/IP (puerto por
defecto 5432)
• Estos procesos se comunican entre si
para mantener la integridad de los datos.
• Se puede conectar con cualquier
aplicación – driver que entienda el
protocolo de Postgresql.
» Mayor detalle en el manual, capítulo
“Frontend/Backend Protocol” (45 en versión 8.4)
Binarios escenciales
•
postgres
» Servidor
•
psql
» No olbligatorio, pero extremadamente útil.
•
pg_ctl
» Administra el arranque o la parada del servidor.
•
pg_config
» Provee información sobre la instalación de la base
•
pg_controldata
» Información del Cluster de datos
•
reindexdb – vacuumdb
» Herramientas de mantenimiento
•
Initdb
» Inicializa un cluster de bases de datos.
•
Ipcclean
» Limpia la memoría compartida de consultas canceladas.
Instalación
Elección del SO
• La elección del SO es crucial para la
instalación de nuestro motor. Influirá:
–
–
–
–
–
–
Escalamiento.
Mantenimiento.
Funcionalidad.
Estabilidad.
Herramientas.
Seguridad.
Caso: Windows
• En el caso de utilizarse Windows como
plataforma servidor, se recomienda la serie
'server' o superior.
• Preferentemente 2000 o superior.
• Imposibilidad de utilizar sistemas de ficheros
ajenos a su licencia (NTFS -FAT).
• Soporte no tan poblado como en otras
plataformas.
Caso: Derivado Linux
• Es el más soportado.
• Posibilidad de utlización de varios
sistemas de ficheros (xfs, jfs, reiserfs,
ext2-3, etc.)
• Económico.
• Escalable.
• Fácil de configurar.
Caso: BSD
• Bastante similar a Linux en cuanto a
posibles problemas y soporte.
• Soporta ZFS.
Caso: Solaris
• Estable.
• Soporta varios sistemas de archivo incluido ZFS.
• Soporta herramientas de administración avanzada.
• Soporta herramientas de debug avanzadas.
» Postgresql incluye 'probes' para ser traceado con
DTRACE.
• Exelente rendimiento en ambientes muy concurrentes y
de alta carga de datos.
Instalación
• Homo Paquetus
– Es la forma más común de instalación.
– Existen en forma de paquetes .deb, .rpm, .pkg, one-clickinstallers (varias plataformas, gracias al aporte de
EnterpriseDB y traducción de SistemasAgiles)
• Homo compilatis
– En linux es necesario el build-essential (se puede
descargar desde los repositorios de derivados de
Debian).
– En Solaris se puede compilar con gcc o con SunStudio.
No soporta readline. Se debe instalar gmake.
– En windows se puede compilar con Visual Studio (más
info en www.arpug.com.ar)
Homo paquetus
• Buscamos:
• Instalamos:
Homo compilatis
• Instalamos el build-essential (Debian*).
• Configuramos la instalación con
'configure'.
• Compilamos e instalamos con gmake.
• Copiar los scripts de arranque.
• Verificar si existe el usuario postgres o el
que será dueño del cluster.
• Inicializar el cluster.
• Arrancar el motor.
Script de arranque (derivados Linux)
Nivel de arranque
• Los directorios rc.d nos indican el orden de la
ejecución de los scripts de inicio.
• Aquí podemos configurar en que nivel arrancar el
gestor de datos.
• Para administrar esto, utilizar el script 'update-rc.d',
incorporado en las distros derivadas de Debian.
• Esta imagen nos indica que esta en todos los
niveles de init.
Estructura del cluster en el sistema de ficheros
• Aquí se encuentran:
–
–
–
–
–
Datos y bases.
WAL
Archivos de configuración
Logs
etc...
Dentro del data/
Oid2name es un contrib que permite
ver el nombre de acuerdo a los OID de
cada objeto.
Output pg_config
Script init
Habilitar conexiones remotas
• postgresql.conf
• listen_addresses (pueden estar separadas por coma o especificar
todas con '*')
• Port (recordar que debe estar habilitado desde el firewall)
• pg_hba.conf (mejora sustancial en 8.4)
– local
database user auth-method [auth-options]
– host
database user CIDR-address auth-method [auth-options]
– hostssl
database user CIDR-address auth-method [auth-options]
– hostnossl database user CIDR-address auth-method [auth-options]
– host
– hostssl
database user IP-address IP-mask auth-method [auth-options]
database user IP-address IP-mask auth-method [auth-options]
– hostnossl database user IP-address IP-mask auth-method [auth-options]
• pg_ident.conf
– Asigna alias para los usuarios.
Diferencias e/versiones
•
•
•
•
•
•
•
7.4
8.0
8.1.17
8.2.11
8.3.7
8.4.0
devel8.5
• Cada aprox. 6 meses
se completa el ciclo de
desarrollo.
• Los parches
constantemente se van
'comiteando'
• Las versiones de
segundo dígito
adhieren nuevas
prestaciones.
Herramientas
• Stack Builder: permite instalar
aditamentos para desarrollo, como
conectores desde lenguajes y drivers.
• PgAdmin: Administrador gráfico.
Localización
• Se puede crear el cluster con la opción
'initdb –locale=es_AR'
• LC_COLLATE, Orden de cadenas
• LC_CTYPE, Clasificación de caracteres.
• LC_MESSAGES, Lenguaje de mensajes
• LC_MONETARY, Formato de dinero
• LC_NUMERIC, Formato de numeros
• LC_TIME, Formato de fechas y timestamps
Notas sobre localización
• Afecta a:
– Ordenamiento en consultas que utilizan
ORDER BY o los operadores de consulta
tradicionales en textos.
– La utilización de usos de índices con la
cláusula LIKE.
– A las funciones upper, lower e initcap.
– A la familiar de funciones de to_char.
Set de caracteres
• Como se especifica?
– initdb -E UTF8
– createdb -E UTF8 -T template0 --lc-collate=es_AR.utf8
--lc-ctype=es_AR.UTF8 <nombrebase>
– CREATE DATABASE prueba WITH ENCODING 'UTF8'
LC_COLLATE='es_AR.utf8' LC_CTYPE='es_AR.utf8'
TEMPLATE=template0;
• Los más comunes que utilizaremos son:
– UTF8
– SQL-ASCII
– WIN1252
– LATIN1
Verificar las bases (1)
• Podemos verificar el encoding de nuestras
bases:
Verificar las bases (2)
• La salida del 8.4 es un poco más
completa:
Cambio de set
• \encoding de psql permite cambiar el
encoding client 'on the fly'.
• Existe un listado de conversión automática
de set de caracteres.
¿Como postgres promete ACID?
Soluciones para ACID
• [A]tomicidad (transacciones indivisibles)
• [C]onsistencia
• [I]solation ,aislamiento (no se pueden ver
entre transacciones)
• [D]urabilidad: éxito de una transaccion que
perdura.
Solución para [A]
• Sentencias de BEGIN, END, ROLLBACK,
COMMIT y SAVEPOINT.
Solución para [C]
• A partir de 7.*, gestor de integridad:
– not null
– check
– unique
– primary key
– fk -match full y partial
Solución para [I]
• MVCC
– Multi Versión Concurrency Control
• Impide el bloqueo de la tabla
Solución para [D]
• WAL (write Ahead Log) /var/pg_xlog
• Acelera los tiempos de commit y de insercion y
update.
• En caso de caída, las transacciónes cmprometidas
pero que no llegaron a la base, permanecen en la
WAL.
MVCC
EXPLAIN MVCC;
EXPLAIN ANALYZE MVCC;
Cada consulta ve unicamente las transacciones completadas antes
de comenzar.
Al comienzo de la consulta, Pgsql guarda:
• El contador de transacciones. (de ahi que es importante mantener
en estado con VACUUM FREEZE si tenemos un número muy alto
de transacciones, para resetearlo)
• Todos los identificadores que estan en proceso.
• En una transacción de multi-cláusulas, las previas transacciones
propias a la actual son visibles
• Se toma por defecto el nivel de read committed isolation level
EXPLAIN ANALYZE VERBOSE MVCC;
•
Las tuplas deben tener un
transaction id que:
– Es una transacción
comprometida.
– Es menor al contador de la
transacción almacenado al
comienzo de la consulta y...
– No estar en proceso al comienzo
de la consulta.
•
El transaction id de las tuplas visibles
expiran cuando:
– Esta en blanco o abortado
– Es mayor al contador y ..
– Estar en proceso al inicio de la
consulta
Búsqueda Secuencial
Contador de transacciones al
comienzo de la consulta: 100
Transacciones abiertas :
25,50,75
Por simplicidad, se asume
que el resto estan
comprometidas
Bibliografía
• wiki.postgresql.org
• Documentación 8.3.x y 8.4
• Presentación B. Momjian (Postgresql Internals throw
pictures)
• www.ibm.com
</Día 1>
Gracias!