Amazon DVA-C02: Amazon DynamoDB и проектирование NoSQL — Руководство по подготовке

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Часть AWS Developer Associate DVA-C02 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.

Моделирование данных и шаблоны доступа

Проектирование DynamoDB начинается с шаблонов доступа: каждый запрос должен соответствовать первичному ключу, глобальному вторичному индексу (GSI) или локальному вторичному индексу (LSI). Дизайн таблицы определяется тем, как приложение читает и записывает элементы, а не тем, как была бы структурирована реляционная схема. Выбирайте ключ раздела с высокой кардинальностью, чтобы избежать «горячих» разделов, и используйте составной первичный ключ (ключ раздела + ключ сортировки), когда вам нужны диапазонные запросы. Операции Query требуют точного совпадения по ключу раздела и могут использовать необязательное выражение KeyConditionExpression для ключа сортировки. Для SDK предпочитайте абстракции DynamoDB Document: используйте DynamoDBDocumentClient с AWS SDK for JavaScript v3 (marshall/unmarshall выполняется за вас) или DynamoDB Enhanced Client в Java для сопоставления объектов с атрибутами. Реализуйте шаблоны с одной таблицей только тогда, когда шаблоны чтения используют общие ключи, и вы можете кодировать типы элементов через атрибут типа. Используйте разреженные GSI для создания вторичных путей доступа, записывая атрибуты только в те элементы, которым они нужны. Распространенная ошибка — злоупотребление операцией Scan: сканирование больших таблиц является дорогостоящим и разбивается на страницы (LastEvaluatedKey); предпочитайте Query с ProjectionExpression для снижения потребления RCU. Для условных записей используйте UpdateItem с ConditionExpression или TransactWriteItems для атомарности операций с несколькими элементами; обрабатывайте исключение ConditionalCheckFailedException и используйте откат с джиттером.

Индексы, запросы и транзакционные шаблоны

Локальные вторичные индексы создаются только при создании таблицы, используют тот же ключ раздела, что и базовая таблица, и потребляют единицы пропускной способности таблицы на чтение для запросов. В то же время GSI можно добавлять после создания таблицы, они имеют независимую пропускную способность или тарификацию по требованию и позволяют использовать другие ключи разделов. Вызовы Query используют KeyConditionExpression и ExpressionAttributeNames/Values; выражения проекции (projection expressions) уменьшают объем передаваемых данных. GSI по умолчанию обеспечивают согласованность в конечном счёте и влекут за собой дополнительные затраты на запись, поскольку каждая запись в базовую таблицу, которая проецирует индексируемые атрибуты, создает соответствующие записи в GSI — планируйте WCU соответствующим образом и отслеживайте ConsumedWriteCapacityUnits для индекса. Для строгой согласованности используйте GetItem или Query с параметром ConsistentRead=true для базовой таблицы (GSI не поддерживают строго согласованные чтения). Транзакции (TransactWriteItems и TransactGetItems) гарантируют атомарность для 25 элементов или 4 МБ данных; используйте ReturnValuesOnConditionCheckFailure для анализа сбоев. BatchWriteItem и BatchGetItem ограничены 25 и 100 элементами соответственно и не являются транзакционными; код должен обрабатывать UnprocessedItems с помощью повторных попыток с экспоненциальной задержкой. Частая ошибка — забывать о стоимости и последствиях согласованности в конечном счёте при миграции реляционных соединений в GSI.

Режимы пропускной способности, настройка производительности и устранение неполадок

Выбирайте между подготовленной (provisioned) и по требованию (on-demand) пропускной способностью в зависимости от предсказуемости нагрузки: подготовленная с Auto Scaling (Application Auto Scaling для DynamoDB) дает контроль над RCU/WCU и стоимостью для стабильных рабочих нагрузок, в то время как режим по требованию упрощает обработку пикового трафика без планирования пропускной способности, но по более высокой цене за запрос. Включите Auto Scaling с целевым использованием и несколькими политиками масштабирования; отслеживайте метрики CloudWatch, такие как ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests, SuccessfulRequestLatency, SystemErrors и ConditionalCheckFailedRequests, чтобы обнаруживать горячие точки и троттлинг. Используйте адаптивную пропускную способность для смягчения троттлинга по одному ключу, но не полагайтесь на нее — проектируйте для равномерного распределения ключей. Для нагрузок с преобладанием чтения рассмотрите DAX для чтения с микросекундной задержкой или кеширование с помощью Amazon ElastiCache; для нагрузок с преобладанием записи используйте шардирование записи (с помощью префиксов или сегментов) для распределения записей по разделам. Устраняйте неполадки, анализируя исключения ProvisionedThroughputExceededException и реализуя экспоненциальную задержку со случайным разбросом (jitter) в клиентах SDK, включите CloudWatch Contributor Insights для поиска горячих ключей и используйте Parallel Scan для крупной одноразовой аналитики с сегментированными рабочими процессами. Помните об ограничении размера элемента (400 КБ) и о том, что большие элементы увеличивают потребление RCU/WCU; при необходимости разделяйте большие двоичные объекты (blobs), сохраняя их в S3, а метаданные — в DynamoDB.

Потоки, интеграции, резервное копирование и лучшие практики эксплуатации

DynamoDB Streams фиксируют изменения на уровне элементов (INSERT, MODIFY, REMOVE) в порядке ключа раздела и напрямую интегрируются с Lambda через сопоставление источника событий (настройте startingPosition как TRIM_HORIZON или LATEST, задайте batchSize и maximumBatchingWindowInSeconds, а также отрегулируйте bisectBatchOnError и maximumRetryAttempts). Для надежной обработки используйте Lambda с очередью недоставленных сообщений (Dead-Letter Queue) на базе SQS или SNS, либо направляйте записи потока в Kinesis или Kinesis Data Firehose для аналитики. Включите Time To Live (TTL) для автоматического удаления элементов по истечении срока их жизни; учтите, что удаления через TTL обрабатываются в конечном счете (eventually processed) и на них не следует полагаться для обеспечения немедленной согласованности. Используйте восстановление на определенный момент времени (Point-in-Time Recovery, PITR) и резервные копии по запросу для аварийного восстановления; для обеспечения доступности в нескольких регионах используйте Global Tables для репликации изменений между регионами. Применяйте IAM-роли с минимальными привилегиями к сервисам и предоставляйте Lambda-функциям только необходимые действия, такие как dynamodb:Query, dynamodb:PutItem, dynamodb:UpdateItem, dynamodb:GetItem, dynamodb:DescribeStream и dynamodb:ListStreams. Распространенные операционные ошибки включают отсутствие логики повторных попыток с экспоненциальной задержкой (retry/backoff) в потребителях, неадекватное планирование пропускной способности GSI и отсутствие мониторинга метрики IteratorAge для потоков с целью обнаружения задержек; используйте CloudWatch Logs и X-Ray для трассировки сквозной задержки (end-to-end latency).

Практическая задача: Пример использования

Сценарий: AcmeMedia использует каталог метаданных в одной таблице DynamoDB в регионе us-east-1, содержащей десятки миллионов элементов. Новому конвейеру обработки изображений требуется выполнять запросы с низкой задержкой по photographerId и диапазону uploadTimestamp, а последующие потребители Lambda должны надежно обрабатывать изменения.

Задача: Добавить эффективный способ запроса по photographerId и диапазону временных меток без изменения дизайна таблицы, обеспечить обработку записей потока последующими Lambda-функциями с семантикой “хотя бы один раз” (at-least-once) и избежать “горячих” разделов для фотографов с большим количеством работ.

Рекомендуемый подход:

1. Создайте GSI с именем photographer-gsi, где ключом раздела будет photographerId, а ключом сортировки — uploadTimestamp; используйте API-вызов UpdateTable или консоль, чтобы добавить GSI, и укажите режим оплаты ProvisionedThroughput или On-Demand через UpdateTable, а также настройте мониторинг IndexStatus.
2. При записи элементов включайте атрибуты photographerId и uploadTimestamp, чтобы проекция индекса была разреженной (sparse); выберите ProjectionType=INCLUDE с неключевыми атрибутами, необходимыми для запросов, чтобы сократить расходы на хранение и запись.
3. Включите DynamoDB Streams (со статусом ENABLED) для таблицы и создайте сопоставление источника событий для Lambda с параметрами: startingPosition=TRIM_HORIZON, настроенный batchSize (например, 100), bisectBatchOnError=true, maximumRetryAttempts=2, а также укажите очередь SQS в качестве назначения для недоставленных сообщений (Dead-Letter Destination) в конфигурации Lambda-функции.
4. Реализуйте повторные попытки на стороне клиента SDK с использованием джиттера (используйте встроенную в AWS SDK стратегию повторов) и примените шардирование записи (write sharding), если один и тот же photographerId все еще вызывает троттлинг (добавляйте префикс к photographerId из N сегментов при записи и удаляйте его на стороне клиента при чтении).

Обоснование: Добавление GSI предоставляет необходимый шаблон доступа без изменения основного первичного ключа; проецирование только необходимых атрибутов снижает стоимость записи в GSI. Связка Streams и Lambda с DLQ и механизмами повторных попыток обеспечивает надежную обработку “хотя бы один раз”, в то время как шардирование защищает от “горячих” разделов, возникающих из-за трафика с высокой кардинальностью.

← Amazon API Gateway и интеграция приложений · Все домены · CloudFormation и инфраструктура как код (SAM →

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

Просмотреть Amazon →