Datenbanken unter HighLoad ++ 2019

Die Arbeit mit einer Datenbank wirkt sich erheblich auf die Leistung eines Webdienstes aus. Wenn Sie es versuchen , können Sie eine Hochlast ohne Last arrangieren.

Und wenn Sie alles mit Bedacht tun, werden die Anforderungen von vielen tausend Benutzern verarbeitet. Daher enthält der HighLoad ++ - Zeitplan traditionell viele Berichte zu Datenbanken. Wir haben Tracks zu PostgreSQL, MySQL und ClickHouse, es gibt mehrere Berichte zu MongoDB (in der besten Tradition ist der Sprecher ein Performance-Ingenieur in MongoDB). Darüber hinaus gibt es Vorträge zum Vergleich verschiedener Ansätze oder zur Berücksichtigung spezialisierter Lösungen. Und im Allgemeinen fügen wir hier Tarantool und In-Memory hinzu. Insgesamt 33 Berichte stehen in direktem Zusammenhang mit dem Abschnitt „Datenbanken und Speichersysteme“ und mindestens 10 indirekt. Und dies zählt nicht die Mitaps , die nicht weniger als zehn sind, und neue werden auf dem Weg hinzugefügt.

Wir werden versuchen, Ihnen dabei zu helfen, in all seiner Vielfalt zu navigieren und wirklich einzigartige Berichte nicht zu verpassen. Aus Gründen der Zuverlässigkeit bitten wir das für diesen Abschnitt zuständige Mitglied des Programmausschusses, Nikolay Samokhvalov, um Stellungnahme. Und schauen Sie nicht, dass Nikolai der Gründer von Postgres.ai und im Allgemeinen Postgresmen ist - er kennt sich in der Datenbankwelt gut aus, er kennt interessante Backstage-Geschichten und Trends.

Die Überprüfung ist so einfach wie möglich organisiert: Wir haben die Liste der Berichte geöffnet und sind von oben nach unten gegangen, um uns mit den Themen zu befassen, die beachtet werden müssen.

ClickHouse Query Profiler

Der Abfrageprofiler in analytischen Datenbanken ist eine sehr interessante Sache. Der Ansatz sollte sich stark von OLTP-Datenbanken unterscheiden, da Abfragen in der Regel lange Zeit in analytischen Datenbanken durchgeführt werden. Wenn in PostgreSQL der Abfrageausführungsplan statisch ist, ist es sinnvoll, fast eine Abfrage zu überwachen.

In diesem Bericht wird Nikita Lapkov über das Design eines solchen ClickHouse-Anforderungsprofilers sprechen, mit dem Sie bestimmen können, welcher Abschnitt des Codes für eine bestimmte Anforderung langsamer wird . Und ergreifen Sie geeignete Maßnahmen, um das berühmte "ClickHouse verlangsamt nicht" zu implementieren.

Backup in moderner Infrastruktur

Dieser Bericht stammt nur aus der Reihe "neben der Datenbank" und untersucht das Systemproblem. Der größte Teil davon befasst sich jedoch mit dem Thema Backups in MySQL. Die Geschichte von Anton Turetsky wird auf jeden Fall interessant sein, da es sich um die Erfahrung von Badoo handelt, also um eine große Anzahl von Servern . In einem solchen Maßstab ist das Sichern und vor allem das Überprüfen von allem keine triviale Aufgabe. Darüber hinaus gelang es ihnen, sich mit modernen Trends und Paradigmen beim Entwurf von Systemen mit Backup anzufreunden, um nicht das Vertrauen zu verlieren, dass die erforderlichen Daten in jedem, selbst im kritischsten Fall, abgerufen werden können.

NB: Backups ohne automatische Überprüfung sind keine Backups.

Umzug nach ClickHouse: 3 Jahre später

ClickHouse erobert seine Position zuversichtlich, aber nur wenige Entwickler von Drittanbietern konnten solide Erfahrungen mit der Arbeit sammeln. Alexander Zaitsev und Altinity sind Pioniere bei der Verwendung von ClickHouse und sprachen bereits vor 3 Jahren bei HighLoad ++ über die Verlagerung eines Multi-Petabyte-Analysesystems auf ClickHouse.

Was hat sich seitdem geändert? Alexander wird seine Erfahrungen und sein Know-how teilen , die in der Dokumentation nicht zu finden sind.

