DBA-Bot Joe. Anatoly Stansler (Postgres.ai)

Wie versteht ein Backend-Entwickler, dass eine SQL-Abfrage auf einem „Produkt“ gut funktioniert? In großen oder schnell wachsenden Unternehmen hat nicht jeder Zugang zum „Produkt“. Und mit Zugriff können nicht alle Anfragen schmerzlos geprüft werden und das Erstellen einer Kopie der Datenbank dauert oft Stunden. Um diese Probleme zu lösen, haben wir einen künstlichen DBA geschaffen – Joe. Es wurde bereits in mehreren Unternehmen erfolgreich implementiert und hilft mehr als einem Dutzend Entwicklern.

Video:

Hallo alle! Mein Name ist Anatoly Stansler. Ich arbeite für ein Unternehmen postgres.ai. Wir sind bestrebt, den Entwicklungsprozess zu beschleunigen, indem wir die mit der Arbeit von Postgres verbundenen Verzögerungen bei Entwicklern, DBAs und Qualitätssicherungen beseitigen.

Wir haben großartige Kunden und heute wird ein Teil des Berichts Fällen gewidmet sein, die wir bei der Zusammenarbeit mit ihnen kennengelernt haben. Ich werde darüber sprechen, wie wir ihnen geholfen haben, ziemlich ernste Probleme zu lösen.

Wenn wir komplexe Hochlastmigrationen entwickeln und durchführen, stellen wir uns die Frage: „Wird diese Migration erfolgreich sein?“ Wir nutzen Überprüfungen, wir nutzen das Wissen erfahrenerer Kollegen, DBA-Experten. Und sie können erkennen, ob es fliegen wird oder nicht.

Aber vielleicht wäre es besser, wenn wir es selbst an Kopien in Originalgröße testen könnten. Und heute werden wir einfach darüber reden, welche Ansätze es beim Testen gibt und wie man es besser machen kann und mit welchen Tools. Wir werden auch über die Vor- und Nachteile solcher Ansätze sprechen und darüber, was wir hier beheben können.

Wer hat jemals Indizes direkt am Produkt erstellt oder Änderungen vorgenommen? Ziemlich viel. Und bei wem führte dies dazu, dass Daten verloren gingen oder es zu Ausfällen kam? Dann kennen Sie diesen Schmerz. Gott sei Dank gibt es Backups.

Der erste Ansatz ist das Testen in Produkten. Oder wenn ein Entwickler auf einem lokalen Computer sitzt und Testdaten hat, gibt es eine begrenzte Auswahl. Und wir rollen zur Produktion aus und bekommen diese Situation.

Es tut weh, es ist teuer. Es ist wahrscheinlich am besten, es nicht zu tun.

Und wie geht das am besten?

Nehmen wir das Staging und wählen dort einen Teil des Produkts aus. Oder bestenfalls nehmen wir ein echtes Produkt, alle Daten. Und nachdem wir es vor Ort entwickelt haben, prüfen wir zusätzlich das Staging.

Dies wird es uns ermöglichen, einige der Fehler zu beseitigen, d. h. zu verhindern, dass sie auf dem Produkt erscheinen.

Was sind die Probleme?

• Das Problem ist, dass wir diese Inszenierung mit Kollegen teilen. Und sehr oft kommt es vor, dass man irgendeine Änderung vornimmt, bam – und es keine Daten gibt, die Arbeit ist den Bach runter. Das Staging umfasste mehrere Terabyte. Und man muss lange warten, bis er wieder steigt. Und wir beschließen, es morgen fertigzustellen. Das ist es, wir haben eine Entwicklung.
• Und natürlich arbeiten dort viele Kollegen, viele Teams. Und es muss manuell erfolgen. Und das ist unbequem.

Und es ist erwähnenswert, dass wir nur einen Versuch, einen Versuch haben, wenn wir einige Änderungen an der Datenbank vornehmen, die Daten bearbeiten oder die Struktur ändern möchten. Und wenn etwas schief gelaufen ist, wenn bei der Migration ein Fehler aufgetreten ist, werden wir nicht schnell ein Rollback durchführen.

Dies ist besser als der vorherige Ansatz, aber es besteht immer noch eine hohe Wahrscheinlichkeit, dass ein Fehler in die Produktion gelangt.

Was hindert uns daran, jedem Entwickler einen Prüfstand, eine Kopie in Originalgröße, zur Verfügung zu stellen? Ich denke, es ist klar, was da im Weg steht.

Wer hat eine Datenbank, die größer als ein Terabyte ist? Mehr als die Hälfte des Zimmers.

Und es ist klar, dass die Wartung der Maschinen für jeden Entwickler bei einer so großen Produktion sehr teuer ist und außerdem viel Zeit in Anspruch nimmt.

