Pasé una semana en la magnífica ciudad de Lisboa asistiendo a la Conferencia Europea PostgeSQL anual. Esto marcó el décimo aniversario desde la primera conferencia europea de PostgreSQL y la sexta vez que asistí.
Primeras impresiones
La ciudad estuvo genial, el ambiente genial y parecía que sería una semana muy productiva e informativa llena de conversaciones interesantes con gente inteligente y amable. Entonces, básicamente, lo primero que aprendí en Lisboa es lo grandiosos que son Lisboa y Portugal, ¡pero supongo que viniste aquí por el resto de la historia!
Búferes compartidos
Asistimos a la sesión de formación “PostgreSQL DBA toolbelt for day-to-day ops”
de Kaarel Moppel (Cybertec) . Una cosa que noté fue la configuración de shared_buffers. Dado que shared_buffers en realidad compite o complementa la memoria caché del sistema, no debe establecerse en ningún valor entre el 25 % y el 75 % de la memoria RAM total disponible. Entonces, mientras que, en general, la configuración recomendada para las cargas de trabajo típicas es el 25 % de la RAM, podría establecerse en>=75 % para casos especiales, pero no en el medio.
Otras cosas que aprendimos en esta sesión:
- la activación/habilitación en línea (o fuera de línea) lamentablemente fácil de sumas de verificación de datos aún no está en 11 (initdb/replicación lógica sigue siendo la única opción)
- cuidado con vm.overcommit_memory, es mejor que lo deshabilite configurándolo en 2. Establezca vm.overcommit_ratio en aproximadamente 80.
Replicación lógica avanzada
En la charla de Petr Jelinek (segundo cuadrante) , los autores originales de la replicación lógica, aprendimos sobre usos más avanzados de esta nueva y emocionante tecnología:
- Recopilación centralizada de datos:podemos tener varios editores y luego un sistema central con un suscriptor para cada uno de esos editores, haciendo que los datos de varias fuentes estén disponibles en un sistema central. (uso típico:OLAP)
- Datos globales compartidos o, en otras palabras, un sistema central para mantener datos y parámetros globales (como divisas, acciones, valores de mercado/mercancías, clima, etc.) que publica para uno o más suscriptores. Luego, estos datos se mantienen solo en un sistema, pero están disponibles en todos los suscriptores.
- La replicación lógica puede ser asíncrona pero también síncrona (garantizada en la confirmación)
- Nuevas posibilidades con decodificación lógica:
- integración con Debezium/Kafka a través de complementos de decodificación lógica
- complemento wal2json
- Replicación bidireccional
- Actualizaciones con tiempo de inactividad cercano a cero:
- configure la replicación lógica en el nuevo servidor (posiblemente initdb con la habilitación de sumas de verificación de datos)
- espere hasta que el retraso sea relativamente pequeño
- desde pgbouncer pausar la(s) base(s) de datos
- espera hasta que el retraso sea cero
- cambie la configuración de pgbouncer para que apunte al nuevo servidor, vuelva a cargar la configuración de pgbouncer
- desde pgbouncer reanude la(s) base(s) de datos
Novedades de PostgreSQL 11
En esta emocionante presentación, Magnus Hagander (Redpill Linpro AB) nos presentó las maravillas de PostgreSQL 11:
- pg_stat_statements admite queryid de 64 bits.
- pg_prewarm (un método para calentar el caché del sistema o los búferes compartidos):adición de nuevos parámetros de configuración
- Nuevos roles predeterminados que facilitan el alejamiento de postgres (el usuario al que me refiero :))
- Procedimientos almacenados con control xaccional
- Búsqueda de texto completo mejorada
- La replicación lógica admite TRUNCATE
- Copias de seguridad base (pg_basebackup) validan sumas de control
- Varias mejoras en la paralelización de consultas
- Particionamiento aún más refinado que en 10
- partición predeterminada
- actualizaciones entre particiones (mueve la fila de una partición a otra)
- índices de partición locales
- clave única en todas las particiones (todavía no referenciable)
- partición hash
- uniones por partición
- agregados por partición
- las particiones pueden ser tablas externas en diferentes servidores externos. Esto abre grandes posibilidades para fragmentación de grano más fino.
- Compilación JIT
zheap:una respuesta a los problemas de hinchamiento de PostgreSQL
Esto todavía no está en 11, pero suena tan prometedor que tuve que incluirlo en la lista de cosas geniales. La presentación estuvo a cargo de Amit Kapila (EnterpriseDB) uno de los principales autores de esta nueva tecnología que pretende integrarse eventualmente en el núcleo de PostgreSQL como un tipo alternativo de almacenamiento dinámico. Esto se integrará con la nueva API de almacenamiento conectable en PostgreSQL, que admitirá múltiples métodos de acceso a tablas (de la misma manera que los diversos métodos de acceso [Índice] tratados en mi primer blog).
Esto intentará resolver las deficiencias crónicas que tiene PostgreSQL con:
- hinchazón de la mesa
- necesita (auto)aspirar
- potencialmente un ajuste de ID de transacción
Todo eso no es un problema para la empresa mediana o grande promedio (aunque esto es muy relativo), sabemos que los bancos y otras instituciones financieras ejecutan PostgreSQL de decenas de TB de datos y varias miles de transacciones por segundo sin problemas. El hinchamiento de la tabla es manejado por autovacuum y la congelación de filas resuelve el problema de la envoltura de la identificación de la transacción, pero aún así esto no está libre de mantenimiento. La comunidad de PostgreSQL trabaja para lograr una base de datos verdaderamente libre de mantenimiento, por lo que se propone la arquitectura zheap. Esto traerá:
- un nuevo registro de DESHACER
- El registro UNDO hará que los datos sean visibles para las transacciones antiguas al ver las versiones anteriores
- DESHACER se utilizará para revertir los efectos de las transacciones abortadas
- los cambios ocurren en el lugar. Las versiones antiguas ya no se guardan en los archivos de datos.
Objetivos de alto nivel:
- mejor control de la hinchazón
- menos escrituras
- encabezados de tupla más pequeños
Esto pondrá a PostgreSQL a la par con MySql y Oracle en este sentido.
Consulta paralela en PostgreSQL:¿Cómo no usarlo (mal)?
En esta presentación de Amit Kapila y Rafia Sabih (EnterpriseDB) aprendimos los aspectos internos de la paralelización y también consejos para evitar errores comunes, así como algunas configuraciones de GUC recomendadas:
- el paralelismo solo admite índices de árbol B
- max_parallel_workers_per_gather establecido en 1→ 4 (según los núcleos disponibles)
- preste atención a las siguientes configuraciones:
- parallel_tuple_cost:costo de transferir una tupla de un proceso de trabajo paralelo a otro proceso
- parallel_setup_cost:costo de lanzar trabajadores paralelos e inicializar la memoria compartida dinámica
- min_parallel_table_scan_size:el tamaño mínimo de las relaciones a considerar para el escaneo de secuencia paralela
- min_parallel_index_scan_size:el tamaño mínimo de índice a considerar para un escaneo paralelo
- random_page_cost:coste estimado de acceder a una página aleatoria en disco
