Der tempor\u00e4re Speicher wird geleert, Ressourcen werden freigegeben.<\/li>\n<\/ul>\nIn dieser Architektur zahlen wir nur f\u00fcr den Prozess der Abfrageausf\u00fchrung. Keine Abfragen \u2013 keine Kosten.<\/p>\n
Am Beispiel von Athena ist zu sehen, dass die Serverless-Datenbank mit echten Abfragen von Dutzenden und Hunderten von Terabyte Daten arbeitet. F\u00fcr Hunderte Terabyte werden Hunderte von Servern ben\u00f6tigt, aber wir m\u00fcssen nicht daf\u00fcr bezahlen \u2013 wir zahlen f\u00fcr die Abfragen. Die Geschwindigkeit jeder Abfrage ist (sehr) langsam im Vergleich zu spezialisierten analytischen Datenbanken wie Vertica, aber wir bezahlen auch nicht f\u00fcr Stillstandszeiten.<\/p>\n
Solch eine Datenbank ist f\u00fcr seltene analytische Ad-hoc-Abfragen anwendbar. Zum Beispiel, wenn wir spontan entscheiden, eine Hypothese an einem riesigen Datenvolumen zu \u00fcberpr\u00fcfen. F\u00fcr diese F\u00e4lle eignet sich Athena perfekt. F\u00fcr regelm\u00e4\u00dfige Abfragen wird ein solches System teuer. In diesem Fall sollten Sie die Daten in einer speziellen L\u00f6sung cachen. <\/p>\n
Serverless f\u00fcr OLTP-L\u00f6sungen.<\/h2>\n \nIm vorherigen Beispiel wurden OLAP-Aufgaben (analytische) betrachtet. Jetzt betrachten wir OLTP-Aufgaben.<\/p>\n
Stellen wir uns ein skalierbares PostgreSQL oder MySQL vor. Lassen Sie uns eine gew\u00f6hnliche verwaltete Instanz von PostgreSQL oder MySQL mit minimalen Ressourcen einrichten. Wenn die Instanz mehr Last erh\u00e4lt, werden wir zus\u00e4tzliche 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.<\/p>\n
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\u00e4rmten minimalen Instanzen bereit \u2013 die Verbindung erfolgt so schnell wie m\u00f6glich. Das Ausschalten der Instanzen geschieht ebenso.<\/p>\n
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\u00fcgt \u00fcber ihren eigenen Arbeitsspeicher, Prozessor und minimalen Speicherplatz. Folglich gibt es ein Master-Exemplar, die anderen sind nur read-only Replikate.<\/p>\n
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).<\/p>\n
Die Aurora Serverless-Datenbank kann die Lese-Last skalieren. Aber in der Dokumentation wird dies nicht direkt gesagt. Es k\u00f6nnte der Eindruck entstehen, dass sie ein Multi-Master-Setup herstellen k\u00f6nnen. Doch es gibt kein Magie. <\/p>\n
Diese Datenbank eignet sich gut, um nicht viel Geld f\u00fcr 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\u00fcr Instanzen. Wenn unerwartet eine Last entsteht, wie nach einer Konferenz oder Werbekampagne, str\u00f6men 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 \u2013 praktisch.<\/p>\n
Diese L\u00f6sung eignet sich nicht f\u00fcr stabile Hochlast, da sie nicht in der Lage ist, die schreibenden Lasten zu skalieren. All diese Verbindungen und Abschaltungen von Ressourcen geschehen im sogenannten \u201eSkalierungspunkt\u201c \u2013 einem Zeitpunkt, an dem die Datenbank nicht durch eine Transaktion gehalten wird und tempor\u00e4re 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. <\/p>\n
Es gibt keinen Zauber \u2013 es ist einfach nur PostgreSQL. Aber der Prozess der Hinzuf\u00fcgung von Maschinen und der teilweisen Automatisierung der Abschaltung ist automatisiert.<\/p>\n
Serverless by design<\/h2>\n \nAurora Serverless ist eine alte Datenbank, die f\u00fcr die Cloud umgeschrieben wurde, um die spezifischen Vorteile von Serverless zu nutzen. Jetzt erz\u00e4hle ich von einer Datenbank, die von Grund auf f\u00fcr die Cloud und den serverless Ansatz entwickelt wurde \u2013 Serverless-by-design. Sie wurde sofort ohne die Annahme entwickelt, dass sie auf physischen Servern arbeitet.<\/p>\n
Diese Datenbank hei\u00dft Snowflake. Sie besteht aus drei Schl\u00fcsselkomponenten.<\/p>\n
Der zweite Block ist eine Vielzahl von virtuellen Rechenclustern f\u00fcr Berechnungen (in der Abbildung \u2013 eine Ansammlung blauer Kreise).<\/p>\n
Der dritte Block ist ein Speichersystem auf Basis von S3. S3 ist ein unbegrenzter Objektspeicher in AWS, \u00e4hnlich einem unbegrenzten Dropbox f\u00fcr Unternehmen.<\/p>\n
Lassen Sie uns anschauen, wie Snowflake funktioniert, unter der Annahme eines Kaltstarts. Das hei\u00dft, 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\u00e4uft, zahlen Sie nur f\u00fcr den Platz, den die Daten einnehmen. Dabei ist der Tarif f\u00fcr den Platz sehr niedrig (insbesondere unter Ber\u00fccksichtigung der erheblichen Kompression). Der Metadata Service l\u00e4uft ebenfalls kontinuierlich, aber f\u00fcr die Optimierung von Abfragen werden nicht viele Ressourcen ben\u00f6tigt, und der Service kann als bedingt kostenlos betrachtet werden. <\/p>\n
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\u00fcgbaren Daten, die Berechtigungen des Benutzers, und wenn alles in Ordnung ist, erstellt er einen Verarbeitungsplan f\u00fcr die Abfrage.<\/p>\n
Dann initiiert der Service den Start des Rechenclusters. Ein Rechencluster ist ein Cluster von Servern, die Berechnungen durchf\u00fchren. Das hei\u00dft, es ist ein Cluster, das aus 1, 2, 4, 8, 16, 32 Servern bestehen kann \u2013 so viele, wie Sie m\u00f6chten. Sie senden die Abfrage und sofort beginnt der Start dieses Clusters. Das dauert tats\u00e4chlich nur Sekunden.<\/p>\n
Jede SQL-Anfrage kann nicht nur Aggregate aus zuvor geladenen Daten berechnen, sondern auch neue Daten in die Datenbank laden\/erstellen. Das hei\u00dft, es kann sich um eine Anfrage handeln, die beispielsweise neue Eintr\u00e4ge in eine andere Tabelle einf\u00fcgt, was zur Schaffung einer neuen Partition im Rechencluster f\u00fchrt, die wiederum automatisch im gemeinsamen S3-Speicher gespeichert wird.<\/p>\n
Das oben beschriebene Szenario, vom Eintreffen des Benutzers bis zum Hochfahren des Clusters, Laden der Daten, Ausf\u00fchren 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\u00f6\u00dfe, betr\u00e4gt 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\u00e4t der Anfragen verf\u00fcgbar. Aber Sie zahlen nur f\u00fcr die Minuten, in denen der Cluster tats\u00e4chlich arbeitet, denn wenn keine Anfragen vorliegen, legen Sie quasi die H\u00e4nde weg, und nach 5-10 Minuten Wartezeit (ein einstellbarer Parameter) wird er selbst abgeschaltet, gibt Ressourcen frei und wird kostenlos.<\/p>\n
Es ist ein v\u00f6llig realistisches Szenario, in dem Sie eine Anfrage senden, der Cluster nach etwa einer Minute auftaucht, eine weitere Minute ben\u00f6tigt, um zu rechnen, dann f\u00fcnf Minuten zum Ausschalten und Sie am Ende f\u00fcr sieben Minuten Arbeitszeit dieses Clusters bezahlen, und nicht f\u00fcr Monate oder Jahre.<\/p>\n
Das erste Szenario beschrieb die Nutzung von Snowflake im Einzelbenutzer-Modus. Lassen Sie uns nun annehmen, dass es viele Benutzer gibt, was n\u00e4her am realen Szenario ist.<\/p>\n
Angenommen, wir haben viele Analysten und Tableau-Berichte, die unsere Datenbank st\u00e4ndig mit einer gro\u00dfen Anzahl einfacher analytischer SQL-Abfragen bombardieren.<\/p>\n
Dar\u00fcber hinaus nehmen wir an, dass wir einfallsreiche Data Scientists haben, die versuchen, mit den Daten monstr\u00f6se Dinge zu tun, mit Dutzenden von Terabyte zu operieren und Milliarden und Billionen von Datenzeilen zu analysieren. <\/p>\n
F\u00fcr die oben beschriebenen beiden Arten von Lasten erm\u00f6glicht es Snowflake, mehrere unabh\u00e4ngige Rechencluster mit unterschiedlicher Leistung zu provisionieren. Diese Rechencluster arbeiten unabh\u00e4ngig, jedoch mit gemeinsamen konsistenten Daten.<\/p>\n
F\u00fcr eine gro\u00dfe Anzahl einfacher Abfragen k\u00f6nnen 2-3 kleine Cluster hochgefahren werden, je zwei Maschinen gro\u00df. Dieses Verhalten kann auch durch automatische Einstellungen realisiert werden. Das hei\u00dft, Sie sagen: \u201eSnowflake, starte ein kleines Cluster. Wenn die Last dar\u00fcber einen bestimmten Parameter \u00fcberschreitet, starte ein \u00e4hnliches zweites, drittes. Wenn die Last zu sinken beginnt \u2013 schalte \u00fcberfl\u00fcssige aus.\u201c Damit alle Ressourcen haben, unabh\u00e4ngig davon, wie viele Analysten kommen und Berichte ansehen.<\/p>\n
Wenn jedoch die Analysten schlafen und sich niemand die Berichte ansieht, k\u00f6nnen die Cluster vollst\u00e4ndig heruntergefahren werden, und Sie h\u00f6ren auf, daf\u00fcr zu zahlen.<\/p>\n
F\u00fcr schwere Abfragen (von Data Scientists) k\u00f6nnen Sie jedoch ein sehr gro\u00dfes Cluster mit theoretisch 32 Maschinen hochfahren. Dieses Cluster wird ebenfalls nur f\u00fcr die Minuten und Stunden bezahlt, in denen Ihre riesige Abfrage dort arbeitet.<\/p>\n
Die oben beschriebene M\u00f6glichkeit erm\u00f6glicht es, die Lasten nicht nur auf 2, sondern auch auf mehrere Cluster zu verteilen (ETL, Monitoring, Materialisierung von Berichten,...).<\/p>\n
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\u00f6\u00dfen. Es gibt diese sogenannten 16-Maschinen-Cluster, 2-Maschinen-Cluster und auch sehr kleine 1-Maschinen-Cluster f\u00fcr spezielle Aufgaben. Sie verteilen die Last erfolgreich und erm\u00f6glichen uns erhebliche Einsparungen.<\/p>\n
Die Datenbank skalieret erfolgreich die Lese- und Schreiblast. Das ist ein riesiger Unterschied und ein gro\u00dfer Fortschritt im Vergleich zu 'Aurora', die lediglich die Lese-last bew\u00e4ltigen konnte. Snowflake erm\u00f6glicht es, diese Rechencluster auch f\u00fcr Schreiblasten zu skalieren. Wie bereits erw\u00e4hnt, verwenden wir bei ManyChat mehrere Cluster; die kleinen und superkleinen Cluster werden \u00fcberwiegend f\u00fcr ETL eingesetzt, um Daten zu laden. Analytiker arbeiten bereits auf den mittleren Clustern, die von der ETL-Last v\u00f6llig unber\u00fchrt sind und daher sehr schnell arbeiten. <\/p>\n
Dementsprechend eignet sich die Datenbank gut f\u00fcr OLAP-Aufgaben. Leider ist sie jedoch noch nicht f\u00fcr 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\u00fcr OLTP-Lasten leider noch nicht schnell genug. Wartezeiten von Sekunden sind f\u00fcr OLAP-Aufgaben in Ordnung, f\u00fcr OLTP-Anforderungen jedoch inakzeptabel; besser w\u00e4ren 100 ms, noch besser 10 ms.<\/p>\n
Fazit<\/h2>\n \nEine serverlose Datenbank ist durch die Trennung der Datenbank in stateless und stateful Teile m\u00f6glich. Ihnen ist sicherlich aufgefallen, dass in allen genannten Beispielen der stateful Teil, sagen wir mal, die Speicherung der Mikropartitionen in S3 ist, w\u00e4hrend der stateless Teil der Optimierer ist, der mit Metadaten arbeitet und Sicherheitsfragen bearbeitet, die als unabh\u00e4ngige, leichtgewichtige stateless Dienste bereitgestellt werden.<\/p>\n
Die Ausf\u00fchrung von SQL-Abfragen kann ebenfalls als Dienste mit leichtem Zustand betrachtet werden, die im serverlosen Modus hochkommen k\u00f6nnen, vergleichbar mit den Rechenclustern von Snowflake, nur die ben\u00f6tigten Daten herunterladen, die Abfrage ausf\u00fchren und dann 'stillgelegt' werden.<\/p>\n
Serverless-Datenbanken auf Produktionsniveau sind bereits verf\u00fcgbar und funktionst\u00fcchtig. Diese serverlosen Datenbanken sind bereit, OLAP-Aufgaben zu bew\u00e4ltigen. Leider kommen sie f\u00fcr OLTP-Aufgaben\u2026 mit Einschr\u00e4nkungen zum Einsatz, da es gewisse Beschr\u00e4nkungen gibt. Auf der einen Seite ist das ein Nachteil. Auf der anderen Seite ist es eine M\u00f6glichkeit. Vielleicht findet einer der Leser einen Weg, wie eine OLTP-Datenbank vollst\u00e4ndig serverlos und ohne Einschr\u00e4nkungen von Aurora realisiert werden kann.<\/p>\n
Ich hoffe, es war interessant f\u00fcr Sie. Auf eine serverlose Zukunft \ud83d\ude42habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0413\u043e\u043b\u043e\u0432 \u041d\u0438\u043a\u043e\u043b\u0430\u0439. \u0420\u0430\u043d\u044c\u0448\u0435 \u044f \u0440\u0430\u0431\u043e\u0442\u0430\u043b \u0432 \u0410\u0432\u0438\u0442\u043e \u0438 \u0448\u0435\u0441\u0442\u044c \u043b\u0435\u0442 \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u043b Data Platform, \u0442\u043e \u0435\u0441\u0442\u044c \u0437\u0430\u043d\u0438\u043c\u0430\u043b\u0441\u044f \u0432\u0441\u0435\u043c\u0438 \u0431\u0430\u0437\u0430\u043c\u0438: \u0430\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c\u0438 (Vertica, ClickHouse), \u043f\u043e\u0442\u043e\u043a\u043e\u0432\u044b\u043c\u0438 \u0438 OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). \u0417\u0430 \u044d\u0442\u043e \u0432\u0440\u0435\u043c\u044f \u044f \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u043b\u0441\u044f \u0441 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0431\u0430\u0437 \u0434\u0430\u043d\u043d\u044b\u0445 \u2014 \u0441\u0430\u043c\u044b\u0445 \u0440\u0430\u0437\u043d\u044b\u0445 \u0438 \u043d\u0435\u043e\u0431\u044b\u0447\u043d\u044b\u0445, \u0438 \u0441 \u043d\u0435\u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u044b\u043c\u0438 \u043a\u0435\u0439\u0441\u0430\u043c\u0438 \u0438\u0445 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u044f. \u0421\u0435\u0439\u0447\u0430\u0441 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91636,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91635","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t