Der tempor\u00e4re Speicher wird geleert, und die Ressourcen werden freigegeben.<\/li>\n<\/ul>\nIn dieser Architektur zahlen wir nur f\u00fcr den Prozess der Ausf\u00fchrung der Anfrage. Keine Anfragen \u2014 keine Kosten.<\/p>\n
Beispielsweise zeigt sich bei Athena, dass die Serverless-Datenbank mit realen Abfragen von Dutzenden und Hunderten von Terabyte Daten funktioniert. F\u00fcr Hunderte von Terabyte sind Hunderte von Servern erforderlich, aber wir m\u00fcssen nicht f\u00fcr diese bezahlen \u2014 wir zahlen nur f\u00fcr die Abfragen. Die Geschwindigkeit jeder Abfrage ist (sehr) niedrig im Vergleich zu spezialisierten Analyse-Datenbanken wie Vertica, aber wir zahlen auch nicht f\u00fcr Ausfallzeiten.<\/p>\n
Eine solche Datenbank ist f\u00fcr sporadische analytische Ad-hoc-Abfragen geeignet. Beispielsweise, wenn wir spontan eine Hypothese mit einem riesigen Datenvolumen \u00fcberpr\u00fcfen m\u00f6chten. F\u00fcr diese F\u00e4lle ist Athena ideal. F\u00fcr regelm\u00e4\u00dfige Abfragen ist ein solches System kostspielig. In diesem Fall sollten Sie die Daten in einer spezialisierten L\u00f6sung zwischenspeichern. <\/p>\n
Serverless f\u00fcr OLTP-L\u00f6sungen<\/h2>\n \nIm vorherigen Beispiel wurden OLAP-Aufgaben (analytische) behandelt. Jetzt betrachten wir OLTP-Aufgaben.<\/p>\n
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\u00fcgen wir zus\u00e4tzliche 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.<\/p>\n
Diese Idee wird in einer Datenbank namens Aurora Serverless AWS umgesetzt. Das Prinzip ist einfach: Eine Proxy-Flotte empf\u00e4ngt Anfragen von externen Anwendungen. Bei steigender Last weist sie Rechenressourcen aus bereits vorgew\u00e4rmten minimalen Instances zu \u2013 die Verbindung erfolgt sehr schnell. Das Abschalten von Instances erfolgt auf die gleiche Weise.<\/p>\n
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\u00fcgt \u00fcber eigenen Arbeitsspeicher, Prozessor und minimalen Speicherplatz. Dementsprechend gibt es einen Master und die anderen sind nur f\u00fcr Lesevorg\u00e4nge gedacht.<\/p>\n
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).<\/p>\n
Die Aurora Serverless-Datenbank kann die Leseanforderungen skalieren. Dies wird jedoch nicht direkt in der Dokumentation erw\u00e4hnt. Es k\u00f6nnte der Eindruck entstehen, dass sie ein Multi-Master-System aktivieren k\u00f6nnen. Doch es gibt kein magisches Geheimnis. <\/p>\n
Diese Datenbank eignet sich hervorragend, um keine hohen Ausgaben f\u00fcr 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\u00fcr Instanzen, wenn kein Zugriff besteht. Wenn jedoch pl\u00f6tzlich eine Belastung auftritt, etwa nach einer Konferenz oder einer Werbekampagne, str\u00f6men viele Menschen auf die Website und die Last steigt stark an. Aurora Serverless bew\u00e4ltigt diese Last automatisch und f\u00fcgt schnell die fehlenden Ressourcen (ACU) hinzu. Nach der Konferenz vergessen alle den Prototyp, die Server (ACU) gehen offline und die Ausgaben sinken auf null \u2014 sehr praktisch.<\/p>\n
Diese L\u00f6sung ist nicht f\u00fcr 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 \u201eScale Point\u201c \u2014 dem Zeitpunkt, wenn die Datenbank nicht von einer Transaktion gehalten wird, keine tempor\u00e4ren 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. <\/p>\n
Magie gibt es nicht \u2013 es ist ganz normales PostgreSQL. Aber der Prozess zum Hinzuf\u00fcgen und Trennen von Maschinen ist teilweise automatisiert.<\/p>\n
Serverless by design<\/h2>\n \nAurora Serverless ist eine alte Datenbank, die f\u00fcr die Cloud neu geschrieben wurde, um die spezifischen Vorteile von Serverless zu nutzen. Jetzt m\u00f6chte ich Ihnen von einer Datenbank erz\u00e4hlen, die von Anfang an f\u00fcr die Cloud und den Serverless-Ansatz entwickelt wurde \u2013 Serverless-by-design. Sie wurde von Anfang an ohne die Annahme entwickelt, dass sie auf physischen Servern l\u00e4uft.<\/p>\n
Diese Datenbank hei\u00dft Snowflake. Sie besteht aus drei Schl\u00fcsselmolek\u00fclen.<\/p>\n
Der zweite Block besteht aus vielen virtuellen Rechenclustern f\u00fcr Berechnungen (in der Abbildung \u2013 eine Gruppe blauer Kreise).<\/p>\n
Der dritte Block ist ein Datenspeichersystem auf Basis von S3. S3 ist ein unbegrenzter Objektspeicher in AWS, sozusagen ein unbegrenzter Dropbox-Dienst f\u00fcr Unternehmen.<\/p>\n
Schauen wir uns an, wie Snowflake funktioniert, unter der Annahme eines kalten Starts. Das hei\u00dft, die Datenbank existiert, die Daten sind geladen, aber es gibt keine aktiven Abfragen. Wenn also keine Abfragen an die Datenbank gestellt werden, l\u00e4uft 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\u00fcr den Speicherplatz, der von den Daten belegt wird. Der Preis f\u00fcr den Speicherplatz ist sehr niedrig (insbesondere unter Ber\u00fccksichtigung der erheblichen Kompression). Der Metadatenservice l\u00e4uft ebenfalls st\u00e4ndig, ben\u00f6tigt jedoch f\u00fcr die Optimierung der Abfragen nicht viele Ressourcen, sodass man den Service als quasi kostenlos betrachten kann. <\/p>\n
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\u00fcgbaren Daten und die Berechtigungen des Benutzers und erstellt, sofern alles in Ordnung ist, einen Plan zur Verarbeitung der Abfrage.<\/p>\n
Anschlie\u00dfend initiiert der Dienst den Start des Rechenclusters. Ein Rechencluster besteht aus Servern, die Berechnungen durchf\u00fchren. Das bedeutet, es kann aus einem, zwei, vier, acht, sechzehn, oder sogar dreiunddrei\u00dfig Servern bestehen \u2013 je nachdem, wie viele Sie ben\u00f6tigen. Sie geben eine Anfrage ein, und sofort beginnt der Start dieses Clusters. Das dauert tats\u00e4chlich nur Sekunden.<\/p>\n
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\u00e4ge in eine andere Tabelle einf\u00fcgen kann, was zur Entstehung einer neuen Partition im Rechencluster f\u00fchrt, die wiederum automatisch im zentralen S3-Speicher gespeichert wird.<\/p>\n
Das oben beschriebene Szenario, vom Eintritt des Nutzers bis zum Start des Clusters, Ladevorg\u00e4ngen, der Ausf\u00fchrung 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\u00f6\u00dfe, 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\u00fcgbar, abh\u00e4ngig von der Komplexit\u00e4t der Anfragen. Sie zahlen jedoch nur f\u00fcr die Minuten, in denen der Cluster tats\u00e4chlich 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.<\/p>\n
Ein v\u00f6llig realistisches Szenario ist, dass Sie eine Anfrage senden, der Cluster sich innerhalb einer Minute aufbaut, eine weitere Minute f\u00fcr die Berechnung ben\u00f6tigt wird, und dann f\u00fcnf Minuten f\u00fcr das Abschalten, sodass Sie letztendlich nur f\u00fcr sieben Minuten Betriebszeit dieses Clusters bezahlen und nicht f\u00fcr Monate oder Jahre.<\/p>\n
Das erste Szenario beschrieb die Verwendung von Snowflake in einer Einbenutzerumgebung. Lassen Sie uns nun annehmen, dass es viele Nutzer gibt, was n\u00e4her an einem realistischen Szenario liegt.<\/p>\n
Stellen wir uns vor, wir haben viele Analysten und Tableau-Berichte, die unsere Datenbank st\u00e4ndig mit einer Vielzahl einfacher analytischer SQL-Abfragen bombardieren.<\/p>\n
Dar\u00fcber 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. <\/p>\n
F\u00fcr die oben beschriebenen beiden Lasttypen erm\u00f6glicht es Snowflake, mehrere unabh\u00e4ngige Rechencluster unterschiedlicher Leistung hochzufahren. Diese Rechencluster arbeiten unabh\u00e4ngig, aber mit konsistenten gemeinsamen Daten.<\/p>\n
F\u00fcr eine gro\u00dfe Anzahl leichter Abfragen k\u00f6nnen 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: \u201eSnowflake, starte ein kleines Cluster. Wenn die Last \u00fcber einen bestimmten Wert steigt, starte ein \u00e4hnliches zweites oder drittes. Wenn die Last sinkt, schalte die \u00fcbersch\u00fcssigen ab.\u201c Damit stehen Ihnen unabh\u00e4ngig von der Anzahl der Analysten, die Berichte einsehen, gen\u00fcgend Ressourcen zur Verf\u00fcgung.<\/p>\n
Wenn die Analysten schlafen und niemand die Berichte einsehen, k\u00f6nnen die Cluster vollst\u00e4ndig abgeschaltet 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 rund 32 Maschinen bereitstellen. Dieses Cluster wird ebenfalls nur f\u00fcr die Minuten und Stunden berechnet, in denen Ihr gro\u00dfer Auftrag l\u00e4uft.<\/p>\n
Die oben beschriebene M\u00f6glichkeit erlaubt es, nicht nur 2, sondern auch mehrere Arten von Lasten (ETL, Monitoring, Materialisierung von Berichten, ...) nach Clustern zu trennen.<\/p>\n
Zusammenfassend l\u00e4sst sich sagen, dass Snowflake eine ansprechende Idee mit einer funktionalen Umsetzung kombiniert. Bei ManyChat nutzen wir Snowflake zur Analyse aller verf\u00fcgbaren Daten. Wir haben nicht drei Cluster wie in der Beispielbeschreibung, sondern zwischen 5 und 9, in verschiedenen Gr\u00f6\u00dfen. Es gibt bei uns Cluster mit 16 Maschinen, 2 Maschinen und auch super kleine 1-Maschinen-Cluster f\u00fcr bestimmte Aufgaben. Diese verteilen die Last erfolgreich und erm\u00f6glichen uns signifikante Einsparungen.<\/p>\n
Die Datenbank skaliert erfolgreich sowohl die Lese- als auch die Schreiblast. Das stellt einen enormen Unterschied und einen gro\u00dfen Fortschritt im Vergleich zu \u201eAurora\u201c dar, die nur die Lese-Last bew\u00e4ltigen konnte. Snowflake erm\u00f6glicht es, mit diesen Rechenclustern auch die Schreiblast zu skalieren. Wie bereits erw\u00e4hnt, verwenden wir bei ManyChat mehrere Cluster; kleinere und super kleine Cluster werden haupts\u00e4chlich f\u00fcr ETL, also das Laden von Daten, verwendet. Die Analysten arbeiten bereits auf den mittleren Clustern, die von der ETL-Last absolut unber\u00fchrt bleiben, und daher sehr schnell arbeiten. <\/p>\n
Daher eignet sich die Datenbank gut f\u00fcr OLAP-Anwendungen. Leider ist sie jedoch noch nicht f\u00fcr 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\u00fcr OLTP-Lasten noch nicht schnell genug. Sekundenwartezeiten sind f\u00fcr OLAP-Anwendungen in Ordnung, aber f\u00fcr OLTP-Anwendungen sind sie inakzeptabel \u2013 ideal w\u00e4ren 100 ms, noch besser 10 ms.<\/p>\n
Zusammenfassung<\/h2>\n \nEine serverlose Datenbank ist m\u00f6glich durch die Trennung der Datenbank in stateless und stateful Teile. Sie haben sicherlich bemerkt, dass im gesamten Beispiel der stateful Teil \u2013 vereinfacht gesagt \u2013 die Speicherung von Mikropartitionen in S3 ist, w\u00e4hrend stateless der Optimierer ist, der mit Metadaten arbeitet und Sicherheitsfragen behandelt, die als unabh\u00e4ngige, leichtgewichtige stateless Dienste hochgefahren werden k\u00f6nnen.<\/p>\n
Die Ausf\u00fchrung von SQL-Anfragen kann auch als Dienste mit leichtem Zustand betrachtet werden, die im serverlosen Modus auftauchen k\u00f6nnen, wie f\u00fcr Rechencluster von Snowflake, nur die ben\u00f6tigten Daten herunterladen, die Abfrage ausf\u00fchren und dann \"schlummern\".<\/p>\n
Serverless-Datenbanken auf Produktionsniveau sind jetzt verf\u00fcgbar und funktionsf\u00e4hig. Diese serverlosen Datenbanken sind bereits darauf vorbereitet, OLAP-Aufgaben zu bew\u00e4ltigen. Leider haben sie f\u00fcr OLTP-Aufgaben\u2026 einige Einschr\u00e4nkungen, 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\u00e4ndig serverlos und ohne Einschr\u00e4nkungen nutzen kann, \u00e4hnlich wie bei Aurora.<\/p>\n
Ich hoffe, Sie fanden es interessant. Auf in die 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