Wir haben Kunden, die erkannt haben, dass es sehr wichtig ist, alle Änderungen an Kopien in voller Größe zu testen, aber ihre Datenbank ist weniger als ein Terabyte groß und es gibt keine Ressourcen, um für jeden Entwickler einen Prüfstand zu unterhalten. Daher müssen sie die Dumps lokal auf ihren Rechner herunterladen und auf diese Weise testen. Es benötigt viel Zeit.

Selbst wenn Sie dies innerhalb der Infrastruktur tun, ist das Herunterladen von einem Terabyte an Daten pro Stunde bereits sehr gut. Aber sie verwenden logische Dumps, die sie lokal aus der Cloud herunterladen. Bei ihnen beträgt die Geschwindigkeit etwa 200 Gigabyte pro Stunde. Und es dauert immer noch einige Zeit, den logischen Dump zu beenden, die Indizes hochzufahren usw.

Aber sie verwenden diesen Ansatz, weil er es ihnen ermöglicht, das Produkt zuverlässig zu halten.

Was können wir hier tun? Machen wir Prüfstände günstig und geben wir jedem Entwickler seinen eigenen Prüfstand.

Und das ist möglich.

Und wenn wir bei diesem Ansatz für jeden Entwickler dünne Klone erstellen, können wir diese auf einer Maschine teilen. Wenn Sie beispielsweise über eine 10-TB-Datenbank verfügen und diese an 10 Entwickler weitergeben möchten, benötigen Sie keine XNUMX x XNUMX-TB-Datenbanken. Sie benötigen nur eine Maschine, um mit einer Maschine dünne, isolierte Kopien für jeden Entwickler zu erstellen. Wie es funktioniert, erzähle ich euch etwas später.

Echtes Beispiel:

• DB – 4,5 Terabyte.

• Wir können in 30 Sekunden unabhängige Kopien erhalten.

Sie müssen nicht auf einen Prüfstand warten und sich darauf verlassen, wie groß er ist. Sie können es in Sekundenschnelle erhalten. Es werden völlig isolierte Umgebungen sein, die jedoch Daten untereinander austauschen.

Das ist cool. Hier geht es um Magie und ein Paralleluniversum.

In unserem Fall funktioniert das über das OpenZFS-System.

OpenZFS ist ein Copy-on-Write-Dateisystem, das Snapshots und Klone sofort unterstützt. Es ist zuverlässig und skalierbar. Sie ist sehr einfach zu handhaben. Es kann buchstäblich in zwei Teams eingesetzt werden.

Es gibt noch andere Möglichkeiten:

• lvm,

• Speicher (z. B. Pure Storage).

Das Datenbanklabor, von dem ich spreche, ist modular aufgebaut. Kann mit diesen Optionen umgesetzt werden. Aber vorerst haben wir uns auf OpenZFS konzentriert, da es speziell Probleme mit LVM gab.

Wie es funktioniert? Anstatt die Daten jedes Mal zu überschreiben, wenn wir sie ändern, speichern wir sie, indem wir einfach markieren, dass diese neuen Daten von einem neuen Zeitpunkt stammen, einem neuen Snapshot.

Und wenn wir in Zukunft ein Rollback durchführen oder einen neuen Klon einer älteren Version erstellen möchten, sagen wir einfach: „OK, geben Sie uns diese Datenblöcke, die so markiert sind.“

Und dieser Benutzer wird mit einem solchen Datensatz arbeiten. Er wird sie nach und nach verändern, eigene Schnappschüsse machen.

Und wir werden uns verzweigen. In unserem Fall hat jeder Entwickler die Möglichkeit, seinen eigenen Klon zu haben, den er bearbeitet, und die gemeinsam genutzten Daten werden von allen gemeinsam genutzt.

Um ein solches System zu Hause bereitzustellen, müssen Sie zwei Probleme lösen:

• Das erste ist die Quelle der Daten, aus der Sie sie beziehen. Sie können die Replikation mit der Produktion einrichten. Ich hoffe, Sie können die Backups, die Sie konfiguriert haben, bereits verwenden. WAL-E, WAL-G oder Barmann. Und selbst wenn Sie eine Cloud-Lösung wie RDS oder Cloud SQL verwenden, können Sie logische Dumps verwenden. Wir raten Ihnen jedoch trotzdem, Backups zu verwenden, da Sie bei diesem Ansatz auch die physische Struktur der Dateien beibehalten und so noch näher an den Kennzahlen sind, die Sie in der Produktion sehen würden, um bestehende Probleme zu erkennen.

• Der zweite Punkt ist der Ort, an dem Sie das Datenbanklabor hosten möchten. Es könnte eine Cloud sein, es könnte eine On-Premise-Lösung sein. Wichtig ist hier zu erwähnen, dass ZFS die Datenkomprimierung unterstützt. Und das gelingt ihm ganz gut.

