Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску
Amazon DynamoDB
DynamoDB.png
Разработчики)Amazon.com
изначальный выпускЯнварь 2012 г . ; 9 лет назад [1] ( 2012-01 )
Операционная системаКроссплатформенность
Доступно ванглийский
Тип
ЛицензияПроприетарный
Интернет сайтaws .amazon .com / Dynamodb /

Amazon DynamoDB - это полностью управляемая проприетарная служба баз данных NoSQL, которая поддерживает структуры данных « ключ-значение» и документы [2] и предлагается Amazon.com как часть портфеля Amazon Web Services . [3] DynamoDB предоставляет аналогичную модель данных и получает свое название от Dynamo , но имеет другую базовую реализацию. Dynamo имел многопользовательский дизайн, требующий от клиента разрешения конфликтов версий, а DynamoDB использует синхронную репликацию в нескольких центрах обработки данных [4] для обеспечения высокой надежности и доступности. DynamoDB анонсировал технический директор Amazon Вернер Фогельс18 января 2012 г. [5] и представлен как эволюция решения Amazon SimpleDB . [6]

Фон [ править ]

Вернер Фогельс (Werner Vogels) , технический директор Amazon.com, в своем объявлении 2012 года мотивировал этот проект. [5] Amazon начинался как децентрализованная сеть услуг. Изначально сервисы имели прямой доступ к базам данных друг друга. Когда это стало узким местом для инженерных операций, сервисы отошли от этой схемы прямого доступа в пользу общедоступных API . Тем не менее, сторонние системы управления реляционными базами данных изо всех сил пытались справиться с клиентской базой Amazon. Это стало кульминацией во время курортного сезона 2004 года, когда несколько технологий вышли из строя в условиях высокой загруженности.

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

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

Обзор [ править ]

Веб-консоль

DynamoDB отличается от других сервисов Amazon тем, что позволяет разработчикам приобретать сервис на основе пропускной способности , а не хранилища . Если автоматическое масштабирование включено, база данных будет масштабироваться автоматически. [8] Кроме того, администраторы могут запрашивать изменения пропускной способности, и DynamoDB распределяет данные и трафик по нескольким серверам с помощью твердотельных накопителей , обеспечивая предсказуемую производительность. [3] Он предлагает интеграцию с Hadoop через Elastic MapReduce . [9]

В сентябре 2013 года Amazon предоставила локальную версию DynamoDB для разработки, чтобы разработчики могли локально тестировать приложения, поддерживаемые DynamoDB. [10]

Соображения по поводу развития [ править ]

Моделирование данных [ править ]

Обзор веб-консоли

Таблица DynamoDB содержит элементы, у которых есть атрибуты, некоторые из которых образуют первичный ключ . [11] В реляционных системах, однако, элемент имеет каждый атрибут таблицы (или жонглирует «нулевыми» и «неизвестными» значениями в их отсутствие), элементы DynamoDB не имеют схемы. Единственное исключение: при создании таблицы разработчик указывает первичный ключ, а таблица требует ключ для каждого элемента. Первичные ключи должны быть скалярными ( строковыми , числовыми или двоичными ) и могут принимать одну из двух форм. Первичный ключ с одним атрибутом известен как «ключ раздела» таблицы, который определяет раздел, хэшируемый элементом.к –– подробнее о разделении ниже –– так, чтобы идеальный ключ раздела имел равномерное распределение по всему диапазону. Первичный ключ также может содержать второй атрибут, который DynamoDB называет «ключом сортировки» таблицы. В этом случае ключи разделов не обязательно должны быть уникальными; они сочетаются с ключами сортировки, чтобы создать уникальный идентификатор для каждого элемента. Ключ раздела по-прежнему используется для определения раздела, в котором хранится элемент, но в каждом разделе элементы сортируются по ключу сортировки.

Индексы [ править ]

