Auf dem Weg zu serverlosen Datenbanken – wie und warum

Hallo zusammen! Mein Name ist Nikolaj Golow. Früher habe ich bei Avito gearbeitet und sechs Jahre die Datenplattform geleitet, das heißt, ich habe mich um alle Datenbanken gekümmert: analytische (Vertica, ClickHouse), Streaming und OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). In dieser Zeit habe ich mich mit einer Vielzahl von Datenbanken auseinander gesetzt – die verschiedensten und unkonventionellsten, sowie mit speziellen Anwendungsfällen.

Derzeit arbeite ich bei ManyChat. Im Grunde handelt es sich um ein Startup – neu, ehrgeizig und schnell wachsend. Und als ich gerade in das Unternehmen gekommen bin, stellte sich die klassische Frage: „Was sollte man jetzt für ein junges Startup im Bereich DBMS und Datenbanken vom Markt nehmen?“

In diesem Artikel, der auf meinem Vortrag basiert, beim Online-Festival RIT++2020, werde ich diese Frage beantworten. Die Videoaufzeichnung des Vortrags ist verfügbar unter YouTube.

Allseits bekannte Datenbanken des Jahres 2020

Es ist das Jahr 2020, ich habe mich umgeschaut und drei Typen von Datenbanken gesehen.

Der erste Typ — klassische OLTP-Datenbanken: PostgreSQL, SQL Server, Oracle, MySQL. Sie wurden vor langer Zeit geschrieben, sind aber immer noch relevant, weil sie der Entwicklergemeinschaft gut bekannt sind.

Der zweite Typ — Datenbanken aus den „Nullern“. Sie versuchten, sich von klassischen Mustern zu lösen, indem sie auf SQL, traditionelle Strukturen und ACID verzichteten, durch die Einführung von eingebautem Sharding und anderen attraktiven Funktionen. Beispiele hierfür sind Cassandra, MongoDB, Redis oder Tarantool. All diese Lösungen wollten dem Markt etwas grundlegend Neues bieten und fanden ihren Platz, weil sie sich in bestimmten Aufgaben als äußerst praktisch erwiesen. Diese Datenbanken bezeichne ich als Sammelbegriff NOSQL.

Die „Nuller“ sind vorbei, die NOSQL-Datenbanken sind akzeptiert worden, und die Welt hat aus meiner Sicht den nächsten Schritt gemacht — zu verwalteten Datenbanken.Ihre Kerntechnologie ist die gleiche wie die von klassischen OLTP-Datenbanken oder neuen NoSQL-Datenbanken. Aber sie benötigen keine DBA und DevOps und laufen auf verwalteter Hardware in der Cloud. Für den Entwickler ist das „einfach eine Datenbank“, die irgendwo funktioniert, und wie sie auf dem Server installiert ist, wer den Server konfiguriert hat und wer ihn aktualisiert, interessiert niemanden.

Beispiele für solche Datenbanken:

• AWS RDS — eine verwaltete Schicht über PostgreSQL/MySQL.
• DynamoDB — der AWS-Ableger einer dokumentenbasierten Datenbank, ähnlich wie Redis und MongoDB.
• Amazon Redshift — eine verwaltete analytische Datenbank.

Im Grunde sind das alte Datenbanken, aber in einer verwalteten Umgebung, ohne dass mit Hardware gearbeitet werden muss.

Hinweis. Die Beispiele beziehen sich auf die AWS-Umgebung, aber auch ihre Alternativen gibt es in Microsoft Azure, Google Cloud oder Yandex.Cloud.

Was ist also neu daran? Im Jahr 2020 nichts davon.

Das Konzept von Serverless

Tatsächlich neu auf dem Markt im Jahr 2020 sind Serverless- oder cloudlose Lösungen.

Ich werde versuchen zu erklären, was das bedeutet, am Beispiel eines normalen Services oder Backend-Anwendung.
Um eine normale Backend-Anwendung bereitzustellen, kaufen oder mieten wir einen Server, kopieren den Code darauf, veröffentlichen einen externen Endpunkt und zahlen regelmäßig für Miete, Strom und die Dienste des Rechenzentrums. Das ist das Standardverfahren.

