Амазон ДинамоБД

Амазон ДинамоБД

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

Amazon DynamoDB — это полностью управляемая проприетарная NoSQL, база данных предлагаемая Amazon.com как часть портфеля Amazon Web Services . DynamoDB предлагает быстрое постоянное хранилище данных «ключ-значение» со встроенной поддержкой репликации , автомасштабирования , шифрования при хранении и резервного копирования по требованию, а также других функций.

Фон

Вернер Фогельс , технический директор Amazon.com, мотивировал проект в своем объявлении в 2012 году. Amazon начинался как децентрализованная сеть сервисов. Первоначально сервисы имели прямой доступ к базам данных друг друга. Когда это стало узким местом в инженерных операциях, сервисы отошли от этого шаблона прямого доступа в пользу общедоступных API . Тем не менее, сторонние системы управления реляционными базами данных с трудом справлялись с клиентской базой Amazon. Кульминацией этого стал период 2004 г. сезон отпусков, когда несколько технологий вышли из строя из-за большого трафика.

Инженеры нормализовали эти реляционные системы, чтобы уменьшить избыточность данных , и эта конструкция оптимизирует хранение. Жертва: они сохранили заданный «элемент» данных (например, информацию, относящуюся к продукту в базе данных продуктов) в нескольких отношениях, и сбор непересекающихся частей для запроса требует времени. Многие сервисы Amazon требовали в основном чтения данных по первичному ключу, а поскольку скорость была главным приоритетом, объединение этих частей было чрезвычайно трудоемким.

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

Обзор

Веб-консоль

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

Таблицы DynamoDB

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

Элементы DynamoDB

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

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

Ключи в DynamoDB

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

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

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

Типы данных DynamoDB

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

Индексы DynamoDB

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

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

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

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

Соображения развития

Синтаксис

DynamoDB использует JSON в качестве синтаксиса из-за его повсеместного распространения. Для действия создания таблицы требуется всего три аргумента: TableName, KeySchema — список, содержащий ключ раздела и необязательный ключ сортировки, — и AttributeDefinitions — список определяемых атрибутов, который должен как минимум содержать определения атрибутов, используемых в качестве раздела. и сортировать ключи. В то время как реляционные базы данных предлагают надежные языки запросов, DynamoDB предлагает только операции «Поместить», «Получить», «Обновить» и «Удалить». Запросы на размещение содержат атрибут TableName и атрибут Item, который состоит из всех атрибутов и значений, которые имеет элемент. Запрос на обновление имеет тот же синтаксис. Аналогично, чтобы получить или удалить элемент, просто укажите TableName и Key.

Архитектура системы

Таблица создания в DynamoDB

Структуры данных

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

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

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

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

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

Выполнение запроса

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

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

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

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

Производительность

Вкладка «Емкость», масштабирование

DynamoDB предоставляет показатели производительности, которые помогают пользователям правильно подготовить его и обеспечить бесперебойную работу приложений, использующих DynamoDB:

• Запросы и регулирование
• Ошибки : ProvisionedThroughputExceededException, ConditionalCheckFailedException, внутренняя ошибка сервера (HTTP 500).
• Метрики, связанные с глобального вторичного индекса созданием

Эти метрики можно отслеживать с помощью консоли управления AWS AWS , интерфейса командной строки или инструмента мониторинга, интегрируемого с Amazon CloudWatch .

Лучшие практики

Разработчики DynamoDB должны:

• Определить шаблоны доступа к данным
• Используйте события вместо опроса

Языковые привязки

DynamoDB Языки и платформы с привязкой включают Java , JavaScript , Node.js , Go , C# .NET , Perl , PHP , Python , Ruby , Rust , Haskell , Erlang , Django и Grails .

Примеры кода

AWS DynamoDB: просмотр элементов

HTTP API

В отношении HTTP API элементы запроса:

POST / HTTP/1.1
Host: dynamodb.<region>.<domain>;
Accept-Encoding: identity
Content-Length: <PayloadSizeBytes>
User-Agent: <UserAgentString>
Content-Type: application/x-amz-json-1.0
Authorization: AWS4-HMAC-SHA256 Credential=<Credential>, SignedHeaders=<Headers>, Signature=<Signature>
X-Amz-Date: <Date>
X-Amz-Target: DynamoDB_20120810.Query

{
    "TableName": "Reply",
    "IndexName": "PostedBy-Index",
    "Limit": 3,
    "ConsistentRead": true,
    "ProjectionExpression": "Id, PostedBy, ReplyDateTime",
    "KeyConditionExpression": "Id = :v1 AND PostedBy BETWEEN :v2a AND :v2b",
    "ExpressionAttributeValues": {
        ":v1": {"S": "Amazon DynamoDB#DynamoDB Thread 1"},
        ":v2a": {"S": "User A"},
        ":v2b": {"S": "User C"}
    },
    "ReturnConsumedCapacity": "TOTAL"
}

Пример ответа:

HTTP/1.1 200 OK
x-amzn-RequestId: <RequestId>
x-amz-crc32: <Checksum>
Content-Type: application/x-amz-json-1.0
Content-Length: <PayloadSizeBytes>
Date: <Date>
 {
    "ConsumedCapacity": {
        "CapacityUnits": 1,
        "TableName": "Reply"
    },
    "Count": 2,
    "Items": [
        {
            "ReplyDateTime": {"S": "2015-02-18T20:27:36.165Z"},
            "PostedBy": {"S": "User A"},
            "Id": {"S": "Amazon DynamoDB#DynamoDB Thread 1"}
        },
        {
            "ReplyDateTime": {"S": "2015-02-25T20:27:36.165Z"},
            "PostedBy": {"S": "User B"},
            "Id": {"S": "Amazon DynamoDB#DynamoDB Thread 1"}
        }
    ],
    "ScannedCount": 2
}

Идти

GetItem в Go :

getItemInput := &dynamodb.GetItemInput{
	TableName: aws.String("happy-marketer"),
	Key: map[string]*dynamodb.AttributeValue{
		"pk": {
			S: aws.String("project"),
		},
		"sk": {
			S: aws.String(email + " " + name),
		},
	},
}
getItemOutput, err := dynamodbClient.GetItem(getItemInput)

Удалить элемент в Go :

deleteItemInput := &dynamodb.DeleteItemInput{
	TableName: aws.String("happy-marketer"),
	Key: map[string]*dynamodb.AttributeValue{
		"pk": {
			S: aws.String("project"),
		},
		"sk": {
			S: aws.String(email + " " + name),
		},
	},
}

_, err := dynamodbClient.DeleteItem(deleteItemInput)
if err != nil {
	panic(err)
}

UpdateItem в Go с помощью Expression Builder :

update := expression.Set(
	expression.Name(name),
	expression.Value(value),
)

expr, err := expression.NewBuilder().WithUpdate(update).Build()
if err != nil {
	panic(err)
}

updateItemInput := &dynamodb.UpdateItemInput{
	TableName: aws.String(tableName),
	Key: map[string]*dynamodb.AttributeValue{
		"pk": {
			S: aws.String("project"),
		},
		"sk": {
			S: aws.String("mySortKeyValue"),
		},
	},
	UpdateExpression:          expr.Update(),
	ExpressionAttributeNames:  expr.Names(),
	ExpressionAttributeValues: expr.Values(),
}
fmt.Printf("updateItemInput: %#v\n", updateItemInput)

_, err = dynamodbClient.UpdateItem(updateItemInput)
if err != nil {
	panic(err)
}

См. также

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

Внешние ссылки

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