Hei, Habrovskin asukkaat. Kurssin ensimmäisen ryhmän tunnit alkavat tänään . Tässä yhteydessä haluaisimme kertoa teille, kuinka tämän kurssin avoin webinaari sujui.
В puhuimme haasteista, joita SQL-tietokannat kohtaavat pilvien ja Kubernetesin aikakaudella. Samalla tarkastelimme, kuinka SQL-tietokannat mukautuvat ja muuntuvat näiden haasteiden vaikutuksesta.
Webinaari pidettiin , Google Cloud Practice Delivery Manager, EPAM Systems.
Kun puut olivat pieniä...
Aluksi muistetaan kuinka DBMS:n valinta alkoi viime vuosisadan lopulla. Tämä ei kuitenkaan ole vaikeaa, koska DBMS-järjestelmän valinta niinä päivinä alkoi ja päättyi oraakkeli.
90-luvun lopulla ja 2-luvun alussa teollisesti skaalautuvien tietokantojen suhteen ei käytännössä ollut valinnanvaraa. Kyllä, IBM DBXNUMX, Sybase ja joitain muita tietokantoja tuli ja meni, mutta yleensä ne eivät olleet niin havaittavissa Oraclen taustalla. Niinpä noiden aikojen insinöörien taidot oli jotenkin sidottu ainoaan olemassa olevaan valintaan.
Oracle DBA:n oli kyettävä:
- asenna Oracle Server jakelusarjasta;
- määritä Oracle Server:
- init.ora;
- listener.ora;
- luo:
- pöytätilat;
- järjestelmästä;
- käyttäjät;
— Suorita varmuuskopiointi ja palautus;
— suorittaa seurantaa;
— käsittelemään epäoptimaalisia pyyntöjä.
Samaan aikaan Oracle DBA:lta ei ollut erityisiä vaatimuksia:
- osaa valita optimaalinen DBMS tai muu tekniikka tietojen tallentamiseen ja käsittelyyn;
- tarjoavat korkean käytettävyyden ja horisontaalisen skaalautuvuuden (tämä ei aina ollut DBA-ongelma);
- hyvä aihealueen, infrastruktuurin, sovellusarkkitehtuurin, käyttöjärjestelmän tuntemus;
- ladata ja purkaa tietoja, siirtää tietoja eri DBMS-järjestelmien välillä.
Yleensä, jos puhumme valinnasta niinä päivinä, se muistuttaa valintaa Neuvostoliiton myymälässä 80-luvun lopulla:
Meidän aikamme
Siitä lähtien puut ovat tietysti kasvaneet, maailma on muuttunut ja siitä on tullut jotain tällaista:
Myös DBMS-markkinat ovat muuttuneet, kuten Gartnerin uusimmasta raportista käy selvästi ilmi:
Ja tässä on huomattava, että pilvet, joiden suosio kasvaa, ovat valloittaneet markkinaraon. Jos luemme saman Gartnerin raportin, näemme seuraavat johtopäätökset:
- Monet asiakkaat ovat siirtämässä sovelluksia pilveen.
- Uudet teknologiat ilmestyvät ensin pilvessä, eikä ole tosiasia, että ne koskaan siirtyisivät ei-pilviinfrastruktuuriin.
- Jako-jako-hinnoittelumallista on tullut arkipäivää. Jokainen haluaa maksaa vain käyttämästään, eikä tämä ole edes trendi, vaan pelkkä toteamus.
Mitä nyt?
Tänään olemme kaikki pilvessä. Ja meille heräävät kysymykset ovat valintakysymyksiä. Ja se on valtava, vaikka puhumme vain DBMS-tekniikoiden valinnasta On-premises-muodossa. Meillä on myös hallinnoidut palvelut ja SaaS. Näin ollen valinta vaikeutuu vuosi vuodelta.
Valintakysymysten ohella on myös rajoittavia tekijöitä:
- hinta. Monet tekniikat maksavat edelleen rahaa;
- taitoja. Jos puhumme vapaista ohjelmistoista, nousee esiin kysymys taidoista, koska vapaat ohjelmistot edellyttävät riittävää osaamista niitä käyttöön ottavilta ja käyttäjiltä;
- toimiva. Kaikki palvelut, jotka ovat saatavilla pilvessä ja rakennettu vaikkapa samalle Postgresille, eivät sisällä samoja ominaisuuksia kuin Postgres On-premises. Tämä on olennainen tekijä, joka on tiedettävä ja ymmärrettävä. Lisäksi tämä tekijä tulee tärkeämmäksi kuin tieto yksittäisen DBMS:n piilotetuista ominaisuuksista.
Mitä DA/DE:ltä odotetaan nyt:
- hyvä oppiainealueen ja sovellusarkkitehtuurin tuntemus;
- kyky valita oikein sopiva DBMS-tekniikka ottaen huomioon käsillä oleva tehtävä;
- kyky valita optimaalinen menetelmä valitun tekniikan toteuttamiseksi olemassa olevien rajoitusten yhteydessä;
- kyky suorittaa tiedonsiirtoa ja siirtoa;
- kyky toteuttaa ja käyttää valittuja ratkaisuja.
Alla esimerkki perustuu GCP:hen osoittaa, kuinka yhden tai toisen tekniikan valinta tietojen kanssa työskentelemiseen toimii sen rakenteesta riippuen:
Huomaa, että PostgreSQL ei sisälly skeemaan, koska se on piilotettu terminologian alle Pilvinen SQL. Ja kun pääsemme Cloud SQL:ään, meidän on tehtävä valinta uudelleen:
On huomattava, että tämä valinta ei ole aina selvä, joten sovelluskehittäjiä ohjaa usein intuitio.
Yhteensä:
- Mitä pidemmälle mennään, sitä painavammaksi valintakysymys tulee. Ja vaikka katsoisit vain GCP:tä, hallittuja palveluita ja SaaS-palvelua, RDBMS-järjestelmä näkyy vain neljännessä vaiheessa (ja siellä on Spanner lähellä). Lisäksi valinta PostgreSQL ilmestyy 4. vaiheeseen ja sen vieressä ovat myös MySQL ja SQL Server, eli kaikkea on paljon, mutta sinun on valittava.
- Emme saa unohtaa rajoituksia kiusausten taustalla. Periaatteessa kaikki haluavat avaimen, mutta se on kallis. Tämän seurauksena tyypillinen pyyntö näyttää suunnilleen tältä: "Tee meistä jakoavain, mutta Cloud SQL:n hinnalla olette ammattilaisia!"
Mutta mitä tehdä?
Väittämättä olevansa lopullinen totuus, sanotaan seuraavaa:
Meidän on muutettava lähestymistapaamme oppimiseen:
- ei ole mitään järkeä opettaa samalla tavalla kuin DBA:ta opetettiin aiemmin;
- yhden tuotteen tuntemus ei enää riitä;
- mutta kymmenien tunteminen yhden tasolla on mahdotonta.
Sinun ei tarvitse tietää vain tuotteen hintaa, vaan myös:
- sen sovelluksen käyttötapaus;
- erilaisia käyttöönottomenetelmiä;
- kunkin menetelmän edut ja haitat;
- samankaltaisia ja vaihtoehtoisia tuotteita tehdäkseen tietoisen ja optimaalisen valinnan eikä aina tutun tuotteen hyväksi.
Sinun on myös pystyttävä siirtämään tietoja ja ymmärtämään ETL:n integroinnin perusperiaatteet.
todellinen tapaus
Viime aikoina mobiilisovellukselle oli tarpeen luoda taustajärjestelmä. Kun työskentely aloitettiin, taustaohjelma oli jo kehitetty ja valmis käyttöönotettavaksi, ja kehitystiimi käytti projektin parissa noin kaksi vuotta. Seuraavat tehtävät asetettiin:
- rakentaa CI/CD;
- tarkista arkkitehtuuri;
- laita se kaikki käyttöön.
Itse sovellus oli mikropalveluita, ja Python/Django-koodi kehitettiin tyhjästä suoraan GCP:ssä. Kohdeyleisön osalta oletettiin, että alueita olisi kaksi - USA ja EU, ja liikenne jaettiin Global Load Balancerin kautta. Kaikki työmäärät ja laskentatyökuormitus suoritettiin Google Kubernetes Enginessä.
Mitä tulee dataan, rakenteita oli kolme:
- pilvitallennus;
- Tietovarasto;
- Cloud SQL (PostgreSQL).
Voidaan ihmetellä, miksi Cloud SQL valittiin? Totta puhuen tällainen kysymys on aiheuttanut jonkinlaisen kiusallisen tauon viime vuosina - tuntuu, että ihmisistä on tullut ujoja relaatiotietokantojen suhteen, mutta silti he jatkavat niiden aktiivista käyttöä ;-).
Meidän tapauksessamme Cloud SQL valittiin seuraavista syistä:
- Kuten mainittiin, sovellus on kehitetty käyttämällä Djangoa, ja siinä on malli pysyvien tietojen kartoittamiseksi SQL-tietokannasta Python-objekteihin (Django ORM).
- Kehys itsessään tuki melko rajallista luetteloa DBMS:istä:
- PostgreSQL;
- MariaDB;
- MySQL;
- Oraakkeli;
- SQLite.
Vastaavasti PostgreSQL valittiin tästä luettelosta melko intuitiivisesti (no, Oracle ei todellakaan voi valita).
Mitä puuttui:
- sovellus otettiin käyttöön vain kahdella alueella, ja kolmas ilmestyi suunnitelmiin (Aasia);
- Tietokanta sijaitsi Pohjois-Amerikan alueella (Iowa);
- asiakas oli huolissaan mahdollisesta pääsyviiveet Euroopasta ja Aasiasta ja keskeytyksiä palveluksessa DBMS-seisokkien tapauksessa.
Huolimatta siitä, että Django itse voi työskennellä useiden tietokantojen kanssa rinnakkain ja jakaa ne lukemiseen ja kirjoittamiseen, sovelluksessa ei ollut niin paljon kirjoittamista (yli 90% lukemista). Ja yleensä, ja yleensä, jos se oli mahdollista luku-kopio päätukikohdasta Euroopassa ja Aasiassa, tämä olisi kompromissiratkaisu. No mikä siinä on niin monimutkaista?
Vaikeutena oli, että asiakas ei halunnut luopua hallittujen palveluiden ja Cloud SQL:n käytöstä. Ja Cloud SQL:n ominaisuudet ovat tällä hetkellä rajalliset. Cloud SQL tukee korkeaa käytettävyyttä (HA) ja Read Replicaa (RR), mutta samaa RR:tä tuetaan vain yhdellä alueella. Kun olet luonut tietokannan Amerikan alueelle, et voi tehdä lukukopiota Euroopan alueella Cloud SQL:n avulla, vaikka Postgres itse ei estä sinua tekemästä tätä. Kirjeenvaihto Googlen työntekijöiden kanssa ei johtanut mihinkään ja päättyi lupauksiin tyyliin "tiedämme ongelman ja työskentelemme sen parissa, joskus ongelma ratkaistaan".
Jos luettelemme Cloud SQL:n ominaisuudet lyhyesti, se näyttää suunnilleen tältä:
1. Korkea saatavuus (HA):
- yhden alueen sisällä;
- levyn replikoinnin kautta;
- PostgreSQL-koneita ei käytetä;
- automaattinen ja manuaalinen ohjaus mahdollista - vikasieto/palautus;
- Kun vaihdat, DBMS ei ole käytettävissä useaan minuuttiin.
2. Lue replika (RR):
- yhden alueen sisällä;
- kuuma valmiustila;
- PostgreSQL-suoratoiston replikointi.
Lisäksi, kuten on tapana, tekniikkaa valittaessa kohtaat aina joitain rajoituksia:
- asiakas ei halunnut luoda kokonaisuuksia ja käyttää IaaS:ää muuten kuin GKE:n kautta;
- asiakas ei halua ottaa käyttöön itsepalvelua PostgreSQL/MySQL;
- No, yleisesti ottaen Google Spanner olisi varsin sopiva, jos se ei olisi hinnaltaan, Django ORM ei kuitenkaan voi toimia sen kanssa, mutta se on hyvä asia.
Tilanne huomioon ottaen asiakas sai jatkokysymyksen: "Voitko tehdä jotain vastaavaa niin, että se on kuin Google Spanner, mutta toimii myös Django ORM:n kanssa?"
Ratkaisuvaihtoehto nro 0
Ensimmäinen asia mikä tuli mieleen:
- pysyä CloudSQL:ssä;
- alueiden välillä ei ole sisäänrakennettua replikointia missään muodossa;
- yritä liittää replika olemassa olevaan Cloud SQL:ään PostgreSQL:llä;
- käynnistä PostgreSQL-ilmentymä jonnekin ja jollain tavalla, mutta älä ainakaan koske masteriin.
Valitettavasti kävi ilmi, että tätä ei voi tehdä, koska isäntään ei ole pääsyä (se on kokonaan eri projektissa) - pg_hba ja niin edelleen, eikä myöskään pääsyä superkäyttäjän alla.
Ratkaisuvaihtoehto nro 1
Lisäharkinnan jälkeen ja aiemmat olosuhteet huomioon ottaen ajatuskulku muuttui jonkin verran:
- Pyrimme edelleen pysymään CloudSQL:n sisällä, mutta siirrymme MySQL:ään, koska Cloud SQL by MySQL:llä on ulkoinen isäntä, joka:
— on välityspalvelin ulkoiselle MySQL:lle;
- näyttää MySQL-instanssilta;
- keksitty tietojen siirtämiseen muista pilvistä tai paikan päällä.
Koska MySQL-replikaation määrittäminen ei vaadi pääsyä isäntään, periaatteessa kaikki toimi, mutta se oli erittäin epävakaa ja hankala. Ja kun menimme pidemmälle, siitä tuli täysin pelottavaa, koska otimme koko rakenteen käyttöön terraformilla, ja yhtäkkiä kävi ilmi, että ulkoinen isäntä ei tukeutunut terraformilla. Kyllä, Googlella on CLI, mutta jostain syystä kaikki toimi täällä silloin tällöin - joskus se luodaan, joskus ei. Ehkä siksi, että CLI keksittiin ulkoista tiedonsiirtoa varten, ei replikoita varten.
Itse asiassa tässä vaiheessa kävi selväksi, että Cloud SQL ei sovellu ollenkaan. Kuten he sanovat, teimme kaikkemme.
Ratkaisuvaihtoehto nro 2
Koska Cloud SQL -kehyksen sisällä ei ollut mahdollista pysyä, yritimme muotoilla vaatimuksia kompromissiratkaisulle. Vaatimukset osoittautuivat seuraavanlaisiksi:
- työ Kubernetesissa, Kubernetesin (DCS, ...) ja GCP:n (LB, ...) resurssien ja ominaisuuksien maksimaalinen käyttö;
- painolastin puute joukosta tarpeettomia asioita pilvessä, kuten HA-välityspalvelin;
- kyky suorittaa PostgreSQL- tai MySQL-tietokanta pääasiallisella HA-alueella; muilla alueilla - HA pääalueen RR:stä plus sen kopio (luotettavuuden vuoksi);
- multi master (en halunnut ottaa häneen yhteyttä, mutta se ei ollut kovin tärkeää)
.
Näiden vaatimusten seurauksena ssopivat DBMS- ja sidontavaihtoehdot:
- MySQL Galera;
- torakkaDB;
- PostgreSQL-työkalut
:
- pgpool-II;
– Patroni.
MySQL Galera
MySQL Galera -teknologian on kehittänyt Codership, ja se on InnoDB:n laajennus. Ominaisuudet:
- multi master;
- synkroninen replikointi;
- lukeminen mistä tahansa solmusta;
- tallennus mihin tahansa solmuun;
- sisäänrakennettu HA-mekanismi;
- Bitnamilta löytyy ruorikaavio.
TorakkaDB
Kuvauksen mukaan asia on täysin pommi ja Go:lla kirjoitettu avoimen lähdekoodin projekti. Pääosallistuja on Cockroach Labs (Googlen ihmisten perustama). Tämä relaatiotietokantajärjestelmä oli alun perin suunniteltu hajautetuksi (vaakasuuntaisella skaalauksella) ja vikasietoiseksi. Sen kirjoittajat yrityksestä määrittelivät tavoitteen "yhdistää SQL-toimintojen rikkaus NoSQL-ratkaisuille tuttuihin horisontaalisiin saavutettavuuteen".
Mukava bonus on tuki post-gress-yhteysprotokollalle.
Pgpool
Tämä on PostgreSQL:n lisäosa, itse asiassa uusi kokonaisuus, joka ottaa haltuunsa kaikki yhteydet ja käsittelee ne. Sillä on oma BSD-lisenssillä lisensoitu kuormantasaaja ja jäsentäjä. Se tarjoaa runsaasti mahdollisuuksia, mutta näyttää hieman pelottavalta, koska uuden kokonaisuuden läsnäolo voi olla joidenkin lisäseikkailujen lähde.
Patroni
Tämä on viimeinen asia, johon silmäni osuivat, ja kuten kävi ilmi, ei turhaan. Patroni on avoimen lähdekoodin apuohjelma, joka on pohjimmiltaan Python-daemon, jonka avulla voit ylläpitää automaattisesti PostgreSQL-klustereita erilaisilla replikaatioilla ja automaattisella roolinvaihdolla. Asia osoittautui erittäin mielenkiintoiseksi, koska se integroituu hyvin cuberiin eikä tuo esille uusia kokonaisuuksia.
Mitä valitsit lopulta?
Valinta ei ollut helppo:
- TorakkaDB - tuli, mutta tumma;
- MySQL Galera - ei myöskään huono, sitä käytetään monissa paikoissa, mutta MySQL;
- Pgpool — paljon tarpeettomia kokonaisuuksia, niin integrointi pilveen ja K8:aan;
- Patroni - Erinomainen integrointi K8s:ien kanssa, ei tarpeettomia kokonaisuuksia, integroituu hyvin GCP LB:hen.
Näin ollen valinta osui Patronille.
Tulokset
On aika tehdä lyhyt yhteenveto. Kyllä, IT-infrastruktuurin maailma on muuttunut merkittävästi, ja tämä on vasta alkua. Ja jos ennen pilvet olivat vain toisenlainen infrastruktuuri, nyt kaikki on toisin. Lisäksi pilvissä olevia innovaatioita ilmaantuu jatkuvasti, niitä tulee ja kenties ne ilmestyvät vain pilviin ja vasta sitten ne siirtyvät startup-yritysten ponnisteluilla On-premisesiin.
Mitä tulee SQL:ään, SQL elää. Tämä tarkoittaa, että sinun tulee tuntea PostgreSQL ja MySQL ja osata työskennellä niiden kanssa, mutta vielä tärkeämpää on osata käyttää niitä oikein.
Lähde: will.com