Gibt es eine andere Möglichkeit? Mit Serverless-Services ja.

Worin liegt der Fokus dieses Ansatzes: Kein Server, nicht einmal die Miete eines virtuellen Instances in der Cloud. Um den Service bereitzustellen, kopieren wir den Code (Funktionen) in ein Repository und veröffentlichen den externen Endpunkt. Danach zahlen wir einfach für jeden Aufruf dieser Funktion und ignorieren dabei die Hardware, auf der sie ausgeführt wird.

Ich werde versuchen, diesen Ansatz mit Bildern zu veranschaulichen.


Klassisches Deployment. Wir haben einen Service mit einer bestimmten Last. Wir betreiben zwei Instanzen: physische Server oder Instanzen in AWS. An diese Instanzen werden externe Anfragen weitergeleitet, die dort verarbeitet werden.

Wie auf dem Bild zu sehen ist, sind die Server unterschiedlich ausgelastet. Einer ist zu 100 % ausgelastet, dort gibt es zwei Anfragen, der andere nur zu 50 % — er steht teilweise still. Wenn nicht drei Anfragen, sondern 30 kommen, kann das gesamte System mit der Last nicht umgehen und beginnt zu stocken.

Serverless Deployment. In einer serverlosen Umgebung hat ein solcher Service keine Instanzen und Server. Es gibt einen Pool von vorgeheizten Ressourcen — kleinen vorbereiteten Docker-Containern mit dem bereitgestellten Funktionscode. Das System erhält externe Anfragen und für jede von ihnen startet das serverlose Framework einen kleinen Container mit dem Code: es verarbeitet genau diese Anfrage und zerstört den Container.

Eine Anfrage — ein gestarteter Container, 1000 Anfragen — 1000 Container. Und das Deployment auf physischer Hardware ist bereits die Aufgabe des Cloud-Anbieters. Es wird vollständig vom serverlosen Framework verborgen. In diesem Konzept zahlen wir für jeden Aufruf. Zum Beispiel, wenn eine Anfrage pro Tag kommt — wir haben für einen Aufruf bezahlt, wenn eine Million pro Minute kommt — wir haben für eine Million bezahlt. Oder pro Sekunde, das kommt auch vor.

Das Konzept der Veröffentlichung einer serverlosen Funktion eignet sich für einen zustandslosen Dienst. Wenn Sie jedoch einen zustandsbehafteten Dienst benötigen, fügen wir der Dienstleistung eine Datenbank hinzu. In diesem Fall, wenn es um den Umgang mit dem Zustand geht, schreibt und liest jede zustandsbehaftete Funktion einfach aus der Datenbank. Dabei kann es sich um eine Datenbank eines der drei Typen handeln, die zu Beginn des Artikels beschrieben wurden.

Was ist die allgemeine Einschränkung all dieser Datenbanken? Es sind die Kosten für einen ständig genutzten Cloud- oder physikalischen Server (oder mehrere Server). Es spielt keine Rolle, ob wir eine klassische Datenbank oder eine verwaltete verwenden, ob ein DevOps- und ein Administrator vorhanden sind oder nicht, wir zahlen dennoch 24/7 für die Hardware, den Strom und die Miete des Rechenzentrums. Wenn wir eine klassische Datenbank haben, zahlen wir für Master und Slave. Bei einer hochbelasteten, sharded Datenbank zahlen wir für 10, 20 oder 30 Server und das kontinuierlich.

Die Tatsache, dass in der Kostenstruktur ständig reservierte Server vorhanden sind, wurde früher als unvermeidliches Übel angesehen. Gewöhnliche Datenbanken haben auch andere Herausforderungen, wie zum Beispiel Limits für die Anzahl der Verbindungen, Skalierungsbeschränkungen, georedundante Konsensbildung — diese können in bestimmten Datenbanken irgendwie gelöst werden, aber nicht alle auf einmal und nicht perfekt.

Serverlose Datenbank — Theorie