Stellen Sie sich vor, dass für jeden dieser Klon, abhängig von den Operationen, die wir mit der Basis durchführen, eine Art Entwickler wächst. Dafür benötigen Entwickler auch Platz. Da wir jedoch eine Basis von 4,5 Terabyte angenommen haben, wird ZFS diese auf 3,5 Terabyte komprimieren. Dies kann je nach Einstellungen variieren. Und wir haben noch Platz für Entwickler.

Ein solches System kann für verschiedene Fälle eingesetzt werden.

• Dies sind Entwickler, DBAs für die Abfragevalidierung und Optimierung.

• Dies kann bei QA-Tests verwendet werden, um eine bestimmte Migration zu testen, bevor wir sie in die Produktion einführen. Und wir können auch spezielle Umgebungen für die Qualitätssicherung mit echten Daten aufbauen, in denen sie neue Funktionen testen können. Und es wird Sekunden dauern, statt Stunden zu warten, und in einigen anderen Fällen, in denen keine dünnen Kopien verwendet werden, vielleicht Tage.

• Und noch ein Fall. Wenn das Unternehmen kein Analysesystem eingerichtet hat, können wir einen dünnen Klon der Produktbasis isolieren und ihn für lange Abfragen oder spezielle Indizes bereitstellen, die in der Analyse verwendet werden können.

Mit diesem Ansatz:

1. Geringe Fehlerwahrscheinlichkeit beim „Produkt“, da wir alle Änderungen anhand von Daten in Originalgröße getestet haben.

2. Bei uns herrscht eine Kultur des Testens, denn jetzt müssen Sie nicht mehr stundenlang auf Ihren eigenen Stand warten.

3. Und es gibt keine Barriere, keine Wartezeiten zwischen den Tests. Sie können tatsächlich hingehen und nachsehen. Und auf diese Weise wird es besser, wenn wir die Entwicklung beschleunigen.

• Es wird weniger Refactoring geben. Es werden weniger Fehler im Produkt landen. Wir werden sie später weniger umgestalten.

• Wir können irreversible Veränderungen rückgängig machen. Dies ist nicht der Standardansatz.

1. Das ist von Vorteil, weil wir uns die Ressourcen der Prüfstände teilen.

Schon gut, aber was könnte noch beschleunigt werden?

Dank eines solchen Systems können wir die Hürde für die Teilnahme an solchen Tests erheblich senken.

Jetzt gibt es einen Teufelskreis, wenn ein Entwickler, um Zugriff auf echte Daten in voller Größe zu erhalten, ein Experte werden muss. Dieser Zugang muss ihm anvertraut werden.

Aber wie kann man wachsen, wenn es nicht da ist? Was aber, wenn Ihnen nur ein sehr kleiner Satz an Testdaten zur Verfügung steht? Dann bekommst du keine wirklichen Erfahrungen.

Wie kommt man aus diesem Kreis heraus? Als erste Schnittstelle, die für Entwickler aller Niveaus praktisch ist, haben wir den Slack-Bot ausgewählt. Es kann aber auch jede andere Schnittstelle sein.

Was ermöglicht es Ihnen? Sie können eine bestimmte Abfrage annehmen und an einen speziellen Kanal für die Datenbank senden. Wir werden innerhalb von Sekunden automatisch einen Thin Clone bereitstellen. Lassen Sie uns diese Anfrage ausführen. Wir sammeln Kennzahlen und Empfehlungen. Lassen Sie uns eine Visualisierung zeigen. Und dann bleibt dieser Klon erhalten, damit diese Abfrage irgendwie optimiert, Indizes hinzugefügt usw. werden kann.

Und auch Slack bietet uns Möglichkeiten für eine sofort einsatzbereite Zusammenarbeit. Da es sich nur um einen Kanal handelt, können Sie direkt im Thread für eine solche Anfrage mit der Diskussion dieser Anfrage beginnen und Ihre Kollegen und Datenbankadministratoren innerhalb des Unternehmens anpingen.

Aber es gibt natürlich Probleme. Da dies die reale Welt ist und wir einen Server verwenden, der viele Klone gleichzeitig hostet, müssen wir den für die Klone verfügbaren Arbeitsspeicher und die CPU-Leistung komprimieren.

Damit diese Tests jedoch plausibel sind, müssen Sie dieses Problem irgendwie lösen.

Es ist klar, dass der wichtige Punkt dieselben Daten sind. Aber wir haben es bereits. Und wir wollen die gleiche Konfiguration erreichen. Und wir können eine so nahezu identische Konfiguration angeben.

Es wäre cool, die gleiche Hardware wie in der Produktion zu haben, aber es kann anders sein.

