Google PCD: Данные приложений, состояние и паттерны хранения — Руководство по подготовке

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

Часть Google Professional Cloud Developer — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Google, или пройдите тесты на время на ExamRoll.io.

Обзор

Современные приложения в Google Cloud обычно сочетают несколько хранилищ данных для достижения баланса между задержкой, согласованностью, масштабируемостью, стоимостью и операционной сложностью. Выбор подходящих сервисов и паттернов, а также понимание их режимов сбоя, является ключевым аспектом отказоустойчивого проектирования. В этом разделе обобщаются практические рекомендации для Cloud SQL, Cloud Spanner, Firestore, Bigtable, Memorystore и Cloud Storage, а также рассматриваются вопросы миграции, секционирования и защиты данных.

Реляционные данные в Cloud SQL

Cloud SQL предоставляет управляемые MySQL, PostgreSQL и SQL Server с привычной семантикой СУБД.

Приватное подключение
- Используйте приватный IP-адрес, чтобы трафик базы данных оставался в вашей VPC. Это устраняет необходимость в правилах для входящего публичного трафика и списках разрешенных IP-адресов, а также позволяет избежать сложностей с NAT для исходящего трафика.
- Убедитесь, что маршруты и правила брандмауэра разрешают трафик от VPC к инстансу. Разрешение имен для приватного IP-адреса обрабатывается автоматически при его включении.
- Для бессерверных сред (Cloud Run, App Engine, Cloud Functions) предпочтительно использовать коннекторы Cloud SQL, которые управляют IAM-аутентификацией и TLS, даже при использовании приватного IP.
Высокая доступность и реплики
- Региональная высокая доступность (HA) размещает основной и резервный экземпляры в разных зонах с синхронной репликацией дисков. При переключении на резервный экземпляр ожидается кратковременный разрыв соединения; приложения должны повторять попытки при временных ошибках и переподключаться.
- Реплики чтения асинхронны и разгружают трафик чтения. Используйте межрегиональные реплики для аварийного восстановления (DR) и для уменьшения задержки чтения, понимая, что реплики в конечном итоге становятся согласованными.
- Повышайте реплику чтения для восстановления или плановой смены ролей. Регулярно тестируйте процедуры повышения.
Резервные копии и восстановление на момент времени
- Включите автоматическое резервное копирование и журналы транзакций/PITR. Планируйте резервное копирование на время низкой нагрузки, чтобы уменьшить конкуренцию за ввод-вывод.
- Храните несколько копий и периодически проверяйте восстановление на отдельный инстанс. Резервная копия, которую невозможно восстановить, с операционной точки зрения равносильна отсутствию резервной копии.
Пулы соединений и лимиты
- Cloud SQL устанавливает максимальное количество соединений; избыток кратковременных соединений вызывает резкое увеличение нагрузки на ЦП и задержки. Используйте пулы соединений на стороне приложения (например, HikariCP, PgBouncer, ProxySQL).
- Определяйте размер пулов на основе количества ядер ЦП и параллелизма рабочей нагрузки, а не только памяти инстанса. Начинайте с малого и масштабируйте эмпирически.
- Для эфемерных/бессерверных вычислений коннектор Cloud SQL для конкретного языка поддерживает пул для каждой ревизии; все равно ограничивайте параллелизм, чтобы избежать «шторма соединений» после холодных стартов.
Секционирование данных и производительность
- Шардируйте большие многопользовательские схемы по клиенту или региону, чтобы уменьшить конкуренцию. По возможности изолируйте «горячих» арендаторов.
- Тщательно создавайте покрывающие индексы; избыточное индексирование замедляет запись и увеличивает объем хранилища. Проверяйте кардинальность и селективность предикатов.
- Используйте оптимистическую блокировку или SELECT FOR UPDATE для «горячих» строк; настраивайте autovacuum (PostgreSQL) или параметры InnoDB (MySQL) для устойчивых рабочих нагрузок на запись.

Распространенные режимы сбоев и способы их устранения:

Эффект «стада» (thundering herd) после перезапуска ВМ/узлов: ограничьте размеры пулов и используйте экспоненциальную выдержку.
Отставание реплики для сценариев «чтение после записи»: направляйте чтение на основной экземпляр, когда требуется согласованность на уровне сессии.
Частые переключения HA из-за «шумных соседей» или технического обслуживания: реализуйте повторные попытки для соединений и транзакций с идемпотентностью.

Планетарно-масштабируемые реляционные данные в Cloud Spanner