Die Frage des Jahres 2020: Kann man auch eine Datenbank serverlos gestalten? Jeder hat von einem serverlosen Backend gehört... wie wäre es, auch eine Datenbank serverlos zu machen?

Es klingt seltsam, denn eine Datenbank ist schließlich ein zustandsbehafteter Dienst, der nicht wirklich für serverlose Infrastrukturen geeignet ist. Dabei ist der Zustand einer Datenbank sehr groß: Gigabytes, Terabytes und in analytischen Datenbanken sogar Petabytes. So einfach lässt sich das nicht in leichten Docker-Containern umsetzen.

Andererseits basieren nahezu alle modernen Datenbanken auf einer großen Menge an Logik und Komponenten: Transaktionen, Konsistenz, Verfahren, relationale Abhängigkeiten und viel Logik. Ein beträchtlicher Teil der Logik einer Datenbank benötigt oft nur einen kleinen Zustand. Gigabytes und Terabytes werden nur von einem kleinen Teil der Logik der Datenbank beansprucht, die mit der direkten Ausführung von Anfragen zu tun hat.

Dementsprechend die Idee: Wenn ein Teil der Logik ein zustandsloses Ausführen zulässt, warum nicht die Datenbank in zustandsbehaftete und zustandslose Teile aufteilen.

Serverlos für OLAP-Lösungen

Schauen wir uns praktische Beispiele an, wie eine Aufteilung einer Datenbank in zustandsbehaftete und zustandslose Teile aussehen könnte.

Zum Beispiel haben wir eine analytische Datenbank.: externe Daten (roter Zylinder links), ETL-Prozess, der Daten in die Datenbank lädt, und ein Analyst, der SQL-Abfragen an die Datenbank sendet. Dies ist das klassische Schema für die Arbeit mit einem Data Warehouse.

In diesem Schema wird ETL bedingt einmal ausgeführt. Danach müssen wir ständig für die Server zahlen, auf denen die Datenbank mit den durch ETL geladenen Daten läuft, damit wir Anfragen stellen können.

Betrachten wir einen alternativen Ansatz, der in der AWS Athena Serverless-Datenbank umgesetzt ist. Hier gibt es keine ständig zugewiesene Hardware, auf der die geladenen Daten gespeichert werden. Stattdessen:

• Der Benutzer sendet eine SQL-Abfrage an Athena. Der Optimierer von Athena analysiert die SQL-Abfrage und sucht im Metadaten-Speicher nach den spezifischen Daten, die für die Ausführung der Abfrage benötigt werden.
• Der Optimierer lädt basierend auf den gesammelten Daten die benötigten Daten aus externen Quellen in einen temporären Speicher (temporäre Datenbank) herunter.
• Im temporären Speicher wird die SQL-Abfrage des Benutzers ausgeführt, das Ergebnis wird an den Benutzer zurückgegeben.
• Der temporäre Speicher wird geleert, Ressourcen werden freigegeben.

In dieser Architektur zahlen wir nur für den Prozess der Abfrageausführung. Keine Abfragen – keine Kosten.

Dies ist ein funktionierender Ansatz und wird nicht nur in Athena Serverless, sondern auch in Redshift Spectrum (in AWS) umgesetzt.

Am Beispiel von Athena ist zu sehen, dass die Serverless-Datenbank mit echten Abfragen von Dutzenden und Hunderten von Terabyte Daten arbeitet. Für Hunderte Terabyte werden Hunderte von Servern benötigt, aber wir müssen nicht dafür bezahlen – wir zahlen für die Abfragen. Die Geschwindigkeit jeder Abfrage ist (sehr) langsam im Vergleich zu spezialisierten analytischen Datenbanken wie Vertica, aber wir bezahlen auch nicht für Stillstandszeiten.

Solch eine Datenbank ist für seltene analytische Ad-hoc-Abfragen anwendbar. Zum Beispiel, wenn wir spontan entscheiden, eine Hypothese an einem riesigen Datenvolumen zu überprüfen. Für diese Fälle eignet sich Athena perfekt. Für regelmäßige Abfragen wird ein solches System teuer. In diesem Fall sollten Sie die Daten in einer speziellen Lösung cachen.