Erinnern wir uns daran, wie Postgres mit dem Speicher arbeitet. Wir haben zwei Caches. Eines aus dem Dateisystem und ein natives Postgres, also Shared Buffer Cache.

Es ist wichtig zu beachten, dass der Shared Buffer Cache beim Start von Postgres zugewiesen wird, abhängig von der Größe, die Sie in der Konfiguration angeben.

Und der zweite Cache nutzt den gesamten verfügbaren Speicherplatz.

Und wenn wir mehrere Klone auf einer Maschine erstellen, stellt sich heraus, dass wir den Speicher nach und nach füllen. Und im positiven Sinne macht der Shared Buffer Cache 25 % des gesamten auf dem Computer verfügbaren Speichers aus.

Und es stellt sich heraus, dass wir, wenn wir diesen Parameter nicht ändern, nur 4 Instanzen auf einer Maschine ausführen können, d. h. 4 aller dieser Thin Clones. Und das ist natürlich schlecht, denn wir wollen viel mehr davon haben.

Andererseits wird der Puffercache verwendet, um Abfragen für Indizes auszuführen, d. h. der Plan hängt davon ab, wie groß unsere Caches sind. Und wenn wir diesen Parameter einfach nehmen und reduzieren, können sich unsere Pläne stark ändern.

Wenn wir beispielsweise einen großen Cache für Produkte haben, verwendet Postgres lieber einen Index. Und wenn nicht, dann wird es SeqScan geben. Und was wäre der Sinn, wenn unsere Pläne nicht übereinstimmen würden?

Aber hier kommen wir zu dem Schluss, dass der Plan in Postgres tatsächlich nicht von der spezifischen Größe abhängt, die im Shared Buffer im Plan angegeben ist, sondern von der effektiven_cache_größe.

Effective_cache_size ist die geschätzte Menge an Cache, die uns zur Verfügung steht, d. h. die Summe aus Puffercache und Dateisystemcache. Dies wird durch die Konfiguration festgelegt. Und dieser Speicher ist nicht allokiert.

Und aufgrund dieses Parameters können wir Postgres irgendwie austricksen und sagen, dass uns tatsächlich viele Daten zur Verfügung stehen, auch wenn wir diese Daten nicht haben. Und so werden die Pläne vollständig mit der Produktion übereinstimmen.

Dies kann sich jedoch auf das Timing auswirken. Und wir optimieren Abfragen nach Timing, aber es ist wichtig, dass das Timing von vielen Faktoren abhängt:

• Dies hängt von der Last ab, die derzeit auf dem Produkt vorhanden ist.

• Dies hängt von den Eigenschaften der Maschine selbst ab.

Und das ist ein indirekter Parameter, aber tatsächlich können wir genau anhand der Datenmenge optimieren, die diese Abfrage liest, um das Ergebnis zu erhalten.

Und wenn Sie möchten, dass das Timing dem entspricht, was wir in der Produktion sehen werden, müssen wir die ähnlichste Hardware verwenden und möglicherweise sogar noch mehr, damit alle Klone passen. Dies ist jedoch ein Kompromiss, d. h. Sie erhalten die gleichen Pläne, sehen, wie viele Daten eine bestimmte Abfrage liest, und können daraus schließen, ob diese Abfrage gut (oder migriert) oder schlecht ist, sie muss noch optimiert werden .

Werfen wir einen Blick darauf, wie Joe konkret optimiert wird.

Nehmen wir eine Anfrage von einem realen System. In diesem Fall ist die Datenbank 1 Terabyte groß. Und wir möchten die Anzahl der neuen Beiträge zählen, die mehr als 10 Likes hatten.

Wir schreiben eine Nachricht an den Kanal, ein Klon wurde für uns bereitgestellt. Und wir werden sehen, dass eine solche Anfrage in 2,5 Minuten abgeschlossen ist. Das ist das erste, was uns auffällt.

B Joe zeigt Ihnen automatische Empfehlungen basierend auf dem Plan und den Kennzahlen.

Wir werden sehen, dass die Abfrage zu viele Daten verarbeitet, um eine relativ kleine Anzahl von Zeilen zu erhalten. Und es wird eine Art spezialisierter Index benötigt, da wir festgestellt haben, dass die Abfrage zu viele gefilterte Zeilen enthält.

Schauen wir uns genauer an, was passiert ist. Tatsächlich sehen wir, dass wir fast eineinhalb Gigabyte Daten aus dem Dateicache oder sogar von der Festplatte gelesen haben. Und das ist nicht gut, denn wir haben nur 142 Zeilen.

Und es sieht so aus, als hätten wir hier einen Indexscan durchgeführt, der schnell hätte funktionieren sollen, aber da wir zu viele Zeilen herausgefiltert haben (wir mussten sie zählen), hat die Abfrage langsam funktioniert.

