Cómo sobrevivir a una base de datos SQL en el siglo XXI: nubes, Kubernetes y PostgreSQL multimaster

Hola, residentes de Khabrovsk. Hoy empiezan las clases del primer grupo del curso "PostgreSQL". En este sentido, nos gustaría contaros cómo se desarrolló el webinar abierto de este curso.

В próxima lección abierta Hablamos sobre los desafíos que enfrentan las bases de datos SQL en la era de las nubes y Kubernetes. Al mismo tiempo, analizamos cómo las bases de datos SQL se adaptan y mutan bajo la influencia de estos desafíos.

Se realizó el seminario web Valery Bezrukov, Gerente de entrega de prácticas de Google Cloud en EPAM Systems.

Cuando los árboles eran pequeños...

Primero, recordemos cómo comenzó la elección de DBMS a finales del siglo pasado. Sin embargo, esto no será difícil, porque la elección de un DBMS en aquellos días comenzaba y terminaba. Oracle.

A finales de los años 90 y principios de los 2, prácticamente no había otra opción cuando se trataba de bases de datos industriales escalables. Sí, hubo IBM DBXNUMX, Sybase y algunas otras bases de datos que iban y venían, pero en general no se notaban tanto en el contexto de Oracle. En consecuencia, las habilidades de los ingenieros de aquellos tiempos estaban de alguna manera ligadas a la única opción que existía.

Oracle DBA tenía que poder:

• instale Oracle Server desde el kit de distribución;
• configurar el servidor Oracle:

• init.ora;
• oyente.ora;

- crear:

• espacios de tabla;
• esquemas;
• usuarios;

— realizar copias de seguridad y restaurar;
— realizar un seguimiento;
— abordar solicitudes subóptimas.

Al mismo tiempo, no hubo ningún requisito especial por parte de Oracle DBA:

• poder elegir el DBMS óptimo u otra tecnología para almacenar y procesar datos;
• proporcionar alta disponibilidad y escalabilidad horizontal (esto no siempre fue un problema de DBA);
• buen conocimiento del área temática, infraestructura, arquitectura de aplicaciones, sistema operativo;
• cargar y descargar datos, migrar datos entre diferentes DBMS.

En general, si hablamos de la elección en aquellos días, se parece a la elección en una tienda soviética de finales de los 80:

Nuestro tiempo

Desde entonces, por supuesto, los árboles han crecido, el mundo ha cambiado y se ha convertido en algo como esto:

El mercado de DBMS también ha cambiado, como se desprende claramente del último informe de Gartner:

Y aquí cabe señalar que las nubes, cuya popularidad va en aumento, han ocupado su nicho. Si leemos el mismo informe de Gartner, veremos las siguientes conclusiones:

1. Muchos clientes están en el camino de trasladar aplicaciones a la nube.
2. Las nuevas tecnologías aparecen por primera vez en la nube y no es un hecho que algún día vayan a pasar a una infraestructura fuera de la nube.
3. El modelo de precios de pago por uso se ha vuelto común. Todo el mundo quiere pagar sólo por lo que utiliza, y esto ni siquiera es una tendencia, sino simplemente una constatación de un hecho.

Que ahora

Hoy estamos todos en la nube. Y las preguntas que nos surgen son cuestiones de elección. Y es enorme, incluso si hablamos sólo de la elección de tecnologías DBMS en formato local. También contamos con servicios gestionados y SaaS. Por lo tanto, la elección se vuelve cada año más difícil.

Además de las cuestiones de elección, también existen factores limitantes:

• precio. Muchas tecnologías todavía cuestan dinero;
• навыки. Si hablamos de software libre, entonces surge la cuestión de las habilidades, ya que el software libre requiere competencia suficiente por parte de las personas que lo implementan y operan;
• funcional. No todos los servicios que están disponibles en la nube y creados, digamos, incluso en el mismo Postgres, tienen las mismas características que Postgres local. Este es un factor esencial que necesita ser conocido y comprendido. Además, este factor se vuelve más importante que el conocimiento de algunas capacidades ocultas de un único DBMS.