MongoDB vs. Postgres-Benchmarks

Zwei Gäste werden über MongoDB in HighLoad ++ sprechen. Der Bericht von Álvaro Hernández hat einen interessanten, sogar skandalösen Hintergrund. Als Alvaro Benchmarks zum Vergleich von MongoDB und PostgreSQL erstellte und einführte, kam es im Internet zu einem Gefecht. MongoDB stellte später ihre Benchmarks vor.

Infolgedessen hat jede der Welten einfach ihre eigene Philosophie. PostgreSQL-Anhänger haben es schwer, eine derart verschwommene Haltung gegenüber Daten zu akzeptieren, aber MongoDB-Lösungen sind auf dem Markt gefragt. Ein direkter Vergleich ist fast unmöglich, und das macht Alvaros Bericht sehr aufregend. Es ist leicht, blind an einem Standpunkt festzuhalten, aber es ist viel besser, beide zu kennen und zu verstehen.

Dies ist eine lustige Tatsache für alle - Michael Stonebreaker hat teilgenommen. Er machte auf den Streit zwischen Postgres und Mongo aufmerksam und veröffentlichte mehrere Artikel über die Probleme dieses Modells. Das heißt, der Gründer von Postgres, der einst sagte, dass eine Größe nicht für alle geeignet ist, und infolgedessen die Erstellung spezialisierter Datenbanken, einschließlich NoSQL, auf den Weg brachte, kehrt nun im Wesentlichen zu Postgres zurück. Er schreibt, welche Probleme es gibt, schlägt vor, Datenmodelle zu heiraten, und sagt im Allgemeinen, dass mit Postgres alles in Ordnung ist. Es ist sehr interessant, diesen 20-Jahres-Zyklus zu beobachten.

MongoDB verteilte Transaktionen von oben nach unten

Der zweite Bericht über MongoDB wird von Henrik Ingo, dem MongoDB-Lösungsarchitekten, erstellt, der sich auf die Verbesserung der MongoDB-Leistung und die Bereitstellung hoher Verfügbarkeit spezialisiert hat. Aber Henrik, vor MongoDB, hat viele Jahre in der MySQL-Welt gearbeitet, sodass er die Argumente verschiedener Lager genau kennt.

In HighLoad ++ erklärt Ihnen Henrik , wie Transaktionen in einer verteilten NoSQL-Datenbank ACID erfüllen und warum Sie sie möglicherweise überhaupt benötigen.

Odyssey-Roadmap: Was wollen wir noch vom Verbindungsabzieher?

Vor drei Wochen wurde die Hauptbeschränkung von PgBouncer, auf die Unternehmen häufig stoßen, aufgehoben, aber es gelang bereits, alle zu stören. Zum Beispiel, weil es unmöglich war, Verbesserungen an Open Source vorzunehmen - Yandex- und Avito-Patches werden seit Jahren nicht mehr akzeptiert.

Yandex wartete nicht auf diese Änderungen und machte ihren Verbindungsabzieher - Odyssey. Es ist Multithread, es hat zusätzliche Chips, und Andrei Borodin wird in seinem Bericht ausführlicher darauf eingehen. Darüber hinaus wird es möglich sein, die Roadmap zu diskutieren - welche Funktionen der Abzieher in den neuen Versionen der Community sehen möchte.

DBA-Bot Joe. Entlasten Sie den Schmerz der Backend-Entwicklung

Mit diesem Bericht schlägt Postgres.ai vor, den Ansatz für die Backend-Entwicklung grundlegend zu ändern. Anstatt den Code und die Abfragen in kleinen Datenbanken zu überprüfen, überprüfen Sie große Datenbanken und sehen Sie sofort das Ergebnis. Es klingt logisch - wenn die Anfrage langsam ist, wird sie sofort erkannt. Eine andere Sache ist, was zu tun ist, zum Beispiel sind vollwertige Kopien der Kampfdatenbank sehr unpraktisch. Hier kommt der künstliche DBA-Bot Joe zur Rettung

