¡Hola a todos! Mi nombre es Golov Nikolay. Anteriormente trabajé en Avito y administré la Plataforma de Datos durante seis años, es decir, trabajé en todas las bases de datos: analítica (Vertica, ClickHouse), streaming y OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Durante este tiempo, trabajé con una gran cantidad de bases de datos, muy diferentes e inusuales, y con casos de uso no estándar.
Actualmente estoy trabajando en ManyChat. En esencia, se trata de una startup: nueva, ambiciosa y en rápido crecimiento. Y cuando me uní a la empresa por primera vez, surgió una pregunta clásica: "¿Qué debería sacar ahora una joven startup del mercado de DBMS y bases de datos?"
En este artículo, basado en mi informe en , Responderé a esta pregunta. Una versión en vídeo del informe está disponible en .
Bases de datos comúnmente conocidas 2020
Estamos en 2020, miré a mi alrededor y vi tres tipos de bases de datos.
Primer tipo - bases de datos OLTP clásicas: PostgreSQL, SQL Server, Oracle, MySQL. Fueron escritos hace mucho tiempo, pero siguen siendo relevantes porque son muy familiares para la comunidad de desarrolladores.
El segundo tipo es bases desde "cero". Intentaron alejarse de los patrones clásicos abandonando SQL, las estructuras tradicionales y ACID, agregando fragmentación integrada y otras características atractivas. Por ejemplo, este es Cassandra, MongoDB, Redis o Tarantool. Todas estas soluciones querían ofrecer al mercado algo fundamentalmente nuevo y ocuparon su nicho porque resultaron extremadamente cómodas para determinadas tareas. Denotaré estas bases de datos con el término general NOSQL.
Se acabaron los "ceros", nos acostumbramos a las bases de datos NOSQL y el mundo, desde mi punto de vista, dio el siguiente paso: bases de datos administradas. Estas bases de datos tienen el mismo núcleo que las bases de datos OLTP clásicas o las nuevas NoSQL. Pero no necesitan DBA ni DevOps y se ejecutan en hardware administrado en las nubes. Para un desarrollador, esto es "solo una base" que funciona en alguna parte, pero a nadie le importa cómo está instalado en el servidor, quién configuró el servidor y quién lo actualiza.
Ejemplos de tales bases de datos:
- AWS RDS es un contenedor administrado para PostgreSQL/MySQL.
- DynamoDB es un análogo de AWS de una base de datos basada en documentos, similar a Redis y MongoDB.
- Amazon Redshift es una base de datos analítica administrada.
Se trata de bases de datos básicamente antiguas, pero levantadas en un entorno gestionado, sin necesidad de trabajar con hardware.
Nota. Los ejemplos están tomados para el entorno AWS, pero también existen análogos en Microsoft Azure, Google Cloud o Yandex.Cloud.
¿Qué hay de nuevo en esto? En 2020, nada de esto.
Concepto sin servidor
Lo realmente nuevo en el mercado en 2020 son las soluciones serverless o serverless.
Intentaré explicar lo que esto significa usando el ejemplo de un servicio normal o una aplicación backend.
Para implementar una aplicación backend normal, compramos o alquilamos un servidor, copiamos el código en él, publicamos el punto final en el exterior y pagamos periódicamente el alquiler, la electricidad y los servicios del centro de datos. Este es el esquema estándar.
¿Hay alguna otra manera? Con los servicios sin servidor puedes hacerlo.
¿Cuál es el objetivo de este enfoque? No hay servidor, ni siquiera se puede alquilar una instancia virtual en la nube. Para implementar el servicio, copie el código (funciones) al repositorio y publíquelo en el punto final. Luego simplemente pagamos por cada llamada a esta función, ignorando por completo el hardware donde se ejecuta.
Intentaré ilustrar este enfoque con imágenes.
Implementación clásica. Disponemos de un servicio con una carga determinada. Planteamos dos instancias: servidores físicos o instancias en AWS. Las solicitudes externas se envían a estas instancias y se procesan allí.
Como puedes ver en la imagen, los servidores no se eliminan por igual. Uno está utilizado al 100%, hay dos solicitudes y uno está solo al 50%, parcialmente inactivo. Si no llegan tres solicitudes, sino 30, todo el sistema no podrá hacer frente a la carga y comenzará a ralentizarse.
Implementación sin servidor. En un entorno sin servidor, dicho servicio no tiene instancias ni servidores. Hay un cierto grupo de recursos calentados: pequeños contenedores Docker preparados con código de función implementado. El sistema recibe solicitudes externas y para cada una de ellas, el marco sin servidor genera un pequeño contenedor con código: procesa esta solicitud en particular y elimina el contenedor.
Una solicitud: un contenedor levantado, 1000 solicitudes: 1000 contenedores. Y la implementación en servidores de hardware ya es obra del proveedor de la nube. Está completamente oculto por el marco sin servidor. En este concepto pagamos por cada llamada. Por ejemplo, llegó una llamada por día: pagamos por una llamada, llegó un millón por minuto, pagamos por un millón. O en un segundo, esto también sucede.
El concepto de publicar una función sin servidor es adecuado para un servicio sin estado. Y si necesita un servicio con estado (estado), agregamos una base de datos al servicio. En este caso, cuando se trata de trabajar con el estado, cada función con estado simplemente escribe y lee de la base de datos. Es más, desde una base de datos de cualquiera de los tres tipos descritos al inicio del artículo.
¿Cuál es la limitación común de todas estas bases de datos? Estos son los costos de un servidor de hardware o en la nube que se utiliza constantemente (o varios servidores). No importa si usamos una base de datos clásica o administrada, si tenemos Devops y un administrador o no, igual pagamos el alquiler del hardware, la electricidad y el centro de datos 24 horas al día, 7 días a la semana. Si tenemos una base clásica, pagamos por amo y esclavo. Si se trata de una base de datos fragmentada y muy cargada, pagamos por 10, 20 o 30 servidores, y pagamos constantemente.
La presencia de servidores reservados permanentemente en la estructura de costes se percibía hasta ahora como un mal necesario. Las bases de datos convencionales también tienen otras dificultades, como límites en el número de conexiones, restricciones de escala, consenso geodistribuido; de alguna manera se pueden resolver en determinadas bases de datos, pero no todas a la vez y no de manera ideal.
Base de datos sin servidor: teoría
Pregunta de 2020: ¿es posible hacer una base de datos sin servidor también? Todo el mundo ha oído hablar del backend sin servidor... ¿Intentemos hacer que la base de datos no tenga servidor?
Esto suena extraño, porque la base de datos es un servicio con estado completo, no muy adecuado para infraestructura sin servidor. Al mismo tiempo, el estado de la base de datos es muy grande: gigabytes, terabytes y, en bases de datos analíticas, incluso petabytes. No es tan fácil levantarlo en contenedores Docker livianos.
Por otro lado, casi todas las bases de datos modernas contienen una gran cantidad de lógica y componentes: transacciones, coordinación de integridad, procedimientos, dependencias relacionales y mucha lógica. Para mucha lógica de base de datos, un estado pequeño es suficiente. Los gigabytes y terabytes son utilizados directamente por solo una pequeña parte de la lógica de la base de datos involucrada en la ejecución directa de consultas.
En consecuencia, la idea es: si parte de la lógica permite la ejecución sin estado, ¿por qué no dividir la base en partes con estado y sin estado?
Sin servidor para soluciones OLAP
Veamos cómo se vería dividir una base de datos en partes con estado y sin estado usando ejemplos prácticos.
Por ejemplo, tenemos una base de datos analítica.: datos externos (cilindro rojo a la izquierda), un proceso ETL que carga datos en la base de datos y un analista que envía consultas SQL a la base de datos. Este es un esquema de operación de almacén de datos clásico.
En este esquema, ETL se realiza condicionalmente una vez. Luego, debe pagar constantemente por los servidores en los que se ejecuta la base de datos con datos llenos de ETL, para que haya algo a lo que enviar consultas.
Veamos un enfoque alternativo implementado en AWS Athena Serverless. No existe ningún hardware dedicado permanentemente en el que se almacenen los datos descargados. En lugar de esto:
- El usuario envía una consulta SQL a Athena. El optimizador de Athena analiza la consulta SQL y busca en el almacén de metadatos (Metadatos) los datos específicos necesarios para ejecutar la consulta.
- El optimizador, basándose en los datos recopilados, descarga los datos necesarios de fuentes externas en un almacenamiento temporal (base de datos temporal).
- Se ejecuta una consulta SQL del usuario en el almacenamiento temporal y el resultado se devuelve al usuario.
- Se borra el almacenamiento temporal y se liberan recursos.
En esta arquitectura, solo pagamos por el proceso de ejecución de la solicitud. Sin solicitudes, sin costes.
Este es un enfoque funcional y se implementa no solo en Athena Serverless, sino también en Redshift Spectrum (en AWS).
El ejemplo de Athena muestra que la base de datos Serverless funciona en consultas reales con decenas y cientos de Terabytes de datos. Cientos de Terabytes requerirán cientos de servidores, pero no tenemos que pagar por ellos: pagamos por las solicitudes. La velocidad de cada solicitud es (muy) baja en comparación con bases de datos analíticas especializadas como Vertica, pero no pagamos por los períodos de inactividad.
Una base de datos de este tipo es aplicable para consultas analíticas ad hoc poco frecuentes. Por ejemplo, cuando decidimos espontáneamente probar una hipótesis sobre una cantidad gigantesca de datos. Athena es perfecta para estos casos. Para solicitudes periódicas, un sistema de este tipo es caro. En este caso, almacene en caché los datos en alguna solución especializada.
Sin servidor para soluciones OLTP
El ejemplo anterior analizó las tareas OLAP (analíticas). Ahora veamos las tareas OLTP.
Imaginemos PostgreSQL o MySQL escalable. Creemos una instancia administrada normal de PostgreSQL o MySQL con recursos mínimos. Cuando la instancia reciba más carga conectaremos réplicas adicionales a las que repartiremos parte de la carga de lectura. Si no hay solicitudes ni carga, apagamos las réplicas. La primera instancia es la maestra y el resto son réplicas.
Esta idea se implementa en una base de datos llamada Aurora Serverless AWS. El principio es simple: la flota de proxy acepta las solicitudes de aplicaciones externas. Al ver el aumento de carga, asigna recursos informáticos de instancias mínimas precalentadas: la conexión se establece lo más rápido posible. La desactivación de instancias ocurre de la misma manera.
Dentro de Aurora existe el concepto de Unidad de Capacidad Aurora, ACU. Esta es (condicionalmente) una instancia (servidor). Cada ACU específica puede ser maestra o esclava. Cada Unidad de Capacidad tiene su propia RAM, procesador y disco mínimo. En consecuencia, uno es maestro y el resto son réplicas de solo lectura.
La cantidad de estas unidades de capacidad Aurora en ejecución es un parámetro configurable. La cantidad mínima puede ser uno o cero (en este caso, la base de datos no funciona si no hay solicitudes).
Cuando la base recibe solicitudes, la flota de proxy aumenta las unidades de capacidad de Aurora, lo que aumenta los recursos de rendimiento del sistema. La capacidad de aumentar y disminuir recursos permite al sistema hacer malabarismos con los recursos: mostrar automáticamente las ACU individuales (reemplazándolas por otras nuevas) e implementar todas las actualizaciones actuales de los recursos retirados.
La base Aurora Serverless puede escalar la carga de lectura. Pero la documentación no dice esto directamente. Puede parecer que pueden levantar un multi-master. No hay magia.
Esta base de datos es ideal para evitar gastar grandes cantidades de dinero en sistemas con acceso impredecible. Por ejemplo, al crear sitios MVP o de tarjetas de presentación de marketing, generalmente no esperamos una carga estable. En consecuencia, si no hay acceso, no pagamos por las instancias. Cuando se produce una carga inesperada, por ejemplo después de una conferencia o una campaña publicitaria, una multitud de personas visita el sitio y la carga aumenta dramáticamente, Aurora Serverless toma automáticamente esta carga y conecta rápidamente los recursos faltantes (ACU). Luego pasa la conferencia, todos se olvidan del prototipo, los servidores (ACU) se apagan y los costos bajan a cero, lo cual es conveniente.
Esta solución no es adecuada para cargas elevadas estables porque no escala la carga de escritura. Todas estas conexiones y desconexiones de recursos ocurren en el llamado "punto de escala", un momento en el que la base de datos no es compatible con una transacción o tablas temporales. Por ejemplo, dentro de una semana es posible que no se alcance el punto de escala y que la base funcione con los mismos recursos y simplemente no pueda expandirse ni contraerse.
No hay magia: es PostgreSQL normal. Pero el proceso de agregar máquinas y desconectarlas está parcialmente automatizado.
Sin servidor por diseño
Aurora Serverless es una base de datos antigua reescrita para la nube para aprovechar algunos de los beneficios de Serverless. Y ahora les hablaré sobre la base, que fue escrita originalmente para la nube, para el enfoque sin servidor: Serverless-by-design. Se desarrolló inmediatamente sin asumir que se ejecutaría en servidores físicos.
Esta base se llama Snowflake. Tiene tres bloques clave.
El primero es un bloque de metadatos. Este es un servicio rápido en memoria que resuelve problemas de seguridad, metadatos, transacciones y optimización de consultas (como se muestra en la ilustración de la izquierda).
El segundo bloque es un conjunto de clústeres informáticos virtuales para realizar cálculos (en la ilustración hay un conjunto de círculos azules).
El tercer bloque es un sistema de almacenamiento de datos basado en S3. S3 es un almacenamiento de objetos adimensional en AWS, algo así como Dropbox adimensional para empresas.
Veamos cómo funciona Snowflake, suponiendo un arranque en frío. Es decir, hay una base de datos, los datos se cargan en ella, no hay consultas en ejecución. En consecuencia, si no hay solicitudes a la base de datos, entonces hemos elevado el servicio rápido de metadatos en memoria (primer bloque). Y tenemos el almacenamiento S3, donde se almacenan los datos de las tablas, divididos en las llamadas microparticiones. Para simplificar: si la tabla contiene transacciones, las microparticiones son los días de las transacciones. Cada día es una micropartición separada, un archivo separado. Y cuando la base de datos opera en este modo, solo pagas por el espacio que ocupan los datos. Además, el precio por asiento es muy bajo (sobre todo teniendo en cuenta la importante compresión). El servicio de metadatos también funciona constantemente, pero no se necesitan muchos recursos para optimizar las consultas y el servicio puede considerarse shareware.
Ahora imaginemos que un usuario llegó a nuestra base de datos y envió una consulta SQL. La consulta SQL se envía inmediatamente al servicio de metadatos para su procesamiento. En consecuencia, al recibir una solicitud, este servicio analiza la solicitud, los datos disponibles, los permisos del usuario y, si todo está bien, elabora un plan para procesar la solicitud.
A continuación, el servicio inicia el lanzamiento del clúster informático. Un clúster informático es un clúster de servidores que realizan cálculos. Es decir, este es un clúster que puede contener 1 servidor, 2 servidores, 4, 8, 16, 32, tantos como desee. Lanza una solicitud y el lanzamiento de este clúster comienza inmediatamente. Realmente lleva unos segundos.
Luego, una vez iniciado el clúster, las microparticiones necesarias para procesar su solicitud comienzan a copiarse en el clúster desde S3. Es decir, imaginemos que para ejecutar una consulta SQL necesitas dos particiones de una tabla y una de la segunda. En este caso, sólo se copiarán al clúster las tres particiones necesarias y no todas las tablas por completo. Por eso, y precisamente porque todo está ubicado dentro de un centro de datos y conectado por canales muy rápidos, todo el proceso de transferencia ocurre muy rápidamente: en segundos, muy raramente en minutos, a menos que estemos hablando de algunas solicitudes monstruosas. En consecuencia, las microparticiones se copian en el clúster informático y, al finalizar, se ejecuta la consulta SQL en este clúster informático. El resultado de esta solicitud puede ser una línea, varias líneas o una tabla; se envían externamente al usuario para que pueda descargarlo, mostrarlo en su herramienta de BI o utilizarlo de alguna otra manera.
Cada consulta SQL no solo puede leer agregados de datos cargados previamente, sino también cargar/generar nuevos datos en la base de datos. Es decir, puede ser una consulta que, por ejemplo, inserta nuevos registros en otra tabla, lo que provoca la aparición de una nueva partición en el clúster informático, que, a su vez, se guarda automáticamente en un único almacenamiento S3.
El escenario descrito anteriormente, desde la llegada del usuario hasta el levantamiento del cluster, carga de datos, ejecución de consultas, obtención de resultados, se paga a razón de minutos de uso del cluster de computación virtual levantado, almacén virtual. La tarifa varía según la zona de AWS y el tamaño del clúster, pero en promedio es de unos pocos dólares por hora. Un grupo de cuatro máquinas cuesta el doble que un grupo de dos máquinas, y un grupo de ocho máquinas sigue siendo el doble de caro. Están disponibles opciones de 16 a 32 máquinas, según la complejidad de las solicitudes. Pero solo paga por esos minutos en los que el clúster se está ejecutando, porque cuando no hay solicitudes, quita las manos y, después de 5 a 10 minutos de espera (un parámetro configurable), se activará por sí solo. Libera recursos y vuélvete libre.
Un escenario completamente realista es que cuando envías una solicitud, el clúster aparece, relativamente hablando, en un minuto, cuenta otro minuto, luego cinco minutos para apagarse y terminas pagando por siete minutos de operación de este clúster, y no durante meses y años.
El primer escenario describió el uso de Snowflake en una configuración de usuario único. Ahora imaginemos que hay muchos usuarios, lo que se acerca más al escenario real.
Digamos que tenemos muchos analistas e informes de Tableau que bombardean constantemente nuestra base de datos con una gran cantidad de consultas SQL analíticas simples.
Además, digamos que tenemos científicos de datos inventivos que intentan hacer cosas monstruosas con datos, operar con decenas de Terabytes, analizar miles de millones y billones de filas de datos.
Para los dos tipos de carga de trabajo descritos anteriormente, Snowflake le permite crear varios clústeres informáticos independientes de diferentes capacidades. Además, estos grupos informáticos funcionan de forma independiente, pero con datos comunes y consistentes.
Para una gran cantidad de consultas ligeras, puede generar de 2 a 3 grupos pequeños, aproximadamente de 2 máquinas cada uno. Este comportamiento se puede implementar, entre otras cosas, mediante la configuración automática. Entonces dices: “Copo de nieve, levanta un pequeño grupo. Si la carga aumenta por encima de un determinado parámetro, aumente un segundo o tercero similar. Cuando la carga comience a disminuir, extinga el exceso”. De modo que no importa cuántos analistas vengan y empiecen a mirar informes, todos tengan suficientes recursos.
Al mismo tiempo, si los analistas están dormidos y nadie mira los informes, es posible que los clústeres se apaguen por completo y usted deje de pagar por ellos.
Al mismo tiempo, para consultas pesadas (de científicos de datos), puede generar un clúster muy grande para 32 máquinas. A este clúster también se le pagará solo por los minutos y horas en que su solicitud gigante se ejecute allí.
La oportunidad descrita anteriormente le permite dividir no sólo 2, sino también más tipos de carga de trabajo en clusters (ETL, seguimiento, materialización de informes,...).
Resumamos Snowflake. La base combina una hermosa idea y una implementación viable. En ManyChat utilizamos Snowflake para analizar todos los datos que tenemos. No tenemos tres clusters, como en el ejemplo, sino de 5 a 9, de diferentes tamaños. Disponemos de convencionales de 16 máquinas, de 2 máquinas y también de 1 máquina superpequeñas para algunas tareas. Distribuyen con éxito la carga y nos permiten ahorrar mucho.
La base de datos escala con éxito la carga de lectura y escritura. Esta es una gran diferencia y un gran avance en comparación con el mismo "Aurora", que solo llevaba la carga de lectura. Snowflake le permite ampliar su carga de trabajo de escritura con estos grupos informáticos. Es decir, como mencioné, usamos varios clústeres en ManyChat, los clústeres pequeños y superpequeños se usan principalmente para ETL, para cargar datos. Y los analistas ya viven en clústeres medianos, que no se ven afectados en absoluto por la carga ETL, por lo que trabajan muy rápidamente.
En consecuencia, la base de datos es muy adecuada para tareas OLAP. Sin embargo, lamentablemente, todavía no es aplicable a cargas de trabajo OLTP. En primer lugar, esta base de datos es columnar, con todas las consecuencias consiguientes. En segundo lugar, el enfoque en sí, cuando para cada solicitud, si es necesario, genera un clúster informático y lo inunda con datos, desafortunadamente, aún no es lo suficientemente rápido para las cargas OLTP. Esperar segundos para tareas OLAP es normal, pero para tareas OLTP es inaceptable; 100 ms sería mejor, o 10 ms sería incluso mejor.
Total
Una base de datos sin servidor es posible dividiendo la base de datos en partes sin estado y con estado. Es posible que haya notado que en todos los ejemplos anteriores, la parte con estado es, relativamente hablando, almacenar microparticiones en S3, y Stateless es el optimizador, trabaja con metadatos y maneja problemas de seguridad que pueden plantearse como servicios Stateless livianos e independientes.
La ejecución de consultas SQL también puede percibirse como servicios ligeros que pueden aparecer en modo sin servidor, como los clústeres informáticos Snowflake, descargar solo los datos necesarios, ejecutar la consulta y "salir".
Las bases de datos de nivel de producción sin servidor ya están disponibles para su uso y están funcionando. Estas bases de datos sin servidor ya están listas para manejar tareas OLAP. Desgraciadamente, para tareas OLTP se utilizan… con matices, ya que existen limitaciones. Por un lado, esto es un inconveniente. Pero, por otro lado, ésta es una oportunidad. Quizás uno de los lectores encuentre una manera de hacer que una base de datos OLTP sea completamente sin servidor, sin las limitaciones de Aurora.
Espero que te haya resultado interesante. Sin servidor es el futuro :)
Fuente: habr.com