Rozwiązania MySQL w PostgreSQL: architektura Polar dla wysokiej wydajności

# Integracja rozwiązań MySQL w PostgreSQL: architektoniczne innowacje dla wysokiej wydajności

Na konferencji PG BootCamp 2026 Aleksej Kopytow (autor sysbench i były deweloper MySQL AB/Percona) przedstawił referat o przenoszeniu optymalizacji z ekosystemu MySQL do PostgreSQL. Kluczowa teza — wykorzystanie sprawdzonych rozwiązań do zwiększenia odporności na awarie i wydajności PostgreSQL w warunkach systemów o wysokiej obciążeniu. Szczególne zainteresowanie budzi implementacja technologii separacji compute i storage, zaadaptowana przez zespół Tantor na podstawie Alibaba PolarDB.

Główne zalety tego podejścia — zachowanie pełnej kompatybilności z PostgreSQL przy znacznym wzroście przepustowości. W odróżnieniu od shardingu czy rozwiązań rozproszonych (Citus, Greenplum), architektura Tantor Polar umożliwia obsługę zapytań między shardami bez utraty gwarancji ACID, co jest kluczowe dla systemów OLTP.

Klasyfikacja architektur rozwiązań dla systemów bazodanowych

Aleksej Kopytow zaproponował klarowną klasyfikację istniejących podejść do separacji węzłów obliczeniowych i magazynujących:

• Sharding i systemy MPP (Greenplum, Citus): separacja na poziomie parsera SQL. Problem — brak spójności na poziomie pojedynczego punktu w czasie (xid/SCN)
• Rozproszone transakcyjne systemy bazodanowe (Spanner, YugabyteDB): obsługa transakcji na węzłach storage
• Architektury „LOG is DB” (Amazon Aurora, Neon): pierwotność dziennika zmian, obsługa WAL na storage
• Architektura Polar (Tantor Polar): separacja bezpośrednio nad warstwą storage

Kluczowa różnica podejścia Polar — minimalizacja zmian w jądrze PostgreSQL. Wszystkie optymalizacje zaimplementowano na poziomie systemu plików (PolarFS), co pozwala:

• Zachować 100% kompatybilności z istniejącymi aplikacjami (w tym 1C)
• Uniknąć inwazyjnych modyfikacji w rdzeniu PostgreSQL
• Zapewnić współpracę z istniejącymi narzędziami do backupu

Architektura Tantor Polar: realizacja techniczna

System opiera się na trzech kluczowych komponentach:

• PolarFS — wysokowydajny system plików oparty na RDMA/NVMe-oF
• Sieć RDMA — do komunikacji między węzłami compute i storage
• Zmodyfikowany PostgreSQL — z minimalnymi zmianami w podsystemie I/O

Cechą implementacji jest wykorzystanie Linux MD Cluster jako warstwy bazowej dla urządzeń blokowych. To rozwiązanie zapewnia:

• Opóźnienia dostępu do danych porównywalne z lokalnym SSD (5-10 μs)
• Przejrzyste skalowanie węzłów compute niezależnie od storage
• Obsługę trybu Active-Active dla węzłów RW

Ważne, że PolarFS działa przez standardowy interfejs POSIX, co eliminuje potrzebę modyfikacji jądra PostgreSQL. Wszystkie zmiany skupiono w sterowniku systemu plików, co znacznie ułatwia backporting i utrzymanie.

Porównanie z Oracle RAC i innymi rozwiązaniami

Choć koncepcyjnie Polar przypomina Oracle RAC, różnice są znaczące:

• Protokół transmisji danych: Polar używa NVMe-oF nad RDMA, RAC — protokołu własnościowego
• Poziom separacji: w Polar separacja następuje na poziomie systemu plików, w RAC — na poziomie ASM
• Otwartość kodu: PolarFS zostanie udostępniony jako open source, w przeciwieństwie do ASM

Szczególnej uwagi zasługuje implementacja RDMA. Wczesne próby (w PostgresPro 10-11) wymagały głębokiej modyfikacji jądra PostgreSQL. Tantor zrealizował nieinwazyjne podejście przez sterownik systemu plików, co pozwoliło:

• Wyeliminować problem asymetrycznych opóźnień dostępu
• Zapewnić identyczną wydajność dla wszystkich węzłów compute
• Zachować standardowy mechanizm obsługi WAL

Co jest ważne

• Kompatybilność bez kompromisów: Tantor Polar obsługuje wszystkie funkcje PostgreSQL, w tym złożone JOIN i transakcje
• Wydajność RDMA: opóźnienia na poziomie lokalnego SSD (5-10 μs) przy pracy przez sieć
• Skalowalność: compute i storage skalują się niezależnie
• Otwartość: PolarFS będzie dostępny na licencji open-source
• Gotowość produkcyjna: rozwiązanie jest już używane w XData Gen.3 z konfiguracją 3 storage + N węzłów compute

Szczegóły techniczne implementacji

Kluczowe komponenty architektury:

// Przykład integracji RDMA w podsystemie I/O
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);
}

Optymalizacje skupiono w trzech obszarach:

• Zarządzanie buforami: buforowanie metadanych na węzłach compute
• Obsługa WAL: asynchroniczne wysyłanie przez RDMA z potwierdzeniem
• Menedżer blokad: rozproszona implementacja bez single point of failure

Szczególną uwagę poświęcono obsłudze przypadków brzegowych:

• Odzyskiwanie po zerwaniu połączenia RDMA
• Obsługa asymetrycznych opóźnień sieciowych
• Gwarancja atomowości operacji zapisu

Eksperymenty wykazały, że przy użyciu PolarFS:

• Przepustowość wzrasta o 35-40% przy wysokiej obciążeniu
• percentyl opóźnień spada 2,3 raza
• Maksymalna liczba transakcji na sekundę rośnie o 28%

Wniosek

Podejście Tantor pokazuje, jak przenoszenie rozwiązań między ekosystemami systemów bazodanowych może przynosić znaczące korzyści. Kluczowy sukces — minimalna inwazyjność zmian i nacisk na kompatybilność. Architektura Polar otwiera nowe możliwości skalowania PostgreSQL w warunkach, gdzie wcześniej wymagały radykalnych zmian aplikacji lub przejścia na rozwiązania NoSQL.

Ważne, że implementacja nie wymaga specjalistycznego sprzętu — wystarczy obsługa RDMA i NVMe-oF na poziomie sieci. To czyni rozwiązanie dostępnym dla szerokiego grona organizacji borykających się z wzrostem obciążenia istniejących klastrów PostgreSQL.

— Editorial Team