PostgreSQL sharding czy partycjonowanie? Wybierz dobrze!

Gdy baza PostgreSQL zaczyna rosnąć szybciej niż pojedynczy serwer, zwykłe indeksy i tuning zapytań przestają wystarczać. Wtedy pojawia się temat postgresql sharding, ale w praktyce najpierw trzeba odróżnić rozproszenie danych od klasycznego partycjonowania tabel, bo to są dwa różne narzędzia do dwóch różnych problemów. Poniżej pokazuję, kiedy wystarczy dobrze zaprojektowany podział tabel, kiedy trzeba wejść w architekturę wielowęzłową i jak podejść do tego bez kosztownych pomyłek.

Partycjonowanie i sharding rozwiązują różne ograniczenia

Największe nieporozumienie w tym temacie polega na tym, że oba podejścia wyglądają podobnie na poziomie modelu danych, ale kończą się zupełnie innym efektem. Partycjonowanie pomaga uporządkować jedną dużą tabelę i sprawić, że PostgreSQL odczyta tylko potrzebne fragmenty danych, czyli wykona pruning, a nie przeszuka całość. Sharding idzie dalej: rozkłada dane na wiele serwerów, dzięki czemu rosną nie tylko tabele, ale też dostępne CPU, pamięć i dysk.

To właśnie ta różnica decyduje, czy wystarczy przebudować jedną tabelę, czy trzeba zmienić całą architekturę danych. Następne pytanie jest już bardziej praktyczne: kiedy sama organizacja tabel daje wystarczający efekt, a kiedy to tylko odroczenie większego problemu?

Kiedy partycjonowanie w PostgreSQL wystarczy

W wielu systemach nie potrzeba jeszcze klastra rozproszonego, tylko porządnego partycjonowania. Ja zaczynam od niego zawsze wtedy, gdy zapytania naturalnie filtrują po czasie, tenant_id albo innym stabilnym kluczu, a największy ból powodują duże tabele, długie VACUUM-y i koszt utrzymania indeksów.

• Dane czasowe, takie jak logi, zdarzenia, telemetryka i historia operacji.
• Archiwa, w których stare fragmenty można odcinać albo usuwać całymi partycjami zamiast pojedynczymi wierszami.
• Aplikacje multi-tenant, ale nadal działające na jednej instancji bazy.
• Raporty, które zawsze zaczynają się od tego samego warunku, na przykład zakresu dat lub identyfikatora klienta.
• Modele, w których ważne jest szybkie izolowanie gorących i zimnych danych, czyli aktywnych i rzadko używanych rekordów.

CREATE TABLE events (
    id bigserial,
    tenant_id bigint NOT NULL,
    created_at timestamptz NOT NULL,
    payload jsonb NOT NULL
) PARTITION BY HASH (tenant_id);

CREATE TABLE events_p0 PARTITION OF events
FOR VALUES WITH (MODULUS 4, REMAINDER 0);

CREATE TABLE events_p1 PARTITION OF events
FOR VALUES WITH (MODULUS 4, REMAINDER 1);

Taki układ nie rozrzuca danych po wielu serwerach, ale już poprawia równowagę pracy w obrębie jednej instancji i ułatwia utrzymanie. W dokumentacji PostgreSQL ważne jest też jedno ograniczenie: przy partycjonowanej tabeli klucz unikalny albo PRIMARY KEY musi obejmować kolumny klucza partycji, więc nie każdy stary model da się przenieść bez zmian. Jeśli to nadal nie rozwiązuje problemu, trzeba spojrzeć szerzej niż na jedną tabelę.

Jakie opcje rozproszenia masz dziś do dyspozycji

Jeżeli problemem jest już nie tylko pojedyncza tabela, ale cały serwer, patrzę na trzy ścieżki. Dwie są rozszerzeniem PostgreSQL, trzecia to architektura własna aplikacji, i każda ma inny koszt utrzymania.

W praktyce Citus jest najbliżej idei „PostgreSQL, ale rozproszony”, bo daje wspólny język SQL i rozdziela pracę między węzły. `postgres_fdw` jest za to sensowne wtedy, gdy chcesz przejść przez etap pośredni, a nie od razu budować pełną warstwę shardingu. Kiedy już wiesz, którą ścieżkę wybierasz, kluczowe staje się pytanie: po czym w ogóle dzielić dane, żeby nie stworzyć hotspotów.

Dobry klucz shardingu robi większą różnicę niż sam silnik