Lo que se espera ahora de DA/DE:

• buena comprensión del área temática y la arquitectura de la aplicación;
• la capacidad de seleccionar correctamente la tecnología DBMS adecuada, teniendo en cuenta la tarea en cuestión;
• la capacidad de seleccionar el método óptimo para implementar la tecnología seleccionada en el contexto de las limitaciones existentes;
• capacidad para realizar transferencias y migraciones de datos;
• Capacidad para implementar y operar soluciones seleccionadas.

A continuación el ejemplo basado en PCG Demuestra cómo funciona la elección de una u otra tecnología para trabajar con datos en función de su estructura:

Tenga en cuenta que PostgreSQL no está incluido en el esquema y esto se debe a que está oculto bajo la terminología Nube SQL. Y cuando lleguemos a Cloud SQL, tendremos que volver a tomar una decisión:

Cabe señalar que esta elección no siempre es clara, por lo que los desarrolladores de aplicaciones suelen guiarse por la intuición.

Total:

1. Cuanto más avanzas, más apremiante se vuelve la cuestión de la elección. E incluso si nos fijamos solo en GCP, servicios administrados y SaaS, alguna mención de RDBMS aparece solo en el cuarto paso (y Spanner está cerca). Además, la elección de PostgreSQL aparece en el quinto paso, y junto a ella también están MySQL y SQL Server, es decir Hay mucho de todo, pero hay que elegir..
2. No debemos olvidarnos de las restricciones en el contexto de las tentaciones. Básicamente todo el mundo quiere una llave inglesa, pero es cara. Como resultado, una solicitud típica se parece a esta: "Por favor, conviértanos en Spanner, pero por el precio de Cloud SQL, ¡ustedes son profesionales!"

¿Qué hacer?

Sin pretender ser la verdad última, digamos lo siguiente:

Necesitamos cambiar nuestro enfoque del aprendizaje:

• no tiene sentido enseñar como se enseñaba antes a los DBA;
• el conocimiento de un producto ya no es suficiente;
• pero conocer decenas al nivel de uno es imposible.

Necesita saber no solo y no cuánto cuesta el producto, sino también:

• caso de uso de su aplicación;
• diferentes métodos de implementación;
• ventajas y desventajas de cada método;
• productos similares y alternativos para hacer una elección informada y óptima y no siempre a favor de un producto familiar.

También debe poder migrar datos y comprender los principios básicos de integración con ETL.

Caso real

En el pasado reciente, era necesario crear un backend para una aplicación móvil. Cuando comenzó a trabajar en él, el backend ya se había desarrollado y estaba listo para su implementación, y el equipo de desarrollo pasó aproximadamente dos años en este proyecto. Se establecieron las siguientes tareas:

• construir CI/CD;
• revisar la arquitectura;
• ponerlo todo en funcionamiento.

La aplicación en sí eran microservicios y el código Python/Django se desarrolló desde cero y directamente en GCP. En cuanto al público objetivo, se suponía que habría dos regiones: EE. UU. y la UE, y el tráfico se distribuiría a través del balanceador de carga global. Todas las cargas de trabajo y la carga de trabajo informática se ejecutaron en Google Kubernetes Engine.

En cuanto a los datos, existían 3 estructuras:

• Almacenamiento en la nube;
• Almacén de datos;
• Nube SQL (PostgreSQL).

Uno podría preguntarse por qué se eligió Cloud SQL. A decir verdad, esta pregunta ha causado una especie de pausa incómoda en los últimos años: existe la sensación de que la gente se ha vuelto tímida con respecto a las bases de datos relacionales, pero aún así continúan usándolas activamente ;-).

En cuanto a nuestro caso, se eligió Cloud SQL por los siguientes motivos:

1. Como se mencionó, la aplicación fue desarrollada usando Django y tiene un modelo para mapear datos persistentes de una base de datos SQL a objetos Python (Django ORM).
2. El marco en sí admitía una lista bastante finita de DBMS:

• PostgresSQL;
• MaríaDB;
• MySQL
• Oráculo
• SQLite.

En consecuencia, PostgreSQL fue elegido de esta lista de manera bastante intuitiva (bueno, en realidad no es Oracle quien elige).

Lo que faltaba:

• la aplicación se implementó sólo en 2 regiones y apareció en planes una tercera (Asia);
• La base de datos estuvo ubicada en la región de Norteamérica (Iowa);
• por parte del cliente había preocupaciones sobre posibles retrasos en el acceso de Europa y Asia y interrupciones en servicio en caso de inactividad del DBMS.

A pesar de que el propio Django puede trabajar con varias bases de datos en paralelo y dividirlas en lectura y escritura, no había tanta escritura en la aplicación (más del 90% es lectura). Y en general, y en general, si fuera posible hacer réplica de lectura de la base principal en Europa y Asia, esta sería una solución de compromiso. Bueno, ¿qué tiene de complicado?

La dificultad era que el cliente no quería dejar de utilizar servicios gestionados y Cloud SQL. Y las capacidades de Cloud SQL son actualmente limitadas. Cloud SQL admite alta disponibilidad (HA) y réplica de lectura (RR), pero el mismo RR solo se admite en una región. Habiendo creado una base de datos en la región americana, no puede realizar una réplica de lectura en la región europea utilizando Cloud SQL, aunque el propio Postgres no le impide hacerlo. La correspondencia con los empleados de Google no condujo a ninguna parte y terminó con promesas del estilo de "conocemos el problema y estamos trabajando en ello, algún día el problema se resolverá".

Si enumeramos brevemente las capacidades de Cloud SQL, se verá así:

1. Alta disponibilidad (HA):

• dentro de una región;
• mediante replicación de disco;
• No se utilizan motores PostgreSQL;
• control automático y manual posible - conmutación por error/recuperación;
• Al cambiar, el DBMS no está disponible durante varios minutos.

2. Leer réplica (RR):

• dentro de una región;
• espera en caliente;
• Replicación de transmisión de PostgreSQL.

Además, como es habitual, a la hora de elegir una tecnología siempre te encuentras con algunos restricciones:

• el cliente no quería crear entidades ni utilizar IaaS, excepto a través de GKE;
• al cliente no le gustaría implementar PostgreSQL/MySQL de autoservicio;
• Bueno, en general, Google Spanner sería bastante adecuado si no fuera por su precio, sin embargo, Django ORM no puede funcionar con él, pero es algo bueno.

Considerando la situación, el cliente recibió una pregunta de seguimiento: "¿Puedes hacer algo similar para que sea como Google Spanner, pero que también funcione con Django ORM?"

Opción de solución nº 0

Lo primero que me vino a la mente:

• permanecer dentro de CloudSQL;
• no habrá replicación integrada entre regiones de ninguna forma;
• intente adjuntar una réplica a un Cloud SQL existente mediante PostgreSQL;
• inicie una instancia de PostgreSQL en algún lugar y de alguna manera, pero al menos no toque master.

Por desgracia, resultó que esto no se puede hacer porque no hay acceso al host (está en un proyecto completamente diferente): pg_hba, etc., y tampoco hay acceso como superusuario.

Opción de solución nº 1

Después de una mayor reflexión y teniendo en cuenta circunstancias anteriores, la línea de pensamiento cambió un poco:

• Todavía estamos intentando permanecer dentro de CloudSQL, pero estamos cambiando a MySQL, porque Cloud SQL de MySQL tiene un maestro externo, que:

— es un proxy para MySQL externo;
- parece una instancia de MySQL;
- inventado para migrar datos desde otras nubes o localmente.

Dado que configurar la replicación MySQL no requiere acceso al host, en principio todo funcionó, pero fue muy inestable e inconveniente. Y cuando avanzamos, se volvió completamente aterrador, porque desplegamos toda la estructura con terraform y de repente resultó que el maestro externo no estaba soportado por terraform. Sí, Google tiene una CLI, pero por alguna razón todo funcionó aquí de vez en cuando: a veces se crea, a veces no se crea. Quizás porque la CLI se inventó para la migración de datos externos y no para réplicas.

