Der Beitrag von Yandex zu den folgenden Datenbanken wird überprüft.
- Clickhouse
- Odyssey
- Wiederherstellung zu einem bestimmten Zeitpunkt (WAL-G)
- PostgreSQL (einschließlich Logerrors, Amcheck, Heapcheck)
- Grüne Pflaume
Video:
Hallo Welt! Mein Name ist Andrey Borodin. Und was ich bei Yandex.Cloud mache, ist die Entwicklung offener relationaler Datenbanken im Interesse von Yandex.Cloud und Yandex.Cloud-Kunden.
In diesem Vortrag werden wir über die Herausforderungen sprechen, denen offene Datenbanken im großen Maßstab gegenüberstehen. Warum ist es wichtig? Denn kleine, kleine Probleme, die dann, wie Mücken, zu Elefanten werden. Sie werden groß, wenn Sie viele Cluster haben.
Aber das ist nicht die Hauptsache. Unglaubliche Dinge passieren. Dinge, die in einem von einer Million Fällen passieren. Und in einer Cloud-Umgebung muss man darauf vorbereitet sein, denn unglaubliche Dinge werden sehr wahrscheinlich, wenn etwas in großem Maßstab existiert.
Aber! Was ist der Vorteil offener Datenbanken? Tatsache ist, dass Sie theoretisch die Möglichkeit haben, jedes Problem zu lösen. Sie haben den Quellcode, Sie haben Programmierkenntnisse. Wir kombinieren es und es funktioniert.
Welche Ansätze gibt es bei der Arbeit an Open-Source-Software?
- Der einfachste Ansatz ist der Einsatz von Software. Wenn Sie Protokolle verwenden, wenn Sie Standards verwenden, wenn Sie Formate verwenden, wenn Sie Abfragen in Open-Source-Software schreiben, dann unterstützen Sie dies bereits.
- Sie vergrößern sein Ökosystem. Sie erhöhen die Wahrscheinlichkeit, dass ein Fehler frühzeitig erkannt wird. Sie erhöhen die Zuverlässigkeit dieses Systems. Sie erhöhen die Verfügbarkeit von Entwicklern auf dem Markt. Sie verbessern diese Software. Sie sind bereits ein Mitwirkender, wenn Sie dort gerade etwas Stil gefunden und daran herumgebastelt haben.
- Ein weiterer verständlicher Ansatz ist das Sponsoring von Open-Source-Software. Zum Beispiel das bekannte Google Summer of Code-Programm, bei dem Google einer großen Anzahl von Studenten aus aller Welt verständliches Geld zahlt, damit sie offene Softwareprojekte entwickeln, die bestimmte Lizenzanforderungen erfüllen.
- Dies ist ein sehr interessanter Ansatz, da er die Weiterentwicklung der Software ermöglicht, ohne den Fokus von der Community abzuwenden. Google als Technologieriese sagt nicht, dass wir diese Funktion wollen, wir wollen diesen Fehler beheben und hier müssen wir nachhaken. Google sagt: „Tu, was du tust.“ Arbeiten Sie einfach so weiter, wie Sie es bisher getan haben, und alles wird gut.“
- Der nächste Ansatz zur Teilnahme an Open Source ist die Teilnahme. Wenn Sie ein Problem mit Open-Source-Software haben und es Entwickler gibt, beginnen Ihre Entwickler, die Probleme zu lösen. Sie machen Ihre Infrastruktur effizienter, Ihre Programme schneller und zuverlässiger.
Eines der bekanntesten Yandex-Projekte im Bereich Open-Source-Software ist ClickHouse. Dies ist eine Datenbank, die als Antwort auf die Herausforderungen von Yandex.Metrica entstanden ist.
Und als Datenbank wurde sie in Open Source erstellt, um ein Ökosystem zu schaffen und es gemeinsam mit anderen Entwicklern (nicht nur innerhalb von Yandex) weiterzuentwickeln. Und das ist nun ein großes Projekt, an dem viele verschiedene Unternehmen beteiligt sind.
In Yandex.Cloud haben wir ClickHouse auf Basis von Yandex Object Storage, also auf Basis von Cloud-Speicher, erstellt.
Warum ist das in der Cloud wichtig? Denn jede Datenbank funktioniert in diesem Dreieck, in dieser Pyramide, in dieser Hierarchie von Speichertypen. Sie haben schnelle, aber kleine Register und billige, große, aber langsame SSDs, Festplatten und einige andere Blockgeräte. Und wenn Sie an der Spitze der Pyramide effizient sind, dann verfügen Sie über eine schnelle Datenbank. Wenn Sie am unteren Ende dieser Pyramide effizient sind, verfügen Sie über eine skalierte Datenbank. Und in dieser Hinsicht ist das Hinzufügen einer weiteren Ebene von unten ein logischer Ansatz, um die Skalierbarkeit der Datenbank zu erhöhen.
Wie könnte es gemacht werden? Dies ist ein wichtiger Punkt in diesem Bericht.
- Wir könnten ClickHouse über MDS implementieren. MDS ist eine interne Yandex-Cloud-Speicherschnittstelle. Es ist komplexer als das übliche S3-Protokoll, eignet sich jedoch besser für ein Blockgerät. Es eignet sich besser zum Aufzeichnen von Daten. Es erfordert mehr Programmierung. Programmierer werden programmieren, es ist sogar gut, es ist interessant.
- S3 ist ein gängigerer Ansatz, der die Schnittstelle einfacher macht, auf Kosten einer geringeren Anpassung an bestimmte Arten von Arbeitslasten.
Da wir dem gesamten ClickHouse-Ökosystem Funktionalität bieten und die erforderliche Aufgabe innerhalb von Yandex.Cloud erledigen wollten, haben wir uns natürlich dafür entschieden, sicherzustellen, dass die gesamte ClickHouse-Community davon profitiert. Wir haben ClickHouse über S3 implementiert, nicht ClickHouse über MDS. Und das ist eine Menge Arbeit.
Links:
„Dateisystem-Abstraktionsschicht“
„AWS SDK S3-Integration“
„Basisimplementierung der IDisk-Schnittstelle für S3“
„Integration von Log-Storage-Engines mit IDisk-Schnittstelle“
„Protokoll-Engine-Unterstützung für S3 und SeekableReadBuffer“
„Storage Stripe Log S3-Unterstützung“
„Storage MergeTree anfängliche Unterstützung für S3“
„MergeTree volle Unterstützung für S3“
„Unterstützt ReplicatedMergeTree über S3“
„Standardanmeldeinformationen und benutzerdefinierte Header für S3-Speicher hinzufügen“
„S3 mit dynamischer Proxy-Konfiguration“
„S3 mit Proxy-Resolver“
Dies ist eine Pull-Request-Liste zur Implementierung eines virtuellen Dateisystems in ClickHouse. Dies ist eine große Anzahl von Pull-Anfragen.
Links:
„DiskS3 Hardlinks optimale Implementierung“
„S3-HTTP-Client – Vermeiden Sie das Kopieren des Antwortstroms in den Speicher“
„Vermeiden Sie das Kopieren des gesamten Antwortstroms in den Speicher in S3 HTTP
Kunde"
„Möglichkeit, Markierungs- und Indexdateien für S3-Festplatten zwischenzuspeichern“
„Teile parallel von DiskLocal nach DiskS3 verschieben“
Aber die Arbeit war damit noch nicht zu Ende. Nachdem die Funktion erstellt wurde, waren weitere Arbeiten erforderlich, um diese Funktionalität zu optimieren.
Links:
„SelectedRows- und SelectedBytes-Ereignisse hinzufügen“
„Fügen Sie Profiling-Ereignisse aus der S3-Anfrage zu system.events hinzu“
„Fügen Sie QueryTimeMicroseconds, SelectQueryTimeMicroseconds und InsertQueryTimeMicroseconds hinzu“
Und dann galt es, es diagnostizierbar zu machen, ein Monitoring einzurichten und es beherrschbar zu machen.
Und das alles, damit die gesamte Community, das gesamte ClickHouse-Ökosystem, das Ergebnis dieser Arbeit erhält.
Kommen wir nun zu den Transaktionsdatenbanken, zu den OLTP-Datenbanken, die mir persönlich näher liegen.
Dies ist die Open-Source-DBMS-Entwicklungsabteilung. Diese Leute betreiben Straßenmagie, um transaktionale offene Datenbanken zu verbessern.
Eines der Projekte, anhand dessen wir anhand eines Beispiels darüber sprechen können, wie und was wir tun, ist der Connection Pooler in Postgres.
Postgres ist eine Prozessdatenbank. Das bedeutet, dass die Datenbank möglichst wenige Netzwerkverbindungen haben sollte, die Transaktionen abwickeln.
Andererseits kommt es in einer Cloud-Umgebung typischerweise vor, dass tausend Verbindungen gleichzeitig zu einem Cluster kommen. Und die Aufgabe des Verbindungspoolers besteht darin, tausend Verbindungen in eine kleine Anzahl von Serververbindungen zu packen.
Wir können sagen, dass der Verbindungspooler der Telefonist ist, der die Bytes neu anordnet, damit sie effizient die Datenbank erreichen.
Leider gibt es kein gutes russisches Wort für Connection Pooler. Manchmal spricht man auch von Multiplexer-Verbindungen. Wenn Sie wissen, wie man den Verbindungspooler nennt, dann sagen Sie es mir unbedingt, ich spreche sehr gerne die richtige russische Fachsprache.
Wir haben Verbindungspooler untersucht, die für einen verwalteten Postgres-Cluster geeignet sind. Und PgBouncer war für uns die beste Wahl. Wir sind jedoch auf eine Reihe von Problemen mit PgBouncer gestoßen. Vor vielen Jahren berichtete Volodya Borodin, dass wir PgBouncer verwenden, uns gefällt alles, aber es gibt Nuancen, es gibt etwas, an dem man arbeiten kann.
Und wir haben gearbeitet. Wir haben die aufgetretenen Probleme behoben, Bouncer gepatcht und versucht, Pull-Anfragen in den Upstream zu pushen. Es war jedoch schwierig, mit grundlegendem Single-Threading zu arbeiten.
Wir mussten Kaskaden von gepatchten Bouncern sammeln. Wenn wir viele Single-Thread-Bouncer haben, werden die Verbindungen auf der obersten Ebene auf die innere Ebene der Bouncer übertragen. Dies ist ein schlecht verwaltetes System, das schwierig aufzubauen und hin und her zu skalieren ist.
Wir kamen zu dem Schluss, dass wir unseren eigenen Verbindungspooler namens Odyssey erstellt haben. Wir haben es von Grund auf geschrieben.
2019 habe ich diesen Pooler auf der PgCon-Konferenz der Entwickler-Community vorgestellt. Jetzt haben wir etwas weniger als 2 Sterne auf GitHub, d. h. das Projekt lebt, das Projekt ist beliebt.
Und wenn Sie in Yandex.Cloud einen Postgres-Cluster erstellen, handelt es sich um einen Cluster mit integriertem Odyssey, der beim Skalieren des Clusters neu konfiguriert wird.
Was haben wir aus diesem Projekt gelernt? Ein konkurrierendes Projekt zu starten ist immer ein aggressiver Schritt, es ist eine extreme Maßnahme, wenn wir sagen, dass es Probleme gibt, die nicht schnell genug gelöst werden, nicht in den Zeitintervallen, die uns passen würden. Aber das ist eine wirksame Maßnahme.
PgBouncer begann sich schneller zu entwickeln.
Und jetzt sind weitere Projekte erschienen. Zum Beispiel pgagroal, das von Red Hat-Entwicklern entwickelt wurde. Sie verfolgen ähnliche Ziele und setzen ähnliche Ideen um, aber natürlich mit ihren eigenen Besonderheiten, die den Pgagroal-Entwicklern näher kommen.
Ein weiterer Fall der Zusammenarbeit mit der Postgres-Community ist die Wiederherstellung eines bestimmten Zeitpunkts. Dies ist eine Wiederherstellung nach einem Fehler, dies ist eine Wiederherstellung aus einem Backup.
Es gibt viele Backups und sie sind alle unterschiedlich. Fast jeder Postgres-Anbieter verfügt über eine eigene Backup-Lösung.
Wenn Sie alle Backup-Systeme nehmen, eine Merkmalsmatrix erstellen und scherzhaft die Determinante in dieser Matrix berechnen, ist sie Null. Was bedeutet das? Was passiert, wenn Sie eine bestimmte Sicherungsdatei erstellen, dann kann diese nicht aus Teilen aller anderen zusammengesetzt werden. Es ist einzigartig in seiner Umsetzung, es ist einzigartig in seinem Zweck, es ist einzigartig in den Ideen, die darin eingebettet sind. Und sie sind alle spezifisch.
Während wir an diesem Problem arbeiteten, startete CitusData das WAL-G-Projekt. Hierbei handelt es sich um ein Backup-System, das mit Blick auf die Cloud-Umgebung entwickelt wurde. Jetzt ist CitusData bereits Teil von Microsoft. Und in diesem Moment gefielen uns die Ideen, die in den ersten Veröffentlichungen von WAL-G dargelegt wurden, wirklich gut. Und wir begannen, zu diesem Projekt beizutragen.
Mittlerweile gibt es viele Dutzend Entwickler in diesem Projekt, aber zu den zehn größten Mitwirkenden an WAL-G gehören sechs Yandexoids. Wir haben dort viele unserer Ideen eingebracht. Und natürlich haben wir sie selbst implementiert, selbst getestet, selbst in die Produktion eingeführt, wir nutzen sie selbst, wir finden selbst heraus, wohin wir als nächstes gehen sollen, während wir mit der großen WAL-G-Community interagieren.
Und aus unserer Sicht ist dieses Backup-System nun, auch unter Berücksichtigung unserer Bemühungen, optimal für eine Cloud-Umgebung geworden. Dies sind die besten Kosten für die Sicherung von Postgres in der Cloud.
Was bedeutet das? Wir haben eine ziemlich große Idee vorangetrieben: Backups sollten sicher, kostengünstig im Betrieb und so schnell wie möglich wiederherzustellen sein.
Warum sollte der Betrieb günstig sein? Wenn nichts kaputt ist, sollten Sie nicht wissen, dass Sie Backups haben. Alles funktioniert einwandfrei, Sie verschwenden so wenig CPU wie möglich, verbrauchen so wenig Festplattenressourcen wie möglich und senden so wenig Bytes wie möglich an das Netzwerk, um die Nutzlast Ihrer wertvollen Dienste nicht zu beeinträchtigen.
Und wenn zum Beispiel alles kaputt geht, der Administrator die Daten gelöscht hat, etwas schief gelaufen ist und Sie dringend in die Vergangenheit zurückkehren müssen, erholen Sie sich mit dem ganzen Geld, weil Sie Ihre Daten schnell und intakt zurückhaben möchten.
Und wir haben diese einfache Idee gefördert. Und es scheint uns, dass wir es geschafft haben, es umzusetzen.
Aber das ist nicht alles. Wir wollten noch eine Kleinigkeit. Wir wollten viele verschiedene Datenbanken. Nicht alle unserer Kunden nutzen Postgres. Einige Leute verwenden MySQL, MongoDB. In der Community haben andere Entwickler FoundationDB unterstützt. Und diese Liste wird ständig erweitert.
Der Community gefällt die Idee, dass die Datenbank in einer verwalteten Umgebung in der Cloud ausgeführt wird. Und Entwickler pflegen ihre Datenbanken, die mit unserem Backup-System einheitlich zusammen mit Postgres gesichert werden können.
Was haben wir aus dieser Geschichte gelernt? Unser Produkt als Entwicklungsabteilung besteht nicht aus Codezeilen, es sind keine Anweisungen, es sind keine Dateien. Bei unserem Produkt handelt es sich nicht um Pull Requests. Das sind die Ideen, die wir der Community vermitteln. Dabei handelt es sich um technologisches Fachwissen und die Entwicklung der Technologie hin zu einer Cloud-Umgebung.
Es gibt eine solche Datenbank wie Postgres. Mir gefällt der Postgres-Kern am besten. Ich verbringe viel Zeit damit, den Postgres-Kern mit der Community zu entwickeln.
Hier muss jedoch gesagt werden, dass Yandex.Cloud über eine interne Installation verwalteter Datenbanken verfügt. Und es begann vor langer Zeit in Yandex.Mail. Das Know-how, das nun zur Verwaltung von Postgres geführt hat, wurde angesammelt, als die Post in Postgres einziehen wollte.
Mail hat sehr ähnliche Anforderungen wie die Cloud. Sie müssen in der Lage sein, an jedem Punkt Ihrer Daten ein unerwartetes exponentielles Wachstum zu erzielen. Und die E-Mail war bereits mit mehreren Hundert Millionen Postfächern einer riesigen Anzahl von Benutzern belastet, die ständig viele Anfragen stellen.
Und das war eine ziemlich große Herausforderung für das Team, das Postgres entwickelte. Damals wurden alle Probleme, auf die wir gestoßen sind, der Community gemeldet. Und diese Probleme wurden behoben und von der Community an einigen Stellen sogar auf der Ebene der kostenpflichtigen Unterstützung für einige andere Datenbanken und sogar noch besser behoben. Das heißt, Sie können einen Brief an den PgSQL-Hacker senden und innerhalb von 40 Minuten eine Antwort erhalten. Der kostenpflichtige Support in einigen Datenbanken denkt möglicherweise, dass es Dinge gibt, die wichtiger sind als Ihr Fehler.
Jetzt umfasst die interne Installation von Postgres einige Petabyte an Daten. Das sind mehrere Millionen Anfragen pro Sekunde. Das sind Tausende von Clustern. Es ist sehr großflächig.
Aber es gibt eine Nuance. Es lebt nicht von schicken Netzlaufwerken, sondern von recht einfacher Hardware. Und es gibt eine Testumgebung speziell für interessante Neuheiten.
Und zu einem bestimmten Zeitpunkt erhielten wir in der Testumgebung eine Meldung, dass die internen Invarianten der Datenbankindizes verletzt wurden.
Eine Invariante ist eine Art Beziehung, von der wir erwarten, dass sie immer besteht.
Eine sehr kritische Situation für uns. Dies weist darauf hin, dass möglicherweise einige Daten verloren gegangen sind. Und Datenverlust ist geradezu katastrophal.
Die allgemeine Idee, die wir bei verwalteten Datenbanken verfolgen, ist, dass es selbst bei großem Aufwand schwierig sein wird, Daten zu verlieren. Selbst wenn Sie sie bewusst entfernen, müssen Sie ihre Abwesenheit über einen längeren Zeitraum hinweg ignorieren. Datensicherheit ist eine Religion, der wir sehr gewissenhaft folgen.
Und hier entsteht eine Situation, die darauf hindeutet, dass es eine Situation geben könnte, auf die wir möglicherweise nicht vorbereitet sind. Und wir begannen, uns auf diese Situation vorzubereiten.
Als Erstes haben wir die Protokolle dieser Tausenden Cluster vergraben. Wir haben herausgefunden, welche der Cluster sich auf Festplatten mit problematischer Firmware befanden, bei denen Datenseitenaktualisierungen verloren gingen. Den gesamten Postgres-Datencode markiert. Und wir haben die Meldungen, die auf Verstöße gegen interne Invarianten hinweisen, mit Code markiert, der darauf ausgelegt ist, Datenbeschädigungen zu erkennen.
Dieser Patch wurde von der Community praktisch ohne große Diskussion angenommen, da in jedem einzelnen Fall klar war, dass etwas Schlimmes passiert war und dem Protokoll gemeldet werden musste.
Danach kamen wir zu dem Punkt, dass wir eine Überwachung haben, die Protokolle scannt. Und bei verdächtigen Nachrichten weckt er den diensthabenden Beamten und der diensthabende Beamte repariert das Problem.
Aber! Das Scannen von Protokollen ist auf einem Cluster ein kostengünstiger Vorgang und bei tausend Clustern katastrophal teuer.
Wir haben eine Erweiterung namens geschrieben . Es erstellt eine Ansicht der Datenbank, in der Sie kostengünstig und schnell Statistiken zu vergangenen Fehlern abrufen können. Und wenn wir den diensthabenden Beamten wecken müssen, werden wir das herausfinden, ohne Gigabyte-Dateien zu scannen, sondern indem wir ein paar Bytes aus der Hash-Tabelle extrahieren.
Diese Erweiterung wurde beispielsweise im Repository für übernommen . Wenn Sie es verwenden möchten, können Sie es selbst installieren. Natürlich ist es Open Source.
Aber das ist nicht alles. Wir haben begonnen, Amcheck, eine von der Community erstellte Erweiterung, zu verwenden, um invariante Verstöße in Indizes zu finden.
Und wir haben herausgefunden, dass es Fehler gibt, wenn man es in großem Maßstab betreibt. Wir haben angefangen, sie zu reparieren. Unsere Korrekturen wurden übernommen.
Wir haben festgestellt, dass diese Erweiterung keine GiST- und GIT-Indizes analysieren kann. Wir haben sie dazu gebracht, sie zu unterstützen. Diese Unterstützung wird in der Community jedoch noch diskutiert, da es sich um eine relativ neue Funktionalität handelt und es dort viele Details gibt.
Und wir haben auch festgestellt, dass bei der Überprüfung von Indizes auf Verstöße auf dem Replikationsleiter, auf dem Master, alles gut funktioniert, aber auf den Replikaten, auf dem Follower, ist die Suche nach Korruption nicht so effektiv. Nicht alle Invarianten werden überprüft. Und eine Invariante hat uns sehr gestört. Und wir haben anderthalb Jahre damit verbracht, mit der Community zu kommunizieren, um diese Überprüfung von Replikaten zu ermöglichen.
Wir haben Code geschrieben, der allen can...-Protokollen folgen sollte. Wir haben diesen Patch eine ganze Weile mit Peter Gaghan von Crunchy Data besprochen. Er musste den vorhandenen B-Baum in Postgres leicht modifizieren, um diesen Patch zu akzeptieren. Er wurde angenommen. Und jetzt ist auch die Überprüfung der Indizes auf Replikaten effektiv genug, um die festgestellten Verstöße zu erkennen. Dies sind also Verstöße, die durch Fehler in der Festplatten-Firmware, Fehler in Postgres, Fehler im Linux-Kernel und Hardwareprobleme verursacht werden können. Eine ziemlich umfangreiche Liste von Problemquellen, auf die wir uns vorbereitet haben.
Aber neben den Indizes gibt es noch einen Teil wie den Heap, also den Ort, an dem die Daten gespeichert werden. Und es gibt nicht viele Invarianten, die überprüft werden könnten.
Wir haben eine Erweiterung namens Heapcheck. Wir haben mit der Entwicklung begonnen. Parallel dazu begann die Firma EnterpriseDB gemeinsam mit uns, ein Modul zu schreiben, das sie auf die gleiche Weise Heapcheck nannten. Nur haben wir es PgHeapcheck genannt, und sie nannten es einfach Heapcheck. Sie haben es mit ähnlichen Funktionen, einer etwas anderen Signatur, aber mit den gleichen Ideen. Sie haben sie an manchen Stellen etwas besser umgesetzt. Und sie haben es schon einmal in Open Source veröffentlicht.
Und jetzt entwickeln wir ihre Expansion, denn es ist nicht mehr ihre Expansion, sondern die Expansion der Gemeinschaft. Und in Zukunft ist dies ein Teil des Kernels, der jedem zur Verfügung gestellt wird, damit er im Voraus über zukünftige Probleme Bescheid weiß.
An einigen Stellen kamen wir sogar zu dem Schluss, dass unsere Überwachungssysteme falsch positive Ergebnisse enthalten. Zum Beispiel das 1C-System. Bei der Verwendung einer Datenbank schreibt Postgres manchmal Daten hinein, die es lesen kann, pg_dump jedoch nicht lesen kann.
Diese Situation schien für unser Problemerkennungssystem eine Beschädigung zu sein. Der diensthabende Beamte wurde geweckt. Der diensthabende Beamte schaute sich an, was geschah. Nach einiger Zeit kam ein Kunde und sagte, ich hätte Probleme. Der Mitarbeiter erklärte, was das Problem sei. Aber das Problem liegt im Postgres-Kern.
Ich habe eine Diskussion zu dieser Funktion gefunden. Und er schrieb, dass wir auf dieses Merkmal gestoßen sind und es unangenehm war, dass eine Person nachts aufwachte, um herauszufinden, was es war.
Die Community antwortete: „Oh, wir müssen das Problem wirklich beheben.“
Ich habe eine einfache Analogie. Wenn Sie in einem Schuh laufen, in dem sich ein Sandkorn befindet, können Sie grundsätzlich weitergehen – kein Problem. Wenn Sie Stiefel an Tausende von Menschen verkaufen, dann machen wir Stiefel ganz ohne Sand. Und wenn einer der Nutzer Ihrer Schuhe einen Marathon laufen will, dann möchten Sie sehr gute Schuhe herstellen und diese dann auf alle Ihre Nutzer skalieren. Und solche unerwarteten Benutzer befinden sich immer in der Cloud-Umgebung. Es gibt immer Benutzer, die den Cluster auf originelle Weise ausnutzen. Darauf müssen Sie sich immer vorbereiten.
Was haben wir hier gelernt? Wir haben etwas Einfaches gelernt: Das Wichtigste ist, der Community zu erklären, dass es ein Problem gibt. Wenn die Gemeinschaft das Problem erkannt hat, entsteht ein natürlicher Wettbewerb um die Lösung des Problems. Weil jeder ein wichtiges Problem lösen möchte. Alle Anbieter, alle Hacker verstehen, dass sie selbst auf diesen Rechen treten können, also wollen sie sie eliminieren.
Wenn Sie an einem Problem arbeiten, es aber niemanden außer Ihnen stört, Sie aber systematisch daran arbeiten und es letztendlich als Problem betrachtet wird, dann wird Ihr Pull-Request auf jeden Fall angenommen. Ihr Patch wird angenommen, Ihre Verbesserungen oder auch Verbesserungswünsche werden von der Community geprüft. Am Ende des Tages verbessern wir die Datenbank füreinander.
Eine interessante Datenbank ist Greenplum. Es handelt sich um eine hochparallele Datenbank, die auf der Postgres-Codebasis basiert, mit der ich sehr vertraut bin.
Und Greenplum hat eine interessante Funktionalität – optimierte Tabellen anhängen. Dies sind Tabellen, die Sie schnell ergänzen können. Sie können entweder spaltenförmig oder zeilenförmig sein.
Es gab jedoch kein Clustering, d. h. es gab keine Funktionalität, mit der man die in der Tabelle befindlichen Daten entsprechend der Reihenfolge anordnen konnte, die in einem der Indizes vorliegt.
Die Jungs vom Taxi kamen zu mir und sagten: „Andrey, du kennst Postgres. Und hier ist es fast das Gleiche. Wechseln Sie zu 20 Minuten. Du nimmst es und tust es.“ Ich dachte, ja, ich kenne Postgres, 20 Minuten lang wechseln – ich muss das tun.
Aber nein, es waren keine 20 Minuten, ich habe es über Monate hinweg geschrieben. Auf der PgConf.Russia-Konferenz wandte ich mich an Heikki Linakangas von Pivotal und fragte: „Gibt es damit Probleme?“ Warum gibt es kein anhangsoptimiertes Tabellen-Clustering?“ Er sagt: „Sie nehmen die Daten. Sie sortieren, Sie ordnen neu. Es ist nur ein Job.“ Ich: „Oh ja, du musst es einfach annehmen und tun.“ Er sagt: „Ja, dafür brauchen wir freie Hände.“ Ich dachte, dass ich das unbedingt tun muss.
Und ein paar Monate später reichte ich einen Pull-Request ein, der diese Funktionalität implementierte. Diese Pull-Anfrage wurde von Pivotal zusammen mit der Community überprüft. Natürlich gab es Fehler.
Aber das Interessanteste ist, dass beim Zusammenführen dieser Pull-Anfrage Fehler in Greenplum selbst gefunden wurden. Wir haben festgestellt, dass Heap-Tabellen beim Clustering manchmal die Transaktionalität unterbrechen. Und das ist eine Sache, die behoben werden muss. Und sie ist an der Stelle, die ich gerade berührt habe. Und meine natürliche Reaktion war: Okay, lass mich das auch machen.
Ich habe diesen Fehler behoben. Habe eine Pull-Anfrage an die Fixierer gesendet. Er wurde getötet.
Danach stellte sich heraus, dass diese Funktionalität in der Greenplum-Version für PostgreSQL 12 erworben werden muss. Das heißt, das 20-minütige Abenteuer geht mit neuen interessanten Abenteuern weiter. Es war interessant, die aktuelle Entwicklung zu verfolgen, bei der die Community neue und wichtigste Funktionen einführt. Es ist gefroren.
Aber damit war es noch nicht getan. Letztendlich stellte sich heraus, dass wir für all das eine Dokumentation schreiben mussten.
Ich begann, Dokumentationen zu schreiben. Zum Glück kamen die Dokumentarfilmer von Pivotal. Englisch ist ihre Muttersprache. Sie haben mir bei der Dokumentation geholfen. Tatsächlich haben sie selbst meinen Vorschlag in echtes Englisch umgeschrieben.
Und hier schien das Abenteuer zu Ende zu sein. Und wissen Sie, was dann passiert ist? Die Jungs vom Taxi kamen zu mir und sagten: „Es gibt noch zwei Abenteuer, jeweils 10 Minuten.“ Und was soll ich ihnen sagen? Ich sagte, dass ich jetzt einen maßstabsgetreuen Bericht vorlegen werde, dann werden wir uns Ihre Abenteuer ansehen, denn das ist ein interessanter Job.
Was haben wir aus diesem Fall gelernt? Da die Arbeit mit Open Source immer die Zusammenarbeit mit einer bestimmten Person bedeutet, arbeitet sie immer mit der Community zusammen. Denn in jeder einzelnen Phase habe ich mit einem Entwickler, einem Tester, einem Hacker, einem Dokumentarfilmer, einem Architekten zusammengearbeitet. Ich habe nicht mit Greenplum gearbeitet, sondern mit Leuten aus der Umgebung von Greenplum.
Aber! Es gibt noch einen weiteren wichtigen Punkt: Es ist nur Arbeit. Das heißt, Sie kommen, trinken Kaffee, schreiben Code. Alle möglichen einfachen Invarianten funktionieren. Machen Sie es ganz normal – es wird gut! Und es ist ein ziemlich interessanter Job. Es gibt eine Anfrage für diese Arbeit von Yandex.Cloud-Kunden, Benutzern unserer Cluster sowohl innerhalb als auch außerhalb von Yandex. Und ich denke, dass die Anzahl der Projekte, an denen wir teilnehmen, zunehmen wird und auch die Tiefe unseres Engagements zunehmen wird.
Das ist alles. Kommen wir zu den Fragen.
Fragestunde
Hallo! Wir haben eine weitere Frage-und-Antwort-Runde. Und im Studio Andrei Borodin. Dies ist die Person, die Ihnen gerade vom Beitrag von Yandex.Cloud und Yandex zu Open Source erzählt hat. In unserem Bericht geht es jetzt nicht ausschließlich um die Cloud, aber gleichzeitig basieren wir auf solchen Technologien. Ohne das, was Sie in Yandex getan haben, gäbe es keinen Service in Yandex.Cloud, also vielen Dank von mir persönlich. Und die erste Frage aus der Sendung: „Über welche Projekte, die Sie erwähnt haben, wurde geschrieben?“
Das Backup-System in WAL-G ist in Go geschrieben. Dies ist eines der neueren Projekte, an denen wir gearbeitet haben. Er ist buchstäblich erst 3 Jahre alt. Und bei einer Datenbank geht es oft um Zuverlässigkeit. Und das bedeutet, dass die Datenbanken ziemlich alt sind und normalerweise in C geschrieben sind. Das Postgres-Projekt begann vor etwa 30 Jahren. Dann war der C89 die richtige Wahl. Und Postgres steht darauf. Modernere Datenbanken wie ClickHouse sind normalerweise in C++ geschrieben. Die gesamte Systementwicklung basiert auf C und C++.
Eine Frage unseres Finanzmanagers, der bei Cloud für die Ausgaben verantwortlich ist: „Warum gibt Cloud Geld für die Unterstützung von Open Source aus?“
Für den Finanzmanager gibt es hier eine einfache Antwort. Wir tun dies, um unsere Dienstleistungen zu verbessern. Wie können wir es besser machen? Wir können Dinge effizienter und schneller erledigen und skalierbarer machen. Aber für uns geht es in dieser Geschichte vor allem um Zuverlässigkeit. Beispielsweise überprüfen wir in einem Backup-System 100 % der darauf anwendbaren Patches. Wir kennen den Code. Und wir fühlen uns wohler, wenn wir neue Versionen in die Produktion einführen. Das heißt, es geht in erster Linie um Vertrauen, um Entwicklungsbereitschaft und um Verlässlichkeit
Eine weitere Frage: „Unterscheiden sich die Anforderungen externer Benutzer, die in Yandex.Cloud leben, von denen interner Benutzer, die in der internen Cloud leben?“
Das Lastprofil ist natürlich unterschiedlich. Aber aus Sicht meiner Abteilung werden alle besonderen und interessanten Fälle auf einer nicht standardmäßigen Last erstellt. Entwickler mit Fantasie, Entwickler, die das Unerwartete tun, sind sowohl intern als auch extern gleichermaßen anzutreffen. In dieser Hinsicht sind wir alle ungefähr gleich. Und wahrscheinlich ist das einzige wichtige Merkmal im Yandex-Datenbankbetrieb, dass wir in Yandex eine Lehre haben. Irgendwann gerät eine Verfügbarkeitszone vollständig in den Schatten und alle Yandex-Dienste müssen trotzdem irgendwie weiter funktionieren. Das ist ein kleiner Unterschied. Aber es erzeugt viel Forschungsentwicklung an der Schnittstelle zwischen Datenbank und Netzwerk-Stack. Ansonsten generieren externe und interne Installationen die gleichen Anfragen nach Funktionen und ähnliche Anfragen zur Verbesserung von Zuverlässigkeit und Leistung.
Nächste Frage: „Wie stehen Sie persönlich dazu, dass ein Großteil Ihrer Arbeit von anderen Clouds genutzt wird?“ Wir werden keine konkreten Projekte nennen, aber viele Projekte, die in Yandex.Cloud durchgeführt wurden, werden in den Clouds anderer Leute verwendet.
Das ist cool. Erstens ist es ein Zeichen dafür, dass wir etwas richtig gemacht haben. Und es kratzt am Ego. Und wir sind zuversichtlicher, dass wir die richtige Entscheidung getroffen haben. Andererseits ist dies die Hoffnung, dass uns dies in Zukunft neue Ideen, neue Wünsche von Drittbenutzern bringen wird. Die meisten Probleme auf GitHub werden von einzelnen Systemadministratoren, einzelnen Datenbankadministratoren, einzelnen Architekten, einzelnen Ingenieuren erstellt, aber manchmal kommen Leute mit systematischer Erfahrung und sagen, dass wir in 30 % aller Fälle dieses Problem haben, und lassen Sie uns darüber nachdenken, wie wir es lösen können. Darauf freuen wir uns am meisten. Wir freuen uns auf den Erfahrungsaustausch mit anderen Cloud-Plattformen.
Du hast viel über den Marathon gesprochen. Ich weiß, dass Sie in Moskau einen Marathon gelaufen sind. Infolge? Die Jungs von PostgreSQL überholt?
Nein, Oleg Bartunov rennt sehr schnell. Er war eine Stunde vor mir fertig. Insgesamt bin ich zufrieden damit, wie weit ich gekommen bin. Für mich war schon der Abschluss eine Errungenschaft. Insgesamt ist es überraschend, dass es in der Postgres-Community so viele Läufer gibt. Mir scheint, dass es eine Art Zusammenhang zwischen Aerobic-Sportarten und dem Wunsch nach Systemprogrammierung gibt.
Wollen Sie damit sagen, dass es bei ClickHouse keine Läufer gibt?
Ich weiß mit Sicherheit, dass sie da sind. ClickHouse ist auch eine Datenbank. Oleg schreibt mir übrigens jetzt: „Sollen wir nach dem Bericht einen Lauf machen?“ Das ist eine tolle Idee.
Eine weitere Frage aus der Sendung von Nikita: „Warum hast du den Fehler in Greenplum selbst behoben und ihn nicht an Junioren weitergegeben?“ Es ist zwar nicht ganz klar, um welchen Fehler es sich handelt und bei welchem Dienst, aber es handelt sich wahrscheinlich um den Fehler, über den Sie gesprochen haben.
Ja, im Prinzip hätte es jemandem gegeben werden können. Es war nur der Code, den ich gerade geändert habe. Und es war selbstverständlich, sofort damit weiterzumachen. Grundsätzlich ist die Idee, Fachwissen mit dem Team zu teilen, eine gute Idee. Wir werden die Greenplum-Aufgaben auf jeden Fall auf alle Mitglieder unserer Abteilung aufteilen.
Da es sich um Junioren handelt, hier eine Frage. Die Person beschloss, den ersten Commit in Postgres zu erstellen. Was muss er tun, um den ersten Commit durchzuführen?
Das ist eine interessante Frage: „Wo soll ich anfangen?“ Normalerweise ist es ziemlich schwierig, mit etwas im Kernel zu beginnen. In Postgres gibt es beispielsweise eine To-Do-Liste. Aber in Wirklichkeit ist dies ein Beispiel dafür, was sie versucht haben, aber nicht geschafft haben. Das sind komplizierte Dinge. Und normalerweise findet man im Ökosystem einige Dienstprogramme, einige Erweiterungen, die verbessert werden können, die jedoch weniger Aufmerksamkeit von Kernel-Entwicklern auf sich ziehen. Und dementsprechend gibt es dort noch mehr Wachstumspotenziale. Beim Google Summer of Code-Programm schlägt die Postgres-Community jedes Jahr viele verschiedene Themen vor, die angesprochen werden könnten. Dieses Jahr hatten wir, glaube ich, drei Studenten. Einer hat sogar in WAL-G über Themen geschrieben, die für Yandex wichtig sind. In Greenplum ist alles einfacher als in der Postgres-Community, da Greenplum-Hacker Pull-Requests sehr gut behandeln und sofort mit der Überprüfung beginnen. Das Versenden eines Patches an Postgres ist eine Frage von Monaten, aber Greenplum kommt in einem Tag und sieht, was Sie getan haben. Eine andere Sache ist, dass Greenplum aktuelle Probleme lösen muss. Greenplum wird nicht häufig verwendet, daher ist es ziemlich schwierig, Ihr Problem zu finden. Und natürlich müssen wir zunächst einmal Probleme lösen.
Source: habr.com