MySQL-Lösungen in PostgreSQL: Polar-Architektur für hohe Leistung

# Integration von MySQL-Lösungen in PostgreSQL: Architekturinnovationen für hohe Leistung

Auf der PG BootCamp 2026 Konferenz hielt Alexey Kopytov (Autor von sysbench und ehemaliger Entwickler bei MySQL AB/Percona) einen Vortrag über das Portieren von Optimierungen aus dem MySQL-Ökosystem nach PostgreSQL. Der zentrale Punkt: bewährte Lösungen nutzen, um die Ausfallsicherheit und Leistung von PostgreSQL in Systemen mit hoher Last zu steigern. Besonders interessant ist die Umsetzung der Compute-Storage-Separierungstechnologie, die das Tantor-Team auf Basis von Alibaba PolarDB angepasst hat.

Der Hauptvorteil dieses Ansatzes besteht darin, volle Kompatibilität mit PostgreSQL zu wahren und gleichzeitig den Durchsatz erheblich zu steigern. Im Gegensatz zu Sharding- oder verteilten Lösungen (Citus, Greenplum) bewältigt die Tantor Polar-Architektur Cross-Shard-Abfragen, ohne ACID-Garantien aufzugeben – entscheidend für OLTP-Systeme.

Klassifikation von Architekturlösungen für DBMS

Alexey Kopytov schlug eine klare Klassifikation bestehender Ansätze zur Trennung von Compute- und Storage-Knoten vor:

• Sharding- und MPP-Systeme (Greenplum, Citus): Trennung auf SQL-Parser-Ebene. Problem – Fehlen der Konsistenz auf Snapshot-Ebene (xid/SCN)
• Verteilte transaktionale DBMS (Spanner, YugabyteDB): Transaktionsverarbeitung auf Storage-Knoten
• „LOG is DB“-Architekturen (Amazon Aurora, Neon): Primat des Change-Logs, WAL-Verarbeitung auf Storage
• Polar-Architektur (Tantor Polar): Trennung direkt über der Storage-Schicht

Der entscheidende Unterschied des Polar-Ansatzes ist die Minimierung von Änderungen am PostgreSQL-Kern. Alle Optimierungen werden auf Dateisystem-Ebene umgesetzt (PolarFS), was ermöglicht:

• 100% Kompatibilität mit bestehenden Anwendungen (einschließlich 1C)
• Vermeidung invasiver Änderungen am PostgreSQL-Kern
• Unterstützung bestehender Backup-Tools

Tantor Polar-Architektur: Technische Umsetzung

Das System basiert auf drei Schlüsselteilen:

• PolarFS – hochperformantes Dateisystem über RDMA/NVMe-oF
• RDMA-Netzwerk – für die Kommunikation zwischen Compute- und Storage-Knoten
• Modifiziertes PostgreSQL – mit minimalen Änderungen am I/O-Subsystem

Ein Highlight ist die Nutzung von Linux MD Cluster als Basis für Blockgeräte. Diese Lösung liefert:

• Datenzugriffs-Latenzzeiten vergleichbar mit lokalen SSDs (5-10 μs)
• Transparente Skalierung von Compute-Knoten unabhängig vom Storage
• Unterstützung für Active-Active-Modus auf RW-Knoten

Wichtig: PolarFS arbeitet über die standardmäßige POSIX-Schnittstelle und macht Kernänderungen an PostgreSQL überflüssig. Alle Änderungen beschränken sich auf den Dateisystem-Treiber, was Upstream-Integration und Wartung stark vereinfacht.

Vergleich mit Oracle RAC und anderen Lösungen

Obwohl konzeptionell ähnlich zu Oracle RAC, sind die Unterschiede erheblich:

• Datenübertragungsprotokoll: Polar nutzt NVMe-oF über RDMA, RAC ein proprietäres Protokoll
• Trennungsebene: Polar trennt auf Dateisystem-Ebene, RAC auf ASM-Ebene
• Open Source: PolarFS wird als Open Source freigegeben, im Gegensatz zu ASM

Die RDMA-Umsetzung verdient besondere Erwähnung. Frühe Versuche (in PostgresPro 10-11) erforderten tiefe PostgreSQL-Kernänderungen. Tantor wählte einen nicht-invasiven Weg über den Dateisystem-Treiber, was ermöglicht:

• Beseitigung asymmetrischer Zugriffs-Latenzprobleme
• Einheitliche Leistung auf allen Compute-Knoten
• Erhalt des standardmäßigen WAL-Handling-Mechanismus

Wichtige Erkenntnisse

• Kompatibilität ohne Kompromisse: Tantor Polar unterstützt alle PostgreSQL-Features, einschließlich komplexer JOINs und Transaktionen
• RDMA-Leistung: Latenzzeiten auf dem Niveau lokaler SSDs (5-10 μs) über das Netzwerk
• Skalierbarkeit: Compute und Storage skalieren unabhängig
• Offenheit: PolarFS wird unter einer Open-Source-Lizenz verfügbar sein
• Produktionsreife: Die Lösung ist bereits bei XData Gen.3 im Einsatz (3 Storage + N Compute-Knoten)

Technische Umsetzungsdetails

Schlüssel-Architekturkomponenten:

// Example of RDMA integration into the I/O subsystem
static int polarfs_submit_io(struct io_request *req) {
    if (use_rdma) {
        return rdma_send(req->buffer, req->length);
    }
    return posix_write(req->fd, req->buffer, req->length);
}

Optimierungen konzentrieren sich auf drei Bereiche:

• Buffer-Verwaltung: Metadaten-Caching auf Compute-Knoten
• WAL-Handling: Asynchrone RDMA-Sends mit Bestätigungen
• Lock-Manager: Verteilte Umsetzung ohne Single Point of Failure

Besondere Aufmerksamkeit galt Randfällen:

• Wiederherstellung nach RDMA-Verbindungsabbrüchen
• Umgang mit asymmetrischen Netzwerk-Latenzzeiten
• Garantie der Atomizität von Schreiboperationen

Benchmarks mit PolarFS zeigen:

• Durchsatzsteigerungen von 35-40 % unter hoher Last
• 99th-Percentil-Latenzzeiten um den Faktor 2,3 reduziert
• Spitzen-Transaktionen pro Sekunde um 28 % höher

Fazit

Tantors Ansatz zeigt, wie das Portieren von Lösungen zwischen DBMS-Ökosystemen zu großen Gewinnen führen kann. Der Erfolgs-Schlüssel – minimale Invasivität und Fokus auf Kompatibilität. Die Polar-Architektur eröffnet PostgreSQL neue Skalierungsmöglichkeiten in Szenarien, die zuvor radikale App-Änderungen oder einen Wechsel zu NoSQL erforderten.

Bemerkenswert: Die Umsetzung benötigt keine spezielle Hardware – nur RDMA- und NVMe-oF-Netzwerkunterstützung. Das macht sie für viele Organisationen zugänglich, die wachsende Lasten auf bestehenden PostgreSQL-Clustern bewältigen müssen.

— Editorial Team