Bases de datos en HighLoad ++ 2019

Trabajar con una base de datos es lo que afecta significativamente el rendimiento de cualquier servicio web. Si lo intenta , puede organizar una carga alta sin ninguna carga.

Y si lo hace todo sabiamente, resultará procesar las solicitudes de muchos miles de usuarios. Por lo tanto, la programación de HighLoad ++ tradicionalmente tiene muchos informes sobre bases de datos. Tenemos pistas en PostgreSQL, MySQL y ClickHouse, hay varios informes sobre MongoDB (en la mejor tradición, el orador es un ingeniero de rendimiento en MongoDB). Además, hay discursos sobre la comparación de diferentes enfoques o la consideración de soluciones especializadas. Y en general, agreguemos Tarantool y en memoria aquí. Un total de 33 informes están directamente relacionados con la sección "Bases de datos y sistemas de almacenamiento" y al menos 10 indirectamente. Y esto no cuenta los mitaps , que no son menos de diez, y se agregarán nuevos a lo largo del camino.

Intentaremos ayudarlo a navegar en toda su diversidad y no perderse informes verdaderamente únicos. Para mayor confiabilidad, solicitamos la opinión del miembro del Comité del Programa responsable de esta sección, Nikolay Samokhvalov. Y no parezca que Nikolai es el fundador de Postgres.ai y, en general, postgresmen: está bien versado en el mundo de las bases de datos, conoce interesantes historias y tendencias entre bastidores.

La revisión está organizada de la manera más simple posible: abrimos la lista de informes y fuimos de arriba a abajo, haciendo hincapié en aquellos temas a los que se debe prestar atención.

ClickHouse Query Profiler

El generador de perfiles de consulta en bases de datos analíticas es algo muy interesante. El enfoque debe ser muy diferente de las bases de datos OLTP, porque, por regla general, las consultas se realizan en bases de datos analíticas durante mucho tiempo. Si en PostgreSQL el plan de ejecución de la consulta es estático, entonces tiene sentido monitorear casi una consulta.

En este informe, Nikita Lapkov hablará sobre el dispositivo de dicho generador de perfiles para las solicitudes de ClickHouse, lo que le permite determinar qué sección del código se ralentiza para una solicitud en particular . Y tome las medidas adecuadas para implementar el famoso "ClickHouse no se ralentiza".

Respaldo en infraestructura moderna

Este informe es solo de la serie "al lado de la base de datos", que considera el problema del sistema, pero la mayor parte está dedicado al tema de las copias de seguridad en MySQL. La historia de Anton Turetsky ciertamente será interesante, porque es la experiencia de Badoo, es decir, se trata de una gran cantidad de servidores . En tal escala, hacer copias de seguridad y, lo más importante, verificar todo es una tarea no trivial. Además, lograron hacerse amigos de las tendencias y paradigmas modernos de diseño de sistemas con respaldo para no perder la confianza de que se pueden obtener los datos necesarios en cualquier caso, incluso en el más crítico.

NB: las copias de seguridad sin verificación automática no son copias de seguridad.

Mudarse a ClickHouse: 3 años después

ClickHouse conquista con confianza su posición, pero pocos desarrolladores externos lograron acumular una sólida experiencia trabajando con él. Alexander Zaitsev y Altinity son pioneros en el uso de ClickHouse; ya hace 3 años en HighLoad ++ hablaron acerca de mover un sistema analítico de múltiples petabytes a ClickHouse.

¿Qué ha cambiado desde entonces? Alexander compartirá su experiencia y conocimientos, que no se pueden encontrar en la documentación.

MongoDB vs. Puntos de referencia de Postgres

Dos invitados hablarán sobre MongoDB en HighLoad ++. El informe Álvaro Hernández tiene un fondo interesante, incluso escandaloso. Cuando Alvaro hizo e introdujo puntos de referencia que comparaban MongoDB y PostgreSQL, estalló una escaramuza en Internet. MongoDB más tarde presentó sus puntos de referencia.

Como resultado, cada uno de los mundos simplemente tiene su propia filosofía. Los adherentes a PostgreSQL tienen dificultades para aceptar una actitud tan difusa hacia los datos, pero las soluciones de MongoDB tienen demanda en el mercado. Compararlos directamente es casi imposible, y esto hace que el informe de Alvaro sea muy emocionante. Es fácil adherirse ciegamente a un punto de vista, pero es mucho mejor conocer y comprender ambos.

