Hallo, inwoners van Khabrovsk. De lessen in de eerste groep van de cursus starten vandaag . In dit verband vertellen wij u graag hoe het open webinar over deze cursus plaatsvond.
В we spraken over de uitdagingen waarmee SQL-databases worden geconfronteerd in het tijdperk van clouds en Kubernetes. Tegelijkertijd keken we naar hoe SQL-databases zich aanpassen en muteren onder invloed van deze uitdagingen.
Het webinar is gehouden , Google Cloud Practice Delivery Manager bij EPAM Systems.
Toen de bomen nog klein waren...
Laten we eerst onthouden hoe de keuze voor DBMS eind vorige eeuw begon. Dit zal echter niet moeilijk zijn, omdat de keuze voor een DBMS in die tijd begon en eindigde Oracle.
Eind jaren negentig en begin jaren 90 was er feitelijk geen keuze als het ging om industrieel schaalbare databases. Ja, er waren IBM DB2, Sybase en enkele andere databases die kwamen en gingen, maar over het algemeen waren ze niet zo opvallend tegen de achtergrond van Oracle. Dienovereenkomstig waren de vaardigheden van ingenieurs uit die tijd op de een of andere manier verbonden met de enige keuze die er bestond.
Oracle DBA moest het volgende kunnen:
- installeer Oracle Server vanuit de distributiekit;
- configureer Oracle Server:
- init.ora;
- luisteraar.ora;
- creëren:
- tabelruimten;
- regeling;
- gebruikers;
— back-up en herstel uitvoeren;
— toezicht uitoefenen;
— omgaan met suboptimale verzoeken.
Tegelijkertijd was er geen speciale vereiste van Oracle DBA:
- in staat zijn om de optimale DBMS of andere technologie te kiezen voor het opslaan en verwerken van gegevens;
- zorgen voor hoge beschikbaarheid en horizontale schaalbaarheid (dit was niet altijd een DBA-probleem);
- goede kennis van het vakgebied, infrastructuur, applicatiearchitectuur, OS;
- gegevens laden en ontladen, gegevens migreren tussen verschillende DBMS'en.
Als we het in die tijd over de keuze hebben, lijkt deze over het algemeen op de keuze in een Sovjetwinkel eind jaren 80:
Onze tijd
Sindsdien zijn de bomen natuurlijk gegroeid, is de wereld veranderd en is het ongeveer zo geworden:
Ook de DBMS-markt is veranderd, zoals duidelijk blijkt uit het laatste rapport van Gartner:
En hier moet worden opgemerkt dat wolken, waarvan de populariteit groeit, hun niche hebben ingenomen. Als we hetzelfde Gartner-rapport lezen, zien we de volgende conclusies:
- Veel klanten zijn op weg om applicaties naar de cloud te verplaatsen.
- Nieuwe technologieën verschijnen voor het eerst in de cloud en het is geen feit dat ze ooit zullen overgaan naar een niet-cloudinfrastructuur.
- Het ‘pay-as-you-go’-prijsmodel is gemeengoed geworden. Iedereen wil alleen betalen voor wat hij of zij gebruikt, en dit is niet eens een trend, maar gewoon een feit.
Wat nu?
Tegenwoordig bevinden we ons allemaal in de cloud. En de vragen die bij ons opkomen zijn keuzevragen. En het is enorm, zelfs als we het alleen hebben over de keuze voor DBMS-technologieën in het On-premises-formaat. Daarnaast beschikken wij over managed services en SaaS. Zo wordt de keuze elk jaar alleen maar moeilijker.
Naast keuzevragen zijn er ook Beperkende factoren:
- prijs. Veel technologieën kosten nog steeds geld;
- vaardigheden. Als we het hebben over vrije software, dan rijst de kwestie van vaardigheden, aangezien vrije software voldoende competentie vereist van de mensen die deze implementeren en exploiteren;
- functioneel. Niet alle services die beschikbaar zijn in de cloud en bijvoorbeeld zijn gebouwd op dezelfde Postgres, hebben dezelfde functies als Postgres On-premises. Dit is een essentiële factor die bekend en begrepen moet worden. Bovendien wordt deze factor belangrijker dan kennis van enkele verborgen mogelijkheden van een enkel DBMS.
Wat wordt er nu van DA/DE verwacht:
- goed begrip van het vakgebied en de applicatiearchitectuur;
- het vermogen om de juiste DBMS-technologie correct te selecteren, rekening houdend met de uit te voeren taak;
- het vermogen om de optimale methode te selecteren voor het implementeren van de geselecteerde technologie in de context van bestaande beperkingen;
- vermogen om gegevensoverdracht en migratie uit te voeren;
- vermogen om geselecteerde oplossingen te implementeren en te exploiteren.
Hieronder voorbeeld gebaseerd op GCP laat zien hoe de keuze voor een of andere technologie voor het werken met data werkt, afhankelijk van de structuur ervan:
Houd er rekening mee dat PostgreSQL niet is opgenomen in het schema, en dit komt omdat het verborgen is onder de terminologie Cloud SQL. En als we bij Cloud SQL komen, moeten we opnieuw een keuze maken:
Opgemerkt moet worden dat deze keuze niet altijd duidelijk is, dus applicatie-ontwikkelaars laten zich vaak leiden door intuïtie.
Totaal:
- Hoe verder je gaat, hoe urgenter de keuzevraag wordt. En zelfs als je alleen naar GCP, managed services en SaaS kijkt, verschijnt enige vermelding van RDBMS pas bij de 4e stap (en daar is Spanner in de buurt). Bovendien verschijnt de keuze voor PostgreSQL in de 5e stap, en daarnaast zijn er ook MySQL en SQL Server, dat wil zeggen Er is van alles, maar je moet kiezen.
- We mogen beperkingen tegen de achtergrond van verleidingen niet vergeten. Eigenlijk wil iedereen een Spanner, maar die is duur. Als gevolg hiervan ziet een typisch verzoek er ongeveer zo uit: “Maak ons alstublieft een Spanner, maar voor de prijs van Cloud SQL zijn jullie professionals!”
Maar wat te doen?
Laten we, zonder te beweren de ultieme waarheid te zijn, het volgende zeggen:
We moeten onze benadering van leren veranderen:
- het heeft geen zin om les te geven op de manier waarop DBA’s voorheen werden onderwezen;
- kennis van één product is niet langer voldoende;
- maar het kennen van tientallen op het niveau van één is onmogelijk.
U moet niet alleen weten hoeveel het product kost, maar:
- gebruiksscenario van de toepassing ervan;
- verschillende inzetmethoden;
- voor- en nadelen van elke methode;
- vergelijkbare en alternatieve producten om een weloverwogen en optimale keuze te maken en niet altijd in het voordeel van een bekend product.
Je moet ook gegevens kunnen migreren en de basisprincipes van integratie met ETL begrijpen.
echte zaak
In het recente verleden was het nodig om een backend te creëren voor een mobiele applicatie. Tegen de tijd dat er aan werd gewerkt, was de backend al ontwikkeld en klaar voor implementatie, en het ontwikkelingsteam heeft ongeveer twee jaar aan dit project besteed. De volgende taken zijn vastgelegd:
- CI/CD bouwen;
- de architectuur beoordelen;
- zet het allemaal in werking.
De applicatie zelf was microservices en de Python/Django-code werd helemaal opnieuw en rechtstreeks in GCP ontwikkeld. Wat de doelgroep betreft, werd aangenomen dat er twee regio's zouden zijn: de VS en de EU, en het verkeer werd gedistribueerd via de Global Load balancer. Alle werklasten en rekenwerklasten werden uitgevoerd op Google Kubernetes Engine.
Wat de gegevens betreft, waren er 3 structuren:
- Cloud opslag;
- Gegevensopslag;
- CloudSQL (PostgreSQL).
Je vraagt je misschien af waarom voor Cloud SQL is gekozen? Eerlijk gezegd heeft een dergelijke vraag de afgelopen jaren voor een soort ongemakkelijke pauze gezorgd - er is een gevoel dat mensen verlegen zijn geworden over relationele databases, maar ze blijven er toch actief gebruik van maken ;-).
In ons geval werd om de volgende redenen voor Cloud SQL gekozen:
- Zoals gezegd is de applicatie ontwikkeld met Django en beschikt deze over een model voor het toewijzen van persistente gegevens uit een SQL-database aan Python-objecten (Django ORM).
- Het raamwerk zelf ondersteunde een tamelijk eindige lijst van DBMS'en:
- PostgreSQL;
- MariaDB;
- MySQL;
- Orakel;
- SQLite.
Dienovereenkomstig werd PostgreSQL nogal intuïtief uit deze lijst gekozen (nou ja, het is eigenlijk niet Oracle om te kiezen).
Wat miste er:
- de applicatie werd slechts in twee regio's ingezet en een derde verscheen in plannen (Azië);
- De database bevond zich in de Noord-Amerikaanse regio (Iowa);
- Aan de kant van de klant waren er zorgen over mogelijk vertragingen bij de toegang uit Europa en Azië en onderbrekingen in dienst in geval van DBMS-downtime.
Ondanks dat Django zelf met meerdere databases parallel kan werken en deze kan opdelen in lezen en schrijven, werd er niet zo veel geschreven in de applicatie (meer dan 90% is lezen). En in het algemeen, en in het algemeen, als het mogelijk was om te doen lees-replica van de belangrijkste basis in Europa en Azië, zou dit een compromisoplossing zijn. Wat is er zo ingewikkeld aan?
Het probleem was dat de klant het gebruik van managed services en Cloud SQL niet wilde opgeven. En de mogelijkheden van Cloud SQL zijn momenteel beperkt. Cloud SQL ondersteunt hoge beschikbaarheid (HA) en Read Replica (RR), maar dezelfde RR wordt slechts in één regio ondersteund. Nadat je een database in de Amerikaanse regio hebt aangemaakt, kun je met Cloud SQL geen leesreplica in de Europese regio maken, al belet Postgres je dit zelf niet. Correspondentie met Google-medewerkers leidde nergens toe en eindigde met beloftes in de stijl van “we kennen het probleem en werken eraan, ooit zal het probleem opgelost worden.”
Als we de mogelijkheden van Cloud SQL kort opsommen, ziet het er ongeveer zo uit:
1. Hoge beschikbaarheid (HA):
- binnen één regio;
- via schijfreplicatie;
- Er worden geen PostgreSQL-engines gebruikt;
- automatische en handmatige bediening mogelijk - failover/failback;
- Bij het overschakelen is het DBMS enkele minuten niet beschikbaar.
2. Replica lezen (RR):
- binnen één regio;
- hete stand-by;
- PostgreSQL-streamingreplicatie.
Bovendien wordt u, zoals gebruikelijk, bij het kiezen van een technologie altijd met een aantal geconfronteerd beperkingen:
- de klant wilde geen entiteiten creëren en IaaS gebruiken, behalve via GKE;
- de klant wil geen selfservice PostgreSQL/MySQL inzetten;
- Over het algemeen zou Google Spanner best geschikt zijn als het niet vanwege de prijs was, maar Django ORM kan er niet mee werken, maar het is een goede zaak.
Gezien de situatie ontving de klant een vervolgvraag: “Kun je iets soortgelijks doen, zodat het lijkt op Google Spanner, maar ook werkt met Django ORM?”
Oplossingsoptie nr. 0
Het eerste wat in me opkwam:
- blijf binnen CloudSQL;
- er zal geen enkele ingebouwde replicatie tussen regio's zijn;
- probeer een replica te koppelen aan een bestaande Cloud SQL van PostgreSQL;
- start ergens en op de een of andere manier een PostgreSQL-instantie, maar raak in ieder geval de master niet aan.
Helaas bleek dat dit niet mogelijk is, omdat er geen toegang is tot de host (deze bevindt zich helemaal in een ander project) - pg_hba enzovoort, en er is ook geen toegang onder superuser.
Oplossingsoptie nr. 1
Na verdere reflectie en rekening houdend met eerdere omstandigheden veranderde de gedachtegang enigszins:
- We proberen nog steeds binnen CloudSQL te blijven, maar we stappen over naar MySQL, omdat Cloud SQL by MySQL een externe master heeft, die:
— is een proxy voor externe MySQL;
- ziet eruit als een MySQL-instantie;
- Uitgevonden voor het migreren van gegevens vanuit andere clouds of on-premises.
Omdat het opzetten van MySQL-replicatie geen toegang tot de host vereist, werkte alles in principe, maar het was erg onstabiel en lastig. En toen we verder gingen, werd het helemaal eng, omdat we de hele structuur met terraform hadden ingezet, en plotseling bleek dat de externe master niet werd ondersteund door terraform. Ja, Google heeft een CLI, maar om de een of andere reden werkte alles hier zo nu en dan - soms is het gemaakt, soms is het niet gemaakt. Misschien omdat de CLI is uitgevonden voor externe datamigratie, en niet voor replica's.
Eigenlijk werd op dit punt duidelijk dat Cloud SQL helemaal niet geschikt is. Zoals ze zeggen, we hebben alles gedaan wat we konden.
Oplossingsoptie nr. 2
Omdat het niet mogelijk was om binnen het Cloud SQL-framework te blijven, hebben we geprobeerd eisen te formuleren voor een compromisoplossing. De eisen bleken de volgende te zijn:
- werken in Kubernetes, maximaal gebruik van resources en mogelijkheden van Kubernetes (DCS, ...) en GCP (LB, ...);
- gebrek aan ballast door een heleboel onnodige dingen in de cloud, zoals HA-proxy;
- de mogelijkheid om PostgreSQL of MySQL in de belangrijkste HA-regio uit te voeren; in andere regio's - HA uit de RR van de hoofdregio plus de kopie ervan (voor betrouwbaarheid);
- multi master (ik wilde geen contact met hem opnemen, maar het was niet erg belangrijk)
.
Als resultaat van deze eisen, pgeschikte DBMS- en bindingsopties:
- MySQL Galera;
- KakkerlakDB;
- PostgreSQL-hulpmiddelen
:
- pgpool-II;
— Patroni.
MySQL Galera
MySQL Galera-technologie is ontwikkeld door Codership en is een plug-in voor InnoDB. Eigenaardigheden:
- multimaster;
- synchrone replicatie;
- lezen vanaf elk knooppunt;
- opnemen op elk knooppunt;
- ingebouwd HA-mechanisme;
- Er is een Helm-kaart van Bitnami.
Kakkerlak DB
Volgens de beschrijving is het ding absoluut een bom en is het een open source-project geschreven in Go. De belangrijkste deelnemer is Cockroach Labs (opgericht door mensen van Google). Dit relationele DBMS is oorspronkelijk ontworpen om te worden gedistribueerd (met horizontale schaalvergroting) en fouttolerant. De auteurs van het bedrijf schetsten het doel om “de rijkdom van SQL-functionaliteit te combineren met de horizontale toegankelijkheid die bekend is bij NoSQL-oplossingen.”
Een leuke bonus is ondersteuning voor het post-gress-verbindingsprotocol.
Pgpool
Dit is een add-on op PostgreSQL, sterker nog, een nieuwe entiteit die alle verbindingen overneemt en verwerkt. Het heeft een eigen load balancer en parser, gelicentieerd onder de BSD-licentie. Het biedt volop mogelijkheden, maar ziet er enigszins eng uit, omdat de aanwezigheid van een nieuwe entiteit de bron van enkele extra avonturen zou kunnen worden.
patroon
Dit is het laatste waar mijn oog op viel, en het bleek niet tevergeefs. Patroni is een open source-hulpprogramma, dat in wezen een Python-daemon is waarmee u automatisch PostgreSQL-clusters kunt onderhouden met verschillende soorten replicatie en automatische rolwisseling. Het ding bleek erg interessant, omdat het goed integreert met de cuber en geen nieuwe entiteiten introduceert.
Waar heb je uiteindelijk voor gekozen?
De keuze was niet eenvoudig:
- Kakkerlak DB - vuur, maar donker;
- MySQL Galera - ook niet slecht, het wordt op veel plaatsen gebruikt, maar MySQL;
- Pgpool — veel onnodige entiteiten, matige integratie met de cloud en K8s;
- patroon - uitstekende integratie met K8s, geen onnodige entiteiten, integreert goed met GCP LB.
De keuze viel dus op Patroni.
Bevindingen
Het is tijd om het kort samen te vatten. Ja, de wereld van de IT-infrastructuur is aanzienlijk veranderd, en dit is nog maar het begin. En als de wolken voorheen gewoon een ander type infrastructuur waren, is alles nu anders. Bovendien verschijnen er voortdurend innovaties in de cloud, ze zullen verschijnen en misschien zullen ze alleen in de cloud verschijnen en pas dan, door de inspanningen van startups, zullen ze worden overgebracht naar On-premises.
Wat SQL betreft, SQL zal blijven bestaan. Dit betekent dat je PostgreSQL en MySQL moet kennen en ermee moet kunnen werken, maar nog belangrijker is dat je ze correct kunt gebruiken.
Bron: www.habr.com