SQL Academy · Lekcja

Zapytania między shardami: trudny problem

Rozumieć, dlaczego złączenia i transakcje między shardami są najtrudniejszym problemem w rozproszonych bazach danych, oraz poznawać wzorce ograniczające ich użycie

Zapytania między shardami: trudny problem to bezpłatna lekcja SQL Academy na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej SQL Academy, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs SQL Academy zawiera 4 lekcji w sumie.

Koszt shardingu

Sharding skaluje zapisy i pojemność, ale utrudnia zapytania obejmujące wiele shardów: każde zapytanie między shardami wymaga rozesłania zapytań.

Zapytania do jednego shardu są proste

Jeśli klucz shardu znajduje się w klauzuli WHERE, router wysyła jedno zapytanie do jednego shardu:

-- shard_id = hash(user_id) % N
SELECT * FROM orders WHERE user_id = 42;
-- Router computes shard, sends one query, gets one result.

Zapytania z rozsyłaniem

Bez klucza shardu router wysyła zapytanie do każdego shardu, a następnie scala wyniki:

-- WHERE status = 'paid' — no user_id
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 100;
-- Must query all N shards, merge results, sort, take top 100.

Agregacje z rozsyłaniem

W przypadku COUNT/SUM/AVG należy pobrać częściowe wyniki z każdego shardu, a następnie połączyć je w routerze lub aplikacji:

-- On each shard:
SELECT COUNT(*), SUM(total) FROM orders;

-- Aggregator:
final_count = SUM(counts), final_sum = SUM(sums)

-- AVG is trickier — need SUM and COUNT, can't average averages.

JOIN-y między shardami

Jeśli obie strony są shardowane według tego samego klucza (współlokowane), JOIN jest lokalny dla shardu. W przeciwnym razie przy dużej skali jest praktycznie niemożliwy.

Tabele referencyjne (replikowane wszędzie)

Małe tabele „wyszukiwania” są replikowane na każdy shard, dzięki czemu JOIN-y z nimi pozostają lokalne. Citus nazywa je „tabelami referencyjnymi”.

Unikanie wzorców między shardami

Sposoby projektowania schematu:

Denormalizacja — duplikowanie danych nadrzędnych na shardzie zawierającym dane podrzędne
Używanie klucza shardu wszędzie — nawet gdy jest „niepotrzebny”
Wstępne obliczanie raportów w osobnej bazie analitycznej

Stronicowanie między shardami

OFFSET 1000 LIMIT 10 dla wielu shardów działa fatalnie — każdy shard musi zwrócić 1010 wierszy. Zamiast tego należy używać stronicowania keyset.

Transakcje rozproszone

Dwufazowe zatwierdzanie (2PC) koordynuje atomowe zatwierdzanie między shardami. Jest powolne i podatne na awarie podczas partycjonowania sieci. W praktyce należy projektować system z myślą o wzorcach „saga”:

// Saga pattern (conceptual):
//   1. Local TX on shard A: mark as pending, log
//   2. RPC to shard B: do its part
//   3. Local TX on shard A: mark as committed
//   4. On failure: compensating transactions

Gorące shardy

Popularny użytkownik lub produkt, który stał się wiralowy — skoncentrowany ruch na jednym shardzie niweczy korzyści ze skalowania. Należy wykryć taki shard i podzielić go (sub-sharding) albo przenieść.

Klucze obce między shardami

Klucze obce RDBMS nie obejmują wielu shardów. Integralność referencyjną należy wymuszać w aplikacji albo zaakceptować spójność ostateczną dla relacji między shardami.

Podsumowanie

Sharding przenosi trudność z „skalowania zapisów” na „kształtowanie zapytań tak, aby pozostały lokalne dla shardu”.

Zapytania do jednego shardu są szybkie
Rozsyłanie zapytań jest powolne
Denormalizacja pozwala zachować lokalność operacji
Tabele referencyjne służą do współdzielonych wymiarów
Sagi zamiast 2PC

Szybkie sprawdzenie

Dlaczego zapytanie SELECT bez klucza shardu w klauzuli WHERE jest kosztowne w shardowanej bazie danych?

Często zadawane pytania

Czy lekcja „Zapytania między shardami: trudny problem” jest bezpłatna?

Tak — pełny tekst „Zapytania między shardami: trudny problem” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu SQL Academy, przejdź na CoddyKit PRO. Kurs SQL Academy zawiera 4 lekcji w sumie.

Co nauczysz się w „Zapytania między shardami: trudny problem”?

Rozumieć, dlaczego złączenia i transakcje między shardami są najtrudniejszym problemem w rozproszonych bazach danych, oraz poznawać wzorce ograniczające ich użycie Ćwiczysz SQL Academy z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć SQL Academy?

Nie wymagamy żadnego doświadczenia. SQL Academy w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Zapytania między shardami: trudny problem”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji SQL Academy?

Tak. Każda lekcja SQL Academy zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Strategie shardingu: zakres, hash, katalog
Zapytania między shardami: trudny problem
Citus i rozproszony Postgres
Kiedy NIE stosować shardingu

← Powrót do SQL Academy