Este es un hecho divertido para todos: Michael Stonebreaker participó. Llamó la atención sobre la disputa entre Postgres y Mongo y publicó varios artículos sobre los problemas de este modelo. Es decir, el fundador de Postgres, que en un momento dijo que un tamaño no es adecuado para todos, y como resultado lanzó la creación de bases de datos especializadas, incluido NoSQL, ahora está volviendo esencialmente a Postgres. Escribe qué problemas hay, sugiere casarse con modelos de datos y, en general, dice que todo está bien con Postgres. Es muy interesante ver este ciclo de veinte años.

MongoDB distribuyó transacciones de arriba a abajo

El segundo informe sobre MongoDB será realizado por Henrik Ingo, el arquitecto de soluciones de MongoDB, especializado en mejorar el rendimiento de MongoDB y proporcionar alta disponibilidad. Pero Henrik, antes de MongoDB, trabajó en el mundo MySQL durante muchos años, por lo que conoce exactamente los argumentos de varios campos.

En HighLoad ++, Henrik le dirá cómo hacer que las transacciones en una base de datos NoSQL distribuida satisfagan ACID, y por qué podría necesitarlo.

Hoja de ruta de Odyssey: ¿qué más queremos del extractor de conexiones?

Hace tres semanas, se eliminó la principal limitación de PgBouncer, con la que a menudo se enfrentan las empresas, pero ya logró molestar a todos. Por ejemplo, debido a que era imposible realizar mejoras en el código abierto, los parches Yandex y Avito no se han aceptado durante años.

Yandex no esperó estos cambios e hizo su extractor de conexiones: Odyssey. Es multihilo, tiene chips adicionales, y Andrei Borodin lo contará con más detalle en su informe . Además, será posible discutir la hoja de ruta: qué características del extractor le gustaría ver en las nuevas versiones de la comunidad.

DBA bot Joe. Alivie el dolor del desarrollo del backend

Con este informe, Postgres.ai propone cambiar fundamentalmente el enfoque del desarrollo de backend. En lugar de verificar el código y las consultas en bases de datos pequeñas, verifique en bases de datos grandes e inmediatamente vea el resultado. Suena lógico: si la solicitud es lenta, se detectará de inmediato. Otra cosa es qué hacer para esto, por ejemplo, las copias completas de la base de datos de combate son muy inconvenientes. Aquí es donde el bot artificial de DBA Joe viene al rescate

Joe puede escribir una solicitud o pedir crear un índice, y realizará todas las acciones en una copia de tamaño completo de la base de datos de combate. En cualquier momento, puede comenzar de nuevo, cancelar todos los cambios en unos segundos y soltar los cachés del sistema operativo y del DBMS. Y para el trabajo de diez desarrolladores no necesitan espacio en disco x10. Anatoly Stansler le dirá cómo funciona esta magia y desde qué componentes de código abierto puede intentar recopilarla.

Estimado BORRAR. Errores típicos al realizar operaciones masivas en bases de datos PostgreSQL altamente cargadas

Y si a alguien le parece que no hay nada de malo en eliminar varios millones de filas con un DELETE, cuando se conoce la condición y hay un índice adecuado, debe escuchar el informe de Nikolay Samokhvalov. Si intenta realizar una operación en tales condiciones, lo más probable es que el servicio se caiga, y hay muchas razones para ello de inmediato: DBA no funcionó, los desarrolladores no se comportaron correctamente y el enfoque organizativo era incorrecto.

Nikolay mostrará cómo Postgres.ai ayuda a resolver estos problemas y cómo configurar la protección sin usarla y siempre actúa de manera confiable sin perder el producto. Todo esto se basa en una experiencia real de dolor y enormes pérdidas financieras . Porque parece claro que no puede eliminar de inmediato, pero, por ejemplo, marcar los datos para eliminar primero, pero se encuentran operaciones de bloqueo en un millón de líneas.

Patroni en GitLab.com

GitLab utiliza PostgreSQL para MySQL completo, recientemente abandonado, y para garantizar que HA cambie de REPMGR a Patroni. Patroni fue desarrollado por Zalando, su tarea es cambiar automáticamente si algo le sucedió al asistente y garantizar la disponibilidad del servicio.

Ahora Patroni es el estándar de facto , y GitLab lo ha implementado en su solución en la nube, por un segundo, 25,000,000 de operaciones de extracción de git por día, y está preparando una solución para verificar las instalaciones. Jose Cores Finotto compartirá esta experiencia súper interesante en HighLoad ++ el 7 de noviembre.