Und das geschah im Plan dadurch, dass die Bedingungen in der Abfrage und die Bedingungen im Index teilweise nicht übereinstimmen.

Versuchen wir, den Index präziser zu gestalten und zu sehen, wie sich die Abfrageausführung danach ändert.

Die Erstellung des Index hat ziemlich lange gedauert, aber jetzt überprüfen wir die Abfrage und stellen fest, dass die Zeit statt 2,5 Minuten nur 156 Millisekunden beträgt, was gut genug ist. Und wir lesen nur 6 Megabyte Daten.

Und jetzt verwenden wir nur den Index-Scan.

Eine weitere wichtige Geschichte ist, dass wir den Plan verständlicher präsentieren wollen. Wir haben die Visualisierung mithilfe von Flame Graphs implementiert.

Das ist eine andere Bitte, intensiver. Und wir erstellen Flame Graphs nach zwei Parametern: Dies ist die Datenmenge, die ein bestimmter Knoten im Plan gezählt hat, und das Timing, also die Ausführungszeit des Knotens.

Hier können wir bestimmte Knoten miteinander vergleichen. Und es wird deutlich, welche davon mehr oder weniger benötigt, was bei anderen Rendering-Methoden normalerweise schwierig ist.

Natürlich kennt jeder EXPLAIN.depesz.com. Eine gute Funktion dieser Visualisierung ist, dass wir den Textplan speichern und auch einige grundlegende Parameter in eine Tabelle einfügen, damit wir sie sortieren können.

Und auch Entwickler, die sich noch nicht mit diesem Thema beschäftigt haben, nutzen EXPLAIN.depesz.com, weil sie so einfacher herausfinden können, welche Metriken wichtig sind und welche nicht.

Es gibt einen neuen Ansatz zur Visualisierung – das ist EXPLAIN.DALIBO.com. Sie führen eine Baumvisualisierung durch, aber es ist sehr schwierig, Knoten miteinander zu vergleichen. Hier kann man den Aufbau gut nachvollziehen, allerdings ist bei einer großen Anfrage dann ein Hin- und Herscrollen nötig, aber auch eine Option.

оллаборация

Und wie gesagt, Slack bietet uns die Möglichkeit zur Zusammenarbeit. Wenn wir beispielsweise auf eine komplexe Anfrage stoßen, bei der nicht klar ist, wie optimiert werden soll, können wir dieses Problem mit unseren Kollegen in einem Thread in Slack klären.

Es scheint uns wichtig zu sein, Tests in voller Größe durchzuführen. Zu diesem Zweck haben wir das Update Database Lab-Tool entwickelt, das als Open Source verfügbar ist. Sie können auch den Joe-Bot verwenden. Sie können es gleich jetzt in Angriff nehmen und bei Ihnen vor Ort umsetzen. Alle Ratgeber sind dort verfügbar.

Es ist auch wichtig zu beachten, dass die Lösung selbst nicht revolutionär ist, da es Delphix gibt, sondern dass es sich um eine Unternehmenslösung handelt. Es ist völlig geschlossen, es ist sehr teuer. Wir sind speziell auf Postgres spezialisiert. Dies sind alles Open-Source-Produkte. Begleiten Sie uns!

Hier ende ich. Danke!

Fragen

Guten Tag! Danke für den Bericht! Sehr interessant, besonders für mich, weil ich vor einiger Zeit ungefähr das gleiche Problem gelöst habe. Daher habe ich eine Reihe von Fragen. Hoffentlich bekomme ich zumindest einen Teil davon.

Ich frage mich, wie Sie den Platz für diese Umgebung berechnen? Durch die Technologie können Ihre Klone unter bestimmten Umständen die maximale Größe erreichen. Grob gesagt: Wenn Sie über eine Datenbank mit zehn Terabyte und zehn Klone verfügen, ist es einfach, eine Situation zu simulieren, in der jeder Klon zehn eindeutige Daten wiegt. Wie berechnen Sie diesen Ort, das heißt das Delta, von dem Sie gesprochen haben, in dem diese Klone leben werden?

Gute Frage. Hier ist es wichtig, den Überblick über bestimmte Klone zu behalten. Und wenn bei einem Klon eine zu große Änderung vorliegt und er zu wachsen beginnt, können wir den Benutzer zunächst darüber warnen oder diesen Klon sofort stoppen, damit es nicht zu einem Ausfall kommt.

Ja, ich habe eine verschachtelte Frage. Das heißt, wie stellen Sie den Lebenszyklus dieser Module sicher? Wir haben dieses Problem und eine ganz andere Geschichte. Wie kommt es dazu?

Für jeden Klon gibt es etwas TTL. Grundsätzlich haben wir eine feste TTL.

Was ist, wenn nicht ein Geheimnis?

