Hallo zusammen! Mein Name ist Nikolai Golov. Früher habe ich bei Avito gearbeitet und sechs Jahre die Data Platform geleitet, das heißt, ich war für alle Datenbanken zuständig: analytische (Vertica, ClickHouse), Streaming- und OLTP-Datenbanken (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). In dieser Zeit habe ich mich mit einer Vielzahl von Datenbanken auseinandergesetzt – von den unterschiedlichsten und ungewöhnlichsten bis hin zu speziellen Anwendungsfällen.
Derzeit arbeite ich bei ManyChat. Im Grunde genommen ist das ein Startup – neu, ambitioniert und schnell wachsend. Als ich gerade in die Firma kam, stellte sich die klassische Frage: „Was sollte sich ein junges Startup momentan auf dem Markt für DBMS und Datenbanken zulegen?“
In diesem Artikel, der auf meinem Vortrag basiert , werde ich diese Frage beantworten. Die Videoaufnahme des Vortrags ist verfügbar unter .
Allseits bekannte Datenbanken des Jahres 2020
Es ist 2020, ich schaue mich um und sehe drei Arten von Datenbanken.
Die erste Art – klassische OLTP-Datenbanken: PostgreSQL, SQL Server, Oracle, MySQL. Sie wurden vor vielen Jahren entwickelt, sind aber nach wie vor relevant, weil sie der Entwickler-Community gut bekannt sind.
Die zweite Art – Datenbanken aus den "Nuller-Jahren". Sie versuchten, sich von klassischen Mustern zu lösen, indem sie auf SQL, traditionelle Strukturen und ACID verzichteten und stattdessen eingebautes Sharding und andere attraktive Funktionen hinzufügten. Beispiele hierfür sind Cassandra, MongoDB, Redis oder Tarantool. Alle diese Lösungen wollten dem Markt etwas grundlegend Neues bieten und fanden ihre Nische, da sie sich in bestimmten Aufgaben als äußerst praktisch erwiesen. Diese Datenbanken bezeichne ich mit dem Überbegriff NOSQL.
Die "Nuller" sind vorbei, die NOSQL-Datenbanken sind etabliert, und die Welt hat, meiner Meinung nach, den nächsten Schritt gemacht — hin zu Managed-Datenbanken. Diese Datenbanken haben den gleichen Kern wie klassische OLTP-Datenbanken oder neue NoSQL-Lösungen. Aber sie benötigen keinen DBA oder DevOps und laufen auf verwalteter Hardware in der Cloud. Für den Entwickler ist dies "einfach eine Datenbank", die irgendwo funktioniert, wobei es niemanden interessiert, wie sie auf dem Server installiert wurde, wer den Server eingerichtet hat und wer ihn aktualisiert.
Beispiele für solche Datenbanken:
- AWS RDS — eine Managed-Schicht über PostgreSQL/MySQL.
- DynamoDB — das AWS-Pendant zu dokumentenbasierten Datenbanken, ähnlich wie Redis und MongoDB.
- Amazon Redshift — eine managed analytische Datenbank.
Im Grunde sind das alte Datenbanken, die jedoch in einer verwalteten Umgebung bereitgestellt werden, ohne dass eine Arbeit mit der Hardware erforderlich ist.
Hinweis. Die Beispiele stammen aus der AWS-Umgebung, jedoch existieren auch entsprechende Alternativen in Microsoft Azure, Google Cloud oder Yandex.Cloud.
Was ist daran neu? Im Jahr 2020 gab es nichts davon.
Das Konzept Serverless
Echt neu auf dem Markt im Jahr 2020 sind serverless oder serverlose Lösungen.
Ich werde versuchen zu erklären, was das bedeutet, anhand eines typischen Dienstes oder Backend-Anwendung.
Um eine gewöhnliche Backend-Anwendung bereitzustellen, kaufen oder mieten wir einen Server, kopieren den Code darauf, veröffentlichen einen Endpunkt nach außen und zahlen regelmäßig für Miete, Strom und Rechenzentrumsdienste. Das ist das Standardverfahren.
Gibt es einen anderen Weg? Mit serverlosen Diensten schon.
Worin liegt der Kern dieses Ansatzes: kein Server, nicht einmal die Miete eines virtuellen Instances in der Cloud. Zum Bereitstellen eines Dienstes kopieren wir den Code (Funktionen) in ein Repository und veröffentlichen einen Endpunkt. Danach zahlen wir einfach für jeden Aufruf dieser Funktion, wobei wir die Hardware, auf der sie ausgeführt wird, vollständig ignorieren.
Ich werde versuchen, diesen Ansatz mit Bildern zu veranschaulichen.
Klassisches Deployment. Wir bieten einen Dienst mit bestimmter Last an. Wir starten zwei Instanzen: physische Server oder Instanzen in AWS. Auf diese Instanzen werden externe Anfragen geleitet, 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, während der andere nur zu 50 % ausgelastet ist — er steht teilweise still. Wenn nicht drei Anfragen, sondern 30 eingehen, kann das gesamte System die Last nicht bewältigen und beginnt zu verlangsamen.
Serverless Deployment. In einer serverlosen Umgebung gibt es für einen solchen Dienst keine Instanzen und Server. Es gibt einen Pool von vorgeheizten Ressourcen – kleinen vorbereiteten Docker-Containern mit dem implementierten Funktionscode. Das System erhält externe Anfragen, und für jede dieser Anfragen startet das serverlose Framework einen kleinen Container mit Code: es verarbeitet genau diese Anfrage und beendet den Container.
Eine Anfrage entspricht einem Container, 1000 Anfragen sind 1000 Container. Die Bereitstellung auf physischen Servern hingegen obliegt dem Cloud-Anbieter und wird vollständig durch das serverlose Framework abstrahiert. In diesem Modell zahlen wir für jeden Aufruf. Erhalten wir einen Aufruf pro Tag, zahlen wir für einen Aufruf; erhalten wir eine Million pro Minute, zahlen wir für eine Million. Oder pro Sekunde, das kann auch vorkommen.
Das Konzept der Veröffentlichung einer serverlosen Funktion eignet sich für stateless Dienste. Wenn jedoch ein statefull Dienst benötigt wird, fügen wir eine Datenbank hinzu. In diesem Fall schreiben und lesen jede statefull Funktion einfach aus der Datenbank, und zwar aus einer der drei Typen, die zu Beginn des Artikels beschrieben wurden.
Was sind die allgemeinen Einschränkungen aller dieser Datenbanken? Es sind die Kosten für einen ständig genutzten Cloud- oder physikalischen Server (oder mehrere Server). Egal, ob wir eine klassische Datenbank oder eine Managed-Lösung verwenden, ob es DevOps und Administratoren gibt oder nicht – wir zahlen rund um die Uhr für die Hardware, den Strom und die Miete des Rechenzentrums. Bei einer klassischen Datenbank zahlen wir für Master und Slave. Bei einer hochbelasteten, shardierten Datenbank zahlen wir für 10, 20 oder 30 Server und das kontinuierlich.
Die Präsenz von dauerhaft reservierten Servern in der Kostenstruktur wurde früher als notwendiges Übel angesehen. Auch herkömmliche Datenbanken haben weitere Herausforderungen, wie Verbindungsgrenzen, Skalierungseinschränkungen, georedundanten Konsens – einige dieser Probleme können in bestimmten Datenbanken gelöst werden, aber nicht alle gleichzeitig und nicht perfekt.
Serverlose Datenbank – Theorie
Frage des Jahres 2020: Kann man eine Datenbank auch serverlos gestalten? Jeder hat von serverlosem Backend gehört… warum sollten wir nicht auch versuchen, eine Datenbank serverlos zu gestalten?
Das klingt seltsam, denn eine Datenbank ist ein stateful Dienst, der nicht besonders gut für serverless Infrastruktur geeignet ist. Zudem ist der State einer Datenbank sehr groß: Gigabytes, Terabytes und in analytischen Datenbanken sogar Petabytes. Es ist nicht einfach, dies in leichten Docker-Containern zu betreiben.
Auf der anderen Seite besteht die Mehrheit der modernen Datenbanken aus einer großen Menge an Logik und Komponenten: Transaktionen, Integritätsprüfungen, Prozeduren, relationale Abhängigkeiten und viel Logik. Ein erheblicher Teil der Logik einer Datenbank benötigt nur einen kleinen State. Gigabytes und Terabytes werden nur von einem kleinen Teil der Datenbanklogik verwendet, der direkt mit der Ausführung von Abfragen zusammenhängt.
Daher die Idee: Wenn ein Teil der Logik stateless ausgeführt werden kann, warum sollte man die Datenbank nicht in stateful und stateless Teile unterteilen?
Serverless für OLAP-Lösungen
Lassen Sie uns ansehen, wie eine Aufteilung der Datenbank in stateful und stateless Komponenten anhand praktischer Beispiele aussehen könnte.
Nehmen wir an, wir haben eine analytische Datenbank.: externe Daten (roter Zylinder links), ETL-Prozess, der die 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 eines Data Warehouses.
In diesem Schema wird der ETL-Prozess hypothetisch einmalig ausgeführt. Danach muss kontinuierlich für die Server gezahlt werden, auf denen die mit ETL geladenen Daten gespeichert sind, damit Anfragen bearbeitet werden können.
Betrachten wir einen alternativen Ansatz, der in AWS Athena Serverless umgesetzt ist. Hier gibt es keine permanent 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 Anfrage erforderlich sind.
- 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, und die Ressourcen werden freigegeben.
In dieser Architektur zahlen wir nur für den Prozess der Ausführung der Anfrage. Keine Anfragen — keine Kosten.
Dieser Ansatz ist praktikabel und wird nicht nur in Athena Serverless, sondern auch in Redshift Spectrum (in AWS) umgesetzt.
Beispielsweise zeigt sich bei Athena, dass die Serverless-Datenbank mit realen Abfragen von Dutzenden und Hunderten von Terabyte Daten funktioniert. Für Hunderte von Terabyte sind Hunderte von Servern erforderlich, aber wir müssen nicht für diese bezahlen — wir zahlen nur für die Abfragen. Die Geschwindigkeit jeder Abfrage ist (sehr) niedrig im Vergleich zu spezialisierten Analyse-Datenbanken wie Vertica, aber wir zahlen auch nicht für Ausfallzeiten.
Eine solche Datenbank ist für sporadische analytische Ad-hoc-Abfragen geeignet. Beispielsweise, wenn wir spontan eine Hypothese mit einem riesigen Datenvolumen überprüfen möchten. Für diese Fälle ist Athena ideal. Für regelmäßige Abfragen ist ein solches System kostspielig. In diesem Fall sollten Sie die Daten in einer spezialisierten Lösung zwischenspeichern.
Serverless für OLTP-Lösungen
Im vorherigen Beispiel wurden OLAP-Aufgaben (analytische) behandelt. Jetzt betrachten wir OLTP-Aufgaben.
Stellen Sie sich eine skalierbare PostgreSQL- oder MySQL-Datenbank vor. Lassen Sie uns einen typischen verwalteten PostgreSQL- oder MySQL-Instance mit minimalen Ressourcen einrichten. Wenn die Last auf die Instance steigt, fügen wir zusätzliche Replikate hinzu, um einen Teil der Leseanfragen darauf zu verteilen. Wenn es keine Anfragen oder Last gibt, schalten wir die Replikate ab. Die erste Instance ist der Master, die anderen sind die Replikate.
Diese Idee wird in einer Datenbank namens Aurora Serverless AWS umgesetzt. Das Prinzip ist einfach: Eine Proxy-Flotte empfängt Anfragen von externen Anwendungen. Bei steigender Last weist sie Rechenressourcen aus bereits vorgewärmten minimalen Instances zu – die Verbindung erfolgt sehr schnell. Das Abschalten von Instances erfolgt auf die gleiche Weise.
Innerhalb von Aurora gibt es das Konzept der Aurora Capacity Unit, ACU. Das ist (vereinfacht gesagt) eine Instance (Server). Jeder spezifische ACU kann Master oder Slave sein. Jede Capacity Unit verfügt über eigenen Arbeitsspeicher, Prozessor und minimalen Speicherplatz. Dementsprechend gibt es einen Master und die anderen sind nur für Lesevorgänge gedacht.
Die Anzahl dieser aktiven Aurora Capacity Units ist ein konfigurierbarer 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 die Proxy-Flotte die Aurora Capacity Units an und erhöht die Leistungsressourcen des Systems. Die Möglichkeit, Ressourcen zu erhöhen und zu verringern, ermöglicht dem System, Ressourcen 'zu jonglieren': sie ziehen einzelne ACUs automatisch heraus (und ersetzen sie durch neue) und wenden alle aktuellen Updates auf die herausgezogenen Ressourcen an.
Die Aurora Serverless-Datenbank kann die Leseanforderungen skalieren. Dies wird jedoch nicht direkt in der Dokumentation erwähnt. Es könnte der Eindruck entstehen, dass sie ein Multi-Master-System aktivieren können. Doch es gibt kein magisches Geheimnis.
Diese Datenbank eignet sich hervorragend, um keine hohen Ausgaben für Systeme mit unvorhersehbarem Zugriff zu haben. Zum Beispiel erwarten wir bei der Erstellung eines MVP oder von Marketing-Visitenkarten-Websites normalerweise keine stabile Last. Entsprechend zahlen wir nicht für Instanzen, wenn kein Zugriff besteht. Wenn jedoch plötzlich eine Belastung auftritt, etwa nach einer Konferenz oder einer Werbekampagne, strömen viele Menschen auf die Website und die Last steigt stark an. Aurora Serverless bewältigt diese Last automatisch und fügt schnell die fehlenden Ressourcen (ACU) hinzu. Nach der Konferenz vergessen alle den Prototyp, die Server (ACU) gehen offline und die Ausgaben sinken auf null — sehr praktisch.
Diese Lösung ist nicht für eine stabile hohe Last geeignet, da sie nicht in der Lage ist, die schreibende Last zu skalieren. All diese Verbindungen und Trennungen von Ressourcen erfolgen im sogenannten „Scale Point“ — dem Zeitpunkt, wenn die Datenbank nicht von einer Transaktion gehalten wird, keine temporären Tabellen gehalten werden. Beispielsweise kann es in der Woche vorkommen, dass kein Scale Point eintritt, wodurch die Datenbank mit denselben Ressourcen arbeitet und sich einfach weder ausdehnen noch zusammenziehen kann.
Magie gibt es nicht – es ist ganz normales PostgreSQL. Aber der Prozess zum Hinzufügen und Trennen von Maschinen ist teilweise automatisiert.
Serverless by design
Aurora Serverless ist eine alte Datenbank, die für die Cloud neu geschrieben wurde, um die spezifischen Vorteile von Serverless zu nutzen. Jetzt möchte ich Ihnen von einer Datenbank erzählen, die von Anfang an für die Cloud und den Serverless-Ansatz entwickelt wurde – Serverless-by-design. Sie wurde von Anfang an ohne die Annahme entwickelt, dass sie auf physischen Servern läuft.
Diese Datenbank heißt Snowflake. Sie besteht aus drei Schlüsselmolekülen.
Der erste ist der Metadatenblock. Es handelt sich um einen schnellen In-Memory-Service, der Fragen zur Sicherheit, zu Metadaten, Transaktionen und zur Optimierung von Anfragen löst (auf der linken Illustration).
Der zweite Block besteht aus vielen virtuellen Rechenclustern für Berechnungen (in der Abbildung – eine Gruppe blauer Kreise).
Der dritte Block ist ein Datenspeichersystem auf Basis von S3. S3 ist ein unbegrenzter Objektspeicher in AWS, sozusagen ein unbegrenzter Dropbox-Dienst für Unternehmen.
Schauen wir uns an, wie Snowflake funktioniert, unter der Annahme eines kalten Starts. Das heißt, die Datenbank existiert, die Daten sind geladen, aber es gibt keine aktiven Abfragen. Wenn also keine Abfragen an die Datenbank gestellt werden, läuft unser schneller in-memory Metadatenservice (das erste Modul). Und wir haben einen S3-Speicher, in dem die Tabellendaten in so genannten Mikropartitionen abgelegt sind. Zur Vereinfachung: Wenn in der Tabelle Deals gespeichert sind, sind Mikropartitionen die Tage der Deals. Jeder Tag ist eine eigene Mikropartition, eine eigene Datei. Und wenn die Datenbank in diesem Modus arbeitet, zahlen Sie nur für den Speicherplatz, der von den Daten belegt wird. Der Preis für den Speicherplatz ist sehr niedrig (insbesondere unter Berücksichtigung der erheblichen Kompression). Der Metadatenservice läuft ebenfalls ständig, benötigt jedoch für die Optimierung der Abfragen nicht viele Ressourcen, sodass man den Service als quasi kostenlos betrachten kann.
Stellen wir uns nun vor, ein Benutzer hat eine Abfrage an unsere Datenbank gesendet. Die SQL-Abfrage wird sofort zur Verarbeitung an den Metadatenservice gesendet. Der Service analysiert die Anfrage, die verfügbaren Daten und die Berechtigungen des Benutzers und erstellt, sofern alles in Ordnung ist, einen Plan zur Verarbeitung der Abfrage.
Anschließend initiiert der Dienst den Start des Rechenclusters. Ein Rechencluster besteht aus Servern, die Berechnungen durchführen. Das bedeutet, es kann aus einem, zwei, vier, acht, sechzehn, oder sogar dreiunddreißig Servern bestehen – je nachdem, wie viele Sie benötigen. Sie geben eine Anfrage ein, und sofort beginnt der Start dieses Clusters. Das dauert tatsächlich nur Sekunden.
Nachdem der Cluster gestartet wurde, werden die für die Verarbeitung Ihrer Anfrage benötigten Mikropartitionen aus S3 in den Cluster kopiert. Stellen Sie sich vor, dass für die Ausführung einer SQL-Abfrage zwei Partitionen aus einer Tabelle und eine aus einer anderen nötig sind. In diesem Fall werden nur diese drei benötigten Partitionen in den Cluster kopiert, und nicht die gesamten Tabellen. Da sich alles innerhalb eines Rechenzentrums befindet und durch sehr schnelle Verbindungen verbunden ist, geschieht der gesamte Datenübertragungsprozess äußerst schnell: innerhalb von Sekunden, in seltenen Fällen — in Minuten, es sei denn, es handelt sich um äußerst komplexe Abfragen. Die Mikropartitionen werden daher in den Rechencluster kopiert, und nach Abschluss wird die SQL-Abfrage auf diesem Rechencluster ausgeführt. Das Ergebnis dieser Abfrage kann eine Zeile, mehrere Zeilen oder eine Tabelle sein — diese werden an den Benutzer gesendet, damit er sie herunterladen, in seinem BI-Tool anzeigen oder auf andere Weise verwenden kann.
Jede SQL-Abfrage kann nicht nur Aggregatdaten aus zuvor geladenen Informationen abrufen, sondern auch neue Daten in der Datenbank laden oder erstellen. Das bedeutet, dass eine Abfrage beispielsweise neue Einträge in eine andere Tabelle einfügen kann, was zur Entstehung einer neuen Partition im Rechencluster führt, die wiederum automatisch im zentralen S3-Speicher gespeichert wird.
Das oben beschriebene Szenario, vom Eintritt des Nutzers bis zum Start des Clusters, Ladevorgängen, der Ausführung von Anfragen und dem Erhalt der Ergebnisse, wird nach Minuten abgerechnet, die der virtuelle Rechencluster und das virtuelle Warehouse genutzt werden. Die Tarife variieren je nach AWS-Region und Clustergröße, im Durchschnitt liegen sie jedoch bei einigen Dollar pro Stunde. Ein Cluster mit vier Maschinen kostet doppelt so viel wie eines mit zwei Maschinen, und eines mit acht Maschinen kostet nochmals doppelt so viel. Optionen mit 16 und 32 Maschinen sind verfügbar, abhängig von der Komplexität der Anfragen. Sie zahlen jedoch nur für die Minuten, in denen der Cluster tatsächlich aktiv ist, da er, wenn keine Anfragen vorliegen, nach 5 bis 10 Minuten Wartezeit (ein anpassbarer Parameter) automatisch heruntergefahren wird, Ressourcen freigibt und kostenlos wird.
Ein völlig realistisches Szenario ist, dass Sie eine Anfrage senden, der Cluster sich innerhalb einer Minute aufbaut, eine weitere Minute für die Berechnung benötigt wird, und dann fünf Minuten für das Abschalten, sodass Sie letztendlich nur für sieben Minuten Betriebszeit dieses Clusters bezahlen und nicht für Monate oder Jahre.
Das erste Szenario beschrieb die Verwendung von Snowflake in einer Einbenutzerumgebung. Lassen Sie uns nun annehmen, dass es viele Nutzer gibt, was näher an einem realistischen Szenario liegt.
Stellen wir uns vor, wir haben viele Analysten und Tableau-Berichte, die unsere Datenbank ständig mit einer Vielzahl einfacher analytischer SQL-Abfragen bombardieren.
Darüber hinaus nehmen wir an, dass wir einfallsreiche Data Scientists haben, die mit den Daten Unglaubliches vollbringen wollen, indem sie mit Dutzenden Terabytes arbeiten und Milliarden sowie Billionen von Datenzeilen analysieren.
Für die oben beschriebenen beiden Lasttypen ermöglicht es Snowflake, mehrere unabhängige Rechencluster unterschiedlicher Leistung hochzufahren. Diese Rechencluster arbeiten unabhängig, aber mit konsistenten gemeinsamen Daten.
Für eine große Anzahl leichter Abfragen können Sie 2-3 kleine Cluster mit jeweils etwa 2 Maschinen bereitstellen. Dieses Verhalten kann unter anderem durch automatische Konfigurationen realisiert werden. Das bedeutet, Sie sagen: „Snowflake, starte ein kleines Cluster. Wenn die Last über einen bestimmten Wert steigt, starte ein ähnliches zweites oder drittes. Wenn die Last sinkt, schalte die überschüssigen ab.“ Damit stehen Ihnen unabhängig von der Anzahl der Analysten, die Berichte einsehen, genügend Ressourcen zur Verfügung.
Wenn die Analysten schlafen und niemand die Berichte einsehen, können die Cluster vollständig abgeschaltet 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 rund 32 Maschinen bereitstellen. Dieses Cluster wird ebenfalls nur für die Minuten und Stunden berechnet, in denen Ihr großer Auftrag läuft.
Die oben beschriebene Möglichkeit erlaubt es, nicht nur 2, sondern auch mehrere Arten von Lasten (ETL, Monitoring, Materialisierung von Berichten, ...) nach Clustern zu trennen.
Zusammenfassend lässt sich sagen, dass Snowflake eine ansprechende Idee mit einer funktionalen Umsetzung kombiniert. Bei ManyChat nutzen wir Snowflake zur Analyse aller verfügbaren Daten. Wir haben nicht drei Cluster wie in der Beispielbeschreibung, sondern zwischen 5 und 9, in verschiedenen Größen. Es gibt bei uns Cluster mit 16 Maschinen, 2 Maschinen und auch super kleine 1-Maschinen-Cluster für bestimmte Aufgaben. Diese verteilen die Last erfolgreich und ermöglichen uns signifikante Einsparungen.
Die Datenbank skaliert erfolgreich sowohl die Lese- als auch die Schreiblast. Das stellt einen enormen Unterschied und einen großen Fortschritt im Vergleich zu „Aurora“ dar, die nur die Lese-Last bewältigen konnte. Snowflake ermöglicht es, mit diesen Rechenclustern auch die Schreiblast zu skalieren. Wie bereits erwähnt, verwenden wir bei ManyChat mehrere Cluster; kleinere und super kleine Cluster werden hauptsächlich für ETL, also das Laden von Daten, verwendet. Die Analysten arbeiten bereits auf den mittleren Clustern, die von der ETL-Last absolut unberührt bleiben, und daher sehr schnell arbeiten.
Daher eignet sich die Datenbank gut für OLAP-Anwendungen. Leider ist sie jedoch noch nicht für OLTP-Lasten bereit. Erstens handelt es sich um eine spaltenorientierte Datenbank, mit allen sich daraus ergebenden Konsequenzen. Zweitens ist der Ansatz, bei dem Sie bei jeder Anfrage nach Bedarf einen Rechencluster hochfahren und mit Daten speisen, leider für OLTP-Lasten noch nicht schnell genug. Sekundenwartezeiten sind für OLAP-Anwendungen in Ordnung, aber für OLTP-Anwendungen sind sie inakzeptabel – ideal wären 100 ms, noch besser 10 ms.
Zusammenfassung
Eine serverlose Datenbank ist möglich durch die Trennung der Datenbank in stateless und stateful Teile. Sie haben sicherlich bemerkt, dass im gesamten Beispiel der stateful Teil – vereinfacht gesagt – die Speicherung von Mikropartitionen in S3 ist, während stateless der Optimierer ist, der mit Metadaten arbeitet und Sicherheitsfragen behandelt, die als unabhängige, leichtgewichtige stateless Dienste hochgefahren werden können.
Die Ausführung von SQL-Anfragen kann auch als Dienste mit leichtem Zustand betrachtet werden, die im serverlosen Modus auftauchen können, wie für Rechencluster von Snowflake, nur die benötigten Daten herunterladen, die Abfrage ausführen und dann "schlummern".
Serverless-Datenbanken auf Produktionsniveau sind jetzt verfügbar und funktionsfähig. Diese serverlosen Datenbanken sind bereits darauf vorbereitet, OLAP-Aufgaben zu bewältigen. Leider haben sie für OLTP-Aufgaben… einige Einschränkungen, was ein Nachteil ist. Auf der anderen Seite ist es jedoch auch eine Chance. Vielleicht findet einer der Leser einen Weg, wie man eine OLTP-Datenbank vollständig serverlos und ohne Einschränkungen nutzen kann, ähnlich wie bei Aurora.
Ich hoffe, Sie fanden es interessant. Auf in die serverlose Zukunft 🙂
Quelle: habr.com
