Re: PG11: particionado, parallel query y performance
Buenos días Álvaro. Es muy interesante la propuesta que haces. Como siempre, iba perdido y pensaba que pgpool era el más liviano Voy a echarle un vistazo a pgbouncer y a Odyssey y a ver si puedo sacarle un buen partido. Gracias. Un saludo On Thu, 8 Aug 2019 at 18:27, Alvaro Herrera wrote: > Ruben Fitó escribió: > > > Entiendo que: > > > >- Me ahorraría el pool (tanto escritura como lectura) en nuevos > >aplicativos. > > Sí, puede ser. > > >- No tendría que preocuparme del número de conexiones en postgres. > > Correcto. > > >- Reduciría carga de sistema? > > Más que seguro que sí. Abrir conexiones en Postgres es bastante pesado; > abrirlas en el pooler y permitir que éste las mantenga abiertas a Postgres > es muchísimo mejor. > > >- Que tal los tiempos de respuesta? Lo pregunto ya que tenemos un > >intermediario y creo que eso puede tener una penalización. > > Se supone que es liviano, aunque pgpool tiene un montón de cosas > adicionales a la tarea del pool propiamente dicho. pgbouncer se nota > muy poco. Hay un pooler de conexiones nuevo de los rusos que dicen que > funciona mejor que pgbouncer, Odyssey, aunque desconozco en qué estado > está. > > Yo consideraría la idea de usar un pooler más liviano que pgpool (como > pgbouncer que ya está "probado en batalla" u Odyssey, que es tecnología > más nueva y por lo tanto más verde pero es mejor en papel), y mantener > la arquitectura de que las apps sepan de conexiones separadas para > escritura vs. lectura. > > Saludos > > -- > Álvaro Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > -- *Ruben Fitó * Software Engineer [image: Ubiquat Technologies, SL] r.f...@ubiquat.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.
Re: PG11: particionado, parallel query y performance
Ruben Fitó escribió: > Entiendo que: > >- Me ahorraría el pool (tanto escritura como lectura) en nuevos >aplicativos. Sí, puede ser. >- No tendría que preocuparme del número de conexiones en postgres. Correcto. >- Reduciría carga de sistema? Más que seguro que sí. Abrir conexiones en Postgres es bastante pesado; abrirlas en el pooler y permitir que éste las mantenga abiertas a Postgres es muchísimo mejor. >- Que tal los tiempos de respuesta? Lo pregunto ya que tenemos un >intermediario y creo que eso puede tener una penalización. Se supone que es liviano, aunque pgpool tiene un montón de cosas adicionales a la tarea del pool propiamente dicho. pgbouncer se nota muy poco. Hay un pooler de conexiones nuevo de los rusos que dicen que funciona mejor que pgbouncer, Odyssey, aunque desconozco en qué estado está. Yo consideraría la idea de usar un pooler más liviano que pgpool (como pgbouncer que ya está "probado en batalla" u Odyssey, que es tecnología más nueva y por lo tanto más verde pero es mejor en papel), y mantener la arquitectura de que las apps sepan de conexiones separadas para escritura vs. lectura. Saludos -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 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
Re: PG11: particionado, parallel query y performance
Mil gracias Martín por su repuesta, no leí la letra menuda de la documentación! 樂 El dom., 14 de jul. de 2019 3:05 PM, Martín Marqués escribió: > Buenas Hellmuth, > > El 12/7/19 a las 07:24, Hellmuth Vargas escribió: > > Hola Alvaro > > > > Me llama la atención lo que menciona sobre las limitaciones del > > particionamiento y la replicación lógica, no puede indicar a que > > limitaciones se refiere... Estoy también interesado en implementar una > > solución basado en esto... De antemano muchas gracias > > Eso es porque la replicación lógica solo se puede hacer entre tablas > físicas. Tratar de replicar la table raíz de una partición terminará en > un error así: > > ERROR: logical replication target relation "public.mypartitiontable" is > not a table > > Dicha restriccion esta en la documentacion de replicación lógica: > > https://www.postgresql.org/docs/11/logical-replication-restrictions.html > > ``` > Replication is only possible from base tables to base tables. That is, > the tables on the publication and on the subscription side must be > normal tables, not views, materialized views, partition root tables, or > foreign tables. In the case of partitions, you can therefore replicate a > partition hierarchy one-to-one, but you cannot currently replicate to a > differently partitioned setup. Attempts to replicate tables other than > base tables will result in an error. > ``` > > Saludos, > > -- > Martín Marquéshttp://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
Re: PG11: particionado, parallel query y performance
Hola Alvaro Me llama la atención lo que menciona sobre las limitaciones del particionamiento y la replicación lógica, no puede indicar a que limitaciones se refiere... Estoy también interesado en implementar una solución basado en esto... De antemano muchas gracias El mar., 9 de jul. de 2019 8:20 AM, Alvaro Herrera escribió: > 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 Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > > >
Re: PG11: particionado, parallel query y performance
Muchas gracias Álvaro. Dedicaré esfuerzos en los puntos que has remarcado y continuaremos adelante con el cambio. Esperemos haber tomado una buena decisión. ;-) Saludos On Tue, 9 Jul 2019 at 15:20, Alvaro Herrera 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 Herrerahttps://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > -- *Ruben Fitó * Software Engineer [image: Ubiquat Technologies, SL] r.f...@ubiquat.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.