StackGres: PostgreSQL nativo de la nube en Kubernetes

Álvaro Hernández, en comparación con PostgreSQL y MongoDB, también presentará el producto StackGres, esencialmente un reemplazo para RDS. Pero hace posible implementar RDS en Kubernetes mucho más barato, configurar copias de seguridad con un mínimo de esfuerzo con un trailer, Patroni para conmutación por error automática, verificación de estado y un montón de herramientas diferentes.

Esta es una empresa prometedora en una dirección similar a la historia de Linux. Hay un kernel de Linux y muchos ensambles diferentes a su alrededor. Vemos lo mismo con respecto a PostgreSQL, que puede considerarse el núcleo de un DBMS, y aparecerán ensamblajes a su alrededor. StackGres tiene buenas posibilidades de ganar popularidad, porque hay un equipo animado y clientes donde puede tomar sus decisiones.

Cerraduras PostgreSQL

Los bloqueos son básicamente un tema que todos los que trabajan con PostgreSQL deberían escuchar. Además, Yegor Rogov, quien se ha establecido como un profesor caído muerto, hablará sobre ellos. Él conoce profundamente el material y lo ayudará a comprender los tipos de bloqueos y comprender cómo leer pg_locks y pg_stat_activity y evitar una serie de errores en el diseño del sistema. El informe de Egor sobre HighLoad ++ es una gran oportunidad no solo para escuchar, sino para hablar con un experto, hacerle sus preguntas y posiblemente discutir problemas completamente diferentes.

Copia de seguridad de DBMS cargado

Andrey Borodin y Georgy Rylov trabajan en Yandex y están desarrollando WAL-G, una herramienta de respaldo de código abierto.

Inicialmente, WAL-G es una herramienta para PostgreSQL desarrollada por Citus (es curioso que Microsoft haya absorbido recientemente Citus, es decir, de hecho, compró una pieza de PostgreSQL). Pero resultó que la idea de organizar el trabajo con WAL-G se adapta bien a otras bases de datos. Andrew y George solo hablarán sobre la funcionalidad de MySQL, Redis, MongoDB y las perspectivas que se abren en relación con esto.

Vitess: escalando sin miedo en la nube

Sugu Sougoumarane es el fundador de PlanetScale. Es posible que aún no haya oído hablar de esta compañía, pero recientemente recibió fondos de $ 25 millones para desarrollar su producto abierto Vitess. Es posible que tampoco hayas oído hablar de Vitess. Por lo tanto, Vitess es un sistema de fragmentación de MySQL , y definitivamente conoce a más de una gran empresa que utiliza Vitess para bases de datos altamente cargadas.

Todo comenzó con YouTube. Fue allí donde Sugu y su equipo crearon lo que más tarde se convirtió en el sistema de código abierto Vitess. Por cierto, eligieron Go, un idioma muy joven en ese momento. Sugu puede contar muchas historias interesantes sobre los primeros años de Go y sobre su desarrollo en general: en Google, su equipo se convirtió en el primer usuario importante del idioma.

Bueno, ahora, además de YouTube, Vitess es utilizado por compañías como GitHub, Pinterest, Slack, Square. Después de dejar Google, Sugu fundó PlanetScale y continúa desarrollando Vitess, manteniendo el código abierto. Venga a escuchar sobre fragmentación a escala planetaria y sobre el uso de Go en Highload real. Y no olvide preguntar sobre los planes para la versión Postgres de Vitess: Sugu ama mucho esta pregunta.

Historias de fallas de Patroni o cómo bloquear su clúster PostgreSQL

Es curioso que escuchemos al responsable principal de Patroni sobre un tema diferente , porque ya nos habló de Patroni. Pero Aleksey Lesovsky puede decir cómo se explota a Patroni fuera de Zalando y qué conos se rellenan. Debido a que estos conos pueden ser muy diferentes, y Alex promete compartir los detalles de casos reales de accidentes . Aprenderemos del informe qué problemas hay, qué lecciones se han aprendido en Data Egret y cómo configurar Patroni (y, posiblemente, PostgreSQL) correctamente. Y, por supuesto, tenemos una idea de cómo identificar rápidamente los problemas emergentes y solucionarlos rápidamente.

SQL / JSON: implementamos el estándar y no nos detenemos allí

