Последняя проверка: май 2026 г.
Сжатый справочник архитектурных шаблонов, проверяемых на экзамене PCDE. Читайте сверху вниз или переходите к нужному разделу.
Глобальная платформа электронной коммерции, требующая ACID-транзакций, строгой согласованности и 99.999% доступности на нескольких континентах.
Cloud Spanner с многорегиональной конфигурацией (например, nam-eur-asia).
Почему: Spanner - единственный управляемый сервис GCP, обеспечивающий глобально распределенные, строго согласованные ACID-транзакции в масштабе с SLA 99.999%.
Миграция крупной, высокопроизводительной Oracle OLTP базы данных со сложными хранимыми процедурами и потребностями в аналитических запросах.
AlloyDB for PostgreSQL.
Почему: AlloyDB предлагает превосходную производительность PostgreSQL, функции совместимости с Oracle и columnar engine для ускорения аналитических запросов (HTAP) без влияния на транзакционные рабочие нагрузки.
Высокопроизводительный (миллионы операций в секунду) прием временных рядов данных (например, IoT, журналы), требующий чтений с низкой задержкой и автоматического истечения срока действия данных.
Cloud Bigtable с дизайном ключа строки `(entity_id)#(reverse_timestamp)` и политикой сбора мусора.
Почему: Bigtable разработан для крупномасштабных рабочих нагрузок ключ/значение с низкой задержкой. Обратная метка времени в ключе строки совместно размещает недавние данные для эффективного сканирования. Сбор мусора управляет TTL.
Мобильное или веб-приложение, требующее гибкой схемы, синхронизации данных в реальном времени с клиентами и поддержки работы в автономном режиме.
Firestore в Native Mode.
Почему: Firestore специально разработан для этого паттерна serverless app backend, предоставляя слушателей в реальном времени и автономное сохранение через свои клиентские SDKs из коробки.
Поиск схожести в больших масштабах (более 10 миллионов векторов) для приложений AI/ML (например, RAG, рекомендации), требующий задержки менее 100 мс.
AlloyDB for PostgreSQL с расширением pgvector и индексом ScaNN.
Почему: AlloyDB интегрирует высокопроизводительный алгоритм Google ScaNN для поиска ближайших соседей (ANN), превосходящий стандартные реализации векторного поиска в масштабе.
Разработка схемы Cloud Spanner для рабочей нагрузки с большим количеством записей, чтобы предотвратить "горячие точки" на одном сервере.
Проектируйте первичные ключи, которые не используют монотонно возрастающие значения (например, последовательные ID, метки времени) в качестве первой части ключа. Вместо этого используйте UUIDs, хешированные значения или битовые инвертированные последовательности.
Почему: Spanner распределяет данные лексикографически по первичному ключу. Последовательные ключи направляют все записи в один сплит, создавая "горячую точку". Случайно распределенные ключи распределяют записи по всем сплитам.
Схема Spanner имеет сильную связь "родитель-потомок" (например, Customers и Orders), и запросы часто извлекают родителя со всеми его потомками.
Используйте чередующиеся таблицы (interleaved tables), определяя дочернюю таблицу с `INTERLEAVE IN PARENT`.
Почему: Чередование физически размещает дочерние строки рядом с родительской строкой в хранилище. Это делает соединения "родитель-потомок" чрезвычайно эффективными, поскольку они превращаются в высокооптимизированное сканирование диапазона в одном сплите.
Отслеживание местоположения в реальном времени для огромного автопарка (более 50 тыс. записей/сек) с запросами для поиска транспортных средств в определенной географической области.
Cloud Bigtable с ключом строки, предваренным GeoHash местоположения транспортного средства.
Почему: Bigtable обрабатывает экстремальную пропускную способность записи. Кодирование GeoHash преобразует 2D-координаты в 1D-строку, где префиксы представляют географическую близость, что позволяет эффективно сканировать геопространственные диапазоны.
Хранение и анализ данных петабайтного масштаба (например, геномные данные, журналы) с помощью сложных аналитических SQL-запросов.
Храните необработанные данные в Cloud Storage и запрашивайте их непосредственно из BigQuery с использованием внешних таблиц, или загружайте в собственное хранилище BigQuery.
Почему: BigQuery - это serverless хранилище данных, созданное для аналитики петабайтного масштаба. Разделение хранения и вычислений обеспечивает беспрецедентную производительность запросов и экономическую эффективность для OLAP-нагрузок.
Высокодоступный in-memory кэш для сложных структур данных (хеши, множества) с возможностями pub/sub для инвалидации кэша.
Memorystore for Redis Standard Tier с репликами для чтения.
Почему: Standard Tier обеспечивает SLA 99.9% с автоматическим переключением при сбое. Redis поддерживает сложные типы данных и pub/sub, в отличие от Memcached. Реплики для чтения могут масштабировать пропускную способность чтения.
Разработка многопользовательского SaaS-приложения на Spanner, требующего сильной изоляции данных и гарантий производительности для каждого клиента.
Используйте tenant_id в качестве первого компонента первичного ключа для всех таблиц. Для более сильной изоляции используйте модель "база данных на клиента" в рамках одного экземпляра Spanner.
Почему: Префикс tenant_id естественным образом совместно размещает все данные одного клиента, оптимизируя запросы и позволяя Spanner разделять данные по клиентам. Модель "база данных на клиента" обеспечивает сильнейшую логическую изоляцию.
База данных Cloud SQL испытывает медленную производительность запросов и высокое использование CPU.
Используйте Query Insights для выявления наиболее ресурсоемких запросов, анализа их планов выполнения и определения отсутствующих индексов или неэффективных паттернов.
Почему: Query Insights - это основной, встроенный инструмент для диагностики производительности запросов в Cloud SQL. Он визуализирует нагрузку запросов, идентифицирует события ожидания и помогает определить первопричину без сторонних инструментов.
Организации требуется единая панель мониторинга и набор политик оповещения для десятков экземпляров баз данных, распределенных по нескольким проектам GCP.
Создайте рабочую область Cloud Monitoring в центральном проекте и настройте ее "metrics scope" так, чтобы она включала все проекты, содержащие экземпляры баз данных.
Почему: Metrics scopes позволяют одной рабочей области Monitoring агрегировать и отображать метрики из нескольких проектов, предоставляя унифицированное представление без дублирования данных или сложной конфигурации.
Необходимо предоставлять и управлять экземплярами Cloud SQL в средах разработки, тестирования и производства последовательно и с контролем версий.
Используйте Terraform с провайдером Google Cloud. Определите модуль Cloud SQL и используйте отдельные файлы `.tfvars` для каждой среды.
Почему: Terraform предоставляет Infrastructure as Code (IaC), обеспечивая повторяемые, проверяемые и версионированные развертывания. Это позволяет избежать ошибок ручной конфигурации и обеспечивает согласованность между средами.
Подрядчику требуется временный расширенный доступ к базе данных, который должен быть автоматически отозван через 4 часа.
Предоставьте необходимую роль IAM с IAM Condition, использующей выражение, основанное на времени (`request.time < timestamp(...)`).
Почему: IAM Conditions предоставляют нативный, безопасный способ предоставления ограниченного по времени доступа без ручной очистки, которая подвержена ошибкам. Доступ автоматически отклоняется после истечения метки времени.
Политика безопасности требует, чтобы все шифрование дисков баз данных использовало ключи, управляемые клиентом (CMEK), с контролируемой ротацией.
Настройте экземпляр Cloud SQL или AlloyDB для использования ключа из Cloud KMS. Настройте автоматическую ротацию для ключа KMS.
Почему: CMEK обеспечивает контроль и возможность аудита над ключами, используемыми для шифрования данных в состоянии покоя. Cloud KMS бесшовно управляет жизненным циклом ключей, включая автоматическую ротацию.
Соответствие требованиям требует захвата всех SQL-запросов, выполненных на экземпляре Cloud SQL for PostgreSQL, с сохранением журналов в течение 7 лет.
Включите расширение `pgaudit` на экземпляре. Настройте Cloud Audit Logs для Data Access. Создайте log sink из Cloud Logging в BigQuery для долгосрочного хранения и анализа.
Почему: pgaudit обеспечивает детальный аудит на уровне SQL. Перенаправление журналов в BigQuery - это стандартный, экономически эффективный паттерн для долгосрочного, доступного для поиска хранения журналов, выходящего за рамки значений по умолчанию Cloud Logging.
Аналитикам данных необходимо выполнять ресурсоемкие аналитические запросы к производственным данным Cloud SQL, не влияя на транзакционную нагрузку.
Создайте реплику для чтения и направляйте все аналитические запросы к ней. Для более сложной аналитики используйте федеративные запросы BigQuery к реплике для чтения.
Почему: Реплика для чтения полностью изолирует аналитический трафик чтения от основного экземпляра, защищая производительность OLTP. Федерация позволяет использовать мощный движок BigQuery без отдельного ETL-конвейера.
Кластер Bigtable демонстрирует неравномерную загрузку CPU: некоторые узлы сильно загружены, в то время как другие простаивают, что указывает на узкое место в производительности.
Используйте инструмент Key Visualizer в Cloud Console для анализа шаблонов доступа и выявления конкретных диапазонов ключей строк, которые слишком часто используются ("горячие точки").
Почему: Key Visualizer - это специально разработанный диагностический инструмент для проблем с производительностью Bigtable. Он предоставляет тепловую карту доступа к ключам, что упрощает идентификацию "горячих точек", требующих решения путем перепроектирования схемы.
Необходимо реплицировать изменения из OLTP базы данных Cloud SQL в хранилище данных BigQuery практически в реальном времени.
Используйте Datastream для настройки потока Change Data Capture (CDC) из исходного экземпляра Cloud SQL непосредственно в BigQuery.
Почему: Datastream - это управляемый сервис CDC с низкой задержкой, который считывает журналы базы данных, минимизируя влияние на источник. Он обрабатывает дрейф схемы и надежно доставляет изменения в BigQuery.
Приложение Cloud Run исчерпывает соединения с базой данных из-за быстрого масштабирования во время пиков трафика.
Разверните Cloud SQL Auth Proxy как sidecar-контейнер и настройте его для пулинга соединений (или используйте его с выделенным пулером, таким как PgBouncer).
Почему: Serverless-платформы могут масштабироваться до тысяч экземпляров, перегружая лимиты подключений к базе данных. Пулер соединений мультиплексирует эти многочисленные, временные соединения приложений в небольшой, стабильный набор соединений базы данных.
Миграция большой (5 ТБ) локальной базы данных MySQL в Cloud SQL for MySQL с максимальным временем простоя 30 минут.
Используйте Database Migration Service (DMS) для настройки задачи непрерывной репликации. DMS выполняет начальную загрузку, а затем передает изменения до момента переключения.
Почему: DMS - это управляемое решение для миграций с минимальным временем простоя. Непрерывная репликация означает, что единственное время простоя - это время, необходимое для остановки записей, ожидания окончательной синхронизации и перенаправления приложения на новую базу данных.
Миграция базы данных Oracle в AlloyDB for PostgreSQL, включая сложные хранимые процедуры PL/SQL.
Используйте DMS для миграции данных. Используйте инструменты преобразования схем (например, Ora2Pg или DMS Schema Conversion) для преобразования схем и PL/SQL в PL/pgSQL, с последующим ручным просмотром и тестированием.
Почему: Гетерогенные миграции требуют как миграции данных (обрабатывается DMS), так и преобразования схемы/кода. Автоматизированные инструменты обрабатывают около 80% преобразования, но ручные усилия всегда требуются для специфических функций Oracle.
Необходимо проверить целостность и полноту данных после миграции базы данных из локального центра обработки данных в Google Cloud.
Используйте инструмент Data Validation Tool (DVT с открытым исходным кодом). Настройте его для сравнения количества строк, агрегаций на уровне столбцов (min, max, sum) и хешей на уровне строк между источником и целью.
Почему: DVT предоставляет комплексную, масштабируемую и настраиваемую платформу для проверки данных, которая выходит за рамки простого подсчета строк, выявляя тонкие проблемы повреждения или преобразования данных.
Миграция шардированного MySQL-приложения в единую, глобально согласованную базу данных.
Используйте несколько параллельных заданий Dataflow для одновременной миграции каждого шарда в единую базу данных Cloud Spanner. Перепроектируйте схему, чтобы исключить необходимость шардирования на уровне приложения.
Почему: Spanner разработан для замены сложных шардированных архитектур. Подход параллельной миграции с Dataflow является наиболее эффективным по времени способом консолидации больших, шардированных наборов данных в Spanner.
Миграция базы данных SQL Server, использующей Windows Authentication (Active Directory), в Cloud SQL for PostgreSQL.
Интегрируйте Cloud SQL с Cloud Identity, используя аутентификацию базы данных IAM. Синхронизируйте группы AD с Google Groups через GCDS и сопоставьте роли базы данных с этими группами.
Почему: Этот подход реплицирует централизованную, групповую модель контроля доступа AD в облачной среде, избегая ручного управления пользователями/паролями и используя существующие структуры идентификации.
Миграция приложения из Amazon DynamoDB в Cloud Bigtable.
Сопоставьте составной первичный ключ DynamoDB (partition key + sort key) с конкатенированным ключом строки Bigtable, разделенным разделителем (например, `partitionKey#sortKey`).
Почему: Такой дизайн ключа строки сохраняет возможности запросов составного ключа DynamoDB, позволяя эффективно выполнять поиски по префиксу partition key и сканирования диапазонов по части sort key.
Приложение, подключающееся к высокодоступному экземпляру Cloud SQL, должно выдерживать сбой зоны без ручного вмешательства.
Подключайтесь к базе данных, используя Cloud SQL Auth Proxy с именем подключения экземпляра (project:region:instance), а не статический IP-адрес.
Почему: IP-адрес экземпляра изменяется во время отработки отказа. Auth Proxy и имя подключения экземпляра предоставляют стабильную конечную точку, которая автоматически разрешается в IP-адрес текущего основного экземпляра.
Глобальное приложение Spanner имеет пользователей в Северной Америке и Азии. Записи в основном происходят из Северной Америки, но азиатским пользователям нужны чтения с низкой задержкой.
Используйте многорегиональную конфигурацию с ведущим регионом в Северной Америке (`nam*`). Чтения в Азии будут обслуживаться локальными репликами только для чтения.
Почему: Записи в Spanner маршрутизируются через ведущий регион, поэтому размещение его рядом с источником записи минимизирует задержку записи. Реплики для чтения в других регионах обеспечивают низкую задержку чтения для глобально распределенных пользователей.
Приложение, использующее AlloyDB, имеет соотношение чтений к записям 10:1 и нуждается в масштабировании для обработки высокого трафика чтения, сохраняя при этом доступность 99.99%.
Настройте основной экземпляр с высокой доступностью и добавьте несколько экземпляров пула чтения. Направляйте трафик чтения в пул чтения.
Почему: Высокая доступность AlloyDB обеспечивает SLA 99.99%. Экземпляры пула чтения предназначены для горизонтального масштабирования чтения, перенаправляя трафик с основного экземпляра на выделенные узлы, оптимизированные для чтения.
Экземпляр Cloud SQL с SSD-хранилищем, чувствительный к задержкам, имеет недостаточную производительность ввода-вывода.
Увеличьте объем выделенного хранилища экземпляра.
Почему: В Cloud SQL как IOPS чтения, так и записи линейно масштабируются с объемом выделенного постоянного дискового хранилища. Увеличение размера диска - это прямой способ увеличить доступные IOPS.
Необходимо развернуть рискованное изменение схемы в критически важной базе данных Cloud SQL с возможностью быстрого отката.
Создайте реплику для чтения производственного (синего) экземпляра. Повысьте реплику до автономного экземпляра (зеленого), примените и проверьте изменения схемы. Затем перенаправьте трафик приложения на зеленый экземпляр. Оставьте синий экземпляр работающим для отката.
Почему: Этот паттерн позволяет полностью протестировать изменения на копии данных производственного масштаба, не влияя на работающую систему. Трафик может быть переключен мгновенно, а откат так же прост, как перенаправление трафика обратно на синий экземпляр.
Необходимо ежеквартально тестировать план аварийного восстановления базы данных, не затрагивая производственную среду.
Создайте временный тестовый экземпляр, восстановив его из недавней производственной резервной копии. Выполните задокументированные процедуры DR на этом тестовом экземпляре, включая имитацию переключения при сбое и тесты повторного подключения приложения.
Почему: Тестирование на восстановленной резервной копии обеспечивает реалистичную среду для проверки RTO/RPO и процедур восстановления без риска вызвать сбой в производстве.
Сервису Cloud Run необходимо безопасно подключиться к экземпляру Cloud SQL без прохождения трафика через публичный интернет.
Настройте Cloud SQL с приватным IP-адресом. Создайте коннектор Serverless VPC Access в том же VPC и настройте сервис Cloud Run для маршрутизации трафика через него.
Почему: Это стандартный, безопасный паттерн для подключения serverless-вычислений к ресурсам, нативным для VPC. Коннектор соединяет serverless-среду и ваш VPC, сохраняя весь трафик в частной сети Google.
Добавление нового, не допускающего NULL значений столбца в массивную, активно используемую таблицу Cloud Spanner без простоя.
1. Добавьте столбец как допускающий NULL. 2. Обновите код приложения для записи в новый столбец. 3. Заполните существующие строки пакетами с помощью Dataflow. 4. После заполнения измените столбец на NOT NULL.
Почему: Этот многошаговый процесс является стандартным паттерном изменения схемы онлайн для больших таблиц. Он позволяет избежать блокировки таблицы на длительное время или выполнения массовой, влияющей на производительность операции заполнения в одной транзакции.