Moien, Khabrovsk Awunner. D'Coursen an der éischter Grupp vum Cours starten haut . An dëser Hisiicht wëlle mir Iech soen wéi den oppene Webinar op dësem Cours stattfonnt huet.
В mir hunn iwwer d'Erausfuerderunge geschwat SQL Datenbanken an der Ära vu Wolleken a Kubernetes. Zur selwechter Zäit hu mir gekuckt wéi SQL Datenbanken upassen an mutéieren ënner dem Afloss vun dësen Erausfuerderungen.
De Webinar gouf ofgehalen , Google Cloud Practice Delivery Manager bei EPAM Systems.
Wéi d'Beem kleng waren ...
Als éischt, loosst eis erënneren wéi d'Wiel vun DBMS um Enn vum leschte Joerhonnert ugefaang huet. Dëst wäert awer net schwéier sinn, well d'Wiel vun engem DBMS an deenen Deeg ugefaang an opgehalen huet entscheet.
An de spéiden 90er a fréien 2er gouf et am Fong keng Wiel wann et ëm industriell skalierbar Datenbanken kënnt. Jo, et waren IBM DBXNUMX, Sybase an e puer aner Datenbanken, déi koumen a gaangen sinn, awer am Allgemengen waren se net sou opfälleg géint den Hannergrond vun Oracle. Deementspriechend waren d'Fäegkeeten vun deenen Zäiten Ingenieuren iergendwéi un déi eenzeg Wiel gebonnen déi existéiert.
Oracle DBA muss fäeg sinn:
- Oracle Server aus dem Verdeelungskit installéieren;
- Oracle Server konfiguréieren:
- init.ora;
- lauschteren.ora;
- kreéieren:
- tablespaces;
- Schemaen;
- Benotzer;
- Backupsatellit maachen a Restauréieren;
- Iwwerwaachung ausféieren;
- mat suboptimalen Ufroen ëmgoen.
Zur selwechter Zäit gouf et keng speziell Ufuerderung vun Oracle DBA:
- fäeg sinn déi optimal DBMS oder aner Technologie fir Daten ze späicheren an ze veraarbechten;
- bitt héich Disponibilitéit an horizontal Skalierbarkeet (dëst war net ëmmer en DBA Thema);
- gutt Kenntnisser vum Fachberäich, Infrastruktur, Applikatiounsarchitektur, OS;
- lued an entluede Donnéeën, migréieren Daten tëscht verschiddene DBMSs.
Am Allgemengen, wa mir iwwer d'Wiel an deenen Deeg schwätzen, gläicht et d'Wiel an engem sowjetesche Buttek an de spéiden 80er:
Eis Zäit
Zënterhier sinn natierlech d'Beem gewuess, d'Welt huet sech geännert, an et gouf sou eppes:
Den DBMS Maart huet och geännert, wéi kloer aus dem leschte Bericht vu Gartner gesi ka ginn:
An hei sollt et feststellen datt d'Wolleken, deenen hir Popularitéit wiisst, hir Nisch besat hunn. Wa mir dee selwechte Gartner Bericht liesen, wäerte mir déi folgend Conclusiounen gesinn:
- Vill Clientë sinn um Wee fir Uwendungen an d'Cloud ze plënneren.
- Nei Technologien erschéngen fir d'éischt an der Wollek an et ass kee Fakt datt se jeemools an net-Cloud Infrastruktur plënneren.
- De Pay-as-you-go Präismodell ass allgemeng ginn. Jidderee wëll nëmme bezuelen fir dat wat e benotzt, an dëst ass net emol en Trend, mee einfach eng Erklärung.
Waat elo?
Haut si mir all an der Wollek. An d'Froen, déi fir eis optrieden, si Froen vum Choix. An et ass enorm, och wa mir nëmmen iwwer d'Wiel vun DBMS Technologien am On-premises Format schwätzen. Mir hunn och geréiert Servicer a SaaS. Sou gëtt de Choix just all Joer méi schwéier.
Zesumme mat de Choix Froen ginn et och limitéierend Faktoren:
- den Präiss. Vill Technologien kaschten nach ëmmer Sue;
- Fäegkeeten. Wa mir iwwer gratis Software schwätzen, da stellt sech d'Fro vun de Fäegkeeten op, well gratis Software erfuerdert genuch Kompetenz vun de Leit, déi se ofsetzen an operéieren;
- funktionell. Net all Servicer, déi an der Wollek verfügbar sinn a gebaut sinn, sot och op der selwechter Postgres, hunn déiselwecht Funktiounen wéi Postgres On-premises. Dëst ass e wesentleche Faktor dee muss bekannt a verstane ginn. Ausserdeem gëtt dëse Faktor méi wichteg wéi Wëssen iwwer e puer verstoppte Fäegkeeten vun engem eenzegen DBMS.
Wat gëtt elo vum DA/DE erwaart:
- gutt Verständnis vum Thema Beräich an Applikatioun Architektur;
- d'Kapazitéit fir déi entspriechend DBMS-Technologie richteg ze wielen, andeems d'Aufgab op der Hand berécksiichtegt;
- d'Fäegkeet fir déi optimal Method fir d'Ëmsetzung vun der gewielter Technologie am Kontext vun existente Aschränkungen ze wielen;
- Fäegkeet fir Datenübertragung a Migratioun ze maachen;
- Fäegkeet ausgewielt Léisungen ëmzesetzen an ze bedreiwen.
Drënner Beispill baséiert op GCP weist wéi d'Wiel vun enger oder anerer Technologie fir mat Daten ze schaffen ofhängeg vun hirer Struktur funktionnéiert:
Maacht weg datt PostgreSQL net am Schema abegraff ass, an dëst ass well et ënner der Terminologie verstoppt ass Cloud SQL. A wa mir op Cloud SQL kommen, musse mir erëm e Choix maachen:
Et sollt bemierkt datt dës Wiel net ëmmer kloer ass, sou datt d'Applikatioun Entwéckler dacks vun Intuition guidéiert ginn.
Total:
- Wat Dir méi wäit geet, wat méi dréngend d'Fro vum Choix gëtt. An och wann Dir nëmmen op GCP, verwalteten Servicer a SaaS kuckt, da erschéngt e puer Ernimmung vu RDBMS nëmmen um 4. Schrëtt (an do ass Spanner an der Géigend). Plus, d'Wiel vu PostgreSQL erschéngt am 5. Schrëtt, an niewendrun sinn et och MySQL a SQL Server, dat ass et gëtt vill vun allem, mee du muss wielen.
- Mir däerfen net iwwer Restriktiounen géint den Hannergrond vun de Versuchungen vergiessen. Prinzipiell wëll jiddereen e Spanner, awer et ass deier. Als Resultat gesäit eng typesch Ufro sou eppes aus: "Maacht w.e.g. e Spanner, awer fir de Präis vu Cloud SQL sidd Dir Professionnel!"
Wat sollt ech maachen?
Ouni ze behaapten déi ultimativ Wourecht ze sinn, loosst eis déi folgend soen:
Mir mussen eis Approche zum Léieren änneren:
- et huet kee Sënn fir d'Art a Weis wéi d'DBAs virdru geléiert goufen ze léieren;
- Wësse vun engem Produkt geet net méi duer;
- mee wëssen Dosende um Niveau vun engem onméiglech ass.
Dir musst net nëmmen wëssen an net wéi vill de Produkt ass, awer:
- benotzen Fall vu senger Applikatioun;
- verschidde Deploymentmethoden;
- Virdeeler an Nodeeler vun all Method;
- ähnlechen an alternativ Produkter fir en informéierten an optimale Choix ze maachen an net ëmmer zugonschte vun engem vertraute Produkt.
Dir musst och fäeg sinn Daten ze migréieren an d'Basisprinzipien vun der Integratioun mat ETL ze verstoen.
Real Fall
An der rezenter Vergaangenheet war et néideg e Backend fir eng mobil Applikatioun ze kreéieren. Wéi d'Aarbechte ugefaang hunn, war de Backend scho entwéckelt a war prett fir d'Ëmsetzung, an d'Entwécklungsteam huet ongeféier zwee Joer un dësem Projet verbruecht. Folgend Aufgaben goufen opgestallt:
- bauen CI / CD;
- iwwerpréiwen d'Architektur;
- alles a Betrib setzen.
D'Applikatioun selwer war Mikroservicer, an de Python / Django Code gouf vun Null an direkt am GCP entwéckelt. Wat d'Zilpublikum ugeet, gouf ugeholl datt et zwou Regioune wäerte ginn - d'US an d'EU, an de Verkéier gouf duerch de Global Load Balancer verdeelt. All Workloads a Berechnungsaarbechtslaascht lafen op Google Kubernetes Engine.
Wat d'Donnéeën ugeet, goufen et 3 Strukturen:
- Cloud Storage;
- Datastore;
- Cloud SQL (PostgreSQL).
Et kann ee sech froen firwat Cloud SQL gewielt gouf? Fir d'Wourecht ze soen, esou eng Fro huet an de leschte Joeren eng Aart vu schweier Paus gesuergt - et gëtt d'Gefill datt d'Leit schei ginn iwwer relational Datenbanken, awer trotzdem benotze se se weider ;-).
Wat eise Fall ugeet, gouf Cloud SQL aus de folgende Grënn gewielt:
- Wéi erwähnt, ass d'Applikatioun entwéckelt mat Django, an et huet e Modell fir persistent Daten aus enger SQL Datebank op Python Objeten (Django ORM) ze kartéieren.
- De Kader selwer ënnerstëtzt eng zimlech endlech Lëscht vun DBMSen:
- PostgreSQL;
- MariaDB;
- MySQL;
- Orakel;
- SQLite.
Deementspriechend gouf PostgreSQL aus dëser Lëscht éischter intuitiv gewielt (gutt, et ass net Oracle ze wielen, wierklech).
Wat huet gefeelt:
- D'Applikatioun gouf nëmmen an 2 Regiounen agesat, an eng 3. erschéngt a Pläng (Asien);
- D'Datebank war an der North American Regioun (Iowa);
- op der Säit vum Client gouf et Bedenken iwwer méiglech Zougang Verspéidungen aus Europa an Asien an Ënnerbriechungen am Déngscht am Fall vun DBMS Ausdauer.
Trotz der Tatsaach, datt den Django selwer mat verschiddenen Datenbanken parallel kann schaffen an se a Liesen a Schreiwen opdeelen, gouf et net sou vill Schreiwen an der Applikatioun (méi wéi 90% liesen). An am Allgemengen, an am Allgemengen, wann et méiglech war ze maachen liesen-Replique vun der Haaptrei Basis an Europa an Asien, wier dat eng Kompromissléisung. Gutt, wat ass sou komplizéiert doriwwer?
D'Schwieregkeet war datt de Client net wollt opginn mat verwalteten Servicer a Cloud SQL. An d'Kapazitéite vu Cloud SQL sinn am Moment limitéiert. Cloud SQL ënnerstëtzt High Disponibilitéit (HA) a Read Replica (RR), awer déiselwecht RR gëtt nëmmen an enger Regioun ënnerstëtzt. Nodeems Dir eng Datebank an der amerikanescher Regioun erstallt hutt, kënnt Dir net eng Lieskopie an der europäescher Regioun mat Cloud SQL maachen, obwuel Postgres selwer Iech net verhënnert dëst ze maachen. Korrespondenz mat Google Mataarbechter huet néierens gefouert an ass mat Verspriechen am Stil vun "mir kennen de Problem a schaffen drun, iergendwann wäert d'Thema geléist ginn."
Wa mir d'Kapazitéite vu Cloud SQL kuerz opzielen, da gesäit et esou aus:
1. Héich Disponibilitéit (HA):
- bannent enger Regioun;
- iwwer Disk Replikatioun;
- PostgreSQL Motore ginn net benotzt;
- automatesch a manuell Kontroll méiglech - Failover / Failback;
- Wann Dir wiesselt, ass den DBMS fir e puer Minutten net verfügbar.
2. Liesen Replica (RR):
- bannent enger Regioun;
- waarme Standby;
- PostgreSQL Streaming Replikatioun.
Ausserdeem, wéi et üblech ass, wann Dir eng Technologie wielt, sidd Dir ëmmer mat e puer konfrontéiert Restriktiounen:
- de Client wollt net Entitéiten erstellen an IaaS benotzen, ausser duerch GKE;
- de Client wéilt net Self-Service PostgreSQL / MySQL ofsetzen;
- Gutt, am Allgemengen, Google Spanner wier ganz gëeegent wann et net fir säi Präis wier, awer Django ORM kann net mat him schaffen, awer et ass eng gutt Saach.
Wann Dir d'Situatioun berécksiichtegt, krut de Client eng Suivifro: "Kënnt Dir eppes ähnleches maachen, sou datt et wéi Google Spanner ass, awer och mat Django ORM funktionnéiert?"
Léisungsoptioun Nr 0
Dat éischt wat an de Kapp koum:
- bleiwen bannent CloudSQL;
- et gëtt keng agebauter Replikatioun tëscht Regiounen an iergendenger Form;
- probéiert eng Replika op eng existent Cloud SQL vun PostgreSQL ze befestigen;
- lancéiert eng PostgreSQL Instanz iergendwou an iergendwéi, awer op d'mannst net de Master beréieren.
Och, et huet sech erausgestallt datt dëst net ka gemaach ginn, well et keen Zougang zum Host gëtt (et ass ganz an engem anere Projet) - pg_hba an sou weider, an et gëtt och keen Zougang ënner Superuser.
Léisungsoptioun Nr 1
No weiderer Reflexioun a Berécksiichtegung vu fréieren Ëmstänn, huet de Gedankenzuch e bësse geännert:
- Mir probéieren nach ëmmer bannent CloudSQL ze bleiwen, awer mir wiesselen op MySQL, well Cloud SQL vu MySQL en externe Master huet, deen:
- ass e Proxy fir extern MySQL;
- gesäit aus wéi eng MySQL Instanz;
- erfonnt fir d'Migratioun vun Daten aus anere Wolleken oder on-premises.
Zënter datt d'MySQL Replikatioun opgeriicht ass keen Zougang zum Host erfuerdert, huet am Prinzip alles geschafft, awer et war ganz onbestänneg an onbequem. A wa mir weider gaang sinn, ass et komplett grujeleg ginn, well mir déi ganz Struktur mat Terraform agesat hunn, an op eemol huet sech erausgestallt datt den externen Meeschter net vun der Terraform ënnerstëtzt gouf. Jo, Google huet e CLI, awer aus irgendege Grënn huet alles hei all elo an dann geschafft - heiansdo ass et erstallt, heiansdo ass et net erstallt. Vläicht well de CLI fir extern Datenmigratioun erfonnt gouf, an net fir Repliken.
Eigentlech, op dësem Punkt gouf et kloer datt Cloud SQL guer net gëeegent ass. Wéi se soen, mir hunn alles gemaach wat mir konnten.
Léisungsoptioun Nr 2
Well et net méiglech war am Cloud SQL Kader ze bleiwen, hu mir probéiert Ufuerderunge fir eng Kompromissléisung ze formuléieren. D'Ufuerderunge waren déi folgend:
- Aarbecht an Kubernetes, maximal Notzung vu Ressourcen a Fäegkeete vu Kubernetes (DCS, ...) a GCP (LB, ...);
- Mangel u Ballast vun enger Rëtsch onnéideg Saachen an der Wollek wéi HA Proxy;
- d'Fäegkeet fir PostgreSQL oder MySQL an der Haaptrei HA Regioun ze lafen; an anere Regiounen - HA aus der RR vun der Haaptrei Regioun plus seng Kopie (fir Zouverlässegkeet);
- Multi Master (Ech wollt him net kontaktéieren, awer et war net ganz wichteg)
.
Als Resultat vun dëse Fuerderungen, pgëeegent DBMS a verbindlech Optiounen:
- MySQL Galera;
- KakerlakDB;
- PostgreSQL Tools
:
- pgpool-II;
- Patroni.
MySQL Galera
MySQL Galera Technologie gouf vum Codership entwéckelt an ass e Plugin fir InnoDB. Eegenheeten:
- Multi Meeschtesch;
- synchron Replikatioun;
- liesen vun all Node;
- Opnam op all Node;
- gebaut-an HA Mechanismus;
- Et gëtt eng Helm Chart vu Bitnami.
KakerlakDB
No der Beschreiwung ass d'Saach absolut Bomm an ass en Open Source Projet geschriwwen an Go. Den Haaptparticipant ass Cockroach Labs (gegrënnt vu Leit vu Google). Dës relational DBMS war ursprénglech entworf fir verdeelt ze ginn (mat horizontaler Skaléierung aus der Këscht) a Feelertolerant. Seng Autoren aus der Firma hunn d'Zil beschriwwen "de Räichtum vun der SQL Funktionalitéit ze kombinéieren mat der horizontaler Accessibilitéit déi mat NoSQL-Léisungen vertraut ass."
E flotte Bonus ass Ënnerstëtzung fir de Post-gress Verbindungsprotokoll.
pgpool
Dëst ass en Add-on zu PostgreSQL, tatsächlech, eng nei Entitéit déi all Verbindungen iwwerhëlt an se veraarbecht. Et huet säin eegene Lastbalancer a Parser, lizenzéiert ënner der BSD Lizenz. Et bitt vill Méiglechkeeten, awer gesäit e bësse grujeleg aus, well d'Präsenz vun enger neier Entitéit kéint d'Quell vun e puer zousätzlech Abenteuer ginn.
Patroni
Dëst ass déi lescht Saach op meng Ae gefall, a wéi et sech erausstellt, net ëmsoss. Patroni ass en Open Source Utility, deen am Wesentlechen e Python-Daemon ass, deen Iech erlaabt automatesch PostgreSQL-Cluster mat verschiddenen Aarte vu Replikatioun an automatesch Rollewiessel z'erhalen. D'Saach huet sech als ganz interessant erausgestallt, well se gutt mam Cuber integréiert an keng nei Entitéite virstellt.
Wat hutt Dir um Enn gewielt?
De Choix war net einfach:
- KakerlakDB - Feier, awer däischter;
- MySQL Galera - och net schlecht, et gëtt op ville Plazen benotzt, awer MySQL;
- pgpool - vill onnéideg Entitéiten, sou-sou Integratioun mat der Wollek an K8s;
- Patroni - excellent Integratioun mat K8s, keng onnéideg Entitéite, integréiert gutt mat GCP LB.
Sou ass de Choix op Patroni gefall.
Conclusiounen
Et ass Zäit fir kuerz ze resuméieren. Jo, d'Welt vun der IT Infrastruktur huet wesentlech geännert, an dëst ass just den Ufank. A wann virdrun d'Wolleken nëmmen eng aner Zort Infrastruktur waren, ass elo alles anescht. Ausserdeem erschéngen dauernd Innovatiounen an de Wolleken, si erschéngen a vläicht erschéngen se nëmmen an de Wolleken an nëmmen dann, duerch d'Efforte vun Startups, ginn se op On-premises transferéiert.
Wat SQL ugeet, wäert SQL liewen. Dëst bedeit datt Dir PostgreSQL a MySQL muss kennen a fäeg sinn mat hinnen ze schaffen, awer nach méi wichteg ass se richteg ze benotzen.
Source: will.com