El 15 de septiembre, se realizó una reunión en Avito, donde hablamos sobre el escalado de aplicaciones en PostgreSQL. Hoy quiero compartir materiales de él: videos, presentaciones de oradores, fotos de espectáculos. Además, debajo del corte, publico una discusión de las preguntas del cuestionario que realizamos aquí en Habré, antes del mitap. Y hablo sobre mis impresiones de la reunión.
Informes
Transacciones distribuidas y viajes en el tiempo. Stas Kelvich, profesional de Postgres
Stas habló sobre transacciones distribuidas y viajes en el tiempo.
Presentación
Comentarios:
¡Stas y su equipo hicieron un excelente trabajo! Espero que su decisión sea aprobada por la comunidad y veremos esta solución en la nueva versión de Postgres.
Escalar una aplicación en PostgreSQL en Avito: consejos y trucos. Konstantin Evteev, Avito
Hice una presentación sobre escalar una aplicación en PostgreSQL en Avito y compartí nuestros consejos y trucos.
Presentación
Comentarios:
Un enfoque interesante: en el que Kostantin explicó de manera muy interesante e inteligible qué problemas puede encontrar al trabajar con datos en una arquitectura de microservicio, y también sugirió soluciones para escalar IP. Saga es recordada :)
Replicación lógica y niveles de aislamiento de transacciones PostgreSQL. Mikhail Tyurin
Michael preparó un informe sobre replicación lógica y niveles de aislamiento de transacciones PostgreSQL.
Presentación
Comentarios:
Michael destacó los momentos sutiles de las transacciones, que están lejos de ser visibles de inmediato, no solo para los principiantes. Todo el mundo necesita saber sobre esto.
OZO es una biblioteca de cliente PostgreSQL asíncrona de tipo seguro con encabezado solo para C ++ 17. Sergey Handrikov, Yandex
Sergey le contó a la audiencia cómo se organiza OZO, la biblioteca de cliente PostgreSQL asíncrona con encabezado seguro solo para C ++ 17, e invitada a contribuir.
Presentación
Comentarios:
El autor, en mi opinión, logró revelar rápidamente los problemas en las bibliotecas existentes y las soluciones en las nuevas bibliotecas de C ++ en poco tiempo. Por lo tanto, me alegrará si estas bibliotecas se desarrollan en código abierto, las cosas más básicas ya están implementadas, lo que no puede dejar de alegrarse.
Respuestas a las preguntas del cuestionario.
Antes de la reunión, lo invitamos a responder preguntas sobre Postgres. Hoy quiero mostrar las respuestas correctas. Están debajo de los spoilers (por si acaso).
Hay una tabla vacía sin registros de usuarios ("UserId" int, "balance" int). ¿Qué devolverá como resultado de la consulta?
with ins as ( insert into users select gs, gs * 10 from generate_series(1, 4) gs where gs%2 = 0) select * from users;
Lo que devolverá la solicitud select * from users where UserId = 10; al acceder a la tabla de usuarios después de completar el trabajo anterior?
La respuestaERROR: la columna "userid" no existe.
Definido por Enum CREATE TYPE status AS ENUM ('wait', 'init', 'run', 'stop'); ¿Qué comando puede eliminar el valor de 'init'?
La respuestaNo hay una forma estándar de eliminar un valor de enum.
¿Cómo puedo obtener una lista de funciones en PostgreSQL?
¿Qué devolverá como resultado de la consulta?
select null = null, null is null, 1::smallint::boolean is true, null::bigint > 1
La respuestaERROR: no se puede convertir el tipo smallint a boolean.
El desarrollador junior Vasya recibió instrucciones de escribir una consulta que muestre todas las entradas de la tabla parent para las cuales no hay entradas en la tabla child .
Esquema de datos:
create table parent (parent_id serial primary key, payload text); create table child (child_id serial primary key, parent_id integer unique references parent (parent_id));
Vasya se esforzó mucho y no quiso enfrentar la suciedad, por lo que se le ocurrieron ocho consultas diferentes para resolver el problema:
-- 0 select p.parent_id, p.payload from parent p where not exists(select from child c where c.parent_id = p.parent_id); -- 1 select p.parent_id, p.payload from parent p where not (array[p.parent_id] && array(select c.parent_id from child c)); -- 2 select distinct p.parent_id, p.payload from parent p full join child c on (c.parent_id = p.parent_id) where c.parent_id is null; -- 3 select p.parent_id, p.payload from parent p where p.parent_id not in (select c.parent_id from child c); -- 4 select p.parent_id, p.payload from parent p left join child c on (c.parent_id = p.parent_id) where c.parent_id is null; -- 5 with w_child_with_parents as ( select c.parent_id, ( select count(*) from parent p where c.parent_id = p.parent_id) = 1 as parent_exists from child c) select p.parent_id, p.payload from parent p where p.parent_id in (select pc.parent_id from w_child_with_parents pc where not pc.parent_exists); -- 6 select p.parent_id, p.payload from parent p full join child c on (c.parent_id = p.parent_id) group by p.parent_id, p.payload having count(c) = 0; -- 7 select p.parent_id, p.payload from parent p where p.parent_id in ( select p2.parent_id from parent p2 except all select c2.parent_id from child c2);
Vasya te presentó sus opciones para que pudieras ayudarlo a elegir la mejor. Afirma que todas las consultas funcionan de la misma manera: las tablas se colocan en la memoria y la diferencia en el rendimiento no es significativa (o incluso invisible). Sin embargo, usted, como desarrollador más experimentado, ha notado que quizás no todas las solicitudes resuelven la tarea. Enumere las consultas que no resuelven la tarea (y explique por qué).
Respuesta cortaLas tareas 2, 3 y 5 no resuelven este problema (en algunos casos, también solicitan 1).
La respuesta al resultado del experimento.Datos de prueba:
La "incorrección" del comportamiento se manifiesta cuando hay registros en la tabla secundaria con parent_id es nulo.
insert into parent (parent_id, payload) values (1, 'payload 1'), (2, 'payload 2'), (3, 'payload 3'), (4, 'payload 4'), (5, 'payload 5'); insert into child (child_id, parent_id) values (1, 1), (2, 3), (3, null), (5, 5);
En los datos de prueba dados
- La consulta 1, dependiendo de si la extensión intarray está instalada, puede o no funcionar.
- La consulta 2 devuelve una cadena adicional (nula, nula).
- Las consultas 3 y 5 devuelven un conjunto de resultados vacío.
Interpretación de resultados experimentales.
Solicitud 1: en caso de que la extensión intarray esté instalada en la base de datos ( https://www.postgresql.org/docs/current/static/intarray.html ), la solicitud se bloquea con el error "ERROR: la matriz no debe contener valores nulos". Este comportamiento se debe al hecho de que la extensión anula los operadores estándar y cambia el comportamiento de las matrices que contienen elementos nulos.
La documentación dice lo siguiente:
Los operadores &&, @> y <@ son equivalentes a los operadores integrados de PostgreSQL con los mismos nombres, excepto que funcionan solo en matrices enteras que no contienen valores nulos, mientras que los operadores integrados funcionan para cualquier tipo de matriz. Esta restricción los hace más rápidos que los operadores integrados en muchos casos.
Solicitud 2: debido a la unión completa, como resultado aparece una cadena adicional (nula, nula).
Solicitud 3: devuelve un conjunto de resultados vacío debido al hecho de que el conjunto formado por la subconsulta tiene elementos nulos.
Documentación ( https://www.postgresql.org/docs/current/static/functions-subquery.html#FUNCTIONS-SUBQUERY-NOTIN ):
Tenga en cuenta que si la expresión de la izquierda produce un valor nulo, o si no hay valores iguales de la derecha y al menos una fila de la derecha produce un valor nulo, el resultado de la construcción NOT IN será nulo, no verdadero. Esto está de acuerdo con las reglas normales de SQL para combinaciones booleanas de valores nulos.
Consulta 5: devuelve un conjunto de resultados vacío porque se llama a la sección w_child_with_parents, las tablas child y parent_id están vacías o no se reflejan en absoluto en la sección.
Todas las preguntas del cuestionario fueron respondidas correctamente por tres participantes. Entregamos uno al premio en la reunión, dos juegos más de recuerdos fueron enviados por correo.
Epílogo
Más de cien personas vinieron a la reunión. Fue muy agradable conocer a tal audiencia. Según una encuesta, más del 60% de los huéspedes de mitap tienen experiencia trabajando con bases de datos durante más de cinco años. Y es muy agradable cuando los informes reciben una reacción tan viva de la audiencia:
Al margen de las reuniones, se habló mucho sobre PostgreSQL como una herramienta cada vez más común. Realmente lo es Aprovecharé esta oportunidad para decir que en Avito planeamos expandir el equipo de DBA, y si estás interesado en tareas ambiciosas en un proyecto grande, mira la vacante en Mi Círculo o escríbeme.
En conclusión, quiero agradecer a los colegas de Yandex, Postgres Professional y, por supuesto, Avito por los maravillosos informes que escuchamos. Gracias a los invitados que vinieron a nosotros este sábado día y a los espectadores en vivo. Y, por supuesto, la comunidad #RuPostgres por su confianza.
Lista de reproducción con todos los informes aquí .
Publicamos reportajes fotográficos en Facebook y VKontakte .
Hasta pronto!