Hola a tots! Em dic Golov Nikolay. Anteriorment, vaig treballar a Avito i vaig gestionar la Plataforma de Dades durant sis anys, és a dir, vaig treballar en totes les bases de dades: analítiques (Vertica, ClickHouse), streaming i OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Durant aquest temps, vaig tractar amb un gran nombre de bases de dades, molt diferents i inusuals, i amb casos no estàndards del seu ús.
Actualment estic treballant a ManyChat. En essència, es tracta d'una startup: nova, ambiciosa i en ràpid creixement. I quan em vaig unir per primera vegada a l'empresa, va sorgir una pregunta clàssica: "Què hauria de treure ara una jove startup del mercat de DBMS i bases de dades?"
En aquest article, basat en el meu informe a , respondré aquesta pregunta. Una versió en vídeo de l'informe està disponible a .
Bases de dades conegudes habitualment 2020
Som el 2020, vaig mirar al voltant i vaig veure tres tipus de bases de dades.
Primer tipus - bases de dades OLTP clàssiques: PostgreSQL, SQL Server, Oracle, MySQL. Es van escriure fa molt de temps, però encara són rellevants perquè són tan familiars per a la comunitat de desenvolupadors.
El segon tipus és bases de "zero". Van intentar allunyar-se dels patrons clàssics abandonant SQL, estructures tradicionals i ACID, afegint fragments integrats i altres característiques atractives. Per exemple, es tracta de Cassandra, MongoDB, Redis o Tarantool. Totes aquestes solucions volien oferir al mercat quelcom fonamentalment nou i ocupaven el seu nínxol perquè resultaven molt convenients per a determinades tasques. Denotaré aquestes bases de dades amb el terme paraigua NOSQL.
Els "zeros" s'han acabat, ens vam acostumar a les bases de dades NOSQL i el món, des del meu punt de vista, va fer el següent pas: bases de dades gestionades. Aquestes bases de dades tenen el mateix nucli que les bases de dades OLTP clàssiques o les noves NoSQL. Però no necessiten DBA i DevOps i funcionen amb maquinari gestionat als núvols. Per a un desenvolupador, això és "només una base" que funciona en algun lloc, però a ningú li importa com s'instal·la al servidor, qui ha configurat el servidor i qui l'actualitza.
Exemples d'aquestes bases de dades:
- AWS RDS és un embolcall gestionat per a PostgreSQL/MySQL.
- DynamoDB és un anàleg d'AWS d'una base de dades basada en documents, similar a Redis i MongoDB.
- Amazon Redshift és una base de dades analítica gestionada.
Es tracta bàsicament de bases de dades antigues, però plantejades en un entorn gestionat, sense necessitat de treballar amb maquinari.
Nota. Els exemples es prenen per a l'entorn AWS, però els seus anàlegs també existeixen a Microsoft Azure, Google Cloud o Yandex.Cloud.
Què hi ha de nou en això? El 2020, res d'això.
Concepte sense servidor
El que és realment nou al mercat el 2020 són les solucions sense servidor o sense servidor.
Intentaré explicar què significa això utilitzant l'exemple d'un servei normal o una aplicació de fons.
Per implementar una aplicació de backend normal, comprem o lloguem un servidor, copiem el codi, publiquem el punt final fora i paguem regularment el lloguer, l'electricitat i els serveis del centre de dades. Aquest és l'esquema estàndard.
Hi ha alguna altra manera? Amb els serveis sense servidor podeu fer-ho.
Quin és el focus d'aquest enfocament: no hi ha servidor, ni tan sols hi ha llogar una instància virtual al núvol. Per implementar el servei, copieu el codi (funcions) al repositori i publiqueu-lo al punt final. Aleshores, simplement paguem per cada trucada a aquesta funció, ignorant completament el maquinari on s'executa.
Intentaré il·lustrar aquest enfocament amb imatges.
Desplegament clàssic. Tenim un servei amb una certa càrrega. Plantegem dues instàncies: servidors físics o instàncies a AWS. Les sol·licituds externes s'envien a aquestes instàncies i s'hi processen.
Com podeu veure a la imatge, els servidors no s'eliminen per igual. Una s'utilitza al 100%, hi ha dues sol·licituds i una només està al 50%, parcialment inactiva. Si no arriben tres sol·licituds, sinó 30, tot el sistema no podrà fer front a la càrrega i començarà a alentir-se.
Desplegament sense servidor. En un entorn sense servidor, aquest servei no té instàncies ni servidors. Hi ha un determinat conjunt de recursos escalfats: petits contenidors Docker preparats amb codi de funció desplegat. El sistema rep sol·licituds externes i per a cadascuna d'elles el framework sense servidor genera un petit contenidor amb codi: processa aquesta sol·licitud concreta i mata el contenidor.
Una sol·licitud: un contenidor plantejat, 1000 sol·licituds: 1000 contenidors. I el desplegament en servidors de maquinari ja és feina del proveïdor del núvol. Està completament amagat pel marc sense servidor. En aquest concepte paguem cada trucada. Per exemple, una trucada venia al dia: vam pagar una trucada, un milió per minut; vam pagar un milió. O en un segon, això també passa.
El concepte de publicar una funció sense servidor és adequat per a un servei sense estat. I si necessiteu un servei (estatal) complet, afegim una base de dades al servei. En aquest cas, quan es tracta de treballar amb l'estat, cada funció amb estat simplement escriu i llegeix des de la base de dades. A més, a partir d'una base de dades de qualsevol dels tres tipus descrits al principi de l'article.
Quina és la limitació comuna de totes aquestes bases de dades? Aquests són els costos d'un núvol o servidor de maquinari utilitzat constantment (o diversos servidors). No importa si fem servir una base de dades clàssica o gestionada, si tenim Devops i un administrador o no, encara paguem el maquinari, l'electricitat i el lloguer del centre de dades les 24 hores del dia. Si tenim una base clàssica, paguem amo i esclau. Si es tracta d'una base de dades fragmentada molt carregada, paguem per 7, 10 o 20 servidors i paguem constantment.
La presència de servidors reservats permanentment a l'estructura de costos es percebia anteriorment com un mal necessari. Les bases de dades convencionals també tenen altres dificultats, com ara límits en el nombre de connexions, restriccions d'escala, consens geodistribuït; d'alguna manera es poden resoldre en determinades bases de dades, però no totes alhora i no idealment.
Base de dades sense servidor - teoria
Pregunta del 2020: també és possible fer una base de dades sense servidor? Tothom ha sentit a parlar del backend sense servidor... intentem que la base de dades sigui sense servidor?
Això sona estrany, perquè la base de dades és un servei amb estat, poc adequat per a una infraestructura sense servidor. Al mateix temps, l'estat de la base de dades és molt gran: gigabytes, terabytes, i a les bases de dades analítiques fins i tot petabytes. No és tan fàcil aixecar-lo en contenidors Docker lleugers.
D'altra banda, gairebé totes les bases de dades modernes contenen una gran quantitat de lògica i components: transaccions, coordinació d'integritat, procediments, dependències relacionals i molta lògica. Per a una gran quantitat de lògica de base de dades, un estat petit és suficient. Els gigabytes i els terabytes són utilitzats directament per només una petita part de la lògica de la base de dades implicada en l'execució directa de consultes.
En conseqüència, la idea és: si una part de la lògica permet l'execució sense estat, per què no dividir la base en parts amb estat i sense estat.
Sense servidor per a solucions OLAP
Vegem com pot semblar tallar una base de dades en parts Stateful i Stateless utilitzant exemples pràctics.
Per exemple, tenim una base de dades analítica: dades externes (cilindre vermell a l'esquerra), un procés ETL que carrega dades a la base de dades i un analista que envia consultes SQL a la base de dades. Aquest és un esquema d'operació clàssic de magatzem de dades.
En aquest esquema, ETL es realitza condicionalment una vegada. Aleshores, heu de pagar constantment pels servidors en què s'executa la base de dades amb dades plenes d'ETL, de manera que hi hagi alguna cosa a què enviar consultes.
Vegem un enfocament alternatiu implementat a AWS Athena Serverless. No hi ha cap maquinari dedicat permanentment on s'emmagatzemin les dades descarregades. En lloc d'això:
- L'usuari envia una consulta SQL a Athena. L'optimitzador d'Athena analitza la consulta SQL i cerca al magatzem de metadades (Metadades) les dades específiques necessàries per executar la consulta.
- L'optimitzador, a partir de les dades recollides, descarrega les dades necessàries de fonts externes a l'emmagatzematge temporal (base de dades temporal).
- Una consulta SQL de l'usuari s'executa a l'emmagatzematge temporal i el resultat es retorna a l'usuari.
- S'esborra l'emmagatzematge temporal i s'alliberen recursos.
En aquesta arquitectura, només paguem el procés d'execució de la sol·licitud. Sense sol·licituds, sense costos.
Aquest és un enfocament de treball i s'implementa no només a Athena Serverless, sinó també a Redshift Spectrum (a AWS).
L'exemple d'Athena mostra que la base de dades Serverless funciona amb consultes reals amb desenes i centenars de Terabytes de dades. Centenars de terabytes requeriran centenars de servidors, però no els hem de pagar: nosaltres paguem per les sol·licituds. La velocitat de cada sol·licitud és (molt) baixa en comparació amb bases de dades analítiques especialitzades com Vertica, però no paguem per períodes d'inactivitat.
Aquesta base de dades és aplicable a consultes analítiques ad-hoc rares. Per exemple, quan decidim espontàniament provar una hipòtesi sobre una quantitat gegantina de dades. Athena és perfecte per a aquests casos. Per a sol·licituds habituals, aquest sistema és car. En aquest cas, emmagatzemeu les dades a la memòria cau en alguna solució especialitzada.
Sense servidor per a solucions OLTP
L'exemple anterior va analitzar les tasques OLAP (analíticas). Ara mirem les tasques OLTP.
Imaginem PostgreSQL o MySQL escalables. Creem una instància regular gestionada PostgreSQL o MySQL amb recursos mínims. Quan la instància rebi més càrrega, connectarem rèpliques addicionals a les quals distribuirem part de la càrrega de lectura. Si no hi ha sol·licituds ni càrrega, desactivem les rèpliques. La primera instància és el mestre, i la resta són rèpliques.
Aquesta idea s'implementa en una base de dades anomenada Aurora Serverless AWS. El principi és senzill: les sol·licituds d'aplicacions externes són acceptades per la flota de proxy. En veure com augmenta la càrrega, assigna recursos informàtics a partir d'instàncies mínimes preescalfades: la connexió es fa el més ràpidament possible. Les instàncies de desactivació es produeixen de la mateixa manera.
Dins d'Aurora hi ha el concepte d'Aurora Capacity Unit, ACU. Això és (condicionalment) una instància (servidor). Cada ACU específica pot ser un mestre o un esclau. Cada unitat de capacitat té la seva pròpia memòria RAM, processador i disc mínim. En conseqüència, un és mestre, la resta són rèpliques de només lectura.
El nombre d'aquestes unitats de capacitat Aurora en funcionament és un paràmetre configurable. La quantitat mínima pot ser un o zero (en aquest cas, la base de dades no funciona si no hi ha sol·licituds).
Quan la base rep sol·licituds, la flota de proxy augmenta Aurora CapacityUnits, augmentant els recursos de rendiment del sistema. La capacitat d'augmentar i disminuir els recursos permet al sistema fer malabarismes amb els recursos: mostrar automàticament ACU individuals (substituint-los per de nous) i desplegar totes les actualitzacions actuals dels recursos retirats.
La base Aurora Serverless pot escalar la càrrega de lectura. Però la documentació no ho diu directament. Pot semblar que poden aixecar un multi-master. No hi ha màgia.
Aquesta base de dades és molt adequada per evitar gastar grans quantitats de diners en sistemes amb accés impredictible. Per exemple, quan es crea MVP o llocs de màrqueting de targetes de visita, normalment no esperem una càrrega estable. En conseqüència, si no hi ha accés, no paguem per instàncies. Quan es produeix una càrrega inesperada, per exemple després d'una conferència o una campanya publicitària, multitud de persones visiten el lloc i la càrrega augmenta dràsticament, Aurora Serverless agafa automàticament aquesta càrrega i connecta ràpidament els recursos que falten (ACU). Llavors passa la conferència, tothom s'oblida del prototip, els servidors (ACU) s'enfoquen i els costos baixen a zero, convenient.
Aquesta solució no és adequada per a una càrrega elevada estable perquè no escala la càrrega d'escriptura. Totes aquestes connexions i desconnexions de recursos es produeixen a l'anomenat "punt d'escala", un punt en el temps en què la base de dades no és compatible amb una transacció o taules temporals. Per exemple, en una setmana el punt d'escala pot no passar, i la base treballa amb els mateixos recursos i simplement no pot expandir-se ni contraure's.
No hi ha màgia: és PostgreSQL normal. Però el procés d'afegir màquines i desconnectar-les està parcialment automatitzat.
Sense servidor per disseny
Aurora Serverless és una base de dades antiga reescrita per al núvol per aprofitar alguns dels avantatges de Serverless. I ara us parlaré de la base, que es va escriure originalment per al núvol, per a l'enfocament sense servidor: Serverless-by-design. Es va desenvolupar immediatament sense suposar que s'executaria en servidors físics.
Aquesta base s'anomena Floquet de neu. Té tres blocs clau.
El primer és un bloc de metadades. Aquest és un servei ràpid en memòria que resol problemes de seguretat, metadades, transaccions i optimització de consultes (que es mostra a la il·lustració de l'esquerra).
El segon bloc és un conjunt de clústers informàtics virtuals per a càlculs (a la il·lustració hi ha un conjunt de cercles blaus).
El tercer bloc és un sistema d'emmagatzematge de dades basat en S3. S3 és un emmagatzematge d'objectes adimensionals a AWS, una mena de Dropbox sense dimensions per a empreses.
Vegem com funciona Floquet de neu, suposant un inici en fred. És a dir, hi ha una base de dades, les dades s'hi carreguen, no hi ha consultes en execució. En conseqüència, si no hi ha sol·licituds a la base de dades, hem augmentat el servei ràpid de metadades en memòria (primer bloc). I tenim l'emmagatzematge S3, on s'emmagatzemen les dades de la taula, dividides en les anomenades microparticions. Per simplicitat: si la taula conté transaccions, les microparticions són els dies de les transaccions. Cada dia és una micropartició separada, un fitxer separat. I quan la base de dades funciona en aquest mode, només pagueu per l'espai que ocupen les dades. A més, la taxa per seient és molt baixa (sobretot tenint en compte la important compressió). El servei de metadades també funciona constantment, però no necessiteu molts recursos per optimitzar les consultes i el servei es pot considerar shareware.
Ara imaginem que un usuari va entrar a la nostra base de dades i va enviar una consulta SQL. La consulta SQL s'envia immediatament al servei de metadades perquè la processi. En conseqüència, en rebre una sol·licitud, aquest servei analitza la sol·licitud, les dades disponibles, els permisos de l'usuari i, si tot va bé, elabora un pla de tramitació de la sol·licitud.
A continuació, el servei inicia el llançament del clúster informàtic. Un clúster informàtic és un clúster de servidors que realitzen càlculs. És a dir, aquest és un clúster que pot contenir 1 servidor, 2 servidors, 4, 8, 16, 32, tants com vulgueu. Llenceu una sol·licitud i immediatament comença el llançament d'aquest clúster. Realment triguen segons.
A continuació, un cop iniciat el clúster, les microparticions necessàries per processar la vostra sol·licitud comencen a copiar-se al clúster des de S3. És a dir, imaginem que per executar una consulta SQL necessiteu dues particions d'una taula i una de la segona. En aquest cas, només es copiaran les tres particions necessàries al clúster, i no totes les taules completament. Per això, i precisament perquè tot està situat dins d'un mateix centre de dades i connectat per canals molt ràpids, tot el procés de transferència es produeix molt ràpidament: en segons, molt rarament en minuts, tret que estem parlant d'algunes peticions monstruoses. En conseqüència, les microparticions es copien al clúster informàtic i, un cop finalitzada, la consulta SQL s'executa en aquest clúster informàtic. El resultat d'aquesta sol·licitud pot ser una línia, diverses línies o una taula: s'envien externament a l'usuari perquè el pugui descarregar, mostrar-lo a la seva eina de BI o utilitzar-lo d'una altra manera.
Cada consulta SQL no només pot llegir agregats de dades carregades anteriorment, sinó que també pot carregar/generar dades noves a la base de dades. És a dir, pot ser una consulta que, per exemple, insereix nous registres en una altra taula, la qual cosa fa que aparegui una nova partició al clúster informàtic, que, al seu torn, es desa automàticament en un únic emmagatzematge S3.
L'escenari descrit anteriorment, des de l'arribada de l'usuari fins a l'aixecament del clúster, la càrrega de dades, l'execució de consultes, l'obtenció de resultats, es paga a la tarifa per minuts d'ús del clúster d'informàtica virtual elevat, magatzem virtual. La tarifa varia segons la zona AWS i la mida del clúster, però de mitjana és d'uns pocs dòlars per hora. Un clúster de quatre màquines és el doble de car que un clúster de dues màquines, i un grup de vuit màquines encara és el doble. Hi ha disponibles opcions de 16, 32 màquines, depenent de la complexitat de les peticions. Però només pagueu per aquells minuts en què el clúster s'executa realment, perquè quan no hi ha sol·licituds, us treu les mans, i després de 5-10 minuts d'espera (un paràmetre configurable) s'apagarà per si sol, allibera recursos i esdevé lliure.
Un escenari completament realista és que quan envieu una sol·licitud, el clúster apareix, relativament parlant, en un minut, compta un altre minut, després cinc minuts per tancar-se i acabeu pagant set minuts de funcionament d'aquest clúster, i no durant mesos i anys.
El primer escenari descrit amb Snowflake en una configuració d'un sol usuari. Ara imaginem que hi ha molts usuaris, la qual cosa està més a prop de l'escenari real.
Suposem que tenim molts analistes i informes de Tableau que bombardegen constantment la nostra base de dades amb un gran nombre de consultes SQL analítiques senzilles.
A més, diguem que tenim científics de dades inventius que intenten fer coses monstruoses amb dades, operen amb desenes de terabytes, analitzen milers de milions i bilions de files de dades.
Per als dos tipus de càrrega de treball descrits anteriorment, Snowflake us permet crear diversos clústers informàtics independents de diferents capacitats. A més, aquests clústers informàtics funcionen de manera independent, però amb dades coherents comunes.
Per a un gran nombre de consultes lleugeres, podeu generar 2-3 grups petits, aproximadament 2 màquines cadascun. Aquest comportament es pot implementar, entre altres coses, mitjançant la configuració automàtica. Així que dius: "Floquet de neu, aixeca un petit cúmul. Si la càrrega sobre ell augmenta per sobre d'un paràmetre determinat, augmenta un segon, un tercer similar. Quan la càrrega comenci a disminuir, apagueu l'excés". Perquè per més que vinguin analistes i comencin a mirar informes, tothom té prou recursos.
Al mateix temps, si els analistes estan adormits i ningú mira els informes, els clústers poden enfosquir-se completament i deixar de pagar per ells.
Al mateix temps, per a consultes pesades (de Data Scientists), podeu crear un clúster molt gran per a 32 màquines. Aquest clúster també es pagarà només pels minuts i hores en què s'executa la vostra sol·licitud gegant.
L'oportunitat descrita anteriorment permet dividir no només 2, sinó també més tipus de càrrega de treball en clústers (ETL, seguiment, materialització d'informes,...).
Resumim Floquet de neu. La base combina una idea bonica i una implementació viable. A ManyChat, fem servir Snowflake per analitzar totes les dades que tenim. No tenim tres clústers, com a l'exemple, sinó de 5 a 9, de diferents mides. Tenim 16 màquines convencionals, 2 màquines i també súper petites d'una màquina per a algunes tasques. Reparteixen amb èxit la càrrega i ens permeten estalviar molt.
La base de dades escala correctament la càrrega de lectura i escriptura. Aquesta és una gran diferència i un gran avenç en comparació amb la mateixa "Aurora", que només portava la càrrega de lectura. Snowflake us permet escalar la vostra càrrega de treball d'escriptura amb aquests clústers informàtics. És a dir, com he esmentat, fem servir diversos clústers a ManyChat, els clústers petits i super-petits s'utilitzen principalment per a ETL, per carregar dades. I els analistes ja viuen en clústers mitjans, que no es veuen afectats per la càrrega ETL, de manera que funcionen molt ràpidament.
En conseqüència, la base de dades és molt adequada per a tasques OLAP. Tanmateix, malauradament, encara no és aplicable a les càrregues de treball OLTP. En primer lloc, aquesta base de dades és columnar, amb totes les conseqüències que se'n deriven. En segon lloc, l'enfocament en si, quan per a cada sol·licitud, si cal, aixequeu un clúster informàtic i l'inundeu de dades, malauradament, encara no és prou ràpid per a les càrregues OLTP. Esperar segons per a les tasques OLAP és normal, però per a les tasques OLTP és inacceptable; 100 ms seria millor, o 10 ms seria encara millor.
Total
Una base de dades sense servidor és possible dividint la base de dades en parts sense estat i amb estat. És possible que hàgiu notat que en tots els exemples anteriors, la part Stateful és, relativament parlant, emmagatzemar microparticions a S3, i Stateless és l'optimitzador, que treballa amb metadades, gestiona problemes de seguretat que es poden plantejar com a serveis sense estat lleugers independents.
L'execució de consultes SQL també es pot percebre com a serveis d'estat lleuger que poden aparèixer en mode sense servidor, com ara clústers informàtics de Snowflake, descarregar només les dades necessàries, executar la consulta i "sortir".
Les bases de dades de nivell de producció sense servidor ja estan disponibles per al seu ús, estan funcionant. Aquestes bases de dades sense servidor ja estan preparades per gestionar tasques OLAP. Malauradament, per a les tasques OLTP s'utilitzen... amb matisos, ja que hi ha limitacions. D'una banda, això és un negatiu. Però, d'altra banda, aquesta és una oportunitat. Potser un dels lectors trobarà una manera de fer que una base de dades OLTP sigui completament sense servidor, sense les limitacions d'Aurora.
Espero que t'hagi trobat interessant. Sense servidor és el futur :)
Font: www.habr.com