Hei kaikki! Nimeni on Golov Nikolay. Aiemmin työskentelin Avitossa ja hallinnoin Data Platformia kuusi vuotta, eli työskentelin kaikkien tietokantojen parissa: analyyttisten (Vertica, ClickHouse), streaming- ja OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL) parissa. Tänä aikana olen käsitellyt suurta määrää tietokantoja - hyvin erilaisia ja epätavallisia, ja epätyypillisiä niiden käyttötapauksia.
Työskentelen tällä hetkellä ManyChatissa. Pohjimmiltaan tämä on startup - uusi, kunnianhimoinen ja nopeasti kasvava. Ja kun ensimmäisen kerran liityin yritykseen, heräsi klassinen kysymys: "Mitä nuoren startupin pitäisi nyt ottaa DBMS- ja tietokantamarkkinoilta?"
Tässä artikkelissa, joka perustuu raporttiini osoitteessa , Vastaan tähän kysymykseen. Raportin videoversio on saatavilla osoitteessa .
Yleisesti tunnetut tietokannat 2020
On vuosi 2020, katselin ympärilleni ja näin kolmenlaisia tietokantoja.
Ensimmäinen tyyppi - klassiset OLTP-tietokannat: PostgreSQL, SQL Server, Oracle, MySQL. Ne on kirjoitettu kauan sitten, mutta ovat edelleen ajankohtaisia, koska ne ovat niin tuttuja kehittäjäyhteisölle.
Toinen tyyppi on perusteet "nollasta". He yrittivät siirtyä pois klassisista malleista luopumalla SQL:stä, perinteisistä rakenteista ja ACID:stä, lisäämällä sisäänrakennettua shardingia ja muita houkuttelevia ominaisuuksia. Tämä on esimerkiksi Cassandra, MongoDB, Redis tai Tarantool. Kaikki nämä ratkaisut halusivat tarjota markkinoille jotain täysin uutta ja valloittivat markkinaraon, koska ne osoittautuivat erittäin käteviksi tiettyihin tehtäviin. Merkitsen näitä tietokantoja kattotermillä NOSQL.
"nollat" ovat ohi, totuimme NOSQL-tietokantoihin, ja maailma otti minun näkökulmastani seuraavan askeleen - hallinnoidut tietokannat. Näillä tietokannoilla on sama ydin kuin perinteisillä OLTP-tietokannoilla tai uusilla NoSQL-tietokannoilla. Mutta he eivät tarvitse DBA:ta ja DevOpsia, ja ne toimivat hallitulla laitteistolla pilvissä. Kehittäjälle tämä on "vain tukikohta", joka toimii jossain, mutta ketään ei kiinnosta, kuinka se on asennettu palvelimelle, kuka on määrittänyt palvelimen ja kuka päivittää sen.
Esimerkkejä tällaisista tietokannoista:
- AWS RDS on PostgreSQL/MySQL:n hallittu kääre.
- DynamoDB on asiakirjapohjaisen tietokannan AWS-analogi, samanlainen kuin Redis ja MongoDB.
- Amazon Redshift on hallittu analyyttinen tietokanta.
Nämä ovat pohjimmiltaan vanhoja tietokantoja, mutta ne on luotu hallitussa ympäristössä ilman tarvetta työskennellä laitteiston kanssa.
Huomautus. Esimerkit on otettu AWS-ympäristöön, mutta niiden analogeja on myös Microsoft Azuressa, Google Cloudissa tai Yandex.Cloudissa.
Mitä uutta tässä on? Vuonna 2020 ei mikään näistä.
Palvelimeton konsepti
Mitä todella uutta markkinoilla vuonna 2020 on palvelimettomat tai palvelimettomat ratkaisut.
Yritän selittää, mitä tämä tarkoittaa tavallisen palvelun tai taustasovelluksen esimerkin avulla.
Tavallisen taustasovelluksen käyttöönottoa varten ostamme tai vuokraamme palvelimen, kopioimme koodin siihen, julkaisemme päätepisteen ulkopuolella ja maksamme säännöllisesti vuokrasta, sähköstä ja konesalin palveluista. Tämä on vakiomalli.
Onko muuta keinoa? Palvelimettomilla palveluilla voit.
Mikä on tämän lähestymistavan painopiste: palvelinta ei ole, pilvessä ei edes vuokrata virtuaalista ilmentymää. Ota palvelu käyttöön kopioimalla koodi (funktiot) arkistoon ja julkaisemalla se päätepisteeseen. Sitten vain maksamme jokaisesta tämän toiminnon kutsusta jättäen täysin huomiotta laitteiston, jossa se suoritetaan.
Yritän havainnollistaa tätä lähestymistapaa kuvilla.
Klassinen käyttöönotto. Meillä on palvelu tietyllä kuormituksella. Esittelemme kaksi ilmentymää: fyysiset palvelimet tai esiintymät AWS:ssä. Ulkoiset pyynnöt lähetetään näihin instansseihin ja käsitellään siellä.
Kuten kuvasta näkyy, palvelimia ei hävitetä tasapuolisesti. Toinen on 100-prosenttisesti käytetty, pyyntöjä on kaksi ja toinen vain 50-prosenttisesti - osittain käyttämättömänä. Jos ei tule kolme pyyntöä, vaan 30, koko järjestelmä ei pysty selviytymään kuormasta ja alkaa hidastua.
Palvelimeton käyttöönotto. Palvelimettomassa ympäristössä tällaisella palvelulla ei ole ilmentymiä tai palvelimia. On olemassa tietty joukko lämmitettyjä resursseja - pienet valmistetut Docker-kontit, joissa on käytössä toimintokoodi. Järjestelmä vastaanottaa ulkoisia pyyntöjä ja jokaiselle niistä palvelimeton kehys nostaa pienen kontin koodilla: se käsittelee tämän pyynnön ja tappaa kontin.
Yksi pyyntö - yksi kontti nostettu, 1000 pyyntöä - 1000 konttia. Ja käyttöönotto laitteistopalvelimilla on jo pilvipalveluntarjoajan työtä. Palvelimeton kehys piilottaa sen kokonaan. Tässä konseptissa maksamme jokaisesta puhelusta. Esimerkiksi yksi puhelu tuli päivässä - maksoimme yhdestä puhelusta, miljoona tuli minuutissa - maksoimme miljoonasta. Tai sekunnissa tämä myös tapahtuu.
Palvelittoman toiminnon julkaisemisen konsepti sopii tilattomaan palveluun. Ja jos tarvitset (state) statefull -palvelun, lisäämme palveluun tietokannan. Tässä tapauksessa, kun on kyse tilan kanssa työskentelystä, jokainen tila täynnä -toiminto yksinkertaisesti kirjoittaa ja lukee tietokannasta. Lisäksi tietokannasta mistä tahansa artikkelin alussa kuvatuista kolmesta tyypistä.
Mikä on kaikkien näiden tietokantojen yhteinen rajoitus? Nämä ovat jatkuvasti käytetyn pilvi- tai laitteistopalvelimen (tai useamman palvelimen) kustannuksia. Ei ole väliä, käytämmekö klassista vai hallittua tietokantaa, onko meillä Devopsia ja järjestelmänvalvojaa vai ei, maksamme silti laitteiston, sähkön ja datakeskuksen vuokrasta 24/7. Jos meillä on klassinen tukikohta, maksamme isännästä ja orjasta. Jos se on erittäin ladattu sirpaloitu tietokanta, maksamme 10, 20 tai 30 palvelimesta ja maksamme jatkuvasti.
Pysyvästi varattujen palvelimien läsnäolo kustannusrakenteessa nähtiin aiemmin välttämättömänä pahana. Perinteisillä tietokannoilla on myös muita hankaluuksia, kuten yhteyksien lukumäärän rajoitukset, skaalausrajoitukset, maantieteellisesti hajautettu konsensus - ne voidaan jotenkin ratkaista tietyissä tietokannoissa, mutta ei kaikkia kerralla eikä ihanteellisesti.
Palvelimeton tietokanta - teoria
Vuoden 2020 kysymys: onko mahdollista tehdä myös tietokanta palvelimettomaksi? Kaikki ovat kuulleet palvelimettomasta taustajärjestelmästä... yritetäänkö tehdä tietokannasta palvelimeton?
Tämä kuulostaa oudolta, koska tietokanta on tilan täyttävä palvelu, joka ei sovellu palvelimettomaan infrastruktuuriin. Samaan aikaan tietokannan tila on erittäin suuri: gigatavuja, teratavuja ja analyyttisissä tietokannoista jopa petatavuja. Se ei ole niin helppoa nostaa sitä kevyissä Docker-säiliöissä.
Toisaalta lähes kaikki nykyaikaiset tietokannat sisältävät valtavan määrän logiikkaa ja komponentteja: tapahtumia, eheyden koordinointia, menettelyjä, relaatioriippuvuuksia ja paljon logiikkaa. Melko suurelle tietokantalogiikalle pieni tila riittää. Gigatavuja ja teratavuja käyttää suoraan vain pieni osa tietokantalogiikasta, joka liittyy suoraan kyselyjen suorittamiseen.
Vastaavasti ajatus on: jos osa logiikasta sallii valtiottoman suorituksen, miksi ei jaeta perustaa tilallisiin ja valtiottomiin osiin.
Palvelimeton OLAP-ratkaisuille
Katsotaanpa, miltä tietokannan leikkaaminen Stateful- ja Stateless-osiin voisi näyttää käytännön esimerkkien avulla.
Meillä on esimerkiksi analyyttinen tietokanta: ulkoiset tiedot (punainen sylinteri vasemmalla), ETL-prosessi, joka lataa tiedot tietokantaan, ja analyytikko, joka lähettää SQL-kyselyitä tietokantaan. Tämä on klassinen tietovaraston toimintamalli.
Tässä järjestelmässä ETL suoritetaan ehdollisesti kerran. Sitten joudut jatkuvasti maksamaan palvelimista, joilla tietokanta toimii ETL:llä täytetyllä tiedolla, jotta kyselyitä olisi jonne lähettää.
Katsotaanpa vaihtoehtoista lähestymistapaa, joka on toteutettu AWS Athena Serverlessissä. Ei ole pysyvästi erillistä laitteistoa, johon ladatut tiedot tallennetaan. Tämän sijaan:
- Käyttäjä lähettää SQL-kyselyn Athenalle. Athena-optimoija analysoi SQL-kyselyn ja etsii metatietovarastosta (Metadata) kyselyn suorittamiseen tarvittavat tiedot.
- Optimoija lataa kerättyjen tietojen perusteella tarvittavat tiedot ulkoisista lähteistä väliaikaiseen tallennustilaan (väliaikainen tietokanta).
- Käyttäjän SQL-kysely suoritetaan väliaikaisessa muistissa ja tulos palautetaan käyttäjälle.
- Väliaikainen tallennus tyhjennetään ja resurssit vapautetaan.
Tässä arkkitehtuurissa maksamme vain pyynnön suoritusprosessista. Ei pyyntöjä - ei kuluja.
Tämä on toimiva lähestymistapa, ja sitä ei toteuteta vain Athena Serverlessissä, vaan myös Redshift Spectrumissa (AWS:ssä).
Athena-esimerkki osoittaa, että Serverless-tietokanta toimii todellisilla kyselyillä, joissa on kymmeniä ja satoja teratavuja dataa. Sadat teratavut vaativat satoja palvelimia, mutta meidän ei tarvitse maksaa niistä - me maksamme pyynnöt. Jokaisen pyynnön nopeus on (erittäin) alhainen verrattuna erikoistuneisiin analyyttisiin tietokantoihin, kuten Vertica, mutta emme maksa seisokkeista.
Tällainen tietokanta soveltuu harvinaisiin analyyttisiin ad-hoc-kyselyihin. Esimerkiksi, kun päätämme spontaanisti testata hypoteesin valtavalla datamäärällä. Athena on täydellinen näihin tapauksiin. Tavallisille pyynnöille tällainen järjestelmä on kallis. Tallenna tässä tapauksessa tiedot välimuistiin jossain erikoisratkaisussa.
Palvelimeton OLTP-ratkaisuille
Edellisessä esimerkissä tarkasteltiin OLAP (analyyttisiä) tehtäviä. Katsotaanpa nyt OLTP-tehtäviä.
Kuvitellaan skaalautuva PostgreSQL tai MySQL. Nostetaan tavallinen hallittu ilmentymä PostgreSQL tai MySQL minimaalisilla resursseilla. Kun ilmentymä saa enemmän kuormaa, yhdistämme lisäkopioita, joihin jaamme osan lukukuormasta. Jos pyyntöjä tai latausta ei ole, sammutamme kopiot. Ensimmäinen esiintymä on master, ja loput ovat kopioita.
Tämä idea on toteutettu tietokannassa nimeltä Aurora Serverless AWS. Periaate on yksinkertainen: välityspalvelin hyväksyy ulkoisten sovellusten pyynnöt. Nähdessään kuormituksen lisääntyvän se allokoi laskentaresursseja esilämmitetyistä minimaalitapauksista - yhteys muodostetaan mahdollisimman nopeasti. Tapahtumien poistaminen käytöstä tapahtuu samalla tavalla.
Aurorassa on käsite Aurora Capacity Unit, ACU. Tämä on (ehdollisesti) ilmentymä (palvelin). Jokainen tietty ACU voi olla isäntä tai orja. Jokaisella kapasiteettiyksiköllä on oma RAM-muisti, prosessori ja minilevy. Näin ollen yksi on päällikkö, loput ovat vain luku -kopioita.
Näiden käynnissä olevien Aurora-kapasiteettiyksiköiden lukumäärä on konfiguroitavissa oleva parametri. Vähimmäismäärä voi olla yksi tai nolla (tässä tapauksessa tietokanta ei toimi, jos pyyntöjä ei ole).
Kun tukiasema vastaanottaa pyyntöjä, välityspalvelinkanta nostaa Aurora CapacityUnits -yksikköjä, mikä lisää järjestelmän suorituskykyresursseja. Kyky lisätä ja vähentää resursseja mahdollistaa järjestelmän "jongleerata" resursseja: näyttää automaattisesti yksittäiset ACU:t (korvaa ne uusilla) ja ottaa käyttöön kaikki nykyiset päivitykset poistetuista resursseista.
Aurora Serverless -tukiasema voi skaalata lukukuormitusta. Mutta dokumentaatio ei kerro tätä suoraan. Saattaa tuntua, että he voivat nostaa multimasterin. Ei ole taikuutta.
Tämä tietokanta sopii hyvin välttämään valtavien rahasummien kuluttamista järjestelmiin, joihin pääsy on arvaamaton. Esimerkiksi luotaessamme MVP- tai markkinoimalla käyntikorttisivustoja emme yleensä odota vakaata kuormitusta. Näin ollen, jos pääsyä ei ole, emme maksa tapauksista. Kun odottamaton kuormitus tapahtuu, esimerkiksi konferenssin tai mainoskampanjan jälkeen, sivustolla vierailee väkijoukkoja ja kuormitus kasvaa dramaattisesti, Aurora Serverless ottaa tämän kuorman automaattisesti ja yhdistää nopeasti puuttuvat resurssit (ACU). Sitten konferenssi menee ohi, kaikki unohtavat prototyypin, palvelimet (ACU) pimenevät ja kustannukset putoavat nollaan - kätevää.
Tämä ratkaisu ei sovellu vakaalle suurelle kuormitukselle, koska se ei skaalaa kirjoituskuormaa. Kaikki nämä resurssien kytkennät ja katkaisut tapahtuvat niin sanotussa "skaalapisteessä" - ajankohtana, jolloin tietokanta ei tue tapahtumaa tai väliaikaisia taulukoita. Esimerkiksi viikon sisällä skaalauspiste ei välttämättä tapahdu, ja tukikohta toimii samoilla resursseilla eikä yksinkertaisesti voi laajentua tai supistua.
Ei ole taikuutta - se on tavallinen PostgreSQL. Mutta koneiden lisääminen ja irrottaminen on osittain automatisoitu.
Suunnittelultaan palvelinton
Aurora Serverless on vanha tietokanta, joka on kirjoitettu uudelleen pilveen hyödyntämään joitain Serverlessin etuja. Ja nyt kerron sinulle pohjasta, joka on alun perin kirjoitettu pilvelle, palvelimettomaan lähestymistapaan - Serverless-by-design. Se kehitettiin välittömästi ilman oletusta, että se toimisi fyysisillä palvelimilla.
Tätä pohjaa kutsutaan lumihiutaleeksi. Siinä on kolme avainlohkoa.
Ensimmäinen on metatietolohko. Tämä on nopea muistipalvelu, joka ratkaisee turvallisuuteen, metatietoihin, tapahtumiin ja kyselyn optimointiin liittyvät ongelmat (näkyy vasemmalla olevassa kuvassa).
Toinen lohko on joukko virtuaalisia laskentaklustereita laskelmia varten (kuvassa on joukko sinisiä ympyröitä).
Kolmas lohko on S3:een perustuva tiedontallennusjärjestelmä. S3 on dimensioton objektin tallennus AWS:ssä, tavallaan kuin dimensioton Dropbox yrityksille.
Katsotaan kuinka Snowflake toimii, olettaen, että se käynnistyy. Eli on olemassa tietokanta, tiedot ladataan siihen, käynnissä ei ole kyselyjä. Vastaavasti, jos tietokantaan ei ole pyyntöjä, olemme nostaneet nopean muistin Metadata-palvelun (ensimmäinen lohko). Ja meillä on S3-tallennustila, johon taulukkotiedot tallennetaan, jaettuna ns. mikroosioihin. Yksinkertaisuuden vuoksi: jos taulukko sisältää tapahtumia, mikroosiot ovat tapahtumapäiviä. Jokainen päivä on erillinen mikroosio, erillinen tiedosto. Ja kun tietokanta toimii tässä tilassa, maksat vain tietojen käyttämästä tilasta. Lisäksi hinta per istuin on erittäin alhainen (etenkin kun otetaan huomioon merkittävä puristus). Myös metatietopalvelu toimii jatkuvasti, mutta kyselyiden optimointiin ei tarvita paljoa resursseja ja palvelua voidaan pitää sharewarena.
Kuvitellaan nyt, että käyttäjä tuli tietokantaan ja lähetti SQL-kyselyn. SQL-kysely lähetetään välittömästi metatietopalveluun käsiteltäväksi. Vastaanotettuaan pyynnön tämä palvelu siis analysoi pyynnön, käytettävissä olevat tiedot, käyttöoikeudet ja, jos kaikki on kunnossa, laatii suunnitelman pyynnön käsittelystä.
Seuraavaksi palvelu käynnistää laskentaklusterin käynnistämisen. Laskentaklusteri on klusteri palvelimia, jotka suorittavat laskelmia. Tämä on siis klusteri, joka voi sisältää 1 palvelimen, 2 palvelinta, 4, 8, 16, 32 - niin monta kuin haluat. Lähetät pyynnön ja tämän klusterin käynnistäminen alkaa välittömästi. Se todella kestää sekunteja.
Seuraavaksi, kun klusteri on käynnistynyt, pyyntösi käsittelyyn tarvittavia mikroosioita aletaan kopioida klusteriin S3:sta. Eli kuvitellaan, että SQL-kyselyn suorittamiseen tarvitaan kaksi osiota yhdestä taulukosta ja yksi toisesta. Tässä tapauksessa vain kolme tarpeellista osiota kopioidaan klusteriin, ei kaikkia taulukoita kokonaan. Tästä syystä ja juuri siksi, että kaikki sijaitsee yhdessä datakeskuksessa ja yhdistetty erittäin nopeilla kanavilla, koko siirtoprosessi tapahtuu erittäin nopeasti: sekunneissa, erittäin harvoin minuuteissa, ellei puhuta hirviömäisistä pyynnöistä. Vastaavasti mikroosiot kopioidaan laskentaklusteriin, ja valmistuttuaan SQL-kysely suoritetaan tässä laskentaklusterissa. Tämän pyynnön tulos voi olla yksi rivi, useita rivejä tai taulukko - ne lähetetään ulkoisesti käyttäjälle, jotta hän voi ladata sen, näyttää sen BI-työkalussaan tai käyttää sitä jollain muulla tavalla.
Jokainen SQL-kysely ei voi vain lukea aggregaatteja aiemmin ladatusta tiedosta, vaan myös ladata/luoda uusia tietoja tietokantaan. Eli kyseessä voi olla kysely, joka esimerkiksi lisää uusia tietueita toiseen taulukkoon, mikä johtaa uuden osion ilmestymiseen laskentaklusteriin, joka puolestaan tallennetaan automaattisesti yhteen S3-muistiin.
Yllä kuvattu skenaario, käyttäjän saapumisesta klusterin nostamiseen, tiedon lataamiseen, kyselyjen suorittamiseen, tulosten saamiseen, maksetaan korotetun virtuaalisen laskentaklusterin, virtuaalisen varaston käyttöminuuteista. Hinta vaihtelee AWS-vyöhykkeen ja klusterin koon mukaan, mutta keskimäärin se on muutama dollari tunnissa. Neljän koneen klusteri on kaksi kertaa kalliimpi kuin kahden koneen klusteri, ja kahdeksan koneen klusteri on edelleen kaksi kertaa kalliimpi. Saatavilla on 16, 32 koneen vaihtoehtoja pyyntöjen monimutkaisuudesta riippuen. Mutta maksat vain niistä minuuteista, kun klusteri on todella käynnissä, koska kun pyyntöjä ei ole, otat kätesi pois ja 5-10 minuutin odotuksen jälkeen (konfiguroitava parametri) se sammuu itsestään, vapauttaa resursseja ja tulla vapaaksi.
Täysin realistinen skenaario on, että kun lähetät pyynnön, klusteri ponnahtaa esiin, suhteellisesti sanottuna, minuutissa, se laskee toisen minuutin, sitten viisi minuuttia sulkemiseen, ja joudut maksamaan tämän klusterin seitsemästä minuutista ja ei kuukausiin ja vuosiin.
Ensimmäinen skenaario kuvattiin käyttämällä Snowflakea yhden käyttäjän asetuksissa. Oletetaan nyt, että käyttäjiä on paljon, mikä on lähempänä todellista skenaariota.
Oletetaan, että meillä on paljon analyytikoita ja Tableau-raportteja, jotka jatkuvasti pommittavat tietokantaamme suurella määrällä yksinkertaisia analyyttisiä SQL-kyselyjä.
Oletetaan lisäksi, että meillä on kekseliäitä datatieteilijöitä, jotka yrittävät tehdä datalla hirviömäisiä asioita, operoida kymmenillä teratavuilla, analysoida miljardeja ja biljoonia rivejä dataa.
Lumihiutale mahdollistaa useiden eri kapasiteetin omaavien riippumattomien laskentaklustereiden nostamisen kahdelle yllä kuvatulle työkuormatyypille. Lisäksi nämä laskentaklusterit toimivat itsenäisesti, mutta yhteisillä yhdenmukaisilla tiedoilla.
Useita kevyitä kyselyitä varten voit nostaa 2-3 pientä klusteria, joissa kussakin on noin 2 konetta. Tämä käyttäytyminen voidaan toteuttaa muun muassa automaattisten asetusten avulla. Joten sanot: "Lumihiutale, nosta pieni klusteri. Jos sen kuormitus kasvaa tietyn parametrin yläpuolelle, nosta vastaava toinen, kolmas. Kun kuorma alkaa laantua, sammuta ylimääräinen." Joten riippumatta siitä, kuinka monta analyytikkoa tulee ja alkaa tarkastella raportteja, kaikilla on tarpeeksi resursseja.
Samanaikaisesti, jos analyytikot nukkuvat eikä kukaan katso raportteja, klusterit voivat pimentyä kokonaan ja lopetat niistä maksamisen.
Samaan aikaan (Data Scientists) raskaille kyselyille voit nostaa yhden erittäin suuren klusterin 32 koneelle. Tälle klusterille maksetaan myös vain niiltä minuuteilta ja tunneilta, jolloin jättimäinen pyyntösi on käynnissä.
Yllä kuvatun mahdollisuuden avulla voit jakaa paitsi 2, myös useamman tyyppisen työmäärän klusteriin (ETL, seuranta, raportin materialisointi,...).
Tehdään yhteenveto Lumihiutaleesta. Pohjassa yhdistyy kaunis idea ja toimiva toteutus. ManyChatissa käytämme Snowflakea kaiken datamme analysoimiseen. Meillä ei ole kolmea klusteria, kuten esimerkissä, vaan 5-9, erikokoisia. Meillä on tavanomaisia 16-koneisia, 2-koneisia ja myös superpieniä 1-koneisia joihinkin tehtäviin. Ne jakavat kuorman onnistuneesti ja antavat meille mahdollisuuden säästää paljon.
Tietokanta skaalaa luku- ja kirjoituskuorman onnistuneesti. Tämä on valtava ero ja valtava läpimurto verrattuna samaan "Auroraan", joka kantoi vain lukukuormaa. Snowflaken avulla voit skaalata kirjoitustyötäsi näiden laskentaklustereiden avulla. Eli, kuten mainitsin, käytämme ManyChatissa useita klustereita, pieniä ja superpieniä klustereita käytetään pääasiassa ETL:ään, tietojen lataamiseen. Ja analyytikot elävät jo keskisuurissa klustereissa, joihin ETL-kuorma ei todellakaan vaikuta, joten he työskentelevät erittäin nopeasti.
Näin ollen tietokanta soveltuu hyvin OLAP-tehtäviin. Valitettavasti se ei kuitenkaan vielä sovellu OLTP-työkuormille. Ensinnäkin tämä tietokanta on sarakemainen kaikkine seurauksineen. Toiseksi itse lähestymistapa, kun kullekin pyynnölle tarvittaessa nostat laskentaklusterin ja täytät sen datalla, ei valitettavasti ole vielä tarpeeksi nopea OLTP-latauksille. Sekuntien odottaminen OLAP-tehtävissä on normaalia, mutta OLTP-tehtävissä sitä ei voida hyväksyä; 100 ms olisi parempi tai 10 ms olisi vielä parempi.
Koko
Palvelimeton tietokanta on mahdollista jakamalla tietokanta Stateless- ja Stateful-osiin. Olet ehkä huomannut, että kaikissa yllä olevissa esimerkeissä Stateful-osa on suhteellisesti sanoen mikro-osioiden tallentamista S3:ssa, ja Stateless on optimoija, joka työskentelee metatietojen kanssa ja käsittelee tietoturvaongelmia, jotka voidaan nostaa esiin itsenäisinä kevyinä Stateless-palveluina.
SQL-kyselyjen suorittaminen voidaan myös nähdä kevyttilapalveluina, jotka voivat ponnahtaa esiin palvelimettomassa tilassa, kuten Snowflake-laskentaklusterit, ladata vain tarvittavat tiedot, suorittaa kyselyn ja "poistua".
Palvelimettomat tuotantotason tietokannat ovat jo käytössä, ne toimivat. Nämä palvelimettomat tietokannat ovat jo valmiita käsittelemään OLAP-tehtäviä. Valitettavasti niitä käytetään OLTP-tehtäviin... vivahtein, koska niillä on rajoituksia. Toisaalta tämä on miinus. Mutta toisaalta tämä on mahdollisuus. Ehkä joku lukijoista löytää tavan tehdä OLTP-tietokannasta täysin palvelimeton, ilman Auroran rajoituksia.
Toivottavasti se oli kiinnostava. Palvelimeton on tulevaisuus :)
Lähde: will.com