Google ACE: Pamięć masowa, bazy danych i usługi danych — Przewodnik do nauki

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Przegląd

Ta sekcja stanowi praktyczny, zorientowany na operacje przewodnik po usługach Google Cloud w zakresie przechowywania danych, baz danych i analityki. Kładzie nacisk na wzorce konfiguracji, kontrolę dostępu, mechanizmy trwałości, charakterystykę wydajności i kosztów oraz bezpieczne praktyki odzyskiwania danych. Celem jest pomoc w podjęciu decyzji, której usługi użyć dla danego obciążenia, zrozumienie kompromisów operacyjnych i przewidywanie typowych trybów awarii.

Cloud Storage: projektowanie, dostęp, cykl życia i ochrona

Cloud Storage to trwały, wysoko dostępny magazyn obiektów dla danych nieustrukturyzowanych i kopii zapasowych.

• Buckety i obiekty: Buckety to globalne przestrzenie nazw w danej lokalizacji (regionie, podwójnym lub wieloregionie), które zawierają niezmienne wersje obiektów. Wybierz lokalizację bucketa, aby zminimalizować ruch wychodzący (egress) i spełnić wymogi dotyczące rezydencji danych.
• Klasy pamięci masowej: Używaj Standard (gorąca), Nearline (min. ~30 dni), Coldline (min. ~90 dni) i Archive (min. ~365 dni) w zależności od częstotliwości dostępu. Dla kopii zapasowych odzyskiwania po awarii (DR), Coldline jest częstym wyborem domyślnym. Można mieszać klasy dla poszczególnych obiektów w ramach jednego bucketa.
• Reguły cyklu życia: Automatyzuj przenoszenie i usuwanie obiektów za pomocą warunków Age, CreatedBefore, MatchesStorageClass i NoncurrentVersion. Przykład przeniesienia po 90 dniach i usunięcia po 365 dniach:
  1. lifecycle.json: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 90}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
  2. Zastosuj: gsutil lifecycle set lifecycle.json gs://my-bucket
• Przechowywanie i blokady prawne: Zasady przechowywania (retention policies) zapobiegają usunięciu lub modyfikacji obiektów przed upływem okresu; zablokowanie zasady jest nieodwracalne. Blokady prawne (legal holds) są nakładane na poszczególne obiekty i muszą zostać usunięte przed ich skasowaniem.

Kontrola dostępu i udostępnianie:

• Jednolity vs szczegółowy: Preferuj jednolity dostęp na poziomie bucketa (UBLA), aby zarządzać uprawnieniami wyłącznie za pomocą IAM. Dostęp szczegółowy (listy ACL obiektów) jest przestarzały i komplikuje audytowalność oraz propagację uprawnień. Włączenie UBLA dezaktywuje listy ACL i może natychmiast wpłynąć na istniejące integracje, które na nich polegały.
• Podpisane adresy URL: Aby zapewnić krótkotrwały dostęp bez tożsamości Google, użyj podpisanych adresów URL (signed URLs). Unikaj plików kluczy konta serwisowego, podpisując żądania za pomocą IAM: gcloud storage sign-url gs://my-bucket/path/object –duration=4h –impersonate-service-account sa-sharing@proj.iam.gserviceaccount.com Upewnij się, że konto serwisowe ma uprawnienie service account token creator nadane sobie samemu lub poprzez rolę signer.
• Szyfrowanie: Domyślnie włączone jest szyfrowanie po stronie serwera; włącz CMEK na poziomie bucketa lub obiektu, gdy potrzebujesz kontroli nad kluczami i ścieżkami audytu. Monitoruj dostępność i rotację kluczy KMS; niedostępność CMEK zablokuje wysyłanie i deszyfrowanie danych.
• Wersjonowanie: Włącz wersjonowanie obiektów, aby zachować nieaktualne wersje po nadpisaniu/usunięciu. Połącz z regułami cyklu życia, aby wygaszać nieaktualne wersje i kontrolować wzrost zużycia pamięci. Bądź świadomy logiki listowania po stronie klienta, gdy istnieje wiele wersji obiektu.

Tryby awarii i ich łagodzenie:

• Przypadkowe usunięcie lub nadpisanie: Użyj wersjonowania i zasad przechowywania. Dla ścisłej zgodności z regulacjami, zablokuj zasady przechowywania.
• Błędnie skonfigurowany dostęp publiczny: Wymuś zapobieganie dostępowi publicznemu (Public Access Prevention) i UBLA. Okresowo przeprowadzaj audyt za pomocą Cloud Asset Inventory i analizatora zasad (policy analyzer).
• Nadmierne koszty: Reguły cyklu życia, klasy na poziomie obiektów i opcja requester pays zmniejszają ryzyko niespodzianek. Monitoruj za pomocą metryk Cloud Monitoring i budżetów.