Serverless für OLTP-Lösungen.

Im vorherigen Beispiel wurden OLAP-Aufgaben (analytische) betrachtet. Jetzt betrachten wir OLTP-Aufgaben.

Stellen wir uns ein skalierbares PostgreSQL oder MySQL vor. Lassen Sie uns eine gewöhnliche verwaltete Instanz von PostgreSQL oder MySQL mit minimalen Ressourcen einrichten. Wenn die Instanz mehr Last erhält, werden wir zusätzliche Replikate verbinden, auf die wir einen Teil der Lese-Last verteilen. Gibt es keine Anfragen und keine Last, schalten wir die Replikate ab. Die erste Instanz ist der Master, die anderen sind Replikate.

Diese Idee ist in einer Datenbank namens Aurora Serverless AWS umgesetzt. Das Prinzip ist einfach: Die Anfragen von externen Anwendungen nimmt ein Proxy-Fleet entgegen. Bei steigender Last stellt es Rechenressourcen aus vorgewärmten minimalen Instanzen bereit – die Verbindung erfolgt so schnell wie möglich. Das Ausschalten der Instanzen geschieht ebenso.

Innerhalb von Aurora gibt es das Konzept der Aurora Capacity Unit, ACU. Dies ist (nennen wir es so) eine Instanz (Server). Jede spezifische ACU kann Master oder Slave sein. Jede Capacity Unit verfügt über ihren eigenen Arbeitsspeicher, Prozessor und minimalen Speicherplatz. Folglich gibt es ein Master-Exemplar, die anderen sind nur read-only Replikate.

Die Anzahl dieser aktiven Aurora Capacity Units ist ein einstellbarer Parameter. Die Mindestanzahl kann eins oder null sein (in diesem Fall funktioniert die Datenbank nicht, wenn keine Anfragen vorliegen).

Wenn die Datenbank Anfragen erhält, hebt das Proxy-Fleet Aurora Capacity Units an, um die Leistung der Ressourcen des Systems zu erhöhen. Die Möglichkeit, Ressourcen zu vergrößern und zu verringern, erlaubt es dem System, mit Ressourcen zu „jonglieren“: automatisch einzelne ACUs anzuschalten (indem sie durch neue ersetzt werden) und auf die abgeschalteten Ressourcen alle aktuellen Updates anzuwenden.

Die Aurora Serverless-Datenbank kann die Lese-Last skalieren. Aber in der Dokumentation wird dies nicht direkt gesagt. Es könnte der Eindruck entstehen, dass sie ein Multi-Master-Setup herstellen können. Doch es gibt kein Magie.

Diese Datenbank eignet sich gut, um nicht viel Geld für Systeme mit unvorhersehbarem Zugriff auszugeben. Beispielsweise erwarten wir bei der Erstellung eines MVP oder von Marketing-Visitenkarten-Webseiten normalerweise keine stabile Last. Entsprechend bezahlen wir bei fehlendem Zugriff nicht für Instanzen. Wenn unerwartet eine Last entsteht, wie nach einer Konferenz oder Werbekampagne, strömen die Menschen auf die Seite und die Last steigt sprunghaft an, Aurora Serverless nimmt diese Last automatisch an und bindet schnell fehlende Ressourcen (ACU) hinzu. Nach der Konferenz ist das interessiertes Publikum vergessen, die Server (ACU) werden abgeschaltet und die Ausgaben sinken auf Null – praktisch.

Diese Lösung eignet sich nicht für stabile Hochlast, da sie nicht in der Lage ist, die schreibenden Lasten zu skalieren. All diese Verbindungen und Abschaltungen von Ressourcen geschehen im sogenannten „Skalierungspunkt“ – einem Zeitpunkt, an dem die Datenbank nicht durch eine Transaktion gehalten wird und temporäre Tabellen nicht genutzt werden. Beispielsweise kann es innerhalb einer Woche keinen Skalierungspunkt geben, und die Datenbank arbeitet einfach mit den gleichen Ressourcen und kann sich nicht erweitern oder verkleinern.

Es gibt keinen Zauber – es ist einfach nur PostgreSQL. Aber der Prozess der Hinzufügung von Maschinen und der teilweisen Automatisierung der Abschaltung ist automatisiert.

Serverless by design

Aurora Serverless ist eine alte Datenbank, die für die Cloud umgeschrieben wurde, um die spezifischen Vorteile von Serverless zu nutzen. Jetzt erzähle ich von einer Datenbank, die von Grund auf für die Cloud und den serverless Ansatz entwickelt wurde – Serverless-by-design. Sie wurde sofort ohne die Annahme entwickelt, dass sie auf physischen Servern arbeitet.

Diese Datenbank heißt Snowflake. Sie besteht aus drei Schlüsselkomponenten.

Die erste ist der Metadatenblock. Dies ist ein schneller In-Memory-Service, der Fragen zu Sicherheit, Metadaten, Transaktionen und Anfrageoptimierung löst (in der Abbildung links).

Der zweite Block ist eine Vielzahl von virtuellen Rechenclustern für Berechnungen (in der Abbildung – eine Ansammlung blauer Kreise).

Der dritte Block ist ein Speichersystem auf Basis von S3. S3 ist ein unbegrenzter Objektspeicher in AWS, ähnlich einem unbegrenzten Dropbox für Unternehmen.

Lassen Sie uns anschauen, wie Snowflake funktioniert, unter der Annahme eines Kaltstarts. Das heißt, die Datenbank existiert, die Daten wurden hochgeladen, es gibt keine aktiven Abfragen. Folglich, wenn es keine Abfragen an die Datenbank gibt, haben wir einen schnellen in-memory Metadata Service (der erste Block) aktiviert. Und wir haben ein S3-Speicher, in dem die Tabellendaten in sogenannten Mikropartitionen gespeichert sind. Zur Vereinfachung: Wenn in der Tabelle Transaktionen gespeichert sind, dann sind Mikropartitionen die Tage der Transaktionen. Jeder Tag ist eine separate Mikropartition, eine separate Datei. Und wenn die Datenbank in diesem Modus läuft, zahlen Sie nur für den Platz, den die Daten einnehmen. Dabei ist der Tarif für den Platz sehr niedrig (insbesondere unter Berücksichtigung der erheblichen Kompression). Der Metadata Service läuft ebenfalls kontinuierlich, aber für die Optimierung von Abfragen werden nicht viele Ressourcen benötigt, und der Service kann als bedingt kostenlos betrachtet werden.

Stellen wir uns nun vor, dass ein Benutzer zu unserer Datenbank kommt und eine SQL-Abfrage eingibt. Die SQL-Abfrage wird sofort zur Verarbeitung an den Metadata Service gesendet. Folglich analysiert dieser Service die Abfrage, die verfügbaren Daten, die Berechtigungen des Benutzers, und wenn alles in Ordnung ist, erstellt er einen Verarbeitungsplan für die Abfrage.

Dann initiiert der Service den Start des Rechenclusters. Ein Rechencluster ist ein Cluster von Servern, die Berechnungen durchführen. Das heißt, es ist ein Cluster, das aus 1, 2, 4, 8, 16, 32 Servern bestehen kann – so viele, wie Sie möchten. Sie senden die Abfrage und sofort beginnt der Start dieses Clusters. Das dauert tatsächlich nur Sekunden.

Nachdem der Cluster gestartet wurde, beginnen die Mikropartitionen, die für die Bearbeitung Ihrer Anfrage benötigt werden, aus S3 in den Cluster kopiert zu werden. Das bedeutet, stellen wir uns vor, dass für die Ausführung einer SQL-Anfrage zwei Partitionen aus einer Tabelle und eine aus einer anderen benötigt werden. In diesem Fall werden nur die drei benötigten Partitionen in den Cluster kopiert, nicht alle Tabellen vollständig. Genau aus diesem Grund und weil alles innerhalb eines einzigen Rechenzentrums ist und mit sehr schnellen Kanälen verbunden ist, erfolgt der gesamte Prozess der Datenübertragung sehr schnell: innerhalb von Sekunden, sehr selten innerhalb von Minuten, es sei denn, es handelt sich um monströse Anfragen. Entsprechend werden die Mikropartitionen in den Rechencluster kopiert, und nach Abschluss wird die SQL-Anfrage auf diesem Rechencluster ausgeführt. Das Ergebnis dieser Anfrage kann eine Zeile, mehrere Zeilen oder eine Tabelle sein – sie werden an den Benutzer gesendet, damit er sie exportieren, in seinem BI-Tool anzeigen oder anderweitig nutzen kann.