Joe kann eine Anfrage schreiben oder darum bitten, einen Index zu erstellen, und er führt alle Aktionen für eine Kopie der Kampfdatenbank in voller Größe aus. Sie können jederzeit von vorne beginnen, alle Änderungen in wenigen Sekunden rückgängig machen und die Caches für Betriebssystem und DBMS löschen. Und für die Arbeit von zehn Entwicklern benötigen Sie keinen x10-Speicherplatz. Wie diese Magie funktioniert und von welchen Open-Source-Komponenten Sie versuchen können, sie von sich selbst zu sammeln, wird Anatoly Stansler erzählen .

Lieber DELETE. Typische Fehler bei der Ausführung umfangreicher Vorgänge in hoch geladenen PostgreSQL-Datenbanken

Und wenn jemand den Eindruck hat, dass es nichts auszusetzen hat, mehrere Millionen Zeilen mit einem DELETE zu löschen, wenn die Bedingung bekannt ist und ein geeigneter Index vorhanden ist, müssen Sie sich den Bericht von Nikolai Samokhvalov anhören. Wenn Sie versuchen, eine Operation unter solchen Bedingungen durchzuführen, fällt der Dienst höchstwahrscheinlich aus, und es gibt viele Gründe dafür: Die Datenbankadministratoren funktionierten nicht gut, die Entwickler verhielten sich falsch und der organisatorische Ansatz war falsch.

Nikolay wird zeigen, wie Postgres.ai zur Lösung dieser Probleme beiträgt und wie der Schutz konfiguriert wird, ohne ihn zu verwenden, und immer zuverlässig zu handeln, ohne das Produkt fallen zu lassen. All dies basiert auf echten Schmerzenserfahrungen und enormen finanziellen Verlusten . Denn es scheint klar zu sein, dass Sie Daten nicht sofort löschen können, sondern beispielsweise zuerst Daten zum Löschen markieren, aber Blockierungsvorgänge auf einer Million Zeilen auftreten.

Patroni auf GitLab.com

GitLab verwendet PostgreSQL vollständig, kürzlich aufgegebenes MySQL, um sicherzustellen, dass HA von REPMGR auf Patroni umgestellt wird. Patroni wurde von Zalando entwickelt und hat die Aufgabe, automatisch zu wechseln, wenn etwas mit dem Assistenten passiert ist, und die Verfügbarkeit des Dienstes sicherzustellen.

Jetzt ist Patroni der De-facto-Standard , und GitLab hat ihn in seiner Cloud-Lösung implementiert - für eine Sekunde 25.000.000 Git-Pull-Vorgänge pro Tag - und bereitet eine Lösung für die Überprüfung von Installationen vor. Jose Cores Finotto wird diese interessante Erfahrung am 7. November auf HighLoad ++ teilen .

StackGres: Cloud-natives PostgreSQL auf Kubernetes

Álvaro Hernández wird im Vergleich zu PostgreSQL und MongoDB auch das StackGres-Produkt vorstellen - im Wesentlichen ein Ersatz für RDS. Aber es macht es möglich, RDS in Kubernetes viel billiger bereitzustellen, Backups mit minimalem Aufwand mit einem Trailer, Patroni für Auto-Failover, Integritätsprüfung und einer Reihe verschiedener Tools zu konfigurieren.

Dies ist ein vielversprechendes Unterfangen in einer ähnlichen Richtung wie die Linux-Geschichte. Es gibt einen Linux-Kernel und viele verschiedene Assemblys. Wir sehen dasselbe in Bezug auf PostgreSQL, das als Kernel für ein DBMS betrachtet werden kann, und Assemblies werden darum herum angezeigt. StackGres hat gute Chancen, an Popularität zu gewinnen, da es ein lebhaftes Team und Kunden gibt, in denen Sie Ihre Entscheidungen treffen können.

PostgreSQL-Sperren

Sperren sind grundsätzlich ein Thema, das jeder, der mit PostgreSQL arbeitet, anhören sollte. Darüber hinaus wird Jegor Rogow, der sich als Drop-Dead-Dozent etabliert hat, darüber sprechen. Er kennt das Material sehr gut und wird Ihnen helfen, die Arten von Sperren zu verstehen und zu verstehen, wie man pg_locks und pg_stat_activity liest und eine Reihe von Fehlern im Systemdesign vermeidet. Egors Bericht über HighLoad ++ ist eine großartige Gelegenheit, nicht nur zuzuhören, sondern mit einem Experten zu sprechen, ihm Ihre Fragen zu stellen und möglicherweise ganz andere Probleme zu diskutieren.

