Wie versteht ein Backend-Entwickler, dass eine SQL-Abfrage in der Produktion gut funktionieren wird? In großen oder schnell wachsenden Unternehmen haben nicht alle Zugang zur Produktion. Und auch mit Zugang können viele Abfragen nicht schmerzfrei getestet 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. Er wurde bereits erfolgreich in mehreren Unternehmen implementiert und hilft nicht nur einem Dutzend von Entwicklern.
Video:
Hallo zusammen! Mein Name ist Anatoli Stansler. Ich arbeite bei . Wir kümmern uns darum, den Entwicklungsprozess zu beschleunigen, indem wir Verzögerungen, die mit der Nutzung von Postgres verbunden sind, für Entwickler, DBAs und QA eliminieren.
Wir haben großartige Kunden, und heute wird ein Teil des Vortrags den Fällen gewidmet sein, die wir in der Zusammenarbeit mit ihnen erlebt haben. Ich werde erzählen, wie wir ihnen geholfen haben, ernsthafte Probleme zu lösen.
Wenn wir entwickeln und komplexe belastete Migrationen durchführen, stellen wir uns die Frage: „Wird diese Migration gelingen?“. Wir nutzen Reviews, wir profitieren vom Wissen erfahrenerer Kollegen, DBA-Experten. Und sie können sagen, ob es funktionieren wird oder nicht.
Aber es wäre vielleicht besser, wenn wir dies selbst auf vollständigen Kopien testen könnten. Heute werden wir genau darüber sprechen, welche Ansätze es derzeit für Tests gibt und wie man es besser machen kann und mit welchen Tools. Außerdem werden wir die Vor- und Nachteile solcher Ansätze besprechen und was wir hier verbessern können.
Wer hat jemals direkt in der Produktion Indizes erstellt oder Änderungen vorgenommen? Ziemlich viele. Und bei wem hat das dazu geführt, 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 der Produktion. Oder wenn ein Entwickler von seinem lokalen Rechner aus arbeitet, hat er Testdaten, es gibt eine begrenzte Auswahl. Und wir bringen es in die Produktion und erhalten so eine Situation.
Es ist schmerzhaft, es ist kostspielig. Wahrscheinlich sollte man das besser nicht tun.
Wie könnte man es besser machen?
Lassen Sie uns Staging nehmen und einen Teil der Produktion dorthin auslagern. Oder, im besten Fall, nehmen wir die echte Produktion, alle Daten. Und nachdem wir lokal entwickelt haben, sollten wir auch auf Staging zusätzliche Prüfungen durchführen.
Das wird uns helfen, einen Teil der Fehler zu beseitigen, d.h. sie in der Produktion zu vermeiden.
Welche Probleme gibt es?
- Das Problem ist, dass wir diese Staging-Umgebung mit Kollegen teilen. Und es kommt sehr oft vor, dass du eine Änderung vornimmst, zack – und keine Daten mehr da sind, die Arbeit ist umsonst. Das Staging war mehrere Terabyte groß. Und es dauert lange, bis es wieder online ist. Und wir entscheiden, dass wir es morgen weiterbearbeiten. Das heißt, unsere Entwicklung steht still.
- Und natürlich arbeiten dort viele Kollegen, viele Teams. Und das muss man manuell abstimmen. Das ist unpraktisch.
Es ist erwähnenswert, dass wir nur einen Versuch haben, einen Schuss, wenn wir Änderungen an der Datenbank vornehmen, Daten anpassen oder die Struktur ändern wollen. Und wenn etwas schiefgeht, wenn ein Fehler bei der Migration auftritt, können wir uns nicht schnell zurückziehen.
Es 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 eine Testumgebung, eine vollwertige Kopie zu geben? Ich denke, das ist klar.
Wer hat eine Datenbank, die größer als ein Terabyte ist? Mehr als die Hälfte des Raums.
Und es ist klar, dass es sehr teuer und zudem zeitaufwendig ist, Maschinen für jeden Entwickler bereitzustellen, wenn die Produktionsumgebung so groß ist.
Wir haben Kunden, die erkannt haben, dass es sehr wichtig ist, alle Änderungen an vollwertigen Kopien zu testen, aber ihre Datenbanken sind kleiner als ein Terabyte und sie haben nicht die Ressourcen, um für jeden Entwickler eine Testumgebung bereitzustellen. Deshalb müssen sie die Dumps lokal auf ihren Rechner herunterladen und auf diese Weise testen. Das nimmt eine Menge Zeit in Anspruch.
Selbst wenn Sie das innerhalb der Infrastruktur erledigen, ist es schon sehr gut, einen Terabyte Daten in einer Stunde herunterzuladen. Aber sie verwenden logische Dumps, sie laden lokal aus der Cloud herunter. Für sie liegt die Geschwindigkeit bei etwa 200 Gigabyte pro Stunde. Und es dauert auch Zeit, um aus dem logischen Dump zu entpacken, Indizes aufzuspielen usw.
Aber sie verwenden diesen Ansatz, weil es hilft, die Produktion stabil zu halten.
Was können wir hier tun? Lassen Sie uns dafür sorgen, dass die Testumgebungen kostengünstig sind und jedem Entwickler seine eigene Testumgebung zur Verfügung gestellt wird.
Und das ist möglich.
Und bei diesem Ansatz, wenn wir dünne Klone für jeden Entwickler erstellen, können wir das auf einem Gerät teilen. Wenn Sie beispielsweise eine vier Terabyte große Datenbank haben und diese 10 Entwicklern zur Verfügung stellen möchten, müssen Sie nicht 10 mal eine vier Terabyte große Datenbank haben. Eine Maschine reicht aus, um dünne, isolierte Kopien für jeden Entwickler zu erstellen, indem Sie eine Maschine verwenden. Wie das funktioniert, werde ich später erläutern.
Echtes Beispiel:
Datenbank – 4,5 Terabyte.
Wir können unabhängige Kopien in 30 Sekunden erhalten.
Sie müssen nicht auf eine Testumgebung warten und von ihrer Größe abhängig sein. Sie können sie in Sekundenschnelle erhalten. Dies werden vollständig isolierte Umgebungen sein, die jedoch die Daten untereinander teilen.
Das ist cool. Hier sprechen wir von Magie und Paralleluniversen.
In unserem Fall funktioniert das mit dem OpenZFS-System.
OpenZFS ist ein Copy-on-Write-Dateisystem, das von Haus aus Snapshots und Klone unterstützt. Es ist zuverlässig und skalierbar. Es lässt sich ganz einfach verwalten. Man kann es mit nur zwei Befehlen bereitstellen.
Es gibt andere Optionen:
LVM,
Speichersysteme (z. B. Pure Storage).
Die Datenbanklabors, über die ich spreche, sind modular. Man kann sie unter Verwendung solcher Optionen implementieren. Aber bisher haben wir uns auf OpenZFS konzentriert, da es speziell mit LVM Probleme gab.
Wie funktioniert das? Anstatt die Daten jedes Mal neu zu schreiben, wenn wir sie ändern, speichern wir sie, indem wir einfach kennzeichnen, dass diese neuen Daten zu einem neuen Zeitpunkt, zu einem neuen Snapshot gehören.
Und wenn wir später zurückrollen oder einen neuen Klon von einer älteren Version erstellen möchten, sagen wir einfach: „Ok, geben Sie uns die Datenblöcke, die so gekennzeichnet sind“.
Und der Benutzer wird mit diesem Datensatz arbeiten. Er wird diese nach und nach ändern und seine Snapshots erstellen.
Und wir werden Verzweigungen haben. Jeder Entwickler hat in unserem Fall die Möglichkeit, seinen eigenen Klon zu haben, den er bearbeitet, und die gemeinsamen Daten werden unter allen geteilt.
Um ein solches System bei sich zu implementieren, müssen zwei Probleme gelöst werden:
Die erste ist die Datenquelle, von der Sie sie abrufen. Sie können die Replikation von der Produktion einstellen. Sie können bereits konfigurierte Backups verwenden, hoffe ich. WAL-E, WAL-G oder Barman. Und selbst wenn Sie eine Cloud-Lösung wie RDS oder Cloud SQL verwenden, können Sie logische Dumps nutzen. Aber wir empfehlen Ihnen dennoch, Backups zu verwenden, denn bei diesem Ansatz bleibt Ihnen auch die physische Struktur der Dateien erhalten, was es ermöglicht, näher an den Metriken zu sein, die Sie in der Produktion sehen würden, um die Probleme zu erkennen, die es gibt.
Die zweite ist der Ort, an dem Sie Database Lab hosten möchten. Das kann in der Cloud sein oder vor Ort. Hier ist wichtig zu erwähnen, dass ZFS Datenkompression unterstützt. Und das macht es ziemlich gut.
Stellen Sie sich vor, dass jeder solcher Klone, abhängig von den Operationen, die wir mit der Datenbank durchführen, eine Art Dev-Ressource aufbauen wird. Dafür benötigt dieser Dev ebenfalls Platz. Aber da wir eine Datenbank von 4,5 Terabyte übernommen haben, wird ZFS sie auf 3,5 Terabyte komprimieren. Das kann je nach Einstellungen variiert werden. Und wir haben noch Platz für Dev.
Ein solches System kann für verschiedene Anwendungsfälle genutzt werden.
Das sind Entwickler, DBAs zur Überprüfung von Abfragen, zur Optimierung.
Das kann im QA-Testen verwendet werden, um eine spezifische Migration zu prüfen, bevor wir sie in die Produktion bringen. Außerdem können wir spezielle Umgebungen für QA mit echten Daten hochfahren, in denen sie neue Funktionen testen können. Und das wird Sekunden dauern anstatt Stunden, vielleicht sogar Tage in anderen Fällen, wo dünne Kopien nicht verwendet werden.
Und noch ein zusätzlicher Anwendungsfall. Wenn im Unternehmen kein Analysesystem eingerichtet ist, können wir einen dünnen Klon der Produktionsdatenbank erstellen und ihn für langwierige Abfragen oder spezielle Indizes, die möglicherweise in der Analyse Verwendung finden, zur Verfügung stellen.
Mit diesem Ansatz:
Geringe Fehlerwahrscheinlichkeit in der Produktion, da wir alle Änderungen mit vollständigen Daten getestet haben.
Wir schaffen eine Testkultur, da man nun nicht stundenlang auf seine eigene Umgebung warten muss.
Es gibt keine Barriere, kein Warten zwischen den Tests. Man kann tatsächlich gehen und alles überprüfen. Und das wird besser sein, da wir die Entwicklung beschleunigen werden.
Es wird weniger Refactoring geben. Weniger Bugs gelangen in die Produktion. Wir werden sie später weniger refaktorisieren.
Wir können irreversible Änderungen vornehmen. Das gibt es in den Standardansätzen nicht.
- Das ist vorteilhaft, da wir die Ressourcen der Teststände teilen.
Das ist schon gut, aber was könnte noch beschleunigt werden?
Dank eines solchen Systems können wir die Einstiegshürde zu solchen Tests erheblich senken.
Aktuell gibt es einen Teufelskreis, bei dem Entwickler, um Zugriff auf echte, vollständige Daten zu erhalten, Experten werden müssen. Sie müssen diesen Zugang vertrauensvoll erhalten.
Aber wie soll man wachsen, wenn dieser Zugang fehlt? Was ist, wenn dir nur eine sehr kleine Menge an Testdaten zur Verfügung steht? Dann wirst du keine reale Erfahrung sammeln können.
Wie kommen wir aus diesem Kreis heraus? Als erste Schnittstelle, die für Entwickler aller Level bequem ist, haben wir einen Slack-Bot gewählt. Aber es könnte auch jede andere Schnittstelle sein.
Was erlaubt er? Man kann eine spezifische Abfrage nehmen und sie in einen speziellen Kanal für die Datenbank senden. Wir werden automatisch in wenigen Sekunden einen schlanken Klon bereitstellen. Wir führen diese Abfrage aus. Sammeln Metriken und Empfehlungen. Zeigen eine Visualisierung an. Und dieser Klon bleibt dann vorhanden, damit diese Abfrage optimiert, Indizes hinzugefügt usw. werden kann.
Und außerdem bietet uns Slack out-of-the-box Kollaboration Möglichkeiten. Da es sich einfach um einen Kanal handelt, kann man direkt dort im Thread mit dieser Abfrage beginnen, diese Abfrage diskutieren, seine Kollegen und DBAs, die innerhalb des Unternehmens sind, anpingen.
Aber es gibt natürlich auch Probleme. Da dies die reale Welt ist und wir einen Server nutzen, auf dem viele Klone gleichzeitig gehostet werden, müssen wir die Speichermenge und die verfügbare Rechenleistung für die Klone einschränken.
Um diese Tests aber glaubwürdig zu gestalten, müssen wir dieses Problem auf irgendeine Weise lösen.
Es ist klar, dass identische Daten ein wichtiger Punkt sind. Aber das haben wir bereits. Und wir streben eine identische Konfiguration an. Und wir können eine nahezu identische Konfiguration bereitstellen.
Es wäre großartig, die gleiche Hardware wie in der Produktion zu haben, aber sie kann abweichen.
Lass uns daran erinnern, wie Postgres mit Speicher arbeitet. Wir haben zwei Caches. Einen von der Dateisystem- und einen eigenen Postgres, d.h. Shared Buffer Cache.
Es ist wichtig zu beachten, dass der Shared Buffer Cache beim Start von Postgres abhängig von der Größe, die Sie in der Konfiguration festlegen, zugewiesen wird.
Der zweite Cache nutzt den gesamten verfügbaren Speicherplatz.
Und wenn wir mehrere Klone auf einer Maschine erstellen, füllen wir nach und nach den Speicher. Optimalerweise sollte der Shared Buffer Cache 25 % des gesamten Speichers betragen, der auf der Maschine verfügbar ist.
Das bedeutet, dass wir, wenn wir diesen Parameter nicht ändern, nur 4 Instanzen auf einer Maschine ausführen können, also insgesamt 4 solcher schlanken Klone. Das ist natürlich nicht ideal, da wir gerne viel mehr hätten.
Andererseits wird der Buffer Cache zur Ausführung von Abfragen, für Indizes verwendet; das bedeutet, der Plan hängt von der Größe unserer Caches ab. Wenn wir diesen Parameter einfach verringern, könnten sich unsere Pläne erheblich ändern.
Zum Beispiel, wenn wir auf prod einen großen Cache haben, wird Postgres bevorzugen, den Index zu verwenden. Andernfalls wird SeqScan verwendet. Was hätte es für einen Sinn, wenn unsere Pläne nicht übereinstimmen würden?
Hier kommen wir zu der Erkenntnis, dass der Plan in Postgres tatsächlich nicht von der spezifischen Größe des Shared Buffers abhängt, sondern vom effective_cache_size.
Effective_cache_size ist das geschätzte Cache-Volumen, das uns zur Verfügung steht, also die Summe aus Buffer Cache und Dateisystem-Cache. Dies wird in der Konfiguration festgelegt. Dieser Speicher wird nicht zugewiesen.
Anhand dieses Parameters können wir Postgres gewissermaßen täuschen, indem wir sagen, dass uns tatsächlich viele Daten zur Verfügung stehen, auch wenn wir diese Daten nicht haben. So werden die Pläne vollständig mit der Produktionsumgebung übereinstimmen.
Dies könnte jedoch Auswirkungen auf das Timing haben. Wir optimieren unsere Anfragen nach dem Timing, aber es ist wichtig, dass das Timing von vielen Faktoren abhängt:
Es hängt von der aktuellen Last auf prod ab.
Es hängt von den Eigenschaften der Maschine selbst ab.
Und das ist ein indirekter Parameter, aber wir können tatsächlich basierend auf der Menge an Daten optimieren, die diese Abfrage liest, um ein Ergebnis zu erzielen.
Und wenn wir möchten, dass das Timing dem entspricht, was wir in der Prod sehen, müssen wir die ähnlichste Hardware nehmen und möglicherweise sogar mehr, damit alle Klone Platz finden. Aber das ist ein Kompromiss, d. h. Sie erhalten die gleichen Pläne, Sie sehen, wie viele Daten eine bestimmte Anfrage liest und können Schlussfolgerungen ziehen – diese Anfrage ist gut (oder die Migration) oder schlecht, sie muss weiter optimiert werden.
Lassen Sie uns analysieren, wie die Optimierung konkret mit Joe abläuft.
Nehmen wir eine Anfrage aus einem realen System. In diesem Fall beträgt die Datenbank 1 Terabyte. Und wir möchten die Anzahl der frischen Beiträge zählen, die mehr als 10 Likes hatten.
Wir senden eine Nachricht in den Kanal, ein Klon wurde für uns bereitgestellt. Und wir sehen, dass eine solche Anfrage in 2,5 Minuten bearbeitet wird. Das ist das Erste, was wir bemerken.
B Joe zeigt automatisierte Empfehlungen basierend auf dem Plan und den Metriken.
Wir werden sehen, dass die Anfrage zu viele Daten verarbeitet, um relativ wenige Zeilen zu erhalten. Und es ist ein spezieller Index erforderlich, da wir bemerkt haben, dass der Anfrage zu viele gefilterte Zeilen vorliegen.
Lassen Sie uns genauer betrachten, was passiert ist. Tatsächlich sehen wir, dass wir fast anderthalb Gigabyte Daten aus dem Dateicache oder sogar von der Festplatte gelesen haben. Das ist nicht gut, da wir nur 142 Zeilen abgerufen haben.
Und es scheint, dass wir hier einen Index-Scan haben sollten, der schnell ablaufen müsste; aber da wir zu viele Zeilen gefiltert haben (wir mussten sie zählen), hat die Anfrage langsam gearbeitet.
Und das geschah im Plan, weil die Bedingungen in der Anfrage und die Bedingungen im Index teilweise nicht übereinstimmen.
Lassen Sie uns versuchen, den Index präziser zu gestalten, und schauen, wie sich die Ausführung der Anfrage danach verändert.
Die Erstellung des Index hat viel Zeit in Anspruch genommen, aber jetzt überprüfen wir die Anfrage und sehen, dass die Zeit anstelle von 2,5 Minuten nur 156 Millisekunden beträgt, was ziemlich gut ist. Und wir lesen nur 6 Megabyte Daten.
Und jetzt verwenden wir einen Index-Only-Scan.
Eine weitere wichtige Sache ist, dass wir den Plan auf eine verständlichere Weise präsentieren möchten. Wir haben bei uns eine Visualisierung mit Hilfe von Flame Graphs implementiert.
Das ist eine andere Anfrage, die reichhaltiger ist. Und die Flame Graphs bauen wir anhand von zwei Parametern auf: das ist die Menge an Daten, die ein bestimmter Knoten im Plan gelesen hat, und das Timing, d. h. die Ausführungszeit des Knotens.
Hier können wir die Knoten konkret untereinander vergleichen. Es wird deutlich, welcher von ihnen mehr oder weniger Platz benötigt, was normalerweise bei anderen Visualisierungsmethoden schwierig zu realisieren ist.
Natürlich kennt jeder explain.depesz.com. Ein gutes Feature dieser Visualisierung ist, dass wir den textbasierten Plan speichern und auch einige Hauptparameter in eine Tabelle auslagern, um sie sortieren zu können.
Und auch Entwickler, die sich mit diesem Thema noch nicht tiefgehend beschäftigt haben, nutzen explain.depesz.com, da sie leichter herausfinden können, welche Metriken wichtig sind und welche nicht.
Es gibt einen neuen Ansatz zur Visualisierung – explain.dalibo.com. Sie erstellen eine baumartige Visualisierung, aber es ist sehr schwierig, die Knoten untereinander zu vergleichen. Hier kann man die Struktur gut verstehen, aber wenn die Abfrage groß ist, muss man hin und her scrollen, was auch eine Option ist.
Zusammenarbeit
Und, wie ich bereits sagte, bietet uns Slack die Möglichkeit zur Zusammenarbeit. Wenn wir beispielsweise auf eine komplizierte Abfrage stoßen, die schwer zu optimieren ist, können wir in einem Thread in Slack diese Frage mit unseren Kollegen klären.
Wir halten es für wichtig, mit volllastfähigen Daten zu testen. Zu diesem Zweck haben wir das Tool Update Database Lab entwickelt, das als Open Source verfügbar ist. Sie können auch den Bot Joe verwenden. Sie können ihn jetzt gleich nehmen und in Ihrem eigenen Umfeld implementieren. Alle Anleitungen sind dort verfügbar.
Es ist auch wichtig zu beachten, dass die Lösung an sich nicht revolutionär ist, denn es gibt Delphix, aber das ist eine Unternehmenslösung. Sie ist komplett geschlossen und sehr teuer. Wir spezialisieren uns speziell auf Postgres. Alle unsere Produkte sind Open Source. Schließen Sie sich uns an!
Damit beende ich. Vielen Dank!
Fragen
Hallo! Vielen Dank für den Vortrag! Sehr interessant, besonders für mich, da ich vor einiger Zeit eine ähnliche Aufgabe gelöst habe. Daher habe ich eine Reihe von Fragen. Ich hoffe, ich kann zumindest einige davon stellen.
Es interessiert mich, wie Sie den Platz für diese Umgebung berechnen? Die Technologie impliziert, dass unter bestimmten Umständen Ihre Klone auf die maximale Größe anwachsen können. Grob gesagt: Wenn Sie eine zehn Terabyte große Datenbank und 10 Klone haben, lässt sich leicht eine Situation simulieren, in der jeder Klon 10 eindeutige Daten enthält. Wie berechnen Sie diesen Platz, also die Delta, von der Sie gesprochen haben, in der diese Klone leben werden?
Gute Frage. Hier ist es wichtig, auf die spezifischen Klone zu achten. Wenn ein Klon zu stark wächst, können wir zunächst eine Warnung an den Benutzer ausgeben oder diesen Klon sofort stoppen, um eine Fehlersituation zu vermeiden.
Ja, ich habe eine ergänzende Frage. Wie stellen Sie den Lebenszyklus dieser Module sicher? Bei uns ist das ein Problem und eine ganz eigene Geschichte. Wie funktioniert das?
Jeder Klon hat eine Art TTL. Prinzipiell haben wir eine feste TTL.
Welche, wenn ich fragen darf?
1 Stunde, d. h. im Leerlauf – 1 Stunde. Wenn er nicht verwendet wird, löschen wir ihn. Aber da gibt es nichts Überraschendes, da wir den Klon innerhalb von Sekunden hochfahren können. Und wenn er wieder benötigt wird, bitte sehr.
Ich finde die Wahl der Technologien interessant, denn auch wir verwenden aus verschiedenen Gründen mehrere Ansätze parallel. Warum gerade ZFS? Warum haben Sie nicht LVM verwendet? Sie haben erwähnt, dass es Probleme mit LVM gab. Welche Probleme gab es? Meiner Meinung nach ist die Variante mit dem SAN bezüglich der Leistung am optimalsten.
Was ist das Hauptproblem mit ZFS? Dass man es auf einem Host ausführen muss, d. h. alle Instanzen leben innerhalb eines Betriebssystems. Im Fall eines SAN können Sie verschiedene Hardware anschließen. Der Engpass sind nur die Blöcke, die auf dem SAN sind. Und die Frage der Technologieauswahl ist interessant. Warum nicht LVM?
Über LVM können wir beim Meetup sprechen. Bei SAN ist es einfach teuer. Das ZFS-System können wir überall implementieren. Sie können es auf Ihrem eigenen Rechner einrichten. Sie können einfach das Repository herunterladen und es aufsetzen. ZFS kann quasi überall installiert werden, wenn wir von Linux sprechen. Das heißt, wir bekommen eine sehr flexible Lösung. Und ZFS selbst bietet aus der Box schon sehr viel. Sie können unbegrenzt viele Daten laden, viele Festplatten anschließen und es gibt Snapshots. Wie ich schon sagte, ist es einfach zu verwalten. Das heißt, es ist sehr angenehm in der Nutzung. Es ist bewährt, es hat viele Jahre Bestand. Es gibt eine sehr große Community, die wächst. ZFS ist eine sehr zuverlässige Lösung.
Nikolaj Samokhvalov: Darf ich noch einen Kommentar abgeben? Ich heiße Nikolaj, ich arbeite zusammen mit Anatolij. Ich stimme zu, dass SAN großartig ist. Einige unserer Kunden haben Pure Storage usw.
Anatoli hat richtig bemerkt, dass wir auf Modularität abzielen. In Zukunft könnte man eine einheitliche Schnittstelle implementieren – mache einen Snapshot, mache einen Klon, zerstöre den Klon. Das ist alles einfach. Und eine SAN ist großartig, wenn man eine hat.
Aber ZFS ist für alle verfügbar. Es reicht schon mit DelPhix, die haben 300 Kunden. Davon sind 50 in den Fortune 100, d. h. sie zielen auf NASA usw. Es ist Zeit, dass diese Technologie allen zugänglich gemacht wird. Deshalb haben wir den Open-Source-Core. Wir haben einen Teil der Schnittstelle, der nicht Open Source ist. Das ist eine Plattform, die wir zeigen werden. Aber wir wollen, dass es für jeden verfügbar ist. Wir wollen eine Revolution bewirken, damit alle Tester nicht mehr auf ihren Laptops raten müssen. Wir sollten SELECT schreiben und sofort sehen, dass es langsam ist. Es reicht, darauf zu warten, dass der DBA uns darüber informiert. Das ist das Hauptziel. Und ich denke, dass wir das alle erreichen werden. Und dieses Tool entwickeln wir, damit es für alle verfügbar ist. Deshalb ZFS, weil es überall verfügbar sein wird. Danke an die Community für die Problemlösungen und für die open-source Lizenz usw.
Hallo! Danke für den Vortrag! Ich heiße Maxim. Wir hatten ähnliche Probleme. Bei uns haben wir sie gelöst. Wie teilen Sie die Ressourcen zwischen diesen Klonen auf? Jeder Klon kann zu jedem Zeitpunkt an seinen eigenen Aufgaben arbeiten: der eine testet das eine, der andere das andere, einer baut einen Index auf, der andere führt einen intensiven Job aus. Und wenn man die CPU noch aufteilen kann, wie teilen Sie das bei IO auf? Das ist die erste Frage.
Und die zweite Frage betrifft die unterschiedlichen Stände. Angenommen, ich habe hier ZFS und es läuft großartig, aber der Kunde hat in der Produktion nicht ZFS, sondern beispielsweise ext4. Wie gehen Sie in diesem Fall vor?
Das sind sehr gute Fragen. Ich habe dieses Problem, das wir beim Teilen von Ressourcen haben, schon etwas erwähnt. Die Lösung ist wie folgt: Stellen Sie sich vor, Sie testen im Staging. Auch dort kann die Situation gleichzeitig so aussehen, dass jemand eine Belastung erzeugt, jemand anderes eine andere. Und am Ende sehen Sie unklare Metriken. Das gleiche Problem könnte auch in der Produktion auftreten. Wenn Sie einen bestimmten Query überprüfen und feststellen, dass es ein Problem damit gibt – dass er langsam ist –, dann liegt das Problem eigentlich nicht am Query selbst, sondern an einer parallel auftretenden Belastung.
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 hochladen werden. Dass unsere Laufwerke zum Beispiel mit etwas beladen werden, wird konkret den Zeitrahmen beeinflussen. Aber wir können an der Datenmenge abschätzen, wie belastend diese Anfrage ist. Es ist nicht so wichtig, dass gleichzeitig noch eine Ausführung stattfinden wird.
Ich habe zwei Fragen. Das ist eine sehr coole Sache. Gab es Fälle, in denen die Daten in der Produktion kritisch wichtig waren, zum Beispiel Kreditkartennummern? Gibt es bereits etwas Fertiges oder ist das eine separate Aufgabe? Und die zweite Frage – gibt es so etwas für MySQL?
Was die Daten betrifft. Wir werden Obfuskation durchführen, während wir das noch nicht tun. Aber wenn Sie speziell Joe bereitstellen, und wenn Sie Entwicklern keinen Zugang gewähren, dann gibt es keinen Zugriff auf die Daten. Warum? Weil Joe keine Daten anzeigt. Er zeigt nur Metriken, Pläne und so weiter. Das wurde absichtlich so gemacht, weil es eine der Anforderungen unseres Kunden war. Sie wollten die Möglichkeit haben, zu optimieren, aber gleichzeitig nicht jedem Zugang gewähren.
Was MySQL betrifft. Dieses System kann für alles verwendet werden, was den Zustand auf der Festplatte speichert. Und da wir uns mit Postgres befassen, automatisieren wir derzeit vorrangig alles vollständig für Postgres. Wir möchten den Datenabruf aus Backups automatisieren. Wir konfigurieren Postgres korrekt. Wir wissen, wie wir sicherstellen können, dass die Pläne übereinstimmen usw.
Aber da das System erweiterbar ist, wird es auch für MySQL verwendet werden können. Und solche Beispiele gibt es. Eine ähnliche Lösung gibt es bei Yandex, aber sie wird nirgendwo veröffentlicht. Sie verwenden sie intern in Yandex.Metrica. Und dort geht es genau um MySQL. Aber die Technologien sind dieselben, ZFS.
Danke für den Vortrag! Ich habe auch ein paar Fragen. Sie erwähnten, dass Klonen für Analysen verwendet werden kann, zum Beispiel um dort zusätzliche Indizes zu erstellen. Können Sie ein bisschen detaillierter erklären, wie das funktioniert?
Und gleich die zweite Frage zur Einheitlichkeit der Stände, zur Einheitlichkeit der Pläne. Der Plan hängt unter anderem von der Statistik ab, die Postgres gesammelt hat. Wie lösen Sie dieses Problem?
In Bezug auf die Analyse gibt es keine spezifischen Fälle, da wir es bisher noch nicht so verwendet haben, aber diese Möglichkeit existiert. Wenn wir über Indizes sprechen, stellen Sie sich vor, dass eine Abfrage über eine Tabelle mit hundert Millionen Datensätzen ausgeführt wird, und zwar über eine Spalte, die normalerweise in der Produktionsumgebung nicht indiziert ist. Und wir möchten einige Daten berechnen. Wenn wir diese Abfrage in der Produktionsumgebung ausführen, besteht die Möglichkeit, dass es zu Verzögerungen kommt, da die Abfrage dort eine Minute lang bearbeitet wird.
Okay, lassen Sie uns einen dünnen Klon erstellen, den wir für einige Minuten stoppen können, ohne Angst zu haben. Um die Analyse komfortabler durchzuführen, fügen wir Indizes für die Spalten hinzu, die uns interessieren.
Wird der Index jedes Mal erstellt?
Es ist möglich, dass wir die Daten anfassen, Schnappschüsse machen und dann von diesem Schnappschuss wiederherstellen und neue Abfragen durchführen. Das heißt, wir können es so machen, dass wir neue Klone mit bereits gesetzten Indizes erstellen.
Was die Statistik betrifft, so wird unsere Statistik genau gleich sein, wenn wir aus einem Backup wiederherstellen oder Replikation durchführen. Denn wir bringen die gesamte physische Struktur der Daten mit, d.h. die Daten liegen so vor, wie sie sind, einschließlich aller Statistikmetriken.
Hier gibt es ein anderes Problem. Wenn Sie eine Cloud-Lösung verwenden, sind nur logische Dumps verfügbar, da Google und Amazon keine physikalischen Kopien herausgeben. Das wird ein Problem darstellen.
Danke für den Bericht. Es wurden zwei gute Fragen zu MySQL und zur Ressourcenteilung gestellt. Aber letztlich läuft alles darauf hinaus, dass es sich nicht um spezifische DBMS-Themen handelt, sondern um die Dateien im Allgemeinen. Entsprechend sollten auch die Fragen zur Ressourcenteilung dort geregelt werden, nicht am Ende, dass es Postgres ist, sondern in der Dateisystem, in Server, in der Instanz.
Meine Frage betrifft etwas anderes. Sie ist stärker an der Schichtung der Datenbank orientiert, wo es mehrere Schichten gibt. Wir haben beispielsweise ein Update eines Zehn-Terabyte-Images eingerichtet, und wir führen die Replikation durch. Wir verwenden diese Lösung konkret für Datenbanken. Es läuft die Replikation, und die Daten werden aktualisiert. Parallel arbeiten hierbei 100 Mitarbeiter, die ständig diese unterschiedlichen Schnappschüsse ausführen. Was sollen wir tun? Wie können wir sicherstellen, dass es keine Konflikte gibt, wenn sie eins gestartet haben und dann das Dateisystem ausgetauscht wurde und diese Schnappschüsse durcheinander geraten sind?
Sie werden nicht fahren, weil ZFS so funktioniert. Wir können Änderungen am Dateisystem in einem separaten Stream aufbewahren, die durch Replikation kommen. Und wir halten Klone von alten Versionen der Daten, die von den Entwicklern verwendet werden. Und das funktioniert bei uns, damit ist alles in Ordnung.
Das bedeutet, das Update erfolgt als zusätzliche Schicht, und alle neuen Snapshots werden dann basierend auf dieser Schicht erstellt, richtig?
Aus den vorherigen Schichten, die von vorherigen Replikationen stammen.
Die vorherigen Schichten werden verloren gehen, aber sie werden auf die alte Schicht verweisen, während die neuen Bilder von der letzten Schicht genommen werden, die durch das Update erhalten wurde?
Im Großen und Ganzen, ja.
Dann werden wir als Folge viele Schichten haben. Und im Laufe der Zeit müssen sie komprimiert werden?
Ja, das ist richtig. Es gibt ein bestimmtes Zeitfenster. Wir behalten wöchentliche Snapshots. Das hängt davon ab, welche Ressourcen Sie haben. Wenn Sie die Möglichkeit haben, viele Daten zu speichern, können Sie Snapshots über längere Zeiträume aufbewahren. Sie werden nicht automatisch gelöscht. Es wird keine Datenkorruption geben. Wenn die Snapshots veraltet sind, wie wir denken, d.h. das hängt von der Unternehmenspolitik ab, können wir sie einfach löschen und Platz schaffen.
Hallo, danke für den Vortrag! Zu Joes Frage: Sie sagten, dass der Kunde nicht wollte, dass allen ohne weiteres Zugang zu den Daten gegeben wird. Streng genommen, wenn jemand ein Ergebnis von Explain Analyze hat, kann er die Daten einsehen.
Das ist richtig. Zum Beispiel könnten wir schreiben: „SELECT FROM WHERE email = etwas“. D.h. wir würden die Daten selbst nicht sehen, aber einige indirekte Hinweise könnten wir einsehen. Das muss man verstehen. Aber andererseits ist alles sichtbar. Wir haben ein Audit der Protokolle, wir haben die Kontrolle anderer Kollegen, die auch sehen, womit die Entwickler beschäftigt sind. Und wenn jemand versucht, so etwas zu tun, wird die Sicherheitsabteilung zu ihnen kommen und sich um das Problem kümmern.
Guten Tag! Danke für die Präsentation! Ich habe eine kurze Frage. Wenn in der Firma kein Slack genutzt wird, gibt es dann derzeit eine Bindung daran oder können Entwickler Instanzen bereitstellen, um eine Testanwendung mit den Datenbanken zu verbinden?
Derzeit gibt es eine Bindung an Slack, d. h. es gibt keinen anderen Messenger, aber es wäre sehr wünschenswert, auch andere Messenger zu unterstützen. Was können Sie tun? Sie können DB Lab ohne Joe bei sich bereitstellen, über die REST API oder über unsere Plattform arbeiten und Klone erstellen sowie sich mit PSQL verbinden. Das kann jedoch nur gemacht werden, wenn Sie bereit sind, Ihren Entwicklern Zugang zu den Daten zu gewähren, da es dann keinen Bildschirm mehr geben wird.
Ich brauche diese Schicht nicht, sondern eine solche Möglichkeit.
Dann – ja, das kann gemacht werden.
Quelle: habr.com
