Amazon DynamoDB¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Область версий: DynamoDB API 2012-08-10; global tables 2019.11.21. Проверка источников: 2026-11-02.

1. Архитектура и модель данных¶

FACT. Managed key-value/document database с partition key и необязательным sort key. Query читает известный partition-key range; Scan обходит таблицу. Внутренний on-disk engine/compaction не является публичным контрактом: UNKNOWN, не приписываем DynamoDB Cassandra LSM.

flowchart LR
  Request --> Key[Partition and sort key routing]
  Key --> Item[Conditional item or regional transaction]
  Item -. async .-> GSI[GSI projection]
  Item --> Global[Optional global table mode]
  Global --> MREC[MREC async conflicts]
  Global --> MRSC[MRSC strong mode with restrictions]

2. Физическое хранение и путь записи¶

Сервис распределяет storage partitions и replicas внутри Region; physical layout и recovery реализует AWS. Размер item, key distribution, indexes и mode provisioned/on-demand определяют billable work. Capacity accounting и quotas проверять в актуальной service documentation, а не заменять выдуманным benchmark.

Источники механизма: документация 1.

3. Индексы и путь чтения¶

Base-table PK обеспечивает key access; LSI использует тот же partition key и иной sort key, GSI — иной key и отдельную асинхронную проекцию. Strongly consistent reads доступны для table/LSI, не GSI и Streams. Projection/index design влияет на стоимость записи и возможные фильтры; FilterExpression применяется после чтения и не делает Scan дешёвым.

Источники механизма: документация 1.

4. Транзакции и consistency guarantees¶

Conditional writes атомарно проверяют item condition; UpdateItem позволяет counters, но retry инкремента без dedup может повторить эффект. TransactWriteItems/TransactGetItems дают multi-item transaction в поддерживаемой одной Region/account scope. Изменения transaction появляются в GSIs/Streams постепенно и могут interleave; downstream нельзя считать их атомарным batch.

Источники механизма: документация 1, документация 2.

5. Репликация, partitioning и sharding¶

Global tables version 2019.11.21 имеют MREC и MRSC. MREC реплицирует асинхронно и использует per-item last-writer-wins; local strong read не превращается в global serial read. MRSC — другой режим с синхронным межрегиональным согласованием и ограничениями Region/topology/features; проверять текущую матрицу. Не писать «все DynamoDB global tables eventual».

Режимы не смешиваются в одной global table. У MRSC свои ограничения, включая неподдерживаемые transaction APIs и TTL по проверенной документации; эти свойства не переносить из single-Region/MREC примеров.

Источники механизма: документация 3.

6. Конкурентная запись и конфликты¶

ConditionExpression attribute_not_exists защищает создание конкретного key; version condition реализует CAS. В MREC competing Region writes могут перезаписать локально принятую логику. Idempotency token transaction API имеет ограниченный срок действия; для длительного business replay нужен собственный реестр в нужной transaction scope.

Источники механизма: документация 2, документация 3.

7. Отказы и восстановление¶

Managed replicas не заменяют PITR/on-demand backup. Восстановление создаёт отдельную таблицу; переключение приложения, восстановление indexes/TTL/Streams/global topology и прав требует runbook. Timeout после write — ambiguous outcome: читать key либо повторять с согласованной идемпотентностью.

Источники механизма: документация 5.

8. Масштабирование и ограничения¶

Adaptive capacity не отменяет физические ограничения горячего key/partition и лимиты аккаунта. Write sharding снимает часть skew, но чтение требует fan-out. On-demand устраняет ручной steady provisioning, не отменяет ramp-up, quotas и цену неэффективного Scan.

9. Performance trade-offs¶

Платить приходится за access pattern: item size, strongly consistent vs eventual reads, transactions, replicated writes и indexes. GSI повышает query flexibility ценой asynchronous freshness и write amplification. Меньше server ops не равно нулевая operational complexity: schema/access redesign, throttling и costs остаются.

10. Мониторинг и эксплуатация¶

CloudWatch throttling, consumed capacity, system errors, successful request latency, GSI pressure и global replication metrics соответствующего режима. Различать hot partition от account/table capacity. CloudTrail/backup policies и restore drills включать в operations; не предполагать, что Streams — бессрочный archive.

11. Сценарии FinTech и iGaming¶

INFERENCE. Idempotency/session/event lookup по детерминированному key; highload player state с conditional updates. Financial invariants допустимы лишь внутри доказанной transaction boundary и consistency mode. MREC active-active wallet без бизнес-протокола conflict resolution опасен.

12. Когда не выбирать¶

Не выбирать для произвольных joins, непредсказуемых аналитических scans или global ACID transactions без проверки поддержки. Не применять TTL как точный дедлайн удаления: в поддерживаемых TTL режимах физическое удаление асинхронное, истёкшие items надо фильтровать по бизнес-времени.

13. Вопросы на собеседовании¶

Почему GSI не подтверждает read-your-writes? Индекс обновляется асинхронно и не поддерживает strongly consistent read.

MRSC равно MREC с флагом чтения? Нет, это отдельный режим репликации с собственной матрицей ограничений.

Чем counter retry опасен? Утрата ответа не доказывает отсутствие первого инкремента.

14. Практические SQL/config примеры¶

{
  "TableName": "Idempotency",
  "Item": {"pk": {"S": "tenant-7#request-42"}, "payload_hash": {"S": "example-hash"}},
  "ConditionExpression": "attribute_not_exists(pk)"
}

Тело PutItem для учебной single-Region таблицы; hash вычисляется по каноническому payload и сравнивается при duplicate. JSON syntax проверен; AWS API/IAM/capacity и conflict paths не запускались.

15. Дополнительные источники¶

Типичные ошибки проектирования¶

Игнорировать выбранный engine/consistency mode; считать replica backup; повторять ambiguous write без idempotency; переносить guarantee другой СУБД. Конкретные опасные случаи разобраны в разделах 4–7.

Практические упражнения¶

Для примера выше опишите успешный commit с потерянным ответом и потерю primary. Укажите authoritative copy, способ обнаружения результата, допустимый retry и процедуру restore. Выполните эксперимент на выбранной версии; текущие проверки не заменяют его.