Amazon SAA-C03: Базы данных и кеширование — Руководство по подготовке

By Laurynas Brazys · 19 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

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

Amazon RDS: Управляемые реляционные движки

Amazon RDS предоставляет шесть управляемых движков — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server и Amazon Aurora (совместимый с MySQL и PostgreSQL), — абстрагируя установку исправлений, резервное копирование, топологию репликации и обработку отказов. Выбор движка определяет лицензирование, семантику резервного копирования и доступность функций: Oracle и SQL Server предлагают варианты BYOL (Bring Your Own License) и License Included (лицензия включена), SQL Server поддерживает до пяти реплик чтения через нативную репликацию, а для реплик чтения Oracle требуется Enterprise Edition с Active Data Guard.

Две функции RDS, наиболее активно используемые для обеспечения доступности и масштабирования — и которые чаще всего путают, — это развертывания Multi-AZ и реплики чтения. Они ортогональны, дополняют друг друга и не являются взаимозаменяемыми.

Multi-AZ создает синхронную резервную реплику во второй зоне доступности. Каждая операция записи фиксируется как на основном, так и на резервном экземпляре перед подтверждением, что обеспечивает RPO фактически равный нулю и RTO в 60–120 секунд при автоматическом переключении. Резервный экземпляр не принимает трафик — он существует исключительно для отказоустойчивости. Когда основной экземпляр выходит из строя, нарушается работа зоны доступности или обслуживание требует перезапуска, RDS переключает CNAME в DNS на резервный экземпляр, и приложения прозрачно переподключаются через ту же конечную точку. Multi-AZ — это самое простое решение для устранения единой точки отказа в одной зоне доступности: это переключатель в конфигурации, не требующий изменений в схеме или приложении и сохраняющий конечную точку. Более новая опция, кластерное развертывание Multi-AZ, представляет собой топологию из трех узлов (один для записи, два читаемых резервных) с использованием полусинхронной репликации с задержкой фиксации транзакций около одной секунды, что обеспечивает высокую доступность и ограниченную разгрузку по чтению.

Реплики чтения используют асинхронную репликацию на основе собственного механизма движка (binlog в MySQL, потоковая передача WAL в PostgreSQL). Это правильный инструмент для масштабирования чтения — аналитические запросы, отчетные дашборды, нерегламентированные SELECT-запросы, — которые в противном случае привели бы к исчерпанию ресурсов OLTP на основном экземпляре. Классический сценарий: база данных обработки заказов перестает отвечать, потому что сотрудники запускают длительные отчеты в конце месяца. Добавление реплики чтения и направление на ее конечную точку инструмента отчетности изолирует аналитическую нагрузку без увеличения мощности основного экземпляра. Реплики чтения могут быть межрегиональными и могут быть вручную повышены до автономных баз данных, но это повышение никогда не происходит автоматически, и любые транзакции, которые не были реплицированы на момент сбоя, теряются.

В этой области часто встречаются две ловушки. Во-первых, рассматривать реплики чтения как решение для высокой доступности неверно по нескольким причинам: репликация асинхронна (возможна потеря данных), нет автоматического повышения, конечная точка меняется при повышении, а незавершенные транзакции теряются. Если в архитектуре обещается «нулевая потеря данных» и в качестве цели для переключения при сбое указывается реплика чтения, это обещание ложно. Во-вторых, создание Multi-AZ для обслуживания трафика чтения — это пустая трата денег, потому что в стандартной топологии резервный экземпляр не доступен для чтения. Multi-AZ решает проблему доступности; реплики чтения решают проблему масштабирования чтения; часто требуется и то, и другое.

Реплики чтения также никак не помогают в масштабировании записи — каждая запись по-прежнему поступает на основной экземпляр, и реплики должны ее воспроизвести. Для масштабирования записи используется шардирование, переход на Aurora (с разделенным хранилищем) или перепроектирование в сторону DynamoDB.

Правильный подбор размера реплик чтения

Реплика не обязана соответствовать классу инстанса основного экземпляра. Основной экземпляр обрабатывает полную нагрузку на запись плюс чтение; реплика обрабатывает только те операции чтения, которые на нее поступают. Сочетание основного экземпляра db.r6i.4xlarge с репликой db.r6i.large для ночной задачи по формированию отчетов вполне разумно — при условии, что реплика успевает обрабатывать I/O репликации. Методология такова: измерьте фактическую загрузку ЦП, памяти и задержку репликации (replica lag) на реплике, а затем подберите размер под эту нагрузку. Единственное предостережение: если вы планируете повысить реплику до основного экземпляра во время аварийного восстановления, она должна быть рассчитана на обработку нагрузки на запись. Реплики недостаточного размера не подходят для повышения.

