Hallo, Bewohner von Chabrowsk. Der Unterricht in der ersten Gruppe des Kurses beginnt heute . In diesem Zusammenhang möchten wir Ihnen erzählen, wie das offene Webinar zu diesem Kurs abgelaufen ist.
В Wir haben über die Herausforderungen gesprochen, denen SQL-Datenbanken im Zeitalter von Clouds und Kubernetes gegenüberstehen. Gleichzeitig haben wir untersucht, wie sich SQL-Datenbanken unter dem Einfluss dieser Herausforderungen anpassen und verändern.
Das Webinar wurde abgehalten , Google Cloud Practice Delivery Manager bei EPAM Systems.
Als die Bäume klein waren...
Erinnern wir uns zunächst daran, wie die Wahl des DBMS Ende des letzten Jahrhunderts begann. Dies wird jedoch nicht schwierig sein, denn die Wahl eines DBMS begann und endete damals Oracle.
In den späten 90er und frühen 2er Jahren gab es praktisch keine Wahl, wenn es um industriell skalierbare Datenbanken ging. Ja, es gab IBM DBXNUMX, Sybase und einige andere Datenbanken, die kamen und gingen, aber im Allgemeinen fielen sie vor dem Hintergrund von Oracle nicht so auf. Dementsprechend waren die Fähigkeiten der damaligen Ingenieure irgendwie an die einzige Wahlmöglichkeit gebunden, die es gab.
Oracle DBA musste in der Lage sein:
- Installieren Sie Oracle Server aus dem Distributionskit.
- Konfigurieren Sie Oracle Server:
- init.ora;
- listener.ora;
- erstellen:
- Tabellenbereiche;
- Schemata;
- Benutzer;
— Sicherung und Wiederherstellung durchführen;
— Überwachung durchführen;
– mit suboptimalen Anfragen umgehen.
Gleichzeitig gab es keine besonderen Anforderungen von Oracle DBA:
- in der Lage sein, das optimale DBMS oder eine andere Technologie zum Speichern und Verarbeiten von Daten auszuwählen;
- Bereitstellung hoher Verfügbarkeit und horizontaler Skalierbarkeit (dies war nicht immer ein DBA-Problem);
- gute Kenntnisse des Fachgebiets, Infrastruktur, Anwendungsarchitektur, Betriebssystem;
- Daten laden und entladen, Daten zwischen verschiedenen DBMS migrieren.
Wenn wir über die damalige Auswahl sprechen, ähnelt sie im Allgemeinen der Auswahl in einem sowjetischen Laden Ende der 80er Jahre:
Unsere Zeit
Seitdem sind natürlich die Bäume gewachsen, die Welt hat sich verändert und es ist ungefähr so geworden:
Auch der DBMS-Markt hat sich verändert, wie aus dem neuesten Bericht von Gartner deutlich hervorgeht:
Und hier ist anzumerken, dass Clouds, deren Popularität wächst, ihre Nische besetzt haben. Wenn wir denselben Gartner-Bericht lesen, werden wir die folgenden Schlussfolgerungen sehen:
- Viele Kunden sind auf dem Weg, Anwendungen in die Cloud zu verlagern.
- Neue Technologien tauchen zuerst in der Cloud auf und es ist keine Tatsache, dass sie jemals in eine Nicht-Cloud-Infrastruktur übergehen werden.
- Das Pay-as-you-go-Preismodell hat sich durchgesetzt. Jeder möchte nur für das bezahlen, was er verbraucht, und das ist nicht einmal ein Trend, sondern lediglich eine Tatsachenfeststellung.
Was jetzt?
Heute sind wir alle in der Cloud. Und die Fragen, die sich für uns stellen, sind Fragen der Wahl. Und es ist riesig, auch wenn wir nur über die Auswahl an DBMS-Technologien im On-Premises-Format sprechen. Wir bieten auch Managed Services und SaaS an. Somit wird die Wahl von Jahr zu Jahr schwieriger.
Neben Fragen der Wahl gibt es auch limitierende Faktoren:
- Preis. Viele Technologien kosten immer noch Geld;
- навыки. Wenn wir über freie Software sprechen, dann stellt sich die Frage nach den Fähigkeiten, denn freie Software erfordert ausreichende Kompetenz von den Menschen, die sie einsetzen und betreiben;
- funktional. Nicht alle Dienste, die in der Cloud verfügbar sind und beispielsweise auf demselben Postgres basieren, verfügen über dieselben Funktionen wie Postgres On-Premises. Dies ist ein wesentlicher Faktor, der bekannt und verstanden werden muss. Darüber hinaus wird dieser Faktor wichtiger als das Wissen über einige verborgene Fähigkeiten eines einzelnen DBMS.
Was jetzt von DA/DE erwartet wird:
- gutes Verständnis des Fachgebiets und der Anwendungsarchitektur;
- die Fähigkeit, die geeignete DBMS-Technologie unter Berücksichtigung der jeweiligen Aufgabe richtig auszuwählen;
- die Fähigkeit, die optimale Methode zur Implementierung der ausgewählten Technologie im Kontext bestehender Einschränkungen auszuwählen;
- Fähigkeit zur Datenübertragung und -migration;
- Fähigkeit, ausgewählte Lösungen umzusetzen und zu betreiben.
Untenstehendes Beispiel basierend auf GCP zeigt, wie die Wahl der einen oder anderen Technologie für die Arbeit mit Daten je nach ihrer Struktur funktioniert:
Bitte beachten Sie, dass PostgreSQL nicht im Schema enthalten ist, da es unter der Terminologie verborgen ist SQL Cloud. Und wenn wir zu Cloud SQL kommen, müssen wir erneut eine Wahl treffen:
Es ist zu beachten, dass diese Wahl nicht immer klar ist und sich Anwendungsentwickler daher oft von ihrer Intuition leiten lassen.
Total:
- Je weiter man geht, desto drängender wird die Frage der Wahl. Und selbst wenn Sie sich nur GCP, Managed Services und SaaS ansehen, wird RDBMS erst im vierten Schritt erwähnt (und da ist Spanner in der Nähe). Außerdem erscheint im 4. Schritt die Auswahl von PostgreSQL, daneben gibt es nämlich auch MySQL und SQL Server Es gibt von allem viel, aber man muss wählen.
- Wir dürfen Einschränkungen vor dem Hintergrund der Versuchungen nicht vergessen. Grundsätzlich möchte jeder einen Schraubenschlüssel, aber er ist teuer. Im Ergebnis sieht eine typische Anfrage etwa so aus: „Bitte machen Sie uns zu einem Spanner, aber für den Preis von Cloud SQL sind Sie Profis!“
Was ist zu tun?
Ohne den Anspruch zu erheben, die ultimative Wahrheit zu sein, sagen wir Folgendes:
Wir müssen unseren Lernansatz ändern:
- Es macht keinen Sinn, DBAs auf die Art und Weise zu unterrichten, wie es früher der Fall war.
- Kenntnisse über ein Produkt reichen nicht mehr aus;
- Aber Dutzende auf der Ebene von Eins zu kennen, ist unmöglich.
Sie müssen nicht nur wissen, wie viel das Produkt kostet, sondern auch:
- Anwendungsfall seiner Anwendung;
- verschiedene Bereitstellungsmethoden;
- Vor- und Nachteile jeder Methode;
- Vergleichen Sie ähnliche und alternative Produkte, um eine fundierte und optimale Wahl zu treffen und sich nicht immer für ein bekanntes Produkt zu entscheiden.
Sie müssen außerdem in der Lage sein, Daten zu migrieren und die Grundprinzipien der Integration mit ETL zu verstehen.
echter Fall
In der jüngeren Vergangenheit war es notwendig, ein Backend für eine mobile Anwendung zu erstellen. Zu Beginn der Arbeiten war das Backend bereits entwickelt und bereit für die Implementierung, und das Entwicklungsteam verbrachte etwa zwei Jahre mit diesem Projekt. Folgende Aufgaben wurden gestellt:
- CI/CD erstellen;
- Überprüfen Sie die Architektur.
- alles in Betrieb nehmen.
Bei der Anwendung selbst handelte es sich um Microservices, und der Python/Django-Code wurde von Grund auf und direkt in GCP entwickelt. Bezüglich der Zielgruppe wurde davon ausgegangen, dass es zwei Regionen gibt – USA und EU – und der Datenverkehr über den Global Load Balancer verteilt wird. Alle Arbeitslasten und Rechenlasten wurden auf Google Kubernetes Engine ausgeführt.
Was die Daten betrifft, gab es 3 Strukturen:
- Cloud-Speicher;
- Datenspeicher;
- Cloud SQL (PostgreSQL).
Man könnte sich fragen, warum Cloud SQL ausgewählt wurde? Um ehrlich zu sein, hat eine solche Frage in den letzten Jahren zu einer unangenehmen Pause geführt – man hat das Gefühl, dass die Leute gegenüber relationalen Datenbanken schüchtern geworden sind, sie aber dennoch weiterhin aktiv nutzen ;-).
In unserem Fall wurde Cloud SQL aus folgenden Gründen ausgewählt:
- Wie bereits erwähnt, wurde die Anwendung mit Django entwickelt und verfügt über ein Modell zum Zuordnen persistenter Daten aus einer SQL-Datenbank zu Python-Objekten (Django ORM).
- Das Framework selbst unterstützte eine ziemlich begrenzte Liste von DBMS:
- PostgreSQL;
- MariaDB;
- MySQL;
- Oracle
- SQLite.
Dementsprechend wurde PostgreSQL eher intuitiv aus dieser Liste ausgewählt (naja, die Wahl liegt eigentlich nicht bei Oracle).
Was hat gefehlt:
- Die Anwendung wurde nur in zwei Regionen bereitgestellt und eine dritte war in Planung (Asien).
- Die Datenbank befand sich in der nordamerikanischen Region (Iowa);
- Seitens des Kunden gab es Bedenken hinsichtlich möglicher Zugriffsverzögerungen aus Europa und Asien und Unterbrechungen im Dienst im Falle eines DBMS-Ausfalls.
Obwohl Django selbst mit mehreren Datenbanken parallel arbeiten und diese in Lesen und Schreiben aufteilen kann, wurde in der Anwendung nicht so viel geschrieben (mehr als 90 % lesen). Und im Allgemeinen und im Allgemeinen, wenn es möglich wäre Nachbildung der Hauptbasis in Europa und Asien, das wäre eine Kompromisslösung. Nun, was ist daran so kompliziert?
Die Schwierigkeit bestand darin, dass der Kunde nicht auf die Nutzung von Managed Services und Cloud SQL verzichten wollte. Und die Möglichkeiten von Cloud SQL sind derzeit begrenzt. Cloud SQL unterstützt Hochverfügbarkeit (HA) und Read Replica (RR), aber dieselbe RR wird nur in einer Region unterstützt. Nachdem Sie eine Datenbank in der amerikanischen Region erstellt haben, können Sie mit Cloud SQL keine Lesereplikate in der europäischen Region erstellen, obwohl Postgres selbst Sie nicht daran hindert. Die Korrespondenz mit Google-Mitarbeitern führte ins Leere und endete mit Versprechungen im Stil von „Wir kennen das Problem und arbeiten daran, eines Tages wird das Problem gelöst sein.“
Wenn wir die Möglichkeiten von Cloud SQL kurz auflisten, sieht das etwa so aus:
1. Hochverfügbarkeit (HA):
- innerhalb einer Region;
- über Festplattenreplikation;
- PostgreSQL-Engines werden nicht verwendet;
- automatische und manuelle Steuerung möglich – Failover/Failback;
- Beim Wechsel ist das DBMS mehrere Minuten lang nicht verfügbar.
2. Read Replica (RR):
- innerhalb einer Region;
- Hot-Standby;
- PostgreSQL-Streaming-Replikation.
Hinzu kommt, dass man bei der Auswahl einer Technologie wie üblich immer mit einigen konfrontiert wird Einschränkungen:
- Der Kunde wollte keine Entitäten erstellen und IaaS nutzen, außer über GKE.
- Der Kunde möchte kein Self-Service-PostgreSQL/MySQL bereitstellen.
- Nun, im Allgemeinen wäre Google Spanner ohne seinen Preis durchaus geeignet, Django ORM kann damit jedoch nicht arbeiten, aber es ist eine gute Sache.
Angesichts der Situation erhielt der Kunde eine Folgefrage: „Können Sie etwas Ähnliches tun, damit es wie Google Spanner ist, aber auch mit Django ORM funktioniert?“
Lösungsoption Nr. 0
Das erste, was mir in den Sinn kam:
- Bleiben Sie in CloudSQL;
- Es wird keine integrierte Replikation zwischen Regionen in irgendeiner Form geben.
- Versuchen Sie, ein Replikat an ein vorhandenes Cloud SQL by PostgreSQL anzuhängen;
- Starten Sie irgendwo und irgendwie eine PostgreSQL-Instanz, aber berühren Sie Master zumindest nicht.
Leider stellte sich heraus, dass dies nicht möglich ist, da kein Zugriff auf den Host (er befindet sich in einem ganz anderen Projekt) (pg_hba usw.) und auch keinen Zugriff unter Superuser besteht.
Lösungsoption Nr. 1
Nach weiteren Überlegungen und unter Berücksichtigung der bisherigen Umstände änderte sich der Gedankengang etwas:
- Wir versuchen immer noch, innerhalb von CloudSQL zu bleiben, wechseln aber zu MySQL, da Cloud SQL by MySQL über einen externen Master verfügt, der:
– ist ein Proxy für externes MySQL;
- sieht aus wie eine MySQL-Instanz;
– erfunden für die Migration von Daten aus anderen Clouds oder vor Ort.
Da für die Einrichtung der MySQL-Replikation kein Zugriff auf den Host erforderlich ist, funktionierte im Prinzip alles, allerdings war es sehr instabil und umständlich. Und als wir weitergingen, wurde es völlig beängstigend, denn wir stellten die gesamte Struktur mit Terraform bereit und plötzlich stellte sich heraus, dass der externe Master nicht von Terraform unterstützt wurde. Ja, Google hat eine CLI, aber aus irgendeinem Grund hat hier ab und zu alles funktioniert – manchmal wird sie erstellt, manchmal nicht. Vielleicht, weil die CLI für die externe Datenmigration und nicht für Replikate erfunden wurde.
Tatsächlich wurde an dieser Stelle klar, dass Cloud SQL überhaupt nicht geeignet ist. Wie man so schön sagt, haben wir alles getan, was wir konnten.
Lösungsoption Nr. 2
Da es nicht möglich war, innerhalb des Cloud SQL-Frameworks zu bleiben, haben wir versucht, Anforderungen für eine Kompromisslösung zu formulieren. Die Anforderungen stellten sich wie folgt dar:
- Arbeiten in Kubernetes, maximale Nutzung der Ressourcen und Fähigkeiten von Kubernetes (DCS, ...) und GCP (LB, ...);
- Mangel an Ballast durch eine Menge unnötiger Dinge in der Cloud wie HA-Proxy;
- die Möglichkeit, PostgreSQL oder MySQL in der Haupt-HA-Region auszuführen; in anderen Regionen - HA aus dem RR der Hauptregion plus seiner Kopie (aus Gründen der Zuverlässigkeit);
- Multimaster (Ich wollte ihn nicht kontaktieren, aber es war nicht sehr wichtig)
.
Als Ergebnis dieser Forderungen, Sgeeignetes DBMS und Bindungsoptionen:
- MySQL Galera;
- CockroachDB;
- PostgreSQL-Tools
:
- pgpool-II;
– Patroni.
MySQL-Galera
Die MySQL Galera-Technologie wurde von Codership entwickelt und ist ein Plugin für InnoDB. Besonderheiten:
- Multi-Master;
- synchrone Replikation;
- Lesen von jedem Knoten;
- Aufnahme auf einen beliebigen Knoten;
- eingebauter HA-Mechanismus;
- Es gibt ein Helm-Diagramm von Bitnami.
CockroachDB
Laut Beschreibung ist das Ding absolut bombastisch und ein in Go geschriebenes Open-Source-Projekt. Der Hauptteilnehmer ist Cockroach Labs (gegründet von Leuten von Google). Dieses relationale DBMS wurde ursprünglich für die Verteilung (mit sofort einsatzbereiter horizontaler Skalierung) und die Fehlertoleranz entwickelt. Die Autoren des Unternehmens skizzierten das Ziel, „den Reichtum der SQL-Funktionalität mit der horizontalen Zugänglichkeit zu kombinieren, die von NoSQL-Lösungen bekannt ist“.
Ein schöner Bonus ist die Unterstützung des Post-Ggress-Verbindungsprotokolls.
Pgpool
Dabei handelt es sich um ein Add-on zu PostgreSQL, also um eine neue Entität, die alle Verbindungen übernimmt und verarbeitet. Es verfügt über einen eigenen Load Balancer und Parser, lizenziert unter der BSD-Lizenz. Es bietet zahlreiche Möglichkeiten, sieht jedoch etwas beängstigend aus, da die Anwesenheit eines neuen Wesens zur Quelle einiger zusätzlicher Abenteuer werden könnte.
Patron
Das ist das Letzte, worauf mein Blick fiel, und wie sich herausstellte, nicht umsonst. Patroni ist ein Open-Source-Dienstprogramm, bei dem es sich im Wesentlichen um einen Python-Daemon handelt, mit dem Sie PostgreSQL-Cluster mit verschiedenen Replikationstypen und automatischem Rollenwechsel automatisch verwalten können. Das Ding erwies sich als sehr interessant, da es sich gut in den Cuber integrieren lässt und keine neuen Entitäten einführt.
Wofür hast du dich letztendlich entschieden?
Die Wahl war nicht einfach:
- CockroachDB - Feuer, aber dunkel;
- MySQL-Galera - auch nicht schlecht, es wird an vielen Stellen verwendet, aber MySQL;
- Pgpool — viele unnötige Einheiten, mittelmäßige Integration mit der Cloud und K8s;
- Patron - Hervorragende Integration mit K8s, keine unnötigen Einheiten, lässt sich gut in GCP LB integrieren.
Somit fiel die Wahl auf Patroni.
Befund
Es ist Zeit, kurz zusammenzufassen. Ja, die Welt der IT-Infrastruktur hat sich erheblich verändert, und das ist erst der Anfang. Und wenn die Clouds früher nur eine andere Art von Infrastruktur waren, ist jetzt alles anders. Darüber hinaus tauchen ständig Innovationen in den Clouds auf, sie werden erscheinen und vielleicht werden sie nur in den Clouds erscheinen und erst dann durch die Bemühungen von Startups auf On-Premises übertragen.
Was SQL betrifft, wird SQL leben. Das bedeutet, dass Sie PostgreSQL und MySQL kennen und damit arbeiten müssen, aber noch wichtiger ist, sie richtig nutzen zu können.
Source: habr.com