Przydatne polecenia:

• Utwórz bucket z UBLA i przechowywaniem: gcloud storage buckets create gs://my-bucket –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://my-bucket –retention-period=365d

Pamięć blokowa i plikowa dla obciążeń obliczeniowych

Wybierz pamięć masową na podstawie wzorca dostępu, wymagań wydajnościowych i trwałości dla Compute Engine i GKE.

• Persistent Disk (PD): Trwała pamięć blokowa, strefowa lub regionalna. Typy: Standard (HDD) dla przepustowości sekwencyjnej; Balanced (pd-balanced) i SSD (pd-ssd) dla niskich opóźnień i dużej liczby operacji IOPS. Regionalny PD synchronicznie replikuje dane między strefami, umożliwiając szybsze odzyskiwanie. PD można snapshotować, zmieniać rozmiar online i podłączać w trybie tylko do odczytu do wielu maszyn wirtualnych (jeden zapisujący dla trybu odczytu i zapisu).
  • Kompromisy: Wyższe koszty IOPS na SSD; HDD jest opłacalny, ale ma wysokie opóźnienia dla losowych operacji we/wy. Regionalny PD kosztuje więcej, ale skraca RTO.
• Local SSD: Efemeryczna pamięć masowa podłączona przez NVMe lub SCSI o bardzo wysokiej liczbie IOPS i niskich opóźnieniach. Dane są tracone podczas zatrzymania maszyny wirtualnej lub konserwacji hosta; używaj go tylko dla efemerycznych pamięci podręcznych lub danych replikowanych. Twórz kopie zapasowe lub replikuj dane w inne miejsce, aby uniknąć ich utraty.
• Filestore: Zarządzany NFS zapewniający semantykę współdzielenia plików zgodną z POSIX. Podstawowe poziomy (tiers) są strefowe; Enterprise i wyższe oferują regionalną wysoką dostępność (HA) z synchroniczną replikacją i wyższą liczbą IOPS. Idealny dla GCVE, tymczasowej przestrzeni roboczej HPC, renderowania mediów i aplikacji wymagających współdzielonego blokowania plików.
  • Kompromisy: NFS wprowadza buforowanie po stronie klienta i semantykę blokad; przepustowość i opóźnienia różnią się w zależności od poziomu; nie nadaje się do małych, losowych operacji we/wy z opóźnieniami rzędu pojedynczych mikrosekund, jak Local SSD.

Rozważania dotyczące awarii:

• Konserwacja hosta: Utrata danych na Local SSD; zabezpiecz poprzez replikację na poziomie aplikacji.
• Awarie strefowe: Przerwy w działaniu strefowego PD i Filestore Basic; użyj regionalnego PD lub Filestore Enterprise dla wysokiej dostępności (HA).
• Spójność snapshotów: Aby uzyskać spójne na poziomie aplikacji snapshoty PD, skoordynuj operację z zamrożeniem systemu plików lub natywnym wyciszeniem bazy danych, aby uniknąć okien odzyskiwania po awarii.

Zarządzane bazy danych i usługi danych

Cloud SQL (zarządzany MySQL, PostgreSQL, SQL Server):

• Konfiguracja: Wybierz typ maszyny, rodzaj pamięci masowej, połączenia (preferowany prywatny adres IP), autoryzowane sieci w przypadku korzystania z publicznego IP, okna konserwacji i wglądy (insights) do diagnostyki wydajności. Używaj puli połączeń (np. Cloud SQL Auth Proxy, PGbouncer), aby nie przekraczać limitów połączeń i CPU.
• Wysoka dostępność: Regionalne instancje HA wdrażają instancję rezerwową (standby) w innej strefie z synchroniczną replikacją pamięci masowej; przełączanie awaryjne (failover) jest automatyczne. Podczas przełączania awaryjnego należy spodziewać się krótkiego okna niedostępności zapisu.
• Repliki: Repliki do odczytu (read replicas) do skalowania odczytów i odciążania systemów BI; replikacja zewnętrzna do celów migracji. Monitoruj opóźnienie replikacji (replica lag) i projektuj idempotentne systemy odczytujące.
• Kopie zapasowe i PITR: Włącz zautomatyzowane kopie zapasowe i logowanie binarne/WAL w celu przywracania do punktu w czasie (point-in-time recovery). Regularnie testuj proces przywracania.

undefined

• Tryby awarii: Długo działające transakcje blokują procesy vacuum/checkpointing; nagłe wzrosty liczby połączeń powodują niestabilność (thrashing); automatyczne powiększanie pamięci masowej może się zatrzymać, jeśli limit (quota) jest niewystarczający. Ustaw alerty dla użycia CPU, pamięci, liczby połączeń, opóźnienia replikacji i użycia dysku.

Cloud Spanner:

• Skala i regionalność: Instancje regionalne lub wieloregionalne z synchroniczną replikacją i silną spójnością globalną. Skaluj węzły w celu zwiększenia przepustowości i pojemności; lokalizacja regionu wiodącego (leader region) wpływa na opóźnienie zapisu.
• Schemat i klucze: Projektuj klucze główne tak, aby unikać hotspotów; używaj kluczy złożonych z haszowanym lub losowym prefiksem dla danych szeregów czasowych, aby rozproszyć zapisy. Używaj indeksów wtórnych dla wzorców zapytań i rozważ przechowywanie razem często filtrowanych kolumn. Utrzymuj transakcje małe i ograniczone, aby zminimalizować rywalizację o blokady (lock contention).
• Transakcje: Silnie spójne, rozproszone transakcje z zewnętrzną spójnością dzięki TrueTime. Opóźnienie zapisu ograniczone przez kworum; konflikty prowadzą do przerwania transakcji — ponów próbę z wycofywaniem wykładniczym (backoff).

Firestore i Bigtable:

• Firestore (tryb natywny): Baza dokumentowa z kolekcjami, nasłuchiwaniem w czasie rzeczywistym (real-time listeners), transakcjami obejmującymi do 500 dokumentów na transakcję i silną spójnością dla odczytów dokumentów i większości zapytań. Najlepsza dla danych aplikacji mobilnych/webowych, hierarchicznych danych JSON i aplikacji sterowanych zdarzeniami.
• Bigtable: Szerokokulumnowa baza danych (wide-column) dla skali petabajtowej i opóźnień poniżej 10 ms. Tylko transakcje na pojedynczym wierszu; projektuj klucze wierszy tak, aby unikać hotspottingu. Idealna dla szeregów czasowych, IoT, personalizacji i liczników na dużą skalę. Nie nadaje się do złączeń ad-hoc ani złożonych agregacji.

Memorystore:

• Redis i Memcached: Pamięci podręczne typu in-memory zapewniające opóźnienia na poziomie mikrosekund-milisekund. Poziom Basic nie ma wysokiej dostępności (HA); poziom Standard zapewnia regionalną wysoką dostępność z automatycznym przełączaniem awaryjnym dla Redis. Traktuj jako dane efemeryczne; nie używaj jako głównego systemu zapisu (system of record).

BigQuery:

• Zbiory danych i tabele: Organizuj dane według zbiorów danych (dataset); kontroluj dostęp na poziomie projektu, zbioru danych, tabeli, kolumny i wiersza. Używaj tabel partycjonowanych i klastrowanych, aby kontrolować ilość skanowanych bajtów i koszty.
• Zadania ładowania i zapytań: Ładuj dane z Cloud Storage, eksportów Cloud SQL lub za pomocą wstawiania strumieniowego (streaming inserts). Używaj próbnych uruchomień (dry runs), aby oszacować koszt:

undefined

• Kontrola dostępu: Nadawaj rolę BigQuery Data Viewer na poziomie zbioru danych dla użytkowników tylko do odczytu; używaj autoryzowanych widoków lub zabezpieczeń na poziomie wiersza/kolumny, aby zapewnić zasadę najmniejszych uprawnień (least privilege).

Przenoszenie, migracja, walidacja i kompromisy operacyjne danych

Migracja i transfer:

• Database Migration Service (DMS): Do migracji homogenicznych do Cloud SQL z minimalnym czasem przestoju dzięki replikacji. Waliduj przełączenie (cutover) za pomocą metryk opóźnienia i porównań sum kontrolnych.
• Transfery Cloud Storage: Storage Transfer Service do powtarzalnych lub sterowanych zdarzeniami transferów; gsutil -m rsync do jednorazowych zsynchronizowanych kopii z sumami kontrolnymi; Transfer Appliance do dużych transferów offline.
• Import/eksport: Cloud SQL eksportuje do Cloud Storage; ponowny import wspiera inicjalizację PITR i weryfikację danych. BigQuery wspiera wsadowe ładowanie z Cloud Storage i eksport do formatów Avro/Parquet do dalszego wykorzystania.
• Walidacja: Używaj sum kontrolnych obiektów (CRC32C), liczby wierszy, zapytań próbkujących i niezmienników na poziomie aplikacji. W przypadku BigQuery porównuj agregacje GROUP BY lub hashe między źródłem a celem.