Cloud Spanner обеспечивает горизонтальную масштабируемость с возможностью глобальной согласованности.

Согласованность и транзакции
- Строгие чтения (strong reads) и транзакции чтения-записи обеспечивают строгую внешнюю согласованность с использованием TrueTime; коммиты ожидают короткое время для обеспечения линеаризуемости.
- Устаревшие (stale) и ограниченно устаревшие (bounded-staleness) чтения снижают задержку и улучшают доступность для рабочих нагрузок с интенсивным чтением, когда свежесть данных может быть немного ослаблена.
- Транзакции только для чтения охватывают несколько чтений по одной временной метке без блокировок; используйте их для получения согласованных срезов данных для аналитики.
Региональность, доступность и задержки
- Региональные инстансы обеспечивают высокую доступность в пределах одного региона. Мультирегиональные конфигурации (например, nam-asia-eur1) обеспечивают очень высокую доступность и низкую задержку локального чтения на разных континентах с глобально согласованными записями.
- Выбирайте конфигурации инстансов в соответствии с географией ваших пользователей; задержки записи увеличиваются с размером межконтинентального кворума.
Масштабируемость и проектирование схемы
- Spanner шардирует данные на сплиты по диапазонам первичных ключей, распределяя их по узлам. Возникновение «горячих точек» (hotspotting) происходит, когда ключи монотонно возрастают. Избегайте ключей, таких как автоинкрементные ID или постоянно возрастающие временные метки в начале ключа.
- Используйте составные первичные ключи, которые распределяют запись (например, customer_hash, customer_id, reverse_timestamp).
- Чередующиеся таблицы (interleaved tables) размещают дочерние строки вместе с родительскими для локальности данных и эффективных соединений. Используйте их, когда кардинальность дочерних элементов и доступ к ним тесно связаны с родительским элементом. Дополняйте их вторичными индексами; рассмотрите использование клаузулы STORING для уменьшения обращений к таблице.
- Мониторьте ЦП, хранилище и операции с высоким приоритетом в сравнении с операциями с наилучшим возможным результатом (best-effort); масштабируйте узлы для поддержания запаса производительности при P95 задержках.
Операционные паттерны
- Клиенты используют пулы сессий; настраивайте min/max сессий, чтобы избежать «шторма» их создания. Повторные попытки должны быть ограничены и идемпотентны; при ошибке ABORTED повторяйте транзакции чтения-записи с экспоненциальной выдержкой.
- Резервные копии легковесны и согласованы; проверяйте восстановление на отдельные инстансы. Потоки изменений (change streams) и интеграции CDC могут служить источником данных для нижестоящих систем.

Компромиссы:

Строгая глобальная запись добавляет задержку на коммит; используйте устаревшие чтения (stale reads) для критичных к UX путей с преобладанием чтения.
Чередование (interleaving) улучшает локальность данных, но может концентрировать нагрузку на запись; тестируйте на трафике, близком к производственному.

Операционные хранилища NoSQL: Firestore и Bigtable

Выбирайте модель NoSQL, соответствующую вашим шаблонам запросов и профилю пропускной способности.

Firestore (документная)
- Модель данных: коллекции содержат документы; документы могут иметь подколлекции. Моделируйте данные вокруг шаблонов запросов; избегайте глубоких каскадных записей (fan-out) в отдельные «горячие» документы.
- Доступ и транзакции: чтение документов и запросы строго согласованы в режиме Native. Используйте пакетные записи для атомарности «не более одного раза» для нескольких документов и транзакции для операций «чтение-изменение-запись» с проверкой конфликтов.
- Индексы: индексы по одному полю создаются автоматически. Составные индексы по нескольким полям необходимо определять при использовании нескольких фильтров по диапазону/неравенству или нескольких порядков сортировки. Денормализация часто используется, чтобы сделать запросы покрывающимися только индексом (index-only).
- Синхронизация клиентов: слушатели (listeners) в реальном времени передают изменения потоком; офлайн-кэши синхронизируются по семантике «побеждает последняя запись» (last-write-wins). Защищайтесь от неограниченного каскадного распространения слушателей (listener fan-out); предпочитайте курсоры запросов и фильтры.
- Ограничения и режимы отказа: скорость записи в один документ сериализуется; постоянные обновления одного документа с высоким QPS создают конфликты. Используйте сегментированные (sharded) счетчики с N поддокументами и агрегируйте данные при чтении.
Cloud Bigtable (ширококолоночная)
- Дизайн ключа строки (row-key) имеет первостепенное значение. Bigtable лексикографически разделяет строки; начальные сегменты ключа определяют возникновение «горячих точек» (hotspotting). Избегайте последовательных ключей, таких как ключи, начинающиеся с временной метки, или несегментированные идентификаторы пользователей.
- Шаблоны:
  - Обратная временная метка в ключе для чтения временных рядов: key = device#hash(device_id)#reverse_ts.
  - Хэшируйте или распределяйте по корзинам (bucket) первый компонент, чтобы распределить нагрузку при записи: bucket = crc32(user_id) % 128.
