Google PCD: Dane aplikacji, stan i wzorce przechowywania — Przewodnik do nauki

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Część Google Professional Cloud Developer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Nowoczesne aplikacje w Google Cloud rutynowo łączą wiele magazynów danych, aby zrównoważyć opóźnienia, spójność, skalowalność, koszty i złożoność operacyjną. Wybór usług i wzorców dopasowanych do celu — oraz zrozumienie ich trybów awarii — ma kluczowe znaczenie dla projektowania odpornych systemów. Ta sekcja podsumowuje praktyczne wskazówki dotyczące usług Cloud SQL, Cloud Spanner, Firestore, Bigtable, Memorystore i Cloud Storage, a także omawia migracje, partycjonowanie i ochronę danych.

Dane relacyjne w Cloud SQL

Cloud SQL dostarcza zarządzane bazy danych MySQL, PostgreSQL i SQL Server ze znaną semantyką RDBMS.

Łączność prywatna
- Używaj prywatnego adresu IP, aby utrzymać ruch bazodanowy wewnątrz sieci VPC. Eliminuje to potrzebę publicznych reguł ingress i list dozwolonych adresów IP (allowlists) oraz pozwala uniknąć złożoności związanej z NAT egress.
- Upewnij się, że trasy i reguły zapory sieciowej zezwalają na ruch z VPC do instancji. Rozwiązywanie nazw dla prywatnego IP jest obsługiwane automatycznie po włączeniu tej opcji.
- W przypadku środowisk serverless (Cloud Run, App Engine, Cloud Functions) preferuj konektory Cloud SQL, które obsługują uwierzytelnianie IAM i szyfrowanie TLS, nawet przy użyciu prywatnego IP.
Wysoka dostępność i repliki
- Regionalna wysoka dostępność (HA) umieszcza instancję podstawową i zapasową (standby) w różnych strefach z synchroniczną replikacją dysku. Podczas przełączania awaryjnego (failover) należy spodziewać się krótkiego zerwania połączenia; aplikacje powinny ponawiać próby w przypadku błędów przejściowych i ponownie nawiązywać połączenie.
- Repliki do odczytu (read replicas) są asynchroniczne i odciążają ruch związany z odczytem. Używaj replik międzyregionalnych do celów odtwarzania po awarii (DR) i zapewnienia bliskości odczytu (read proximity), pamiętając, że repliki te zapewniają spójność ostateczną (eventually consistent).
- Awansuj replikę do odczytu w celu odzyskiwania danych lub planowanej zamiany ról. Regularnie testuj procedury awansowania (promotion).
Kopie zapasowe i odzyskiwanie do punktu w czasie (point-in-time recovery)
- Włącz automatyczne kopie zapasowe i logi transakcji/PITR. Planuj tworzenie kopii zapasowych poza godzinami szczytu, aby zmniejszyć rywalizację o zasoby IO.
- Przechowuj wiele kopii i okresowo weryfikuj proces ich odtwarzania na oddzielnej instancji. Kopia zapasowa, której nie można odtworzyć, jest operacyjnie równoznaczna z brakiem kopii zapasowej.
Pule połączeń i limity
- Cloud SQL wymusza maksymalną liczbę połączeń; nadmierna liczba krótkotrwałych połączeń powoduje gwałtowne zużycie CPU (CPU thrash) i zwiększa opóźnienia. Używaj pul połączeń po stronie aplikacji (np. HikariCP, PgBouncer, ProxySQL).
- Dobieraj rozmiar puli w oparciu o liczbę rdzeni CPU i współbieżność obciążenia, a nie tylko o pamięć instancji. Zacznij od małej wartości i skaluj empirycznie.
- W przypadku efemerycznych/bezserwerowych środowisk obliczeniowych, konektor Cloud SQL specyficzny dla danego języka utrzymuje pulę per rewizja; mimo to ograniczaj współbieżność, aby uniknąć “burzy połączeń” (connection storms) po zimnym starcie.
Partycjonowanie danych i wydajność
- Sharduj duże schematy wielodostępowe (multi-tenant) według klienta lub regionu, aby zmniejszyć rywalizację o zasoby. W miarę możliwości izoluj “gorących” najemców (hot tenants).
- Ostrożnie twórz indeksy pokrywające (covering indexes); nadmierna liczba indeksów spowalnia operacje zapisu i zwiększa zużycie pamięci masowej. Weryfikuj kardynalność i selektywność predykatów.
- Używaj blokowania optymistycznego lub SELECT FOR UPDATE dla “gorących” wierszy (hot rows); dostosuj ustawienia autovacuum (PostgreSQL) lub InnoDB (MySQL) do ciągłych obciążeń zapisu.

