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
