Amazon DynamoDB

Amazon DynamoDB

Разработчик(и)	Amazon.com
Первоначальный выпуск	Январь 2012 г .; 13 лет назад [1] ( 2012-01 )
Написано в	Ява
Операционная система	Кроссплатформенный
Доступно в	Английский
Тип	Документоориентированная база данных База данных «ключ-значение»
Лицензия	Запатентованный
Веб-сайт	aws.amazon.com/dynamodb/

Amazon DynamoDB — это управляемая служба базы данных NoSQL, предоставляемая Amazon Web Services (AWS). Она поддерживает структуры данных «ключ-значение» и «документ» и предназначена для обработки широкого спектра приложений, требующих масштабируемости и производительности. ^[2]

Вернер Фогельс , технический директор Amazon.com, в своем заявлении 2012 года мотивировал проект. ^[3] Amazon начинался как децентрализованная сеть сервисов. Изначально сервисы имели прямой доступ к базам данных друг друга. Когда это стало узким местом в инженерных операциях, сервисы отошли от этой модели прямого доступа в пользу общедоступных API . Тем не менее, сторонние системы управления реляционными базами данных с трудом справлялись с клиентской базой Amazon. Это достигло кульминации в праздничный сезон 2004 года ^{[4] [5]} , когда несколько технологий вышли из строя из-за большого трафика.

Традиционные базы данных часто разбивают данные на более мелкие части для экономии места, но объединение этих частей во время поиска может замедлить запросы. Многие из служб Amazon требовали в основном чтения первичных ключей своих данных, и поскольку скорость была главным приоритетом, объединение этих частей было чрезвычайно утомительным. ^[6]

Amazon, довольствуясь снижением эффективности хранения, ответила Dynamo : высокодоступное хранилище ключей и значений, созданное для внутреннего использования. ^[3] Dynamo, казалось, было всем, что нужно их инженерам, но принятие запаздывало. Разработчики Amazon выбрали шаблоны проектирования «просто работает» с S3 и SimpleDB. Хотя эти системы имели заметные недостатки дизайна, они не требовали накладных расходов на предоставление оборудования, масштабирование и повторное разбиение данных. Следующая итерация технологии NoSQL от Amazon , DynamoDB, автоматизировала эти операции по управлению базами данных.

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

Таблица DynamoDB — это логическая группировка элементов, представляющих данные, хранящиеся в этой таблице. Учитывая NoSQL-природу DynamoDB, таблицы не требуют, чтобы все элементы в таблице соответствовали какой-либо предопределенной схеме. ^[7]

Элемент в DynamoDB — это набор атрибутов, которые могут быть однозначно идентифицированы в Таблице. Атрибут — это атомарная сущность данных, которая сама по себе является парой Ключ-Значение. Ключ всегда имеет тип String, тогда как значение может иметь один из нескольких типов данных.

Элемент уникально идентифицируется в таблице с помощью подмножества его атрибутов, называемых ключами. ^[7]

Первичный ключ — это набор атрибутов, который однозначно идентифицирует элементы в таблице DynamoDB. Создание таблицы DynamoDB требует определения первичного ключа. Каждый элемент в таблице DynamoDB должен иметь все атрибуты, составляющие первичный ключ, и никакие два элемента в таблице не могут иметь одинаковый первичный ключ. Первичные ключи в Dynamo DB могут состоять из одного или двух атрибутов.

Когда первичный ключ состоит только из одного атрибута, он называется ключом раздела. Ключи раздела определяют физическое расположение связанного элемента. В этом случае никакие два элемента в таблице не могут иметь одинаковый ключ раздела.

Когда первичный ключ состоит из двух атрибутов, первый называется «ключом раздела», а второй называется «ключом сортировки». Как и прежде, ключ раздела определяет физическое расположение данных, но ключ сортировки затем определяет относительное логическое положение записи связанного элемента внутри этого физического расположения. В этом случае два элемента в таблице могут иметь один и тот же ключ раздела, но никакие два элемента в разделе не могут иметь один и тот же ключ сортировки. Другими словами, заданная комбинация ключа раздела и ключа сортировки гарантированно будет иметь не более одного связанного с ней элемента в таблице DynamoDB. ^[7]

DynamoDB поддерживает числовые, строковые, логические, документные и наборные типы данных. ^[8]

Первичный ключ таблицы — это индекс по умолчанию или первичный индекс таблицы DynamoDB.

Кроме того, таблица DynamoDB может иметь вторичные индексы. Вторичный индекс определяется по атрибуту, который отличается от ключа раздела или ключа сортировки как первичный индекс.

Если вторичный индекс имеет тот же ключ раздела, что и первичный индекс, но другой ключ сортировки, он называется локальным вторичным индексом.

Когда первичный индекс и вторичный индекс имеют разные ключи раздела, вторичный индекс называется глобальным вторичным индексом. ^[7]

Шаблоны моделирования данных DynamoDB — это архитектурные подходы, используемые в Amazon DynamoDB, службе баз данных NoSQL, разработанной для распределенных систем. Эти шаблоны решают различные проблемы организации данных и включают «Проектирование одной таблицы», которое объединяет связанные данные, соблюдая ограничение размера элемента DynamoDB в 400 КБ; «Проектирование нескольких таблиц», которое разделяет данные на отдельные таблицы на основе шаблонов доступа и различий в моделях данных; и Гибридное проектирование, которое сочетает оба подхода для баланса гибкости и эффективности. ^{[9] [10] [11]}

Дополнительные шаблоны, описанные в документации AWS, включают «Event Sourcing», где изменения данных хранятся как неизменяемые события, что позволяет историческую реконструкцию состояния; «Materialized Views», которые упрощают аналитические запросы с помощью предварительно вычисленных агрегаций, часто реализуемых с помощью потоков DynamoDB, обработки на уровне приложений или периодических пакетных обновлений с использованием функций Lambda; и «Time-Series Design», оптимизированный для рабочих нагрузок, таких как ведение журнала и метрики, обычно использующий ключ раздела для идентификации сущности и ключ сортировки, представляющий временные метки, для эффективного запроса наборов данных на основе времени. ^{[12] [13] [14]}

Каждый шаблон отвечает определенным техническим требованиям. «Проект одной таблицы» может оптимизировать эффективность запроса путем совместного размещения связанных данных под одним и тем же ключом раздела для сокращения задержки доступа. «Проект нескольких таблиц» позволяет разделять проблемы путем изоляции данных в целевых таблицах с различными шаблонами доступа. «Источник событий» сохраняет исторический журнал изменений состояния, часто реализуемый с неизменяемым хранилищем данных. «Материализированные представления» упрощают сложные аналитические запросы с помощью стратегий предварительной агрегации, адаптированных к шаблонам доступа. «Проект временных рядов» использует стратегии разделения и сортировки для эффективного хранения и запроса больших объемов временных данных. ^{[9] [10] [11] [12] [13] [14]}

Заявление Amazon DynamoDB о задержке в одну цифру миллисекунды в первую очередь относится к простым операциям, таким как GetItemи PutItem, которые извлекают или изменяют отдельные элементы с помощью их первичных ключей. Это отражает среднюю задержку в идеальных условиях, таких как равномерное распределение разделов и достаточная пропускная способность, и не учитывает транспортные издержки, возникающие во время связи с конечной точкой DynamoDB. Более сложные операции, такие как Queryс фильтрами Scan, или те, которые включают большие наборы данных, могут испытывать повышенную задержку из-за дополнительных требований к вычислениям и передаче данных. ^{[15] [16]}

Для оптимизации производительности DynamoDB разработчики должны тщательно планировать и анализировать шаблоны доступа при проектировании схемы базы данных. Это включает создание таблиц и соответствующую настройку индексов. ^{[17] [18] [19] [20]}

При запросе неиндексированных атрибутов DynamoDB выполняет полное сканирование таблицы, что приводит к значительным накладным расходам. Даже при использовании операции «фильтр» DynamoDB сканирует всю таблицу перед применением фильтров. ^[18]

Amazon DynamoDB изначально не поддерживает операции соединения, поскольку это база данных NoSQL, оптимизированная для высокопроизводительных шаблонов доступа с одной таблицей. Однако операции, подобные соединениям, могут быть достигнуты посредством интеграции с внешними инструментами, такими как Amazon EMR, Amazon Athena и Apache Spark. Эти инструменты обрабатывают данные DynamoDB вне базы данных, позволяя выполнять соединения в стиле SQL для аналитических и пакетных рабочих нагрузок. Хотя эти методы расширяют возможности запросов DynamoDB, они вносят дополнительную сложность и задержку, что делает их непригодными для случаев использования в реальном времени или транзакций. Архитектура DynamoDB разработана таким образом, чтобы избегать соединений, поощряя денормализацию и схемы с одной таблицей. ^{[21] [22] [23] [24]}

Хотя DynamoDB изначально не поддерживает объединения, альтернативные подходы могут достигать схожих результатов. Денормализация объединяет связанные данные в одну таблицу, а составные ключи или вторичные индексы позволяют эффективно группировать и запрашивать связанные элементы. Объединения на уровне приложений объединяют результаты программным образом из нескольких запросов, в то время как проектирование одной таблицы предварительно объединяет данные во время планирования схемы. Для аналитических рабочих нагрузок внешние инструменты, такие как Amazon EMR и Athena, позволяют выполнять объединения в стиле SQL за пределами DynamoDB. Решения для кэширования, такие как DynamoDB Accelerator (DAX) или OpenSearch, также могут имитировать объединения путем предварительной агрегации и кэширования данных. ^{[21] [22] [23] [24]}

Хотя DynamoDB изначально не поддерживает блокировку, существуют различные механизмы. Оптимистическая блокировка может использовать номер версии для обнаружения конфликтов, возникающих после обновлений, а не для их предварительного предотвращения. Пессимистическая блокировка , напротив, может включать условные обновления с такими атрибутами, как lockTimeи lockedBy. В сочетании с Time to Live (TTL) эти атрибуты позволяют автоматически удалять просроченные блокировки, что потенциально улучшает управление параллелизмом в архитектурах, управляемых событиями. ^{[15] [25] [26] [27]}

DynamoDB использует хеширование и B-деревья для управления данными. После ввода данные сначала распределяются по разным разделам путем хеширования ключа раздела. Каждый раздел может хранить до 10 ГБ данных и обрабатывать по умолчанию 1000 единиц емкости записи (WCU) и 3000 единиц емкости чтения (RCU). ^[28] Один RCU представляет одно строго согласованное чтение в секунду или два в конечном счете согласованных чтения в секунду для элементов размером до 4 КБ. ^[29] Один WCU представляет одну запись в секунду для элемента размером до 1 КБ.

Для предотвращения потери данных DynamoDB имеет двухуровневую систему резервного копирования репликации и долгосрочного хранения. ^[30] Каждый раздел имеет три узла, каждый из которых содержит копию данных этого раздела. Каждый узел также содержит две структуры данных: дерево B, используемое для поиска элементов, и журнал репликации, в котором отмечаются все изменения, внесенные в узел. DynamoDB периодически делает снимки этих двух структур данных и хранит их в течение месяца в S3, чтобы инженеры могли выполнять восстановление своих баз данных на определенный момент времени.

В каждом разделе один из трех узлов назначается «узлом-лидером». Все операции записи сначала проходят через узел-лидер перед распространением, что делает записи в DynamoDB согласованными. Чтобы поддерживать свой статус, лидер отправляет «пульс» каждому другому узлу каждые 1,5 секунды. Если другой узел перестает получать пульс, он может инициировать новые выборы лидера. DynamoDB использует алгоритм Paxos для выбора лидеров.

Инженеры Amazon изначально избегали Dynamo из-за технических накладных расходов, таких как предоставление и управление разделами и узлами. ^[6] В ответ команда DynamoDB создала службу, которая называется AutoAdmin для управления базой данных. ^[30] AutoAdmin заменяет узел, когда он перестает отвечать, копируя данные с другого узла. Когда раздел превышает любой из трех пороговых значений (RCU, WCU или 10 ГБ), AutoAdmin автоматически добавляет дополнительные разделы для дальнейшей сегментации данных. ^[28]