Typowe tryby awarii i sposoby ich łagodzenia:

Efekt “galopującego stada” (thundering herds) po restarcie maszyn wirtualnych/węzłów: ogranicz rozmiary pul i stosuj wykładniczy backoff (exponential backoff).
Opóźnienie repliki (replica lag) dla spójności typu read-your-writes: przypinaj odczyty do instancji podstawowej, gdy wymagana jest spójność na poziomie sesji.
Niestabilne przełączanie awaryjne HA (failover flaps) z powodu “hałaśliwych sąsiadów” lub prac konserwacyjnych: zaimplementuj ponawianie prób połączeń i transakcji z zapewnieniem idempotencji.

Relacyjna baza danych o skali planetarnej w Cloud Spanner

Cloud Spanner zapewnia skalowalność horyzontalną z opcjami globalnej spójności.

Spójność i transakcje
- Silne odczyty (strong reads) i transakcje odczytu i zapisu (read-write) zapewniają ścisłą spójność zewnętrzną (strict external consistency) przy użyciu TrueTime; zatwierdzenia (commits) czekają krótko, aby zapewnić linearyzowalność.
- Odczyty nieaktualne (stale reads) i o ograniczonej nieaktualności (bounded-staleness reads) zmniejszają opóźnienia i poprawiają dostępność dla obciążeń z dużą liczbą odczytów, gdy świeżość danych może być nieco mniejsza.
- Transakcje tylko do odczytu (read-only) obejmują wiele odczytów w danym punkcie czasowym (timestamp) bez zakładania blokad; używaj ich do tworzenia spójnych migawek analitycznych.
Regionalność, dostępność i opóźnienia
- Instancje regionalne zapewniają wysoką dostępność w obrębie jednego regionu. Konfiguracje wieloregionalne (na przykład nam-asia-eur1) dostarczają bardzo wysoką dostępność i niskie opóźnienia lokalnych odczytów na różnych kontynentach, przy zachowaniu globalnie spójnych zapisów.
- Wybieraj konfiguracje instancji dopasowane do geografii Twoich użytkowników; opóźnienia zapisu rosną wraz z rozmiarem kworum międzykontynentalnego.
Skalowalność i projektowanie schematu
- Spanner sharduje dane na fragmenty (splits) według zakresów klucza podstawowego, rozproszone pomiędzy węzłami. Hotspotting występuje, gdy klucze są monotonicznie rosnące. Unikaj kluczy takich jak autoinkrementowane ID lub zawsze rosnące znaczniki czasu na początku klucza.
- Używaj złożonych kluczy podstawowych, które rozpraszają zapisy (na przykład, customer_hash, customer_id, reverse_timestamp).
- Tabele przeplatane (interleaved tables) umieszczają wiersze podrzędne razem z nadrzędnymi, co zapewnia lokalność danych i wydajne złączenia. Używaj ich, gdy kardynalność i dostęp do danych podrzędnych są silnie skorelowane z danymi nadrzędnymi. Uzupełnij je indeksami wtórnymi; rozważ użycie klauzul STORING, aby zredukować liczbę odwołań do tabeli.
- Monitoruj użycie CPU, pamięci masowej oraz operacje o wysokim priorytecie w porównaniu do operacji typu best-effort; skaluj węzły, aby utrzymać zapas wydajności (headroom) poniżej opóźnień P95.
Wzorce operacyjne
- Klienci używają pul sesji; dostosuj minimalną/maksymalną liczbę sesji, aby uniknąć “burzy tworzenia” (creation storms). Ponowne próby powinny być ograniczone i idempotentne; w przypadku statusu ABORTED, ponów transakcje odczytu i zapisu z zastosowaniem mechanizmu backoff.
- Kopie zapasowe są lekkie i spójne; weryfikuj proces ich odtwarzania na oddzielnych instancjach. Strumienie zmian (change streams) i integracje CDC mogą zasilać systemy podrzędne.

