Kiedy pojedyncza baza danych przestaje wystarczać, a RAC osiąga swoje granice, Oracle Sharding oferuje architekturę zdolną obsłużyć setki terabajtów danych rozproszonych globalnie.
- Sharding to architektura shared-nothing, fundamentalnie różna od Oracle RAC i klasycznego partycjonowania
- Wybór klucza shardującego to decyzja krytyczna, której nie da się łatwo zmienić po wdrożeniu
- Izolacja awarii sprawia, że problem jednego shardu nie wpływa na dostępność pozostałych 99% systemu
- Oracle Sharding wymaga przemyślanego podejścia do zapytań cross-shard i transakcji rozproszonych
Ewolucja skalowania baz danych Oracle
Przez ostatnie dwie dekady obserwowałem, jak zmieniały się podejścia do skalowania baz danych Oracle. Zaczynaliśmy od prostego scale-up, czyli dokładania procesorów, pamięci RAM i szybszych dysków. Potem przyszła era Oracle RAC, która pozwoliła rozłożyć obciążenie na wiele węzłów współdzielących ten sam storage. Dla większości organizacji te rozwiązania nadal są wystarczające.
Problem pojawia się jednak w momencie, gdy pojedyncza baza danych musi obsługiwać setki milionów użytkowników rozproszonych po całym świecie, przetwarzać miliony transakcji na sekundę i przechowywać setki terabajtów danych z wymaganiami niskich opóźnień. W takich scenariuszach nawet najbardziej rozbudowany klaster RAC osiąga swoje granice, głównie ze względu na współdzielony storage oraz koordynację między węzłami.
Oracle Database Sharding, wprowadzony w wersji 12.2, to odpowiedź na te wyzwania. Jest to natywna implementacja architektury shared-nothing bezpośrednio w silniku bazodanowym, pozwalająca na horyzontalną skalowalność praktycznie bez górnych limitów.
Fundamentalne różnice między shardingiem a innymi technologiami
Zanim zagłębimy się w szczegóły techniczne, muszę wyjaśnić fundamentalne różnice między shardingiem a rozwiązaniami, z którymi jest często mylony. To kluczowe dla zrozumienia, kiedy każda z technologii ma zastosowanie.
Partycjonowanie tabel
Partycjonowanie dzieli pojedynczą tabelę na mniejsze segmenty w ramach tej samej bazy danych i tego samego serwera. Wszystkie partycje współdzielą tę samą instancję Oracle, ten sam redo log, te same zasoby systemowe. Partycjonowanie poprawia wydajność zapytań i ułatwia zarządzanie dużymi tabelami, ale nie rozwiązuje problemu skalowalności całego systemu.
Oracle RAC
Real Application Clusters pozwala wielu instancjom Oracle działać na tym samym zestawie plików bazodanowych przechowywanych na współdzielonym storage. RAC zapewnia wysoką dostępność i pewien poziom skalowalności, ale wszystkie węzły muszą koordynować dostęp do tych samych bloków danych poprzez mechanizm Cache Fusion. Przy bardzo dużym obciążeniu ta koordynacja staje się wąskim gardłem.
Oracle Sharding
Sharding to zupełnie inna filozofia. Każdy shard to niezależna baza danych Oracle z własnym storage, własnym redo logiem, własnymi zasobami. Dane są fizycznie podzielone między shardy na podstawie klucza shardującego. Shardy nie współdzielą niczego poza metadanymi konfiguracyjnymi. To architektura shared-nothing w najczystszej postaci.
Po latach pracy z różnymi architekturami mogę powiedzieć jedno: wybór między RAC a shardingiem nie jest kwestią tego, co jest lepsze, ale tego, jaki problem próbujesz rozwiązać. RAC skaluje pojedynczą bazę danych horyzontalnie. Sharding skaluje system składający się z wielu niezależnych baz danych. To fundamentalna różnica w podejściu architektonicznym.
Architektura środowiska shardowanego
Środowisko Oracle Sharding składa się z kilku kluczowych komponentów, które współpracują ze sobą, tworząc spójny system rozproszony. Zrozumienie roli każdego z nich jest niezbędne do prawidłowego projektowania i administracji.
Shard Catalog
Shard Catalog to serce całego środowiska shardowanego. Jest to specjalna baza danych Oracle przechowująca wszystkie metadane konfiguracyjne: definicje shardów, mapowania kluczy do shardów, definicje tabel shardowanych oraz informacje o usługach globalnych. Catalog nie przechowuje danych aplikacyjnych, ale bez niego środowisko nie może funkcjonować.
W praktyce Shard Catalog powinien być zawsze chroniony przez Data Guard w konfiguracji co najmniej z jedną repliką standby. Utrata Catalogu nie oznacza utraty danych (te są na shardach), ale uniemożliwia zarządzanie środowiskiem i kierowanie połączeń. Sam Catalog może być również chroniony przez RAC dla dodatkowej dostępności.
Administracja środowiskiem odbywa się poprzez pakiet DBMS_GSM uruchamiany na Catalogu. To tutaj definiujemy nowe shardy, modyfikujemy konfigurację, inicjujemy operacje reshardingu. Catalog utrzymuje również globalny słownik danych zawierający definicje tabel shardowanych, które są automatycznie propagowane do wszystkich shardów.
Shard Director (GSM)
Global Service Manager, czyli Shard Director, to komponent odpowiedzialny za kierowanie połączeń klientów do właściwych shardów. Jest to warstwa pośrednia między aplikacją a shardami, która na podstawie klucza shardującego określa, gdzie znajdują się żądane dane.
W typowym wdrożeniu produkcyjnym uruchamiamy co najmniej dwa GSM-y dla redundancji. Klienci łączą się z GSM, przekazując klucz shardujący (na przykład customer_id), a GSM kieruje połączenie bezpośrednio do właściwego shardu. Co istotne, po ustanowieniu połączenia ruch bazodanowy płynie już bezpośrednio między klientem a shardem, bez przechodzenia przez GSM.
GSM utrzymuje w pamięci mapę routingu, którą pobiera z Catalogu i odświeża okresowo oraz przy każdej zmianie topologii. Obsługuje również automatyczne przełączanie połączeń w przypadku awarii shardu (jeśli shard ma skonfigurowaną replikę standby).
Shardy
Każdy shard to pełnoprawna baza danych Oracle. Może być pojedynczą instancją, może być chroniony przez Data Guard, może nawet działać jako klaster RAC. Ta elastyczność pozwala dostosować poziom ochrony i wydajności do wymagań konkretnego wdrożenia.
Shardy przechowują dane aplikacyjne podzielone według klucza shardującego. Każdy shard odpowiada za określony zakres wartości klucza (w przypadku shardingu systemowego lub composite) lub za określone wartości (w przypadku shardingu user-defined). Shardy nie komunikują się ze sobą bezpośrednio podczas normalnej pracy.
Strategie podziału danych
Oracle Sharding oferuje trzy strategie podziału danych między shardy. Wybór właściwej strategii ma fundamentalny wpływ na wydajność, skalowalność i operacyjność całego systemu.
System-managed sharding
W tej strategii Oracle automatycznie zarządza podziałem danych przy użyciu consistent hashing. Klucz shardujący jest przepuszczany przez funkcję haszującą, która określa, do którego shardu trafią dane. Ta strategia zapewnia równomierne rozłożenie danych bez interwencji administratora.
Zaletą shardingu systemowego jest prostota i automatyczne równoważenie. Wadą jest brak kontroli nad fizycznym umiejscowieniem danych, co może być problemem w scenariuszach wymagających data locality ze względów regulacyjnych lub wydajnościowych.
Composite sharding
Composite sharding łączy dwa poziomy podziału: najpierw dane są dzielone na shardspace'y (grupy shardów) na podstawie jednego klucza (najczęściej geograficznego), a następnie wewnątrz shardspace'u rozdzielane między shardy przy użyciu consistent hashing.
Ta strategia jest idealna dla globalnych wdrożeń, gdzie dane europejskich klientów muszą fizycznie pozostać w Europie, a dane amerykańskich w USA. Pierwszy poziom podziału zapewnia zgodność regulacyjną, drugi zapewnia skalowalność wewnątrz regionu.
User-defined sharding
W tej strategii administrator jawnie definiuje, które wartości klucza trafiają do których shardów. Daje to pełną kontrolę nad rozmieszczeniem danych, ale wymaga ręcznego zarządzania równowagą obciążenia.
User-defined sharding sprawdza się w scenariuszach, gdzie podział danych wynika z logiki biznesowej, na przykład gdy różni klienci korporacyjni mają dedykowane shardy ze względów bezpieczeństwa lub SLA.
Klucz shardujący jako decyzja architektoniczna
Wybór klucza shardującego to jedna z najważniejszych decyzji przy projektowaniu środowiska shardowanego. Błędny wybór może skutkować nierównomiernym rozłożeniem danych (hot spots), nieefektywnymi zapytaniami cross-shard lub koniecznością kosztownego reshardingu.
Idealny klucz shardujący powinien spełniać kilka kryteriów. Po pierwsze, musi zapewniać równomierne rozłożenie danych między shardy. Po drugie, powinien być obecny w większości zapytań aplikacji, co pozwoli kierować je do pojedynczego shardu. Po trzecie, powinien być stabilny i niezmienny dla istniejących rekordów.
W praktyce najczęściej stosowanymi kluczami są identyfikatory klientów (customer_id), identyfikatory tenantów w aplikacjach multi-tenant lub identyfikatory regionów geograficznych. Kolumny takie jak data utworzenia są zazwyczaj złym wyborem, ponieważ powodują nierównomierne obciążenie w czasie.
Zmiana klucza shardującego po wdrożeniu produkcyjnym to operacja porównywalna z wymianą silnika w lecącym samolocie. Teoretycznie możliwa, praktycznie ekstremalnie ryzykowna i kosztowna. Dlatego poświęcenie kilku tygodni na analizę wzorców dostępu przed wyborem klucza to najlepsza inwestycja, jaką można zrobić.
Tabele shardowane i replikowane
W środowisku shardowanym Oracle rozróżnia dwa typy tabel: shardowane i replikowane. Zrozumienie różnic między nimi jest kluczowe dla prawidłowego modelowania danych.
Tabele shardowane to tabele, których dane są fizycznie podzielone między shardy na podstawie klucza shardującego. Każdy wiersz znajduje się dokładnie na jednym shardzie. Tabele transakcyjne, takie jak zamówienia, płatności czy historia operacji, są zazwyczaj shardowane.
Tabele replikowane to tabele, których pełna kopia znajduje się na każdym shardzie. Są to zazwyczaj tabele słownikowe, referencyjne lub konfiguracyjne, które są często łączone z tabelami shardowanymi, ale rzadko modyfikowane. Przykłady to tabele krajów, walut, kategorii produktów.
Replikacja tabel słownikowych pozwala na wykonywanie joinów lokalnie na każdym shardzie, bez konieczności zapytań cross-shard. Oracle automatycznie synchronizuje zmiany w tabelach replikowanych z Catalogu do wszystkich shardów.
Izolacja awarii jako przewaga architektoniczna
Jedną z najważniejszych zalet architektury shardowanej jest izolacja awarii. W tradycyjnym środowisku RAC problem z jednym węzłem może potencjalnie wpłynąć na cały klaster. W środowisku shardowanym awaria jednego shardu wpływa tylko na dane znajdujące się na tym shardzie.
Jeśli mamy 100 shardów i jeden z nich ulega awarii, 99% systemu nadal działa normalnie. Użytkownicy, których dane znajdują się na pozostałych 99 shardach, nie odczuwają żadnego wpływu. To fundamentalna zmiana w porównaniu z architekturami współdzielonymi.
Oczywiście użytkownicy dotkniętego shardu doświadczą niedostępności, dlatego każdy shard powinien być chroniony przez Data Guard z automatycznym failover. W takiej konfiguracji awaria primary shardu skutkuje przełączeniem na standby w ciągu sekund, minimalizując okno niedostępności.
Wysoka dostępność i disaster recovery
Oracle Sharding integruje się z wszystkimi technologiami wysokiej dostępności Oracle. Każdy shard może być chroniony przez Data Guard z replikami synchronicznymi lub asynchronicznymi. Shardy mogą również działać jako klastry RAC dla dodatkowej dostępności na poziomie węzła.
W globalnych wdrożeniach typowa architektura obejmuje replikę synchroniczną w tym samym regionie (dla ochrony przed awarią serwera) oraz replikę asynchroniczną w odległym regionie (dla ochrony przed katastrofą całego data center). Global Data Services automatycznie przekierowuje ruch do repliki w przypadku awarii primary.
Scenariusz disaster recovery w środowisku shardowanym wymaga przemyślanego podejścia. Możemy przełączyć pojedyncze shardy niezależnie lub wykonać failover całego środowiska. Decyzja zależy od charakteru awarii i wymagań biznesowych.
Monitorowanie środowiska shardowanego
Administracja środowiskiem shardowanym wymaga narzędzi pozwalających na obserwację zarówno pojedynczych shardów, jak i całego systemu. Oracle dostarcza szereg widoków słownikowych i narzędzi do tego celu.
Na poziomie Catalogu mamy widoki takie jak GSMADMIN_INTERNAL.DATABASE (lista shardów), GSMADMIN_INTERNAL.SERVICE (usługi globalne) oraz GSMADMIN_INTERNAL.CHUNK (mapowanie chunków do shardów). Te widoki pozwalają zrozumieć topologię środowiska i stan poszczególnych komponentów.
Enterprise Manager Cloud Control oferuje graficzny interfejs do zarządzania środowiskiem shardowanym, włącznie z wizualizacją rozkładu danych, monitorowaniem wydajności poszczególnych shardów oraz alertami dotyczącymi nierównowagi obciążenia.
W praktyce warto również implementować własne metryki na poziomie aplikacji, mierzące czasy odpowiedzi per shard, liczbę zapytań cross-shard oraz rozkład ruchu. Te metryki pozwalają wcześnie wykryć problemy z równowagą obciążenia.
Zapytania cross-shard i ich wpływ na wydajność
W idealnym świecie każde zapytanie trafia do pojedynczego shardu i tam jest w całości przetwarzane. W rzeczywistości niektóre zapytania muszą agregować dane z wielu shardów. Oracle obsługuje takie zapytania, ale ich wydajność jest znacząco niższa.
Zapytania cross-shard są koordynowane przez Catalog, który zbiera wyniki częściowe z poszczególnych shardów i agreguje je. To wprowadza dodatkowe opóźnienie sieciowe i obciążenie Catalogu. Dlatego przy projektowaniu aplikacji należy minimalizować zapytania cross-shard.
Praktyczne podejście to identyfikacja zapytań, które muszą być cross-shard (raporty zbiorcze, analityka) i wydzielenie ich do oddzielnego przepływu, najlepiej wykonywanych poza godzinami szczytu lub na replikach read-only. Zapytania transakcyjne powinny zawsze trafiać do pojedynczego shardu.
Kiedy Oracle Sharding ma sens
Oracle Sharding to technologia potężna, ale nie dla każdego. Wprowadza znaczącą złożoność operacyjną i architektoniczną. Przed podjęciem decyzji o wdrożeniu warto zadać sobie kilka pytań.
Czy rzeczywiście osiągnęliśmy granice skalowalności RAC? Wielu administratorów zbyt wcześnie sięga po sharding, gdy problemy można rozwiązać optymalizacją zapytań, indeksowaniem lub tuningiem instancji.
Czy model danych naturalnie wspiera sharding? Jeśli większość zapytań wymaga joinów między danymi, które trafiłyby na różne shardy, sharding przyniesie więcej problemów niż korzyści.
Czy mamy kompetencje i zasoby do zarządzania środowiskiem rozproszonym? Administracja 50 shardami to zupełnie inna skala wyzwań niż zarządzanie pojedynczą bazą danych.
- Systemy obsługujące setki milionów użytkowników globalnie
- Platformy SaaS multi-tenant z wymaganiami izolacji danych
- Systemy wymagające data residency w różnych jurysdykcjach
- Aplikacje z naturalnymi granicami partycjonowania (per klient, per region)
Najczęstsze błędy przy wdrożeniach
Przez lata widziałem wiele wdrożeń shardingu, które nie przyniosły oczekiwanych rezultatów. Większość problemów wynikała z tych samych błędów popełnianych na etapie projektowania.
Błąd pierwszy to wybór klucza shardującego bez analizy wzorców dostępu. Klucz wybrany na podstawie intuicji często okazuje się nieodpowiedni, gdy aplikacja trafia na produkcję.
Błąd drugi to niedoszacowanie złożoności operacyjnej. Patching 50 shardów, monitoring 50 baz danych, zarządzanie backupami 50 środowisk wymaga automatyzacji i narzędzi, których organizacja może nie mieć.
Błąd trzeci to ignorowanie zapytań cross-shard na etapie projektowania. Jeśli 30% zapytań produkcyjnych wymaga agregacji danych z wielu shardów, korzyści ze shardingu są mocno ograniczone.
Błąd czwarty to brak planu na resharding. Wymagania biznesowe się zmieniają, a środowisko shardowane musi mieć możliwość ewolucji bez przestojów.