Jede SQL-Anfrage kann nicht nur Aggregate aus zuvor geladenen Daten berechnen, sondern auch neue Daten in die Datenbank laden/erstellen. Das heißt, es kann sich um eine Anfrage handeln, die beispielsweise neue Einträge in eine andere Tabelle einfügt, was zur Schaffung einer neuen Partition im Rechencluster führt, die wiederum automatisch im gemeinsamen S3-Speicher gespeichert wird.

Das oben beschriebene Szenario, vom Eintreffen des Benutzers bis zum Hochfahren des Clusters, Laden der Daten, Ausführen von Anfragen und Erhalten von Ergebnissen, wird nach einem Tarif pro Minute der Nutzung des hochgefahrenen virtuellen Rechenclusters, des virtuellen Warehouses, abgerechnet. Der Tarif variiert je nach AWS-Zone und Clustergröße, beträgt aber im Durchschnitt einige Dollar pro Stunde. Ein Cluster mit vier Maschinen kostet doppelt so viel wie eines mit zwei Maschinen, eines mit acht Maschinen kostet noch einmal doppelt so viel. Optionen mit 16, 32 Maschinen sind je nach Komplexität der Anfragen verfügbar. Aber Sie zahlen nur für die Minuten, in denen der Cluster tatsächlich arbeitet, denn wenn keine Anfragen vorliegen, legen Sie quasi die Hände weg, und nach 5-10 Minuten Wartezeit (ein einstellbarer Parameter) wird er selbst abgeschaltet, gibt Ressourcen frei und wird kostenlos.

Es ist ein völlig realistisches Szenario, in dem Sie eine Anfrage senden, der Cluster nach etwa einer Minute auftaucht, eine weitere Minute benötigt, um zu rechnen, dann fünf Minuten zum Ausschalten und Sie am Ende für sieben Minuten Arbeitszeit dieses Clusters bezahlen, und nicht für Monate oder Jahre.

Das erste Szenario beschrieb die Nutzung von Snowflake im Einzelbenutzer-Modus. Lassen Sie uns nun annehmen, dass es viele Benutzer gibt, was näher am realen Szenario ist.

Angenommen, wir haben viele Analysten und Tableau-Berichte, die unsere Datenbank ständig mit einer großen Anzahl einfacher analytischer SQL-Abfragen bombardieren.

Darüber hinaus nehmen wir an, dass wir einfallsreiche Data Scientists haben, die versuchen, mit den Daten monströse Dinge zu tun, mit Dutzenden von Terabyte zu operieren und Milliarden und Billionen von Datenzeilen zu analysieren.

Für die oben beschriebenen beiden Arten von Lasten ermöglicht es Snowflake, mehrere unabhängige Rechencluster mit unterschiedlicher Leistung zu provisionieren. Diese Rechencluster arbeiten unabhängig, jedoch mit gemeinsamen konsistenten Daten.

Für eine große Anzahl einfacher Abfragen können 2-3 kleine Cluster hochgefahren werden, je zwei Maschinen groß. Dieses Verhalten kann auch durch automatische Einstellungen realisiert werden. Das heißt, Sie sagen: „Snowflake, starte ein kleines Cluster. Wenn die Last darüber einen bestimmten Parameter überschreitet, starte ein ähnliches zweites, drittes. Wenn die Last zu sinken beginnt – schalte überflüssige aus.“ Damit alle Ressourcen haben, unabhängig davon, wie viele Analysten kommen und Berichte ansehen.

Wenn jedoch die Analysten schlafen und sich niemand die Berichte ansieht, können die Cluster vollständig heruntergefahren werden, und Sie hören auf, dafür zu zahlen.