Kompromisy:

Silne zapisy globalne dodają opóźnienie zatwierdzenia (commit-wait); używaj odczytów nieaktualnych (stale reads) dla ścieżek krytycznych z punktu widzenia UX, które głównie odczytują dane.
Przeplatanie (interleaving) poprawia lokalność danych, ale może koncentrować obciążenie zapisu; testuj przy użyciu ruchu zbliżonego do produkcyjnego.

Migracja, spójność, partycjonowanie i ochrona danych

Migracja bazy danych
- Wybór między migracją online a offline: online z użyciem Database Migration Service dla minimalnego czasu przestoju; offline dla prostoty, gdy okna konserwacyjne są akceptowalne.
- Podejście schema-first: uzgodnij typy i ograniczenia; w przypadku Spanner rozważ narzędzia do mapowania schematów i danych z MySQL/PostgreSQL, a następnie dostosuj klucze i indeksy w celu zapewnienia dobrej dystrybucji.
- Działanie równoległe i przełączenie: podczas migracji online stosuj podwójny zapis lub replikację dzienników zmian (changelogs). Zweryfikuj liczbę wierszy, sumy kontrolne i zachowanie krytycznych zapytań przed ostatecznym przełączeniem.
Migracje schematu i wycofywanie zmian
- Używaj wersjonowanych, zautomatyzowanych migracji (na przykład za pomocą narzędzia do migracji) jako części CI/CD. Projektuj zmiany w sposób addytywny i wstecznie kompatybilny: dodaj kolumny i indeksy, uzupełnij dane historyczne (backfill), wdróż kod, który odczytuje/zapisuje obie wersje, a następnie usuń przestarzałe artefakty.
- Zaplanuj wycofanie zmian (rollback) z transformacjami danych: jeśli wdrożenie kodu się nie powiedzie, bądź przygotowany na wyłączenie nowych zapisów i poleganie na flagach funkcjonalności (feature flags); unikaj migracji destrukcyjnych, które blokują możliwość wycofania zmian.
Przepływy transakcyjne a ostatecznie spójne (eventually consistent)
- Używaj transakcji ACID, gdy niezmienniki muszą być zachowane synchronicznie (np. transfery środków, dekrementacja stanów magazynowych).
- Preferuj spójność ostateczną dla funkcji głównie do odczytu, widocznych dla użytkownika, gdzie kluczowa jest niska latencja (np. kanały informacyjne, wyszukiwanie, liczniki). Implementuj klucze idempotencji, wzorce outbox/Saga oraz ponowienia prób z mechanizmem backoff.
- Łącz podejścia: zatwierdzaj autorytatywny stan w magazynie transakcyjnym; publikuj zdarzenia dla ostatecznie spójnych projekcji.
Partycjonowanie danych i zarządzanie połączeniami
- Partycjonuj według dzierżawcy (tenant), lokalizacji geograficznej lub typu obciążenia, aby izolować gorące punkty (hotspots). W przypadku Bigtable i Spanner zakoduj klucze partycjonowania w kluczach głównych; w przypadku Cloud SQL użyj schematu na dzierżawcę (schema-per-tenant) lub shardingu tabel z routerami.
- Zarządzaj połączeniami:
  - Cloud SQL: puluj i ponownie wykorzystuj; ograniczaj współbieżność; rozkładaj w czasie zimne starty (cold starts).
  - Spanner: ponownie wykorzystuj sesje; rozgrzewaj pule przy starcie; ograniczaj liczbę ponowień.
  - Memorystore: ponownie wykorzystuj połączenia TCP; unikaj nawiązywania połączeń dla każdego żądania.
