Kiedy NIE stosować shardingu
Rozumieć, że repliki tylko do odczytu, partycjonowanie i większe serwery rozwiązują większość problemów ze skalowaniem — oraz wiedzieć, kiedy sharding jest niewłaściwym rozwiązaniem
Kiedy NIE stosować shardingu to bezpłatna lekcja SQL Academy na CoddyKit. To lekcja 4 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.
Sharding to ostateczność
Sharding zwielokrotnia złożoność operacyjną. Większość aplikacji nigdy go nie potrzebuje. Najpierw należy wyczerpać prostsze możliwości.
Krok 1: skalowanie pionowe
Większy serwer. Nowoczesne instancje chmurowe bez problemu obsługują:
- 128 rdzeni
- 1 TB pamięci RAM
- 50 000 IOPS na NVMe
Oznacza to 100k-500k QPS na pojedynczym węźle Postgresa. Większość aplikacji bez problemu mieści się w tych granicach.
Krok 2: repliki odczytu
Jeśli dominują odczyty, należy dodać repliki. Jeden primary i 3 repliki mogą obsłużyć 10× więcej odczytów.
Krok 3: buforowanie
Redis lub memcached przed często wykonywanymi zapytaniami. Często jest to najtańszy sposób na uzyskanie poprawy.
Krok 4: partycjonowanie
Natywne deklaratywne partycjonowanie PG rozwiązuje problem „zbyt dużej tabeli” w obrębie jednego serwera. Często jest 100 razy łatwiejsze niż sharding.
Krok 5: rozdzielenie usług
Należy przenieść różne domeny do różnych baz danych — baza zamówień, baza użytkowników, baza analityczna. Każdą z nich można skalować niezależnie.
Krok 6: przeniesienie analityki
Zapytania OLTP → Postgres. Zapytania analityczne → ClickHouse / BigQuery / Snowflake. Wiele historii typu „musimy użyć shardingu” w rzeczywistości oznacza „analityka zjada nasze OLTP”.
Dopiero potem — być może — sharding
Jeśli nadal brakuje zasobów przy 50 TB danych wyłącznie OLTP, a obciążenie wymaga większej liczby zapisów, niż może obsłużyć jeden serwer, należy rozpocząć planowanie shardów.
Koszt operacyjny shardingu
- Więcej serwerów do monitorowania i aktualizowania
- Kopie zapasowe na wielu shardach wymagają koordynacji
- Zapytania między shardami trafiają do kodu aplikacji
- Ponowne shardowanie jest trudne
- Gorące shardy wymagają aktywnego równoważenia
Strategia „późnego shardingu”
Należy tworzyć system z uwzględnieniem wzorców przyjaznych shardingowi (zawsze uwzględniać tenant_id, nigdy nie używać liczników zwiększanych globalnie), aby można było zastosować sharding później. Nie należy jednak shardować, dopóki nie będzie to konieczne.
Schemat przyjazny shardingowi
Nawet jeśli system pozostanie na pojedynczym węźle, należy projektować go tak, jakby w przyszłości miał zostać poddany shardingowi:
- Tenant_id w każdym wierszu
- UUID lub rozproszone identyfikatory (nie auto-increment)
- Brak globalnie unikatowych sekwencji
- Klucze obce w zakresie jednego tenanta
Uznanie kompromisu
Sharding zwiększa pojemność kosztem możliwości. JOIN-y, transakcje i zapytania stają się trudniejsze. Należy upewnić się, że korzyść jest tego warta.
Podsumowanie
Sharding rozwiązuje rzeczywisty problem, ale jest rozwiązaniem kosztownym.
- Najpierw skalowanie pionowe
- Repliki odczytu i buforowanie
- Partycjonowanie przed shardingiem
- Przeniesienie analityki poza OLTP
- Projektowanie z myślą o możliwości shardingu i odłożenie jego wdrożenia
Szybkie sprawdzenie
Rozważają Państwo sharding, ponieważ zapytania OLTP są powolne. Jaki krok przed zastosowaniem shardingu najprawdopodobniej pomoże?
Często zadawane pytania
Czy lekcja „Kiedy NIE stosować shardingu” jest bezpłatna?
Tak — pełny tekst „Kiedy NIE stosować shardingu” 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 „Kiedy NIE stosować shardingu”?
Rozumieć, że repliki tylko do odczytu, partycjonowanie i większe serwery rozwiązują większość problemów ze skalowaniem — oraz wiedzieć, kiedy sharding jest niewłaściwym rozwiązaniem Ć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 4 z 4.
Ile czasu zajmuje lekcja „Kiedy NIE stosować shardingu”?
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