1 Stunde, d.h. Leerlauf - 1 Stunde. Wenn es nicht genutzt wird, dann knallen wir es. Dies ist jedoch keine Überraschung, da wir den Klon in Sekundenschnelle erstellen können. Und wenn Sie es noch einmal brauchen, dann bitte.

Mich interessiert auch die Wahl der Technologien, da wir beispielsweise aus dem einen oder anderen Grund mehrere Methoden parallel nutzen. Warum ZFS? Warum haben Sie LVM nicht verwendet? Sie haben erwähnt, dass es Probleme mit LVM gab. Was waren die Probleme? Meiner Meinung nach ist die Speicherung die optimalste Option, was die Leistung angeht.

Was ist das Hauptproblem bei ZFS? Die Tatsache, dass Sie auf demselben Host ausgeführt werden müssen, d. h. alle Instanzen laufen auf demselben Betriebssystem. Und im Falle der Lagerung können Sie verschiedene Geräte anschließen. Und der Engpass sind nur die Blöcke, die sich im Speichersystem befinden. Und die Frage nach der Wahl der Technologien ist interessant. Warum nicht LVM?

Konkret können wir LVM beim Treffen besprechen. Was die Lagerung betrifft – sie ist einfach teuer. Wir können das ZFS-System überall implementieren. Sie können es auf Ihrem Computer bereitstellen. Sie können das Repository einfach herunterladen und bereitstellen. ZFS ist fast überall installiert, wenn es um Linux geht. Das heißt, wir erhalten eine sehr flexible Lösung. Und ZFS selbst bietet sofort eine Menge. Sie können so viele Daten hochladen, wie Sie möchten, eine große Anzahl von Festplatten anschließen, es gibt Snapshots. Und wie gesagt, es ist einfach zu verwalten. Das heißt, die Verwendung scheint sehr angenehm zu sein. Er ist geprüft, er ist viele Jahre alt. Er hat eine sehr große Community, die wächst. ZFS ist eine sehr zuverlässige Lösung.

Nikolai Samokhvalov: Darf ich weiter kommentieren? Mein Name ist Nikolay, wir arbeiten mit Anatoly zusammen. Ich stimme zu, dass die Speicherung großartig ist. Und einige unserer Kunden haben Pure Storage usw.

Anatoly hat richtig bemerkt, dass wir uns auf Modularität konzentrieren. Und in Zukunft können Sie eine Schnittstelle implementieren – einen Snapshot erstellen, einen Klon erstellen und den Klon zerstören. Es ist alles einfach. Und Lagerung ist cool, wenn überhaupt.

Aber ZFS ist für jeden verfügbar. DelPhix reicht bereits aus, sie haben 300 Kunden. Davon hat Fortune 100 50 Kunden, d. h. sie richten sich an die NASA usw. Es ist an der Zeit, dass jeder diese Technologie erhält. Und deshalb haben wir einen Open-Source-Core. Wir haben einen Schnittstellenteil, der nicht Open Source ist. Dies ist die Plattform, die wir zeigen werden. Aber wir wollen, dass es für alle zugänglich ist. Wir wollen eine Revolution machen, damit alle Tester auf Laptops nicht mehr raten müssen. Wir müssen SELECT schreiben und sofort sehen, dass es langsam ist. Hören Sie auf, darauf zu warten, dass der DBA Ihnen davon erzählt. Hier ist das Hauptziel. Und ich denke, dass wir alle dazu kommen werden. Und wir machen dieses Ding so, dass es jeder haben kann. Deshalb ZFS, weil es überall verfügbar sein wird. Vielen Dank an die Community für die Lösung von Problemen und für die Verfügbarkeit einer Open-Source-Lizenz usw.*

Grüße! Danke für den Bericht! Mein Name ist Maxim. Wir haben uns mit den gleichen Problemen befasst. Sie haben selbst entschieden. Wie teilen Sie Ressourcen zwischen diesen Klonen? Jeder Klon kann jederzeit sein eigenes Ding machen: Einer testet eine Sache, ein anderer eine andere, jemand erstellt einen Index, jemand hat eine schwere Arbeit. Und wenn Sie immer noch durch CPU dividieren können, wie dividieren Sie dann durch IO? Dies ist die erste Frage.

Und die zweite Frage betrifft die Unähnlichkeit der Stände. Nehmen wir an, ich habe hier ZFS und alles ist cool, aber der Client auf Prod hat kein ZFS, sondern zum Beispiel ext4. Wie in diesem Fall?

Die Fragen sind sehr gut. Ich habe dieses Problem mit der Tatsache, dass wir Ressourcen teilen, kurz erwähnt. Und die Lösung ist diese. Stellen Sie sich vor, Sie führen einen Staging-Test durch. Man kann auch gleichzeitig eine solche Situation haben, dass jemand einem anderen eine Last gibt. Und als Ergebnis sehen Sie unverständliche Messwerte. Sogar das gleiche Problem kann bei Produkt auftreten. Wenn Sie eine Anfrage überprüfen möchten und feststellen, dass es ein Problem damit gibt – sie funktioniert langsam, dann lag das Problem tatsächlich nicht in der Anfrage, sondern in der Tatsache, dass eine Art Parallellast vorliegt.

Und deshalb ist es hier wichtig, sich darauf zu konzentrieren, wie der Plan aussehen wird, welche Schritte wir im Plan unternehmen werden und wie viele Daten wir dafür erheben werden. Die Tatsache, dass unsere Festplatten beispielsweise mit etwas belastet werden, wirkt sich speziell auf das Timing aus. Aber wir können anhand der Datenmenge abschätzen, wie belastet diese Anfrage ist. Es ist nicht so wichtig, dass es gleichzeitig zu einer Art Hinrichtung kommt.

Ich habe zwei Fragen. Das ist sehr cooles Zeug. Gab es Fälle, in denen Produktionsdaten kritisch waren, beispielsweise Kreditkartennummern? Ist schon etwas fertig oder handelt es sich um eine separate Aufgabe? Und die zweite Frage: Gibt es so etwas für MySQL?

Über die Daten. Wir werden Verschleierungen durchführen, bis wir es tun. Wenn Sie jedoch genau Joe bereitstellen und den Entwicklern keinen Zugriff gewähren, gibt es keinen Zugriff auf die Daten. Warum? Weil Joe keine Daten anzeigt. Es werden nur Kennzahlen und Pläne angezeigt und das war's. Dies geschah mit Absicht, da dies eine der Anforderungen unseres Kunden ist. Sie wollten in der Lage sein, zu optimieren, ohne jedem Zugriff zu gewähren.

Über MySQL. Dieses System kann für alles verwendet werden, was den Status auf der Festplatte speichert. Und da wir Postgres machen, erledigen wir jetzt in erster Linie die gesamte Automatisierung für Postgres. Wir möchten das Abrufen von Daten aus einem Backup automatisieren. Wir konfigurieren Postgres richtig. Wir wissen, wie man Pläne usw. aufeinander abstimmt.

Da das System aber erweiterbar ist, kann es auch für MySQL verwendet werden. Und es gibt solche Beispiele. Yandex hat etwas Ähnliches, aber sie veröffentlichen es nirgendwo. Sie verwenden es in Yandex.Metrica. Und es gibt nur eine Geschichte über MySQL. Aber die Technologien sind die gleichen, ZFS.

Danke für den Bericht! Ich habe auch ein paar Fragen. Sie haben erwähnt, dass das Klonen für Analysen genutzt werden kann, um beispielsweise dort zusätzliche Indizes aufzubauen. Können Sie etwas mehr darüber erzählen, wie es funktioniert?

Und ich stelle gleich die zweite Frage nach der Ähnlichkeit der Stände, der Ähnlichkeit der Pläne. Der Plan hängt auch von den von Postgres gesammelten Statistiken ab. Wie lösen Sie dieses Problem?

Den Analysen zufolge gibt es keine konkreten Fälle, da wir es noch nicht genutzt haben, aber es besteht eine solche Möglichkeit. Wenn wir über Indizes sprechen, stellen Sie sich vor, dass eine Abfrage eine Tabelle mit Hunderten Millionen Datensätzen und einer Spalte verfolgt, die in prod normalerweise nicht indiziert ist. Und wir wollen dort einige Daten berechnen. Wenn diese Anfrage an prod gesendet wird, besteht die Möglichkeit, dass sie einfach an prod gesendet wird, da die Anfrage dort eine Minute lang verarbeitet wird.

Ok, lasst uns einen dünnen Klon erstellen, bei dem es nicht schlimm ist, ihn für ein paar Minuten anzuhalten. Und um das Lesen der Analysen komfortabler zu gestalten, werden wir Indizes für die Spalten hinzufügen, an denen wir an Daten interessiert sind.

Der Index wird jedes Mal erstellt?

Sie können es so gestalten, dass wir die Daten berühren, Snapshots erstellen, dann von diesem Snapshot wiederherstellen und neue Anfragen vorantreiben. Das heißt, Sie können es so gestalten, dass Sie neue Klone mit bereits angebrachten Indizes erzeugen können.

Was die Frage zu den Statistiken betrifft: Wenn wir von einem Backup wiederherstellen und eine Replikation durchführen, sind unsere Statistiken genau gleich. Da wir über die gesamte physische Datenstruktur verfügen, werden wir die Daten auch mit allen Statistikmetriken so bereitstellen, wie sie sind.