Für schwere Abfragen (von Data Scientists) können Sie jedoch ein sehr großes Cluster mit theoretisch 32 Maschinen hochfahren. Dieses Cluster wird ebenfalls nur für die Minuten und Stunden bezahlt, in denen Ihre riesige Abfrage dort arbeitet.

Die oben beschriebene Möglichkeit ermöglicht es, die Lasten nicht nur auf 2, sondern auch auf mehrere Cluster zu verteilen (ETL, Monitoring, Materialisierung von Berichten,...).

Fassen wir zusammen: Snowflake vereint eine ansprechende Idee mit einer funktionierenden Umsetzung. Bei ManyChat nutzen wir Snowflake zur Analyse aller vorhandenen Daten. Wir haben nicht drei Cluster wie im Beispiel, sondern zwischen 5 und 9 in unterschiedlichen Größen. Es gibt diese sogenannten 16-Maschinen-Cluster, 2-Maschinen-Cluster und auch sehr kleine 1-Maschinen-Cluster für spezielle Aufgaben. Sie verteilen die Last erfolgreich und ermöglichen uns erhebliche Einsparungen.

Die Datenbank skalieret erfolgreich die Lese- und Schreiblast. Das ist ein riesiger Unterschied und ein großer Fortschritt im Vergleich zu 'Aurora', die lediglich die Lese-last bewältigen konnte. Snowflake ermöglicht es, diese Rechencluster auch für Schreiblasten zu skalieren. Wie bereits erwähnt, verwenden wir bei ManyChat mehrere Cluster; die kleinen und superkleinen Cluster werden überwiegend für ETL eingesetzt, um Daten zu laden. Analytiker arbeiten bereits auf den mittleren Clustern, die von der ETL-Last völlig unberührt sind und daher sehr schnell arbeiten.

Dementsprechend eignet sich die Datenbank gut für OLAP-Aufgaben. Leider ist sie jedoch noch nicht für OLTP-Lasten anwendbar. Erstens handelt es sich um eine spaltenorientierte Datenbank, mit allen damit verbundenen Konsequenzen. Zweitens ist der Ansatz, bei jedem Bedarf einen Rechencluster hochzufahren und mit Daten zu versorgen, für OLTP-Lasten leider noch nicht schnell genug. Wartezeiten von Sekunden sind für OLAP-Aufgaben in Ordnung, für OLTP-Anforderungen jedoch inakzeptabel; besser wären 100 ms, noch besser 10 ms.

Fazit

Eine serverlose Datenbank ist durch die Trennung der Datenbank in stateless und stateful Teile möglich. Ihnen ist sicherlich aufgefallen, dass in allen genannten Beispielen der stateful Teil, sagen wir mal, die Speicherung der Mikropartitionen in S3 ist, während der stateless Teil der Optimierer ist, der mit Metadaten arbeitet und Sicherheitsfragen bearbeitet, die als unabhängige, leichtgewichtige stateless Dienste bereitgestellt werden.

Die Ausführung von SQL-Abfragen kann ebenfalls als Dienste mit leichtem Zustand betrachtet werden, die im serverlosen Modus hochkommen können, vergleichbar mit den Rechenclustern von Snowflake, nur die benötigten Daten herunterladen, die Abfrage ausführen und dann 'stillgelegt' werden.

Serverless-Datenbanken auf Produktionsniveau sind bereits verfügbar und funktionstüchtig. Diese serverlosen Datenbanken sind bereit, OLAP-Aufgaben zu bewältigen. Leider kommen sie für OLTP-Aufgaben… mit Einschränkungen zum Einsatz, da es gewisse Beschränkungen gibt. Auf der einen Seite ist das ein Nachteil. Auf der anderen Seite ist es eine Möglichkeit. Vielleicht findet einer der Leser einen Weg, wie eine OLTP-Datenbank vollständig serverlos und ohne Einschränkungen von Aurora realisiert werden kann.

Ich hoffe, es war interessant für Sie. Auf eine serverlose Zukunft 🙂

Quelle: habr.com