В реляционной модели индексы обычно служат «вспомогательными» структурами данных для дополнения таблицы. Они позволяют СУБД оптимизировать внутренние запросы и не улучшают функциональность запросов. В DynamoDB нет оптимизатора запросов , а индекс - это просто другая таблица с другим ключом (или двумя), которая находится рядом с исходной. [11] Когда разработчик создает индекс, он создает новую копию своих данных, но копируются только те поля, которые они указали (как минимум, поля, которые они индексируют, и первичный ключ исходной таблицы).

Пользователи 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). [12] Один RCU представляет одно строго согласованное чтение в секунду или два в конечном итоге согласованных чтения в секунду для элементов размером до 4 КБ. [11] Один WCU соответствует одной записи в секунду для элемента размером до 1 КБ.

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

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

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

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

Выполнение запроса [ править ]

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

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

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

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

Производительность [ править ]

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

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

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

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


Привязки языков [ править ]

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

Примеры кода [ править ]

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

HTTP API [ править ]

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

POST  /  HTTP / 1.1 Хост :  Dynamodb. <Регион>. <Домен>; Accept-Encoding :  идентификатор Content-Length :  <PayloadSizeBytes> User-Agent :  <UserAgentString> Content-Type :  application / x-amz-json-1.0 Authorization :  AWS4-HMAC-SHA256 Credential = <Credential>, SignedHeaders = <Headers> , Подпись = <Подпись> X-Amz-Date :  <Дата> X-Amz-Target :  DynamoDB_20120810.Query{ "TableName": "Ответить", "IndexName": "PostedBy-Index", «Лимит»: 3, "ConsistentRead": правда, "ProjectionExpression": "Id, PostedBy, ReplyDateTime", "KeyConditionExpression": "Id =: v1 И РАЗРЕШЕНО МЕЖДУ: v2a И: v2b", "ExpressionAttributeValues": { ": v1": {"S": "Amazon DynamoDB # DynamoDB Thread 1"}, ": v2a": {"S": "Пользователь A"}, ": v2b": {"S": "Пользователь C"} }, «ReturnConsumedCapacity»: «ИТОГО»}

Образец ответа:

HTTP / 1.1  200  OK x-amzn-RequestId :  <RequestId> x-amz-crc32 :  <Checksum> Content-Type :  application / x-amz-json-1.0 Content-Length :  <PayloadSizeBytes> Дата :  <Дата>  {  " ConsumedCapacity ": {  " CapacityUnits ": 1,  " TableName ":" Reply "  },  " Count ": 2,  " Items ": [  {  " ReplyDateTime ": {" S ":" 2015-02-18T20: 27: 36.165 Z "},  " PostedBy ": {" S ":" Пользователь A "},  " Id ": {" S ":"Amazon DynamoDB # DynamoDB Thread 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 . Строка ( "счастливый маркетолог" ), Ключ :  map [ строка ] * Dynamodb . AttributeValue { "pk" :  { S :  aws . String ( "проект" ), }, "sk" :  { S :  aws . Строка ( электронная почта  +  ""  +  имя), }, }, } getItemOutput ,  err  : =  DynamodbClient . GetItem ( getItemInput )

DeleteItem в Go :

deleteItemInput  : =  & Dynamodb . DeleteItemInput { TableName :  aws . Строка ( "счастливый маркетолог" ), Ключ :  map [ строка ] * Dynamodb . AttributeValue { "pk" :  { S :  aws . String ( "проект" ), }, "sk" :  { S :  aws . Строка ( электронная почта  +  ""  + имя ), }, }, }_ ,  Эээ  : =  dynamodbClient . DeleteItem ( deleteItemInput ) if  err  ! =  Nil  { panic ( err ) }

UpdateItem в Go с помощью построителя выражений :

обновление  : =  выражение . Набор ( выражение . Имя ( имя ), выражение . Значение ( значение ), )expr ,  err  : =  выражение . NewBuilder (). WithUpdate ( обновление ). Build (), если  ошибка  ! =  Ноль  { паника ( ошибка ) }updateItemInput  : =  & Dynamodb . UpdateItemInput { TableName :  aws . Строка ( имя_таблицы ), ключ :  карта [ строка ] * динамодб . AttributeValue { "pk" :  { S :  aws . String ( "проект" ), }, "sk" :  { S :  aws . String ( "mySortKeyValue" ), }, },UpdateExpression :  выражение . Update (), ExpressionAttributeNames :  expr . Имена (), ExpressionAttributeValues :  expr . Значения (), } fmt . Printf ( "updateItemInput:% # v \ n" ,  updateItemInput )_ ,  Эээ  =  dynamodbClient . UpdateItem ( updateItemInput ) if  err  ! =  Nil  { panic ( err ) }

См. Также [ править ]

  • Амазонка Аврора
  • Amazon DocumentDB (с совместимостью с MongoDB)
  • Амазонка Redshift
  • Сервис реляционной базы данных Amazon

Ссылки [ править ]

  1. ^ «Amazon DynamoDB - быстрая и масштабируемая служба баз данных NoSQL, разработанная для приложений Интернет-масштаба - все распределено» . www.allthingsdistributed.com .
  2. ^ «Amazon DynamoDB - Часто задаваемые вопросы» . Amazon Web Services, Inc .
  3. ^ a b Кларк, Джек (19 января 2012 г.). «Amazon включает облачную службу баз данных DynamoDB» . ZDNet . Проверено 21 января 2012 .
  4. ^ «Часто задаваемые вопросы: масштабируемость, доступность и надежность» . Amazon Web Services .
  5. ^ a b c Фогельс, Вернер (18 января 2012 г.). «Amazon DynamoDB - быстрая и масштабируемая служба баз данных NoSQL, разработанная для масштабируемых Интернет-приложений» . Блог All Things Distributed . Проверено 21 января 2012 .
  6. ^ «Amazon DynamoDB - Часто задаваемые вопросы» . Amazon Web Services, Inc . Проверено 3 июня 2019 .
  7. ^ a b DeCandia, Джузеппе; Хасторун, Дениз; Джампани, Мадан; Какулапати, Гунавардхан; Лакшман, Авинаш; Пильчин, Алексей; Сивасубраманиан, Сваминатан; Фосхолл, Питер; Фогельс, Вернер (октябрь 2007 г.). «Dynamo: высокодоступный магазин ключей и значений Amazon». SIGOPS Oper. Syst. Ред . 41 (6): 205–220. DOI : 10.1145 / 1323293.1294281 . ISSN 0163-5980 . 
  8. ^ «Автоматическое управление пропускной способностью с помощью DynamoDB Auto Scaling» . Amazon DynamoDB . Проверено 5 июля 2017 .
  9. ↑ Грей, Адам (25 января 2012 г.). «AWS HowTo: Использование Amazon Elastic MapReduce с DynamoDB (гостевая статья)» . Новостной блог AWS . Проверено 29 октября 2019 года .
  10. ^ «DynamoDB Local для разработки настольных компьютеров» . Amazon Web Services . 12 сентября 2013 . Проверено 13 сентября 2013 года .
  11. ^ a b c «Руководство разработчика Amazon DynamoDB» . AWS . 10 августа 2012 . Проверено 18 июля 2019 года .
  12. ^ a b Гунасекара, Арчи (27.06.2016). «Глубокое погружение в разделы DynamoDB» . Группа Shine Solutions . Проверено 3 августа 2019 .
  13. ^ a b c d AWS re: Invent 2018: Amazon DynamoDB под капотом: как мы создали гипермасштабируемую базу данных (DAT321) , получено 3 августа 2019 г.
  14. ^ «Лучшие показатели производительности DynamoDB» .
  15. ^ «Как собирать метрики DynamoDB» .
  16. ^ "Библиотеки, картографы и макетные реализации Amazon DynamoDB в изобилии!" . Amazon Web Services .

Внешние ссылки [ править ]

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