Развертывания Blue/Green и хранилище

Развертывания RDS Blue/Green создают полную промежуточную копию производственной среды (зеленую), которая синхронизируется с помощью логической репликации. Вы можете обновить версию движка, изменить группы параметров или схемы на зеленой среде, протестировать ее и переключиться менее чем за минуту с автоматическим переименованием конечной точки. Это устраняет классический риск обновления «на месте», когда сбой при обновлении мажорной версии вынуждает выполнять откат из снимка.

Выбор хранилища так же важен, как и класс инстанса для OLTP-систем с высокой нагрузкой на запись. Классификация gp3/io2:

Улучшение gp3 по сравнению с gp2 заключается в отделении IOPS от размера — вам больше не нужно избыточно выделять емкость ради производительности. Выбирайте io2, когда устойчивый уровень IOPS превышает максимум для gp3 или когда требуется долговечность 99,999%. Multi-Attach позволяет одному тому io2 подключаться к 16 инстансам Nitro, но файловая система или приложение должны поддерживать работу в кластере; это не замена репликации. Скрытая ловушка, ведущая к простою: выделение хранилища фиксированного размера без включенного автоматического масштабирования хранилища или без алерта CloudWatch на метрику FreeStorageSpace. Когда свободное место заканчивается, RDS переходит в состояние storage-full и отклоняет операции записи.

Amazon Aurora: Архитектура и эндпоинты

Aurora реализует заново уровень хранения данных для MySQL и PostgreSQL в виде распределенного, лог-структурированного тома с шестикратной репликацией, охватывающего три зоны доступности (AZ). Вычислительные узлы не хранят состояние относительно хранилища, поэтому реплика Aurora читает данные из того же базового тома, что и записывающий узел, вместо воспроизведения лога. Задержка репликации обычно составляет 10–20 мс, в отличие от секунд для стандартных реплик RDS, а кластер поддерживает до 15 реплик, которые могут быть повышены до записывающего узла примерно за 30 секунд.

Aurora предоставляет четыре типа эндпоинтов:

Пользовательские эндпоинты важны, когда реплики разнородны. Если три из шести реплик имеют тип db.r6g.8xlarge для аналитической отчетности, а остальные обслуживают OLTP-чтения, общий эндпоинт для чтения будет периодически направлять запросы отчетности на меньшие узлы, снижая предсказуемость. Пользовательский эндпоинт, ограниченный только большими репликами, обеспечивает детерминированную изоляцию рабочих нагрузок:

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

Обратите внимание, что TTL для DNS-записей эндпоинтов Aurora составляет 5 секунд; кэширование строк подключения на более длительное время нарушает механизм отказоустойчивости.

Aurora Auto Scaling добавляет и удаляет реплики чтения (readers) на основе целевых метрик CPU или количества подключений. Это канонический ответ для непредсказуемых, интенсивно использующих чтение рабочих нагрузок, которые должны оставаться высокодоступными:

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

Когда реплики чтения RDS MySQL не могут поддерживать задержку репликации менее одной секунды при пиковой нагрузке, решение с минимальными изменениями в коде — мигрировать на Aurora MySQL. Строки подключения почти не изменятся, а репликация на уровне хранилища устранит эту задержку.

Aurora Serverless v2 и клонирование

Aurora Serverless v2 масштабирует вычислительные ресурсы вертикально с высокой гранулярностью с помощью Aurora Capacity Units (ACU, по 2 ГиБ памяти каждая) примерно за полсекунды, не разрывая сессии. Он подходит для переменных рабочих нагрузок с известным базовым потреблением памяти — например, для миграции локальной базы данных MySQL, которая всегда потребляет не менее 2 ГиБ. Установите минимум в 1 ACU и максимум в 32 ACU, и кластер будет гибко адаптироваться без администрирования. Provisioned Aurora остается предпочтительным, когда нагрузка стабильна и предсказуема, поскольку Serverless v2 имеет наценку за каждый ACU.