Kompromisy w zakresie wydajności, dostępności, pojemności i kosztów:

• Cloud Storage: Optymalizuj ruch wychodzący (egress) poprzez współlokowanie zasobów obliczeniowych; wybieraj klasy na podstawie częstotliwości dostępu; używaj opcji dual-region/multi-region dla odporności międzystrefowej i wyższej dostępności przy wyższym koszcie przechowywania.
• PD/Filestore: SSD dla operacji I/O o niskim opóźnieniu; HDD dla przepustowości; replikacja regionalna dla wysokiej dostępności (HA); dobieraj odpowiednią liczbę IOPS, aby uniknąć dławienia (throttlingu).
• Cloud SQL: Skalowanie wertykalne jest proste, ale ograniczone; repliki do odczytu odciążają ruch odczytu; HA zwiększa dostępność, ale nie pojemność odczytu; klasa pamięci masowej wpływa na opóźnienia i koszty.
• Spanner: Skaluje się horyzontalnie z silną spójnością; koszt premium jest kompensowany przez globalne RPO/RTO i uproszczony sharding. Zapisy są wrażliwe na projekt klucza i opóźnienie w regionie lidera.
• Firestore/Bigtable/Memorystore: Wybieraj na podstawie opóźnień, modelu danych i spójności. Pamięci podręczne w pamięci (in-memory) zmniejszają obciążenie bazy danych, ale dodają złożoność związaną z unieważnianiem pamięci podręcznej.
• BigQuery: Koszt na żądanie (on-demand) jest proporcjonalny do przeskanowanych bajtów; partycjonowanie/klastrowanie i przenoszenie predykatów (predicate pushdown) zmniejszają wydatki. Rezerwacje o stałej cenie (flat-rate) wymieniają przewidywalność na zobowiązanie.

Rozwiązywanie problemów i bezpieczne odzyskiwanie:

• Cloud Storage: Używaj wersjonowania i retencji obiektów do odzyskiwania; analizuj logi dostępu do danych w Cloud Logging, aby audytować zdarzenia odczytu/zapisu; upewnij się, że klucze CMEK są włączone podczas odzyskiwania.
• PD/Filestore: Odtwarzaj z migawek lub kopii zapasowych; uruchamiaj fsck i tryby odzyskiwania bazy danych; zapewnij spójność poprzez wyciszenie na poziomie aplikacji przed wykonaniem migawki.
• Cloud SQL: Odtwarzaj do nowej instancji dla PITR, aby uniknąć utraty danych na instancji głównej; weryfikuj za pomocą testów tylko do odczytu; utrzymuj zaporę sieciową i prywatny DNS dla bezpiecznych wzorców przełączania.
• Spanner/Bigtable: Badaj hotspotting spowodowany nierównomiernym dostępem do kluczy; używaj Monitoring do śledzenia opóźnień i dławienia; implementuj wycofywanie wykładnicze (backoff) i ponawianie prób dla przerwanych transakcji lub operacji z ograniczoną częstotliwością.
• BigQuery: Diagnozuj wolne zapytania za pomocą szczegółów wykonania; dodaj partycje i klastrowanie; ogranicz użycie SELECT *; materializuj wyniki pośrednie, gdy jest to stosowne. Odzyskuj usunięte tabele w oknie podróży w czasie (time travel), przywracając migawkę lub kopiując z punktu czasowego migawki.

Praktyczny scenariusz problemowy

Firma Contoso Retail konsoliduje kopie zapasowe i dane analityczne, jednocześnie wzmacniając mechanizmy kontroli dostępu i umożliwiając odzyskiwanie do punktu w czasie (point-in-time recovery) dla swoich systemów transakcyjnych. Muszą: przechowywać kopie zapasowe aplikacji z automatycznym przenoszeniem między warstwami (tiering), udostępniać pliki na krótki czas stronom trzecim, włączyć PITR dla niewielkiego obciążenia relacyjnego oraz szacować koszty zapytań analitycznych przed ich wykonaniem.

Podejście:

1. Utwórz regionalny bucket Cloud Storage z UBLA, retencją i cyklem życia.

   • Polecenie: gcloud storage buckets create gs://contoso-backups –location=us-central1 –uniform-bucket-level-access –default-storage-class=STANDARD gcloud storage buckets update gs://contoso-backups –retention-period=365d gsutil lifecycle set lifecycle.json gs://contoso-backups
   • Uzasadnienie: UBLA centralizuje autoryzację w IAM i poprawia audytowalność. Roczna retencja zapobiega przypadkowemu usunięciu. Cykl życia przenosi kopie zapasowe do klasy Coldline po 90 dniach i usuwa je po wygaśnięciu, aby kontrolować koszty.

2. Przyznaj dostęp tylko do zapisu dla zadań tworzenia kopii zapasowych za pomocą dedykowanego konta serwisowego.

   • Polecenie: gcloud storage buckets add-iam-policy-binding gs://contoso-backups –member=serviceAccount:backup-writer@contoso.iam.gserviceaccount.com –role=roles/storage.objectCreator
   • Uzasadnienie: Rola storage.objectCreator zapobiega manipulacji metadanymi i odczytywaniu wrażliwych kopii zapasowych, zgodnie z zasadą najmniejszych uprawnień.

3. Udostępnij wrażliwą kopię zapasową dostawcy na cztery godziny, używając podpisanego adresu URL bez dystrybucji kluczy.

   • Polecenie: gcloud storage sign-url gs://contoso-backups/db-dump-2024-09-30.sql.gz –duration=4h –impersonate-service-account share-signer@contoso.iam.gserviceaccount.com
   • Uzasadnienie: Ograniczony czasowo dostęp bez tożsamości pozwala uniknąć tworzenia zewnętrznych tożsamości lub długotrwałych sekretów. Impersonifikacja wykorzystuje scentralizowane podpisywanie wspierane przez KMS i eliminuje ryzyko wycieku kluczy.

4. Włącz kopie zapasowe Cloud SQL i PITR dla bazy danych zamówień.

   • Polecenie: gcloud sql instances patch orders-sql –backup-start-time=02:00 –enable-bin-log
   • Uzasadnienie: Zautomatyzowane kopie zapasowe oraz logowanie binarne/WAL zapewniają punkty przywracania do dowolnej sekundy w oknie retencji, chroniąc przed logicznym uszkodzeniem i błędem operatora.

5. Przetestuj odzyskiwanie, przywracając dane do nowej instancji i walidując je przed przełączeniem.

   • Polecenie: gcloud sql backups list –instance=orders-sql gcloud sql instances restore-backup orders-restore –backup-id=LATEST –destination-instance=orders-restore
   • Uzasadnienie: Przywracanie do oddzielnej instancji pozwala uniknąć wpływu na produkcję i umożliwia walidację za pomocą sum kontrolnych i zapytań próbkujących przed jakimkolwiek przełączeniem na poziomie DNS lub aplikacji.

6. Oszacuj koszt zapytania BigQuery za pomocą uruchomienia próbnego (dry run) i zoptymalizuj za pomocą partycjonowania.

   • Polecenie: bq query –use_legacy_sql=false –dry_run=true ‘SELECT COUNT(*) FROM contoso.analytics.sales WHERE sale_date >= “2026-01-01”’
   • Uzasadnienie: Uruchomienia próbne ujawniają liczbę bajtów do przeskanowania; upewnienie się, że sale_date jest kolumną partycjonującą z ograniczonym predykatem, zmniejsza liczbę skanowanych bajtów i kontroluje koszty na żądanie.

7. Monitoruj i audytuj dostęp.

   • Kroki:
     • Włącz logi dostępu do danych (Data Access logs) dla Cloud Storage i BigQuery.
     • Skonfiguruj alerty Cloud Monitoring dla połączeń Cloud SQL, użycia dysku i nieudanych kopii zapasowych.
   • Uzasadnienie: Logi dostępu do danych zapewniają wgląd w operacje odczytu/zapisu na poziomie obiektu na potrzeby zgodności z przepisami. Proaktywne alerty skracają MTTR i zapewniają, że kopie zapasowe i PITR pozostają skuteczne.

8. Udokumentuj tryby awarii i procedury (runbooks).

   • Kroki:
     • Zapisz procedury przywracania wersji obiektów, unieważniania podpisanych adresów URL, odzyskiwania PITR w Cloud SQL oraz odzyskiwania tabel BigQuery przy użyciu funkcji time travel.
   • Uzasadnienie: Przejrzyste, przetestowane procedury (runbooks) zmniejszają ryzyko operacyjne podczas incydentów i standaryzują bezpieczne praktyki odzyskiwania w różnych zespołach.

← Sieci VPC · Wszystkie domeny · Wdrażanie →

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

Przeglądaj Google →