Философия и основы

1. Философия и основы

1.1. Зачем вообще нужна DynamoDB?

Проблемы, которые решает DynamoDB

Представьте ситуацию: ваше приложение внезапно становится популярным. За неделю количество пользователей выросло с 10 тысяч до миллиона. Ваша тщательно настроенная база данных PostgreSQL, которая прекрасно справлялась с нагрузкой, начинает задыхаться. Cервер уперся в лимит соединений, CPU на 100%, IOPS на пределе. Репликация отстаёт, индексы не успевают обновляться, а попытки горизонтального масштабирования превращаются в кошмар с ручным шардингом и балансировкой нагрузки.

Или другой сценарий: вы разрабатываете IoT-платформу, где миллионы устройств отправляют телеметрию каждую секунду. Традиционная реляционная база данных требует постоянной оптимизации индексов, тщательного планирования партиционирования, и всё равно начинает деградировать при росте объёма данных. При этом 99% ваших запросов - это простые операции записи и чтения по ключу, для которых вся мощь SQL просто не нужна.

Третий пример: глобальное мобильное приложение с пользователями в Азии, Европе и Америке. Размещение master-базы в одном регионе (например, в Вирджинии) означает, что пользователи в Токио или Сиднее будут испытывать задержки в 200-300 миллисекунд только на сетевой round-trip. Multi-master репликация в PostgreSQL или MySQL - это отдельная, сложнейшая инженерная задача с риском конфликтов и split-brain сценариев.

Когда реляционные БД становятся узким местом

Реляционные базы данных - это прекрасный, проверенный временем инструмент. Их стоит использовать в большинстве проектов. Но есть сценарии, где их архитектурные принципы становятся ограничением:

1. Непредсказуемые всплески нагрузки. "Черная пятница", вирусный твит, внезапная популярность - реляционные БД требуют предварительного выделения ресурсов (provisioning). Вы либо переплачиваете за простаивающее железо 99% времени, либо рискуете упасть в самый важный момент. DynamoDB в режиме On-Demand масштабируется от нуля до практически неограниченной пропускной способности и обратно.

2. Операционная сложность. Управление репликами, настройка параметров памяти, vacuum в PostgreSQL, оптимизация индексов, планирование бэкапов, обновление версий с даунтаймом - всё это требует специализированной экспертизы (DBA/SRE) и постоянного внимания. Ваш телефон, звонящий в 3 часа ночи, потому что "на реплике кончилось место" - это цена эксплуатации. DynamoDB полностью управляется AWS.

3. Простые паттерны доступа при высокой нагрузке. Если 90% ваших запросов - это "получить объект по ID" или "получить последние N записей пользователя", то вы платите огромную цену за неиспользуемую функциональность SQL. Планировщик запросов, оптимизатор, поддержка транзакций MVCC - всё это добавляет накладные расходы (overhead) там, где они не нужны. DynamoDB оптимальнее для простых паттернов доступа.

4. Глобальная доступность с низкой латентностью. Настройка географически распределённой реляционной БД с активной репликацией (Active-Active) - это месяцы работы высококвалифицированных инженеров. В DynamoDB (с Global Tables) это включается одной кнопкой и работает с предсказуемой моделью разрешения конфликтов.

Сценарии использования DynamoDB

DynamoDB была рождена в недрах Amazon для решения главной проблемы - масштабирования корзины покупок во время Prime Day. Она создана для специфичных, но крайне требовательных задач:

• Gaming (Игры): Индустрия, где задержка решает все. Хранение игровых сессий, лидербордов, инвентаря игроков. Игра может выстрелить с тысячи пользователей до десяти миллионов за неделю. Архитектура не должна меняться. Zynga, Electronic Arts, Ubisoft строят на DynamoDB критичные для геймплея системы.

• IoT и временные ряды: Миллионы устройств генерируют непрерывный поток данных. Каждая запись имеет простую структуру: device_id, timestamp, metrics. DynamoDB с TTL (Time-to-Live) автоматически удаляет старые данные, Streams позволяют в реальном времени агрегировать метрики, а стоимость растёт линейно с объёмом.

• AdTech (Рекламные технологии): Платформы для торгов в реальном времени (RTB). На принятие решения (показать рекламу или нет) у вас есть 10-20 миллисекунд. За это время нужно успеть прочитать профиль пользователя и записать результат. DynamoDB гарантирует задержку в единицах миллисекунд при любом масштабе.

• Mobile & Serverless Backends: Ваш бэкенд - это AWS Lambda. Непредсказуемые паттерны использования, необходимость работы в разных регионах. Lambda может масштабироваться от 0 до 10,000 одновременных функций за секунды. Вам нужна база данных, которая так же масштабируется с нуля, не требуя пула соединений.

Сравнение экономики

Когда DynamoDB дешевле?

• На старте и при очень неравномерной нагрузке. Ваш стартап. 100 пользователей днем и 0 ночью. В RDS вы платите за включенный сервер 24/7 (например, $8/мес за t3.micro). В DynamoDB в режиме On-Demand (по требованию) вы платите за каждый запрос. 0 запросов = $0. Ваша стоимость будет $0.10/мес.

• В бессерверных (Serverless) приложениях. Связка Lambda + RDS - это боль. Вам нужен NAT Gateway, VPC, и ваш RDS должен быть постоянно включен. Связка Lambda + DynamoDB (через VPC Endpoint) работает "из коробки" и стоит $0 в состоянии простоя.

• При учете "полной стоимости владения" (TCO). В RDS вы платите не только за сервер, но и за время ваших самых дорогих инженеров (SRE/DBA), которые тратят часы на настройку vacuum, оптимизацию JOINов, планирование обновлений и тушение пожаров в 3 часа ночи. DynamoDB - это "нулевой" OpEx. Вам не нужен DBA для DynamoDB. Эта скрытая экономия на зарплате и времени инженеров часто оказывается более значительной, чем прямой счет от AWS.

Когда DynamoDB дороже?

• При высокой, стабильной нагрузке. Если у вас ровно 1,000 запросов в секунду 24/7, режим On-Demand будет очень дорогим. Здесь дешевле использовать Provisioned (выделенный) режим DynamoDB или правильно настроенный кластер RDS/Aurora.

• При больших объемах данных и редких запросах (aналитика). Хранить 10 ТБ данных в DynamoDB очень дорого. Если вы их редко читаете, гораздо дешевле хранить их в S3 и запрашивать через Athena.

Только теперь, поняв проблемы, мы можем дать определение:

AWS DynamoDB - это полностью управляемая, бессерверная NoSQL база данных, созданная для сценариев, требующих гарантированной производительности (единицы миллисекунд) при любом масштабе.

Это компромисс. Вы добровольно отказываетесь от гибкости SQL (JOIN, ad-hoc запросы) в обмен на почти бесконечную масштабируемость и нулевые операционные расходы.

1.2. Архитектурные принципы DynamoDB

NoSQL и Key-Document модель

Помните, как мы проектируем схему БД? Users, Orders, Products, OrderItems... Третья нормальная форма. Никаких дубликатов. Это красиво, элегантно, но... иногда дорого.

1. Цена JOIN: Чтобы собрать страницу заказа, вашему PostgreSQL нужно "сбегать" в 5 разных мест на диске (5 B-Tree индексов), собрать данные и склеить их. При нагрузке в 1000 RPS это превращается в миллионы дисковых операций.

2. Цена изменения схемы: SQL-схема - это жесткий контракт. Добавление нового поля или изменение существующего требует процесса миграции. Нужно разбивать процесс миграции на этапы, писать специализированные скрипты.

Модель DynamoDB (которая по факту key-document) переворачивает игру. Она бессхемная (schemaless). Каждый "элемент" (item, аналог строки) может иметь свой набор "атрибутов". Вы можете добавить social_links к одному пользователю, не трогая остальные 5 миллиардов, просто начав их записывать. И DynamoDB не поддерживает JOINы.

Почему отказ от JOIN'ов - это благо при больших объемах?

Запрещая JOINы на уровне движка, DynamoDB вынуждает вас делать то, что Amazon и так делал для масштабирования: денормализацию.

Вместо того чтобы джойнить на лету (при чтении), вы джойните данные при записи.

• SQL-подход: Таблица Orders хранит user_id. Чтобы показать имя, вы делаете JOIN users.

• DynamoDB-подход: Элемент Order хранит user_id и user_name. Да, данные дублируются. Но чтение заказа - это одна быстрая операция. "Хранилище дешевле вычислений".

Отказ от JOINов - это фундаментальный компромисс: вы меняете гибкость запросов и эффективность хранения (нормализация) на предсказуемую, сверхнизкую задержку и бесконечную масштабируемость чтения.

Бессерверность (Serverless)

Представьте себе жизнь SRE-инженера, отвечающего за кластер PostgreSQL. Его телефон звонит в 3 часа ночи. Почему?

• На реплике кончилось место на диске.

• Начался VACUUM и забил CPU.

• Забыли применить патч безопасности.