Sichern geladener DBMS

Andrey Borodin und Georgy Rylov arbeiten bei Yandex und entwickeln WAL-G, ein Open-Source-Backup-Tool.

Ursprünglich ist WAL-G ein von Citus entwickeltes Tool für PostgreSQL (es ist merkwürdig, dass Microsoft kürzlich Citus übernommen hat, dh tatsächlich ein Stück PostgreSQL gekauft hat). Es stellte sich jedoch heraus, dass die Idee, die Arbeit mit WAL-G zu organisieren, gut für andere Datenbanken geeignet ist. Andrew und George werden nur über die Funktionalität von MySQL, Redis, MongoDB und die damit verbundenen Perspektiven sprechen .

Vitess: Scaling furchtlos in der Cloud

Sugu Sougoumarane ist der Gründer von PlanetScale. Sie haben vielleicht noch nichts von diesem Unternehmen gehört, aber kürzlich erhielt es eine Finanzierung von 25 Millionen US-Dollar für die Entwicklung seines offenen Vitess-Produkts. Sie haben vielleicht auch noch nichts von Vitess gehört. Vitess ist also ein MySQL-Sharding-System , und Sie kennen definitiv mehr als ein großes Unternehmen, das Vitess für hochgeladene Datenbanken verwendet.

Alles begann mit YouTube. Dort haben Sugu und sein Team das Open-Source-System Vitess entwickelt. Übrigens haben sie sich für Go entschieden - eine damals noch sehr junge Sprache. Sugu kann viele interessante Geschichten über die ersten Jahre von Go und über seine Entwicklung im Allgemeinen erzählen - auf Google wurde sein Team der erste Hauptnutzer der Sprache.

Nun, zusätzlich zu YouTube wird Vitess von Unternehmen wie GitHub, Pinterest, Slack, Square verwendet. Nach dem Verlassen von Google gründete Sugu PlanetScale und entwickelt Vitess weiter, wobei der Code weiterhin offen bleibt. Kommen Sie und erfahren Sie, wie Sie auf planetarischer Ebene Splitter erstellen und Go in echtem Highload verwenden. Und vergessen Sie nicht, nach den Plänen für die Postgres-Version von Vitess zu fragen - Sugu liebt diese Frage sehr.

Patroni-Fehlergeschichten oder Absturz Ihres PostgreSQL-Clusters

Es ist lustig, dass wir dem Hauptbetreuer von Patroni zu einem anderen Thema zuhören, weil er uns bereits von Patroni erzählt hat. Aber Aleksey Lesovsky kann sagen, wie Patroni außerhalb von Zalando ausgebeutet wird und welche Zapfen gefüllt sind. Weil diese Kegel sehr unterschiedlich sein können und Alex verspricht, die Details von echten Crash-Fällen zu teilen. Wir werden aus dem Bericht lernen , welche Probleme es gibt, welche Lehren aus Data Egret gezogen wurden und wie Patroni (und möglicherweise PostgreSQL) richtig konfiguriert wird. Und natürlich bekommen wir eine Vorstellung davon, wie aufkommende Probleme schnell identifiziert und schnell behoben werden können.

SQL / JSON: Wir implementieren den Standard und hören hier nicht auf

In jüngster Zeit wurde die Grenze zwischen relationalen und dokumentenorientierten DBMS verwischt. Der SQL-Standard verfügt über Funktionen für die Arbeit mit JSON, und PostgreSQL ist ein Pionier der effektiven JSON-Unterstützung unter relationalen DBMS . Vor allem dank Postgres Professional wurde der Standard bereits teilweise implementiert.

Der Bericht von Alexander Korotkov ist ein Bericht aus erster Hand über die SQL / JSON-Implementierung und ihren "Herz" -Jsonpfad in PostgreSQL. Dies ist eine Gelegenheit, sich über interne Funktionen, Betriebserfahrungen und Pläne für die Zukunft zu informieren.

PostgreSQL auf K8s in Zalando: zwei Jahre im Kampf

Alexander Kukushkin ist Mitautor von Patroni, aber dieses Jahr wird er über eine weitere interessante Entwicklung von Zalando sprechen . Vor zwei Jahren haben sie mit der Entwicklung von Postgres-Operator begonnen. Derzeit bedienen DBA-Betreiber mit ihrer Hilfe mehr als 1000 Postgres-Cluster, die auf Kubernetes ausgeführt werden.

