Segundo día del CHAR(11)

Tema: 

Como comente en el artículo anterior de este blog, el 11 y 12 de Julio se realizó la conferencia CHAR(11). Y al igual que el lunes 11, el programa del martes 12 fue impresionante. Así que aprovechare el viaje en tren a Londres para comentarles un poco lo que pasó.

Empezaron Yeb Havinga y Willem Dijkstra hablando sobre MGRID, este es un sistema médico basado en PostgreSQL (en realidad, tiene su propio fork de PostgreSQL) y que implementa Alta Disponiblidad y procesamiento paralelo de consultas, además implementa una serie de nuevos tipos de datos de uso médico y clínico. Luego Koichi Suzuki hablo sobre el proyecto que el mismo dirije Postgres-XC, otro fork de PostgreSQL, el objetivo de este proyecto es dar escalibilidad nativa a PostgreSQL no solo en lecturas como tiene ahora con Hot Standby pero también en escrituras; lo que Postgres-XC propone es tener varios nodos en el cluster y que todos los nodos permitan tanto consultar como escribir y para lograr esto tiene un nodo al que llama Global Transaction Manager (GTM) que es un coordinador entre todos los nodos. Aun no está disponible para producción pero hay varias versiones disponibles para pruebas en http://postgres-xc.sourceforge.net y según Koichi habrá suficientas mejoras para liberar un sistema para producción a finales de este año.

Luego de un corto break reiniciamos con otro fork, Greenplum, primero Rob Klopp nos habló de los beneficios de este fork de PostgreSQL orientado a OLAP; según el comento Greenplum es capaz de resolver una consulta simple que retorne 1 registro con 10 columnas de una tabla de 20T (si, son TERAS no me equivoque) y mas de 100 columnas en 0.25s (esto es casi la mitad de un segundo) y sin necesidad de crear índices (es decir, que el SELECT recorrera los 20T buscando el bendito registro), está última parte es importante en sistemas OLAP que son reconstruidos todos los días y que requeriría tener que crear nuevos (y diferentes) índices cada pocos días o cada día. Para lograr este milagro Greenplum necesitó (este es un caso real) un cluster de al menos 6 nodos particionando los datos apropiadamente (cosa que Greenplum implementa de forma nativa), compresión de registros, almacenamiento por columnas (Greenplum permite tener unas tablas almacenadas por columnas y otras por registros e incluso mezclar esto entre particiones de la misma tabla), selección diferenciada de columnas (estos es que las otras 90 columnas de la tabla nunca las lee) y un par de trucos mas que no recuerdo. Greenplum, es un sistema comercial con una versión community que es estable y está en producción. Una de las cosas de las que habló Rob es que necesitan mejorar la comunicación con la comunidad de PostgreSQL para lograr incluir en Greenplum las últimas características de PostgreSQL y así mismo compartir parte del código de Greenplum con PostgreSQL. Luego Lee Fedden explicó algunos pasos para migrar de PostgreSQL a Greenplum.

En total fueron 3 forks; MGRID, para sistemas médicos; Postgres-XC, para escribir y leer muchas veces de forma escalable; y Greenplum, para escribir una vez y leer muchas veces de forma insanamente rápida y escalable sin necesidad de tunear la base cada vez. Sin duda todos tienen algo interesante y un fundamento muy sólido: PostgreSQL.

Luego del almuerzo Dimitri Fontaine, explicó algunas de las mejoras en Skytools 3 (los skytools son un grupo de herramientas escritas originalmente por skype para lograr escalabilidad en PostgreSQL y liberadas desde el inicio con licencia BSD); entre las mejoras más interesantes está el hecho de que londiste ahora tiene replicación en cascada y ejecución coordinada de sentencias DDL entre los nodos. PGQ también tiene algunas mejoras; PGQ es un sistema de encolamiento de eventos del que hace uso londiste para replicar de forma ordenada, pero no es solo usable por londiste tiene un API sencillo que permite que otros sistemas lo usen (estoy esperando a ver el uso que le dio Milton Labanda y que creo mencionará en el PGDay Ecuador 2011 este 10 de Septiembre). Los siguientes fueron Gabriele Bartolini y Marco Nenciarini mostraron un caso en el que necesitaban sacar respaldos físicos periodicos de una base Greenplum de varios Teras, el resultado fue una herramienta llamada Greenback (que lleva un tiempo en producción en la empresa que la requería y proximamente será liberada como ocurre con casi todas las herramientas desarrolladas en 2ndQuadrant). Al final de este bloque Hannu Krosing explicó los retos que hay que solventar para lograr verdadera escalabilidad infinita sin sacfrificar areas escenciales.

Este bloque fue dedicado a 2ndQuadrant parece, pero no es de extrañar siendo los principales patrocinadores y originadores de este evento.

Al final vinieron los casos de éxito. Martín Ericksson de Albourne, una empresa que ayuda a determinar las mejores inversiones y que tiene una base pequeña (de apenas 20Gb) como cambiar de Slony I a Streaming Replication le ayudó a mejorar la eficiencia y disminuir los problemas en su cluster intercontinental (ellos tienen nodos en USA y varios países de Europa). Luego, Daniel Farina de Heroku, una empresa que ofrece "cloud application platform"; es decir, que corren nuestra aplicación en la nube de modo que nuestro tiempo se dedique a la aplicación y no al mantenimiento de servidores; y el explicó los problemas que tuvieron que afrontar y como PostgreSQL les ayudó a solucionarlos de forma fácil y eficiente.

Finalmente, Simon Riggs cerró la sesión y el evento. Dos días de mucha información sumamente útil, de buena cerveza y conversaciones sumamente interesantes. Fue único ver (y participar en) una conversación en la que Daniel Farina exponía una característica que le gustaría agregar a PostgreSQL y ver esa característica hecha pedazos por Jan Wieck y un poco por mi también hasta lograr sacar algo que realmente parece una propuesta útil, esperemos que Daniel pueda avanzar en ese tema.

Pero bueno, ya he perdido media hora de paseo por Londres y el café del Starbucks se me esta acabando así que nos vemos en el PGDay Ecuador 2011. No lo olviden el 10 de Septiembre en Quito (mas información en http://wiki.postgresql.org/wiki/PGDay_Ecuador_2011, aunque aun falta información se ira agregando de a poco).

Comentarios

cómo implementaron la alta

a cual de los expositores en particular te refieres?

un método "normal" de lograr Alta Disponibilidad en postgres es una mezcla de hertbeat+pgpool, Diego Biazus mostro una configuración para eso en el 2008 en un PGDay en Argentina: http://www.arpug.com.ar/pgday2008/slides/postgresql-ha-es.pdf

aunque, hoy en dia yo eliminaria pgpool de la ecuación y usaria postgres 9.0 con su caracteristica llamada Streaming Replication (la replicacion integrada de postgres)

otra manera es usar la v2 de repmgr (http://www.repmgr.org) pero como esa version aun esta en beta yo te diria que primero pruebes

Jaime Casanova
www.2ndQuadrant.com

Alta Disponibilidad

Por cierto, estas consciente que para lograr *verdadera* Alta Disponibilidad necesitas al menos 3 nodos en diferentes ubicaciones, verdad?
Tener 2 nodos en el mismo centro de computo no vale de nada...

Jaime Casanova
www.2ndQuadrant.com