Ola a todos! Chámome Golov Nikolay. Anteriormente, traballei en Avito e xestionei a Plataforma de Datos durante seis anos, é dicir, traballei en todas as bases de datos: analíticas (Vertica, ClickHouse), streaming e OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Durante este tempo, tratei con un gran número de bases de datos, moi diferentes e pouco habituais, e con casos non estándar do seu uso.
Actualmente estou traballando en ManyChat. En esencia, esta é unha startup: nova, ambiciosa e en rápido crecemento. E cando me incorporei á empresa, xurdiu unha pregunta clásica: "Que debería tomar agora unha nova startup do mercado de DBMS e bases de datos?"
Neste artigo, baseado no meu informe en , vou responder a esta pregunta. Unha versión en vídeo do informe está dispoñible en .
Bases de datos máis coñecidas 2020
É 2020, mirei arredor e vin tres tipos de bases de datos.
primeiro tipo - bases de datos OLTP clásicas: PostgreSQL, SQL Server, Oracle, MySQL. Foron escritos hai moito tempo, pero seguen sendo relevantes porque son moi familiares para a comunidade de desenvolvedores.
O segundo tipo é bases de "cero". Intentaron afastarse dos patróns clásicos abandonando SQL, estruturas tradicionais e ACID, engadindo fragmentos incorporados e outras características atractivas. Por exemplo, trátase de Cassandra, MongoDB, Redis ou Tarantool. Todas estas solucións querían ofrecer ao mercado algo fundamentalmente novo e ocuparon o seu oco porque resultaron extremadamente convenientes para determinadas tarefas. Denotarei estas bases de datos co termo xeral NOSQL.
Os "ceros" remataron, acostumámonos ás bases de datos NOSQL e o mundo, dende o meu punto de vista, deu o seguinte paso: bases de datos xestionadas. Estas bases de datos teñen o mesmo núcleo que as bases de datos OLTP clásicas ou as novas NoSQL. Pero non necesitan DBA nin DevOps e funcionan con hardware xestionado nas nubes. Para un desenvolvedor, isto é "só unha base" que funciona nalgún lugar, pero a ninguén lle importa como se instala no servidor, quen o configura e quen o actualiza.
Exemplos de tales bases de datos:
- AWS RDS é un envoltorio xestionado para PostgreSQL/MySQL.
- DynamoDB é un análogo de AWS dunha base de datos baseada en documentos, similar a Redis e MongoDB.
- Amazon Redshift é unha base de datos analítica xestionada.
Trátase basicamente de bases de datos antigas, pero creadas nun entorno xestionado, sen necesidade de traballar con hardware.
Nota. Os exemplos tómanse para o ambiente AWS, pero os seus análogos tamén existen en Microsoft Azure, Google Cloud ou Yandex.Cloud.
Que hai de novo disto? En 2020, nada diso.
Concepto sen servidor
O realmente novo no mercado en 2020 son as solucións sen servidor ou sen servidor.
Tentarei explicar o que significa isto usando o exemplo dun servizo normal ou dunha aplicación de backend.
Para implementar unha aplicación de backend normal, compramos ou alugamos un servidor, copiamos o código nel, publicamos o punto final fóra e pagamos regularmente o aluguer, a electricidade e os servizos do centro de datos. Este é o esquema estándar.
Hai outro xeito? Con servizos sen servidor podes.
Cal é o foco deste enfoque: non hai servidor, nin sequera hai alugar unha instancia virtual na nube. Para implementar o servizo, copie o código (funcións) no repositorio e publícao no punto final. Entón simplemente pagamos por cada chamada a esta función, ignorando por completo o hardware onde se executa.
Tentarei ilustrar este enfoque con imaxes.
Implementación clásica. Temos un servizo con certa carga. Levantamos dúas instancias: servidores físicos ou instancias en AWS. As solicitudes externas envíanse a estas instancias e alí se procesan.
Como podes ver na imaxe, os servidores non se eliminan por igual. Unha delas está empregada ao 100 %, hai dúas solicitudes e outra está só ao 50 %, parcialmente inactiva. Se non chegan tres solicitudes, senón 30, entón todo o sistema non poderá facer fronte á carga e comezará a ralentizarse.
Implementación sen servidor. Nun ambiente sen servidor, tal servizo non ten instancias nin servidores. Hai un certo grupo de recursos quentes: pequenos contedores Docker preparados con código de función despregado. O sistema recibe solicitudes externas e para cada unha delas o marco sen servidor crea un pequeno contenedor con código: procesa esta solicitude en particular e mata o contenedor.
Unha solicitude - un contedor levantado, 1000 solicitudes - 1000 contedores. E a implantación en servidores de hardware xa é traballo do provedor da nube. Está completamente oculto polo marco sen servidor. Neste concepto pagamos por cada chamada. Por exemplo, chegaba unha chamada ao día -pagamos por unha chamada, chegaba un millón por minuto- pagamos por un millón. Ou nun segundo, isto tamén ocorre.
O concepto de publicar unha función sen servidor é adecuado para un servizo sen estado. E se necesitas un servizo completo (estatal), engadimos unha base de datos ao servizo. Neste caso, cando se trata de traballar con state, cada función statefull simplemente escribe e le desde a base de datos. Ademais, a partir dunha base de datos de calquera dos tres tipos descritos ao comezo do artigo.
Cal é a limitación común de todas estas bases de datos? Estes son os custos dun servidor de hardware ou nube de uso constante (ou varios servidores). Non importa se utilizamos unha base de datos clásica ou xestionada, teñamos Devops e un administrador ou non, aínda pagamos o hardware, a electricidade e o aluguer de centros de datos as 24 horas do día, os 7 días da semana. Se temos unha base clásica, pagamos amo e escravo. Se se trata dunha base de datos fragmentada moi cargada, pagamos por 10, 20 ou 30 servidores e pagamos constantemente.
A presenza de servidores reservados permanentemente na estrutura de custos era percibida anteriormente como un mal necesario. As bases de datos convencionais tamén teñen outras dificultades, como os límites no número de conexións, as restricións de escalado, o consenso xeodistribuído: poden resolverse dalgún xeito en determinadas bases de datos, pero non todas á vez e non é ideal.
Base de datos sen servidor - teoría
Pregunta de 2020: tamén é posible facer unha base de datos sen servidor? Todo o mundo xa escoitou falar do backend sen servidor... imos tentar facer que a base de datos sexa sen servidor?
Isto soa estraño, porque a base de datos é un servizo con estado, non moi axeitado para a infraestrutura sen servidor. Ao mesmo tempo, o estado da base de datos é moi grande: gigabytes, terabytes, e nas bases de datos analíticas incluso petabytes. Non é tan sinxelo levantalo en contedores Docker lixeiros.
Por outra banda, case todas as bases de datos modernas conteñen unha enorme cantidade de lóxica e compoñentes: transaccións, coordinación de integridade, procedementos, dependencias relacionais e moita lóxica. Para moita lóxica de base de datos, un pequeno estado é suficiente. Os gigabytes e os terabytes son usados directamente por só unha pequena parte da lóxica da base de datos implicada na execución directa de consultas.
En consecuencia, a idea é: se parte da lóxica permite a execución sen estado, por que non dividir a base en partes con estado e sen estado.
Sen servidor para solucións OLAP
Vexamos como pode ser cortar unha base de datos en partes con estado e sen estado usando exemplos prácticos.
Por exemplo, temos unha base de datos analítica: datos externos (cilindro vermello á esquerda), un proceso ETL que carga datos na base de datos e un analista que envía consultas SQL á base de datos. Este é un esquema de operación de almacén de datos clásico.
Neste esquema, ETL realízase condicionalmente unha vez. Entón cómpre pagar constantemente polos servidores nos que se executa a base de datos con datos cheos de ETL, para que haxa algo ao que enviar consultas.
Vexamos un enfoque alternativo implementado en AWS Athena Serverless. Non hai hardware dedicado permanentemente no que se almacenen os datos descargados. En lugar disto:
- O usuario envía unha consulta SQL a Athena. O optimizador de Athena analiza a consulta SQL e busca no almacén de metadatos (Metadatos) os datos específicos necesarios para executar a consulta.
- O optimizador, baseado nos datos recollidos, descarga os datos necesarios de fontes externas nun almacenamento temporal (base de datos temporal).
- Unha consulta SQL do usuario execútase no almacenamento temporal e o resultado devólvese ao usuario.
- Borrárase o almacenamento temporal e lánzanse os recursos.
Nesta arquitectura, só pagamos polo proceso de execución da solicitude. Sen solicitudes - sen custos.
Este é un enfoque de traballo e está implementado non só en Athena Serverless, senón tamén en Redshift Spectrum (en AWS).
O exemplo de Athena mostra que a base de datos Serverless funciona en consultas reais con decenas e centos de Terabytes de datos. Centos de terabytes requirirán centos de servidores, pero non temos que pagar por eles: pagamos as solicitudes. A velocidade de cada solicitude é (moi) baixa en comparación coas bases de datos analíticas especializadas como Vertica, pero non pagamos por períodos de inactividade.
Esta base de datos é aplicable para consultas analíticas ad-hoc raras. Por exemplo, cando espontaneamente decidimos probar unha hipótese sobre unha cantidade xigantesca de datos. Athena é perfecta para estes casos. Para solicitudes habituais, este sistema é caro. Neste caso, almacena os datos na caché nalgunha solución especializada.
Sen servidor para solucións OLTP
O exemplo anterior analizou tarefas OLAP (analíticas). Agora vexamos as tarefas OLTP.
Imaxinemos PostgreSQL ou MySQL escalables. Imos crear unha instancia regular xestionada PostgreSQL ou MySQL con recursos mínimos. Cando a instancia reciba máis carga, conectaremos réplicas adicionais ás que distribuiremos parte da carga de lectura. Se non hai solicitudes nin carga, desactivamos as réplicas. A primeira instancia é o mestre, e o resto son réplicas.
Esta idea está implementada nunha base de datos chamada Aurora Serverless AWS. O principio é sinxelo: as solicitudes de aplicacións externas son aceptadas pola flota de proxy. Ao ver o aumento da carga, asigna recursos informáticos a partir de instancias mínimas prequentadas: a conexión realízase o máis rápido posible. A desactivación das instancias ocorre do mesmo xeito.
Dentro de Aurora existe o concepto de Unidade de Capacidade Aurora, ACU. Esta é (condicionalmente) unha instancia (servidor). Cada ACU específica pode ser un mestre ou un escravo. Cada unidade de capacidade ten a súa propia memoria RAM, procesador e disco mínimo. En consecuencia, un é mestre, o resto son réplicas de só lectura.
O número destas unidades de capacidade Aurora en execución é un parámetro configurable. A cantidade mínima pode ser un ou cero (neste caso, a base de datos non funciona se non hai solicitudes).
Cando a base recibe solicitudes, a flota de proxy aumenta Aurora CapacityUnits, aumentando os recursos de rendemento do sistema. A capacidade de aumentar e diminuír os recursos permite que o sistema faga malabarismos cos recursos: mostrar automaticamente ACU individuais (substituíndoos por outros novos) e lanzar todas as actualizacións actuais dos recursos retirados.
A base Aurora Serverless pode escalar a carga de lectura. Pero a documentación non o di directamente. Pode parecer que poden levantar un multi-master. Non hai maxia.
Esta base de datos é moi adecuada para evitar gastar grandes cantidades de diñeiro en sistemas con acceso imprevisible. Por exemplo, cando creamos sitios de tarxetas de visita MVP ou comercializamos, normalmente non esperamos unha carga estable. En consecuencia, se non hai acceso, non pagamos as instancias. Cando se produce unha carga inesperada, por exemplo despois dunha conferencia ou campaña publicitaria, multitude de persoas visitan o sitio e a carga aumenta drasticamente, Aurora Serverless toma automaticamente esta carga e conecta rapidamente os recursos que faltan (ACU). A continuación, a conferencia pasa, todos esquécense do prototipo, os servidores (ACU) escurecen e os custos baixan a cero - conveniente.
Esta solución non é axeitada para alta carga estable porque non escala a carga de escritura. Todas estas conexións e desconexións de recursos ocorren no chamado "punto de escala", un momento no que a base de datos non está soportada por unha transacción ou táboas temporais. Por exemplo, dentro dunha semana pode que o punto de escala non se produza e a base funcione cos mesmos recursos e simplemente non se poida expandir nin contraer.
Non hai maxia: é PostgreSQL normal. Pero o proceso de engadir máquinas e desconectalas está parcialmente automatizado.
Sen servidor por deseño
Aurora Serverless é unha antiga base de datos reescrita para a nube para aproveitar algúns dos beneficios de Serverless. E agora falareivos da base, que foi escrita orixinalmente para a nube, para o enfoque sen servidor - Serverless-by-design. Desenvolveuse inmediatamente sen a suposición de que se executaría en servidores físicos.
Esta base chámase Snowflake. Ten tres bloques clave.
O primeiro é un bloque de metadatos. Este é un servizo rápido en memoria que resolve problemas de seguridade, metadatos, transaccións e optimización de consultas (que se mostra na ilustración da esquerda).
O segundo bloque é un conxunto de clusters de computación virtuais para cálculos (na ilustración hai un conxunto de círculos azuis).
O terceiro bloque é un sistema de almacenamento de datos baseado en S3. S3 é almacenamento de obxectos adimensional en AWS, algo así como Dropbox sen dimensión para empresas.
Vexamos como funciona Snowflake, asumindo un arranque en frío. É dicir, hai unha base de datos, os datos cárganse nela, non hai consultas en execución. En consecuencia, se non hai solicitudes á base de datos, entón levantamos o servizo rápido de metadatos en memoria (primeiro bloque). E temos almacenamento S3, onde se almacenan os datos da táboa, divididos nas chamadas microparticións. Por simplicidade: se a táboa contén transaccións, entón as microparticións son os días das transaccións. Cada día é unha micropartición separada, un ficheiro separado. E cando a base de datos funciona neste modo, só pagas polo espazo que ocupan os datos. Ademais, a taxa por asento é moi baixa (sobre todo tendo en conta a importante compresión). O servizo de metadatos tamén funciona constantemente, pero non necesitas moitos recursos para optimizar as consultas e o servizo pódese considerar shareware.
Agora imaxinemos que un usuario chegou á nosa base de datos e enviou unha consulta SQL. A consulta SQL envíase inmediatamente ao servizo de metadatos para procesala. En consecuencia, ao recibir unha solicitude, este servizo analiza a solicitude, os datos dispoñibles, os permisos dos usuarios e, se todo está ben, elabora un plan de tramitación da solicitude.
A continuación, o servizo inicia o lanzamento do clúster de computación. Un clúster de computación é un clúster de servidores que realizan cálculos. É dicir, este é un clúster que pode conter 1 servidor, 2 servidores, 4, 8, 16, 32 - tantos como queiras. Lanzas unha solicitude e o lanzamento deste clúster comeza inmediatamente. Realmente leva segundos.
A continuación, despois de que se inicie o clúster, as microparticións necesarias para procesar a súa solicitude comezan a copiarse no clúster desde S3. É dicir, imaxinemos que para executar unha consulta SQL precisas dúas particións dunha táboa e outra da segunda. Neste caso, só se copiarán no clúster as tres particións necesarias, e non todas as táboas por completo. Precisamente por iso, e precisamente porque todo está situado nun centro de datos e conectado por canles moi rápidos, todo o proceso de transferencia ocorre moi rápido: en segundos, moi raramente en minutos, a non ser que esteamos falando dalgunhas solicitudes monstruosas. En consecuencia, as microparticións cópianse no clúster informático e, ao finalizar, a consulta SQL execútase neste clúster informático. O resultado desta solicitude pode ser unha liña, varias liñas ou unha táboa: envíanse externamente ao usuario para que poida descargalo, visualizalo na súa ferramenta de BI ou utilizalo doutro xeito.
Cada consulta SQL non só pode ler agregados de datos cargados previamente, senón tamén cargar/xerar novos datos na base de datos. É dicir, pode tratarse dunha consulta que, por exemplo, insira novos rexistros noutra táboa, o que leva á aparición dunha nova partición no clúster informático que, á súa vez, gárdase automaticamente nun único almacenamento S3.
O escenario descrito anteriormente, desde a chegada do usuario ata a creación do clúster, a carga de datos, a execución de consultas, a obtención de resultados, págase á taxa por minutos de uso do clúster de computación virtual elevado, almacén virtual. A taxa varía dependendo da zona AWS e do tamaño do clúster, pero en media é duns poucos dólares por hora. Un clúster de catro máquinas é o dobre que un clúster de dúas máquinas, e un clúster de oito máquinas aínda é o dobre. Existen opcións de 16, 32 máquinas dispoñibles, dependendo da complexidade das solicitudes. Pero só pagas por eses minutos nos que o clúster está realmente funcionando, porque cando non hai solicitudes, quitas as mans e despois de 5-10 minutos de espera (un parámetro configurable) apagarase por si só. libera recursos e convértete en libre.
Un escenario completamente realista é cando envías unha solicitude, o clúster aparece, relativamente falando, nun minuto, conta outro minuto, despois cinco minutos para apagar e acabas pagando por sete minutos de funcionamento deste clúster e non por meses e anos.
O primeiro escenario descrito usando Snowflake nunha configuración de usuario único. Agora imaxinemos que hai moitos usuarios, o que está máis preto do escenario real.
Digamos que temos moitos analistas e informes de Tableau que bombardean constantemente a nosa base de datos cunha gran cantidade de consultas SQL analíticas sinxelas.
Ademais, digamos que temos científicos de datos inventivos que intentan facer cousas monstruosas con datos, operar con decenas de terabytes, analizar miles de millóns e billóns de filas de datos.
Para os dous tipos de carga de traballo descritos anteriormente, Snowflake permítelle crear varios clústeres informáticos independentes de diferentes capacidades. Ademais, estes clusters de computación funcionan de forma independente, pero con datos coherentes comúns.
Para un gran número de consultas lixeiras, pode crear 2-3 pequenos clústeres, aproximadamente 2 máquinas cada un. Este comportamento pódese implementar, entre outras cousas, mediante a configuración automática. Entón dis: "Fopo de neve, levanta un pequeno cúmulo. Se a carga sobre el aumenta por encima dun determinado parámetro, suba un segundo, terceiro similar. Cando a carga comece a diminuír, apague o exceso". Para que por moitos analistas que veñan e comecen a mirar informes, todos teñan recursos suficientes.
Ao mesmo tempo, se os analistas están durmidos e ninguén mira os informes, os clústeres poden escurecerse completamente e deixar de pagar por eles.
Ao mesmo tempo, para consultas pesadas (de Data Scientists), pode crear un clúster moi grande para 32 máquinas. Este clúster tamén se pagará só por aqueles minutos e horas nos que a túa solicitude xigante estea a executarse alí.
A oportunidade descrita anteriormente permite dividir non só 2, senón tamén máis tipos de carga de traballo en clusters (ETL, seguimento, materialización de informes,...).
Imos resumir Snowflake. A base combina unha fermosa idea e unha implementación viable. En ManyChat, usamos Snowflake para analizar todos os datos que temos. Non temos tres grupos, como no exemplo, senón de 5 a 9, de diferentes tamaños. Contamos con convencionais de 16 máquinas, 2 máquinas e tamén súper pequenas de 1 máquina para algunhas tarefas. Reparten con éxito a carga e permítennos aforrar moito.
A base de datos escala correctamente a carga de lectura e escritura. Esta é unha gran diferenza e un gran avance en comparación coa mesma "Aurora", que só levou a carga de lectura. Snowflake permíteche escalar a túa carga de traballo de escritura con estes clústeres informáticos. É dicir, como mencionei, usamos varios clústeres en ManyChat, os clústeres pequenos e super-pequenos utilízanse principalmente para ETL, para cargar datos. E os analistas xa viven en clústeres medios, que non están absolutamente afectados pola carga ETL, polo que funcionan moi rápido.
En consecuencia, a base de datos é moi adecuada para tarefas OLAP. Non obstante, por desgraza, aínda non é aplicable ás cargas de traballo OLTP. En primeiro lugar, esta base de datos é columnar, con todas as consecuencias derivadas. En segundo lugar, o enfoque en si, cando para cada solicitude, se é necesario, levantas un clúster de computación e o inundas de datos, desafortunadamente, aínda non é o suficientemente rápido para cargas OLTP. Esperar segundos para tarefas OLAP é normal, pero para tarefas OLTP é inaceptable; 100 ms serían mellores ou 10 ms serían aínda mellores.
Total
É posible unha base de datos sen servidor dividindo a base de datos en partes sen estado e con estado. Quizais teña notado que en todos os exemplos anteriores, a parte Stateful é, relativamente falando, almacenar micro-particións en S3, e Stateless é o optimizador, traballando con metadatos, xestionando problemas de seguridade que se poden plantexar como servizos independentes sen estado.
A execución de consultas SQL tamén se pode percibir como servizos de estado claro que poden aparecer en modo sen servidor, como os clústeres de computación Snowflake, descargar só os datos necesarios, executar a consulta e "saír".
As bases de datos de nivel de produción sen servidor xa están dispoñibles para o seu uso, están funcionando. Estas bases de datos sen servidor xa están listas para xestionar tarefas OLAP. Por desgraza, para tarefas OLTP utilízanse... con matices, xa que hai limitacións. Por unha banda, isto é un negativo. Pero, por outra banda, esta é unha oportunidade. Quizais un dos lectores atope un xeito de facer unha base de datos OLTP completamente sen servidor, sen as limitacións de Aurora.
Espero que vos resulte interesante. Sen servidor é o futuro :)
Fonte: www.habr.com