Rozdzielanie dużych zbiorów danych osiąga się na dwa główne sposoby:
Partyjonowanie (partitioning): Logiczne podzielenie jednej tabeli w ramach jednej bazy danych na segmenty (partition) według określonego klucza, zwykle daty lub zakresu wartości. Umożliwia to szybkie wykonywanie operacji na poszczególnych sekcjach, przyspiesza wyszukiwanie i ułatwia konserwację.
Sharding (sharding): Fizyczne rozdzielenie danych na kilka baz danych/serwerów według określonego algorytmu — tabela faktycznie duplikowana jest w różnych klastrach, z których każdy zawiera swój segment danych.
Zalety partyjonowania — brak konieczności wspierania odrębnej logiki biznesowej do kierowania zapytaniami, wszystko odbywa się "przezroczysto" dla aplikacji; wady — ograniczone możliwości jednej SGBD.
Sharding zapewnia poziome skalowanie (limit zależy tylko od liczby serwerów), ale wymaga złożonej synchronizacji, kierowania i obsługi zapytań "między-shardowych".
-- Podstawowa tabela partycjonowana CREATE TABLE orders ( id SERIAL PRIMARY KEY, customer_id INT, order_date DATE ) PARTITION BY RANGE (order_date); CREATE TABLE orders_2023 PARTITION OF orders FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
Pytanie: Czy można "w locie" przenosić wiersze między partycjami bez blokowania głównej tabeli?
Odpowiedź: W większości SGBD przenoszenie wiersza między partycjami jest równoważne usunięciu i wstawieniu — takie operacje mogą blokować wiersze, a nawet samą tabelę, szczególnie jeśli w procesie zaangażowane są wyzwalacze lub klucze obce. Należy to uwzględnić przy masowych "przekrętach" danych między sekcjami.
-- ALTER TABLE ... MOVE PARTITION, z reguły wymaga szczególnej uwagi na blokady. Lepiej robić to w czasie niskiego obciążenia.
Historia 1: W projekcie tworzono analizy raportów dla wszystkich partycji jednocześnie, nie uwzględniając, że partycjonowana tabela z tysiącami sekcji tworzyła gigantyczne plany wykonania zapytań. W rezultacie — gwałtowny wzrost czasu wykonania i obciążenia serwera. Rozwiązanie: zwiększenie liczby partycji odpowiadających rzeczywistym osiom biznesowym zapytania i optymalizacja planów skanowania.
Historia 2: Przy dodawaniu sharding nie uwzględniono unikalności identyfikatora między shardami. Często występowały konflikty kluczy podczas agregacji między shardingami.
Historia 3: Automatyczna archiwizacja "przestarzałych" partycji usuwała je bez ponownej weryfikacji zewnętrznych zależności, co prowadziło do utraty powiązań z innymi tabelami i utraty części "żywych" danych. Po tym cała logika usuwania partycji została przepisana z testami wieloma na spójność.