Войти
 | |
| Разработчик (и) | Amazon.com |
|---|---|
| Первый выпуск | Январь 2012; 8 лет назад (2012-01) |
| Операционная система | Кросс-платформенная |
| Доступна на | английском языке |
| Тип | |
| Лицензия | Собственный |
| Веб-сайт | aws.amazon.com / Dynamodb / |
Amazon DynamoDB - это полностью управляемый частный NoSQL база данных служба, которая поддерживает пары ключ-значение и структуры данных документов и предлагается Amazon.com как часть портфеля Amazon Web Services. DynamoDB предоставляет аналогичную модель данных и получает свое название от Dynamo, но имеет другую базовую реализацию. Dynamo имел структуру с несколькими мастерами, требующую, чтобы клиент разрешал конфликты версий, а DynamoDB использует синхронную репликацию в нескольких центрах обработки данных для обеспечения высокой надежности и доступности. DynamoDB был анонсирован техническим директором Amazon Вернером Фогельсом 18 января 2012 г. и представлен как эволюция решения Amazon SimpleDB.
Вернер Фогельс, технический директор Amazon.com, послужил мотивацией для проекта в своем объявлении 2012 года. Amazon начинался как децентрализованная сеть услуг. Изначально сервисы имели прямой доступ к базам данных друг друга. Когда это стало узким местом для инженерных операций, сервисы отошли от этого шаблона прямого доступа в пользу общедоступных API. Тем не менее сторонние системы управления реляционными базами данных изо всех сил пытались справиться с клиентской базой Amazon. Это стало кульминацией во время курортного сезона 2004 года, когда несколько технологий вышли из строя из-за высокой посещаемости.
Инженеры нормализовали эти реляционные системы, чтобы уменьшить избыточность данных, проект, оптимизированный для хранения. Жертва: они хранили данный «элемент» данных (например, информацию, относящуюся к продукту в базе данных продуктов) в нескольких отношениях, и требуется время, чтобы собрать непересекающиеся части для запроса. Многие сервисы Amazon требовали в основном чтения данных по первичному ключу, и, поскольку скорость была главным приоритетом, объединение этих частей было чрезвычайно утомительным.
Контент, снижающий эффективность хранения, ответ Amazon был Dynamo : высокодоступное хранилище ключей и значений, созданное для внутреннего использования. Казалось, что «Динамо» - это все, что нужно их инженерам, но его внедрение задержалось. Разработчики Amazon выбрали шаблоны проектирования «просто работает» с S3 и SimpleDB. Хотя эти системы имели заметные конструктивные недостатки, они не требовали дополнительных затрат на подготовку оборудования, масштабирование и повторное разделение данных. Следующая итерация технологии NoSQL от Amazon, DynamoDB, автоматизировала эти операции управления базами данных.
Веб-консоль DynamoDB отличается от других сервисов Amazon тем, что позволяет разработчикам приобретать сервис на основе пропускной способности, а не хранилища. Если автоматическое масштабирование включено, база данных будет автоматически масштабировать. Кроме того, администраторы могут запрашивать изменения пропускной способности, и DynamoDB распределяет данные и трафик по нескольким серверам, используя твердотельные накопители, обеспечивая предсказуемую производительность. Он предлагает интеграцию с Hadoop через Elastic MapReduce.
В сентябре 2013 года Amazon предоставила локальную версию DynamoDB для разработки, чтобы разработчики могли локально тестировать приложения, поддерживаемые DynamoDB.
Обзор веб-консоли Таблица DynamoDB содержит элементы с атрибутами, некоторые из которых образуют первичный ключ. Однако в реляционных системах элемент имеет каждый атрибут таблицы (или жонглирует «нулевыми» и «неизвестными» значениями в их отсутствие), элементы DynamoDB не имеют схемы. Единственное исключение: при создании таблицы разработчик указывает первичный ключ, а таблица требует ключ для каждого элемента. Первичные ключи должны быть скалярными (строки, числа или двоичные ) и могут принимать одну из двух форм. Первичный ключ с одним атрибутом известен как «ключ раздела» таблицы, который определяет раздел, который элемент хеширует в –– больше при разбиении ниже ––, поэтому идеальный ключ раздела имеет равномерное распределение по его спектр. Первичный ключ также может содержать второй атрибут, который DynamoDB называет «ключом сортировки» таблицы. В этом случае ключи разделов не обязательно должны быть уникальными; они сочетаются с ключами сортировки, чтобы создать уникальный идентификатор для каждого элемента. Ключ раздела по-прежнему используется для определения раздела, в котором хранится элемент, но в каждом разделе элементы сортируются по ключу сортировки.
В реляционной модели индексы обычно служат «вспомогательными» структурами данных для дополнения таблицы. Они позволяют СУБД внутренне оптимизировать запросы и не улучшают функциональность запросов. В DynamoDB нет оптимизатора запросов , а индекс - это просто другая таблица с другим ключом (или двумя), которая находится рядом с исходной. Когда разработчик создает индекс, он создает новую копию своих данных, но только те поля, которые они указали, копируются (как минимум, поля, которые они индексируют, и первичный ключ исходной таблицы).
Пользователи DynamoDB отправляют запросы непосредственно к своим индексам. Доступны два типа индексов. Глобальный вторичный индекс содержит ключ раздела (и необязательный ключ сортировки), отличный от ключа раздела исходной таблицы. Локальный вторичный индекс имеет тот же ключ раздела, что и исходная таблица, но другой ключ сортировки. Оба индекса вводят совершенно новую функциональность запросов в базу данных DynamoDB, разрешая запросы по новым ключам. Подобно системам управления реляционными базами данных, DynamoDB автоматически обновляет индексы при добавлении / обновлении / удалении, поэтому вы должны быть осторожны при их создании, иначе вы рискуете замедлить работу базы данных с большим объемом записи за счет множества обновлений индексов.
DynamoDB использует JSON в качестве синтаксиса из-за его повсеместного распространения. Действие создания таблицы требует всего трех аргументов: TableName, KeySchema –– список, содержащий ключ раздела и необязательный ключ сортировки –– и AttributeDefinitions –– список атрибутов, которые необходимо определить, которые должны как минимум содержать определения для атрибутов, используемых в качестве раздела. и ключи сортировки. В то время как реляционные базы данных предлагают надежные языки запросов, DynamoDB предлагает только операции Put, Get, Update и Delete. Запросы на размещение содержат атрибут 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 обрабатывает это с помощью службы, которую он называет «распространителем журналов», который подписывается на журналы репликации в каждом узле и при необходимости отправляет дополнительные запросы на размещение, обновление и удаление в индексы. Поскольку индексы приводят к значительному снижению производительности для запросов на запись, DynamoDB разрешает пользователю не более пяти из них для любой данной таблицы.
Предположим, что пользователь DynamoDB выполняет операцию записи ( Положить, Обновить или Удалить). В то время как типичная реляционная система преобразует запрос SQL в реляционную алгебру и выполняет алгоритмы оптимизации, DynamoDB пропускает оба процесса и сразу приступает к работе. Запрос поступает на маршрутизатор запросов DynamoDB, который аутентифицирует –– «Запрос исходит от того, откуда / кем он заявляется?» –– и проверяет авторизацию –– «Имеет ли пользователь, отправляющий запрос, необходимые разрешения?» Если эти проверки пройдены, система хеширует ключ раздела запроса, чтобы прибыть в соответствующий раздел. Внутри есть три узла, каждый с копией данных раздела. Система сначала записывает в ведущий узел, затем записывает во второй узел, затем отправляет сообщение об успешном завершении и, наконец, продолжает распространение на третий узел. Записи согласованы, потому что они всегда сначала проходят через ведущий узел.
Наконец, распространитель журнала распространяет изменение на все индексы. Для каждого индекса он получает значение первичного ключа этого индекса из элемента, а затем выполняет ту же запись в этот индекс без распространения журнала. Если операция представляет собой обновление уже существующего элемента, обновленный атрибут может служить первичным ключом для индекса, и, следовательно, B-дерево для этого индекса также должно обновляться. B-деревья обрабатывают только операции вставки, удаления и чтения, поэтому на практике, когда распространитель журнала получает операцию обновления, он выдает и операцию удаления, и операцию размещения для всех индексов.
Теперь предположим, что пользователь DynamoDB выполняет операцию Get. Маршрутизатор запросов продолжает аутентификацию и авторизацию, как и раньше. Затем, как указано выше, мы хэшируем наш ключ раздела, чтобы получить соответствующий хеш. Теперь мы сталкиваемся с проблемой: если три узла в конечном итоге согласованы друг с другом, как мы можем решить, какие из них исследовать? DynamoDB предоставляет пользователю два варианта выполнения чтения: согласованный и в конечном итоге согласованный. Последовательное чтение посещает узел лидера. Но компромисс между согласованностью и доступностью снова поднимает голову: в системах с интенсивным чтением постоянное чтение от лидера может привести к перегрузке одного узла и снижению доступности.
Второй вариант, в конечном итоге согласованное чтение, выбирает случайный узел. На практике именно здесь DynamoDB жертвует согласованностью на доступность. Если мы пойдем по этому пути, каковы шансы на несоответствие? Нам понадобится операция записи, чтобы вернуть «успех» и начать распространение на третий узел, но не завершить. Нам также понадобится наш Get для нацеливания на этот третий узел. Это означает, что вероятность несогласованности в пределах окна распространения операции записи составляет 1 к 3. Как долго это окно? Любое количество катастроф может привести к отставанию узла, но в подавляющем большинстве случаев третий узел обновляется в пределах миллисекунд от лидера.
Вкладка «Емкость», масштабирование DynamoDB предоставляет метрики производительности, которые помогают пользователям правильно подготавливать его и обеспечивать бесперебойную работу приложений, использующих DynamoDB:
Эти метрики можно отслеживать с помощью Консоли управления AWS, используя интерфейс командной строки AWS или инструмент мониторинга, интегрирующийся с Amazon CloudWatch.
.
Языки и платформы с привязкой DynamoDB включают Java, JavaScript, Node.js, Go, C# .NET, Perl, PHP, Python, Ruby, Haskell, Erlang, Django и Grails.
AWS DynamoDB : представление элементов В отличие от HTTP API, элементы запроса:
POST / HTTP / 1.1 Хост: Dynamodb.. ; Accept-Encoding: идентификатор Content-Length: User-Agent: Content-Type: application / x-amz-json-1.0 Авторизация: AWS4-HMAC-SHA256 Credential = , SignedHeaders = , Signature = X-Amz-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": "Пользователь A"}, ": v2b": {"S": "Пользователь C"}}, "ReturnConsumedCapacity": "ИТОГО "}
Пример ответа:
HTTP / 1.1 200 OK x-amzn-RequestId:x-amz-crc32: Content-Type: application / x-amz-json-1.0 Content-Length : Дата: {"ConsumedCapacity": {"CapacityUnits": 1, "TableName": "Reply"}, "Count": 2, "Items": [{"ReplyDateTime": {"S" : "2015-02-18T20: 27: 36.165Z"}, "PostedBy": {"S": "Пользователь A"}, "Id": {"S": "Amazon DynamoDB # DynamoDB Thr ead 1 "}}, {" ReplyDateTime ": {" S ":" 2015-02-25T20: 27: 36.165Z "}," PostedBy ": {" S ":" Пользователь B "}," Id ": { "S": "Amazon DynamoDB # DynamoDB Thread 1"}}], "ScannedCount": 2}
GetItem в Go :
getItemInput: = DynamoDb.GetItemInput {TableName: aws.String ("счастливый маркетолог"), Ключ: map [строка] * Dynamodb.AttributeValue {"pk": {S: aws.String ("project"),}, "sk": {S: aws.String (email + "" + name),}, },} getItemOutput, err: = DynamodbClient.GetItem (getItemInput)DeleteItem в Go :
deleteItemInput: = Dynamodb.DeleteItemInput {TableName: aws.String ("счастливый маркетолог"), ключ: map [строка] * Dynamodb.AttributeValue {"pk": {S: aws.String ("project"),}, "sk": {S: aws.String (электронная почта + "" + имя),},},} _, err: = DynamodbClient.DeleteItem (deleteItemInput) if err! = nil {panic (err)}UpdateItem в Go с использованием Expression Builder :
update: = expression.Set (expression.Name (name), expression.Value (значение),) expr, err: = expression.NewBuilder (). WithUpdate (update).Build () if err! = Nil {pan ic (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)}