Hier ist ein weiteres Problem. Wenn Sie eine Cloud-Lösung nutzen, stehen dort nur logische Dumps zur Verfügung, da Google und Amazon die Erstellung einer physischen Kopie nicht zulassen. Es wird ein Problem geben.

Danke für den Bericht. Hier gab es zwei gute Fragen zu MySQL und der gemeinsamen Nutzung von Ressourcen. Tatsächlich kommt es jedoch darauf an, dass es sich hierbei nicht um ein Thema eines bestimmten DBMS handelt, sondern um das Dateisystem als Ganzes. Und dementsprechend sollten auch die Probleme der Ressourcenfreigabe von dort aus gelöst werden, und zwar nicht am Ende von Postgres, sondern im Dateisystem, beispielsweise auf dem Server.

Meine Frage ist etwas anders. Es liegt näher an der mehrschichtigen Datenbank, bei der es mehrere Schichten gibt. Beispielsweise haben wir ein zehn Terabyte großes Image-Update eingerichtet, das wir replizieren. Und wir nutzen diese Lösung speziell für Datenbanken. Die Replikation läuft, die Daten werden aktualisiert. Es arbeiten 100 Mitarbeiter parallel, die ständig diese unterschiedlichen Aufnahmen starten. Was zu tun ist? Wie kann man sicherstellen, dass es keinen Konflikt gibt, dass sie einen gestartet haben, und dass sich dann das Dateisystem geändert hat und alle diese Bilder verschwunden sind?

Sie werden nicht gehen, weil ZFS so funktioniert. Wir können die Dateisystemänderungen, die durch die Replikation entstehen, separat in einem Thread aufbewahren. Und behalten Sie die Klone, die Entwickler für ältere Versionen der Daten verwenden. Und bei uns funktioniert es, damit ist alles in Ordnung.

Es stellt sich heraus, dass das Update als zusätzliche Ebene erfolgt und alle neuen Bilder bereits auf dieser Ebene basieren, oder?

Aus früheren Ebenen, die aus früheren Replikationen stammten.

Die vorherigen Ebenen werden gelöscht, beziehen sich jedoch auf die alte Ebene und werden neue Bilder von der letzten Ebene übernommen, die im Update empfangen wurde?

Im Allgemeinen ja.

Als Konsequenz haben wir dann bis zu eine Feige an Schichten. Und mit der Zeit müssen sie komprimiert werden?

Ja, alles ist korrekt. Es gibt ein Fenster. Wir machen wöchentlich Schnappschüsse. Es hängt davon ab, über welche Ressource Sie verfügen. Wenn Sie viele Daten speichern können, können Sie Snapshots über einen längeren Zeitraum speichern. Sie werden nicht von alleine verschwinden. Es kommt zu keiner Datenbeschädigung. Wenn die Snapshots unserer Meinung nach veraltet sind, d. h. es hängt von den Richtlinien im Unternehmen ab, können wir sie einfach löschen und Speicherplatz freigeben.

Hallo, danke für den Bericht! Frage zu Joe. Sie sagten, der Kunde wolle nicht jedem Zugriff auf die Daten gewähren. Streng genommen kann eine Person, wenn sie das Ergebnis von Explain Analyze hat, einen Blick auf die Daten werfen.

Es ist wie es ist. Wir können zum Beispiel schreiben: „SELECT FROM WHERE email = to that“. Das heißt, wir werden die Daten selbst nicht sehen, aber wir können einige indirekte Anzeichen erkennen. Das muss verstanden werden. Aber andererseits ist alles da. Wir führen eine Protokollprüfung durch und haben die Kontrolle über andere Kollegen, die ebenfalls sehen, was die Entwickler tun. Und wenn jemand dies versucht, wird der Sicherheitsdienst zu ihm kommen und sich um das Problem kümmern.

Guten Tag! Danke für den Bericht! Ich habe eine kurze Frage. Wenn das Unternehmen Slack nicht nutzt, gibt es jetzt eine Bindung dazu oder ist es für Entwickler möglich, Instanzen bereitzustellen, um eine Testanwendung mit den Datenbanken zu verbinden?

Jetzt gibt es einen Link zu Slack, d.h. es gibt keinen anderen Messenger, aber ich möchte unbedingt auch andere Messenger unterstützen. Was kannst du tun? Sie können DB Lab ohne Joe bereitstellen, mithilfe der REST-API oder mithilfe unserer Plattform Klone erstellen und eine Verbindung mit PSQL herstellen. Dies ist jedoch möglich, wenn Sie bereit sind, Ihren Entwicklern Zugriff auf die Daten zu gewähren, da kein Bildschirm mehr vorhanden ist.

Ich brauche diese Ebene nicht, aber ich brauche eine solche Gelegenheit.

Dann ja, es ist machbar.

Source: habr.com