Hej alla invånare i Khabrovsk. Lektionerna i kursens första grupp börjar idag . I detta avseende vill vi berätta om hur det öppna webbinariet om denna kurs gick till.
В vi pratade om de utmaningar som SQL-databaser står inför i en tidevarv av moln och Kubernetes. Samtidigt tittade vi på hur SQL-databaser anpassar sig och muterar under påverkan av dessa utmaningar.
Webinariet hölls , Google Cloud Practice Delivery Manager på EPAM Systems.
När träden var små...
Låt oss först komma ihåg hur valet av DBMS började i slutet av förra seklet. Detta kommer dock inte att vara svårt, eftersom valet av ett DBMS på den tiden började och slutade Oracle.
I slutet av 90-talet och början av 2-talet fanns det i princip inget val när det gäller industriella skalbara databaser. Ja, det var IBM DBXNUMX, Sybase och några andra databaser som kom och gick, men i allmänhet var de inte så märkbara mot bakgrund av Oracle. Följaktligen var kompetensen hos ingenjörer från den tiden på något sätt bundna till det enda valet som fanns.
Oracle DBA var tvungen att kunna:
- installera Oracle Server från distributionspaketet;
- konfigurera Oracle Server:
- init.ora;
- lyssnare.ora;
- skapa:
- bordsutrymmen;
- schema;
- användare;
— utföra säkerhetskopiering och återställning;
— Utföra övervakning.
— hantera suboptimala förfrågningar.
Samtidigt fanns det inga särskilda krav från Oracle DBA:
- kunna välja det optimala DBMS eller annan teknik för lagring och bearbetning av data;
- ge hög tillgänglighet och horisontell skalbarhet (detta var inte alltid ett DBA-problem);
- goda kunskaper om ämnesområdet, infrastruktur, applikationsarkitektur, OS;
- ladda och lossa data, migrera data mellan olika DBMS.
I allmänhet, om vi pratar om valet på den tiden, liknar det valet i en sovjetisk butik i slutet av 80-talet:
Vår tid
Sedan dess har naturligtvis träden växt, världen har förändrats, och det blev ungefär så här:
DBMS-marknaden har också förändrats, vilket tydligt framgår av den senaste rapporten från Gartner:
Och här bör det noteras att moln, vars popularitet växer, har ockuperat sin nisch. Om vi läser samma Gartner-rapport kommer vi att se följande slutsatser:
- Många kunder är på väg att flytta applikationer till molnet.
- Ny teknik dyker först upp i molnet och det är inte ett faktum att de någonsin kommer att gå över till icke-molninfrastruktur.
- Betalningsmodellen har blivit vanlig. Alla vill bara betala för det de använder, och detta är inte ens en trend, utan bara ett faktum.
Och nu då?
Idag är vi alla i molnet. Och frågorna som dyker upp för oss är valfrågor. Och det är enormt, även om vi bara talar om valet av DBMS-teknologier i det lokala formatet. Vi har även hanterade tjänster och SaaS. Därmed blir valet bara svårare för varje år.
Tillsammans med valfrågor finns det också begränsande faktorer:
- pris. Många tekniker kostar fortfarande pengar;
- Kompetens. Om vi talar om fri programvara, då uppstår frågan om kompetens, eftersom fri programvara kräver tillräcklig kompetens från de människor som distribuerar och driver den;
- funktionell. Alla tjänster som är tillgängliga i molnet och byggda, till exempel, ens på samma Postgres, har inte samma funktioner som Postgres On-premises. Detta är en viktig faktor som måste vara känd och förstådd. Dessutom blir denna faktor viktigare än kunskap om några dolda funktioner i ett enda DBMS.
Vad förväntas av DA/DE nu:
- god förståelse för ämnesområdet och applikationsarkitektur;
- förmågan att korrekt välja lämplig DBMS-teknik, med hänsyn till den aktuella uppgiften;
- förmågan att välja den optimala metoden för att implementera den valda tekniken i samband med befintliga begränsningar;
- förmåga att utföra dataöverföring och migrering;
- förmåga att implementera och driva utvalda lösningar.
Nedan exempel baserat på GCP visar hur valet av en eller annan teknik för att arbeta med data fungerar beroende på dess struktur:
Observera att PostgreSQL inte ingår i schemat, och det beror på att det är dolt under terminologin CloudSQL. Och när vi kommer till Cloud SQL måste vi göra ett val igen:
Det bör noteras att detta val inte alltid är tydligt, så applikationsutvecklare styrs ofta av intuition.
Totalt:
- Ju längre du kommer, desto mer pressande blir frågan om val. Och även om du bara tittar på GCP, hanterade tjänster och SaaS, så visas något omnämnande av RDBMS först i det 4:e steget (och där är Spanner i närheten). Dessutom visas valet av PostgreSQL i det 5:e steget, och bredvid det finns även MySQL och SQL Server, det vill säga det finns mycket av allt, men du måste välja.
- Vi får inte glömma restriktioner mot bakgrund av frestelser. I princip alla vill ha en nyckel, men det är dyrt. Som ett resultat ser en typisk begäran ut ungefär så här: "Snälla gör oss till en nyckel, men för priset av Cloud SQL är ni proffs!"
Men vad ska man göra?
Utan att göra anspråk på att vara den ultimata sanningen, låt oss säga följande:
Vi måste ändra vår inställning till lärande:
- det är ingen mening att undervisa på det sätt som DBA lärdes ut tidigare;
- kunskap om en produkt räcker inte längre;
- men att veta dussintals på nivån ett är omöjligt.
Du behöver inte bara veta och inte hur mycket produkten är, utan:
- användningsfallet för dess tillämpning;
- olika distributionsmetoder;
- fördelar och nackdelar med varje metod;
- liknande och alternativa produkter för att göra ett informerat och optimalt val och inte alltid till förmån för en bekant produkt.
Du behöver också kunna migrera data och förstå de grundläggande principerna för integration med ETL.
verkligt fall
På senare tid var det nödvändigt att skapa en backend för en mobilapplikation. När arbetet började med det hade backend redan utvecklats och var redo för implementering, och utvecklingsteamet tillbringade ungefär två år på detta projekt. Följande uppgifter sattes:
- bygga CI/CD;
- granska arkitekturen;
- sätta allt i drift.
Själva applikationen var mikrotjänster, och Python/Django-koden utvecklades från grunden och direkt i GCP. När det gäller målgruppen antogs det att det skulle finnas två regioner - USA och EU, och trafiken distribuerades genom Global Load Balancer. Alla arbetsbelastningar och beräkningsbelastning kördes på Google Kubernetes Engine.
När det gäller data fanns det 3 strukturer:
- Molnlagring;
- Datalagring;
- Cloud SQL (PostgreSQL).
Man kan undra varför Cloud SQL valdes? Ärligt talat har en sådan fråga orsakat någon form av besvärlig paus de senaste åren - det finns en känsla av att folk har blivit blyga för relationsdatabaser, men ändå fortsätter de att aktivt använda dem ;-).
När det gäller vårt fall valdes Cloud SQL av följande skäl:
- Som nämnts utvecklades applikationen med Django, och den har en modell för att kartlägga beständiga data från en SQL-databas till Python-objekt (Django ORM).
- Själva ramverket stödde en ganska begränsad lista över DBMS:er:
- PostgreSQL;
- MariaDB;
- MySQL;
- Orakel;
- SQLite.
Följaktligen valdes PostgreSQL från den här listan ganska intuitivt (tja, det är inte Oracle att välja, egentligen).
Vad saknades:
- applikationen distribuerades endast i 2 regioner, och en tredje dök upp i planer (Asien);
- Databasen fanns i den nordamerikanska regionen (Iowa);
- från kundens sida fanns det farhågor om ev tillträdesförseningar från Europa och Asien och avbrott i tjänst vid DBMS-stopptid.
Trots att Django själv kan arbeta med flera databaser parallellt och dela upp dem i läsning och skrivning, var det inte så mycket skrivning i applikationen (mer än 90% läser). Och i allmänhet, och i allmänhet, om det var möjligt att göra läs-replika av huvudbasen i Europa och Asien, skulle detta vara en kompromisslösning. Tja, vad är det som är så komplicerat med det?
Svårigheten var att kunden inte ville ge upp med att använda hanterade tjänster och Cloud SQL. Och funktionerna i Cloud SQL är för närvarande begränsade. Cloud SQL stöder hög tillgänglighet (HA) och Read Replica (RR), men samma RR stöds bara i en region. Efter att ha skapat en databas i den amerikanska regionen kan du inte göra en läsreplika i den europeiska regionen med Cloud SQL, även om Postgres själv inte hindrar dig från att göra detta. Korrespondens med Google-anställda ledde ingenstans och slutade med löften i stil med "vi känner till problemet och jobbar på det, en dag kommer problemet att lösas."
Om vi kort listar funktionerna i Cloud SQL kommer det att se ut ungefär så här:
1. Hög tillgänglighet (HA):
- inom en region;
- via diskreplikering;
- PostgreSQL-motorer används inte;
- automatisk och manuell kontroll möjlig - failover/failback;
- När du byter är DBMS inte tillgängligt i flera minuter.
2. Läs Replica (RR):
- inom en region;
- varm standby;
- PostgreSQL strömmande replikering.
Dessutom, som är brukligt, när man väljer en teknik ställs man alltid inför en del restriktioner:
- kunden ville inte skapa enheter och använda IaaS, förutom genom GKE;
- kunden vill inte distribuera självbetjäning PostgreSQL/MySQL;
- Tja, i allmänhet skulle Google Spanner vara ganska lämplig om det inte vore för sitt pris, men Django ORM kan inte fungera med det, men det är bra.
Med tanke på situationen fick kunden en följdfråga: "Kan du göra något liknande så att det är som Google Spanner, men också fungerar med Django ORM?"
Lösningsalternativ nr 0
Det första som kom att tänka på:
- stanna inom CloudSQL;
- det kommer inte att finnas någon inbyggd replikering mellan regioner i någon form;
- försök att bifoga en replik till en befintlig Cloud SQL av PostgreSQL;
- starta en PostgreSQL-instans någonstans och på något sätt, men rör åtminstone inte master.
Tyvärr visade det sig att detta inte kan göras, eftersom det inte finns någon åtkomst till värden (den är i ett helt annat projekt) - pg_hba och så vidare, och det finns inte heller åtkomst under superanvändare.
Lösningsalternativ nr 1
Efter ytterligare eftertanke och med hänsyn till tidigare omständigheter förändrades tankegången något:
- Vi försöker fortfarande hålla oss inom CloudSQL, men vi byter till MySQL, eftersom Cloud SQL by MySQL har en extern master, som:
— är en proxy för extern MySQL;
- ser ut som en MySQL-instans;
- uppfunnet för att migrera data från andra moln eller lokalt.
Eftersom att sätta upp MySQL-replikering inte kräver åtkomst till värden fungerade i princip allt, men det var väldigt instabilt och obekvämt. Och när vi gick vidare blev det helt läskigt, eftersom vi satte ut hela strukturen med terraform, och plötsligt visade det sig att den externa mästaren inte stöddes av terraform. Ja, Google har ett CLI, men av någon anledning fungerade allt här då och då - ibland skapas det, ibland skapas det inte. Kanske för att CLI uppfanns för extern datamigrering och inte för repliker.
Egentligen blev det vid det här laget klart att Cloud SQL inte alls är lämpligt. Som de säger, vi gjorde allt vi kunde.
Lösningsalternativ nr 2
Eftersom det inte gick att hålla sig inom Cloud SQL-ramverket försökte vi formulera krav på en kompromisslösning. Kraven visade sig vara följande:
- arbete i Kubernetes, maximal användning av resurser och kapacitet hos Kubernetes (DCS, ...) och GCP (LB, ...);
- brist på barlast från en massa onödiga saker i molnet som HA proxy;
- förmågan att köra PostgreSQL eller MySQL i den huvudsakliga HA-regionen; i andra regioner - HA från RR i huvudregionen plus dess kopia (för tillförlitlighet);
- multi master (jag ville inte kontakta honom, men det var inte särskilt viktigt)
.
Till följd av dessa krav, sidlämpliga DBMS och bindningsalternativ:
- MySQL Galera;
- KackerlackaDB;
- PostgreSQL-verktyg
:
- pgpool-II;
— Patroni.
MySQL Galera
MySQL Galera-teknologin utvecklades av Codership och är en plugin för InnoDB. Egenheter:
- multi master;
- synkron replikering;
- läsning från valfri nod;
- inspelning till valfri nod;
- inbyggd HA-mekanism;
- Det finns ett Helm-diagram från Bitnami.
Kackerlacka DB
Enligt beskrivningen är saken absolut bomb och är ett projekt med öppen källkod skrivet i Go. Huvuddeltagaren är Cockroach Labs (grundat av personer från Google). Denna relationella DBMS designades ursprungligen för att vara distribuerad (med horisontell skalning ur lådan) och feltolerant. Dess författare från företaget beskrev målet att "kombinera rikedomen av SQL-funktionalitet med den horisontella tillgängligheten som är bekant för NoSQL-lösningar."
En trevlig bonus är stöd för post-gress-anslutningsprotokollet.
Pgpool
Detta är ett tillägg till PostgreSQL, i själva verket en ny enhet som tar över alla anslutningar och bearbetar dem. Den har sin egen lastbalanserare och parser, licensierad under BSD-licensen. Det ger gott om möjligheter, men ser något skrämmande ut, eftersom närvaron av en ny enhet kan bli källan till några ytterligare äventyr.
Patroni
Det här är det sista mina ögon föll på, och, som det visade sig, inte förgäves. Patroni är ett verktyg med öppen källkod, som i huvudsak är en Python-demon som låter dig underhålla PostgreSQL-kluster automatiskt med olika typer av replikering och automatisk rollbyte. Saken visade sig vara mycket intressant, eftersom den integreras väl med kubern och inte introducerar några nya enheter.
Vad valde du till slut?
Valet var inte lätt:
- Kackerlacka DB - eld, men mörkt;
- MySQL Galera - inte heller dåligt, det används på många ställen, men MySQL;
- Pgpool — många onödiga enheter, so-so integration med molnet och K8s;
- Patroni - utmärkt integration med K8s, inga onödiga enheter, integreras bra med GCP LB.
Därmed föll valet på Patroni.
Resultat
Det är dags att sammanfatta kort. Ja, världen av IT-infrastruktur har förändrats avsevärt, och detta är bara början. Och om molnen innan bara var en annan typ av infrastruktur, nu är allt annorlunda. Dessutom dyker innovationer i molnen ständigt upp, de kommer att dyka upp och, kanske, kommer de bara att dyka upp i molnen och först då, genom ansträngningar från startups, kommer de att överföras till On-premises.
När det gäller SQL kommer SQL att leva. Det betyder att du behöver känna till PostgreSQL och MySQL och kunna arbeta med dem, men ännu viktigare är att kunna använda dem korrekt.
Källa: will.com