Recientemente, la frontera entre DBMS relacionales y orientados a documentos se ha desdibujado. El estándar SQL tiene funciones para trabajar con JSON, y PostgreSQL es el pionero del soporte efectivo de JSON entre DBMS relacionales . En gran parte gracias a Postgres Professional, el estándar ya se ha implementado parcialmente.

El informe de Alexander Korotkov es una cuenta de primera mano de la implementación de SQL / JSON y su jsonpath "heart" en PostgreSQL. Esa es una oportunidad para conocer las características internas, la experiencia operativa y los planes para el futuro.

PostgreSQL en K8s en Zalando: dos años en batalla

Alexander Kukushkin es coautor de Patroni, pero este año hablará sobre otro desarrollo interesante de Zalando. Hace dos años, comenzaron a desarrollar Postgres-Operator, y en este momento, con su ayuda, los operadores de DBA prestan servicio a más de 1000 clústeres de Postgres que se ejecutan en Kubernetes.

Si bien algunos aún dudan de si las bases de datos son posibles en Kubernetes, las grandes empresas ya están trabajando con todo esto. Sería genial conocer y aprender de otro lugar.

Enterprise llama a Postgres

Las grandes empresas utilizan cada vez más PostgreSQL, a menudo esperan de él a lo que están acostumbradas en la empresa. Un ejemplo típico: necesitamos soluciones para la replicación lógica, recurrimos al proveedor. Y algunos proveedores incluso hicieron tal soporte: existía Oracle, ahora apareció PostgreSQL. Pero comenzamos a entender, y resulta que muchas cosas funcionan de manera diferente.

Estamos presenciando la colisión de los mundos del código abierto y la empresa. Andreessen Horowitz publicó recientemente un estudio que dice que el interés de los inversores en el código abierto ha crecido sustancialmente y seguirá creciendo. Por lo tanto, los proveedores deben cambiar a código abierto y nuevos modelos de monetización; esto será mejor por varias razones.

Ivan Panchenko le dirá exactamente qué dificultades de migración a PostgreSQL para empresas son subjetivas y pertenecen al tipo de "manos torcidas", y cuándo son estos desafíos importantes que PostgreSQL tiene que enfrentar durante su desarrollo. Los resúmenes prometen la discusión de tales temas: factores de escala (tamaños de tabla, número de objetos, memoria, conexiones, replicación), características de almacenamiento (montón, almacenamientos conectables), tablas temporales, vacío, interacción con el sistema operativo.

Y en esta nota, el futuro es de código abierto , completaremos un estudio detallado de los informes. Desafortunadamente, detrás de escena MySQL se quedó casi completamente atrás. Si este es tu tema, echa un vistazo a Vittorio Cioe y Alkin Tezuysal .

ClickHouse también se presenta en una mayor cantidad de informes, y como siempre, un mitap es de especial valor donde puede hacer cualquier pregunta sobre ClickHouse, junto con los desarrolladores encontrar una solución a los problemas, discutir oportunidades y planes.

Tampoco tocamos Tarantool, ya que se trata de una base de datos y un servidor de aplicaciones en una botella. Y los informes en el programa HighLoad ++ 2019 se centran en esta multifuncionalidad. Vasily Tyubek hablará sobre el operador de Tarantool Kubernetes para ejecutar una base de datos en Kubernetes, Yaroslav Dynnikov mostrará la conveniencia de construir sistemas distribuidos utilizando Tarantool. Y no pierda la oportunidad de aclarar todos los detalles con los propios desarrolladores: es mucho más productivo e interesante que leer la documentación.

En general, consideramos las preguntas a los oradores, las discusiones entre bastidores y la creación de redes, una parte muy importante de la conferencia, si no la más importante. Por lo tanto, creamos todas las condiciones para la comunicación informal y tratamos de pasar un buen rato.

Los días 7 y 8 de noviembre, HighLoad ++ llenará SKOLKOVO hasta el borde y saldrá de él. En Novosibirsk y San Petersburgo habrá sus sucursales HighLoad ++ con una teleconferencia al Salón Principal y todos los beneficios de la creación de redes en la conferencia. En youtube, lanzaremos una transmisión de video abierta de los informes más esperados y el Premio HighLoad ++ , y en el canal de telegramas a lo largo del otro camino, lanzaremos los agentes de traducción de texto. En resumen, incluso si no va a HighLoad ++ (en vano, aún puede cambiar de opinión, obtener un boleto y despegar), aún puede obtener mucho bien y diversión a través de nuestras redes.