Najczęstszy błąd polega na tym, że ktoś wybiera klucz pod wygodę modelu danych, a nie pod ruch w aplikacji. Ja patrzę najpierw na to, po czym naprawdę filtrują zapytania, bo shard key musi jednocześnie rozkładać obciążenie i prowadzić do jak najczęstszych odczytów.

• Wysoka kardynalność oznacza dużo różnych wartości, dzięki czemu dane nie lądują w kilku gorących miejscach.
• Stabilność jest ważna, bo klucz shardingu nie powinien się zmieniać po zapisie; przenoszenie rekordu między shardami jest kosztowne.
• Zgodność z filtrami i joinami ma znaczenie, bo jeśli większość zapytań zaczyna się od `tenant_id`, to zwykle jest to lepszy kandydat niż techniczny numer.
• Unikanie monotonicznych wartości pomaga, bo rosnące `id` albo sam `created_at` często tworzą gorący fragment danych na końcu zakresu.
• Plan na wyjątki jest konieczny, bo pojedynczy duży klient potrafi zdominować cały shard nawet wtedy, gdy reszta danych rozkłada się dobrze.

Przeczytaj również: Normalizacja baz danych - Porządek, który oszczędza czas

Hash, range i schematy działają inaczej

Hash daje zwykle najlepszy rozkład, bo sprowadza dane do równych koszyków. Range bywa świetny dla danych czasowych, ale łatwo robi się na nim gorący koniec tabeli, jeśli wszystkie nowe zapisy wpadają do ostatniego zakresu. Sharding po schemacie jest wygodny w mikroserwisach, gdy każda usługa albo każdy tenant ma własną przestrzeń nazw i nie potrzebuje wspólnych joinów. W praktyce często łączę te podejścia: rozkład po tenant_id albo schemacie na zewnątrz i partycjonowanie po czasie wewnątrz każdego dużego zbioru.

Kiedy klucz jest już dobrany, dużo łatwiej zobaczyć, które błędy psują efekt jeszcze przed wejściem na produkcję.

Najczęstsze błędy, które psują efekt

• Przenoszenie systemu do shardingu zanim zmierzy się realny bottleneck, czyli czy problemem jest CPU, I/O, pamięć czy po prostu zły plan zapytania.
• Wybieranie klucza, który nie występuje w większości zapytań, przez co rozproszenie danych nie pomaga w codziennym obciążeniu.
• Brak testu joinów między shardami. Gdy dane do raportu trzeba skleić z wielu węzłów, zysk z równoległości potrafi zniknąć bardzo szybko.
• Zakładanie, że backup, restore, monitoring i failover będą działać tak samo jak na pojedynczym serwerze.
• Zbyt duża liczba shardów na start. Każdy shard to dodatkowe metadane, planowanie i koszt operacyjny.
• Brak strategii rebalance, czyli przenoszenia danych, gdy jeden węzeł zaczyna się zapełniać szybciej od innych.
• Nieoglądanie planów w `EXPLAIN ANALYZE`, przez co łatwo pomylić lokalne przetwarzanie z rzeczywistym rozkładem pracy.

To są błędy, które widzę najczęściej, bo sharding potrafi przykryć problem przez chwilę, ale źle ustawiony model wraca po kilku tygodniach w postaci nierównych shardów albo wolnych złączeń. Dlatego przed migracją warto zrobić krótką, techniczną kontrolę tego, co naprawdę ma sens.

Zanim rozproszysz dane, sprawdź te pięć rzeczy

1. Czy problemem jest skalowanie zapisu, czy tylko jeden wolny typ zapytania albo brak właściwego indeksu.
2. Czy topowe zapytania filtrują po kandydacie na klucz partycji albo shard key.
3. Czy natywne partycjonowanie nie da już wystarczającej ulgi dzięki pruning i łatwiejszej archiwizacji.
4. Czy potrafisz obsłużyć cross-shard joins, transakcje i awarie węzłów bez utraty spójności biznesowej.
5. Czy masz plan na monitoring, migrację danych i późniejsze równoważenie obciążenia.

Rozproszenie danych w PostgreSQL nie jest automatycznym awansem do „większej” architektury, tylko odpowiedzią na konkretny limit: jednej instancji, jednego zestawu dysków albo jednego wzorca obciążenia. Ja zwykle idę od prostszego kroku do trudniejszego: najpierw porządkuję tabele i zapytania, potem sprawdzam, czy partycjonowanie wystarcza, a dopiero na końcu rozciągam system na wiele węzłów. Taka kolejność rzadziej kończy się kosztowną przebudową i szybciej pokazuje, gdzie leży prawdziwy problem.