• Нужно обновить мажорную версию (с даунтаймом в 2 часа).

• Лимит соединений исчерпан.

Бессерверность (Serverless) в DynamoDB означает, что всех этих проблем больше не существует.

• Патчинг ОС? - Не ваша проблема.

• Настройка репликации? - Встроено (3 копии данных в 3-х ЦОДах).

• Планирование бэкапов? - Включается одной кнопкой (PITR).

• Масштабирование диска? - Он бесконечный.

• Масштабирование соединений? - Их нет (API-вызовы по HTTP).

Когда это критично для бизнеса?

1. Time-to-Market: У вас команда из 3-х бэкенд-разработчиков и 0 DBA/DevOps. Вы можете запустить глобально-масштабируемый продукт.

2. Экономия на людях: Вам не нужно нанимать команду DBA для управления парком баз данных.

3. Безопасность и Compliance: AWS автоматически шифрует все данные и берет на себя огромную часть работы по соответствию стандартам (PCI, HIPAA и т.д.).

Что происходит под капотом при автоскейлинге?

Вы не управляете "серверами", но вы управляете "пропускной способностью", которая измеряется в RCU (Read Capacity Units) и WCU (Write Capacity Units).

• 1 WCU = 1 транзакционная запись в секунду для элемента до 1 КБ.

• 1 RCU = 1 строго консистентное чтение в секунду для элемента до 4 КБ (или 2 нестрого консистентных чтения).

Когда ваша нагрузка растет, DynamoDB на лету разрезает (split) ваши партиции, перемещая их на новые сервера и выделяя им новый бюджет RCU/WCU. Это происходит прозрачно и без даунтайма.

Режимы биллинга (тарифы)

1. Выделенный (Provisioned): Вы говорите: "Я хочу 1,000 WCU и 5,000 RCU". Вы платите за эту мощность по часам, независимо от того, используете вы ее или нет. Это дешево при предсказуемой, высокой нагрузке.

2. По требованию (On-Demand): Вы не говорите ничего. DynamoDB просто выполняет все ваши запросы. Вы платите за каждый запрос. Это дороже за запрос, чем Provisioned, но дешевле, если у вас 0 нагрузки или резкие, непредсказуемые пики.

Для Provisioned режима можно включить Auto Scaling, задав целевую утилизацию (например, 70%). Это позволяет AWS автоматически регулировать выделенную мощность: если потребление превышает 70%, Auto Scaling добавляет мощности для создания буфера, а если падает ниже - убирает излишки для экономии. Так вы можете платить за меньше WCU и RCU.

Как правило, для тестового окружения начинают с On-Demand, а для продакшена с предсказуемой нагрузкой используют Provisioned + Auto Scaling.

Гарантированная производительность

Традиционная БД - это как общая автомагистраль в час пик. Ваш SELECT может занять 5 мс (если дорога пустая), а может 500 мс (если аналитик запустил годовой отчет, создав "пробку" из JOINов).

DynamoDB - это как ваша личная выделенная полоса.

В каких сценариях задержка в единицах миллисекунд критична?

• AdTech (Real-Time Bidding): Весь аукцион должен пройти за 100 мс. Ваша БД не может "задуматься".

• Gaming: Таблица лидеров. Вы не можете заставить игрока ждать 2 секунды, пока обновится его счет.

• Бэкенд для API: Если у вас сложная цепочка вызовов микросервисов, и каждый из 5 сервисов ходит в БД, которая иногда тормозит, то 5мс + 5мс + 500мс + 5мс + 5мс = 520мс. Один медленный запрос рушит весь SLA.

SLA и гарантии AWS

DynamoDB дает SLA на задержку в единицах миллисекунд (~2-9 мс). Это SLA для простых операций (GetItem, PutItem, Query по ключу). Это не SLA для Scan (полное сканирование таблицы).

Партиции

Вот почему DynamoDB может это гарантировать:

1. Изоляция: Когда вы запрашиваете GetItem(user_id='123'), DynamoDB хэширует user_id и точно знает, на какой одной партиции (из возможных тысяч) лежит этот элемент. Запрос идет только туда. Он не затрагивает другие 99.9% системы.

2. Нет JOINов, нет блокировок: Нет сложных вычислений. Нет блокировок уровня таблицы.

3. Бюджетирование (RCU/WCU): Это не только модель биллинга, это механизм защиты. Ваш RCU/WCU - это ваш выделенный "кусочек" мощности. Запрос аналитика (который делает Scan) не отнимет RCU у запросов пользователей (GetItem), если они идут на разные партиции.

1.3. Практика