Клонирование Aurora создает новый кластер, который использует страницы хранения исходного кластера по принципу copy-on-write (копирование при записи). Клоны создаются за секунды и не стоят ничего, пока данные не начинают расходиться, что делает их идеальными для сред разработки и тестирования (staging), рискованных миграций или для того, чтобы позволить аналитикам нагружать копию производственной базы. Восстановление из снимка физически воссоздает данные и может занимать часы; клонирование выигрывает, когда важна скорость.

Aurora Global Database

Aurora Global Database расширяет кластер на до пяти вторичных регионов, используя выделенную инфраструктуру репликации на уровне хранилища, а не пересылку бинарного лога (binlog). Типичная задержка репликации — менее секунды, RPO — менее секунды, а управляемое переключение на вторичный регион (failover) занимает менее минуты.

Два критически важных аспекта семантики: вторичные регионы доступны только для чтения во время нормальной работы, и Global Database предназначена для аварийного восстановления с низким RPO и удаленных чтений с низкой задержкой, а не для конфигурации active-active multi-master. Предположение, что глобальная база данных «автоматически обрабатывает записи во вторичном регионе», неверно — запись туда требует явного управляемого переключения (managed failover) или отсоединения и повышения (detach-and-promote). Для заявленного требования RPO в 5 минут и RTO в 20 минут между регионами с минимальными операционными издержками, Global Database является каноническим ответом.

RDS Proxy и управление подключениями

Бессерверные и высококонкурентные рабочие нагрузки усугубляют классическую проблему: шторм подключений (connection storms). Функция Lambda, масштабирующаяся до 3000 одновременных выполнений, открывает 3000 сокетов, исчерпывая лимит max_connections и вызывая каскадные сбои — именно тогда, когда система находится под нагрузкой. Пулы соединений внутри функции не помогают, потому что каждая среда параллельного выполнения изолирована.

RDS Proxy находится между клиентами и базой данных, поддерживая «теплый» пул соединений и мультиплексируя на него клиентские сессии. Он решает две проблемы:

1. Шторм подключений. Тысячи клиентских сессий мультиплексируются в небольшой пул соединений с базой данных.
2. Время переключения. Прокси удерживает клиентские подключения открытыми во время восстановления связи с базой данных, сокращая воспринимаемое время переключения до 66% и устраняя необходимость в повторном установлении TCP/TLS соединения и разрешении DNS на стороне клиента.

Он интегрируется с IAM и Secrets Manager для обработки учетных данных, что позволяет убрать жестко закодированные секреты из кода приложения.

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

Приложения подключаются к эндпоинту прокси, а не к эндпоинту кластера. Любая архитектура типа Lambda-to-RDS или с высоким коэффициентом ветвления (high-fan-out) должна использовать RDS Proxy, если нет веских причин этого не делать. Запуск собственного пулера соединений (PgBouncer, ProxySQL) на EC2 возможен, но это добавляет операционные издержки, для устранения которых и был создан прокси.

DynamoDB: Режимы производительности

DynamoDB — это управляемое хранилище типа «ключ-значение»/документное хранилище с задержкой в несколько миллисекунд при любом масштабе, горизонтально партиционированное по хэш-ключу. Оно предлагает два режима производительности:

Режим «по требованию» значительно проще, но стоит примерно в 6–7 раз дороже за запрос по сравнению с хорошо утилизируемой подготовленной производительностью. Для ночной 4-часовой пакетной обработки с нагрузкой 500 WCU режим «по требованию» приводит к значительной переплате — подготовленный режим с масштабированием по расписанию или зарезервированная производительность (reserved capacity) гораздо дешевле. И наоборот, использование подготовленного режима для непредсказуемой нагрузки при запуске нового продукта приведёт к троттлингу. Для стабильных нагрузок с умеренными колебаниями подготовленный режим с автоматическим масштабированием с отслеживанием целевого значения (target-tracking auto-scaling) на уровне 70% утилизации значительно дешевле, чем режим «по требованию» — часто на 50–70%:

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

Переключать режимы можно раз в 24 часа. Предполагать, что режим «по требованию» всегда дешевле — дорогостоящая ошибка; то же самое касается и мнения, что подготовленный режим всегда подходит для пикового трафика.

DynamoDB: Согласованность, Streams и Global Tables

По умолчанию чтение использует модель согласованности в конечном счёте (может возвращать устаревшие данные в пределах ~1 секунды, стоимость — 0.5 RCU). Установка ConsistentRead=true возвращает последнее зафиксированное значение по двойной цене. Строго согласованные чтения не поддерживаются через глобальные вторичные индексы или через DAX — эти пути всегда возвращают данные с согласованностью в конечном счёте.