De hecho, en este punto quedó claro que Cloud SQL no es adecuado en absoluto. Como dicen, hicimos todo lo que pudimos.

Opción de solución nº 2

Como no era posible permanecer dentro del marco de Cloud SQL, intentamos formular requisitos para una solución de compromiso. Los requisitos resultaron ser los siguientes:

• trabajar en Kubernetes, máximo aprovechamiento de los recursos y capacidades de Kubernetes (DCS, ...) y GCP (LB, ...);
• falta de lastre de un montón de cosas innecesarias en la nube como el proxy HA;
• la capacidad de ejecutar PostgreSQL o MySQL en la región HA principal; en otras regiones: HA del RR de la región principal más su copia (para mayor confiabilidad);
• multi master (no quería contactarlo, pero no era muy importante)

.
Como resultado de estas demandas, pDBMS adecuados y opciones de enlace:

• Galería MySQL;
• CucarachaDB;
• Herramientas PostgreSQL

:
- pgpool-II;
— Patroni.

Galería MySQL

La tecnología MySQL Galera fue desarrollada por Codership y es un complemento para InnoDB. Peculiaridades:

• maestro múltiple;
• replicación sincrónica;
• leer desde cualquier nodo;
• grabar en cualquier nodo;
• mecanismo HA incorporado;
• Hay un gráfico Helm de Bitnami.

Cucarachas

Según la descripción, es absolutamente fantástico y es un proyecto de código abierto escrito en Go. El participante principal es Cockroach Labs (fundado por gente de Google). Este DBMS relacional se diseñó originalmente para ser distribuido (con escalamiento horizontal listo para usar) y tolerante a fallas. Los autores de la empresa describieron el objetivo de "combinar la riqueza de la funcionalidad SQL con la accesibilidad horizontal familiar a las soluciones NoSQL".

Una buena ventaja es la compatibilidad con el protocolo de conexión posterior al ingreso.

grupo de páginas

Este es un complemento de PostgreSQL, de hecho, una nueva entidad que se hace cargo de todas las conexiones y las procesa. Tiene su propio equilibrador de carga y analizador, con licencia BSD. Ofrece amplias oportunidades, pero parece algo aterrador, porque la presencia de una nueva entidad podría convertirse en fuente de algunas aventuras adicionales.

patrón

Esto es lo último que vio y, como resultó, no en vano. Patroni es una utilidad de código abierto, que es esencialmente un demonio de Python que le permite mantener automáticamente clústeres de PostgreSQL con varios tipos de replicación y cambio automático de roles. La cosa resultó muy interesante, ya que se integra bien con el cuber y no introduce ninguna entidad nueva.

¿Qué elegiste al final?

La elección no fue fácil:

1. Cucarachas - fuego, pero oscuro;
2. Galería MySQL - Tampoco está mal, se usa en muchos lugares, pero MySQL;
3. grupo de páginas — muchas entidades innecesarias, integración regular con la nube y los K8;
4. patrón - excelente integración con K8, sin entidades innecesarias, se integra bien con GCP LB.

Así, la elección recayó en Patroni.

Hallazgos

Es hora de resumir brevemente. Sí, el mundo de la infraestructura de TI ha cambiado significativamente y esto es sólo el comienzo. Y si antes las nubes eran un tipo más de infraestructura, ahora todo es diferente. Además, las innovaciones en las nubes aparecen constantemente, aparecerán y, tal vez, aparecerán solo en las nubes y solo entonces, gracias al esfuerzo de las startups, se transferirán a las instalaciones.

En cuanto a SQL, SQL vivirá. Esto significa que necesitas conocer PostgreSQL y MySQL y poder trabajar con ellos, pero aún más importante es poder utilizarlos correctamente.

Fuente: habr.com