- Храните небольшие ячейки с множеством столбцов; избегайте больших строк, охватывающих несколько планшетов (tablets). Используйте несколько семейств столбцов для разделения контроля доступа и политик сборки мусора (GC).
- Пропускная способность и обслуживание:
  - Используйте несколько кластеров для репликации и региональной близости для чтения; межкластерные записи становятся согласованными в конечном счете (eventually consistent).
  - Настраивайте профили приложений и маршрутизацию; поддерживайте достаточные пулы потоков и каналов на стороне клиента.
- Сборка мусора (GC) и TTL: сборка мусора на основе версий и времени асинхронно удаляет старые ячейки; данные сохраняются до уплотнения (compaction), поэтому не полагайтесь на немедленное удаление для соблюдения нормативных сроков.

Паттерны кэширования и объектного хранения

Memorystore (Redis/Memcached)
- Стратегии кэширования:
  - Read-through (сквозное чтение): приложение извлекает данные из кэша; при промахе загружает из источника и заполняет кэш.
  - Write-through (сквозная запись): запись происходит синхронно в кэш и в источник данных.
  - Write-behind (отложенная запись): запись буферизуется в кэше и сбрасывается асинхронно; используйте с осторожностью из-за риска потери данных.
- Истечение срока действия и инвалидация:
  - Применяйте TTL, соответствующие допустимому уровню устаревания данных. Инвалидируйте ключи при изменениях в источнике истины; для агрегирующих кэшей используйте версионированные ключи, чтобы избежать лавинообразных запросов (stampedes).
  - Используйте мьютекс или механизм single-flight, чтобы предотвратить лавинообразные запросы к популярным ключам.
- Сессии: храните эфемерные сессионные данные с TTL; шифруйте значения или храните только непрозрачные токены, если данные чувствительны.
- Ограничение частоты запросов (rate limiting) с помощью Redis:
  - Фиксированное окно (Fixed-window): INCR с EXPIRE для ключа, уникального для каждой сущности.
  - Скользящее окно (Sliding-window) или «ведро с токенами» (token-bucket) для более плавных ограничений; рассмотрите использование скриптов Lua для атомарности.
- Доступность: уровень Basic не имеет отказоустойчивости; уровень Standard обеспечивает региональную высокую доступность (HA). Относитесь к кэшу как к волатильному хранилищу, а не как к авторитетному источнику данных.
Пример: простое ограничение частоты запросов по методу фиксированного окна
- Команды:
  - INCR rate:login:USER123:20260903T1000
  - EXPIRE rate:login:USER123:20260903T1000 60