DynamoDB Streams захватывают изменения на уровне элементов в виде упорядоченного журнала, который хранится 24 часа. Это позволяет запускать Lambda для последующей обработки (индексация для поиска, уведомления, денормализация между таблицами) без необходимости опрашивать таблицу.

Global Tables построены на базе Streams и обеспечивают репликацию в режиме «активный-активный» между несколькими регионами с разрешением конфликтов по принципу «побеждает последняя запись» (last-writer-wins). Это правильное решение, когда операции чтения и записи должны быть локальными в нескольких регионах. Однако они примерно удваивают затраты на хранение и запись — каждая запись потребляет WCU в каждом регионе-реплике — и ослабляют согласованность между регионами. Ловушка заключается в использовании Global Tables, когда один регион удовлетворяет требованиям к доступности: таблица DynamoDB в одном регионе уже реплицируется в трёх зонах доступности (AZ) с доступностью 99.99%. Экономически эффективное решение для высокой доступности в одном регионе — это таблица в одном регионе с включённым PITR и, при необходимости, с подготовленной производительностью и автомасштабированием.

Point-in-Time Recovery (PITR) обеспечивает непрерывное резервное копирование с гранулярностью восстановления до секунды за последние 35 дней с незначительными накладными расходами. Включайте его на любой производственной таблице — это удовлетворяет типичным требованиям RPO в несколько минут, а не часов. Для более длительного хранения (например, по нормативным требованиям) интегрируйте AWS Backup для создания резервных копий по расписанию, с управлением жизненным циклом и возможностью копирования между регионами.

TTL позволяет указать атрибут, содержащий время истечения в формате Unix epoch; DynamoDB асинхронно удаляет просроченные элементы без дополнительной платы, что идеально подходит для хранилищ сессий, временных токенов или кэшей событий. Удаления через TTL попадают в Streams для последующей архивации:

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

Для аналитики экспорт в S3 создаёт снимок на определённый момент времени, который можно читать с помощью Athena, Redshift Spectrum или EMR, не потребляя пропускную способность таблицы — это гораздо лучший паттерн, чем сканирование таблицы.

DAX: DynamoDB Accelerator

DAX — это полностью управляемый кэш в памяти со сквозной записью (write-through), разработанный специально для DynamoDB. Он обеспечивает задержку чтения на уровне микросекунд по сравнению с базовым показателем DynamoDB в несколько миллисекунд. Его отличительная черта — совместимость по API: клиент DAX является прямой заменой (drop-in replacement) для клиента DynamoDB SDK, поэтому приложения могут перейти на него, изменив конфигурацию эндпоинта, а не переписывая логику запросов:

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

DAX поддерживает два кэша: кэш элементов для результатов GetItem/BatchGetItem и кэш запросов для результатов Query/Scan. Записи выполняются по принципу сквозной записи (write-through) — DAX проксирует их в DynamoDB и обновляет свой кэш элементов в случае успеха. Однако кэш запросов полагается на TTL, поэтому результаты запросов могут устаревать даже для только что записанных элементов.

Важны два ограничения. Во-первых, DAX ускоряет только чтения с согласованностью в конечном счёте; строго согласованные чтения обходят кэш. Во-вторых, если другие клиенты записывают данные в обход DAX, это приводит к устареванию данных в кэше. Для страницы с деталями продукта, которую просматривают миллионы раз в день, DAX является ускорителем с наименьшими операционными накладными расходами — не требуется код для инвалидации кэша или отдельное управление кластером. ElastiCache перед DynamoDB тоже будет работать, но потребует реализации логики cache-aside, которую DAX делает ненужной.

ElastiCache: Redis и Memcached

ElastiCache предоставляет доступ к данным в памяти с задержкой менее миллисекунды в виде управляемого сервиса, работающего на базе Redis или Memcached. Выбор движка зависит от требуемых функций:

• Memcached — чистый многопоточный кеш типа «ключ-значение» с горизонтальным шардированием, без персистентности, репликации и pub/sub. Используйте только для эфемерного кеширования, где потеря всего кеша является приемлемой.
• Redis — поддерживает репликацию, Multi-AZ с автоматическим переключением при сбое, кластерный режим для шардирования, персистентность, pub/sub, отсортированные наборы, транзакции, а также шифрование при передаче и хранении. Необходим для любых задач, где требуется долговечность или поддержка сложных типов данных.

