Hallo, Khabrovsk inwoners. Klasse in die eerste groep van die kursus begin vandag . In hierdie verband wil ons jou graag vertel hoe die oop webinar oor hierdie kursus plaasgevind het.
В ons het gepraat oor die uitdagings wat SQL-databasisse in die gesig staar in die era van wolke en Kubernetes. Terselfdertyd het ons gekyk na hoe SQL-databasisse aanpas en muteer onder die invloed van hierdie uitdagings.
Die webinar is gehou , Google Cloud Practice Delivery Manager by EPAM Systems.
Toe die bome klein was...
Eerstens, laat ons onthou hoe die keuse van DBMS aan die einde van die vorige eeu begin het. Dit sal egter nie moeilik wees nie, want die keuse van 'n DBBS in daardie dae het begin en geëindig Oracle.
In die laat 90's en vroeë 2's was daar in wese geen keuse wanneer dit kom by industriële skaalbare databasisse nie. Ja, daar was IBM DBXNUMX, Sybase en 'n paar ander databasisse wat gekom en gegaan het, maar oor die algemeen was hulle nie so opvallend teen die agtergrond van Oracle nie. Gevolglik was die vaardighede van daardie tye se ingenieurs op een of ander manier gekoppel aan die enigste keuse wat bestaan het.
Oracle DBA moes in staat wees om:
- installeer Oracle Server vanaf die verspreidingskit;
- konfigureer Oracle Server:
- init.ora;
- luisteraar.ora;
- skep:
- tafelspasies;
- skemas;
- gebruikers;
- voer rugsteun uit en herstel;
— monitering uit te voer;
- hanteer suboptimale versoeke.
Terselfdertyd was daar geen spesiale vereiste van Oracle DBA nie:
- die optimale DBBS of ander tegnologie vir die stoor en verwerking van data te kan kies;
- voorsien hoë beskikbaarheid en horisontale skaalbaarheid (dit was nie altyd 'n DBA-kwessie nie);
- goeie kennis van die vakgebied, infrastruktuur, toepassingsargitektuur, bedryfstelsel;
- laai en los data, migreer data tussen verskillende DBBS'e.
Oor die algemeen, as ons oor die keuse in daardie dae praat, lyk dit soos die keuse in 'n Sowjetwinkel in die laat 80's:
Ons tyd
Sedertdien het die bome natuurlik gegroei, die wêreld het verander, en dit het so iets geword:
Die DBMS-mark het ook verander, soos duidelik gesien kan word uit die jongste verslag van Gartner:
En hier moet daarop gelet word dat wolke, wie se gewildheid toeneem, hul nis beset het. As ons dieselfde Gartner-verslag lees, sal ons die volgende gevolgtrekkings sien:
- Baie kliënte is op pad om toepassings na die wolk te skuif.
- Nuwe tegnologieë verskyn eers in die wolk en dit is nie 'n feit dat hulle ooit na nie-wolk-infrastruktuur sal beweeg nie.
- Die betaal-soos-jy-gaan-prysmodel het alledaags geword. Almal wil net betaal vir wat hulle gebruik, en dit is nie eers 'n neiging nie, maar bloot 'n feitestelling.
Wat nou?
Vandag is ons almal in die wolk. En die vrae wat vir ons opkom, is vrae van keuse. En dit is groot, selfs al praat ons net oor die keuse van DBMS-tegnologieë in die formaat op die perseel. Ons het ook bestuurde dienste en SaaS. Die keuse word dus elke jaar net moeiliker.
Saam met vrae van keuse, is daar ook beperkende faktore:
- die prys. Baie tegnologie kos steeds geld;
- vaardighede. As ons van vrye sagteware praat, dan ontstaan die vraag na vaardighede, aangesien vrye sagteware voldoende bevoegdheid vereis van die mense wat dit ontplooi en bedryf;
- funksioneel. Nie alle dienste wat in die wolk beskikbaar is en, byvoorbeeld, selfs op dieselfde Postgres gebou is, het dieselfde kenmerke as Postgres On-premises nie. Dit is 'n noodsaaklike faktor wat geken en verstaan moet word. Boonop word hierdie faktor belangriker as kennis van sommige verborge vermoëns van 'n enkele DBBS.
Wat word nou van DA/DE verwag:
- goeie begrip van die vakgebied en toepassingsargitektuur;
- die vermoë om die toepaslike DBMS-tegnologie korrek te kies met inagneming van die taak op hande;
- die vermoë om die optimale metode te kies vir die implementering van die geselekteerde tegnologie in die konteks van bestaande beperkings;
- vermoë om data-oordrag en -migrasie uit te voer;
- vermoë om geselekteerde oplossings te implementeer en te bedryf.
Voorbeeld hieronder gebaseer op GCP demonstreer hoe die keuse van een of ander tegnologie vir werk met data werk, afhangende van die struktuur daarvan:
Neem asseblief kennis dat PostgreSQL nie by die skema ingesluit is nie, en dit is omdat dit onder die terminologie versteek is Wolk SQL. En wanneer ons by Cloud SQL kom, moet ons weer 'n keuse maak:
Daar moet kennis geneem word dat hierdie keuse nie altyd duidelik is nie, daarom word toepassingsontwikkelaars dikwels deur intuïsie gelei.
Totaal:
- Hoe verder jy gaan, hoe meer druk word die kwessie van keuse. En selfs al kyk jy net na GCP, bestuurde dienste en SaaS, dan verskyn 'n paar melding van RDBMS slegs by die 4de stap (en daar is Spanner naby). Boonop verskyn die keuse van PostgreSQL in die 5de stap, en langsaan is daar ook MySQL en SQL Server, dit is daar is baie van alles, maar jy moet kies.
- Ons moet nie vergeet van beperkings teen die agtergrond van versoekings nie. Basies wil almal 'n Spanner hê, maar dit is duur. Gevolglik lyk 'n tipiese versoek iets soos volg: "Maak ons asseblief 'n sleutel, maar vir die prys van Cloud SQL is julle professionele mense!"
Wat moet ons doen?
Sonder om te beweer dat dit die uiteindelike waarheid is, kom ons sê die volgende:
Ons moet ons benadering tot leer verander:
- daar is geen sin om te onderrig soos voorheen DBA's onderrig is nie;
- kennis van een produk is nie meer genoeg nie;
- maar om dosyne op die vlak van een te ken is onmoontlik.
Jy moet nie net weet en nie hoeveel die produk is nie, maar:
- gebruik geval van die toepassing daarvan;
- verskillende ontplooiingsmetodes;
- voor- en nadele van elke metode;
- soortgelyke en alternatiewe produkte om 'n ingeligte en optimale keuse te maak en nie altyd ten gunste van 'n bekende produk nie.
Jy moet ook in staat wees om data te migreer en die basiese beginsels van integrasie met ETL te verstaan.
Werklike geval
In die onlangse verlede was dit nodig om 'n backend vir 'n mobiele toepassing te skep. Teen die tyd dat werk daaraan begin het, was die backend reeds ontwikkel en gereed vir implementering, en die ontwikkelingspan het ongeveer twee jaar aan hierdie projek bestee. Die volgende take is opgestel:
- bou CI/CD;
- hersien die argitektuur;
- dit alles in werking stel.
Die toepassing self was mikrodienste, en die Python/Django-kode is van nuuts af en direk in GCP ontwikkel. Wat die teikengehoor betref, is aanvaar dat daar twee streke sou wees - VSA en EU, en verkeer is deur die Global Load balancer versprei. Alle werkladings en berekende werklading het op Google Kubernetes Engine gehardloop.
Wat die data betref, was daar 3 strukture:
- Wolkberging;
- Datastoor;
- Wolk SQL (PostgreSQL).
Mens kan wonder hoekom Cloud SQL gekies is? Om die waarheid te sê, so 'n vraag het die afgelope paar jaar 'n soort ongemaklike pouse veroorsaak - daar is 'n gevoel dat mense skaam geraak het vir relasionele databasisse, maar nietemin gaan hulle voort om dit aktief te gebruik ;-).
Wat ons geval betref, is Cloud SQL om die volgende redes gekies:
- Soos genoem, is die toepassing ontwikkel met behulp van Django, en dit het 'n model vir die kartering van aanhoudende data vanaf 'n SQL-databasis na Python-voorwerpe (Django ORM).
- Die raamwerk self het 'n redelik beperkte lys van DBBS'e ondersteun:
- PostgreSQL;
- MariaDB;
- MySQL;
- orakels;
- SQLite.
Gevolglik is PostgreSQL eerder intuïtief uit hierdie lys gekies (wel, dit is eintlik nie Oracle om te kies nie).
Wat ontbreek het:
- die toepassing is slegs in 2 streke ontplooi, en 'n 3de een het in planne verskyn (Asië);
- Die databasis was geleë in die Noord-Amerikaanse streek (Iowa);
- aan die kant van die kliënt was daar kommer oor moontlike toegangsvertragings uit Europa en Asië en onderbrekings in diens in die geval van DBMS-stilstand.
Ten spyte van die feit dat Django self met verskeie databasisse parallel kan werk en dit in lees en skryf kan verdeel, was daar nie soveel skryfwerk in die toepassing nie (meer as 90% is lees). En in die algemeen, en in die algemeen, as dit moontlik was om te doen lees-replika van die hoofbasis in Europa en Asië, sal dit 'n kompromie-oplossing wees. Wel, wat is so ingewikkeld daaraan?
Die probleem was dat die kliënt nie wou opgee om bestuurde dienste en Cloud SQL te gebruik nie. En die vermoëns van Cloud SQL is tans beperk. Wolk SQL ondersteun Hoë beskikbaarheid (HA) en Lees Replica (RR), maar dieselfde RR word slegs in een streek ondersteun. Nadat u 'n databasis in die Amerikaanse streek geskep het, kan u nie 'n leesreplika in die Europese streek maak deur Cloud SQL te gebruik nie, alhoewel Postgres self u nie verhinder om dit te doen nie. Korrespondensie met Google-werknemers het nêrens gelei nie en het geëindig met beloftes in die styl van "ons ken die probleem en werk daaraan, eendag sal die probleem opgelos word."
As ons die vermoëns van Cloud SQL kortliks lys, sal dit iets soos volg lyk:
1. Hoë beskikbaarheid (HA):
- binne een streek;
- via skyfreplikasie;
- PostgreSQL-enjins word nie gebruik nie;
- outomatiese en handmatige beheer moontlik - failover/failback;
- Wanneer oorgeskakel word, is die DBBS vir 'n paar minute nie beskikbaar nie.
2. Lees Replika (RR):
- binne een streek;
- warm bystand;
- PostgreSQL stroom replikasie.
Daarbenewens, soos gebruiklik, wanneer jy 'n tegnologie kies, word jy altyd met sommige gekonfronteer beperkings:
- die kliënt wou nie entiteite skep en IaaS gebruik nie, behalwe deur GKE;
- die kliënt wil nie selfdiens PostgreSQL/MySQL ontplooi nie;
- Wel, oor die algemeen sou Google Spanner baie geskik wees as dit nie vir sy prys was nie, maar Django ORM kan nie daarmee werk nie, maar dit is 'n goeie ding.
Met inagneming van die situasie, het die kliënt 'n opvolgvraag ontvang: "Kan jy iets soortgelyks doen sodat dit soos Google Spanner is, maar ook met Django ORM werk?"
Oplossing opsie nr. 0
Die eerste ding wat by my opgekom het:
- bly binne CloudSQL;
- daar sal geen ingeboude replikasie tussen streke in enige vorm wees nie;
- probeer om 'n replika aan 'n bestaande Cloud SQL deur PostgreSQL te heg;
- begin 'n PostgreSQL-instansie iewers en op een of ander manier, maar moet ten minste nie aan meester raak nie.
Helaas, dit het geblyk dat dit nie gedoen kan word nie, want daar is geen toegang tot die gasheer nie (dit is heeltemal in 'n ander projek) - pg_hba ensovoorts, en daar is ook geen toegang onder supergebruiker nie.
Oplossing opsie nr. 1
Na verdere besinning en met inagneming van vorige omstandighede, het die gedagtegang ietwat verander:
- Ons probeer steeds binne CloudSQL bly, maar ons skakel oor na MySQL, want Cloud SQL deur MySQL het 'n eksterne meester, wat:
- is 'n instaanbediener vir eksterne MySQL;
- lyk soos 'n MySQL-instansie;
- uitgevind vir die migreer van data vanaf ander wolke of op die perseel.
Aangesien die opstel van MySQL-replikasie nie toegang tot die gasheer vereis nie, het alles in beginsel gewerk, maar dit was baie onstabiel en ongerieflik. En toe ons verder gaan, het dit heeltemal skrikwekkend geword, want ons het die hele struktuur met terraform ontplooi, en skielik het dit geblyk dat die eksterne meester nie deur terraform ondersteun word nie. Ja, Google het 'n CLI, maar om een of ander rede het alles so nou en dan gewerk - soms is dit geskep, soms is dit nie geskep nie. Miskien omdat die CLI uitgevind is vir eksterne data-migrasie, en nie vir replikas nie.
Eintlik het dit op hierdie stadium duidelik geword dat Cloud SQL glad nie geskik is nie. Soos hulle sê, ons het alles gedoen wat ons kon.
Oplossing opsie nr. 2
Aangesien dit nie moontlik was om binne die Cloud SQL-raamwerk te bly nie, het ons probeer om vereistes vir 'n kompromie-oplossing te formuleer. Die vereistes blyk die volgende te wees:
- werk in Kubernetes, maksimum gebruik van hulpbronne en vermoëns van Kubernetes (DCS, ...) en GCP (LB, ...);
- gebrek aan ballas van 'n klomp onnodige dinge in die wolk soos HA proxy;
- die vermoë om PostgreSQL of MySQL in die hoof-HA-streek te laat loop; in ander streke - HA van die RR van die hoofstreek plus sy kopie (vir betroubaarheid);
- multi master (ek wou hom nie kontak nie, maar dit was nie baie belangrik nie)
.
As gevolg van hierdie eise, pgeskikte DBMS en bindingsopsies:
- MySQL Galera;
- KakkerlakDB;
- PostgreSQL-gereedskap
:
- pgpool-II;
— Patroni.
MySQL Galera
MySQL Galera-tegnologie is ontwikkel deur Codership en is 'n inprop vir InnoDB. Eienskappe:
- multi meester;
- sinchrone replikasie;
- lees vanaf enige nodus;
- opname na enige nodus;
- ingeboude HA-meganisme;
- Daar is 'n Helm grafiek van Bitnami.
KakkerlakDB
Volgens die beskrywing is die ding absoluut bom en is dit 'n oopbronprojek wat in Go geskryf is. Die hoofdeelnemer is Cockroach Labs (gestig deur mense van Google). Hierdie relasionele DBBS is oorspronklik ontwerp om versprei te word (met horisontale skaal uit die boks) en foutverdraagsaam. Sy skrywers van die maatskappy het die doelwit uiteengesit om "die rykdom van SQL-funksionaliteit te kombineer met die horisontale toeganklikheid wat bekend is aan NoSQL-oplossings."
'n Goeie bonus is ondersteuning vir die post-gress-verbindingsprotokol.
Pgpool
Dit is 'n byvoeging tot PostgreSQL, in werklikheid, 'n nuwe entiteit wat alle verbindings oorneem en dit verwerk. Dit het sy eie lasbalanseerder en ontleder, gelisensieer onder die BSD-lisensie. Dit bied oorgenoeg geleenthede, maar lyk ietwat skrikwekkend, want die teenwoordigheid van 'n nuwe entiteit kan die bron van 'n paar bykomende avonture word.
Patroni
Dit is die laaste ding waarop my oë geval het, en, soos dit geblyk het, nie verniet nie. Patroni is 'n oopbron-hulpmiddel, wat in wese 'n Python-demon is waarmee u PostgreSQL-klusters outomaties kan onderhou met verskillende soorte replikasie en outomatiese rolwisseling. Die ding blyk baie interessant te wees, aangesien dit goed met die kuber integreer en geen nuwe entiteite bekendstel nie.
Wat het jy op die ou end gekies?
Die keuse was nie maklik nie:
- KakkerlakDB - vuur, maar donker;
- MySQL Galera - ook nie sleg nie, dit word op baie plekke gebruik, maar MySQL;
- Pgpool - baie onnodige entiteite, so-so integrasie met die wolk en K8's;
- Patroni - uitstekende integrasie met K8's, geen onnodige entiteite nie, integreer goed met GCP LB.
Die keuse het dus op Patroni geval.
Bevindinge
Dit is tyd om kortliks op te som. Ja, die wêreld van IT-infrastruktuur het aansienlik verander, en dit is net die begin. En as die wolke voorheen net 'n ander soort infrastruktuur was, is alles nou anders. Boonop verskyn innovasies in die wolke voortdurend, hulle sal verskyn en miskien sal hulle slegs in die wolke verskyn en eers dan, deur die pogings van opstart, sal dit na die perseel oorgeplaas word.
Wat SQL betref, sal SQL leef. Dit beteken dat jy PostgreSQL en MySQL moet ken en daarmee moet kan werk, maar nog belangriker is om dit korrek te kan gebruik.
Bron: will.com