ProHoster > Blog > administratë > Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Përshëndetje, banorë të Khabrovsk. Mësimet në grupin e parë të kursit nisin sot "PostgreSQL". Në këtë drejtim, do të donim t'ju tregojmë se si u zhvillua webinari i hapur në këtë kurs.

Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

В mĂ«simi tjetĂ«r i hapur folĂ«m pĂ«r sfidat me tĂ« cilat pĂ«rballen bazat e tĂ« dhĂ«nave SQL nĂ« epokĂ«n e reve dhe Kubernetes. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, ne shikuam se si bazat e tĂ« dhĂ«nave SQL pĂ«rshtaten dhe ndryshojnĂ« nĂ«n ndikimin e kĂ«tyre sfidave.

U mbajt webinari Valery Bezrukov, Google Cloud Practice Delivery Manager në EPAM Systems.

Kur pemët ishin të vogla...

Së pari, le të kujtojmë se si filloi zgjedhja e DBMS në fund të shekullit të kaluar. Sidoqoftë, kjo nuk do të jetë e vështirë, sepse zgjedhja e një DBMS në ato ditë filloi dhe mbaroi Orakull.

Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Në fund të viteve '90 dhe në fillim të viteve 2, në thelb nuk kishte zgjidhje kur bëhet fjalë për bazat e të dhënave industriale të shkallëzueshme. Po, kishte IBM DBXNUMX, Sybase dhe disa baza të dhënash të tjera që vinin dhe shkuan, por në përgjithësi ato nuk ishin aq të dukshme në sfondin e Oracle. Prandaj, aftësitë e inxhinierëve të atyre kohërave ishin disi të lidhura me zgjedhjen e vetme që ekzistonte.

Oracle DBA duhej të ishte në gjendje të:

  • instaloni Oracle Server nga kompleti i shpĂ«rndarjes;
  • konfiguroni serverin Oracle:

  • init.ora;
  • dĂ«gjues.ora;

- krijoni:

  • hapĂ«sira tavoline;
  • skemat;
  • pĂ«rdoruesit;

— kryeni kopje rezervĂ« dhe rivendosni;
— tĂ« kryejĂ« monitorim;
— merreni me kĂ«rkesa jo optimale.

Në të njëjtën kohë, nuk kishte asnjë kërkesë të veçantë nga Oracle DBA:

  • tĂ« jetĂ« nĂ« gjendje tĂ« zgjedhĂ« DBMS optimale ose teknologji tjetĂ«r pĂ«r ruajtjen dhe pĂ«rpunimin e tĂ« dhĂ«nave;
  • tĂ« sigurojĂ« disponueshmĂ«ri tĂ« lartĂ« dhe shkallĂ«zim horizontal (kjo nuk ishte gjithmonĂ« njĂ« çështje DBA);
  • njohuri tĂ« mira tĂ« fushĂ«s lĂ«ndore, infrastrukturĂ«s, arkitekturĂ«s sĂ« aplikacioneve, OS;
  • ngarkoni dhe shkarkoni tĂ« dhĂ«nat, migroni tĂ« dhĂ«nat midis DBMS-ve tĂ« ndryshme.

Në përgjithësi, nëse flasim për zgjedhjen në ato ditë, ajo i ngjan zgjedhjes në një dyqan sovjetik në fund të viteve '80:

Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Koha jonë

Që atëherë, natyrisht, pemët janë rritur, bota ka ndryshuar dhe u bë diçka e tillë:

Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Tregu i DBMS gjithashtu ka ndryshuar, siç mund të shihet qartë nga raporti i fundit nga Gartner:

Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Dhe këtu duhet të theksohet se retë, popullariteti i të cilave po rritet, kanë zënë vendin e tyre. Nëse lexojmë të njëjtin raport Gartner, do të shohim përfundimet e mëposhtme:

  1. Shumë klientë janë në rrugën e lëvizjes së aplikacioneve në cloud.
  2. Teknologjitë e reja shfaqen fillimisht në cloud dhe nuk është fakt që ato do të kalojnë ndonjëherë në infrastrukturën jo-cloud.
  3. Modeli i çmimeve paga-as-you-go është bërë i zakonshëm. Të gjithë duan të paguajnë vetëm për atë që përdorin, dhe kjo nuk është as një trend, por thjesht një deklaratë fakti.

Po tani?

Sot jemi të gjithë në re. Dhe pyetjet që na lindin janë pyetje të zgjedhjes. Dhe është e madhe, edhe nëse flasim vetëm për zgjedhjen e teknologjive DBMS në formatin On-premises. Ne gjithashtu kemi menaxhuar shërbime dhe SaaS. Kështu, zgjedhja bëhet më e vështirë çdo vit.

Së bashku me pyetjet e zgjedhjes, ka edhe faktorët kufizues:

  • çmim. ShumĂ« teknologji ende kushtojnĂ« para;
  • aftĂ«sitĂ«. NĂ«se flasim pĂ«r softuer tĂ« lirĂ«, atĂ«herĂ« lind pyetja e aftĂ«sive, pasi softueri i lirĂ« kĂ«rkon kompetencĂ« tĂ« mjaftueshme nga njerĂ«zit qĂ« e vendosin dhe e pĂ«rdorin atĂ«;
  • funksionale. Jo tĂ« gjitha shĂ«rbimet qĂ« janĂ« tĂ« disponueshme nĂ« cloud dhe tĂ« ndĂ«rtuara, tĂ« themi, edhe nĂ« tĂ« njĂ«jtin Postgres, kanĂ« tĂ« njĂ«jtat veçori si Postgres On-premises. Ky Ă«shtĂ« njĂ« faktor thelbĂ«sor qĂ« duhet njohur dhe kuptuar. PĂ«r mĂ« tepĂ«r, ky faktor bĂ«het mĂ« i rĂ«ndĂ«sishĂ«m se njohja e disa aftĂ«sive tĂ« fshehura tĂ« njĂ« DBMS tĂ« vetme.

ÇfarĂ« pritet nga DA/DE tani:

  • tĂ« kuptuarit e mirĂ« tĂ« fushĂ«s sĂ« lĂ«ndĂ«s dhe arkitekturĂ«s sĂ« aplikimit;
  • aftĂ«sia pĂ«r tĂ« zgjedhur saktĂ« teknologjinĂ« e duhur DBMS, duke marrĂ« parasysh detyrĂ«n nĂ« fjalĂ«;
  • aftĂ«sia pĂ«r tĂ« zgjedhur metodĂ«n optimale pĂ«r zbatimin e teknologjisĂ« sĂ« zgjedhur nĂ« kontekstin e kufizimeve ekzistuese;
  • aftĂ«sia pĂ«r tĂ« kryer transferimin dhe migrimin e tĂ« dhĂ«nave;
  • aftĂ«sia pĂ«r tĂ« zbatuar dhe pĂ«rdorur zgjidhjet e zgjedhura.

Më poshtë shembull bazuar në GCP tregon se si funksionon zgjedhja e një ose një teknologjie tjetër për të punuar me të dhëna në varësi të strukturës së saj:

Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Ju lutemi vini re se PostgreSQL nuk është përfshirë në skemë dhe kjo për shkak se është e fshehur nën terminologjinë CloudSQL. Dhe kur të arrijmë në Cloud SQL, duhet të bëjmë një zgjedhje përsëri:

Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Duhet të theksohet se kjo zgjedhje nuk është gjithmonë e qartë, kështu që zhvilluesit e aplikacioneve shpesh udhëhiqen nga intuita.

Total:

  1. Sa më tej të shkoni, aq më urgjente bëhet çështja e zgjedhjes. Dhe edhe nëse shikoni vetëm GCP, shërbimet e menaxhuara dhe SaaS, atëherë disa përmendje të RDBMS shfaqen vetëm në hapin e 4-të (dhe aty afër është Spanner). Plus, zgjedhja e PostgreSQL shfaqet në hapin e 5-të, dhe pranë tij ka edhe MySQL dhe SQL Server, d.m.th. ka shumë nga të gjitha, por ju duhet të zgjidhni.
  2. Nuk duhet të harrojmë kufizimet në sfondin e tundimeve. Në thelb të gjithë duan një çelës, por është i shtrenjtë. Si rezultat, një kërkesë tipike duket diçka si kjo: "Ju lutemi na bëni një çelës, por për çmimin e Cloud SQL, ju jeni profesionistë!"

Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Cfare duhet te bejme?

Pa pretenduar se jemi e vërteta përfundimtare, le të themi sa vijon:

Ne duhet të ndryshojmë qasjen tonë ndaj të mësuarit:

  • nuk ka asnjĂ« kuptim tĂ« mĂ«sosh mĂ«nyrĂ«n se si mĂ«soheshin DBA-tĂ« mĂ« parĂ«;
  • njohja e njĂ« produkti nuk Ă«shtĂ« mĂ« e mjaftueshme;
  • por tĂ« njohĂ«sh dhjetĂ«ra nĂ« nivelin e njĂ« Ă«shtĂ« e pamundur.

Ju duhet të dini jo vetëm dhe jo sa është produkti, por:

  • rasti i pĂ«rdorimit tĂ« aplikimit tĂ« tij;
  • metoda tĂ« ndryshme tĂ« vendosjes;
  • avantazhet dhe disavantazhet e secilĂ«s metodĂ«;
  • produkte tĂ« ngjashme dhe alternative pĂ«r tĂ« bĂ«rĂ« njĂ« zgjedhje tĂ« informuar dhe optimale dhe jo gjithmonĂ« nĂ« favor tĂ« njĂ« produkti tĂ« njohur.

Ju gjithashtu duhet të jeni në gjendje të migroni të dhëna dhe të kuptoni parimet bazë të integrimit me ETL.

Rast real

Në të kaluarën e afërt, ishte e nevojshme të krijohej një backend për një aplikacion celular. Në kohën kur filloi puna për të, backend ishte zhvilluar tashmë dhe ishte gati për zbatim, dhe ekipi i zhvillimit kaloi rreth dy vjet në këtë projekt. U vendosën detyrat e mëposhtme:

  • ndĂ«rtoni CI/CD;
  • rishikoni arkitekturĂ«n;
  • vĂ«nĂ« tĂ« gjitha nĂ« funksion.

Vetë aplikacioni ishte mikroshërbime, dhe kodi Python/Django u zhvillua nga e para dhe drejtpërdrejt në GCP. Sa i përket audiencës së synuar, supozohej se do të kishte dy rajone - SHBA dhe BE, dhe trafiku shpërndahej përmes balancuesit të ngarkesës globale. Të gjitha ngarkesat e punës dhe llogaritja e ngarkesës së punës u ekzekutuan në Google Kubernetes Engine.

Sa i përket të dhënave, kishte 3 struktura:

  • Ruajtja nĂ« renĂ« kompjuterike;
  • Dyqani i tĂ« dhĂ«nave;
  • Cloud SQL (PostgreSQL).

Si të mbijetoni një bazë të dhënash SQL në shekullin 21: retë, Kubernetes dhe PostgreSQL multimaster

Dikush mund të pyesë veten pse u zgjodh Cloud SQL? Për të thënë të vërtetën, një pyetje e tillë ka shkaktuar një lloj pauze të sikletshme vitet e fundit - ekziston një ndjenjë që njerëzit janë bërë të trembur për bazat e të dhënave relacionale, por megjithatë ata vazhdojnë t'i përdorin ato në mënyrë aktive ;-).

Sa për rastin tonë, Cloud SQL u zgjodh për arsyet e mëposhtme:

  1. Siç u përmend, aplikacioni u zhvillua duke përdorur Django dhe ka një model për hartëzimin e të dhënave të vazhdueshme nga një bazë të dhënash SQL në objektet Python (Django ORM).
  2. Vetë korniza mbështeti një listë mjaft të kufizuar të DBMS-ve:

  • PostgreSQL;
  • MariaDB;
  • MySQL;
  • Orakulli;
  • SQLite.

Prandaj, PostgreSQL u zgjodh nga kjo listë mjaft intuitive (epo, nuk është Oracle për të zgjedhur, me të vërtetë).

ÇfarĂ« mungonte:

  • aplikacioni u vendos vetĂ«m nĂ« 2 rajone, dhe njĂ« i tretĂ« u shfaq nĂ« plane (Azi);
  • Baza e tĂ« dhĂ«nave ndodhej nĂ« rajonin e AmerikĂ«s sĂ« Veriut (Iowa);
  • nga ana e klientit kishte shqetĂ«sime pĂ«r tĂ« mundshme vonesat e aksesit nga Evropa dhe Azia dhe ndĂ«rprerjet ne sherbim nĂ« rast tĂ« ndĂ«rprerjes sĂ« DBMS.

Përkundër faktit se vetë Django mund të punojë me disa baza të dhënash paralelisht dhe t'i ndajë ato në lexim dhe shkrim, nuk kishte aq shumë shkrime në aplikacion (më shumë se 90% po lexojnë). Dhe në përgjithësi, dhe në përgjithësi, nëse do të ishte e mundur të bëhej lexoni-kopje e bazës kryesore në Evropë dhe Azi, kjo do të ishte një zgjidhje kompromisi. Epo, çfarë ka kaq të komplikuar?

Vështirësia ishte se klienti nuk donte të hiqte dorë nga përdorimi i shërbimeve të menaxhuara dhe Cloud SQL. Dhe aftësitë e Cloud SQL janë aktualisht të kufizuara. Cloud SQL mbështet disponueshmërinë e lartë (HA) dhe Read Replica (RR), por e njëjta RR mbështetet vetëm në një rajon. Pasi të keni krijuar një bazë të dhënash në rajonin amerikan, nuk mund të bëni një kopje leximi në rajonin evropian duke përdorur Cloud SQL, megjithëse vetë Postgres nuk ju pengon ta bëni këtë. Korrespondenca me punonjësit e Google nuk çoi askund dhe përfundoi me premtime në stilin e "ne e dimë problemin dhe po punojmë për të, një ditë çështja do të zgjidhet".

Nëse rendisim shkurtimisht aftësitë e Cloud SQL, do të duket diçka si kjo:

1. Disponueshmëri e lartë (HA):

  • brenda njĂ« rajoni;
  • nĂ«pĂ«rmjet replikimit tĂ« diskut;
  • MotorĂ«t PostgreSQL nuk pĂ«rdoren;
  • kontrolli automatik dhe manual i mundshĂ«m - failover/failback;
  • Kur ndĂ«rroni, DBMS nuk Ă«shtĂ« i disponueshĂ«m pĂ«r disa minuta.

2. Lexoni kopjen (RR):

  • brenda njĂ« rajoni;
  • gatishmĂ«ri e nxehtĂ«;
  • Replikimi i transmetimit tĂ« PostgreSQL.

Përveç kësaj, siç është zakon, kur zgjidhni një teknologji, gjithmonë përballeni me disa kufizimet:

  • klienti nuk donte tĂ« krijonte entitete dhe tĂ« pĂ«rdorte IaaS, pĂ«rveçse nĂ«pĂ«rmjet GKE;
  • klienti nuk do tĂ« donte tĂ« vendoste vetĂ« shĂ«rbimin PostgreSQL/MySQL;
  • Epo, nĂ« pĂ«rgjithĂ«si, Google Spanner do tĂ« ishte mjaft i pĂ«rshtatshĂ«m nĂ«se nuk do tĂ« ishte pĂ«r çmimin e tij, megjithatĂ«, Django ORM nuk mund tĂ« punojĂ« me tĂ«, por Ă«shtĂ« njĂ« gjĂ« e mirĂ«.

Duke marrë parasysh situatën, klienti mori një pyetje vijuese: "A mund të bëni diçka të ngjashme që të jetë si Google Spanner, por edhe të funksionojë me Django ORM?"

Opsioni i zgjidhjes nr. 0

Gjëja e parë që më erdhi në mendje:

  • qĂ«ndroni brenda CloudSQL;
  • nuk do tĂ« ketĂ« pĂ«rsĂ«ritje tĂ« integruar midis rajoneve nĂ« asnjĂ« formĂ«;
  • pĂ«rpiquni tĂ« bashkĂ«ngjitni njĂ« kopje nĂ« njĂ« Cloud SQL ekzistuese nga PostgreSQL;
  • nisni njĂ« shembull PostgreSQL diku dhe disi, por tĂ« paktĂ«n mos e prekni masterin.

Mjerisht, doli që kjo nuk mund të bëhet, sepse nuk ka qasje në host (është në një projekt krejt tjetër) - pg_hba dhe kështu me radhë, dhe gjithashtu nuk ka qasje nën superpërdorues.

Opsioni i zgjidhjes nr. 1

Pas reflektimit të mëtejshëm dhe duke marrë parasysh rrethanat e mëparshme, treni i mendimit ndryshoi disi:

  • Ne ende po pĂ«rpiqemi tĂ« qĂ«ndrojmĂ« brenda CloudSQL, por po kalojmĂ« nĂ« MySQL, sepse Cloud SQL nga MySQL ka njĂ« master tĂ« jashtĂ«m, i cili:

— Ă«shtĂ« njĂ« pĂ«rfaqĂ«sues pĂ«r MySQL tĂ« jashtĂ«m;
- duket si një shembull MySQL;
- shpikur për migrimin e të dhënave nga retë e tjera ose në mjedise.

Meqenëse konfigurimi i riprodhimit të MySQL nuk kërkon qasje në host, në parim gjithçka funksionoi, por ishte shumë e paqëndrueshme dhe e papërshtatshme. Dhe kur shkuam më tej, u bë krejtësisht e frikshme, sepse vendosëm të gjithë strukturën me terraform, dhe befas doli që mjeshtri i jashtëm nuk mbështetej nga terraformi. Po, Google ka një CLI, por për disa arsye gjithçka funksiononte këtu herë pas here - ndonjëherë krijohet, ndonjëherë nuk krijohet. Ndoshta sepse CLI u shpik për migrimin e të dhënave të jashtme, dhe jo për kopje.

Në fakt, në këtë pikë u bë e qartë se Cloud SQL nuk është aspak i përshtatshëm. Siç thonë ata, ne bëmë gjithçka që mundëm.

Opsioni i zgjidhjes nr. 2

Meqenëse nuk ishte e mundur të qëndronim brenda kornizës së Cloud SQL, ne u përpoqëm të formulonim kërkesat për një zgjidhje kompromisi. Kërkesat rezultuan të jenë si më poshtë:

  • puna nĂ« Kubernetes, pĂ«rdorimi maksimal i burimeve dhe aftĂ«sive tĂ« Kubernetes (DCS, ...) dhe GCP (LB, ...);
  • mungesa e çakĂ«llit nga njĂ« mori gjĂ«rash tĂ« panevojshme nĂ« re si pĂ«rfaqĂ«suesi HA;
  • aftĂ«sia pĂ«r tĂ« ekzekutuar PostgreSQL ose MySQL nĂ« rajonin kryesor HA; nĂ« rajone tĂ« tjera - HA nga RR e rajonit kryesor plus kopjen e tij (pĂ«r besueshmĂ«ri);
  • multi master (nuk doja tĂ« kontaktoja me tĂ«, por nuk ishte shumĂ« e rĂ«ndĂ«sishme)

.
Si rezultat i këtyre kërkesave, pDBMS të përshtatshme dhe opsione të detyrueshme:

  • MySQL Galera;
  • BuburreciDB;
  • Mjetet PostgreSQL

:
- pgpool-II;
- Patroni.

MySQL Galera

Teknologjia MySQL Galera u zhvillua nga Codership dhe është një shtojcë për InnoDB. Veçoritë:

  • multi master;
  • replikimi sinkron;
  • lexim nga çdo nyje;
  • regjistrim nĂ« çdo nyje;
  • mekanizĂ«m i integruar HA;
  • Ekziston njĂ« tabelĂ« Helm nga Bitnami.

BuburreciDB

Sipas përshkrimit, gjëja është absolutisht bombë dhe është një projekt me kod të hapur i shkruar në Go. Pjesëmarrësi kryesor është Cockroach Labs (themeluar nga njerëz nga Google). Kjo DBMS relacionale fillimisht u krijua për t'u shpërndarë (me shkallëzim horizontal jashtë kutisë) dhe tolerante ndaj gabimeve. Autorët e saj nga kompania përshkruan qëllimin e "kombinimit të pasurisë së funksionalitetit SQL me aksesin horizontal të njohur për zgjidhjet NoSQL".

Një bonus i mirë është mbështetja për protokollin e lidhjes post-gress.

Pgpool

Kjo është një shtesë e PostgreSQL, në fakt, një entitet i ri që merr përsipër të gjitha lidhjet dhe i përpunon ato. Ka balancuesin dhe analizuesin e vet të ngarkesës, të licencuar sipas licencës BSD. Ajo ofron mundësi të bollshme, por duket disi e frikshme, sepse prania e një entiteti të ri mund të bëhet burimi i disa aventurave shtesë.

Patroni

Kjo është gjëja e fundit në të cilën më ranë sytë dhe, siç doli, jo më kot. Patroni është një mjet me burim të hapur, i cili në thelb është një demon i Python që ju lejon të ruani automatikisht grupimet PostgreSQL me lloje të ndryshme të replikimit dhe ndërrimin automatik të roleve. Gjëja doli të ishte shumë interesante, pasi integrohet mirë me kuberin dhe nuk prezanton asnjë entitet të ri.

ÇfarĂ« zgjodhĂ«t nĂ« fund?

Zgjedhja nuk ishte e lehtë:

  1. BuburreciDB - zjarr, por i errët;
  2. MySQL Galera - gjithashtu jo keq, përdoret në shumë vende, por MySQL;
  3. Pgpool — shumĂ« entitete tĂ« panevojshme, pra integrim me cloud dhe K8;
  4. Patroni - Integrim i shkëlqyer me K8, pa entitete të panevojshme, integrohet mirë me GCP LB.

KĂ«shtu, zgjedhja ra mbi Patroni.

Gjetjet

ËshtĂ« koha pĂ«r tĂ« pĂ«rmbledhur shkurt. Po, bota e infrastrukturĂ«s IT ka ndryshuar ndjeshĂ«m dhe ky Ă«shtĂ« vetĂ«m fillimi. Dhe nĂ«se mĂ« parĂ« retĂ« ishin thjesht njĂ« lloj tjetĂ«r infrastrukture, tani gjithçka Ă«shtĂ« ndryshe. PĂ«r mĂ« tepĂ«r, risitĂ« nĂ« re po shfaqen vazhdimisht, ato do tĂ« shfaqen dhe, ndoshta, do tĂ« shfaqen vetĂ«m nĂ« re dhe vetĂ«m atĂ«herĂ«, me pĂ«rpjekjet e startup-eve, do tĂ« transferohen nĂ« On-premises.

Sa për SQL, SQL do të jetojë. Kjo do të thotë që ju duhet të njihni PostgreSQL dhe MySQL dhe të jeni në gjendje të punoni me to, por edhe më e rëndësishme është të jeni në gjendje t'i përdorni ato në mënyrë korrekte.

Burimi: www.habr.com

Bleni njĂ« host tĂ« besueshĂ«m pĂ«r faqet me mbrojtje DDoS, serverĂ« VPS VDS đŸ”„ Bleni hosting tĂ« besueshĂ«m tĂ« faqeve tĂ« internetit me mbrojtje DDoS, servera VPS VDS | ProHoster