Преобладают два канонических паттерна.

Централизованное хранилище сессий. Когда ALB распределяет трафик между stateless-инстансами EC2 или ECS, локальное хранилище сессий вынуждает использовать sticky sessions, что нарушает балансировку нагрузки и приводит к сбоям при масштабировании (scale-in), развертывании и отказах AZ. Вынос сессий в Redis позволяет любому инстансу обслуживать любой запрос, а сессии переживают отказ хоста:

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

Снятие нагрузки чтения для дорогостоящих запросов — таблицы лидеров (отсортированные наборы Redis через ZADD/ZREVRANGE), поиск по каталогам, агрегации. Стратегии кеширования должны соответствовать требованиям к согласованности данных:

• Ленивая загрузка (cache-aside): приложение читает из кеша; при промахе читает из БД и заполняет кеш с указанием TTL. Просто, но «холодные» промахи снижают производительность, а данные могут быть устаревшими.
• Сквозная запись (write-through): приложение записывает в кеш и в БД в рамках одной операции. Кеш остается актуальным, но запись замедляется, а неиспользуемые данные продолжают занимать память.
• Отложенная запись (write-back / write-behind): запись сначала идет в кеш, а затем асинхронно сбрасывается в БД. Самая быстрая запись, но при сбое кеша данные теряются.

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

Использование любого слоя кеширования без стратегии инвалидации — TTL, явный вызов DEL при обновлении или сквозная запись — приводит к чтению устаревших данных. Этот сбой происходит незаметно: приложение кажется работающим корректно, пока пользователи не замечают расхождений. Кеширование также часто является самым дешевым способом масштабировать чтение за пределы возможностей реплик чтения и защищает основной инстанс во время всплесков трафика.

В отличие от DAX, ElastiCache не зависит от движка — вы сами отвечаете за логику инвалидации — поэтому DAX выигрывает в простоте эксплуатации, когда в качестве хранилища используется DynamoDB.

Миграция: DMS и SCT

AWS Database Migration Service (DMS) реплицирует данные между однородными (гомогенными) движками (Oracle→Oracle, MySQL→Aurora MySQL) или разнородными (гетерогенными) (Oracle→Aurora PostgreSQL, SQL Server→RDS MySQL, on-prem→DynamoDB). Задача DMS состоит из трех фаз:

1. Полная загрузка (Full load) — массовое копирование существующих строк.
2. CDC (change data capture) — отслеживание журнала транзакций источника и применение текущих изменений.
3. Full load + CDC — распространенный шаблон для миграции с минимальным простоем: источник остается в сети, DMS поддерживает целевую базу в синхронизированном состоянии, а переключение сводится к быстрой смене DNS-записи.

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

DMS Serverless избавляет от необходимости подбирать размер и управлять инстансами репликации — ресурсы автоматически выделяются в соответствии с нагрузкой, что подходит для переменных или длительных задач CDC. В движках-источниках должно быть включено дополнительное логирование (supplemental logging для Oracle) или бинарное логирование в формате ROW (для MySQL). Для очень больших начальных объемов данных DMS интегрируется со Snowball Edge для офлайн-загрузки.

DMS переносит данные, а не схему. Для гетерогенных миграций его используют в паре с AWS Schema Conversion Tool (SCT), который конвертирует хранимые процедуры, представления, триггеры, последовательности и специфичные для диалекта типы данных — например, Oracle PL/SQL в PostgreSQL PL/pgSQL или T-SQL в Aurora MySQL. SCT создает отчет об оценке, отмечая объекты, требующие ручной доработки (обычно это 5–20% для сложных кодовых баз). Использование только DMS для междвижковой миграции — распространенная ошибка: хотя DMS может создавать базовые целевые таблицы, он не переводит корректно процедуры или проприетарные типы данных. Для гомогенных миграций SCT не нужен — достаточно нативных утилит (mysqldump, pg_dump, RMAN) и DMS CDC.

Полный шаблон междвижковой миграции:

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

Резервное копирование и восстановление на момент времени

Автоматические бэкапы RDS сочетают ежедневные снимки (snapshots) с резервным копированием журналов транзакций каждые 5 минут, что позволяет выполнять восстановление на определенный момент времени (PITR) с точностью до секунды в пределах окна хранения (от 1 до 35 дней, по умолчанию 7). Восстановление создает новый инстанс — нельзя восстановить данные на существующем инстансе — поэтому конечные точки приложения или CNAME-записи должны быть обновлены. Снимки, созданные вручную, сохраняются дольше периода хранения и не удаляются вместе с инстансом (в зависимости от настройки создания финального снимка), их можно копировать между регионами для аварийного восстановления (DR) и предоставлять доступ другим аккаунтам.