Cloud Storage
- Объекты и согласованность: строгая глобальная согласованность для операций чтения, записи, перезаписи, удаления и листинга. Объекты неизменяемы (immutable); обновления создают новые поколения.
- Подписанные URL (Signed URLs): разгрузите приложение, выполняя большие загрузки/скачивания напрямую между клиентами и бакетами без проксирования. Устанавливайте короткий срок действия; ограничивайте метод, путь и заголовки контента.
- Возобновляемые загрузки (Resumable uploads): используйте для файлов >5 МБ и при нестабильных сетях; обрабатывайте ошибки 5xx/429 с усеченной экспоненциальной задержкой (truncated exponential backoff) и токенами возобновления.
- Жизненный цикл: определите правила для перехода между классами хранения, удаления старых версий и принудительного хранения. Сочетайте с версионированием объектов для безопасности во время развертывания.
- Уведомления: интегрируйте уведомления Pub/Sub для запуска последующей обработки после завершения создания/удаления объекта и включайте предварительные условия (ifGenerationMatch) для защиты от состояний гонки.
Пример: загрузка локальных файлов
- gsutil cp ./data/*.parquet gs://my-bucket/ingest/

Миграция, согласованность, секционирование и защита данных

Миграция баз данных
- Выбор между онлайн- и офлайн-миграцией: онлайн-миграция с помощью Database Migration Service для минимизации времени простоя; офлайн-миграция для простоты, когда окна обслуживания приемлемы.
- Подход с приоритетом схемы: согласуйте типы и ограничения; для Spanner рассмотрите инструменты для сопоставления схем и данных MySQL/PostgreSQL, а затем настройте ключи и индексы для распределения нагрузки.
- Параллельная работа и переключение: во время онлайн-миграции используйте двойную запись или репликацию журналов изменений (changelogs). Перед окончательным переключением проверьте количество строк, контрольные суммы и поведение критически важных запросов.
Миграции схемы и откат
- Используйте версионированные, автоматизированные миграции (например, с помощью инструмента для миграций) как часть CI/CD. Проектируйте аддитивные, обратно совместимые изменения: добавляйте столбцы и индексы, выполняйте обратное заполнение, развертывайте код, который читает/пишет в оба формата, а затем удаляйте устаревшие артефакты.
- Планируйте откат с преобразованиями данных: если развертывание кода завершается неудачей, будьте готовы отключить новые операции записи и использовать флаги функций (feature flags); избегайте деструктивных миграций, которые блокируют возможность отката.
Транзакционные и итого-согласованные рабочие процессы
- Используйте транзакции ACID, когда инварианты должны соблюдаться синхронно (перевод средств, уменьшение складских запасов).
- Отдавайте предпочтение итоговой согласованности для функций, ориентированных на пользователя и в основном на чтение, где задержка является доминирующим фактором (ленты новостей, поиск, счетчики). Внедряйте ключи идемпотентности, паттерны Outbox/Saga и повторные попытки с экспоненциальной задержкой.
- Комбинируйте подходы: фиксируйте авторитетное состояние в транзакционном хранилище; публикуйте события для итого-согласованных проекций.
Секционирование данных и управление соединениями
- Секционируйте по клиенту (tenant), географии или типу рабочей нагрузки для изоляции «горячих точек» (hotspots). Для Bigtable и Spanner кодируйте ключи секционирования в первичных ключах; для Cloud SQL используйте подход «схема на клиента» или шардирование таблиц с маршрутизаторами.
- Управляйте соединениями:
  - Cloud SQL: объединяйте в пул и повторно используйте; ограничивайте параллелизм; распределяйте «холодные» запуски во времени.
  - Spanner: повторно используйте сессии; «прогревайте» пулы при запуске; ограничивайте количество повторных попыток.
  - Memorystore: повторно используйте TCP-соединения; избегайте подключений на каждый запрос.
Защита данных, архивация, проверка восстановления и поведение при удалении
- Резервные копии и архивация:
  - Cloud SQL: автоматическое резервное копирование + восстановление на определенный момент времени (PITR); тестируйте восстановление.
  - Spanner: управляемые резервные копии; тестируйте восстановление в нерабочую среду.
  - Firestore: экспорт по расписанию в Cloud Storage; проверяйте импорт.
  - Bigtable: резервные копии и снимки; тестируйте клонирование и восстановление.
  - Cloud Storage: политики хранения, удержание объектов и единый доступ на уровне бакета для управления; архивируйте в более «холодные» классы хранения с помощью правил жизненного цикла.
- Проверка восстановления: периодически восстанавливайте данные в изолированные среды и выполняйте проверочные запросы и дымовые тесты приложения. Отслеживайте RTO/RPO в соответствии с политикой.
- Поведение при удалении:
  - Сборка мусора (GC) и жизненный цикл в Bigtable асинхронны — не обещайте немедленного стирания данных.
  - Версионирование в Cloud Storage сохраняет поколения объектов до тех пор, пока их не удалят правила жизненного цикла.
  - TTL в Firestore и удаления на основе экспорта являются асинхронными.
  - Для SLA по необратимому удалению проектируйте процессы, которые помечают данные для удаления, ставят их в очередь и проверяют факт удаления, с ведением журналов аудита.

Практический сценарий

Компания Aurora Outfitters переносит монолитную платформу электронной коммерции в Google Cloud. Им необходимо: 1) выполнить lift-and-shift миграцию MySQL для снижения рисков, 2) обрабатывать загрузку медиафайлов продуктов объемом 500 МБ, не перегружая приложение, 3) масштабировать пропускную способность на чтение для каталогов продуктов и 4) применять ограничения скорости (rate limits) для каждого пользователя во время пиковых продаж.

Подход:

Мигрировать MySQL в Cloud SQL с частным IP-адресом и региональной высокой доступностью (HA)
- Обоснование: Частный IP-адрес устраняет доступ извне и необходимость в списках разрешенных IP, упрощая безопасное подключение из GKE и Compute Engine. Региональная HA защищает от сбоев на уровне зоны; ожидаются кратковременные разрывы соединений при отработке отказа, поэтому приложение будет реализовывать логику повторных транзакций и переподключения.
Включить автоматическое резервное копирование и PITR, а также проверить восстановление
- Обоснование: Автоматические резервные копии и журналы транзакций позволяют выполнять восстановление на определенный момент времени после ошибок пользователя или приложения. Еженедельное плановое восстановление в нерабочий экземпляр подтверждает пригодность резервных копий и позволяет измерить RTO.
Добавить реплику для чтения для запросов к каталогу
- Обоснование: Перенос запросов к каталогу на реплику для чтения снижает конкуренцию за ресурсы на основном экземпляре. Приложение читает с основного экземпляра, когда требуется согласованность «запись после чтения» (корзина/оформление заказа), и с реплики для просмотра каталога, учитывая компромиссы, связанные с задержкой репликации.
Внедрить пулинг соединений на стороне приложения и ограничить параллелизм
- Обоснование: PgBouncer/HikariCP ограничивает и повторно использует соединения, предотвращая «штормы» соединений во время автомасштабирования и отработки отказа HA. Размер пулов определяется количеством ядер ЦП, а не максимальным числом подов, что предотвращает перегрузку.
Перенести загрузку медиафайлов в Cloud Storage с использованием подписанных URL и возобновляемых загрузок
- Обоснование: Приложение выдает клиентам короткоживущие подписанные URL для прямой загрузки. Возобновляемые загрузки подходят для ненадежных сетей; медиасервис прослушивает уведомления о завершении из Pub/Sub для запуска обработки. Заголовки предварительных условий (например, ifGenerationMatch) защищают от гонок перезаписи.
Внедрить Memorystore for Redis для кеширования страниц, сессий и ограничения скорости
- Обоснование: Кеши со сквозным чтением (read-through) снижают нагрузку на базу данных для страниц продуктов с TTL, согласованным с частотой обновлений. Данные сессий хранятся в Redis как эфемерные с коротким TTL; состояние приложения остается в Cloud SQL. Стратегия токенов с фиксированным окном использует INCR/EXPIRE для ограничения количества запросов от пользователя. Кеш рассматривается как неавторитетный; приложение устойчиво к потере кеша и заполняет его при промахах.
Подготовить поэтапный переход на Cloud Bigtable для функций просмотра каталога с высокой пропускной способностью
- Обоснование: По мере роста трафика денормализованные, оптимизированные для чтения представления каталога переносятся в Bigtable. Ключи строк спроектированы как bucket#category#reverse_ts для распределения операций записи и поддержки списков, упорядоченных по времени, без создания «горячих точек».
Установить процедуры миграции схемы и отката
- Обоснование: Миграции являются аддитивными: добавляются столбцы/индексы, выполняется обратное заполнение с помощью идемпотентных заданий, развертывается код, который читает/пишет в оба формата, а затем старые поля удаляются. Флаги функций (feature flags) защищают новые пути выполнения кода; откат отключает запись в новые поля без деструктивных DDL-операций.
Установить политики жизненного цикла и защиты данных
- Обоснование: Бакеты Cloud Storage используют правила жизненного цикла для перемещения миниатюр в более «холодное» хранилище и удаления устаревших временных загрузок. Резервные копии Cloud SQL и (по мере внедрения) Spanner/Bigtable регулярно восстанавливаются для проверки. Журналы аудита фиксируют рабочие процессы удаления; в документации по соответствию требованиям признается, что сборка мусора (GC) в Bigtable является асинхронной.
Внедрить повторные попытки на стороне клиента и сервера с усеченной экспоненциальной задержкой
- Обоснование: Cloud Storage может возвращать ошибки 429/5xx во время всплесков нагрузки; экспоненциальная задержка сглаживает нагрузку и снижает частоту ошибок. В операциях с базами данных и кешем используются ключи идемпотентности для обеспечения безопасных повторных попыток, особенно во время отработки отказа и кратковременных сбоев в сети.

Этот план обеспечивает немедленное снижение рисков за счет использования Cloud SQL с частным подключением и HA, поддерживает отзывчивость и экономичность приложения с помощью кеширования и загрузок по подписанным URL, а также создает четкий путь к масштабированию пропускной способности на чтение и устойчивости данных по мере роста трафика.

← Проектирование API · Все домены · Идентификация →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →