Ich hatte kürzlich die Gelegenheit, an einigen interessanten Vorträgen über die Zukunft von Sharding in PostgreSQL teilzunehmen. Der erste Vortrag wurde von Bruce Momjain auf der PostgreSQL conf Ottawa (Mai 2019) gehalten, in dem er die Zukunft des Shardings in PostgreSQL vorstellte und über den aktuellen Stand und die Zukunft des integrierten Shardings in PostgreSQL sprach. Der zweite Vortrag wurde von mir auf der PostgreSQL–Konferenz in Peking (China – Juli 2019) gehalten, in der ich auch über den aktuellen Stand und die Zukunft des integrierten Shardings in PG sprach. Ich habe im Wesentlichen die Folien aus Bruces Präsentation verwendet (natürlich mit seiner Erlaubnis) und einige weitere Folien hinzugefügt, in denen die Anforderungen erläutert wurden, die die Skalierbarkeit rechtfertigen, und auch über andere Alternativen für Global Transaction Manager gesprochen.
Während der PostgreSQL-Konferenz in Ottawa setzte ich die Tradition fort, während der Konferenzwoche ein Frühstückstreffen zu arrangieren, um das Sharding-Thema zu diskutieren. Wir haben dies jedes Jahr für die letzten Jahre getan, als ich mit EnterpriseDB arbeitete und das Treffen fortsetzte, jetzt wo ich mit HighGo Software Inc. arbeite. Das diesjährige Frühstückstreffen wurde von Leuten von EDB besucht, NTT, HighGO und Pivotal, Die Anzahl der Teilnehmer in diesem Jahr war mehr als das, was wir in den letzten Jahren bekommen haben, also mussten wir uns für einen größeren Frühstückstisch entscheiden. 🙂 Der Zweck dieses Treffens ist es, Leute von Unternehmen zu gewinnen, die an dieser Funktion in der Community arbeiten, und diesmal auch Leute von Unternehmen, die beabsichtigen, zu dieser Funktion in der Community beizutragen. Auf der Tagesordnung steht die Erörterung des aktuellen Stands des integrierten Shardings, der laufenden Arbeiten und der kommenden Schritte. Die anderen Themen, die in diesem Meeting diskutiert werden, sind das übergeordnete Ziel für die Sharding-Funktion, welche Anwendungsfälle wir von diesen Funktionen profitieren erwarten, was sind die groben Zeitskalen, um etwas in PG zu bekommen, das wir Sharding nennen können.
Über diesen Blog
Ich hatte ursprünglich gehofft, dieses Thema in einem Blog zu behandeln, aber da diese Funktion so groß ist, erwies sich der Blog auch als viel länger als das, was ich ursprünglich erwartet hatte. Ich habe dies in 3 Blogs behandelt, damit die Leute nicht müde werden, es zu lesen und dort das Interesse zu verlieren. Die Schlussfolgerung wird am Ende des 3. Blogs dieser Serie gegeben.
Im ersten Blog der Serie geht es um Skalierbarkeit, welche Arten von Skalierbarkeit gibt es und welche Optionen für die Skalierbarkeit in PostgreSQL derzeit verfügbar sind. Der zweite Teil des Blogs konzentriert sich auf die deklarative Partitionierung, die in PG 10 hinzugefügt wurde, und wie Sharding in PostgreSQL heute funktioniert. Der dritte Teil dieses Blogs konzentriert sich auf die integrierte Sharding-Architektur, Pushdown-Funktionen bereits in PG und schließlich die verbleibenden Funktionen und die damit verbundenen Herausforderungen.
Eine Sache, über die ich in diesem Blog nicht gesprochen habe, sind andere Lösungen, die versucht haben, Sharding bereitzustellen. Ich glaube, einige dieser Versuche waren beeindruckend, aber alle haben Einschränkungen, die sie daran gehindert haben, die Hauptsendezeit mit der PG-Community zu erreichen.
Was ist Skalierbarkeit und warum wir sie brauchen
Bevor wir mit dem Sharding beginnen, ist es wichtig zu verstehen, „was ist Skalierbarkeit“ und die Notwendigkeit von Skalierbarkeit und welche verschiedenen Möglichkeiten gibt es, um Ihre Datenbank skalierbar zu machen. Datenbankskalierung ist im Grunde die Fähigkeit, den Datenbankdurchsatz / die Leistung zu erhöhen, indem Ressourcen wie E / A, Arbeitsspeicher, CPU erhöht oder dem Cluster zusätzliche Computer hinzugefügt werden. Das Hinzufügen von mehr Berechnungen wiederum bedeutet auch, die Datenbankleistung zu erhöhen, indem Ressourcen aus mehreren Systemen für die Ausführung der Aufgabe verwendet werden. Ihre Datenbank muss nur skalierbar sein, wenn Sie Ihre PostgreSQL-Datenbank auf einem einzigen Standardserver ausführen und die Anforderungen Ihrer Arbeitslast nicht erfüllen können. Die Symptome, die auf die Notwendigkeit der Skalierbarkeit hinweisen, sind, dass die Datenbank nicht gut funktioniert, die Datengröße sehr groß wird und nicht in den Speicher des Servers passt, die Datenbank zu viele gleichzeitige Clients erhält, die sie nicht verarbeiten kann, es gibt komplexe analytische Abfragen, deren Ausführung zu lange dauert oder in einigen Fällen überhaupt keine Daten zurückgibt und das System zum Stillstand bringt.
Wenn der Benutzer beginnt, einige der im vorherigen Absatz erwähnten Probleme zu sehen, muss er über verschiedene Optionen nachdenken, um dieses Problem anzugehen, bevor er letztendlich über Skalierbarkeit nachdenkt.Die verschiedenen Optionen, die der Benutzer berücksichtigen sollte, bevor er über die Skalierbarkeit nachdenkt, sind folgende :
- Schemaoptimierung – Sie müssen sicherstellen, dass das Schema vollständig für die Arbeitslast und die Art der Abfragen optimiert ist, die an den Datenbankserver gesendet werden. Ein wichtiger Aspekt besteht darin, zu überprüfen, ob die Benutzertabellen groß genug sind, um partitioniert zu werden, damit die Abfragen an Tabellen mit kleinerer Größe weitergeleitet werden können. Sie müssen auch überlegen, ob die Tabellen richtig normalisiert sind.
- Optimierung der Anwendungslogik – Ein weiterer wichtiger Bereich, über den wir nachdenken müssen, wenn wir auf ein Problem stoßen, ist die Optimierung der Anwendungslogik. Der Benutzer kann darüber nachdenken, ob die Anwendung optimiert werden kann, um die beste Leistung aus der Datenbank zu erzielen. Dies kann das Umschreiben einiger Datenbankabfragen oder in einigen Fällen das Refactoring auf Anwendungsebene umfassen, um die Leistung zu beschleunigen.
- Datenbankkonfigurationsparameter-Tuning – Dies ist wahrscheinlich der wichtigste Vorschlag aus den Optionen, die Datenbankkonfigurationsparameter müssen entsprechend der Arbeitslast und der Art des für die Datenbank generierten Datenverkehrs geändert werden. Die Werte für wichtige Parameter wie Shared Memory, Work Mem, Checkpoint usw. müssen ordnungsgemäß und entsprechend dem Worklaod konfiguriert werden. Dies ist eine gute Quelle, die einige der wichtigen Konfigurationsparameter für die PG-Datenbanktuning diskutiert.
https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
Skalierbarkeitsoptionen
Nachdem Sie alle oben genannten Optionen oder mehr ausprobiert haben und die Probleme weiterhin bestehen, sollten Sie am besten über Skalierbarkeitsoptionen nachdenken. Die Datenbank kann auf zwei Arten skaliert werden :
Die beiden Optionen der Skalierbarkeit sind ziemlich einfach zu verstehen: Bei der vertikalen Skalierbarkeit geht es um die Skalierung nach oben und bei der horizontalen Skalierbarkeit um die Skalierung von Seiten. Vertikale Skalierbarkeit wird erreicht, indem der einzelne Server verbessert wird und dem Server mehr Ressourcen hinzugefügt werden, um Skalierbarkeit zu erreichen. Bei der horizontalen Skalierbarkeit geht es darum, mehr Computer auf das Problem zu werfen und dem Cluster mehr Knoten hinzuzufügen, um Ressourcen von mehreren Computern zu verwenden, um die Datenbankskalierbarkeit zu verbessern.
Vertikale Skalierbarkeit ist der richtige Weg, wenn sie die Benutzeranforderungen erfüllt und auch für den Benutzer kostengünstig ist. Der Grund, warum Vertical die bevorzugte Option ist, liegt in der einfachen Konfiguration und dem minimalen Wartungs- und Manager-Overhead. Sie können den Server einfach mit schnellerem Speicher und mehr Arbeitsspeicher aufpeppen und mehr und schnellere CPU hinzufügen, um die Leistung Ihrer Datenbank zu steigern. Es gibt hauptsächlich zwei Gründe, warum vertikale Skalierbarkeit für Ihre Arbeitslast nicht mehr die Option ist. Der erste und wichtigste Grund ist, dass die Verbesserung des Servers sehr kostspielig sein kann und irgendwann für den Benutzer kostengünstig werden kann. Der zweite Grund ist, dass die Workload-Anforderungen, dh Speicher, Anzahl der gleichzeitigen Clients und eingehender Datenverkehr, so hoch werden, dass der einzelne Server nicht skaliert werden kann, um der Workload gerecht zu werden. Es gibt Diskussionen, dass PostgreSQL nur auf 64 Kerne skalieren kann und danach die Linie linear wird. Es handelt sich jedoch um veröffentlichte Benchmark-Ergebnisse, die eine PostgreSQL-Skalierung auf mehr als 64 Kernen zeigen.
Bei der horizontalen Skalierbarkeit geht es darum, dem Datenbankcluster mehr als einen Computer hinzuzufügen, um die Ressourcen zusätzlicher Computer für die horizontale Skalierbarkeit zu nutzen. Horizontale Skalierbarkeit ist nicht die erste Wahl, da sie den Aufwand für die Konfiguration und Wartung von Maschinenclustern mit sich bringt, sodass der Benutzer über Ausfallzeiten, Failover, Sicherung usw. aller Maschinen im Cluster nachdenken muss. Horizontale Skalierbarkeit ist die naheliegende Wahl, wenn die Workload-Anforderungen aus den im vorherigen Absatz genannten Gründen nicht mit einem einzelnen Server erfüllt werden können. Die beliebteste Lösung für horizontale Skalierbarkeit ohne Sharding ist die Leseskalierbarkeit mit Pgpool II. Pgpool II ist ein Middleware-Produkt, das sich zwischen dem Client und dem PostgreSQL-Cluster befindet und Funktionen wie Verbindungspooling, Lastausgleich, Failover usw. bietet. Pgpool II bietet horizontale Skalierbarkeit durch Lastausgleich, Senden der Schreibvorgänge an den primären Knoten und Lastausgleich der Leseanweisungen über die Standby-Knoten. Pgpool II bietet Load Balancing auf Verbindungsebene und Anweisungsebene, mit Load Balancing auf Verbindungsebene Pgpool II Prozess stellt eine Verbindung mit einem Stand-by-Knoten her, Alle Lesevorgänge für die Verbindung werden an den Stand-by-Knoten gesendet und Schreibvorgänge werden an den primären Knoten gesendet. Bei der Verbindung auf Anweisungsebene (ab Pgpool II 4.1) wird jede Anweisung über die Bereitschaftsknoten hinweg lastausgeglichen. Es gibt einen guten Artikel zu diesem Thema https://highgo.ca/2019/07/19/pgpool-ii-4-1-taking-the-bull-by-its-horn/
Ahsan Hadi ist Vice President of Development bei HighGo Software Inc. Bevor er zu HighGo Software kam, hatte Ahsan bei EnterpriseDB als Senior Director of Product Development gearbeitet, Ahsan arbeitete 15 Jahre bei EnterpriseDB. Das Flaggschiff von EnterpriseDB ist Postgres Plus Advanced Server, der auf Open Source PostgreSQL basiert. Ahsan verfügt über umfangreiche Erfahrung mit Postgres und hat das Entwicklungsteam von EnterpriseDB geleitet, um die Kernkompatibilität des Hinzufügens einer Oracle-kompatiblen Ebene zum Postgres Plus Advanced Server von EDB aufzubauen. Ahsan hat auch einige Jahre mit dem Entwicklungsteam zusammengearbeitet, um Postgres horizontale Skalierbarkeit und Sharding hinzuzufügen. Zunächst arbeitete er mit postgres-xc, einem Multi-Master-Sharding-Cluster, und arbeitete später an der Verwaltung der Entwicklung des Hinzufügens von horizontaler Skalierbarkeit / Sharding zu Postgres. Ahsan hat auch viel mit Postgres Foreign Data Wrapper-Technologie gearbeitet und an der Entwicklung und Wartung von FDWS für mehrere SQL- und NOSQL-Datenbanken wie MongoDB, Hadoop und MySQL gearbeitet.
Vor EnterpriseDB arbeitete Ahsan bei Fusion Technologies als Senior Project Manager. Fusion Tech war ein in den USA ansässiges Beratungsunternehmen, Ahsan leitete das Team, das Java-basierte Job Factory entwickelte, die für die Platzierung von Artikeln in Regalen in großen Geschäften wie Walmart verantwortlich war. Vor Fusion Technologies arbeitete Ahsan bei British Telecom als Analyst / Programmierer und entwickelte eine webbasierte Datenbankanwendung zur Überwachung von Netzwerkfehlern.
Ahsan kam im April 2019 zu HighGo Software Inc (Kanada) und leitet die Entwicklungsteams in mehreren Geos. Die Hauptverantwortung liegt in der Community-basierten Postgres-Entwicklung und auch in der Entwicklung von HighGo Postgres Server.