Während manche noch bezweifeln, ob Datenbanken in Kubernetes möglich sind, arbeiten große Unternehmen bereits damit. Es wäre cool, woanders etwas kennenzulernen und zu lernen.

Enterprise fordert Postgres

Große Unternehmen setzen zunehmend PostgreSQL ein und erwarten sehr oft, was sie im Unternehmen gewohnt sind. Ein typisches Beispiel - wir brauchen Lösungen für die logische Replikation - wir wenden uns an den Anbieter. Und einige Anbieter haben sogar solche Unterstützung geleistet - es gab Oracle, jetzt ist PostgreSQL erschienen. Aber wir beginnen zu verstehen, und es stellt sich heraus, dass vieles anders funktioniert.

Wir erleben die Kollision der Welten von Open Source und Enterprise. Andreessen Horowitz hat kürzlich eine Studie veröffentlicht, die besagt, dass das Interesse der Anleger an Open Source erheblich gestiegen ist und weiter zunehmen wird. Daher müssen Anbieter auf Open Source und neue Monetarisierungsmodelle umsteigen - dies ist aus mehreren Gründen besser.

Ivan Panchenko wird Ihnen genau sagen , welche Schwierigkeiten bei der Migration auf PostgreSQL für Unternehmen subjektiv sind und zu den „krummen Händen“ gehören, und wann diese wichtigen Herausforderungen zu bewältigen sind, mit denen PostgreSQL während seiner Entwicklung konfrontiert ist. Abstracts versprechen die Diskussion solcher Themen: Skalierungsfaktoren (Tabellengrößen, Anzahl der Objekte, Speicher, Verbindungen, Replikation), Speicherfunktionen (Heap, steckbare Speicher), temporäre Tabellen, Vakuum, Interaktion mit dem Betriebssystem.

In diesem Sinne - die Zukunft ist Open Source - werden wir eine detaillierte Studie der Berichte durchführen. Leider wurde MySQL hinter den Kulissen fast vollständig zurückgelassen. Wenn dies Ihr Thema ist, schauen Sie sich Vittorio Cioe und Alkin Tezuysal an .

ClickHouse ist auch in einer größeren Anzahl von Berichten vertreten, und wie immer ist eine Mitap von besonderem Wert, bei der Sie Fragen zu ClickHouse stellen und gemeinsam mit Entwicklern eine Lösung für Probleme finden, Möglichkeiten und Pläne diskutieren können.

Wir haben Tarantool auch nicht berührt, da dies eine Datenbank und ein Anwendungsserver in einer Flasche sind. Die Berichte im Programm HighLoad ++ 2019 konzentrieren sich auf diese Multifunktionalität. Vasily Tyubek wird über Tarantool Kubernetes Operator sprechen, um eine Datenbank in Kubernetes zu betreiben. Yaroslav Dynnikov wird die Bequemlichkeit des Aufbaus verteilter Systeme mit Tarantool demonstrieren. Verpassen Sie nicht die Gelegenheit, alle Details mit den Entwicklern selbst zu klären - es ist viel produktiver und interessanter als das Lesen der Dokumentation.

Im Allgemeinen betrachten wir Fragen an Redner, Diskussionen hinter den Kulissen und das Networking - ein sehr, wenn nicht der wichtigste Teil der Konferenz. Deshalb schaffen wir alle Voraussetzungen für informelle Kommunikation und versuchen , eine gute Zeit zu haben.

Am 7. und 8. November wird HighLoad ++ SKOLKOVO bis zum Rand füllen und herausspritzen. In Nowosibirsk und St. Petersburg gibt es ihre HighLoad ++ - Niederlassungen mit einer Telefonkonferenz zur Haupthalle und allen Vorteilen der Vernetzung auf der Konferenz. Auf Youtube werden wir eine offene Videoübertragung der am meisten erwarteten Berichte und des HighLoad ++ Award starten und im Telegrammkanal auf dem anderen Weg die Textübersetzungsagenten starten. Kurz gesagt, auch wenn Sie nicht zu HighLoad ++ wechseln (vergebens - Sie können Ihre Meinung ändern, ein Ticket erhalten und abheben), können Sie über unsere Netzwerke immer noch viel Gutes und Spaß haben.