Hei alle sammen! Mitt navn er Golov Nikolay. Tidligere har jeg jobbet i Avito og administrert Dataplattformen i seks år, det vil si at jeg jobbet på alle databaser: analytisk (Vertica, ClickHouse), streaming og OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). I løpet av denne tiden jobbet jeg med et stort antall databaser - veldig forskjellige og uvanlige, og med ikke-standardiserte tilfeller av deres bruk.
Jeg jobber for tiden på ManyChat. I hovedsak er dette en oppstart – ny, ambisiøs og raskt voksende. Og da jeg først begynte i selskapet, dukket det opp et klassisk spørsmål: "Hva bør en ung startup nå ta fra DBMS- og databasemarkedet?"
I denne artikkelen, basert på rapporten min på , vil jeg svare på dette spørsmålet. En videoversjon av rapporten er tilgjengelig på .
Allment kjente databaser 2020
Det er 2020, jeg så meg rundt og så tre typer databaser.
Første type - klassiske OLTP-databaser: PostgreSQL, SQL Server, Oracle, MySQL. De ble skrevet for lenge siden, men er fortsatt relevante fordi de er så kjent for utviklermiljøet.
Den andre typen er baser fra "null". De prøvde å gå bort fra klassiske mønstre ved å forlate SQL, tradisjonelle strukturer og ACID, ved å legge til innebygd sharding og andre attraktive funksjoner. For eksempel er dette Cassandra, MongoDB, Redis eller Tarantool. Alle disse løsningene ønsket å tilby markedet noe fundamentalt nytt og okkuperte deres nisje fordi de viste seg å være ekstremt praktiske for visse oppgaver. Jeg vil betegne disse databasene med paraplybegrepet NOSQL.
"Nullene" er over, vi ble vant til NOSQL-databaser, og verden, fra mitt ståsted, tok neste skritt - å administrerte databaser. Disse databasene har samme kjerne som klassiske OLTP-databaser eller nye NoSQL-databaser. Men de har ikke behov for DBA og DevOps og kjører på administrert maskinvare i skyene. For en utvikler er dette "bare en base" som fungerer et sted, men ingen bryr seg om hvordan den er installert på serveren, hvem som har konfigurert serveren og hvem som oppdaterer den.
Eksempler på slike databaser:
- AWS RDS er en administrert innpakning for PostgreSQL/MySQL.
- DynamoDB er en AWS-analog av en dokumentbasert database, lik Redis og MongoDB.
- Amazon Redshift er en administrert analytisk database.
Dette er i utgangspunktet gamle databaser, men oppdratt i et administrert miljø, uten behov for å jobbe med maskinvare.
Merk. Eksemplene er tatt for AWS-miljøet, men deres analoger finnes også i Microsoft Azure, Google Cloud eller Yandex.Cloud.
Hva er nytt med dette? I 2020, ingenting av dette.
Serverløst konsept
Det som virkelig er nytt på markedet i 2020 er serverløse eller serverløse løsninger.
Jeg skal prøve å forklare hva dette betyr ved å bruke eksempelet på en vanlig tjeneste eller backend-applikasjon.
For å distribuere en vanlig backend-applikasjon kjøper eller leier vi en server, kopierer koden til den, publiserer endepunktet utenfor og betaler regelmessig for husleie, strøm og datasentertjenester. Dette er standardordningen.
Er det noen annen måte? Med serverløse tjenester kan du.
Hva er fokus for denne tilnærmingen: det er ingen server, det er ikke engang å leie en virtuell instans i skyen. For å distribuere tjenesten, kopier koden (funksjonene) til depotet og publiser det til endepunktet. Da betaler vi ganske enkelt for hvert kall til denne funksjonen, og ignorerer fullstendig maskinvaren der den utføres.
Jeg skal prøve å illustrere denne tilnærmingen med bilder.
Klassisk utplassering. Vi har en tjeneste med en viss belastning. Vi tar opp to instanser: fysiske servere eller instanser i AWS. Eksterne forespørsler sendes til disse instansene og behandles der.
Som du kan se på bildet, er ikke serverne disponert likt. En er 100 % utnyttet, det er to forespørsler, og en er bare 50 % - delvis inaktiv. Hvis ikke tre forespørsler kommer, men 30, vil ikke hele systemet være i stand til å takle belastningen og vil begynne å bremse.
Serverløs distribusjon. I et serverløst miljø har ikke en slik tjeneste forekomster eller servere. Det er en viss pool av oppvarmede ressurser - små forberedte Docker-containere med utplassert funksjonskode. Systemet mottar eksterne forespørsler, og for hver av dem reiser det serverløse rammeverket en liten container med kode: den behandler denne forespørselen og dreper containeren.
Én forespørsel - én container hevet, 1000 forespørsler - 1000 containere. Og distribusjon på maskinvareservere er allerede skyleverandørens arbeid. Det er fullstendig skjult av det serverløse rammeverket. I dette konseptet betaler vi for hver samtale. For eksempel kom en samtale om dagen - vi betalte for en samtale, en million kom per minutt - vi betalte for en million. Eller på et sekund skjer dette også.
Konseptet med å publisere en serverløs funksjon er egnet for en statsløs tjeneste. Og hvis du trenger en (statlig) statefull tjeneste, så legger vi til en database til tjenesten. I dette tilfellet, når det gjelder å jobbe med tilstand, skriver og leser hver statefull-funksjon ganske enkelt fra databasen. Dessuten, fra en database med en av de tre typene beskrevet i begynnelsen av artikkelen.
Hva er fellesbegrensningen for alle disse databasene? Dette er kostnadene for en stadig brukt sky- eller maskinvareserver (eller flere servere). Det spiller ingen rolle om vi bruker en klassisk eller administrert database, om vi har Devops og en admin eller ikke, vi betaler fortsatt for maskinvare, strøm og datasenterleie 24/7. Hvis vi har en klassisk base, betaler vi for herre og slave. Hvis det er en svært belastet shard database, betaler vi for 10, 20 eller 30 servere, og vi betaler konstant.
Tilstedeværelsen av permanent reserverte servere i kostnadsstrukturen ble tidligere oppfattet som et nødvendig onde. Konvensjonelle databaser har også andre vanskeligheter, som begrensninger på antall tilkoblinger, skaleringsbegrensninger, geofordelt konsensus – de kan på en eller annen måte løses i visse databaser, men ikke alle på en gang og ikke ideelt.
Serverløs database - teori
Spørsmål fra 2020: er det mulig å gjøre en database serverløs også? Alle har hørt om den serverløse backend... la oss prøve å gjøre databasen serverløs?
Dette høres rart ut, fordi databasen er en statefull tjeneste, ikke særlig egnet for serverløs infrastruktur. Samtidig er tilstanden til databasen veldig stor: gigabyte, terabyte, og i analytiske databaser til og med petabyte. Det er ikke så lett å heve den i lette Docker-beholdere.
På den annen side inneholder nesten alle moderne databaser en enorm mengde logikk og komponenter: transaksjoner, integritetskoordinering, prosedyrer, relasjonsavhengigheter og mye logikk. For ganske mye databaselogikk er en liten tilstand nok. Gigabyte og Terabyte brukes direkte av bare en liten del av databaselogikken som er involvert i direkte utføring av spørringer.
Følgelig er ideen: hvis en del av logikken tillater statsløs utførelse, hvorfor ikke dele opp basen i Stateful og Stateless deler.
Serverløs for OLAP-løsninger
La oss se hvordan å kutte en database i Stateful og Stateless deler kan se ut ved å bruke praktiske eksempler.
For eksempel har vi en analytisk database: eksterne data (rød sylinder til venstre), en ETL-prosess som laster data inn i databasen, og en analytiker som sender SQL-spørringer til databasen. Dette er et klassisk datavarehusdriftsskjema.
I denne ordningen utføres ETL betinget én gang. Da må du hele tiden betale for serverne som databasen kjører på med data fylt med ETL, slik at det er noe å sende spørringer til.
La oss se på en alternativ tilnærming implementert i AWS Athena Serverless. Det er ingen permanent dedikert maskinvare som nedlastede data lagres på. Istedenfor dette:
- Brukeren sender en SQL-spørring til Athena. Athena-optimalisatoren analyserer SQL-spørringen og søker i metadatalageret (Metadata) etter de spesifikke dataene som trengs for å utføre spørringen.
- Optimalisatoren, basert på de innsamlede dataene, laster ned nødvendige data fra eksterne kilder til midlertidig lagring (midlertidig database).
- En SQL-spørring fra brukeren utføres i midlertidig lagring og resultatet returneres til brukeren.
- Midlertidig lagring tømmes og ressurser frigjøres.
I denne arkitekturen betaler vi kun for prosessen med å utføre forespørselen. Ingen forespørsler - ingen kostnader.
Dette er en arbeidstilnærming og implementeres ikke bare i Athena Serverless, men også i Redshift Spectrum (i AWS).
Athena-eksemplet viser at den serverløse databasen fungerer på ekte spørringer med titalls og hundrevis av terabyte med data. Hundrevis av terabyte vil kreve hundrevis av servere, men vi trenger ikke å betale for dem – vi betaler for forespørslene. Hastigheten på hver forespørsel er (veldig) lav sammenlignet med spesialiserte analytiske databaser som Vertica, men vi betaler ikke for nedetidsperioder.
En slik database er anvendelig for sjeldne analytiske ad-hoc-spørringer. For eksempel når vi spontant bestemmer oss for å teste en hypotese på en gigantisk mengde data. Athena er perfekt for disse tilfellene. For vanlige forespørsler er et slikt system dyrt. I dette tilfellet, hurtigbufrer dataene i en spesialisert løsning.
Serverløs for OLTP-løsninger
Det forrige eksemplet så på OLAP (analytiske) oppgaver. La oss nå se på OLTP-oppgaver.
La oss forestille oss skalerbar PostgreSQL eller MySQL. La oss ta opp en vanlig administrert forekomst av PostgreSQL eller MySQL med minimale ressurser. Når instansen får mer belastning, vil vi koble til flere replikaer som vi vil fordele deler av lesebelastningen til. Hvis det ikke er noen forespørsler og ingen belastning, slår vi av replikaene. Den første instansen er mesteren, og resten er kopier.
Denne ideen er implementert i en database kalt Aurora Serverless AWS. Prinsippet er enkelt: forespørsler fra eksterne applikasjoner aksepteres av proxy-flåten. Når belastningen øker, tildeler den dataressurser fra forhåndsoppvarmede minimale forekomster - tilkoblingen gjøres så raskt som mulig. Deaktivering av forekomster skjer på samme måte.
Innenfor Aurora er det konseptet Aurora Capacity Unit, ACU. Dette er (betinget) en instans (server). Hver spesifikke ACU kan være en master eller en slave. Hver kapasitetsenhet har sin egen RAM, prosessor og minimal disk. Følgelig er en mester, resten er skrivebeskyttede kopier.
Antallet av disse Aurora Capacity Units som kjører er en konfigurerbar parameter. Minimumsmengden kan være én eller null (i dette tilfellet fungerer ikke databasen hvis det ikke er noen forespørsler).
Når basen mottar forespørsler, øker proxy-flåten Aurora CapacityUnits, noe som øker systemets ytelsesressurser. Evnen til å øke og redusere ressurser gjør at systemet kan "jonglere" ressurser: automatisk vise individuelle ACUer (erstatte dem med nye) og rulle ut alle nåværende oppdateringer til de tilbaketrukne ressursene.
Aurora Serverless-basen kan skalere lesebelastningen. Men dokumentasjonen sier ikke dette direkte. Det kan føles som om de kan løfte en multi-master. Det er ingen magi.
Denne databasen er godt egnet til å unngå å bruke enorme mengder penger på systemer med uforutsigbar tilgang. Når vi for eksempel oppretter MVP eller markedsfører visittkortsider, forventer vi vanligvis ikke en stabil belastning. Følgelig, hvis det ikke er tilgang, betaler vi ikke for tilfeller. Når uventet belastning oppstår, for eksempel etter en konferanse eller en reklamekampanje, besøker mengder av mennesker siden og belastningen øker dramatisk, tar Aurora Serverless automatisk denne belastningen og kobler raskt til de manglende ressursene (ACU). Så går konferansen over, alle glemmer prototypen, serverne (ACU) blir mørke, og kostnadene faller til null - praktisk.
Denne løsningen er ikke egnet for stabil høybelastning fordi den ikke skalerer skrivebelastningen. Alle disse tilkoblingene og frakoblingene av ressurser skjer på det såkalte "skaleringspunktet" - et tidspunkt da databasen ikke støttes av en transaksjon eller midlertidige tabeller. For eksempel kan det hende at skalapunktet ikke skjer innen en uke, og basen fungerer på de samme ressursene og kan rett og slett ikke utvide eller trekke seg sammen.
Det er ingen magi - det er vanlig PostgreSQL. Men prosessen med å legge til maskiner og koble dem fra er delvis automatisert.
Serverløs av design
Aurora Serverless er en gammel database omskrevet for skyen for å dra nytte av noen av fordelene med Serverless. Og nå skal jeg fortelle deg om basen, som opprinnelig ble skrevet for skyen, for den serverløse tilnærmingen - Serverless-by-design. Den ble umiddelbart utviklet uten antakelse om at den ville kjøre på fysiske servere.
Denne basen kalles Snowflake. Den har tre nøkkelblokker.
Den første er en metadatablokk. Dette er en rask minnetjeneste som løser problemer med sikkerhet, metadata, transaksjoner og spørringsoptimalisering (vist i illustrasjonen til venstre).
Den andre blokken er et sett med virtuelle databehandlingsklynger for beregninger (i illustrasjonen er det et sett med blå sirkler).
Den tredje blokken er et datalagringssystem basert på S3. S3 er dimensjonsløs objektlagring i AWS, på en måte som dimensjonsløs Dropbox for bedrifter.
La oss se hvordan Snowflake fungerer, forutsatt en kald start. Det vil si at det er en database, dataene lastes inn i den, det er ingen løpende spørringer. Følgelig, hvis det ikke er noen forespørsler til databasen, har vi hevet den raske metadatatjenesten i minnet (første blokk). Og vi har S3-lagring, hvor tabelldata lagres, delt inn i såkalte mikropartisjoner. For enkelhets skyld: hvis tabellen inneholder transaksjoner, er mikropartisjoner dagene for transaksjoner. Hver dag er en egen mikropartisjon, en egen fil. Og når databasen fungerer i denne modusen, betaler du kun for plassen som dataene bruker. Dessuten er prisen per sete veldig lav (spesielt tatt i betraktning den betydelige kompresjonen). Metadatatjenesten fungerer også konstant, men du trenger ikke mye ressurser for å optimalisere spørringer, og tjenesten kan betraktes som shareware.
La oss nå forestille oss at en bruker kom til databasen vår og sendte en SQL-spørring. SQL-spørringen sendes umiddelbart til Metadata-tjenesten for behandling. Følgelig, ved mottak av en forespørsel, analyserer denne tjenesten forespørselen, tilgjengelige data, brukertillatelser og, hvis alt er i orden, utarbeider en plan for behandling av forespørselen.
Deretter starter tjenesten lanseringen av databehandlingsklyngen. En dataklynge er en klynge av servere som utfører beregninger. Det vil si at dette er en klynge som kan inneholde 1 server, 2 servere, 4, 8, 16, 32 - så mange du vil. Du sender en forespørsel og lanseringen av denne klyngen begynner umiddelbart. Det tar virkelig sekunder.
Deretter, etter at klyngen har startet, begynner mikropartisjonene som trengs for å behandle forespørselen din å bli kopiert inn i klyngen fra S3. Det vil si, la oss forestille oss at for å utføre en SQL-spørring trenger du to partisjoner fra en tabell og en fra den andre. I dette tilfellet vil bare de tre nødvendige partisjonene bli kopiert til klyngen, og ikke alle tabellene helt. Det er derfor, og nettopp fordi alt er plassert i ett datasenter og koblet sammen med veldig raske kanaler, skjer hele overføringsprosessen veldig raskt: på sekunder, svært sjelden på minutter, med mindre vi snakker om noen monstrøse forespørsler . Følgelig blir mikropartisjoner kopiert til dataklyngen, og etter fullføring utføres SQL-spørringen på denne dataklyngen. Resultatet av denne forespørselen kan være én linje, flere linjer eller en tabell – de sendes eksternt til brukeren slik at han kan laste den ned, vise den i sitt BI-verktøy, eller bruke den på annen måte.
Hver SQL-spørring kan ikke bare lese aggregater fra tidligere innlastede data, men også laste inn/generere nye data i databasen. Det vil si at det kan være en spørring som for eksempel setter inn nye poster i en annen tabell, noe som fører til at det vises en ny partisjon på dataklyngen, som igjen automatisk lagres i en enkelt S3-lagring.
Scenariet beskrevet ovenfor, fra ankomsten av brukeren til heving av klyngen, lasting av data, utføring av spørringer, oppnåelse av resultater, betales med satsen for minutter med bruk av den hevet virtuelle databehandlingsklyngen, virtuelt lager. Prisen varierer avhengig av AWS-sonen og klyngestørrelsen, men i gjennomsnitt er den noen få dollar i timen. En klynge med fire maskiner er dobbelt så dyr som en klynge med to maskiner, og en klynge med åtte maskiner er fortsatt dobbelt så dyr. Alternativer for 16, 32 maskiner er tilgjengelige, avhengig av kompleksiteten til forespørslene. Men du betaler bare for de minuttene når klyngen faktisk kjører, for når det ikke er noen forespørsler, tar du på en måte hendene av deg, og etter 5-10 minutters venting (en konfigurerbar parameter) vil den gå ut av seg selv, frigjør ressurser og bli gratis.
Et helt realistisk scenario er at når du sender en forespørsel, dukker klyngen opp, relativt sett, i løpet av et minutt, den teller et minutt til, deretter fem minutter å slå av, og du ender opp med å betale for syv minutters drift av denne klyngen, og ikke på måneder og år.
Det første scenariet beskrev bruk av Snowflake i en enkeltbrukerinnstilling. La oss nå forestille oss at det er mange brukere, som er nærmere det virkelige scenariet.
La oss si at vi har mange analytikere og Tableau-rapporter som konstant bombarderer databasen vår med et stort antall enkle analytiske SQL-spørringer.
I tillegg, la oss si at vi har oppfinnsomme dataforskere som prøver å gjøre monstrøse ting med data, operere med titalls terabyte, analysere milliarder og billioner av rader med data.
For de to typene arbeidsbelastning som er beskrevet ovenfor, lar Snowflake deg heve flere uavhengige databehandlingsklynger med forskjellig kapasitet. Dessuten fungerer disse dataklyngene uavhengig, men med felles konsistente data.
For et stort antall lette spørringer kan du opprette 2-3 små klynger, omtrent 2 maskiner hver. Denne oppførselen kan implementeres blant annet ved hjelp av automatiske innstillinger. Så du sier: «Snøfnugg, reis en liten klynge. Hvis belastningen på den øker over en viss parameter, hev en lignende andre, tredje. Når belastningen begynner å avta, slukk overskuddet.» Slik at uansett hvor mange analytikere som kommer og begynner å se på rapporter, har alle nok ressurser.
Samtidig, hvis analytikere sover og ingen ser på rapportene, kan det hende at klyngene blir helt mørke, og du slutter å betale for dem.
På samme tid, for tunge forespørsler (fra Data Scientists), kan du øke en veldig stor klynge for 32 maskiner. Denne klyngen vil også bare bli betalt for de minuttene og timene din gigantiske forespørsel kjører der.
Muligheten beskrevet ovenfor lar deg dele ikke bare 2, men også flere typer arbeidsbelastning i klynger (ETL, overvåking, rapportmaterialisering,...).
La oss oppsummere Snowflake. Basen kombinerer en vakker idé og en gjennomførbar implementering. Hos ManyChat bruker vi Snowflake til å analysere alle dataene vi har. Vi har ikke tre klynger, som i eksemplet, men fra 5 til 9, av forskjellige størrelser. Vi har konvensjonelle 16-maskiner, 2-maskiner og også supersmå 1-maskiner til noen oppgaver. De fordeler belastningen vellykket og lar oss spare mye.
Databasen skalerer lese- og skrivebelastningen. Dette er en enorm forskjell og et stort gjennombrudd sammenlignet med den samme "Aurora", som bare bar lesebelastningen. Snowflake lar deg skalere skrivearbeidsmengden med disse dataklyngene. Det vil si, som jeg nevnte, vi bruker flere klynger i ManyChat, små og supersmå klynger brukes hovedsakelig til ETL, for å laste data. Og analytikere lever allerede på mellomstore klynger, som absolutt ikke påvirkes av ETL-belastningen, så de jobber veldig raskt.
Derfor er databasen godt egnet for OLAP-oppgaver. Imidlertid er det dessverre ennå ikke aktuelt for OLTP-arbeidsbelastninger. For det første er denne databasen kolonneformet, med alle de påfølgende konsekvenser. For det andre er selve tilnærmingen, når du for hver forespørsel, om nødvendig, reiser en dataklynge og oversvømmer den med data, dessverre ennå ikke rask nok for OLTP-belastninger. Å vente sekunder på OLAP-oppgaver er normalt, men for OLTP-oppgaver er det uakseptabelt; 100 ms ville være bedre, eller 10 ms ville være enda bedre.
Total
En serverløs database er mulig ved å dele databasen i Stateless og Stateful deler. Du har kanskje lagt merke til at i alle eksemplene ovenfor er Stateful-delen relativt sett lagring av mikropartisjoner i S3, og Stateless er optimalisereren, arbeider med metadata, håndterer sikkerhetsproblemer som kan reises som uavhengige lettvekts Stateless-tjenester.
Utførelse av SQL-spørringer kan også oppfattes som light-state-tjenester som kan dukke opp i serverløs modus, som Snowflake-dataklynger, kun laste ned de nødvendige dataene, utføre spørringen og "gå ut."
Serverløse databaser på produksjonsnivå er allerede tilgjengelige for bruk, de fungerer. Disse serverløse databasene er allerede klare til å håndtere OLAP-oppgaver. Dessverre, for OLTP-oppgaver brukes de... med nyanser, siden det er begrensninger. På den ene siden er dette et minus. Men på den annen side er dette en mulighet. Kanskje vil en av leserne finne en måte å gjøre en OLTP-database helt serverløs, uten begrensningene til Aurora.
Jeg håper du fant det interessant. Serverløs er fremtiden :)
Kilde: www.habr.com