Hi almal! My naam is Golov Nikolay. Voorheen het ek by Avito gewerk en die Data Platform vir ses jaar bestuur, dit wil sê ek was betrokke by alle databasisse: analitiese (Vertica, ClickHouse), streaming en OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Gedurende hierdie tyd het ek met 'n groot aantal databasisse te doen gehad - baie anders en ongewoon, en met nie-standaard gevalle van hul gebruik.
Ek werk tans vir ManyChat. In wese is dit 'n begin - nuut, ambisieus en vinnig groeiende. En toe ek die eerste keer by die maatskappy aangesluit het, het die klassieke vraag ontstaan: "Wat moet 'n jong beginner nou uit die DBMS- en databasismark neem?".
In hierdie artikel, gebaseer op my verslag oor Ek sal hierdie vraag beantwoord. Die videoweergawe van die verslag is beskikbaar by .
Bekende databasisse 2020
In die jaart van 2020 het ek rondgekyk en drie soorte databasisse gesien.
Die eerste tipe is klassieke OLTP-databasisse: PostgreSQL, SQL Server, Oracle, MySQL. Hulle is lank gelede geskryf, maar is steeds relevant omdat dit goed bekend is aan die ontwikkelingsgemeenskap.
Die tweede tipe is basisse van "nul". Hulle het probeer om weg te kom van die klassieke sjablone deur SQL, tradisionele strukture en ACID te laat vaar, deur ingeboude sharding en ander aantreklike kenmerke by te voeg. Dit is byvoorbeeld Cassandra, MongoDB, Redis of Tarantool. Al hierdie oplossings wou iets fundamenteel nuuts aan die mark bied en het hul nis beset, want dit blyk uiters gerieflik te wees in sekere take. Hierdie databasisse sal met die sambreelterm NOSQL aangedui word.
Die "nul" is verby, hulle is gewoond aan NOSQL-databasisse, en die wêreld, vanuit my oogpunt, het die volgende stap geneem - om bestuurde databasisse. Hierdie databasisse het dieselfde kern as klassieke OLTP-databasisse of nuwe NoSQL-databasisse. Maar hulle het nie DBA en DevOps nodig nie en hulle werk op bestuurde hardeware in die wolke. Vir 'n ontwikkelaar is dit "net 'n basis" wat iewers werk, en niemand gee om hoe dit op die bediener geïnstalleer word, wie die bediener gekonfigureer het en wie dit opdateer nie.
Voorbeelde van sulke basisse:
- AWS RDS - bestuurde omhulsel oor PostgreSQL/MySQL.
- DynamoDB - AWS-analoog van dokumentgebaseerde databasis, soortgelyk aan Redis en MongoDB.
- Amazon Redshift - bestuurde analitiese basis.
Basies is dit ou databasisse, maar opgewek in 'n bestuurde omgewing, sonder dat dit nodig is om met hardeware te werk.
Let wel. Die voorbeelde word geneem vir die AWS-omgewing, maar hul eweknieë bestaan ook in Microsoft Azure, Google Cloud of Yandex.Cloud.
Wat is nuut hieroor? In 2020, niks daarvan nie.
Bedienerlose konsep
Die werklik nuwe ding op die mark in 2020 is bedienerlose of bedienerlose oplossings.
Ek sal probeer om te verduidelik wat dit beteken deur die voorbeeld van 'n gewone diens of backend-toepassing te gebruik.
Om 'n gewone backend-toepassing te ontplooi, koop of huur ons 'n bediener, kopieer die kode daarna, publiseer die eindpunt buite, en betaal gereeld vir huur, elektrisiteit en datasentrumdienste. Dit is die standaard uitleg.
Is dit op een of ander manier anders moontlik? Dit is moontlik met bedienerlose dienste.
Wat is die fokus van hierdie benadering: daar is geen bediener nie, daar is nie eens 'n huurkontrak van 'n virtuele instansie in die wolk nie. Om die diens te ontplooi, kopieer ons die kode (funksies) na die bewaarplek en publiseer dit buite die eindpunt. Verder betaal ons eenvoudig vir elke oproep na hierdie funksie, en ignoreer die hardeware waar dit uitgevoer word heeltemal.
Ek sal probeer om hierdie benadering met prente te illustreer.
Klassieke ontplooiing. Ons het 'n diens met 'n sekere las. Ons opper twee gevalle: fisiese bedieners of gevalle in AWS. Eksterne versoeke word na hierdie instansies gestuur en daar verwerk.
Soos u op die foto kan sien, word die bedieners anders gebruik. Een word 100% benut, daar is twee versoeke, en een is slegs 50% gedeeltelik ledig. As nie drie versoeke kom nie, maar 30, dan sal die hele stelsel nie die las hanteer nie en sal dit begin stadiger word.
Bedienerlose ontplooiing. In 'n bedienerlose omgewing het so 'n diens nie gevalle en bedieners nie. Daar is 'n poel verhitte hulpbronne - klein voorbereide Docker-houers met ontplooide funksiekode. Die stelsel ontvang eksterne versoeke en vir elkeen van hulle verhoog die bedienerlose raamwerk 'n klein houer met kode: dit verwerk hierdie versoek en maak die houer dood.
Een versoek - een opgehefte houer, 1000 versoeke - 1000 houers. En ontplooiing op ysterbedieners is reeds die werk van 'n wolkverskaffer. Dit is heeltemal weggesteek deur die bedienerlose raamwerk. In hierdie konsep betaal ons vir elke oproep. Byvoorbeeld, een oproep het op 'n dag gekom - ons het vir een oproep betaal, 'n miljoen het in 'n minuut gekom - ons het vir 'n miljoen betaal. Of in 'n sekonde gebeur dit ook.
Die konsep om 'n bedienerlose funksie te publiseer is gepas vir 'n staatlose diens. En as jy 'n (staats) staatsvolle diens benodig, voeg dan 'n databasis by die diens. In hierdie geval, wanneer dit kom by die werk met staat, met staat, skryf en lees elke statefull-funksie net vanaf die databasis. Verder, vanaf 'n databasis van enige van die drie tipes wat aan die begin van die artikel beskryf word.
Wat is die algemene beperking van al hierdie basisse? Dit is die koste van 'n voortdurend gebruikte wolk- of ysterbediener (of verskeie bedieners). Dit maak nie saak of ons 'n klassieke databasis gebruik of bestuur word nie, of ons Devops en 'n admin het of nie, ons betaal steeds 24/7 vir hardeware, elektrisiteit en datasentrumhuur. As ons 'n klassieke basis het, betaal ons vir meester en slaaf. As 'n hoogs gelaaide geskeurde basis - ons betaal vir 10, 20 of 30 bedieners, en ons betaal voortdurend.
Die teenwoordigheid van permanent gereserveerde bedieners in die kostestruktuur is vroeër as 'n noodsaaklike euwel beskou. Gewone databasisse het ook ander probleme, soos limiete op die aantal verbindings, skaalgrense, geo-verspreide konsensus – hulle kan op een of ander manier in sekere databasisse opgelos word, maar nie almal op een slag nie en nie ideaal nie.
Bedienerlose databasis - Teorie
Vraag 2020: Kan die databasis ook bedienerloos gemaak word? Almal het gehoor van die bedienerlose agterkant ... maar kom ons probeer om die databasis ook bedienerloos te maak?
Dit klink vreemd, want die databasis is 'n staatvolle diens, nie baie geskik vir 'n bedienerlose infrastruktuur nie. Terselfdertyd is die toestand van die databasis baie groot: gigagrepe, teragrepe en selfs petagrepe in analitiese databasisse. Dit is nie so maklik om dit in liggewig Docker-houers op te lig nie.
Aan die ander kant is byna alle moderne databasisse 'n groot hoeveelheid logika en komponente: transaksies, integriteitsonderhandeling, prosedures, relasionele afhanklikhede en baie logika. Vir 'n redelike groot deel van die databasislogika is 'n klein staat voldoende. Gigagrepe en Teragrepe word direk gebruik deur slegs 'n klein deel van die databasislogika wat verband hou met die direkte uitvoering van navrae.
Gevolglik is die idee: as 'n deel van die logika staatlose uitvoering toelaat, waarom nie die basis in Stateful en Stateless dele verdeel nie.
Bedienerloos vir OLAP-oplossings
Kom ons kyk hoe 'n databasis wat in Stateful en Stateless dele verdeel is, kan lyk deur praktiese voorbeelde te gebruik.
Ons het byvoorbeeld 'n analitiese databasis: eksterne data (rooi silinder aan die linkerkant), 'n ETL-proses wat data in die databasis laai, en 'n ontleder wat SQL-navrae na die databasis stuur. Dit is 'n klassieke datapakhuisskema.
In hierdie skema word ETL konvensioneel een keer uitgevoer. Dan moet jy heeltyd betaal vir die bedieners waarop die databasis loop met data wat oorstroom is met ETL, sodat daar iets is om versoeke te gooi.
Kom ons kyk na 'n alternatiewe benadering wat in AWS Athena Serverless geïmplementeer is. Daar is geen permanent toegewyde hardeware waarop afgelaaide data gestoor word nie. In plaas daarvan:
- Die gebruiker stuur 'n SQL-navraag na Athena. Die Athena-optimeerder ontleed die SQL-navraag en deursoek die Metadata-stoor vir die spesifieke data wat nodig is om die navraag uit te voer.
- Die optimeerder, gebaseer op die versamelde data, laai die nodige data van eksterne bronne af in 'n tydelike berging (tydelike databasis).
- In tydelike berging word 'n SQL-navraag vanaf die gebruiker uitgevoer, die resultaat word aan die gebruiker teruggestuur.
- Tydelike berging word uitgevee, hulpbronne word vrygestel.
In hierdie argitektuur betaal ons slegs vir die proses om die versoek uit te voer. Geen versoeke, geen kostes.
Dit is 'n werkende benadering en word nie net in Athena Serverless geïmplementeer nie, maar ook in Redshift Spectrum (op AWS).
Die Athena-voorbeeld toon dat die Serverless-databasis op werklike navrae werk met tien en honderde Teragrepe se data. Honderde Teragrepe sal honderde bedieners benodig, maar ons hoef nie daarvoor te betaal nie – ons betaal vir versoeke. Die spoed van elke versoek is (baie) laag in vergelyking met gespesialiseerde analitiese databasisse soos Vertica, maar ons betaal nie vir stilstandtydperiodes nie.
So 'n databasis is van toepassing op af en toe ad-hoc analitiese navrae. Byvoorbeeld, wanneer ons spontaan besluit om 'n hipotese op 'n reusagtige hoeveelheid data te toets. Vir hierdie gevalle pas Athena perfek. Vir gereelde versoeke is so 'n stelsel duur. In hierdie geval, kas die data in een of ander gespesialiseerde oplossing.
Bedienerloos vir OLTP-oplossings
In die vorige voorbeeld is OLAP-take (analities) oorweeg. Oorweeg nou OLTP-take.
Stel jou 'n skaalbare PostgreSQL of MySQL voor. Kom ons stel 'n gereelde bestuurde instansie van PostgreSQL of MySQL op met minimale hulpbronne. Wanneer meer vrag by die instansie kom, sal ons bykomende replikas koppel waaraan ons 'n deel van die leeslading sal versprei. As daar geen versoeke en vrag is nie, skakel ons die replikas af. Die eerste instansie is die meester, en die res is replikas.
Hierdie idee word geïmplementeer in 'n databasis genaamd Aurora Serverless AWS. Die beginsel is eenvoudig: versoeke van eksterne aansoeke word deur die volmagvloot aanvaar. Aangesien dit die toename in las sien, ken dit rekenaarhulpbronne toe vanaf voorafverwarmde minimale gevalle - die verbinding word so vinnig as moontlik gemaak. Deaktiveer gevalle werk op dieselfde manier.
Binne Aurora is daar die konsep van Aurora Capacity Unit, ACU. Dit is (voorwaardelik) 'n instansie (bediener). Elke spesifieke ACU kan meester of slaaf wees. Elke kapasiteitseenheid het sy eie RAM, verwerker en minimum skyf. Gevolglik, een meester, die res is slegs leesbare replikas.
Die aantal van hierdie lopende Aurora-kapasiteitseenhede is 'n konfigureerbare instelling. Die minimum getal kan een of nul wees (in hierdie geval werk die databasis nie as daar geen versoeke is nie).
Wanneer die basis versoeke ontvang, verhoog die proxy vloot Aurora Capacity Units, wat die stelsel se produktiewe hulpbronne verhoog. Die vermoë om hulpbronne te vermeerder en te verminder stel die stelsel in staat om hulpbronne te "jongleer": vertoon outomaties individuele ACU's (vervang dit met nuwes) en rol alle relevante opdaterings op die onttrekte hulpbronne.
Die Aurora Serverless-basis kan die leeslading skaal. Maar die dokumentasie sê dit nie direk nie. Jy kan die gevoel kry dat hulle 'n multi-meester kan grootmaak. Daar is geen magie nie.
Hierdie basis is goed geskik om te verhoed dat groot bedrae geld bestee word aan stelsels met onvoorspelbare toegang. Byvoorbeeld, wanneer ons 'n MVP of die bemarking van pamflette-webwerwe bou, verwag ons gewoonlik nie 'n bestendige vrag nie. Gevolglik, in die afwesigheid van toegang, betaal ons nie vir gevalle nie. Wanneer 'n vrag skielik opduik, byvoorbeeld, na 'n konferensie of 'n advertensieveldtog, skares mense die werf binnegaan en die vrag styg skerp, neem Aurora Serverless outomaties hierdie vrag en koppel vinnig die ontbrekende hulpbronne (ACU). Dan gaan die konferensie verby, almal vergeet van die prototipe, die bedieners (ACU) gaan uit, en die koste daal tot nul – gerieflik.
Hierdie oplossing is nie geskik vir 'n stabiele hoë hoëlading nie omdat dit nie die skryflading kan skaal nie. Al hierdie verbindings en ontkoppelings van hulpbronne vind plaas op die oomblik van die sogenaamde "skaalpunt" - die oomblik in tyd wanneer die databasis nie deur 'n transaksie gehou word nie, word tydelike tabelle nie gehou nie. Byvoorbeeld, binne 'n week kan die skaalpunt nie plaasvind nie, en die databasis werk op dieselfde hulpbronne en kan eenvoudig nie uitbrei of krimp nie.
Daar is geen magie nie - dit is net gewone PostgreSQL. Maar die proses om masjiene by te voeg en hulle te ontkoppel, is gedeeltelik geoutomatiseer.
Bedienerlose ontwerp
Aurora Serverless is 'n ou basis wat herskryf is vir die wolke om voordeel te trek uit sommige van die voordele van Serverless. En nou sal ek jou vertel van die databasis, wat oorspronklik vir die wolke geskryf is, vir die bedienerlose benadering - Serverless-by-design. Dit is dadelik ontwikkel sonder die aanname dat dit op fisiese bedieners werk.
Hierdie basis word Snowflake genoem. Dit het drie sleutelblokke.
Die eerste is die metadatablok. Dit is 'n vinnige in-geheue diens wat probleme met sekuriteit, metadata, transaksies, navraagoptimering oplos (in die illustrasie aan die linkerkant).
Die tweede blok is 'n stel virtuele rekenaarklusters vir berekeninge (in die illustrasie, 'n stel blou sirkels).
Die derde blok is 'n stoorstelsel gebaseer op S3. S3 is die dimensielose voorwerpberging in AWS, soort van soos die dimensielose Dropbox vir besigheid.
Kom ons kyk hoe Snowflake werk, met 'n koue begin. Dit wil sê, die databasis is daar, die data word daarin gelaai, daar is geen werkende navrae nie. Gevolglik, as daar geen versoeke na die databasis is nie, het ons 'n vinnige in-geheue Metadata-diens (die eerste blok). En ons het S3-berging, waar die tabeldata gestoor word, verdeel in sogenaamde mikro-partisies. Vir eenvoud: as daar transaksies in die tabel is, dan is mikropartisies die dae van transaksies. Elke dag is 'n aparte mikropartisie, 'n aparte lêer. En wanneer die databasis in hierdie modus werk, betaal jy slegs vir die spasie wat deur die data beset word. Boonop is die tarief per sitplek baie laag (veral gegewe die aansienlike kompressie). Die metadatadiens werk ook heeltyd, maar dit neem nie baie hulpbronne om navrae te optimaliseer nie, en die diens kan as deelware beskou word.
Kom ons stel ons nou voor dat 'n gebruiker na ons databasis gekom het en 'n SQL-navraag gegooi het. Die SQL-navraag word onmiddellik vir verwerking na die Metadata-diens gestuur. Gevolglik, na ontvangs van 'n versoek, ontleed hierdie diens die versoek, beskikbare data, gebruikertoestemmings en, as alles reg is, stel 'n plan op vir die verwerking van die versoek.
Vervolgens begin die diens die bekendstelling van die rekenaarkluster. 'n Rekenaarkluster is 'n groep bedieners wat berekeninge uitvoer. Dit wil sê, dit is 'n groep wat 1 bediener, 2 bedieners, 4, 8, 16, 32 kan bevat - soveel as wat jy wil. Jy gooi 'n versoek en daaronder begin die bekendstelling van hierdie groep onmiddellik. Dit neem regtig sekondes.
Verder, nadat die groepering begin het, begin die mikropartisies wat nodig is om jou versoek te verwerk, na die groepering vanaf S3 gekopieer word. Dit wil sê, stel jou voor dat jy twee partisies van een tabel en een van die tweede nodig het om 'n SQL-navraag uit te voer. In hierdie geval sal slegs drie nodige partisies na die groep gekopieer word, en nie alle tabelle as 'n geheel nie. Dit is hoekom, en juis omdat alles in dieselfde datasentrum geleë is en deur baie vinnige kanale verbind is, is die hele oordragproses baie vinnig: in sekondes, baie selde - in minute, tensy ons praat oor 'n paar monsteragtige versoeke. . Gevolglik word mikropartisies na die rekenaarkluster gekopieer, en na voltooiing word 'n SQL-navraag op hierdie rekenaarkluster uitgevoer. Die resultaat van hierdie versoek kan een reël, verskeie reëls of 'n tabel wees - dit word aan die gebruiker uitgestuur sodat hy dit kan oplaai, dit in sy BI-instrument kan vertoon, of dit op 'n ander manier kan gebruik.
Elke SQL-navraag kan nie net aggregate van voorheen gelaaide data lees nie, maar ook nuwe data in die databasis laai/vorm. Dit wil sê, dit kan 'n navraag wees wat byvoorbeeld nuwe rekords in 'n ander tabel invoeg, wat lei tot die verskyning van 'n nuwe partisie op die rekenaarkluster, wat op sy beurt outomaties in 'n enkele S3-berging gestoor word.
Die scenario hierbo beskryf, vanaf die aankoms van 'n gebruiker tot die verhoging van die groep, die laai van data, die uitvoering van navrae, die verkryging van resultate, word betaal teen die koers vir minute van die gebruik van die verhoogde virtuele rekenaargroepering, virtuele pakhuis. Tariewe wissel volgens AWS-sone en groepgrootte, maar die gemiddelde is 'n paar dollar per uur. 'n Groep van vier motors is twee keer so duur as twee motors, 'n groep van agt motors is twee keer so duur. Beskikbare opsies vanaf 16, 32 masjiene, afhangende van die kompleksiteit van die versoeke. Maar jy betaal net vir daardie minute wanneer die groep regtig werk, want as daar geen versoeke is nie, verwyder jy soort van jou hande, en na 5-10 minute se wag (konfigureerbare parameter), sal dit vanself afskakel, vrymaak hulpbronne en word vry.
Die scenario is redelik werklik wanneer jy 'n versoek stuur, die groep verskyn, relatief gesproke, in 'n minuut, dit tel vir nog 'n minuut, dan vyf minute om dit af te skakel, en jy betaal uiteindelik vir sewe minute van hierdie groep, en nie vir maande en jare nie.
Die eerste scenario het die gebruik van Snowflake in 'n enkelgebruikermodus beskryf. Kom ons stel ons nou voor dat daar baie gebruikers is, wat nader aan die werklike scenario is.
Gestel ons het baie ontleders en Tableau-verslae wat voortdurend ons databasis bombardeer met baie eenvoudige analitiese SQL-navrae.
Daarbenewens, kom ons sê dat ons vindingryke datawetenskaplikes het wat monsteragtige dinge met data probeer doen, op tiene teragrepe werk, miljarde en triljoene datarye ontleed.
Vir die twee tipes werk wat hierbo beskryf word, laat Snowflake jou toe om verskeie onafhanklike rekenaarklusters van verskillende vermoëns te verhoog. Boonop werk hierdie rekenaarklusters onafhanklik, maar met algemene konsekwente data.
Vir 'n groot aantal ligte navrae, kan jy 2-3 klein groepe oprig, voorwaardelik 2 masjiene in grootte elk. Hierdie gedrag word geïmplementeer, insluitend die gebruik van outomatiese instellings. So jy sê: "Sneeuvlok, tel 'n klein tros op. As die las daarop meer as 'n sekere parameter groei, verhoog 'n soortgelyke tweede, derde. Wanneer die las begin afneem, blus die ekstras. Sodat, ongeag hoeveel ontleders na verslae kom en begin kyk, almal genoeg hulpbronne het.
Terselfdertyd, as ontleders slaap en niemand kyk na die verslae nie, kan die clusters heeltemal uitgaan, en jy hou op om daarvoor te betaal.
Terselfdertyd, vir swaar navrae (van Data Scientists), kan jy een baie groot groepie vir 32 voorwaardelike masjiene opstel. Hierdie groepie sal ook net betaal word vir daardie minute en ure wanneer jou reuse-versoek daar werk.
Met die kenmerk wat hierbo beskryf word, kan u nie net 2 in groepe verdeel nie, maar ook meer tipes werklading (ETL, monitering, materialisering van verslae, ...).
Kom ons som Snowflake op. Die basis kombineer 'n pragtige idee en 'n werkbare implementering. By ManyChat gebruik ons Snowflake om al die data wat ons het te ontleed. Ons het nie drie trosse, soos in die voorbeeld nie, maar van 5 tot 9, van verskillende groottes. Ons het voorwaardelike 16-masjien, 2-masjien, en super-klein 1-masjien vir sommige take. Hulle versprei die vrag suksesvol en stel ons in staat om baie te bespaar.
Die basis skaal die lees- en skryflading suksesvol. Dit is 'n groot verskil en 'n groot deurbraak in vergelyking met dieselfde Aurora, wat net die leeslading getrek het. Snowflake laat hierdie rekenaarklusters toe om ook die skryflading te skaal. Dit wil sê, soos ek genoem het, gebruik ons verskeie clusters in ManyChat, klein en super klein clusters word hoofsaaklik gebruik vir ETL, vir die laai van data. En ontleders woon reeds op mediumgrootte groepe wat absoluut nie deur die ETL-lading geraak word nie, so hulle werk baie vinnig.
Gevolglik is die databasis goed geskik vir OLAP-take. Terselfdertyd is dit ongelukkig nog nie van toepassing op OLTP-vragte nie. Eerstens is hierdie basis kolomvormig, met al die gevolge daarvan. Tweedens, die benadering self, wanneer jy vir elke versoek, indien nodig, 'n rekenaargroepering oprig en dit met data mors, is dit ongelukkig steeds nie vinnig genoeg vir OLTP-ladings nie. Om sekondes te wag vir OLAP-take is normaal, maar vir OLTP-take is dit onaanvaarbaar, 100 ms sal beter wees, en selfs beter - 10 ms.
Totale
'n Bedienerlose databasis is moontlik deur die databasis in Stateless en Stateful dele te verdeel. Jy het seker opgemerk dat in al die voorbeelde wat gegee is, die Stateful-deel relatief gesproke mikropartisies in S3 stoor, en Stateless is die optimeerder, wat met metadata werk en sekuriteitskwessies hanteer wat as onafhanklike liggewig staatlose dienste geopper kan word.
Die uitvoering van SQL-navrae kan ook beskou word as dienste met 'n ligte toestand, wat in bedienerlose modus kan ontstaan, soos Snowflake-rekenaarklusters, net die nodige data aflaai, die navraag uitvoer en "uitgaan".
Bedienerlose produksievlak databasisse is reeds beskikbaar vir gebruik, hulle werk. Hierdie bedienerlose databasisse is reeds gereed om OLAP-take te hanteer. Ongelukkig word hulle vir OLTP-take gebruik ... met nuanses, aangesien daar beperkings is. Aan die een kant is dit 'n minus. Maar aan die ander kant is dit 'n geleentheid. Miskien sal een van die lesers 'n manier vind om die OLTP-databasis heeltemal bedienerloos te maak, sonder die beperkings van Aurora.
Ek hoop jy het belang gestel. Bedienerloos is die toekoms 🙂
Bron: will.com