Re: PG11: particionado, parallel query y performance

Hola lista.

Recupero este hilo porque queremos incluir una nueva funcionalidad a
nuestra plataforma que sería pgpool-II.

Partiendo del correo anterior, os explico: Tenemos varios aplicativos que
trabajan con libpq(unos 200 aproximadamente → 100+100 ya que están
duplicados por redundancia) instalados en diferentes máquinas que consultan
y escriben exclusivamente en una BD master (PG11.4). Todos estos
aplicativos mantienen una conexión permanente para poder procesar NOTIFYs a
parte de crear una nueva conexión por cada thread (aproximadamente se abren
unas 20 conexiones a BD por segundo en total y mayormente llegan a estar
abiertos como mucho 1 segundo). Es imperativo que estos aplicativos tengan
la máxima disponibilidad posible.

Otros aplicativos (unos 50), también instalados en diferentes VM, escriben
en la master y consultan en la réplica(instalada en otra VM del mismo
datacenter). Se han programado específicamente para que trabajen de este
modo. Varios de ellos gestionan su propio pool, como por ejemplo tenemos 3
backends WEB(apache tomcat) que mantienen 20 conexiones cada uno. Otros se
ejecutan por cron (scripts perl, python, bash). Es importante la alta
disponibilidad en estos aplicativos pero no tienen tanta prioridad como los
primeros.

Finalmente tenemos unos scripts(10 aproximadamente) sólo de consulta que
usan una 3a BD que también es réplica(simplemente está configurada con un
timeout mayor para consultas lentas). Suelen ser para grandes volúmenes de
datos y procesamiento. En este caso, los aplicativos pueden esperan a su
ejecución en caso de fallo.

Después de este rollo macabro jaja, y después de hacer un primer análisis
de la documentación de pgpool, me gustaría saber las ventajas reales y el
partido que le puedo sacar a pgpool-II.

Entiendo que:

- Me ahorraría el pool (tanto escritura como lectura) en nuevos
aplicativos.
- No tendría que preocuparme del número de conexiones en postgres.
- Reduciría carga de sistema?
- Que tal los tiempos de respuesta? Lo pregunto ya que tenemos un
intermediario y creo que eso puede tener una penalización.
- Que tal el rendimento de las consultas?
- ...(Sinceramente no tengo ni idea si me aporta algo interesante, mi
ignorancia me da dolor de cabeza jaja)

Si pudieran darme sus experiencias se lo agradecería.

Muchas gracias.

On Tue, 9 Jul 2019 at 15:20, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
wrote:

> Ruben Fitó escribió:
>
> Hola
>
> > - Nuestro objetivo para el uso de particionado(por año) es la de
> evitar
> > hacer purgados.
>
> Excelente, ese es uno de los principales motivos para particionar.
>
> > - El otro objetivo es de optimizar consultas porque reducimos el
> volumen
> > de datos por tabla.
>
> Cierto, siempre y cuando esas consultas tengan que recorrer grandes
> porciones de las tablas. Si tus consultas usan mayormente recorridos
> localizados de índice, no ganarás mucho con particionar.
>
> > - Si una consulta afecta a varias tablas particionadas, cómo afecta al
> > rendimiento. "Parallel query" ayuda? Entiendo que los índices se
> heredan en
> > PG11, ...
>
> El particionamiento ayuda a las consultas sobre todo porque ocurre
> "pruning",
> es decir que el optimizador puede evitar recorrer las particiones que
> pueda demostrar (basado en los WHERE y demás) que no necesita recorrer.
> Parallel query ayuda tal como si fuera una consulta sobre una sola
> tabla. Los índices se "heredan" pero esto sólo quiere decir que los
> índices se crean automáticamente en las particiones; no tiene ninguna
> implicancia desde el punto de vista de la optimización de la consulta.
>
> > - Cuándo tiene efecto el "Parallel query"?
>
> Siempre que sea útil.
>
> > - Qué tal han trabajado con JIT?
>
> Está bueno, puede darte un pequeño % de mejora pero no esperes nada muy
> increíble todavía. Quizás en un par de años más. Pero sí está algo
> verde en algunas partes, así que pruébalo con cuidado y reporta
> cualquier comportamiento inesperado o sospechoso.
>
> > - ¿Qué debería tener en cuenta en el momento que empiece a trabajar
> con
> > particionado? Algún consejo, alguna mala experiencia, alguna buena...
>
> Aconsejo probar las operaciones que vas a realizar con cantidades
> razonables de datos, y verificar los planes de ejecución.
>
> Ojo con las definiciones de índices. Hay algunas limitaciones ... por
> ej. si tienes llaves primarias en las tablas particionadas, la PK debe
> incluir la llave de partición.
>
> > - Cómo funciona el particionado con Streaming Replication?
>
> No afecta. Son ortogonales.
>
> > - Y con Logical replication? → Supongo que he de crear todas las
> tablas
> > igual que en master... también se heredan índices?
>
> La replicación lógica tiene algunas limitaciones todavía con tablas
> particionadas. Recomiendo probar con cuidado.
>
> En resumen: es mejor que el año anterior, pero podría ser mejor, y
> seguro que el próximo año será mejor.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>

--
*Ruben Fitó *
Software Engineer
[image: Ubiquat Technologies, SL]
r(dot)fito(at)ubiquat(dot)com <j(dot)catarineu(at)ubiquat(dot)com>
www.ubiquat.com
Tota la informació continguda en aquest document i arxius adjunts és
CONFIDENCIAL protegida per llei de secret comercial. Si l'ha rebut per
error, si us plau elimini'l i posi's en contacte amb l'emissor.

All information contained in this document and any attachments are
CONFIDENTIAL and protected under trade secret laws. If you receive this
message by mistake, please delete it and notify it immediately to the
sender.