Fast Snapshot Restore (FSR) для снимков на базе EBS устраняет задержку «ленивой загрузки», обеспечивая восстановленным томам полную производительность сразу после запуска — это полезно при быстром развертывании нескольких сред из одного снимка. Клонирование Aurora позволяет создавать копии в том же регионе, полностью минуя создание снимков. PITR в DynamoDB — это аналогичная функция, которую нужно включать для каждой таблицы; при восстановлении она создает новую таблицу.

Специализированные базы данных

Выбор специализированного движка, когда этого требуют шаблоны доступа, позволяет избежать дорогостоящей перестройки архитектуры в будущем. Amazon Neptune — это управляемая графовая база данных с поддержкой Gremlin, openCypher и SPARQL, которая подходит для случаев, когда запросы обходят связи (мошеннические схемы, социальные графы, графы знаний), где рекурсивные соединения в реляционной СУБД были бы непомерно дорогими. Amazon QLDB — это неизменяемый, криптографически верифицируемый реестр с журналом, работающим только в режиме добавления записей (append-only), который подходит для систем записи, требующих защищенного от подделки аудита — отслеживание цепочек поставок, финансовые транзакции, записи автоинспекции. DynamoDB — это стандартный выбор для доступа к данным типа «ключ-значение» или документам с задержкой в единицы миллисекунд при любом масштабе, с использованием таких паттернов, как проектирование с одной таблицей (single-table design), составные ключи сортировки для иерархического доступа и глобальные вторичные индексы (GSI) для альтернативных путей доступа. Попытка реализовать такие рабочие нагрузки в RDS приводит к конфликтам блокировок (записи в реестр), сложности запросов (обход графа) или к пределам масштабирования (высокопроизводительный доступ «ключ-значение») — каждую из этих проблем исправить позже гораздо дороже, чем сделать правильный выбор на этапе проектирования.

Краткий обзор ловушек

• Реплики чтения для высокой доступности (HA). Асинхронная репликация, нет автоматического повышения, конечная точка меняется при повышении, незавершённые транзакции теряются. Для HA следует использовать Multi-AZ.
• Multi-AZ для масштабирования чтения. Резервный узел (standby) недоступен для чтения в стандартной конфигурации RDS Multi-AZ. Используйте реплики чтения или реплики Aurora.
• Использование Single-AZ в производственной среде. Нет цели для аварийного переключения; доступность теряется при любом событии в AZ или перезапуске инстанса. Multi-AZ стоит примерно в 2 раза дороже, но обеспечивает качественный скачок в доступности.
• Размер реплики по умолчанию равен размеру основного узла. Репликам часто требуется гораздо меньше ресурсов; подбирайте размер под измеренную нагрузку, если только реплика не является кандидатом на повышение.
• Режим DynamoDB On-Demand всегда дешевле. Стоимость за запрос примерно в 6–7 раз выше; для стабильных нагрузок выгоднее использовать режим provisioned с auto-scaling.
• Использование Global Tables для однорегиональных задач. Удваивает стоимость и ослабляет согласованность без каких-либо преимуществ, если не требуется близость к пользователям в нескольких регионах или аварийное восстановление (DR).
• Вторичные узлы Aurora Global Database обслуживают запись. Они доступны только для чтения, пока управляемое аварийное переключение не повысит их до основного узла.
• Доступ из Lambda к RDS без RDS Proxy. «Шторм соединений» исчерпывает max_connections; пулы соединений внутри функции не помогают при одновременном выполнении в разных средах.
• Использование только DMS для гетерогенной миграции. Переносит данные, но не схему. Используйте в паре с SCT.
• Фиксированный объём хранилища RDS без автомасштабирования или оповещений по FreeStorageSpace. Скрытый сбой — состояние storage-full отклоняет операции записи.
• Кэширование без стратегии инвалидации. «Тихое» устаревание данных. Использование TTL, сквозной записи (write-through) или явной инвалидации обязательно.
• Строго согласованное чтение через DAX или GSI. Оба этих способа обеспечивают только согласованность в конечном счёте (eventually consistent).

← Доставка контента · Все домены · Аналитика →

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

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