Ochrona danych, archiwizacja, weryfikacja odtwarzania i zachowanie przy usuwaniu
- Kopie zapasowe i archiwizacja:
  - Cloud SQL: zautomatyzowane kopie zapasowe + PITR; testuj odtwarzanie.
  - Spanner: zarządzane kopie zapasowe; testuj odtwarzanie do środowiska nieprodukcyjnego.
  - Firestore: zaplanowane eksporty do Cloud Storage; weryfikuj importy.
  - Bigtable: kopie zapasowe i migawki (snapshots); testuj klonowanie i odtwarzanie.
  - Cloud Storage: polityki retencji, blokady obiektów (object holds) i jednolity dostęp na poziomie bucketa dla ładu korporacyjnego (governance); archiwizuj do chłodniejszych klas poprzez cykl życia (lifecycle).
- Weryfikacja odtwarzania: okresowo odtwarzaj dane do izolowanych środowisk i uruchamiaj zapytania walidacyjne oraz testy dymne (smoke tests) aplikacji. Śledź RTO/RPO w odniesieniu do przyjętej polityki.
- Zachowanie przy usuwaniu:
  - GC i cykl życia w Bigtable są asynchroniczne — nie obiecuj natychmiastowego usunięcia danych.
  - Wersjonowanie w Cloud Storage przechowuje generacje obiektów, dopóki cykl życia ich nie usunie.
  - TTL i usuwanie oparte na eksporcie w Firestore są asynchroniczne.
  - Dla umów SLA dotyczących twardego usuwania, projektuj procesy, które oznaczają dane do usunięcia, kolejkują operację i weryfikują usunięcie, z wykorzystaniem dzienników audytu.

Praktyczny scenariusz problemowy

Firma Aurora Outfitters migruje monolityczną platformę e-commerce do Google Cloud. Muszą: 1) przenieść bazę MySQL metodą lift-and-shift, aby zredukować ryzyko, 2) obsługiwać przesyłanie plików multimedialnych o rozmiarze 500 MB bez przeciążania aplikacji, 3) skalować przepustowość odczytu dla katalogów produktów oraz 4) egzekwować limity zapytań na użytkownika (rate limits) podczas szczytów sprzedaży.

Podejście:

Migracja MySQL do Cloud SQL z prywatnym adresem IP i regionalną wysoką dostępnością (HA)
- Uzasadnienie: Prywatny adres IP eliminuje publiczną ekspozycję i potrzebę stosowania list dozwolonych adresów IP (allowlists), upraszczając bezpieczną łączność z GKE i Compute Engine. Regionalna wysoka dostępność (HA) chroni przed awariami strefowymi; należy spodziewać się krótkich przerw w połączeniu podczas przełączania awaryjnego (failover), więc aplikacja zaimplementuje transakcje z możliwością ponowienia i logikę ponownego łączenia.
Włączenie automatycznych kopii zapasowych i PITR oraz walidacja odtwarzania
- Uzasadnienie: Automatyczne kopie zapasowe i dzienniki transakcji umożliwiają odtwarzanie do punktu w czasie (point-in-time recovery) po błędach użytkownika lub aplikacji. Zaplanowane cotygodniowe odtwarzanie do instancji nieprodukcyjnej weryfikuje użyteczność kopii zapasowych i mierzy RTO.
Dodanie repliki do odczytu (read replica) dla zapytań do katalogu
- Uzasadnienie: Przeniesienie zapytań do katalogu na replikę do odczytu zmniejsza rywalizację o zasoby na instancji głównej (primary). Aplikacja odczytuje z instancji głównej, gdy wymagana jest spójność typu write-after-read (koszyk/finalizacja zakupu), a z repliki podczas przeglądania katalogu, rozumiejąc kompromisy związane z opóźnieniem repliki (replica lag).
Wprowadzenie pulowania połączeń po stronie aplikacji i ograniczenie współbieżności
- Uzasadnienie: Narzędzia takie jak PgBouncer/HikariCP ograniczają i ponownie wykorzystują połączenia, unikając burz połączeń (connection storms) podczas autoskalowania i przełączeń awaryjnych HA. Pule są wymiarowane do liczby rdzeni CPU, a nie do maksymalnej liczby podów, co zapobiega przeciążeniu.
Przeniesienie obsługi przesyłania mediów do Cloud Storage z użyciem podpisanych adresów URL (signed URLs) i wznawialnych transferów (resumable uploads)
- Uzasadnienie: Aplikacja wystawia krótkotrwałe podpisane adresy URL, aby klienci mogli przesyłać pliki bezpośrednio. Wznawialne transfery są dostosowane do zawodnych sieci; serwis mediów nasłuchuje powiadomień o finalizacji z Pub/Sub, aby uruchomić przetwarzanie. Nagłówki warunków wstępnych (precondition headers), takie jak ifGenerationMatch, chronią przed wyścigami zapisu (overwrite races).
Wdrożenie Memorystore for Redis do buforowania stron, obsługi sesji i ograniczania liczby zapytań (rate limiting)
- Uzasadnienie: Pamięci podręczne typu read-through zmniejszają obciążenie bazy danych dla stron produktów, z czasem życia (TTL) dostosowanym do częstotliwości aktualizacji. Dane sesji są przechowywane efemerycznie w Redis z krótkim TTL; stan aplikacji pozostaje w Cloud SQL. Strategia tokenów w stałym oknie czasowym (fixed-window) wykorzystuje INCR/EXPIRE do limitowania żądań na użytkownika. Pamięć podręczna jest traktowana jako nieautorytatywna; aplikacja toleruje utratę pamięci podręcznej i uzupełnia ją w przypadku braku trafienia (cache miss).
Przygotowanie etapowej ścieżki migracji do Cloud Bigtable dla funkcji przeglądania katalogu o wysokiej przepustowości
- Uzasadnienie: W miarę wzrostu ruchu, zdenormalizowane, zoptymalizowane pod kątem odczytu widoki katalogu zostaną przeniesione do Bigtable. Klucze wierszy są zaprojektowane jako bucket#kategoria#odwrócony_znacznik_czasu, aby rozproszyć zapisy i wspierać listowanie uporządkowane czasowo bez tworzenia gorących punktów (hotspotting).
Ustanowienie procedur migracji schematu i wycofywania zmian (rollback)
- Uzasadnienie: Migracje są addytywne: dodawane są kolumny/indeksy, dane są uzupełniane za pomocą idempotentnych zadań, wdrażany jest kod, który odczytuje/zapisuje obie wersje, a następnie stare pola są usuwane. Flagi funkcjonalności (feature flags) chronią nowe ścieżki kodu; wycofanie zmian (rollback) wyłącza zapisy do nowych pól bez destrukcyjnego DDL.
Ustawienie polityk cyklu życia i ochrony danych
- Uzasadnienie: Buckety Cloud Storage używają reguł cyklu życia do przenoszenia miniatur do chłodniejszej klasy przechowywania i usuwania nieaktualnych, tymczasowych plików. Kopie zapasowe Cloud SQL oraz Spanner/Bigtable (w miarę ich wdrażania) są regularnie odtwarzane w celach weryfikacyjnych. Dzienniki audytu rejestrują przepływy pracy związane z usuwaniem; asynchroniczny charakter Bigtable GC jest odnotowany w dokumentacji zgodności (compliance).
Wdrożenie ponawiania prób po stronie klienta i serwera z obciętym wykładniczym czasem wycofania (truncated exponential backoff)
- Uzasadnienie: Cloud Storage może zwracać błędy 429/5xx podczas skoków obciążenia; mechanizm backoff wygładza obciążenie i zmniejsza liczbę błędów. Operacje na bazie danych i pamięci podręcznej używają kluczy idempotencji, aby zapewnić bezpieczne ponawianie prób, szczególnie podczas przełączania awaryjnego i chwilowych problemów z siecią.

Ten plan zapewnia natychmiastową redukcję ryzyka dzięki Cloud SQL z prywatną łącznością i HA, utrzymuje responsywność i efektywność kosztową aplikacji dzięki buforowaniu i przesyłaniu plików przez signed URL oraz tworzy jasną ścieżkę do skalowania przepustowości odczytu i odporności danych w miarę wzrostu ruchu.

← Projektowanie API · Wszystkie domeny · Tożsamość →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →