Sharding to technika dzielenia jednej dużej bazy danych na mniejsze, niezależne kawałki zwane shardami, które trzymasz na osobnych serwerach. Każdy shard ma tę samą strukturę tabel, ale przechowuje tylko fragment wszystkich wierszy — na przykład część użytkowników albo część zamówień. Dzięki temu zamiast jednej maszyny, która się dusi pod ciężarem terabajtów danych i tysięcy zapytań na sekundę, masz kilka czy kilkanaście serwerów dzielących robotę między siebie.
Po co to robić
Klasyczne skalowanie pionowe (scale up) polega na dokładaniu RAM-u, CPU i szybszych dysków do jednego serwera. Problem w tym, że w końcu trafiasz na sufit — nie ma maszyny, którą dokupisz za rozsądne pieniądze, a i tak jeden węzeł ma limity I/O. Sharding to scale out: rośniesz wszerz, dorzucając kolejne serwery. To pozwala obsłużyć zbiory danych i ruch, które na pojedynczej instancji byłyby nie do udźwignięcia.
Sercem całej zabawy jest shard key — klucz, według którego dane trafiają do konkretnego sharda. Najczęściej używa się dwóch strategii: range-based (np. użytkownicy A–M na shard 1, N–Z na shard 2) oraz hash-based (liczysz hash z klucza i resztę z dzielenia decyduje o shardzie). Hash daje równiejszy rozkład, range bywa wygodniejszy przy zapytaniach zakresowych.
Przykład z praktyki
W MongoDB sharding jest wbudowany. Włączasz go na kolekcji jednym poleceniem, podając pole, które będzie shard key:
sh.shardCollection("sklep.zamowienia", { "user_id": "hashed" })
Od tego momentu router mongos kieruje zapytania do właściwego sharda, a komponent balancer sam przesuwa chunki danych między węzłami, żeby trzymać równowagę. W świecie SQL podobnie robi to np. Vitess (skalowanie MySQL, używane swego czasu przez YouTube) albo Citus dla PostgreSQL.
Na co uważać
Największa pułapka to zły wybór shard key. Jeśli wybierzesz pole, które nie rozkłada ruchu równomiernie (np. created_at, gdzie wszystkie nowe wpisy lecą na jeden shard), dostaniesz hotspota — jeden serwer haruje, reszta się nudzi. Drugi mit: że sharding to magiczny przycisk „więcej wydajności”. W rzeczywistości komplikuje życie — zapytania łączące dane z wielu shardów (cross-shard joins) są wolne, transakcje rozproszone bywają bolesne, a re-sharding po fakcie to poważna operacja. Dlatego shardingu nie wprowadza się „na wszelki wypadek”, tylko gdy naprawdę uderzasz w ścianę.
Pojęcia powiązane: partycjonowanie (sharding to w istocie partycjonowanie poziome rozproszone na wiele maszyn), replikacja (kopie tych samych danych dla dostępności — często łączona z shardingiem), skalowanie poziome i pionowe, shard key, oraz twierdzenie CAP, które tłumaczy kompromisy w systemach rozproszonych.