Подобно системам индексации в реляционной модели, DynamoDB требует, чтобы любые обновления таблицы отражались в каждом индексе таблицы. DynamoDB обрабатывает это с помощью службы, которую она называет «пропагатором журнала», которая подписывается на журналы репликации в каждом узле и отправляет дополнительные запросы Put, Update и Delete индексам по мере необходимости. ^[30] Поскольку индексы приводят к существенному снижению производительности для запросов на запись, DynamoDB позволяет пользователю выполнять не более пяти из них для любой заданной таблицы. ^[31]

Предположим, что пользователь DynamoDB запускает операцию записи (Put, Update или Delete). В то время как типичная реляционная система преобразует SQL-запрос в реляционную алгебру и запускает алгоритмы оптимизации, DynamoDB пропускает оба процесса и сразу приступает к работе. ^[30] Запрос поступает на маршрутизатор запросов DynamoDB, который аутентифицирует запрос: «Исходит ли запрос от того/кого, кем он себя выдает?» и проверяет авторизацию: «Имеет ли пользователь, отправляющий запрос, необходимые разрешения?». Если эти проверки пройдены, система хэширует ключ раздела запроса, чтобы поступить в соответствующий раздел. Внутри есть три узла, каждый с копией данных раздела. Сначала система записывает в ведущий узел, затем записывает во второй узел, затем отправляет сообщение об успехе и, наконец, продолжает распространяться на третий узел. Записи являются согласованными, поскольку они всегда сначала проходят через ведущий узел.

Наконец, распространитель журнала распространяет изменение на все индексы. Для каждого индекса он извлекает значение первичного ключа этого индекса из элемента, затем выполняет ту же запись в этот индекс без распространения журнала. Если операция является обновлением для уже существующего элемента, обновленный атрибут может служить первичным ключом для индекса, и, таким образом, дерево B для этого индекса также должно обновиться. Деревья B обрабатывают только операции вставки, удаления и чтения, поэтому на практике, когда распространитель журнала получает операцию обновления, он выполняет как операцию удаления, так и операцию размещения для всех индексов.

Теперь предположим, что пользователь DynamoDB запускает операцию Get. Маршрутизатор запросов продолжает работу, как и прежде, с аутентификацией и авторизацией. Затем, как и выше, мы хэшируем наш ключ раздела, чтобы получить соответствующий хэш. Теперь мы сталкиваемся с проблемой: как решить, какой из трех узлов в конечном итоге согласован друг с другом, какой из них исследовать? DynamoDB предлагает пользователю два варианта при запуске чтения: согласованный и в конечном итоге согласованный. Согласованное чтение посещает ведущий узел. Но компромисс согласованности и доступности здесь снова поднимает голову: в системах с большим объемом чтения постоянное чтение с лидера может перегрузить один узел и снизить доступность.

Второй вариант, в конечном счете согласованное чтение, выбирает случайный узел. На практике, это то, где DynamoDB жертвует согласованностью ради доступности. Если мы пойдем этим путем, каковы шансы на несогласованность? Нам понадобится операция записи, чтобы вернуть «успех» и начать распространение на третий узел, но не закончить. Нам также понадобится наш Get, чтобы нацелиться на этот третий узел. Это означает вероятность несогласованности 1 из 3 в пределах окна распространения операции записи. Какова продолжительность этого окна? Любое количество катастроф может привести к отставанию узла, но в подавляющем большинстве случаев третий узел обновляется в течение миллисекунд от лидера.

• Амазонка Аврора
• Amazon DocumentDB
• Амазонка Редшифт
• Служба реляционной базы данных Amazon
• ScyllaDB (совместимо с DynamoDB)
• Сравнение систем управления реляционными базами данных

• Официальный сайт
• Видео: AWS re:Invent 2019: [ПОВТОР 1] Подробное описание Amazon DynamoDB: Расширенные шаблоны проектирования (DAT403-R1)