Hoi allegearre! Myn namme is Golov Nikolay. Earder wurke ik by Avito en behearde it Data Platform foar seis jier, dat is, ik wurke oan alle databases: analytysk (Vertica, ClickHouse), streaming en OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Yn dizze tiid haw ik te krijen mei in grut oantal databases - hiel oars en ûngewoan, en mei net-standert gefallen fan har gebrûk.
Ik wurkje op it stuit by ManyChat. Yn essinsje is dit in opstart - nij, ambisjeus en rap groeiende. En doe't ik foar it earst by it bedriuw kaam, ûntstie in klassike fraach: "Wat moat in jonge startup no nimme fan 'e DBMS- en databasemerk?"
Yn dit artikel, basearre op myn rapport by , Ik sil beäntwurdzje dizze fraach. In fideoferzje fan it rapport is beskikber op .
Algemien bekende databases 2020
It is 2020, ik seach om my hinne en seach trije soarten databases.
Earste type - klassike OLTP-databases: PostgreSQL, SQL Server, Oracle, MySQL. Se binne lang lyn skreaun, mar binne noch altyd relevant om't se sa bekend binne foar de ûntwikkeldersmienskip.
It twadde type is basis fan "nul". Se besochten fuort te gean fan klassike patroanen troch SQL, tradisjonele struktueren en ACID te ferlitten, troch ynboude sharding en oare oantreklike funksjes ta te foegjen. Dit is bygelyks Cassandra, MongoDB, Redis of Tarantool. Al dizze oplossingen woene de merk wat fûneminteel nij oanbiede en besette har niche, om't se heul handich bleken te wêzen foar bepaalde taken. Ik sil dizze databases oantsjutte mei de oerkoepeljende term NOSQL.
De "nullen" binne foarby, wy binne wend oan NOSQL-databases, en de wrâld naam, út myn eachpunt, de folgjende stap - om managed databases. Dizze databases hawwe deselde kearn as klassike OLTP-databases as nije NoSQL-databases. Mar se hawwe gjin ferlet fan DBA en DevOps en rinne op beheare hardware yn 'e wolken. Foar in ûntwikkelder is dit "gewoan in basis" dy't earne wurket, mar gjinien makket it út hoe't it is ynstalleare op 'e tsjinner, wa't de tsjinner konfigureare en wa't it bywurket.
Foarbylden fan sokke databases:
- AWS RDS is in managed wrapper foar PostgreSQL/MySQL.
- DynamoDB is in AWS-analooch fan in dokumint basearre databank, fergelykber mei Redis en MongoDB.
- Amazon Redshift is in behearde analytyske databank.
Dit binne yn prinsipe âlde databases, mar grutbrocht yn in beheare omjouwing, sûnder de needsaak om te wurkjen mei hardware.
Noat. De foarbylden wurde nommen foar de AWS-omjouwing, mar har analogen besteane ek yn Microsoft Azure, Google Cloud, of Yandex.Cloud.
Wat is nij oer dit? Yn 2020, neat fan dit.
Serverless konsept
Wat wirklik nij is op 'e merke yn 2020 is serverless as serverless oplossingen.
Ik sil besykje út te lizzen wat dit betsjut mei it foarbyld fan in reguliere tsjinst as backend-applikaasje.
Om in reguliere backend-applikaasje yn te setten, keapje of hiere wy in server, kopiearje de koade derop, publisearje it einpunt bûten en betelje geregeld foar hier, elektrisiteit en tsjinsten foar datacenters. Dit is it standert skema.
Is der in oare manier? Mei serverless tsjinsten kinne jo.
Wat is it fokus fan dizze oanpak: d'r is gjin server, d'r is net iens in firtuele eksimplaar yn 'e wolk te hieren. Om de tsjinst yn te setten, kopiearje de koade (funksjes) nei it repository en publisearje it nei it einpunt. Dan betelje wy gewoan foar elke oprop nei dizze funksje, folslein negearje de hardware wêr't it wurdt útfierd.
Ik sil besykje dizze oanpak te yllustrearjen mei foto's.
Klassike ynset. Wy hawwe in tsjinst mei in bepaalde lading. Wy ferheegje twa eksimplaren: fysike tsjinners as eksimplaren yn AWS. Eksterne oanfragen wurde nei dizze ynstânsjes stjoerd en dêr ferwurke.
Sa't jo op 'e foto kinne sjen, binne de servers net gelyk ferwidere. Ien wurdt 100% brûkt, d'r binne twa oanfragen, en ien is mar 50% - foar in part idle. As der net trije oanfragen komme, mar 30, dan sil it hiele systeem net by steat wêze om te gaan met de lading en sil begjinne te fertrage.
Serverless ynset. Yn in serverleaze omjouwing hat sa'n tsjinst gjin eksimplaren of servers. D'r is in bepaald swimbad fan ferwaarme boarnen - lytse taret Docker-konteners mei ynset funksjekoade. It systeem ûntfangt eksterne oanfragen en foar elk fan har bringt it serverless ramt in lytse kontener mei koade op: it ferwurket dit bepaalde fersyk en deadet de kontener.
Ien fersyk - ien kontener ferhege, 1000 oanfragen - 1000 konteners. En ynset op hardware-tsjinners is al it wurk fan 'e wolkprovider. It is folslein ferburgen troch it serverless ramt. Yn dit konsept betelje wy foar elke oprop. Bygelyks, ien oprop kaam in dei - wy betellen foar ien oprop, in miljoen kaam per minuut - wy betellen foar in miljoen. Of yn in sekonde bart dit ek.
It konsept fan it publisearjen fan in serverleaze funksje is geskikt foar in steatleaze tsjinst. En as jo in (state) statefull tsjinst nedich hawwe, dan foegje wy in databank ta oan 'e tsjinst. Yn dit gefal, as it giet om wurkjen mei steat, skriuwt en lêst elke statefullfunksje gewoan út 'e databank. Boppedat, út in databank fan ien fan de trije soarten beskreaun oan it begjin fan it artikel.
Wat is de mienskiplike beheining fan al dizze databases? Dit binne de kosten fan in konstant brûkte wolk- of hardwareserver (of ferskate servers). It makket neat út oft wy brûke in klassike of managed databank, oft wy hawwe Devops en in admin of net, wy noch betelje foar hardware, elektrisiteit en data sintrum ferhier 24/7. As wy in klassike basis hawwe, betelje wy foar master en slaaf. As it in tige laden sharded databank is, betelje wy foar 10, 20 of 30 tsjinners, en wy betelje konstant.
De oanwêzigens fan permanint reservearre servers yn 'e kostenstruktuer waard earder ûnderfûn as in needsaaklik kwea. Konvinsjonele databases hawwe ek oare swierrichheden, lykas grinzen op it oantal ferbinings, skaalfergruttings, geo-ferdielde konsensus - se kinne op ien of oare manier oplost wurde yn bepaalde databases, mar net allegear tagelyk en net ideaal.
Serverless databank - teory
Fraach fan 2020: is it mooglik om in database ek tsjinnerleas te meitsjen? Elkenien hat heard oer de serverless backend ... litte wy besykje de databank serverless te meitsjen?
Dit klinkt nuver, om't de databank in statefull tsjinst is, net heul geskikt foar serverless ynfrastruktuer. Tagelyk is de tastân fan de databank tige grut: gigabytes, terabytes, en yn analytyske databanken sels petabytes. It is net sa maklik om it te ferheegjen yn lichtgewicht Docker-konteners.
Oan 'e oare kant befetsje hast alle moderne databases in enoarme hoemannichte logika en komponinten: transaksjes, yntegriteitskoördinaasje, prosedueres, relasjonele ôfhinklikens en in protte logika. Foar in soad databanklogika is in lytse steat genôch. Gigabytes en Terabytes wurde direkt brûkt troch mar in lyts diel fan 'e databaselogika dy't belutsen is by it direkt útfieren fan queries.
Dêrnjonken is it idee: as in diel fan 'e logika steatleaze útfiering mooglik makket, wêrom dan de basis net opspjalte yn Stateful en Stateless dielen.
Serverless foar OLAP-oplossingen
Litte wy sjen hoe't it snijen fan in databank yn Stateful en Stateless dielen der út kin útsjen mei praktyske foarbylden.
Wy hawwe bygelyks in analytyske databank: eksterne gegevens (reade silinder oan de linkerkant), in ETL proses dat laden gegevens yn de databank, en in analist dy't stjoert SQL queries nei de databank. Dit is in klassyk data warehouse operaasje skema.
Yn dit skema wurdt ETL ien kear betingst útfierd. Dan moatte jo konstant betelje foar de servers wêrop de databank rint mei gegevens fol mei ETL, sadat d'r wat is om fragen nei te stjoeren.
Litte wy sjen nei in alternative oanpak ymplementearre yn AWS Athena Serverless. D'r is gjin permanint tawijd hardware wêrop ynladen gegevens wurde opslein. Yn stee fan dit:
- De brûker stjoert in SQL-fraach oan Athena. De Athena-optimizer analysearret de SQL-query en siket de metadata-winkel (Metadata) foar de spesifike gegevens dy't nedich binne om de query út te fieren.
- De optimizer, basearre op de sammele gegevens, downloadt de nedige gegevens fan eksterne boarnen yn tydlike opslach (tydlike databank).
- In SQL-fraach fan de brûker wurdt útfierd yn tydlike opslach en it resultaat wurdt weromjûn oan de brûker.
- Tydlike opslach wurdt wiske en boarnen wurde frijjûn.
Yn dizze arsjitektuer betelje wy allinich foar it proses fan it útfieren fan it fersyk. Gjin oanfragen - gjin kosten.
Dit is in wurkjende oanpak en wurdt ymplementearre net allinich yn Athena Serverless, mar ek yn Redshift Spectrum (yn AWS).
It Athena-foarbyld lit sjen dat de Serverless-database wurket op echte queries mei tsientallen en hûnderten Terabytes oan gegevens. Hûnderten Terabytes sille hûnderten servers fereaskje, mar wy hoege der net foar te beteljen - wy betelje foar de oanfragen. De snelheid fan elk fersyk is (hiel) leech yn ferliking mei spesjalisearre analytyske databases lykas Vertica, mar wy betelje net foar downtime perioaden.
Sa'n databank is fan tapassing foar seldsume analytyske ad-hoc-fragen. Bygelyks, as wy spontaan beslute om in hypoteze te testen op in gigantyske hoemannichte gegevens. Athena is perfekt foar dizze gefallen. Foar reguliere oanfragen is sa'n systeem djoer. Yn dit gefal, cache de gegevens yn guon spesjalisearre oplossing.
Serverless foar OLTP-oplossingen
It foarige foarbyld seach nei OLAP (analytyske) taken. Litte wy no nei OLTP-taken sjen.
Litte wy ús skaalber PostgreSQL of MySQL foarstelle. Litte wy in reguliere behearde eksimplaar PostgreSQL of MySQL ophelje mei minimale boarnen. As de eksimplaar mear lading ûntfangt, sille wy ekstra replika's ferbine wêrop wy in diel fan 'e lêslading sille fersprieden. As d'r gjin oanfragen of laden binne, skeakelje wy de replika's út. It earste eksimplaar is de master, en de rest binne replika's.
Dit idee wurdt ymplementearre yn in database mei de namme Aurora Serverless AWS. It prinsipe is ienfâldich: oanfragen fan eksterne applikaasjes wurde akseptearre troch de proxyfloat. Sjoen de lading tanimme, allocearret it komputerboarnen út pre-ferwaarme minimale eksimplaren - de ferbining wurdt sa rap mooglik makke. It útskeakeljen fan eksimplaren komt op deselde wize foar.
Binnen Aurora is d'r it konsept fan Aurora Capacity Unit, ACU. Dit is (betingsten) in eksimplaar (tsjinner). Elke spesifike ACU kin in master as in slaaf wêze. Elke kapasiteitseenheid hat syn eigen RAM, prosessor en minimale skiif. Dêrnjonken is ien master, de rest wurde allinich replika's lêzen.
It oantal fan dizze Aurora Capacity Units dy't rinne is in ynstelbere parameter. De minimale kwantiteit kin ien of nul wêze (yn dit gefal wurket de databank net as der gjin oanfragen binne).
As de basis oanfragen ûntfangt, ferheget de proxyfloat Aurora CapacityUnits, wêrtroch de prestaasjesboarnen fan it systeem ferheegje. De mooglikheid om boarnen te fergrutsjen en te ferminderjen lit it systeem mei boarnen "jongleren": automatysk yndividuele ACU's werjaan (ferfange se troch nije) en rôlje alle aktuele updates út nei de ynlutsen boarnen.
De basis fan Aurora Serverless kin de lêslading skaalje. Mar de dokumintaasje seit dit net direkt. It kin fiele dat se in multi-master ophelje kinne. Der is gjin magy.
Dizze databank is goed geskikt om foar te kommen dat jo enoarme hoemannichten jild útjaan oan systemen mei ûnfoarspelbere tagong. Bygelyks, by it meitsjen fan MVP- of marketing-sites foar visitekaarten, ferwachtsje wy normaal gjin stabile lading. As d'r gjin tagong is, betelje wy dêrom net foar gefallen. Wannear't ûnferwachte lading optreedt, bygelyks nei in konferinsje of reklamekampanje, besykje mannichte minsken de side en de lading nimt dramatysk ta, Aurora Serverless nimt dizze lading automatysk en ferbynt de ûntbrekkende boarnen (ACU) fluch. Dan giet de konferinsje foarby, elkenien ferjit it prototype, de servers (ACU) wurde tsjuster, en de kosten sakje nei nul - handich.
Dizze oplossing is net geskikt foar stabile hege lading, om't it de skriuwlast net skaalet. Al dizze ferbinings en disconnections fan boarnen foarkomme op it saneamde "skaalpunt" - in punt yn 'e tiid dat de databank net wurdt stipe troch in transaksje of tydlike tabellen. Bygelyks, binnen in wike kin it skaalpunt net barre, en de basis wurket op deselde boarnen en kin gewoan net útwreidzje of kontraktearje.
D'r is gjin magy - it is gewoan PostgreSQL. Mar it proses fan it tafoegjen fan masines en it loskoppelen is foar in part automatisearre.
Serverless by design
Aurora Serverless is in âlde databank opnij skreaun foar de wolk om te profitearjen fan guon fan 'e foardielen fan Serverless. En no sil ik jo fertelle oer de basis, dy't oarspronklik waard skreaun foar de wolk, foar de serverless oanpak - Serverless-by-design. It waard fuortendaliks ûntwikkele sûnder de oanname dat it soe rinne op fysike servers.
Dizze basis wurdt Snowflake neamd. It hat trije kaai blokken.
De earste is in metadatablok. Dit is in rappe tsjinst yn it ûnthâld dy't problemen oplost mei feiligens, metadata, transaksjes, en query-optimalisaasje (werjûn yn 'e yllustraasje links).
It twadde blok is in set fan firtuele kompjûterklusters foar berekkeningen (yn 'e yllustraasje is d'r in set fan blauwe sirkels).
It tredde blok is in gegevens opslachsysteem basearre op S3. S3 is dimensjeleaze objektopslach yn AWS, in soarte fan dimensjeleaze Dropbox foar bedriuw.
Litte wy sjen hoe't Snowflake wurket, útgeande fan in kâlde start. Dat is, d'r is in databank, de gegevens wurde dêryn laden, d'r binne gjin rinnende fragen. Dêrom, as d'r gjin oanfragen binne foar de databank, dan hawwe wy de snelle Metadata-tsjinst yn it ûnthâld opbrocht (earste blok). En wy hawwe S3 opslach, dêr't tabel gegevens wurdt opslein, ferdield yn saneamde micropartitions. Foar ienfâld: as de tabel transaksjes befettet, dan binne mikropartisjes de dagen fan transaksjes. Elke dei is in aparte mikropartition, in apart bestân. En as de databank yn dizze modus wurket, betelje jo allinich foar de romte beset troch de gegevens. Boppedat is it taryf per sit tige leech (benammen mei it rekkenjen fan de signifikante kompresje). De metadata-tsjinst wurket ek konstant, mar jo hawwe net in protte boarnen nedich om queries te optimalisearjen, en de tsjinst kin wurde beskôge as shareware.
Lit ús no yntinke dat in brûker nei ús databank kaam en in SQL-query stjoerde. De SQL-fraach wurdt fuortendaliks stjoerd nei de Metadata-tsjinst foar ferwurking. Sadwaande analysearret dizze tsjinst by ûntfangst fan in fersyk it fersyk, beskikbere gegevens, brûkersrjochten en, as alles goed is, in plan foar it ferwurkjen fan it fersyk op.
Dêrnei inisjearret de tsjinst de lansearring fan it komputerkluster. In komputerkluster is in kluster fan tsjinners dy't berekkeningen útfiere. Dat is, dit is in kluster dat kin befetsje 1 tsjinner, 2 tsjinners, 4, 8, 16, 32 - safolle as jo wolle. Jo smyt in fersyk en de lansearring fan dit kluster fuortendaliks begjint. It duorret echt sekonden.
Folgjende, neidat it kluster is begon, begjinne de mikropartisjes dy't nedich binne om jo oanfraach te ferwurkjen te kopiearjen yn it kluster fan S3. Dat is, lit ús yntinke dat om in SQL-query út te fieren jo twa partysjes nedich hawwe fan ien tabel en ien fan 'e twadde. Yn dit gefal wurde allinich de trije nedige partysjes kopiearre nei it kluster, en net alle tabellen folslein. Dêrom, en krekt om't alles yn ien datasintrum leit en ferbûn is troch heul rappe kanalen, komt it heule oerdrachtproses heul fluch: yn sekonden, heul komselden yn minuten, útsein as wy it hawwe oer guon meunsterlike oanfragen. Dêrtroch wurde mikropartisjes kopiearre nei it komputerkluster, en, nei foltôging, wurdt de SQL-query útfierd op dit komputerkluster. It resultaat fan dit fersyk kin ien rigel, ferskate rigels of in tabel wêze - se wurde ekstern nei de brûker stjoerd, sadat hy it kin downloade, werjaan yn syn BI-ark, of op in oare manier brûke.
Elke SQL-query kin net allinich aggregaten lêze fan earder laden gegevens, mar ek nije gegevens yn 'e databank lade / generearje. Dat is, it kin in query wêze dy't bygelyks nije records yn in oare tabel ynfoegje, wat liedt ta it ferskinen fan in nije partysje op 'e komputerkluster, dy't op syn beurt automatysk wurdt bewarre yn ien S3-opslach.
It hjirboppe beskreaune senario, fan 'e komst fan' e brûker oant it ferheegjen fan 'e kluster, it laden fan gegevens, it útfieren fan fragen, it krijen fan resultaten, wurdt betelle op it taryf foar minuten fan it brûken fan it ferhege firtuele kompjûterkluster, firtuele pakhús. It taryf ferskilt ôfhinklik fan 'e AWS-sône en klustergrutte, mar gemiddeld is it in pear dollar per oere. In kluster fan fjouwer masines is twa kear sa djoer as in kluster fan twa masines, en in kluster fan acht masines is noch twa kear sa djoer. Opsjes fan 16, 32 masines binne beskikber, ôfhinklik fan de kompleksiteit fan de oanfragen. Mar jo betelje allinich foar dy minuten as it kluster eins rint, want as d'r gjin oanfragen binne, nimme jo jo hannen ôf, en nei 5-10 minuten wachtsjen (in ynstelbere parameter) sil it fan himsels gean, boarnen frijmeitsje en fergees wurde.
In folslein realistysk senario is as jo in fersyk ferstjoere, it kluster ferskynt, relatyf sjoen, yn in minút, it telt noch in minút, dan fiif minuten om út te sluten, en jo betelje úteinlik foar sân minuten fan operaasje fan dit kluster, en net foar moannen en jierren.
It earste senario beskreaun mei Snowflake yn in ynstelling foar ien brûker. Lit ús no yntinke dat d'r in protte brûkers binne, wat tichter by it echte senario is.
Litte wy sizze dat wy in protte analisten en Tableau-rapporten hawwe dy't ús databank konstant bombardearje mei in grut oantal ienfâldige analytyske SQL-fragen.
Derneist, litte wy sizze dat wy ynventive gegevenswittenskippers hawwe dy't besykje meunsterlike dingen te dwaan mei gegevens, operearje mei tsientallen Terabytes, analysearje miljarden en trillions fan rigen gegevens.
Foar de twa hjirboppe beskreaune soarten wurkdruk lit Snowflake jo ferskate ûnôfhinklike komputerklusters fan ferskate kapasiteiten ferheegje. Boppedat wurkje dizze komputerklusters selsstannich, mar mei mienskiplike konsekwinte gegevens.
Foar in grut oantal ljochtfragen kinne jo 2-3 lytse klusters ferheegje, sawat 2 masines elk. Dit gedrach kin ûnder oare ymplementearre wurde mei automatyske ynstellingen. Dat jo sizze: "Snievlok, meitsje in lyts kluster op. As de lading derop ferheget boppe in bepaalde parameter, ferheegje in ferlykbere twadde, tredde. As de lading begjint te sakjen, doch it oerskot út." Dat nettsjinsteande hoefolle analisten komme en begjinne te sjen nei rapporten, elkenien hat genôch middels.
Tagelyk, as analysten yn 'e sliep binne en gjinien sjocht nei de rapporten, kinne de klusters folslein tsjuster wurde, en jo stopje mei beteljen foar har.
Tagelyk kinne jo foar swiere fragen (fan Data Scientists) ien heul grut kluster ophelje foar 32 masines. Dit kluster sil ek allinich betelle wurde foar dy minuten en oeren as jo gigantyske fersyk dêr rint.
De hjirboppe beskreaune kâns lit jo net allinich 2, mar ek mear soarten wurkdruk yn klusters ferdielen (ETL, tafersjoch, rapportmaterialisaasje, ...).
Litte wy Snowflake gearfetsje. De basis kombinearret in prachtich idee en in wurkbere útfiering. By ManyChat brûke wy Snowflake om alle gegevens te analysearjen dy't wy hawwe. Wy hawwe gjin trije klusters, lykas yn it foarbyld, mar fan 5 oant 9, fan ferskillende grutte. Wy hawwe konvinsjonele 16-masine, 2-masine, en ek super-lytse 1-masine foar guon taken. Se fersprieden de lading mei súkses en lit ús in protte besparje.
De databank skaal mei súkses de lês- en skriuwlading. Dit is in enoarm ferskil en in enoarme trochbraak yn ferliking mei deselde "Aurora", dy't allinich de lêslading droech. Snowflake lit jo jo skriuwwurklast skaalje mei dizze kompjûterklusters. Dat is, lykas ik neamde, wy brûke ferskate klusters yn ManyChat, lytse en super-lytse klusters wurde benammen brûkt foar ETL, foar it laden fan gegevens. En analysten libje al op middelgrutte klusters, dy't perfoarst net wurde beynfloede troch de ETL-lading, sadat se tige fluch wurkje.
Dêrtroch is de databank goed geskikt foar OLAP-taken. Spitigernôch is it lykwols noch net fan tapassing foar OLTP-workloads. As earste is dizze databank kolumnêr, mei alle gefolgen dy't derop komme. Twad, de oanpak sels, as jo foar elke oanfraach, as it nedich is, in komputerkluster ophelje en it oerstreame mei gegevens, spitigernôch, is noch net fluch genôch foar OLTP-loads. Sekonden wachtsje op OLAP-taken is normaal, mar foar OLTP-taken is it net akseptabel; 100 ms soe better wêze, of 10 ms soe noch better wêze.
It resultaat
In serverless databank is mooglik troch it dielen fan de databank yn Stateless en Stateful dielen. Jo hawwe miskien opfallen dat yn alle boppesteande foarbylden it Stateful-diel, relatyf sprutsen, mikro-partysjes yn S3 opslacht, en Stateless is de optimizer, wurket mei metadata, behannelet feiligensproblemen dy't kinne wurde opheft as ûnôfhinklike lichtgewicht Stateless tsjinsten.
It útfieren fan SQL-query's kin ek wurde waarnommen as ljocht-state-tsjinsten dy't yn serverleaze modus kinne opdûke, lykas Snowflake-komputerklusters, allinich de nedige gegevens downloade, de query útfiere en "útgean."
Serverless produksjenivo databanken binne al beskikber foar gebrûk, se wurkje. Dizze serverless databases binne al klear om OLAP-taken te behanneljen. Spitigernôch wurde se foar OLTP-taken brûkt ... mei nuânses, om't d'r beheiningen binne. Oan 'e iene kant is dit in minus. Mar oan 'e oare kant is dit in kâns. Miskien sil ien fan 'e lêzers in manier fine om in OLTP-database folslein serverless te meitsjen, sûnder de beheiningen fan Aurora.
Ik hoopje dat jo it ynteressant fûnen. Serverless is de takomst 🙂
Boarne: www.habr.com