Hallo, Habr-Bewohner. Heute beginnen die Kurse in der ersten Gruppe des Kurses . In diesem Zusammenhang möchten wir Ihnen erzählen, wie das offizielle Webinar zu diesem Kurs verlief.
Im haben wir darüber gesprochen, mit welchen Herausforderungen SQL-Datenbanken in der Ära von Cloud und Kubernetes konfrontiert sind. Außerdem haben wir betrachtet, wie sich SQL-Datenbanken anpassen und verändern, um mit diesen Herausforderungen umzugehen.
Das Webinar wurde geleitet von , Google Cloud Practice Delivery Manager bei EPAM Systems.
Als die Bäume noch klein waren …
Zunächst erinnern wir uns daran, wie die Wahl der DBMS Ende des letzten Jahrhunderts begann. Das sollte kein Problem sein, denn die Wahl der DBMS in jenen Zeiten begann und endete Oracle.
Ende der 90er Jahre – Anfang der 2000er Jahre gab es im Wesentlichen keine große Auswahl, wenn man über industriell skalierbare Datenbanken spricht. Ja, es gab IBM DB2, Sybase und einige andere Datenbanken, die kamen und gingen, aber insgesamt waren sie im Vergleich zu Oracle nicht so auffällig. Dementsprechend waren die Fähigkeiten der Ingenieure damals mehr oder weniger auf die einzige Auswahl angewiesen, die existierte.
Ein Oracle DBA musste in der Lage sein:
- Oracle Server aus dem Distribution zu installieren;
- Oracle Server zu konfigurieren:
- init.ora;
- listener.ora;
– zu erstellen:
- Tabellenräume;
- Schemas;
- Benutzer;
– Backups und Wiederherstellungen durchzuführen;
– Überwachung durchzuführen;
– Mit nicht optimalen Abfragen zu kämpfen.
Dabei wurde von einem Oracle DBA nicht besonders verlangt, dass er:
- die optimale DBMS oder eine andere Technologie zur Speicherung und Verarbeitung von Daten auswählen kann;
- hohe Verfügbarkeit und horizontale Skalierbarkeit sicherstellen kann (das war nicht immer die Aufgabe des DBA);
- das Fachgebiet, die Infrastruktur, die Anwendungsarchitektur und das Betriebssystem gut kennt;
- Daten importieren und exportieren sowie Datenmigration zwischen verschiedenen DBMS durchführen kann.
Im Allgemeinen erinnert die Wahl in jenen Zeiten an die Wahl in einem sowjetischen Geschäft Ende der 80er Jahre:
Unsere Zeit
Seitdem sind die Bäume natürlich gewachsen, die Welt hat sich verändert, und es sieht jetzt so aus:
Auch der Markt der DBMS hat sich verändert, was gut am aktuellen Bericht von Gartner zu erkennen ist:
Und hier sollte man nicht vergessen, dass die Cloud ihre Nische besetzt hat, deren Beliebtheit zunimmt. Wenn man denselben Bericht von Gartner liest, sieht man folgende Schlussfolgerungen:
- Viele Kunden sind dabei, ihre Anwendungen in die Cloud zu migrieren.
- Neue Technologien erscheinen zunächst in der Cloud, und es ist ungewiss, ob sie jemals in eine nicht-cloudbasierte Infrastruktur umziehen werden.
- Das Preismodell nach dem Prinzip 'pay-as-you-go' ist zur Norm geworden. Jeder möchte nur für das bezahlen, was er tatsächlich nutzt, und das ist nicht einmal mehr ein Trend, sondern eine Tatsache.
Was ist jetzt?
Heute sind wir alle in der Cloud. Die Fragen, die wir haben, betreffen die Auswahl. Diese ist enorm, selbst wenn wir nur über die Auswahl von Datenbanktechnologien im On-premises-Format reden. Zudem gibt es Managed Services und SaaS. Somit wird die Wahl mit jedem Jahr komplizierter.
Neben den Auswahlfragen gibt es auch Einschränkungsfaktoren:
- der Preis. Viele Technologien kosten nach wie vor Geld;
- Skills. Wenn wir über Open Source sprechen, stellt sich die Frage nach den Fähigkeiten, denn kostenlose Software erfordert von den Nutzern, die sie implementieren und betreiben, ein gewisses Maß an Kompetenz;
- Funktionalität. Nicht alle Dienste, die in der Cloud verfügbar sind und beispielsweise auf der Basis von Postgres aufgebaut wurden, haben die gleichen Funktionen wie Postgres On-premises. Dies ist ein wesentlicher Faktor, den man wissen und verstehen muss. Darüber hinaus wird dieser Faktor wichtiger als das Wissen über versteckte Möglichkeiten einer bestimmten Datenbank.
Was erwartet man derzeit von DA/DE:
- ein gutes Verständnis des Fachgebiets und der Anwendungsarchitektur;
- die Fähigkeit, die geeignete Datenbanktechnologie unter Berücksichtigung der gestellten Aufgaben korrekt auszuwählen;
- die Fähigkeit, die optimale Umsetzung der gewählten Technologie im Kontext bestehender Einschränkungen zu finden;
- die Fähigkeit, Datenübertragungen und Migrationen durchzuführen;
- die Fähigkeit, die gewählten Lösungen zu implementieren und zu betreiben.
Das folgende Beispiel auf Basis von GCP zeigt, wie die Auswahl der jeweiligen Technologie zur Datenverarbeitung je nach Struktur erfolgt:
Beachten Sie, dass PostgreSQL in diesem Schema nicht vorhanden ist, denn es versteckt sich hinter der Terminologie Cloud SQL. Und wenn wir in Cloud SQL gelangen, müssen wir wieder eine Auswahl treffen:
Es sei angemerkt, dass diese Auswahl nicht immer klar ist, weshalb Entwickler oft auf Intuition angewiesen sind.
Insgesamt:
- Je weiter wir gehen, desto relevanter wird die Frage der Auswahl. Und selbst wenn man nur auf GCP schaut, erscheinen Managed Services und SaaS erst in Schritt 4 (und dort ist Spanner in der Nähe). Darüber hinaus wird PostgreSQL erst in Schritt 5 erwähnt, und daneben stehen noch MySQL und SQL Server, das heißt Es gibt viel, aber man muss auswählen..
- Die Einschränkungen im Angesicht der Versuchungen sollte man nicht vergessen. Im Großen und Ganzen wollen alle Spanner, aber er ist teuer. Am Ende sieht eine typische Anfrage ungefähr so aus: „Bitte machen Sie uns Spanner, aber zu den Preisen von Cloud SQL, Sie sind schließlich Profis!“
Was sollte man also tun?
Ohne den Anspruch auf die letzte Instanz zu erheben, wollen wir Folgendes sagen:
Der Ansatz zur Ausbildung muss geändert werden:
- Es macht keinen Sinn, wie früher DBA auszubilden;
- Kenntnisse über ein Produkt reichen jetzt nicht mehr aus;
- und es ist unmöglich, dutzende auf dem Niveau eines zu kennen.
Man muss nicht nur das Produkt kennen, sondern auch:
- den Anwendungsfall;
- verschiedene Bereitstellungsmethoden;
- die Vor- und Nachteile jeder Methode;
- vergleichbare und alternative Produkte, um eine informierte und optimale Wahl zu treffen und nicht immer zum gewohnten Produkt zu greifen.
Und man muss auch in der Lage sein, Daten zu migrieren und die grundlegenden Prinzipien der Integration mit ETL zu verstehen.
Ein praktischer Fall
In der jüngeren Vergangenheit war es erforderlich, ein Backend für eine mobile Anwendung zu erstellen. Zum Zeitpunkt des Beginns der Arbeit an dieser war das Backend bereits entwickelt und bereit zur Implementierung, und das Entwicklerteam hatte etwa zwei Jahre für dieses Projekt aufgewendet. Dabei wurden folgende Aufgaben festgelegt:
- CI/CD aufbauen;
- Architektur-Review durchführen;
- alles in Betrieb nehmen.
Die Anwendung selbst war mikroservicebasiert, und der Code in Python/Django wurde von Grund auf neu und direkt in GCP entwickelt. Was die Zielgruppe betrifft, so wurde angenommen, dass es zwei Regionen geben würde - USA und EU, und der Traffic wurde über den Global Load Balancer verteilt. Alle Workloads und Rechenlasten arbeiteten in Google Kubernetes Engine.
Was die Daten betrifft, gab es drei Strukturen:
- Cloud Storage;
- Datastore;
- Cloud SQL (PostgreSQL).
Es könnte die Frage aufkommen, warum Cloud SQL gewählt wurde? Ehrlich gesagt, eine solche Frage verursacht in den letzten Jahren eine gewisse peinliche Pause - es scheint, dass die Leute zögerten, relationale Datenbanken zu verwenden, aber sie nutzen sie dennoch aktiv ;-).
In unserem Fall wurde Cloud SQL aus folgenden Gründen gewählt:
- Wie bereits erwähnt, wurde die Anwendung mit Django entwickelt, und darin gibt es ein Modell zur Abbildung dauerhafter Daten aus der SQL-Datenbank in Python-Objekte (Django ORM).
- Das Framework unterstützte eine recht endliche Liste von DBMS:
- PostgreSQL;
- MariaDB;
- MySQL;
- Oracle;
- SQLite.
In diesem Sinne wurde PostgreSQL eher intuitiv aus dieser Liste gewählt (na, man wählt schließlich nicht Oracle).
Was fehlte:
- Die Anwendung wurde nur in 2 Regionen bereitgestellt, und ein dritter (Asien) steht in den Plänen.
- Die Datenbank befand sich in der nordamerikanischen Region (Iowa).
- Es gab Bedenken seitens des Kunden hinsichtlich möglicher Zugriffsverzögerungen aus Europa und Asien sowie Unterbrechungen im Dienst im Falle eines Ausfalls der Datenbank.
Obwohl Django in der Lage ist, mehrere Datenbanken parallel zu betreiben und sie nach Lese- und Schreibvorgängen zu trennen, waren die Schreiboperationen in der Anwendung nicht besonders zahlreich (über 90 % der Vorgänge waren Lesevorgänge). Insgesamt, wenn es möglich gewesen wäre eine Read Replica der Hauptdatenbank in Europa und Asien zu erstellen,wäre das eine kompromissbereite Lösung gewesen. Aber was wäre daran so schwierig?
Das Problem lag darin, dass der Kunde nicht auf die Verwendung von Managed Services und Cloud SQL verzichten wollte. Die Möglichkeiten von Cloud SQL sind derzeit jedoch eingeschränkt. Cloud SQL unterstützt Hochverfügbarkeit (HA) und Read Replica (RR), aber die RR wird nur in einer Region unterstützt. Wenn eine Datenbank in der amerikanischen Region erstellt wird, kann eine Read Replica in der europäischen Region mit den Mitteln von Cloud SQL nicht erstellt werden, obwohl PostgreSQL dies nicht einschränkt. Der Schriftverkehr mit Google-Mitarbeitern brachte nichts und endete mit Versprechen, die in etwa lauteten: 'Wir kennen das Problem und arbeiten daran, irgendwann wird die Frage gelöst.'
Wenn man die Möglichkeiten von Cloud SQL stichpunktartig aufzählt, dann sieht das ungefähr so aus:
1. Hochverfügbarkeit (HA):
- innerhalb einer Region;
- durch Diskreplication;
- es werden keine PostgreSQL-Mechanismen verwendet;
- es ist eine automatische und manuelle Steuerung möglich - Failover/Fallback;
- bei einem Wechsel ist die Datenbank für mehrere Minuten nicht verfügbar.
2. Read Replica (RR):
- innerhalb einer Region;
- hot standby;
- PostgreSQL Streaming-Replikation.
Außerdem stößt man bei der Wahl der Technologie immer auf irgendwelche Einschränkungen;:
- der Kunde wollte keine Entitäten erzeugen und IaaS nur über GKE nutzen;
- der Kunde wollte keine Selbstbedienungs-Version von PostgreSQL/MySQL bereitstellen;
- und generell würde Google Spanner gut passen, wenn er nicht so teuer wäre, allerdings kann Django ORM nicht damit arbeiten, aber ansonsten ist es ein gutes Produkt.
Angesichts der Situation stellte der Kunde eine herausfordernde Frage: "Können Sie etwas Ähnliches erstellen, das wie Google Spanner funktioniert, aber auch mit Django ORM funktioniert?"
Lösungsansatz Nr. 0
Das Erste, was mir in den Sinn kam:
- im Rahmen von CloudSQL zu bleiben;
- Es wird keine integrierte Replikation zwischen Regionen in irgendeiner Form geben;
- Versuchen, eine Replikation an die bestehende Cloud SQL by PostgreSQL anzuschließen;
- irgendwo und irgendwie eine PostgreSQL-Instanz zu starten, aber zumindest das Master nicht anzufassen.
Leider stellte sich heraus, dass dies nicht möglich ist, da kein Zugriff auf den Host besteht (er ist überhaupt in einem anderen Projekt) – pg_hba und so weiter, und es gibt auch keinen Zugriff als Superuser.
Lösungsvorschlag Nr. 1
Nach weiteren Überlegungen und unter Berücksichtigung der vorherigen Umstände hat sich der Gedankengang etwas geändert:
- wir versuchen immer noch, im Rahmen von CloudSQL zu bleiben, wechseln aber auf MySQL, da Cloud SQL by MySQL einen externen Master hat, der:
– als Proxy für externes MySQL fungiert;
– wie eine MySQL-Instanz aussieht;
– für die Migration von Daten aus anderen Clouds oder On-premises gedacht ist.
Da die Einrichtung der MySQL-Replikation keinen Zugriff auf den Host erfordert, funktionierte grundsätzlich alles, war aber sehr instabil und unangenehm. Als wir weitergingen, wurde es sogar beängstigend, da wir die gesamte Struktur mit Terraform aufbauten und plötzlich herausfanden, dass der externe Master nicht von Terraform unterstützt wird. Ja, Google hat ein CLI, aber aus irgendeinem Grund funktionierte alles auch hier nur gelegentlich – manchmal wurde es erstellt, manchmal nicht. Vielleicht, weil das CLI für die Migration von Daten von außen gedacht war, nicht für Replikate.
Eigentlich wurde damit klar, dass Cloud SQL überhaupt nicht geeignet ist. Wie gesagt, wir haben alles versucht, was wir konnten.
Lösungsvorschlag Nr. 2
Da es nicht gelungen ist, im Rahmen von Cloud SQL zu bleiben, haben wir versucht, Anforderungen für eine Kompromisslösung zu formulieren. Die Anforderungen waren die folgenden:
- Arbeiten in Kubernetes, maximale Nutzung von Ressourcen und Möglichkeiten von Kubernetes (DCS, …) und GCP (LB, …);
- Fehlen von Ballast aus einer Menge unnötiger Dinge in der Cloud wie HA Proxy;
- Möglichkeit, in der Hauptregion HA PostgreSQL oder MySQL zu starten; in den anderen Regionen – HA aus der Hauptregion plus deren Kopie (für die Zuverlässigkeit);
- Multi-Master (es war nicht unbedingt wünschenswert, damit zu interagieren, aber nicht sehr entscheidend)
.
Als Ergebnis dieser Anforderungen erschienen schließlich geeignete DBMS-Optionen am HorizontMySQL 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;
- synchronous replication;
- lesen von jedem Knoten;
- schreiben auf jeden Knoten;
- eingebauter HA-Mechanismus;
- es gibt ein Helm-Chart von Bitnami.
- есть Helm chart от Bitnami.
CockroachDB
Nach der Beschreibung handelt es sich um ein absolut fantastisches Produkt, das ein Open-Source-Projekt ist und in Go geschrieben wurde. Der Hauptbeteiligte ist Cockroach Labs (gegründet von ehemaligen Google-Mitarbeitern). Diese relationale Datenbank wurde ursprünglich als verteilte Datenbank (mit horizontaler Skalierung „out of the box“) und Fehlertoleranz entwickelt. Die Autoren des Unternehmens haben das Ziel gesetzt, „die Funktionalität von SQL mit der horizontalen Verfügbarkeit, die man von NoSQL-Lösungen kennt, zu kombinieren.“
Ein angenehmer Bonus ist die Unterstützung des PostgreSQL-Verbindungsprotokolls.
Pgpool
Es handelt sich um eine Schicht über PostgreSQL, tatsächlich um eine neue Entität, die alle Verbindungen übernimmt und diese verarbeitet. Sie hat einen eigenen Lastenausgleich und Parser und wird unter der BSD-Lizenz lizenziert. Sie bietet umfangreiche Möglichkeiten, sieht jedoch etwas einschüchternd aus, da das Vorhandensein einer neuen Entität zusätzliche Herausforderungen mit sich bringen könnte.
Patroni
Dies ist das Letzte, was ins Auge gefallen ist, und wie sich herausstellte, zu Recht. Patroni ist ein Open-Source-Tool, das im Grunde ein Daemon in Python ist, der es ermöglicht, PostgreSQL-Cluster mit verschiedenen Replikationstypen und automatischem Rollenwechsel automatisch zu verwalten. Die Sache ist sehr interessant, da es gut mit Kubernetes integriert ist und keine neuen Entitäten mit sich bringt.
Was letztendlich gewählt wurde
Die Wahl fiel nicht leicht:
- CockroachDB — großartig, aber beängstigend;
- Die MySQL Galera-Technologie wurde von Codership entwickelt und ist ein Plugin für InnoDB. Besonderheiten: — auch nicht schlecht, wird oft genutzt, aber MySQL;
- Pgpool — viele überflüssige Entitäten, die Integration mit der Cloud und K8s mittelmäßig;
- Patroni — hervorragende Integration mit K8s, keine überflüssigen Entitäten, gut integriert mit GCP LB.
Somit fiel die Wahl auf Patroni.
Das DBMS Tarantool ist ein attraktives, zukunftsträchtiges Produkt zur Erstellung von hochbelasteten Anwendungen.
Es ist an der Zeit, eine kurze Zusammenfassung zu ziehen. Ja, die Welt der IT-Infrastruktur hat sich erheblich verändert, und das ist erst der Anfang. Wenn früher Clouds nur eine andere Art von Infrastruktur waren, ist es jetzt ganz anders. Darüber hinaus entstehen ständig Innovationen in der Cloud, und sie werden wahrscheinlich nur in der Cloud entstehen und dann, durch Start-ups, in On-Premises übertragen.
Was SQL betrifft, so wird SQL weiterleben. Das bedeutet, dass man PostgreSQL und MySQL kennen und damit arbeiten können muss, aber noch wichtiger ist, dass man lernt, sie richtig anzuwenden.
Quelle: habr.com
