SQL Academy · Lekcja

Strategie shardingu: zakres, hash, katalog

Porównywać sharding zakresowy, haszujący i oparty na katalogu oraz wybierać klucz shardu, który równoważy obciążenie i pozostaje stabilny

Strategie shardingu: zakres, hash, katalog to bezpłatna lekcja SQL Academy na CoddyKit. To lekcja 1 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.

Czym jest sharding

Podział jednej logicznej bazy danych między wiele serwerów fizycznych („shardów”), z których każdy przechowuje podzbiór danych. Stosuje się go, gdy jeden serwer nie jest już w stanie obsłużyć obciążenia.

Sharding ≠ replikacja

Replikacja — te same dane na wielu serwerach (na potrzeby HA i skalowania odczytów)
Sharding — różne dane na różnych serwerach (na potrzeby skalowania zapisów i zwiększania pojemności)

Często łączy się oba podejścia: każdy shard jest replikowany na potrzeby HA.

Trzy strategie shardingu

Zakresowa — podział według zakresu wartości (id 1-1M na shardzie A, 1M-2M na shardzie B)
Haszująca — haszowanie klucza shardu, modulo N
Katalogowa — osobna tabela mapuje klucz na shard

Sharding zakresowy

Prosty i dobrze sprawdza się w przypadku szeregów czasowych oraz uporządkowanych identyfikatorów. Ryzyko: gorące shardy, jeśli cały ruch trafia do najnowszych danych.

-- Conceptually:
-- Shard A: user_id 1 - 1,000,000
-- Shard B: user_id 1,000,001 - 2,000,000
-- Shard C: user_id 2,000,001 - 3,000,000

Sharding haszujący

Domyślnie zapewnia równomierny rozkład. Dodawanie shardów jest trudne, ponieważ ponowne shardowanie przenosi wszystkie klucze:

-- shard_id = hash(user_id) % N
-- N=4: any user_id evenly distributed across 4 shards

Sharding katalogowy

Tabela wyszukiwania mapuje każdy klucz na jego shard:

CREATE TABLE shard_routing (
  user_id BIGINT PRIMARY KEY,
  shard_id INT NOT NULL
);

-- Looking up a user costs a directory query first; cache it.

Spójne haszowanie

Haszowanie modulo jest kruche przy dodawaniu shardów. Spójne haszowanie minimalizuje liczbę kluczy, które trzeba przenieść:

-- Each shard owns a ring segment.
-- Adding a new shard moves only ~1/N of the keys.

Wybór klucza shardu

Klucz shardu determinuje wszystko. Dobre klucze shardu:

Rozkładają dane równomiernie
Występują w większości zapytań (unikają rozsyłania zapytań między shardami)
Są niezmienne (lub zmieniają się rzadko)

<p>Common picks: user_id, tenant_id, customer_id. Avoid: timestamps for write-heavy workloads (creates hot shards).</p>

Jeden tenant na shard

Wielodostępne SaaS: każdy tenant znajduje się na osobnym shardzie. Takie rozwiązanie jest łatwe do zrozumienia i ułatwia izolowanie głośnych tenantów.

Projekt z możliwością ponownego shardingu

Projektując system, należy uwzględnić przyszłe ponowne shardowanie:

Należy używać wirtualnych shardów (np. 1024 logicznych mapowanych na fizyczne)
Należy ułatwić migrację logicznego shardu na inny serwer fizyczny
Należy unikać kodu aplikacji, w którym liczba shardów jest zapisana na stałe

Zapytania między shardami

To najtrudniejszy problem. JOIN-y i raporty obejmujące wiele shardów wymagają rozesłania zapytań oraz agregowania wyników w aplikacji. Temat zostanie omówiony w następnej lekcji.

Transakcje między shardami

Atomowe transakcje między shardami wymagają dwufazowego zatwierdzania (2PC) lub sag. Typowa rada: projektować system tak, aby transakcje pozostawały w obrębie jednego shardu.

Podsumowanie

Istnieją trzy strategie — należy wybrać ją na podstawie charakterystyki ruchu.

Zakresowa — prosta, ale wiąże się z ryzykiem gorących shardów
Haszująca — równomierna, ale sztywna
Katalogowa — elastyczna, ale zwiększa opóźnienie
Spójne haszowanie umożliwia łagodne ponowne shardowanie

Szybkie sprawdzenie

Tabela users jest shardowana na podstawie hash(user_id). Liczba shardów wzrasta z 4 do 5. Ile kluczy trzeba przenieść?

Często zadawane pytania

Czy lekcja „Strategie shardingu: zakres, hash, katalog” jest bezpłatna?

Tak — pełny tekst „Strategie shardingu: zakres, hash, katalog” 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 „Strategie shardingu: zakres, hash, katalog”?

Porównywać sharding zakresowy, haszujący i oparty na katalogu oraz wybierać klucz shardu, który równoważy obciążenie i pozostaje stabilny Ć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 1 z 4.

Ile czasu zajmuje lekcja „Strategie shardingu: zakres, hash, katalog”?

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