Database Sharding

Hash-based Sharding

shard = hash(key) % N. Równomierny rozkład, brak hot spots. Range queries wymagają scatter-gather.

Kiedy: Gdy chcesz równomierny write rozkład, brak range query potrzeb

Range-based Sharding

Dane wg zakresu klucza. Range queries efektywne. Hot spots możliwe dla monotonicznie rosnących kluczy.

Kiedy: Time-series, range queries krytyczne

Consistent Hashing

Okrąg hashów. Dodanie/usunięcie sharda przenosi minimalnie danych. Cassandra, DynamoDB, Redis Cluster.

Kiedy: Dynamiczne dodawanie/usuwanie shardów, cloud-native

Directory-based

Lookup table wskazuje na shard. Maksymalna elastyczność, możliwość przenoszenia rekordów. Lookup table = SPOF.

Kiedy: Multi-tenant SaaS, gdy chcesz przenosić tenant między shardami

Geographic Sharding

Dane podzielone per region (EU, US, APAC). Compliance (GDPR), niższe latency lokalnie.

Kiedy: Regulacje data residency, globalne aplikacje

Co-location (Customer Sharding)

Wszystkie dane jednego klienta (tenant) na jednym shard. Eliminuje cross-shard queries w kontekście jednego tenanta.

Kiedy: Multi-tenant B2B SaaS

Co to jest Database Sharding i kiedy jest potrzebne?

Database Sharding to technika poziomego partycjonowania danych — podział jednej dużej bazy danych na wiele mniejszych, zwanych shardami (odłamkami). Każdy shard zawiera podzbiór danych i może być na osobnym serwerze. Sharding vs. Replication: Replication — te same dane na wielu serwerach. Cel: read scalability, availability. Sharding — różne dane na różnych serwerach. Cel: write scalability, pojemność. Kiedy potrzebujesz shardingu: tabela przekracza możliwości jednego serwera (100M+ rekordów, TB danych). Write throughput jest bottleneckiem (jeden master nie nadąża). Read repliki nie wystarczają — dane nie mieszczą się w RAM jednej maszyny. Alternatywy przed shardingiem (wypróbuj najpierw): Vertical scaling — silniejszy serwer (CPU, RAM, szybsze dyski). Read replicas — odciąż reads na repliki. Caching — Redis/Memcached dla hot data. Partycjonowanie — table partitioning (w jednej bazie, np. partycja per miesiąc). Archiwizacja — przenieś stare dane do cold storage. Sharding jest skomplikowany — dodaje złożoność operacyjną. Użyj go dopiero gdy alternatywy są niewystarczające. Przykłady firm które shardują: Discord (Cassandra sharding), Uber (PostgreSQL → Schemaless sharding), GitHub (MySQL sharding), Instagram (PostgreSQL + sharding).

Strategie shardingu — jak podzielić dane między shardy?

Range-based Sharding: dane podzielone według zakresu wartości klucza. Shard A: ID 1-1,000,000, Shard B: ID 1,000,001-2,000,000. Zalety: proste zapytania range queries trafią do jednego shardu. Wady: hot spots — jeśli nowi użytkownicy mają wyższe ID, Shard B jest przeciążony. Hash-based Sharding: shard = hash(klucz) % liczba_shardów. Dane rozłożone losowo — brak hot spotów. Wada: range queries wymagają zapytania do wszystkich shardów. Consistent Hashing: zamiast % N używa okrąg hashów. Dodanie/usunięcie shardu przenosi minimalną ilość danych (tylko sąsiednie na okrągu). Używane przez Cassandra, DynamoDB, Redis Cluster. Directory-based Sharding: lookup table która mówi gdzie jest rekord. Bardzo elastyczne — możesz przenosić rekordy między shardami bez zmiany klucza. Wada: lookup table to single point of failure + hotspot. Geographic/Customer-based Sharding: dane podzielone per region (EU, US, APAC) — zgodność z GDPR. Lub per tenant w multi-tenant SaaS. Composite Sharding: kombinacja strategii. Np. najpierw per region, potem hash w regionie. Wybór klucza shardowania (shard key): kluczowa decyzja — trudno zmienić później. Powinien zapewnić równomierny rozkład. Unikaj kluczy które tworzą hot spots (timestamp dla inserts, sequential ID). Card high enough — wystarczająca liczba unikalnych wartości.

Cross-shard queries i transakcje — jak radzić sobie z rozproszeniem?

Cross-shard queries: zapytania wymagające danych z wielu shardów są najpoważniejszym problemem shardingu. Scatter-Gather: wyślij zapytanie do wszystkich shardów → zbierz wyniki → merge. Wolne, ale sometimes konieczne. Problemy: ORDER BY + LIMIT — każdy shard zwraca top N, trzeba re-sort wszystkich wyników. COUNT, SUM, AVG — partial aggregations z każdego shardu, połącz. JOIN między shardami — prawie niemożliwy efektywnie (denormalizacja + application-level join). Strategie unikania cross-shard: Denormalizacja — trzymaj powiązane dane razem (np. user + user_orders na jednym shard per user_id). Co-location — klucz shardowania wybrany tak żeby powiązane dane trafiły do jednego shardu. Duplicate data — kopiuj dane które często są potrzebne cross-shard (np. user profile na wszystkich shardach). Materialized views / pre-aggregations — pre-compute cross-shard aggregates offline. Distributed transactions: ACID przez wiele shardów jest trudne. 2PC (Two-Phase Commit): koordynator pyta wszystkie shardy czy mogą commit, potem commit lub rollback. Problem: wolne, coordinator failure. Saga pattern: seria lokalnych transakcji z compensating transactions jeśli coś się nie powiedzie. Lepsze dla mikroserwisów z event-driven. Eventual consistency: akceptuj że dane mogą być chwilowo niespójne między shardami. BASE (Basically Available, Soft state, Eventually consistent) zamiast ACID.

Vitess i inne narzędzia do shardingu — jak automatyzować zarządzanie?

Vitess: system zarządzania MySQL/MariaDB sharding — używany przez YouTube, Slack, HubSpot. Abstrakcja shardingu od aplikacji — aplikacja widzi jeden MySQL. VTGate — proxy który routuje zapytania do odpowiednich shardów. VTTablet — agent na każdym MySQL. Automatyczny resharding — reorganizacja danych bez downtime. Query routing, connection pooling, online schema migrations. Kubernetes-native (Vitess Operator). CockroachDB: distributed SQL — sharding automatyczny i transparentny dla aplikacji. ACID transactions globally. Geo-distribution natively. PostgreSQL API compatible. Spanner-like architektura (clock synchronization). YugabyteDB: distributed PostgreSQL — auto-sharding, high availability, ACID. Citus (PostgreSQL Extension): horizontal sharding dla PostgreSQL. Shard tables jako distributed tables lub reference tables. Coordinator node routuje do worker nodes. Używany przez Azure Cosmos DB for PostgreSQL. PlanetScale (MySQL): managed MySQL sharding oparte na Vitess. Database branching (jak Git dla bazy). Non-blocking schema changes. Neon: serverless PostgreSQL — auto-scaling storage, nie klasyczny sharding ale skalowanie pionowe z compute/storage separation. Amazon Aurora: shared storage, read replicas — nie sharding ale skaluje do 128TB. Resharding: najtrudniejsza operacja — przenoszenie danych między shardami. Online resharding (bez downtime): Vitess, CockroachDB robią to automatycznie. Ręczne: double-write pattern → copy → cutover.

Sharding w NoSQL — MongoDB, Cassandra, DynamoDB?

MongoDB Sharding: wbudowane sharding — mongos (router), config servers, shard servers. Shard key wybrany przy tworzeniu collection. Chunk-based: dane podzielone na chunks (domyślnie 128MB). Balancer automatycznie przenosi chunks między shardami. Compound shard key (np. user_id + timestamp). Hashed shard key — automatyczne równe rozłożenie. Wyzwania MongoDB: targeted queries (z shard key) vs. scatter-gather (bez). Jumbo chunks — jeśli shard key ma niską kardynalność. Cassandra: sharding natywny przez consistent hashing (Vnode). Każdy node odpowiada za zakres tokenów na okręgu. Replication factor — każda partycja na N node'ach. Partition key = klucz shardowania w Cassandra. Clustering key — sortowanie wewnątrz partycji. Wyzwania: wide partition problem — jedna partycja za duża jeśli zły partition key. Allow filtering (non-partition queries) — Cassandra Gather. DynamoDB: auto-sharding niewidoczne dla użytkownika. Partition key = shard key. Hot partition — jeden klucz zbyt często używany. Write sharding workaround: dodaj suffix (1-N) do partition key. DAX (DynamoDB Accelerator) — cache dla hot reads. Redis Cluster: sharding przez hash slots (16384). Każdy master node odpowiada za zakres hash slots. Automatyczny failover (replica promotion). MOVED/ASK redirects gdy klient trafia do złego node.

Wyślij zapytanie