Kaixo, Khabrovskeko bizilagunak. Gaur hasiko dira kurtsoko lehen taldeko klaseak . Ildo horretatik, ikastaro honen webinar irekia nola egin den kontatu nahi dizuegu.
Π SQL datu-baseek hodeien eta Kubernetesen garaian dituzten erronkei buruz hitz egin dugu. Aldi berean, erronka horien eraginez SQL datu-baseak nola egokitzen eta nola aldatzen diren aztertu genuen.
Webinarra egin zen , EPAM Systems-en Google Cloud Practice Delivery Manager.
Zuhaitzak txikiak zirenean...
Lehenik eta behin, gogora dezagun nola hasi zen DBMS aukeratzen joan den mendearen amaieran. Hala ere, hau ez da zaila izango, egun haietan DBMS baten aukeraketa hasi eta amaitu baitzen Oracle.
90eko hamarkadaren amaieran eta 2. hamarkadaren hasieran, funtsean, ez zegoen aukerarik datu-base industrial eskalagarriei dagokienez. Bai, bazeuden IBM DBXNUMX, Sybase eta beste datu-base batzuk etorri eta joan zirenak, baina orokorrean ez ziren hain nabariak Oracleren atzealdean. Horren arabera, garai haietako ingeniarien gaitasunak zegoen aukera bakarrari lotuta zeuden nolabait.
Oracle DBA gai izan behar zen:
- instalatu Oracle Server banaketa-kit batetik;
- konfiguratu Oracle zerbitzaria:
- init.ora;
- entzule.ora;
- Sortu:
- tablespaces;
- eskema;
- erabiltzaileak;
- babeskopia egin eta leheneratu;
β jarraipena egitea;
β Eskaere hoberenak ez direnei aurre egin.
Aldi berean, ez zegoen Oracle DBA-ren baldintza berezirik:
- datuak gordetzeko eta prozesatzeko DBMS edo beste teknologiarik egokiena aukeratzeko gai izan;
- erabilgarritasun handia eta eskalagarritasun horizontala eskaintzea (hau ez zen beti DBA arazo bat izan);
- gai-arloa, azpiegitura, aplikazio-arkitektura, OS ondo ezagutzea;
- kargatu eta deskargatu datuak, migratu datuak DBMS ezberdinen artean.
Oro har, garai haietako aukerari buruz hitz egiten badugu, 80ko hamarkadaren amaierako sobietar denda batean egindako aukeraren antza du:
Gure garaia
Harrezkero, noski, zuhaitzak hazi dira, mundua aldatu da, eta honelako zerbait bihurtu da:
DBMS merkatua ere aldatu egin da, Gartner-en azken txostenean argi ikusten denez:
Eta hemen kontuan izan behar da hodeiek, haien ospea gero eta handiagoa den, beren nitxoa okupatu dutela. Gartner txosten bera irakurtzen badugu, ondorio hauek ikusiko ditugu:
- Bezero asko aplikazioak hodeira eramateko bidean daude.
- Teknologia berriak lehen aldiz hodeian agertzen dira eta ez da inoiz hodeiko azpiegituretara pasako direnik.
- Ordaindu ahala prezioen eredua ohiko bihurtu da. Bakoitzak erabiltzen duenagatik bakarrik ordaindu nahi du, eta hau ez da joera bat ere, egiazko adierazpena baizik.
Orain zer?
Gaur denok hodeian gaude. Eta sortzen zaizkigun galderak aukerako galderak dira. Eta izugarria da, nahiz eta On-premises formatuan DBMS teknologien aukeraketaz bakarrik hitz egiten. Kudeatutako zerbitzuak eta SaaS ere baditugu. Beraz, aukeraketa urtero zailagoa da.
Aukerako galderekin batera, badaude faktore mugatzaileak:
- prezioa. Teknologia askok oraindik dirua balio dute;
- trebetasunak. Software libreaz ari bagara, orduan trebetasunen auzia sortzen da, software libreak behar adinako konpetentzia eskatzen baitu hura zabaldu eta funtzionatzen duten pertsonengandik;
- funtzionala. Hodeian eskuragarri dauden eta, esate baterako, Postgres berean eraikitako zerbitzu guztiek ez dituzte Postgres On-premises-en ezaugarri berdinak. Hori ezagutu eta ulertu beharreko funtsezko faktorea da. Gainera, faktore hau DBMS bakar baten ezkutuko gaitasun batzuen ezagutza baino garrantzitsuagoa da.
Zer espero da DA/DEtik orain:
- gai-arloa eta aplikazio-arkitektura ondo ulertzea;
- DBMS teknologia egokia behar bezala hautatzeko gaitasuna, eskuartean duzun zeregina kontuan hartuta;
- aukeratutako teknologia inplementatzeko metodo egokiena aukeratzeko gaitasuna dauden mugen testuinguruan;
- datuen transferentzia eta migrazioa egiteko gaitasuna;
- aukeratutako irtenbideak ezartzeko eta erabiltzeko gaitasuna.
Beheko adibidea GCPn oinarrituta Datuekin lan egiteko teknologia bat edo beste aukeratzeak bere egituraren arabera nola funtzionatzen duen erakusten du:
Kontuan izan PostgreSQL ez dagoela eskeman sartzen, eta hori terminologiaren azpian ezkutatuta dagoelako da Cloud SQL. Eta Cloud SQLra iristen garenean, berriro aukeraketa bat egin behar dugu:
Kontuan izan behar da aukera hau ez dela beti argia, beraz, aplikazioen garatzaileak intuizioaz gidatzen dira askotan.
Guztira:
- Zenbat eta urrunago joan, orduan eta larriagoa da aukeraren galdera. Eta GCPri, kudeatutako zerbitzuei eta SaaSri bakarrik begiratu arren, RDBMSren aipamen batzuk 4. urratsean bakarrik agertzen dira (eta han Spanner gertu dago). Gainera, PostgreSQL aukeraketa 5. urratsean agertzen da, eta ondoan MySQL eta SQL Server ere badaude, hau da. denetarik asko dago, baina aukeratu egin behar da.
- Ez ditugu ahaztu behar tentaldien atzealdean dauden murrizketak. Funtsean, denek nahi dute Spanner bat, baina garestia da. Ondorioz, eskaera tipiko batek honelako itxura du: "Mesedez, egin iezaguzu Spanner, baina Cloud SQL-ren prezioagatik, profesionalak zarete!"
Zer egin beharko nuke?
Azken egia dela esan gabe, esan dezagun honako hau:
Ikaskuntzaren ikuspegia aldatu behar dugu:
- ez du balio lehen DBAk irakasten ziren moduan irakastea;
- produktu baten ezagutza jada ez da nahikoa;
- baina dozenaka bat mailan jakitea ezinezkoa da.
Produktua zenbat den ez ezik, jakin behar duzu:
- bere aplikazioaren erabilera kasua;
- hedapen-metodo desberdinak;
- metodo bakoitzaren abantailak eta desabantailak;
- antzeko produktuak eta alternatiboak aukera informatua eta optimoa egiteko eta ez beti produktu ezagun baten alde.
Gainera, datuak migratzeko eta ETL-rekin integratzeko oinarrizko printzipioak ulertu behar dituzu.
Benetako kasua
Iraganean, mugikorretarako aplikazio baterako backend bat sortzea beharrezkoa zen. Lanak hasi zirenerako, backend-a jada garatuta zegoen eta ezartzeko prest zegoen, eta garapen-taldeak bi urte inguru eman zituen proiektu honetan. Eginkizun hauek ezarri ziren:
- CI/CD eraiki;
- arkitektura berrikusi;
- dena martxan jarri.
Aplikazioa bera mikrozerbitzuak ziren, eta Python/Django kodea hutsetik eta zuzenean GCPn garatu zen. Xede-publikoari dagokionez, bi eskualde egongo zirela suposatu zen: AEB eta EB, eta trafikoa Global Load balancer bidez banatu zen. Lan-karga eta konputazio-lan guztiak Google Kubernetes Engine-n exekutatu ziren.
Datuei dagokienez, 3 egitura zeuden:
- Hodeiko biltegiratzea;
- Datu biltegia;
- Cloud SQL (PostgreSQL).
Norbaitek galde lezake zergatik aukeratu zen Cloud SQL? Egia esateko, halako galdera batek nolabaiteko etenaldi deserosoa eragin du azken urteotan - jendea harreman-datu-baseekin lotsatu egin dela sentsazioa dago, baina hala ere aktiboki erabiltzen jarraitzen duela ;-).
Gure kasuan bezala, Cloud SQL aukeratu zen arrazoi hauengatik:
- Esan bezala, aplikazioa Django erabiliz garatu da, eta SQL datu-base batetik Python objektuetara (Django ORM) datu iraunkorrak mapatzeko eredu bat du.
- Esparruak berak DBMSen zerrenda nahiko mugatua onartzen zuen:
- PostgreSQL;
- MariaDB;
- MySQL;
- Orakulua;
- SQLite.
Horren arabera, PostgreSQL zerrenda honetatik nahiko intuitiboki aukeratu zen (beno, ez da Oracle aukeratzea, benetan).
Zer falta zen:
- aplikazioa 2 eskualdetan bakarrik zabaldu zen, eta 3. bat agertu zen planoetan (Asia);
- Datu-basea Ipar Amerikako eskualdean (Iowa) kokatu zen;
- bezeroaren aldetik egon daitezkeen kezkak zeuden sarbide-atzerapenak Europatik eta Asiatik eta etenaldiak zerbitzuan DBMS geldialdiaren kasuan.
Djangok berak paraleloan hainbat datu-baserekin lan egin eta irakurketa eta idazketan banatu ditzakeen arren, aplikazioan ez zegoen hainbeste idazketa (%90 baino gehiago irakurtzen ari da). Eta orokorrean, eta orokorrean, egin ahal izango balitz Europa eta Asiako oinarri nagusiaren irakur-erreplika, hau konpromiso-konponbidea izango litzateke. Tira, zer da hain konplikatua?
Zailtasuna zen bezeroak ez zuela utzi nahi kudeatutako zerbitzuak eta Cloud SQL erabiltzeari. Eta Cloud SQL-ren gaitasunak mugatuak dira gaur egun. Cloud SQL-k erabilgarritasun handia (HA) eta irakurketa erreplika (RR) onartzen ditu, baina RR bera eskualde batean bakarrik onartzen da. Amerikako eskualdean datu-base bat sortuta, ezin duzu irakurri erreplika bat egin Europako eskualdean Cloud SQL erabiliz, nahiz eta Postgresek berak ez dizu hori egitea eragozten. Google-ko langileekin egindako korrespondentziak ez zuen inora eraman eta "arazoa ezagutzen dugu eta lanean ari gara, noizbait arazoa konponduko da".
Cloud SQL-ren gaitasunak labur-labur zerrendatzen baditugu, itxura hau izango du:
1. Eskuragarritasun handia (HA):
- eskualde baten barruan;
- diskoaren erreplikazioaren bidez;
- PostgreSQL motorrak ez dira erabiltzen;
- kontrol automatikoa eta eskuz posiblea - failover/failback;
- Aldatzean, DBMS ez dago erabilgarri minutu batzuetan.
2. Irakurri Erreplika (RR):
- eskualde baten barruan;
- egonean beroa;
- PostgreSQL streaming erreplikazioa.
Gainera, ohikoa den bezala, teknologia bat aukeratzerakoan beti aurkitzen zara batzuen aurrean murrizketak:
- bezeroak ez zuen nahi entitateak sortu eta IaaS erabili, GKEren bidez izan ezik;
- bezeroak ez luke autozerbitzua PostgreSQL/MySQL zabaldu nahi;
- Beno, oro har, Google Spanner nahiko egokia izango litzateke bere prezioagatik ez balitz, hala ere, Django ORM-ek ezin du berarekin funtzionatu, baina gauza ona da.
Egoera kontuan hartuta, bezeroak galdera bat jaso zuen: "Antzeko zerbait egin al dezakezu Google Spanner bezalakoa izan dadin, baina Django ORM-ekin ere funtzionatzen du?"
0 zenbakiko irtenbide aukera
Burura etorri zitzaidan lehenengo gauza:
- CloudSQL barruan egon;
- ez da inola ere eskualdeen arteko erreplika integraturik egongo;
- saiatu PostgreSQL-ek lehendik dagoen Cloud SQL bati erreplika bat eransten;
- abiarazi PostgreSQL instantzia bat nonbait eta nolabait, baina ez ukitu masterra behintzat.
Ala ere, hori ezin da egin, ez dagoelako ostalarirako sarbiderik (guztiz beste proiektu batean dago) - pg_hba eta abar, eta ez dago supererabiltzailean sarbiderik ere.
1 zenbakiko irtenbide aukera
Hausnarketa gehiago egin ondoren eta aurreko zirkunstantziak kontuan hartuta, pentsamoldea zertxobait aldatu zen:
- CloudSQL-en barruan jarraitzen saiatzen ari gara, baina MySQLra aldatzen ari gara, Cloud SQL by MySQL-k kanpoko maisu bat duelako, hau da:
β kanpoko MySQLrako proxy bat da;
- MySQL instantzia baten itxura du;
- Beste hodei batzuetatik edo tokiko datuak migratzeko asmatua.
MySQL erreplikazioa ezartzeak ostalarirako sarbidea behar ez duenez, printzipioz dena funtzionatu zuen, baina oso ezegonkorra eta deserosoa zen. Eta urrunago joan ginenean, guztiz beldurgarria bihurtu zen, egitura osoa terraformarekin zabaldu genuelako, eta bat-batean kanpoaldeko maisua ez zegoela terraformekin eusten. Bai, Google-k CLI bat dauka, baina arrazoiren batengatik dena hemen funtzionatu zuen noizean behin; batzuetan sortu egiten da, beste batzuetan ez da sortu. Agian CLIa kanpoko datuen migraziorako asmatu zelako, eta ez errepliketarako.
Egia esan, momentu honetan argi geratu zen Cloud SQL ez dela batere egokia. Esaten dutenez, ahal genuen guztia egin genuen.
2 zenbakiko irtenbide aukera
Cloud SQL esparruan egon ezin zenez, konpromezurako irtenbide baterako eskakizunak ezartzen saiatu ginen. Baldintzak honako hauek izan ziren:
- Kubernetesen lan egitea, Kubernetesen (DCS, ...) eta GCP (LB, ...) baliabide eta gaitasunen erabilera maximoa;
- HA proxy bezalako hodeian beharrezkoak ez diren gauza mordo baten balasto falta;
- HA eskualde nagusian PostgreSQL edo MySQL exekutatzeko gaitasuna; beste eskualde batzuetan - HA eskualde nagusiko RRtik gehi bere kopia (fidagarritasunagatik);
- multi master (ez nuen berarekin harremanetan jarri nahi, baina ez zen oso garrantzitsua)
.
Eskakizun horien ondorioz, orDBMS eta lotesle aukera egokiak:
- MySQL Galera;
- LabezomorroDB;
- PostgreSQL tresnak
:
- pgpool-II;
β Patroni.
MySQL Galera
MySQL Galera teknologia Codership-ek garatu zuen eta InnoDBrako plugina da. Berezitasunak:
- multi master;
- erreplikazio sinkronikoa;
- edozein nodotik irakurtzea;
- edozein nodotara grabatzea;
- HA mekanismo integratua;
- Bitnami-ren Helm diagrama bat dago.
LabezomorroaDB
Deskribapenaren arabera, gauza guztiz bonba da eta Go-n idatzitako kode irekiko proiektua da. Partaide nagusia Cockroach Labs da (Google-ko jendeak sortua). Erlazional DBMS hau jatorriz banatua izateko diseinatu zen (eskala horizontalarekin kutxatik kanpo) eta akatsekiko tolerantziarekin. Konpainiako egileek "SQL funtzionalitatearen aberastasuna NoSQL soluzioek ezagutzen duten irisgarritasun horizontalarekin konbinatzeko" helburua zehaztu zuten.
Hobari polita da post-gress konexio protokoloaren laguntza.
Pgpool
Hau PostgreSQL-ren gehigarri bat da, hain zuzen ere, konexio guztiak hartzen eta prozesatzen dituen entitate berri bat. Bere karga-orekatzailea eta analizatzailea ditu, BSD lizentziapean. Aukera ugari eskaintzen ditu, baina itxura beldurgarria ematen du, entitate berri baten presentzia abentura gehigarri batzuen iturri bihur daitekeelako.
Patroni
Hau da nire begiak erori zitzaizkidan azken gauza, eta, ondorioz, ez alferrik. Patroni kode irekiko erabilgarritasun bat da, funtsean Python daemon bat da, eta PostgreSQL klusterrak automatikoki mantentzea ahalbidetzen du hainbat motatako erreplika eta rol-aldaketa automatikoarekin. Gauza oso interesgarria izan da, kuberarekin ondo integratzen baita eta ez baitu entitate berririk sartzen.
Zer aukeratu zenuen azkenean?
Aukeratzea ez zen erraza izan:
- LabezomorroaDB - sua, baina iluna;
- MySQL Galera - gainera ez da txarra, leku askotan erabiltzen da, baina MySQL;
- Pgpool β alferrikako entitate asko, hodeiarekin eta K8ekin integratzea;
- Patroni - K8s-ekin integrazio bikaina, alferrikako entitaterik gabe, ondo integratzen da GCP LB-rekin.
Hala, Patroniren esku geratu zen aukera.
Findings
Labur laburtzeko garaia da. Bai, IT azpiegituren mundua nabarmen aldatu da, eta hau hasiera besterik ez da. Eta lehen hodeiak beste azpiegitura mota bat besterik ez baziren, orain dena ezberdina da. Gainera, hodeietan berrikuntzak etengabe agertzen dira, agertuko dira eta, beharbada, hodeietan bakarrik agertuko dira eta orduan bakarrik, startupen ahaleginez, On-premisera eramango dira.
SQLri dagokionez, SQL biziko da. Horrek esan nahi du PostgreSQL eta MySQL ezagutu eta haiekin lan egin behar duzula, baina are garrantzitsuagoa da horiek behar bezala erabili ahal izatea.
Iturria: www.habr.com