Вопрос: Что такое Amazon DynamoDB?

Amazon DynamoDB – это полностью управляемый сервис баз данных NoSQL, обеспечивающий прогнозируемую высокую производительность с эффективной масштабируемостью. Amazon DynamoDB дает клиентам возможность переложить на AWS административную нагрузку, связанную с управлением распределенными базами данных и их масштабированием, и, как следствие, избавиться от необходимости выделения оборудования, его настройки и конфигурирования, репликации, обновления ПО, планирования ресурсов для поддержания необходимой пропускной способности и масштабирования кластеров.

Вопрос: Какие виды управления берет на себя Amazon DynamoDB?

Amazon DynamoDB позволяет решить одну из ключевых проблем при работе с базами данных: их масштабирование, управление ПО баз данных и выделение аппаратного обеспечения, необходимого для работы баз данных. Клиенты могут развертывать нереляционные базы данных всего за несколько минут. Сервис DynamoDB автоматически масштабирует пропускную способность для соответствия требованиям рабочей нагрузки и способен многократно разбивать данные по мере расширения таблицы. Кроме того, Amazon DynamoDB выполняет синхронную репликацию данных на трех серверах региона AWS, обеспечивая высокую доступность и сохранность данных.

Вопрос: Что означает непротиворечивость чтения? Почему она важна?

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

Вопрос: Какая модель непротиворечивости работает в Amazon DynamoDB?

При чтении данных из баз Amazon DynamoDB пользователи могут указать модель непротиворечивости чтения: потенциально непротиворечивое или строго непротиворечивое.

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

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

Вопрос: Поддерживает ли DynamoDB местные атомарные обновления?

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

Вопрос: Почему Amazon DynamoDB использует в своей работе твердотельные накопители?

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

Вопрос: Стоимость хранилища в сервисе DynamoDB довольно высока. Будет ли этот сервис экономически эффективным в моем случае использования?

Как и в случае с любым другим продуктом, мы рекомендуем потенциальным клиентам Amazon DynamoDB оценивать полную стоимость решения, а не конкретный ценовой аспект. Полная стоимость обслуживания рабочих нагрузок баз данных складывается из требований к трафику запросов и количеству сохраняемых данных. Рабочие нагрузки большинства баз данных требуют высокой производительности операций ввода-вывода (чтения и записи в секунду) из расчета на гигабайт сохраненных данных. Amazon DynamoDB использует в своей работе SSD-накопители, стоимость хранения гигабайта данных на которых выше, чем на дисковых накопителях, но при этом они позволяют добиться крайне низкой стоимости запросов. На основании исследования типичных рабочих нагрузок баз данных мы полагаем, что суммарная стоимость использования сервиса DynamoDB на SSD-накопителях, обычно оказывается ниже, чем стоимость использования реляционных и нереляционных баз данных, работающих на базе традиционных дисковых накопителей. Если ваш пример использования подразумевает хранение больших объемов данных, к которым редко осуществляется доступ, то сервис DynamoDB действительно может быть не лучшим вариантом. В таких случаях мы рекомендуем воспользоваться сервисом S3.

Стоит также учесть, что стоимость хранилища отражает стоимость хранения нескольких копий каждого из элементов данных на нескольких серверах в рамках региона AWS.

Вопрос: DynamoDB применим только для крупномасштабных приложений?

Нет. DynamoDB предлагает эффективное масштабирование, которое позволяет автоматически корректировать масштаб по мере изменения требований приложения. Если вам требуется высокая и предсказуемая производительность вне зависимости от масштаба, сервис DynamoDB подойдет вам как нельзя лучше.

Вопрос: Как начать использовать Amazon DynamoDB?

Нажмите кнопку «Зарегистрироваться», чтобы начать работу с Amazon DynamoDB уже сегодня. После этого вы сможете работать с Amazon DynamoDB либо через Консоль управления AWS, либо посредством API Amazon DynamoDB. При использовании Консоли управления AWS создать таблицу в Amazon DynamoDB и начать работу с ней можно всего за несколько щелчков.

Вопрос: Какие функциональные возможности запросов поддерживает DynamoDB?

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

Первичный ключ может быть либо простым ключом секции (состоящим из одного атрибута), либо составным (состоящим из ключа секции и ключа сортировки). Пример первичного простого (состоящего из одного атрибута) ключа секции – UserID. Он позволит быстро выполнять чтение и запись данных для элемента, связанного с конкретным ID пользователя.

Составной ключ секции и сортировки строится по элементу ключа секции и элементу ключа сортировки. Этот сложный ключ поддерживает иерархию между первым и вторым значениями элемента. Например, составной ключ секции и сортировки может представлять собой комбинацию UserID (секция) и Timestamp (сортировка). Поддерживая значение элемента ключа секции постоянным, можно выполнять поиск по элементу ключа сортировки для извлечения определенных данных. Это позволит использовать API Query, например, для извлечения всех объектов для одного UserID в определенном диапазоне временных меток.

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

 

Вопрос: Каким образом выполняется обновление и запрос элементов данных в Amazon DynamoDB?

После создания таблицы с помощью Консоли управления AWS или API CreateTable можно использовать API PutItem или BatchWriteItem для вставки элементов. Для извлечения элементов, добавленных в таблицу, можно использовать такие API, как GetItem, BatchGetItem или Query, если сложные первичные ключи включены и используются в таблице.

Вопрос: Поддерживает ли Amazon DynamoDB условные операции?

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

  • Логические функции: ATTRIBUTE_EXIST, CONTAINS и BEGINS_WITH.
  • Операторы сравнения: =, <>, <, >, <=, >=, BETWEEN и IN.
  • Логические операторы: NOT, AND и OR. 

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

Вопрос: Поддерживаются ли выражения для ключевых условий?

Да, вы можете задать выражение в виде части вызова API Query, чтобы отфильтровать результаты на основании значений первичных ключей таблицы с помощью параметра KeyConditionExpression.

Вопрос: Поддерживаются ли выражения для ключей секций и ключей секций и сортировки?

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

Вопрос: Поддерживает ли Amazon DynamoDB операции увеличения и уменьшения?

Да, Amazon DynamoDB поддерживает атомарные операции увеличения и уменьшения скалярных значений.

Вопрос: В каких случаях следует использовать сервис Amazon DynamoDB, а в каких – движок реляционных БД в Amazon RDS или Amazon EC2?

Современные веб-приложения создают и потребляют огромные объемы данных. Например, онлайн-игра может стартовать с несколькими сотнями пользователей и низкими рабочими нагрузками БД, состоящими из 10 операций записи в секунду и 50 операций чтения в секунду. Однако если игра станет успешной, количество пользователей может возрасти до нескольких миллионов, а количество операций чтения и записи – до нескольких десятков (а то и сотен) тысяч в секунду. К тому же она может генерировать несколько терабайтов данных в сутки. При разработке приложения в Amazon DynamoDB вы сможете начать работу в небольшом масштабе, а затем по мере роста требований, не останавливая работу, просто увеличить выделенные ресурсы запросов для своей таблицы. Вы будете оплачивать выделенные ресурсы запросов по очень экономичным тарифам, а Amazon DynamoDB самостоятельно выполнит работу по распределению данных и трафика, выделив необходимые серверные ресурсы для решения ваших задач. Amazon DynamoDB управляет базами данных и администрирует их, чтобы вы могли просто сохранять и извлекать данные. Автоматическая репликация и обработка отказов обеспечивают встроенную отказоустойчивость, высокую доступность и сохранность данных. Благодаря сервису Amazon DynamoDB вам не придется заботиться об администрировании базы данных, которая будет расти по мере роста требований вашего приложения.

Amazon DynamoDB решает основные проблемы, связанные с масштабированием, управлением, производительностью и надежностью баз данных, но при этом он не обладает полной функциональностью реляционных баз данных. Сервис не поддерживает комплексные реляционные запросы (например, соединения) или комплексные транзакции. Если ваши рабочие нагрузки используют эти функциональные возможности, или если вам необходимо обеспечить совместимость с существующим реляционным движком, возможно, вам потребуется запустить реляционный движок в сервисе Amazon RDS или Amazon EC2. Движки реляционных БД обладают широкими возможностями и функционалом, но при этом масштабирование рабочих нагрузок за рамки одного инстанса реляционной БД является чрезвычайно сложным процессом, который требует опыта и значительных затрат времени. Таким образом, если вам необходимо обеспечить масштабирование нового приложения и не требуются реляционные функции, Amazon DynamoDB может стать лучшим решением.

Вопрос: Чем Amazon DynamoDB отличается от Amazon SimpleDB?

Какой из сервисов мне лучше использовать? Оба сервиса – это сервисы нереляционных баз данных, не требующие администрирования. Amazon DynamoDB предоставляет более широкие возможности непрерывного масштабирования и стабильно высокую производительность. Использование твердотельных накопителей (SSD) позволяет снизить время задержки отклика, а ограничения на ресурсоемкость запроса или размер хранилища для таблицы отсутствуют. Это связано с тем, что Amazon DynamoDB автоматически распределяет данные и рабочую нагрузку по достаточному количеству серверов с целью соответствия потребностям в ресурсах. Напротив, для таблицы Amazon SimpleDB размер хранилища ограничивается 10 ГБ; ограничения накладываются и на ресурсы запросов (как правило, не более 25 записей в секунду). Распределение и перераспределение данных по дополнительным таблицам SimpleDB при возникновении потребности в дополнительных ресурсах вы можете выполнять по своему усмотрению. В связи с ограничениями масштабирования SimpleDB будет удачным решением в случае небольших рабочих нагрузок, требующих гибкости запросов. Amazon SimpleDB автоматически индексирует все атрибуты элементов, тем самым поддерживая гибкость запросов за счет уровня производительности и масштабируемости.

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

Вопрос: В каких случаях следует использовать Amazon DynamoDB, а в каких – Amazon S3?

Amazon DynamoDB сохраняет структурированные данные, индексированные по первичному ключу, и обеспечивает низкие задержки при выполнении операций чтения и записи элементов размером от 1 байта до 400 КБ. Amazon S3 сохраняет неструктурированные BLOB-объекты данных и подходит для хранения крупных объектов размером до 5 ТБ. В целях сокращения затрат на сервисы AWS большие объекты или редко используемые наборы данных лучше хранить в Amazon S3, а меньшие элементы данных или указатели файлов (в т. ч. на объекты в Amazon S3) – в Amazon DynamoDB.

Вопрос: DynamoDB можно использовать с приложениями, работающими под управлением любых операционных систем?

Да. DynamoDB – это полностью управляемый облачный сервис, доступ к которому осуществляется через API. DynamoDB может использоваться приложениями, работающими под управлением любых операционных систем (например, Linux, Windows, iOS, Android, Solaris, AIX, HP-UX и т. д.). Для начала работы с DynamoDB мы рекомендуем использовать SDK AWS. Перечень SDK AWS можно найти на странице Ресурсы для разработчиков. Если у вас возникли проблемы с установкой или использованием наших SDK, сообщите нам об этом в соответствующем разделе форума AWS.


Вопрос: Что такое модель данных?

В Amazon DynamoDB используются следующие модели данных.

Таблица: представляет собой совокупность элементов данных, подобную совокупности строк в таблице реляционной базы данных. Каждая таблица может иметь бесконечное количество элементов данных. Amazon DynamoDB – сервис с гибким описанием данных, где элементы данных в таблице не обязаны обладать одинаковыми атрибутами или даже равным количеством атрибутов. Каждая таблица должна иметь свой первичный ключ. Первичный ключ может являться ключом с одним атрибутом или ключом со сложным атрибутом, включающим в себя два атрибута. Атрибуты, назначаемые в качестве первичного ключа, должны существовать для каждого элемента в виде первичного ключа, уникально определяющего каждый из элементов в таблице.

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

Атрибут: каждый атрибут, связанный с элементом данных, состоит из имени атрибута (например, «цвет») и значения или набора значений (например, «красный» или «красный, желтый, зеленый»). Отдельные атрибуты не имеют явно заданных ограничений по размеру, но общее значение элемента (включая все имена и значения атрибута) не должно превышать 400 КБ.

Вопрос: Существует ли ограничение на размер элемента?

Общий размер элемента, включая имена и значения атрибута, не должен превышать 400 КБ.

Вопрос: Существует ли ограничение по количеству атрибутов для элемента?

Количество атрибутов для элемента не ограничено. Однако общий размер элемента, включая имена и значения атрибута, не должен превышать 400 КБ.

Вопрос: Какие существуют API?

  • CreateTable: создает таблицу и указывает первичный индекс, используемый для доступа к данным.
  • UpdateTable: изменяет значения выделенной пропускной способности для данной таблицы.
  • DeleteTable: удаляет таблицу.
  • DescribeTable: возвращает размер и состояние таблицы, а также информацию об индексе.
  • ListTables: возвращает список всех таблиц, связанных с текущим аккаунтом и адресом/URL сервера.
  • PutItem: создает новый элемент или заменяет старый элемент новым (включая все атрибуты). Если элемент уже существует в указанной таблице с тем же первичным ключом, новый элемент полностью заменяет собой существующий элемент. Кроме того, можно использовать условные операторы для замены элемента только в том случае, когда его атрибуты будут соответствовать определенным условиям, или для вставки нового элемента только в том случае, если элемент еще не существует.
  • BatchWriteItem: выполняет вставку, замену и удаление нескольких элементов в нескольких таблицах в рамках одного запроса, но не в рамках одной транзакции. Поддерживает пакеты, содержащие до 25 операций Put или Delete, с максимальным общим размером запроса в 16 МБ.
  • UpdateItem: выполняет редактирование атрибутов существующего элемента. Можно также использовать условные операторы для выполнения редактирования только в том случае, когда значения атрибута элемента будут соответствовать определенным условиям.
  • DeleteItem: удаляет отдельный элемент в таблице по первичному ключу. Можно также использовать условные операторы для удаления элемента только в том случае, когда значения атрибута элемента будут соответствовать определенным условиям.
  • GetItem: операция GetItem возвращает перечень атрибутов элемента, соответствующего первичному ключу. Операция GetItem по умолчанию выполняет потенциально непротиворечивое чтение. Если в вашем приложении недопустимо использовать потенциально непротиворечивое чтение, используйте параметр ConsistentRead.
  • BatchGetItem: операция BatchGetItem возвращает атрибуты нескольких элементов из нескольких таблиц, используя их первичные ключи. Размер каждого ответа ограничен 16 МБ; каждый ответ может вернуть до 100 элементов. Поддерживается как строгая, так и потенциальная непротиворечивость.
  • Query: извлекает один или несколько элементов с помощью первичного ключа таблицы или из вторичного индекса с помощью ключа индекса. Рабочую область запроса в таблице можно сузить с помощью операторов или выражений сравнения. Дополнительно можно отфильтровать результаты выполнения запроса с помощью фильтров по неключевым атрибутам. Поддерживается как строгая, так и потенциальная непротиворечивость. Размер каждого ответа ограничен 1 МБ.
  • Scan: извлекает все элементы и атрибуты в результате полного сканирования таблицы или вторичного индекса. Набор возвращаемых элементов можно ограничить с помощью фильтров по одному или нескольким атрибутам.

Вопрос: Какая модель непротиворечивости действует при выполнении операции Scan?

Операция Scan поддерживает потенциальную и строгую непротиворечивость чтения. По умолчанию операция Scan выполняется с потенциальной непротиворечивостью. Однако вы можете изменить модель непротиворечивости с помощью дополнительного параметра ConsistentRead в вызове API Scan. Установка значения true для параметра ConsistentRead позволит осуществлять в операциях Scan строго непротиворечивое чтение. Для получения дополнительной информации см. документацию для операции Scan.

Вопрос: Как работает операция Scan?

Операция Scan работает как итератор. Когда агрегированный размер элементов, просканированных конкретным запросом API Scan, превысит ограничение в 1 МБ, запрос завершит свою работу и полученные результаты будут возвращены вместе с ключом LastEvaluatedKey (для продолжения сканирования в последующих операциях).

Вопрос: Существуют ли ограничения для операции Scan?

Операция Scan, выполняющая сканирование таблицы или вторичного индекса, имеет ограничение в 1 МБ данных на одну операцию. После превышения ограничения в 1 МБ операция прекращает свою работу и возвращает совпадающие значения, полученные до этого момента, а также ключ LastEvaluatedKey, который будет использован в последующей операции, что позволит продолжить работу с того же места.

Вопрос: Какое количество единиц ресурса чтения потребляет операция Scan?

Необходимое количество единиц чтения представляют собой количество байтов, полученных в результате выполнения операции сканирования, округленное до ближайших 4 КБ и поделенное на 4 КБ. Сканирование таблицы со строго непротиворечивым чтением потребляет вдвое больше ресурсов по сравнению с потенциально непротиворечивым чтением.

Вопрос: Какие типы данных поддерживает DynamoDB?

DynamoDB поддерживает четыре типа скалярных данных: число, строка, бинарные и логические данные. Кроме того, DynamoDB поддерживает типы коллекций данных: набор чисел, набор строк, набор бинарных данных, разнородный список и разнородная карта. DynamoDB также поддерживает значения NULL.

Вопрос: Какие типы структур данных поддерживает DynamoDB?

DynamoDB поддерживает модель «ключ-значение» и документную модель данных.

Вопрос: Что такое хранилище данных «ключ-значение»?

Хранилище данных типа «ключ-значение» – это сервис баз данных, поддерживающий сохранение данных, выполнение запросов и обновление коллекций элементов, описываемых с помощью ключа, содержащего фактически сохраняемый контент.

Вопрос: Что такое хранилище документов?

Хранилище документов поддерживает сохранение данных, выполнение запросов и обновление элементов в формате документов, например JSON, XML и HTML.

Вопрос: Входит ли в DynamoDB тип данных JSON?

Нет, но вы можете использовать SDK для документов, чтобы записать данные JSON непосредственно в DynamoDB. Типы данных DynamoDB являются сверхмножеством типов данных, поддерживаемых JSON. SDK для документов автоматически сопоставит документы JSON с собственными типами данных DynamoDB.

Вопрос: Можно ли использовать Консоль управления AWS для просмотра и редактирования документов JSON?

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

Вопрос: Существуют ли какие-либо отличия при выполнении запросов к данным JSON в DynamoDB?

Нет. Вы можете создать глобальный вторичный индекс или локальный вторичный индекс для любого элемента JSON верхнего уровня. Например, вы сохранили документ JSON, содержащий следующую информацию о человеке: имя, фамилию, почтовый индекс и список всех его друзей. Имя, фамилия и почтовый индекс будут являться элементами JSON верхнего уровня. Вы можете создать индекс, чтобы выполнять запросы по имени, фамилии и почтовому индексу. Список друзей не является элементом верхнего уровня, поэтому проиндексировать список друзей невозможно. Для получения дополнительной информации о глобальных вторичных индексах и функциональных возможностях запросов см. раздел «Вторичные индексы» на этой странице вопросов и ответов.

Вопрос: Если данные JSON вложены в DynamoDB, можно ли извлекать отдельные элементы этих данных?

Да. При использовании API GetItem, BatchGetItem, Query или Scan можно задать выражение ProjectionExpression, позволяющее задать атрибуты, которые необходимо извлечь из таблицы. Эти атрибуты могут включать скалярные типы данных, наборы или элементы документа JSON.

Вопрос: Если данные JSON вложены в DynamoDB, можно ли изменять отдельные элементы этих данных?

Да. При обновлении элемента DynamoDB можно указать дочерний элемент документа JSON, который необходимо изменить.

Вопрос: Что такое SDK для документов?

SDK для документов – это оболочка типов данных для JavaScript, которая обеспечивает удобное преобразование типов данных между JS и DynamoDB. Этот SDK будет выполнять упаковку типов данных для запросов, а затем аналогичным образом выполнять распаковку типов данных для ответов. Для получения дополнительной информации и загрузки SDK см. репозиторий GitHub, расположенный здесь.

 


Вопрос: Существуют ли ограничения по объему данных, сохраняемых в Amazon DynamoDB?

Нет. Ограничения на объем хранимых в таблице Amazon DynamoDB данных отсутствуют. По мере роста объема набора данных Amazon DynamoDB будет автоматически распределять данные по доступным аппаратным ресурсам для удовлетворения ваших требований, связанных с хранением данных.

Вопрос: Существуют ли ограничения по пропускной способности для каждой из таблиц?

Нет, с помощью API или Консоли управления AWS можно увеличить лимит по выделению ресурсов, установленный для Auto Scaling, или увеличить пропускную способность, вручную выделенную для таблицы. Сервис DynamoDB способен работать в очень больших масштабах, поэтому величина доступной пропускной способности теоретически не ограничена. DynamoDB автоматически разделяет таблицу по нескольким разделам, где каждый раздел представляет собой независимый параллельный вычислительный блок. DynamoDB способен наращивать значительную пропускную способность за счет добавления дополнительных разделов.

Если вам необходимо получить пропускную способность на уровне выше 10 000 операций записи в секунду или 10 000 операций чтения в секунду, вам нужно сначала связаться с Amazon через эту онлайн-форму.

Вопрос: Остается ли сервис Amazon DynamoDB доступным, когда Auto Scaling запускает процесс масштабирования или сам пользователь инициирует изменение выделенной пропускной способности?

Да. Amazon DynamoDB разработан так, чтобы оставаться доступным в процессе масштабирования выделенной пропускной способности, независимо от того, выполняется этот процесс вручную или с помощью Auto Scaling.

Вопрос: Нужно ли с клиентской стороны управлять распределением разделов в Amazon DynamoDB?

Нет. Amazon DynamoDB устраняет необходимость в распределении таблиц баз данных в целях масштабирования пропускной способности.

Вопрос: Какова степень доступности сервиса Amazon DynamoDB?

Сервис работает на базе надежных ЦОД Amazon с высокой степенью доступности. Сервис выполняет репликацию данных на трех серверах региона AWS в целях обеспечения отказоустойчивости при выходе сервера из строя или аварийном отключении зоны доступности.

Вопрос: Каким образом достигается бесперебойная работа и сохранность данных в Amazon DynamoDB?

Для достижения бесперебойной работы и сохранности данных Amazon DynamoDB выполняет синхронную репликацию данных на трех серверах региона AWS.


Вопрос: Что представляет собой Auto Scaling сервиса DynamoDB?

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

Вопрос: Зачем использовать Auto Scaling?

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

Вопрос: Какие рабочие нагрузки и шаблоны запросов приложения подходят для использования Auto Scaling?

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

Вопрос: Как активировать Auto Scaling для таблицы DynamoDB или глобального вторичного индекса?

Для активации возможности Auto Scaling и применения аналогичных настроек для глобальных вторичных индексов при создании новой таблицы в консоли DynamoDB оставьте флажок для настройки «Use default settings». Сняв флажок с настройки «Use default settings», можно либо устанавливать выделенную пропускную способность вручную, либо включить Auto Scaling с настраиваемыми значениями для целевого потребления, а также минимального и максимального уровня ресурсов. Активировать Auto Scaling для уже существующих таблиц или изменить существующие настройки Auto Scaling можно на вкладке «Capacity». Аналогичные операции для индексов можно выполнить на вкладке «Indexes». Помимо этого, можно управлять возможностью Auto Scaling программными методами с помощью интерфейса командной строки или AWS SDK. Подробную информацию см. в Руководстве для разработчиков по DynamoDB.

Вопрос: Какие настройки Auto Scaling доступны для изменения?

У Auto Scaling есть три изменяемых настройки: целевой уровень потребления (процент реально потребленной пропускной способности по отношению к общей выделенной пропускной способности в конкретный момент времени), минимальный объем ресурсов, до которого может опускаться Auto Scaling, и максимальный объем ресурсов, до которого может подниматься Auto Scaling. Значение по умолчанию для целевого уровня потребления составляет 70 % (допустимый интервал значений – от 20 до 80 % с шагом в один процент). Для минимального объема ресурсов это одна единица, а максимальный объем соответствует лимиту для таблиц, установленному для аккаунта в используемом регионе. Региональные лимиты по умолчанию для таблиц см. на странице Лимиты в DynamoDB.

Вопрос: Могу ли я изменять настройки существующей политики Auto Scaling?

Да, можно изменять настройки существующей политики Auto Scaling в любой момент времени. Для этого перейдите на вкладку «Capacity» в консоли управления или измените настройки программными методами с помощью интерфейса командной строки или SDK, используя API AutoScaling.

Вопрос: Как работает Auto Scaling?

При создании новой политики Auto Scaling для таблицы DynamoDB в сервисе Amazon CloudWatch создаются оповещения с пороговыми значениями для заданного целевого уровня потребления. Они рассчитываются на основании значений выделенных и потребленных ресурсов, переданных в CloudWatch. Если уровень реального потребления отклоняется от заданного значения на определенный промежуток времени, оповещения CloudWatch активируют возможность Auto Scaling, которая сверяется с текущей политикой и отправляет в DynamoDB запрос API UpdateTable на динамическое изменение выделенной пропускной способности для данной таблицы. Это позволяет приблизить уровень реального потребления ресурсов к целевому значению.

Вопрос: Могу ли я установить единую политику Auto Scaling для множества таблиц в различных регионах?

Нет, политика Auto Scaling может быть установлена только для одной таблицы или глобального вторичного индекса в пределах одного региона.

Вопрос: Могу ли я принудительно заставить политику Auto Scaling мгновенно установить минимальное или максимальное значение объема ресурсов?


Нет, такая возможность не поддерживается. Вместо этого можно временно отключить Auto Scaling, вручную установить нужное значение объема ресурсов на требуемый период времени, а после его завершения снова включить Auto Scaling.

Вопрос: Где я могу отслеживать действия масштабирования, инициированные Auto Scaling?

Статус действий масштабирования, запущенных Auto Scaling, можно отслеживать на вкладке «Capacity» в консоли управления и на графиках CloudWatch, расположенных на вкладке «Metrics».

Вопрос: Как понять, имеет конкретная таблица активную политику Auto Scaling или нет?

В консоли DynamoDB нажмите пункт «Tables» в меню слева, чтобы вывести полный список таблиц DynamoDB данного аккаунта. Таблицы с активной политикой Auto Scaling будут иметь в графе «Auto Scaling» значения READ_CAPACITY, WRITE_CAPACITY или READ_AND_WRITE в зависимости от того, для каких операций активирована Auto Scaling (для чтения, записи или одновременно для чтения и записи). Просмотреть, для каких операций активирована возможность Auto Scaling, также можно в разделе «Table details» на вкладке «Overview». Эти данные будут отображаться на ярлыке выделенных ресурсов.

Вопрос: Что происходит с политикой Auto Scaling при удалении таблицы или глобального вторичного индекса с активной политикой?

При удалении таблицы или глобального вторичного индекса с помощью консоли связанная политика Auto Scaling и связанные с ней оповещения CloudWatch также удаляются.

Вопрос: Взимается ли дополнительная плата за использование Auto Scaling?

Нет, за использование Auto Scaling дополнительная плата не взимается. Вы платите по стандартным тарифам за использование сервиса DynamoDB и оповещений CloudWatch. Подробную информацию о ценах DynamoDB см. на странице цен DynamoDB.

Вопрос: Как ресурсы пропускной способности, управляемые Auto Scaling, работают с зарезервированными ресурсами?

Auto Scaling работает с зарезервированными ресурсами так же, как это делают выделенные вручную ресурсы пропускной способности. Резервирование ресурсов применяется к общим выделенным ресурсам для региона, в котором оно было приобретено. Ресурсы, выделенные Auto Scaling, сначала используют зарезервированные ресурсы (по льготной цене), а все ресурсы, которые потребуются сверх этого, оплачиваются по стандартным тарифам. Чтобы ограничить общее потребление до объема приобретенных зарезервированных ресурсов, установите лимит максимального объема ресурсов по всем таблицам с активированной возможностью Auto Scaling таким образом, чтобы он был меньше общего объема приобретенных зарезервированных ресурсов.


Вопрос: Что такое глобальные вторичные индексы?

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

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

Amazon DynamoDB поддерживает два типа вторичных индексов.

  • Локальный вторичный индекс: индекс, который имеет тот же ключ секции, что и таблица, но имеет другой ключ сортировки. Локальный вторичный индекс называется «локальным», поскольку каждый его раздел соответствует разделу таблицы с тем же ключом секции.
  • Глобальный вторичный индекс – это индекс с ключом секции или ключом секции и сортировки, которые могут отличаться от ключей таблицы. Глобальный вторичный индекс считается «глобальным», поскольку запросы, обращенные к этому индексу, распространяются на все элементы таблицы во всех разделах. 

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

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

Рассмотрим игровое приложение, которое сохраняет информацию об игроках в таблице DynamoDB, где первичный ключ состоит из UserId (секция) и GameTitle (сортировка). Элементы имеют атрибуты с названиями TopScore, Timestamp, ZipCode и т. д. При создании таблицы сервис DynamoDB формирует скрытый индекс (первичный индекс) по первичному ключу, поддерживающий эффективные запросы, которые возвращают записи рекордов по всем играм для конкретного пользователя.

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

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

Вопрос: Когда следует использовать глобальные вторичные индексы?

Глобальные вторичные индексы особенно эффективны для отслеживания связей между атрибутами, имеющими множество различных значений. Например, можно создать таблицу DynamoDB с CustomerID в качестве первичного ключа секции таблицы и ZipCode в качестве ключа сортировки глобального вторичного индекса, так как существует множество почтовых индексов и множество различных клиентов. С помощью первичного ключа можно быстро извлечь записи для любого клиента. С помощью глобального вторичного индекса можно эффективно делать запросы всех клиентов, проживающих в пределах данного почтового индекса.

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

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

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

Вопрос: Поддерживает ли локальная версия DynamoDB глобальные вторичные индексы?

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

Вопрос: Что такое проецированные атрибуты?

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

Вопрос: Можно ли задавать ключ глобального вторичного индекса для неуникальных атрибутов?

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

Вопрос: Чем глобальные вторичные индексы отличаются от локальных вторичных индексов?

Глобальные и локальные вторичные индексы повышают гибкость запросов. Локальные вторичные индексы назначены конкретным значениям ключа секции, а глобальные вторичные индексы охватывают все значения ключа секции. Поскольку элементы, имеющие одинаковые значения ключа секции, размещены в одном разделе DynamoDB, локальный вторичный индекс охватывает только те элементы, что хранятся вместе (в одном разделе). Таким образом, назначение локального вторичного индекса – отрабатывать запросы по элементам, имеющим одинаковое значение ключа секции, но различные ключи сортировки. Например, рассмотрим таблицу DynamoDB, отслеживающую заказы клиентов (Orders), где ключом секции является CustomerId.

Локальный вторичный индекс по OrderTime позволит эффективно извлекать последние заказанные элементы с помощью запросов для конкретного клиента.

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

С целью обеспечить нахождение данных в таблице и индексов в одном разделе на локальные вторичные индексы накладывается ограничение в 10 ГБ на общий размер всех элементов (таблиц и индексов) для каждого значения ключа секции. Глобальные вторичные индексы не требуют принудительной колокации данных и не накладывают подобных ограничений.

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

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

Вопрос: Как работают глобальные вторичные индексы?

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

DynamoDB сохраняет проецированные атрибуты глобального вторичного индекса в его структуре данных вместе с ключом глобального вторичного индекса и первичными ключами совпадающих элементов. Глобальный вторичный индекс использует хранилище для размещения проецированных элементов, существующих в исходной таблице. Благодаря этому запросы можно направлять к глобальному вторичному индексу, а не к самой таблице. Такая возможность повышает гибкость запросов и улучшает распределение рабочей нагрузки. Атрибуты, являющиеся частью элемента таблицы, но не являющиеся частью ключа глобального вторичного индекса, первичного ключа таблицы или проецированных атрибутов, не будут возвращены при опросе индекса GSI. Приложения, которым после опроса глобального вторичного индекса оказываются необходимы дополнительные данные из таблицы, могут извлечь первичный ключ из глобального вторичного индекса, а затем использовать API GetItem или BatchGetItem для извлечения необходимых атрибутов из таблицы. Так как глобальные вторичные индексы характеризуются потенциальной непротиворечивостью, приложения, использующие эту схему, должны учитывать удаление элементов (из таблицы) между вызовами к глобальному вторичному индексу и вызовом API GetItem/BatchItem.

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

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

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

Вопрос: Какая модель непротиворечивости действует для глобальных вторичных индексов?

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

Рассмотрим таблицу для отслеживания записей рекордов, где каждый элемент имеет следующие атрибуты: UserId, GameTitle и TopScore. Ключ секции – это UserId, а первичный ключ сортировки – GameTitle. Если приложение добавляет элемент, обозначающий новую запись рекорда для игры, со значением атрибута GameTitle «Крестики-нолики» и значением атрибута UserId «Игрок123», а затем сразу делает запрос к глобальному вторичному индексу, новый результат может не появиться в результатах опроса. Однако когда обновление глобального вторичного индекса завершится, новый элемент начнет появляться в подобных опросах глобального вторичного индекса.

Вопрос: Можно ли выделить пропускную способность отдельно для таблицы и отдельно для каждого из глобальных вторичных индексов?

Да. Глобальные вторичные индексы управляют пропускной способностью независимо от таблицы, на которой они основаны. При активации Auto Scaling для новой или существующей таблицы из консоли можно дополнительно применить те же настройки к глобальным вторичным индексам. Можно также выделить различную пропускную способность для таблиц и глобальных вторичных индексов вручную.

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

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

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

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

Вопрос: Каким образом добавление глобального вторичного индекса влияет на выделенную пропускную способность и хранилище для таблицы?

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

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

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

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

Вопрос: Может ли DynamoDB ограничивать операции записи в таблицу на основании выделенной пропускной способности глобальных вторичных индексов?

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

Вопрос: Как часто можно изменять выделенную пропускную способность на уровне индекса?

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

Вопрос: Как оплачивается использование глобального вторичного индекса в DynamoDB?

Вы оплачиваете совокупную выделенную пропускную способность для таблицы и ее глобальных вторичных индексов на почасовой основе. При ручном распределении, которое не является обязательным, плата за совокупную распределенную пропускную способность для таблицы и ее глобальных вторичных индексов будет взиматься на почасовой основе. Кроме того, необходимо будет оплатить объем данных в хранилище, занятый глобальными вторичными индексами, а также внешнюю передачу данных по стандартным тарифам. Чтобы изменить выделенную пропускную способность глобальных вторичных индексов, используйте консоль DynamoDB, API UpdateTable или API PutScalingPolicy для обновления настроек политики Auto Scaling.

Вопрос: Можно ли указать, какой из глобальных вторичных индексов должен использоваться в запросе?

Да. Помимо стандартных параметров запросов, команда Query глобального вторичного индекса может явно определять название глобального вторичного индекса, к которому обращается. Учтите, что запрос может использовать только один глобальный вторичный индекс.

Вопрос: Какие вызовы API поддерживает глобальный вторичный индекс?

Глобальный вторичный индекс поддерживает вызовы API Query и Scan. Операция Query выполняет поиск только среди значений атрибутов ключа индекса и поддерживает подкласс операторов сравнения. Так как глобальные вторичные индексы обновляются асинхронно, использовать в запросе к ним параметр ConsistentRead нельзя. Дополнительные сведения об использовании глобальных вторичных индексов при запросах и сканировании см. здесь.

Вопрос: Каков порядок вывода результатов при сканировании глобального вторичного индекса?

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

Вопрос: Можно ли изменять глобальные вторичные индексы после создания таблицы?

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

Вопрос: Как можно добавить глобальный вторичный индекс к существующей таблице?

Глобальные вторичные индексы можно добавлять с помощью консоли или через вызов API. В консоли DynamoDB выберите таблицу, для которой необходимо добавить глобальный вторичный индекс, и нажмите кнопку «Создать индекс», чтобы добавить новый индекс. Следуйте этапам, описанным в мастере создания индекса, и в конце нажмите кнопку «Создать». Также глобальные вторичные индексы можно добавлять и удалять с помощью вызова API UpdateTable с параметром GlobalSecondaryIndexes. Дополнительные сведения см. на странице документации.

Вопрос: Как можно удалить глобальный вторичный индекс?

Глобальные вторичные индексы можно удалять из консоли или через вызов API. В консоли DynamoDB выберите таблицу, для которой нужно удалить глобальный вторичный индекс. Затем выберите вкладку «Индексы» в разделе «Элементы таблицы» и нажмите кнопку «Удалить», расположенную рядом, чтобы удалить индекс. Глобальные вторичные индексы также можно удалять с помощью вызова API UpdateTable. Дополнительные сведения см. на странице документации.

Вопрос: Можно ли добавлять и удалять сразу несколько индексов в одном вызове API для одной таблицы?

В одном вызове API можно добавлять или удалять только один индекс.

Вопрос: Что произойдет, если будет отправлено несколько запросов на добавление одного и того же индекса?

Будет принят только первый запрос на добавление, а все последующие запросы на добавление будут отклонены, пока первый запрос на добавление не будет исполнен.

Вопрос: Можно ли одновременно добавлять или удалять несколько индексов в одной таблице?

Нет, в любой момент времени может быть активна только одна операция по добавлению или удалению индекса для таблицы.

Вопрос: Следует ли выделять дополнительную пропускную способность, чтобы добавить глобальный вторичный индекс?

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

Вопрос: Нужно ли сокращать дополнительную пропускную способность, выделенную для глобального вторичного индекса, когда индекс будет создан?

Да, по завершении процесса рекомендуется вернуть пропускную способность операций записи, увеличенную для создания индекса, на прежний уровень.

Вопрос: Можно ли изменять величину пропускной способности, выделенной для создания глобального вторичного индекса?

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

Вопрос: Будет ли таблица оставаться доступной в процессе добавления или удаления глобального вторичного индекса?

Да, в процессе изменения глобального вторичного индекса таблица остается доступна.

Вопрос: Будут ли существующие индексы оставаться доступными в процессе добавления или удаления глобального вторичного индекса?

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

Вопрос: Будет ли новый глобальный вторичный индекс доступен сразу после добавления?

Нет, новый индекс станет доступным только по окончании процесса создания индекса.

Вопрос: Сколько времени занимает добавление глобального вторичного индекса?

Продолжительность процесса зависит от размера таблицы и объема дополнительной пропускной способности операций записи, выделенной для создания глобального вторичного индекса. Процесс добавления или удаления индекса может занимать от нескольких минут до нескольких часов. Предположим, что у вас есть таблица размером 1 ГБ, для которой выделено 500 единиц ресурса записи, и вы выделяете 1000 дополнительных единиц ресурса записи для существующего индекса и создания нового индекса. Если новый индекс будет содержать все атрибуты таблицы, и таблица задействует все единицы ресурса записи, ожидаемое время создания индекса составит около 30 минут.

Вопрос: Сколько времени занимает удаление глобального вторичного индекса?

Удаление индекса обычно занимает всего несколько минут. Например, удаление индекса с 1 ГБ данных займет менее минуты.

Вопрос: Каким образом осуществляется отслеживание процесса добавления или удаления глобального вторичного индекса?

Для проверки состояния всех индексов, связанных с таблицей, можно использовать консоль DynamoDB или API DescribeTable. При операции добавления индекса, пока индекс создается, его состояние будет обозначено как «СОЗДАЕТСЯ». Когда создание индекса будет завершено, состояние индекса изменится с «СОЗДАЕТСЯ» на «АКТИВЕН». При операции удаления индекса, как только запрос будет исполнен, удаленный индекс прекратит свое существование.

Вопрос: Можно ли получать оповещения о завершении процесса создания глобального вторичного индекса?

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

Вопрос: Что произойдет, если будут добавлены дополнительные глобальные вторичные индексы сверх уже доступных пяти?

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

Вопрос: Можно ли использовать название глобального вторичного индекса повторно после того, как индекс с аналогичным названием будет удален?

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

Вопрос: Можно ли отменить добавление индекса в процессе его создания?

Нет, после того как начнется создание индекса, отменить этот процесс уже невозможно.

Вопрос: Атрибуты ключей глобального вторичного индекса требуются во всех элементах таблицы DynamoDB?

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

Вопрос: Можно ли извлечь все атрибуты таблицы DynamoDB запросом к глобальному вторичному индексу?

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

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

Подробную информацию о глобальных вторичных индексах таблицы возвращает API DescribeTable.

Вопрос: Какие типы данных можно индексировать?

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

Вопрос: Можно ли создавать индексы со сложными атрибутами?

Нет. Можно только соединить атрибуты в строку и использовать ее в качестве ключа.

Вопрос: Какие типы данных могут быть частью проецированных атрибутов для глобального вторичного индекса?

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

Вопрос: Что стоит учесть при масштабировании глобальных вторичных индексов?

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

Вопрос: Какие новые показатели будут доступны в CloudWatch для глобальных вторичных индексов?

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

Отчеты по отдельным глобальным вторичным индексам будут поддерживать наборы показателей CloudWatch, поддерживаемые таблицей. Они включают следующее:

  • ресурсы чтения (выделенные ресурсы чтения, потребленные ресурсы чтения);
  • ресурсы записи (выделенные ресурсы записи, потребленные ресурсы записи);
  • пропущенные события чтения;
  • пропущенные события записи.

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

Вопрос: Как можно просканировать глобальный вторичный индекс?

Глобальные вторичные индексы можно просканировать с помощью консоли или API Scan.

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

Вопрос: Позволит ли сканирование глобального вторичного индекса определить непроецированные атрибуты и вывести их в списке результатов?

Сканирование глобальных вторичных индексов не поддерживает извлечение непроецированных атрибутов.

Вопрос: Поддерживается ли параллельное сканирование индексов?

Да, параллельное сканирование для индексов поддерживается с семантикой, аналогичной семантике для основной таблицы.


Вопрос: Что такое локальные вторичные индексы?

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

Чтобы найти конкретные элементы в разделе (элементы с одним общим ключом секции) без использования локальных вторичных индексов, DynamoDB пришлось бы извлечь все объекты с одним общим ключом секции и произвести соответствующую фильтрацию результатов. Например, рассмотрим приложение для интернет-коммерции, сохраняющее данные о заказах клиентов в таблице DynamoDB со схемой ключей секции и сортировки: id клиента – временная метка заказа. Без локального вторичного индекса поиск ответа на вопрос «Отобразить все заказы, выполненные клиентом X с датой отправки в течение последних 30 дней, отсортированные по дате отправки» потребовал бы использования вызова API Query для извлечения всех объектов с ключом секции X, сортировки результатов по дате отгрузки и затем фильтрации старых записей.

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

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

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

Вопрос: Что такое проекции?

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

При определении локального вторичного индекса необходимо задать атрибуты, которые будут спроецированы в индекс. Каждая запись в индексе состоит из (1) значения ключа секции таблицы, (2) атрибута, выступающего для индекса в качестве ключа сортировки и (3) значения ключа сортировки таблицы (как минимум).

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

Вопрос: Как можно создать локальный вторичный индекс?

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

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

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

Вопрос: Какая модель непротиворечивости действует для локального вторичного индекса?

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

Вопрос: Содержат ли локальные вторичные индексы ссылки на все элементы таблицы?

Нет, это не обязательно. Локальные вторичные индексы содержат ссылки только на те элементы, которые содержат индексированный ключ сортировки, заданный для этого локального вторичного индекса. Гибкая схема DynamoDB означает, что не все элементы должны обязательно содержать все атрибуты.

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

Например, в описанном выше примере с заказами для клиента могли существовать дополнительные атрибуты в элементе, который включался только в том случае, если заказ был отменен (например, CanceledDateTime, CanceledReason). Для запросов, связанных с отмененными элементами, будет эффективно использовать локальный вторичный индекс с любым из этих атрибутов, так как элементы, указанные в индексе, будут иметь указанные атрибуты.

Вопрос: Как выполняются запросы к локальным вторичным индексам?

Запросы к локальным вторичным индексам можно направить только с помощью API Query.

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

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

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

Вопрос: Как можно создать локальные вторичные индексы?

Локальные вторичные индексы должны определяться во время создания таблицы. Первичный индекс таблицы должен использовать составной ключ секции и сортировки.

Вопрос: Можно ли добавить локальные вторичные индексы к существующей таблице?

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

Вопрос: Сколько локальных вторичных индексов можно создать для одной таблицы?

Для каждой таблицы можно создать до пяти локальных вторичных индексов.

Вопрос: Сколько проецированных неключевых атрибутов можно создать для одной таблицы?

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

Вопрос: Можно ли вносить изменения в индекс после его создания?

Нет, после создания индекс изменить нельзя. Мы реализуем эту возможность в будущих версиях сервиса.

Вопрос: Можно ли удалять локальные вторичные индексы?

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

Вопрос: Каким образом локальные вторичные индексы потребляют выделенные ресурсы?

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

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

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

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

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

Вопрос: Какой объем хранилища потребляют локальные вторичные индексы?

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

Вопрос: Какие типы данных можно индексировать?

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

Вопрос: Какие типы данных можно проецировать в локальный вторичный индекс?

В локальный вторичный индекс можно проецировать все типы данных (включая набор).

Вопрос: Что такое набор элементов и как они связаны с локальным вторичным индексом?

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

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

Вопрос: Существуют ли ограничения по размеру набора элементов?

На каждый набор элементов в Amazon DynamoDB распространяется ограничение по размеру в 10 ГБ. Для каждого отдельного значения ключа секции общий размер элементов в таблице с учетом размеров элементов во всех локальных вторичных индексах этой таблицы не должен превышать 10 ГБ.

Ограничение в 10 ГБ, распространяющееся на наборы элементов, не применяется к таблицам без локальных вторичных индексов. Оно распространяется только на таблицы, у которых существует один или несколько локальных вторичных индексов.

Несмотря на ограничения по размеру для отдельных наборов элементов, размер хранилища для общей таблицы с локальными вторичными индексами не ограничен. Общий размер индексированной таблицы в Amazon DynamoDB фактически не ограничен при условии, что общий размер таблицы и индексов для каждого значения ключа секции не превышает порогового значения в 10 ГБ.

Вопрос: Как можно узнать размер набора элементов?

API операций записи DynamoDB (PutItem, UpdateItem, DeleteItem и BatchWriteItem) содержат опцию, которая позволяет включать в ответ API примерный размер соответствующем наборе элементов. Эта примерная оценка содержит минимальную и максимальную оценку объема данных в конкретном наборе элементов, выраженного в гигабайтах.

Рекомендуем вам включить в свое приложение функцию мониторинга размера наборов элементов. Ваше приложение должно анализировать ответы API на предмет размера набора элементов и фиксировать в логах сообщение об ошибке, когда размер набора превысит заданное пользователем предельное значение (например, 8 ГБ). Таким образом, вы создадите систему раннего предупреждения, которая оповестит вас об увеличении размера набора элементов и предоставит достаточно времени для решения этой задачи.

Вопрос: Что будет, если размер набора элементов превысит ограничение в 10 ГБ?

Если размер конкретного набора элементов превысит ограничение в 10 ГБ, вы не сможете записывать новые элементы или увеличивать размер существующих элементов для этого конкретного ключа секции. Операции чтения и записи, позволяющие уменьшить размер набора элементов, будут по-прежнему разрешены. Работоспособность прочих наборов элементов в таблице затронута не будет.

Для решения этой проблемы можно удалить элементы или уменьшить размер элементов в коллекции, размер которой превышает 10 ГБ. Чтобы обойти эту проблему, можно добавлять новые элементы с новым значением ключа секции. Если в таблице содержатся данные истории, доступ к которым осуществляется редко, рекомендуется перенести архив таких данных в Amazon S3, Amazon Glacier или другой сервис хранения данных.

Вопрос: Как можно просканировать локальный вторичный индекс?

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

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

Вопрос: Позволит ли сканирование локального вторичного индекса определить непроецированные атрибуты и вывести их в списке результатов?

Сканирование локальных вторичных индексов поддерживает извлечение непроецированных атрибутов.

Вопрос: Каков порядок вывода результатов при сканировании локального вторичного индекса?

Для локального вторичного индекса порядок в рамках коллекции определяется порядком индексированного атрибута.


Вопрос: Что представляет собой полный контроль доступа DynamoDB?

Функция полного контроля доступа (FGAC) позволяет владельцу таблицы DynamoDB полностью контролировать данные таблицы. Это подразумевает возможность предоставлять конкретному оператору доступ к определенным элементам или атрибутам таблицы и выполнению определенных действий (чтения или записи). Функция FGAC работает совместно с сервисом AWS Identity and Access Management (IAM), управляющим правами доступа и связанными разрешениями.

Вопрос: В каких случаях обычно используется функция FGAC DynamoDB?

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

Вопрос: Можно ли использовать функцию полного контроля доступа с документами JSON?

Да. С помощью функции FGAC можно ограничить доступ к данным на основе атрибутов верхнего уровня вашего документа. Доступ на основе вложенных атрибутов с ее помощью ограничить нельзя. Предположим для примера, что документ JSON содержит идентификационный номер (ID), имя, фамилию и список всех друзей некоторого пользователя. С помощью функции FGAC можно ограничить доступ к данным на основе ID, имени или фамилии, но не на основе списка друзей.

Вопрос: Как контролировать доступ на уровне элементов без использования функции FGAC?

Для контроля доступа на этом уровне без использования FGAC разработчику придется использовать достаточно сложные решения. Возможны следующие варианты.

  1. Прокси. Клиент приложения отправляет запрос посреднику – прокси-серверу, который выполняет процесс аутентификации и авторизации. Такое решение усложняет архитектуру системы и может привести к повышению совокупной стоимости владения (TCO).
  2. Собственная таблица для каждого клиента. Каждому клиенту приложения предоставляется собственная таблица. Поскольку клиенты приложения получают доступ к разным таблицам, таблицы оказываются защищены от других клиентов. Это может потребовать от разработчика создания миллионов таблиц, что чрезвычайно усложнит управление базой данных.
  3. Встроенные токены для каждого клиента. Каждый клиент приложения оснащается встроенным секретным токеном. Недостаток этого подхода связан со сложностью смены токена и с влиянием последней на хранимые данные. Ключ доступных для данного клиента элементов при таком решении будет содержать секретный токен.

Вопрос: Как действует функция FGAC сервиса DynamoDB?

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

Вопрос: Какова стоимость DynamoDB FGAC?

Дополнительная плата за использование функции FGAC отсутствует. Как и обычно, вы платите только за пропускную способность и емкость хранилища, которые выделены для таблицы DynamoDB.

Вопрос: Как начать работу с функцией FGAC?

Ознакомьтесь с разделом «Полный контроль доступа» Руководства DynamoDB для разработчиков, чтобы изучить порядок создания политики доступа и роли IAM для приложения (например, роли под названием AcmeFacebookUsers для идентификационного номера Facebook app_id 34567) и привязки политики доступа к роли. Трастовая политика роли определяет допустимых провайдеров идентификации (например, авторизация с помощью аккаунта Amazon, Facebook или Google), а политика доступа описывает, к каким ресурсам AWS предоставлен доступ (например, к таблице DynamoDB). Теперь с помощью роли приложение может получить временные права доступа к DynamoDB путем вызова API AssumeRoleWithIdentityRequest сервиса AWS Security Token Service (STS).

Вопрос: Как разрешить пользователям делать запросы по локальному вторичному индексу, но запретить им доступ к таблице для извлечения атрибутов, которые не были предварительно определены?

Некоторые операции запросов по локальному вторичному индексу оплачиваются по более высоким тарифам, если запрашиваются атрибуты, которые не определены в индексе. Можно ограничить выполнение таких дорогостоящих операций извлечения путем ограниченного предоставления разрешений только на проецированные атрибуты, используя контекстный ключ dynamodb:Attributes.

Вопрос: Как запретить пользователям доступ к определенным атрибутам?

Чтобы запретить доступ к определенным атрибутам, рекомендуется следовать принципу наименьшего уровня привилегий и использовать политику Allow только для определенных атрибутов.

В качестве альтернативы можно использовать политику Deny для указания атрибутов, доступ к которым должен быть запрещен. Последний вариант является менее предпочтительным по следующим причинам.

  1. При использовании политики Deny есть риск, что пользователь обнаружит имена скрытых атрибутов посредством повторяющихся запросов для всех возможных имен атрибутов до получения отказа в доступе.
  2. Политики Deny более уязвимы, поскольку в будущем в DynamoDB могут появиться новые функциональные возможности API, разрешающие схемы доступа, которые разработчик ранее намеревался заблокировать.

Вопрос: Как предотвратить добавление пользователями в таблицу недопустимых данных?

С помощью средств управления FGAC можно определить, какие элементы и атрибуты могут быть изменены или прочитаны. Пользователи могут добавлять новые элементы, не содержащие заблокированных атрибутов, и вносить изменения в любые значения или атрибуты, которые открыты для изменения.

Вопрос: Можно ли предоставить доступ к нескольким атрибутам, не выводя их список?

Да, язык политик IAM поддерживает множество операций сравнения, в том числе StringLike, StringNotLike и многие другие.  Подробнее см. в Справке по политикам IAM.

Вопрос: Как создать подходящую политику?

Для этого рекомендуется использовать DynamoDB Policy Generator в консоли DynamoDB. Можно также сравнить свою политику с перечнем политик, приведенным в Руководстве Amazon DynamoDB для разработчиков, чтобы убедиться, что она соответствует рекомендуемому шаблону. Опубликовав политику на форуме AWS, вы сможете получить совет от участников сообщества DynamoDB.

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

Такой вариант возможен только при использовании средства выдачи токенов. Если пользователь получает интегрированный доступ к роли IAM, напрямую используя данные доступа Facebook в сервисе STS, эти временные данные доступа содержат только информацию о логине Facebook пользователя, но не о логине Amazon или Google. Чтобы сохранить во внутренних данных привязку каждого из этих логинов к вашему собственному постоянному идентификатору, запустите сервис, посредством которого пользователь выполняет вход, вызовите сервис STS и в качестве канонического ID пользователя укажите данные доступа в соответствии со значением ключа секции.

Вопрос: Какие данные невозможно скрыть от операторов с помощью FGAC?

В настоящее время невозможно заблокировать операторам доступ к некоторым данным об элементах таблицы.

  • Набор метрик элемента. Оператор может запросить примерное число элементов и объем набора элементов в байтах.
  • Используемая пропускная способность. Оператор может запросить подробную классификацию или сводные данные о пропускной способности, используемой при выполнении операций.
  • Проверка. В некоторых случаях оператор может получить данные о существовании таблицы, к которой вы не намеревались предоставлять доступ, и ее первичном ключе. Во избежание этого рекомендуется следовать принципу наименьшего уровня привилегий и предоставлять доступ только к таблицам и действиям, которые действительно намерены разрешить.
  • При запрещении доступа к определенным атрибутам вместо предоставления доступа к определенным атрибутам оператор теоретически может определить имена скрытых атрибутов в случае применения логики «разрешить все, кроме». Из соображений безопасности рекомендуется предоставление доступа к конкретным атрибутам.

Вопрос: Поддерживаются ли в Amazon DynamoDB разрешения IAM?

Да, DynamoDB поддерживает разрешения на уровне API путем интеграции с сервисом AWS Identity and Access Management (IAM).

Для получения дополнительной информации об IAM воспользуйтесь следующими ссылками.

Вопрос: Мне нужно выполнить анализ безопасности или устранить неполадки в работе таблиц DynamoDB. Можно ли просмотреть историю всех вызовов API DynamoDB в аккаунте?

Да. AWS CloudTrail – это веб-сервис, который записывает все вызовы AWS API для вашего аккаунта и предоставляет вам лог-файлы. История вызовов API AWS в AWS CloudTrail позволяет провести анализ безопасности и аудит соответствия, а также отследить изменения ресурсов. Подробнее об использовании CloudTrail для DynamoDB см. по ссылке. Дополнительные сведения о CloudTrail см. на странице описания сервиса AWS CloudTrail, при этом включить его можно на главной странице CloudTrail в Консоли управления AWS.


Вопрос: Каков порядок оплаты пользования сервисом Amazon DynamoDB?

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

Обратите внимание на то, что плата за ресурсы пропускной способности взимается на почасовой основе, независимо от того, выполняются ли запросы к таблице. Изменить выделенные ресурсы пропускной способности таблицы можно с помощью Консоли управления AWS, API UpdateTable или API PutScalingPolicy для Auto Scaling.

Кроме того, в DynamoDB взимается плата за объем данных в хранилище, занятый индексами, а также стандартная плата за передачу данных через Интернет.

Подробную информацию о ценах DynamoDB см. на странице цен DynamoDB.

Вопрос: Можно ли ознакомиться с примерами начисления платы?

Ниже приводим пример расчета стоимости пропускной способности по тарифам региона Восток США (Северная Вирджиния). Информацию о тарифах для других регионов см. на странице цен.

При создании таблицы с выделением 10 единиц ресурса записи и 200 единиц ресурса чтения будет начислено:

0,01 USD + (4 x 0,01 USD) = 0,05 USD в час.

Если требования к пропускной способности изменились и вы повысили зарезервированные ресурсы пропускной способности до 10 000 единиц для записи и до 50 000 единиц для чтения, ваш счет изменится следующим образом:

(1000 x 0,01 USD) + (1000 x 0,01 USD) = 20 USD/час.

Подробную информацию о ценах DynamoDB см. на странице цен DynamoDB.

Вопрос: Ваши цены указаны с учетом налогов?

Подробнее о налогах см. в разделе Amazon Web Services Tax Help.

Вопрос: Что такое выделенная пропускная способность?

Auto Scaling в Amazon DynamoDB автоматически регулирует ресурсы пропускной способности, чтобы поддерживать нужный уровень целевого потребления и лимит минимального и максимального потребления ресурсов, или позволяет вручную установить нужный уровень пропускной способности, которого должна достигать конкретная таблица. Незаметно для вас сервис выделяет ресурсы, необходимые для достижения определенного уровня пропускной способности. Больше не требуется заботиться об инстансах, оборудовании, памяти и других факторах, которые могут повлиять на пропускную способность, – просто укажите ее нужный уровень. В этом заключается суть модели выделенной пропускной способности сервиса.

При создании новой таблицы или глобального вторичного индекса возможность Auto Scaling включена по умолчанию, с настройками по умолчанию для уровня целевого потребления, минимального и максимального уровня ресурсов. При этом необходимый уровень ресурсов чтения и записи можно задать вручную. Amazon DynamoDB автоматически распределяет и резервирует необходимый объем ресурсов в соответствии с заявленными требованиями к пропускной способности.

Вопрос: Как выбор первичного ключа влияет на уровень масштабируемости?

Для хранения данных Amazon DynamoDB делит таблицу на множество разделов и распределяет данные на основе элемента ключа секции первичного ключа. При выделении ресурсов пропускной способности Amazon DynamoDB предполагает относительно случайный доступ по всем первичным ключам. Модель данных необходимо формировать таким образом, чтобы в результате запросов трафик по первичным ключам распределялся достаточно равномерно. Если интенсивное обращение к таблице выполняется по очень малому числу ключей секций, возможно, только по одному, то трафик будет сосредоточен лишь на нескольких разделах – возможно, на одном. Если рабочая нагрузка сильно разбалансирована, т. е. непропорционально сосредоточена на одном или нескольких разделах, при выполнении операций общий выделенный уровень пропускной способности не будет достигнут. Чтобы обеспечить максимальную пропускную способность Amazon DynamoDB, следует создавать таблицы, где у ключа секции большое количество отдельных значений, запросы к которым выполняются достаточно равномерно (как можно более случайным образом). Примером удачного первичного ключа является CustomerID, если у приложения много пользователей и запросы к разным пользовательским записям выполняются более или менее равномерно. Примером первичного ключа с высокой степенью асимметричности является ключ «название категории продукта», если одни категории продуктов более широко распространены, чем другие.

Вопрос: Что собой представляет единица ресурса чтения/записи?

Как определить, сколько единиц ресурсов чтения и записи требуется приложению? Единица ресурса записи позволяет выполнять одну операцию записи в секунду для элементов объемом не более 1 КБ. Единица ресурса чтения позволяет выполнять одну операцию строго непротиворечивого или две операции потенциально непротиворечивого чтения в секунду для элементов объемом не более 4 КБ. Большие элементы требуют большего количества ресурсов пропускной способности. Чтобы вычислить требуемое количество единиц ресурсов чтения и записи, оцените требуемое число операций чтения или записи в секунду и умножьте его на объем элементов (с округлением до следующего ближайшего целого числа килобайт).

Требуемое число единиц ресурса записи = число операций записи элемента в секунду x объем элемента в блоках по 1 КБ

Требуемое число единиц ресурса чтения* = число операций чтения элемента в секунду x объем элемента в блоках по 4 КБ

* При потенциально непротиворечивом чтении пропускная способность в операциях чтения в секунду будет вдвое выше.

Если объем элементов не превышает 1 КБ, то каждая единица ресурса чтения обеспечит 1 операцию строго непротиворечивого чтения в секунду, а каждая единица ресурса записи – 1 операцию записи в секунду. Например, если объем элементов составляет 512 байт и из таблицы требуется считывать 100 элементов в секунду, то необходимо выделить 100 единиц ресурса чтения.

Если объем элементов превышает 4 КБ, то необходимо рассчитать требуемое число единиц ресурсов чтения и записи. Например, если объем элементов составляет 4,5 КБ и нужно выполнять 100 операций строго непротиворечивого чтения в секунду, то потребуется выделить 100 (операций чтения в секунду) x 2 (блока по 4 КБ, требуемых для сохранения элемента объемом 4,5 КБ) = 200 единиц ресурса чтения.

Обратите внимание на то, что требуемое количество единиц ресурса чтения определяется числом считываемых за секунду элементов, а не числом вызовов API. Например, чтобы считывать 500 элементов таблицы в секунду при объеме элемента не более 4 КБ, потребуется 500 единиц ресурса чтения. При этом неважно, будет ли сделано 500 отдельных вызовов GetItem или 50 вызовов BatchGetItem, каждый из которых вернет 10 элементов.

Вопрос: Всегда ли возможно достигнуть уровня выделенной пропускной способности?

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

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

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

Вопрос: Верно ли, что при извлечении даже одного элемента документа JSON взимается плата за чтение всего элемента таблицы?

Да. При чтении данных из DynamoDB вы используете пропускную способность, требуемую для чтения всего элемента.

Вопрос: Какую наибольшую пропускную способность можно выделить для одной таблицы DynamoDB?

DynamoDB поддерживает неограниченное масштабирование. Тем не менее, чтобы задать величину пропускной способности, превышающую 10 000 единиц ресурса записи или 10 000 единиц ресурса чтения для отдельной таблицы, необходимо отправить в Amazon заявку посредством этой онлайн-формы. Если требуется выделить более 20 000 единиц ресурса записи или 20 000 единиц ресурса чтения для одного аккаунта, сначала свяжитесь с нами посредством вышеуказанной формы.

Вопрос: Какую наименьшую пропускную способность можно выделить для одной таблицы DynamoDB?

Минимальный объем выделенной пропускной способности, который можно запросить – одна единица чтения или записи (как при использовании Auto Scaling, так и при ручном выделении пропускной способности).

Такие значения входят в уровень бесплатного пользования, который включает 25 единиц ресурса записи и 25 единиц ресурса чтения. Уровень бесплатного пользования относится ко всему аккаунту, а не к отдельной таблице. Иными словами, если вы увеличили выделенные ресурсы для всех своих таблиц, и общий объем этих ресурсов не превышает 25 единиц ресурса записи и 25 единиц ресурса чтения, то вы будете пользоваться ими в рамках уровня бесплатного пользования.

Вопрос: Насколько можно изменить выделенную пропускную способность одним запросом?

С помощью API UpdateTable можно увеличить выделенную пропускную способность таблицы на любое значение. Например, одним вызовом API можно увеличить выделенный ресурс записи таблицы на величину от 1 до 10 000 единиц ресурса записи. Для аккаунта действуют ограничения ресурсов на уровне таблиц и аккаунта (подробнее см. на странице документации). Чтобы повысить ограничения по выделенным ресурсам, перейдите на страницу Центра поддержки, нажмите «Открыть новый запрос» и подайте соответствующую заявку.

Вопрос: Как начисляется оплата за выделенную пропускную способность?

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

Вопрос: Как изменить выделенную пропускную способность существующей таблицы DynamoDB?

Изменить выделенную пропускную способность таблицы Amazon DynamoDB можно двумя способами. Это можно сделать в консоли управления или же вызовом API UpdateTable. В любом случае и при повышении, и при снижении уровня выделенной пропускной способности сервис Amazon DynamoDB останется доступным.

Вопрос: Как часто можно менять выделенную пропускную способность?

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

Следует учесть, что невозможно изменить выделенную пропускную способность, пока таблица Amazon DynamoDB находится в процессе ответа на последний запрос о ее изменении. Чтобы проверить состояние таблицы, воспользуйтесь консолью управления или API DescribeTables. Если таблица находится в состоянии CREATING, DELETING или UPDATING, настройка ее пропускной способности невозможна. Дождитесь состояния ACTIVE и попробуйте снова.

Вопрос: Влияет ли модель непротиворечивости на величину пропускной способности?

Да. При данном распределении ресурсов достижимая скорость чтения таблицы DynamoDB различна для строго непротиворечивого и потенциально непротиворечивого чтения. Если вы запросили 1000 единиц ресурса чтения, DynamoDB предоставит достаточное количество ресурсов для достижения 1000 операций строго непротиворечивого чтения в секунду для элементов объемом не более 4 КБ. Чтобы достигнуть 1000 операций потенциально непротиворечивого чтения элементов объемом не более 4 КБ, потребуется половина этого ресурса, т. е. 500 единиц ресурса чтения. Дополнительные сведения по выбору подходящей пропускной способности для таблицы см. в Руководстве по выделению пропускной способности.

Вопрос: Влияет ли объем элемента на пропускную способность?

Да. При данном распределении ресурсов достижимая скорость чтения таблицы DynamoDB зависит от объема элемента. При указании желаемой величины пропускной способности для чтения DynamoDB выделяет ресурсы из расчета, что объем элементов не превышает 4 КБ. При превышении этого объема потребность в количестве ресурсов для достижения того же уровня пропускной способности возрастает линейно. Например, 100 единиц ресурса чтения таблицы DynamoDB обеспечивают 100 операций чтения в секунду для элементов объемом 4 КБ, 50 операций чтения в секунду для элементов объемом 8 КБ, 25 операций чтения в секунду для элементов объемом 16 КБ и так далее.

Аналогичным образом от объема элемента зависит и достижимая скорость записи в таблицу DynamoDB. Когда вы указываете желаемую величину пропускной способности для записи, DynamoDB выделяет ресурсы исходя из предположения о том, что объем элементов не превышает 1 КБ. При превышении этого объема потребность в количестве ресурсов для достижения того же уровня пропускной способности возрастает линейно. Например, 100 единиц ресурса записи таблицы DynamoDB обеспечивают 100 операций записи в секунду для элементов объемом 1 КБ, 50 операций записи в секунду для элементов объемом 2 КБ, 25 операций записи в секунду для элементов объемом 4 КБ и т. д.

Дополнительные сведения по выбору подходящей пропускной способности для таблицы см. в Руководстве по выделению пропускной способности.

Вопрос: Что произойдет, если число операций чтения или записи, выполняемых приложением, превысит ресурсы выделенной пропускной способности?

Если число выполняемых приложением операций чтения или записи в секунду превысит ресурсы выделенной для таблицы пропускной способности, то выполнение «лишних» запросов будет прервано, и для этих запросов будут выданы коды ошибки 400. Например, если, имея 1000 единиц ресурса записи, попытаться выполнить 1500 операций записи в секунду для элементов объемом 1 КБ, то DynamoDB позволит выполнить только 1000 операций записи в секунду, а в ответ на остальные запросы вернет код ошибки 400. Чтобы всегда быть уверенным в том, что выделенной пропускной способности достаточно для достижения требуемой скорости выполнения запросов, для ее отслеживания следует использовать сервис CloudWatch.

Вопрос: Как узнать о превышении выделенных ресурсов пропускной способности?

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

Вопрос: Сколько времени занимает изменение величины выделенной пропускной способности таблицы?

Как правило, на уменьшение пропускной способности требуется от нескольких секунд до нескольких минут, а на увеличение – от нескольких минут до нескольких часов.

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

Вопрос: Что такое зарезервированные ресурсы?

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

  • внесение одноразового авансового платежа;
  • принятия обязательства по минимальному ежемесячному уровню использования в течение срока действия соглашения.

Резервирование ресурсов действует в пределах одного региона AWS. Можно зарезервировать ресурсы на один год или три года. Каждая таблица DynamoDB имеет связанные с ней выделенные ресурсы пропускной способности, либо управляемые Auto Scaling, либо выделенные вручную при создании или обновлении таблицы. Эти ресурсы определяют пропускную способность чтения или записи, достижимую для таблицы DynamoDB. Соглашение о резервировании ресурсов касается начисления платы и напрямую не влияет на производительность или пропускную способность таблиц DynamoDB. Например, приобретя 100 единиц ресурса записи в виде зарезервированных ресурсов, вы обязуетесь платить за этот объем ресурса в течение срока действия соглашения (1 или 3 года) по тарифу со скидкой.

Вопрос: Как приобрести зарезервированные ресурсы?

Авторизуйтесь в Консоли управления AWS, перейдите на страницу консоли DynamoDB и нажмите на ссылку «Зарезервированные ресурсы». Откроется страница «Использование зарезервированных ресурсов». Нажмите на ссылку «Приобрести зарезервированные ресурсы». Откроется форма, которую необходимо заполнить для приобретения зарезервированных ресурсов. Убедитесь, что выбран регион AWS, в котором будут использоваться ваши зарезервированные ресурсы. После завершения покупки зарезервированных ресурсов приобретенные ресурсы отобразятся на странице «Использование зарезервированных ресурсов».

Вопрос: Можно ли отменить покупку зарезервированных ресурсов?

Нет, отменить зарезервированные ресурсы нельзя, одноразовый платеж не возвращается. Вы продолжите платить за каждый час в течение срока действия зарезервированных ресурсов независимо от уровня использования.

Вопрос: Какой минимальный объем зарезервированных ресурсов можно приобрести?

Минимальный объем зарезервированных ресурсов составляет 100 единиц ресурса чтения или записи.

Вопрос: Можно ли приобрести зарезервированные ресурсы с помощью API?

В настоящее время нет. В дальнейшем планируется предоставить соответствующие API и дополнительные возможности для работы с зарезервированными ресурсами.

Вопрос: Можно ли переместить зарезервированные ресурсы из одного региона в другой?

Нет. Зарезервированные ресурсы связаны только с одним регионом.

Вопрос: Можно ли выделить объем ресурсов пропускной способности, превышающий объем зарезервированных ресурсов?

Да. Приобретая зарезервированные ресурсы, вы принимаете минимальный уровень пользования, за который платите по тарифу со скидкой. При выделении объема ресурсов, превышающего этот минимальный уровень, дополнительные ресурсы вы оплачиваете по стандартному тарифу.

Вопрос: Как пользоваться зарезервированными ресурсами?

Зарезервированные ресурсы вносятся в счет автоматически. Например, если вы приобрели 100 единиц ресурса записи в виде зарезервированных ресурсов, а выделили 300 единиц, то приобретенные вами зарезервированные ресурсы автоматически покрывают стоимость 100 единиц ресурса записи, а за остальные 200 единиц вы платите по стандартным тарифам.

Вопрос: Что произойдет, если выделить меньший объем ресурсов пропускной способности, чем объем зарезервированных ресурсов?

Приобретая зарезервированные ресурсы, вы обязуетесь оплачивать минимальный объем выделенных ресурсов пропускной способности по тарифам со скидкой в течение срока действия соглашения. Даже при использовании меньшего объема, чем объем зарезервированных ресурсов, вы ежемесячно будете оплачивать определенный минимальный объем выделенных ресурсов пропускной способности.

Вопрос: Можно ли использовать зарезервированные ресурсы для нескольких таблиц DynamoDB?

Да. Зарезервированные ресурсы применимы для всех выделенных ресурсов в регионе, в котором они приобретены. Например, при покупке 5000 единиц ресурса записи в виде зарезервированных ресурсов можно все 5000 единиц ресурса записи использовать для одной таблицы, или использовать по 50 единиц ресурса записи для 100 таблиц, или использовать по 5 единиц ресурса записи для 1000 таблиц, и так далее.

Вопрос: Можно ли использовать зарезервированные ресурсы с DynamoDB в аккаунтах с консолидированной оплатой?

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

 

Вопрос: Что такое межрегиональная репликация DynamoDB?

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

 

Вопрос: В каких случаях следует использовать межрегиональную репликацию?

Межрегиональную репликацию можно использовать в следующих сценариях.

  • Эффективное аварийное восстановление. Реплицируя таблицы в несколько ЦОД, можно переключаться на таблицы DynamoDB в другом регионе в случае сбоя ЦОД.
  • Более быстрое чтение. При наличии пользователей в нескольких регионах можно ускорить доставку данных путем запросов чтения к таблицам DynamoDB в ближайшем ЦОД AWS.
  • Упрощенное управление трафиком. Реплики можно использовать для распределения рабочих нагрузок чтения между таблицами, тем самым уменьшив использование ресурсов чтения основной таблицы.
  • Простая межрегиональная миграция. Создав реплику чтения в новом регионе и сделав ее основной, вы без труда перенесете свое приложение в этот регион.
  • Миграция данных без остановки работы. Для перемещения таблицы DynamoDB из одного региона в другой можно создать реплику таблицы из исходного региона в регионе назначения. Когда таблицы синхронизируются, можно переключить приложение на запись в регионе назначения.

Вопрос: Какие режимы межрегиональной репликации поддерживаются?

В настоящее время поддерживается режим межрегиональной репликации с одной основной таблицей. На базе одной основной таблицы создаются одна и более реплик.

Вопрос: Как настроить межрегиональную репликацию с одной основной таблицей?

Межрегиональные реплики можно создавать с использованием библиотеки DynamoDB Cross-region Replication Library.

Вопрос: Как узнать о завершении начальной загрузки?

В приложении управления репликацией состояние репликации должно измениться с «Начальная загрузка» на «Активна».

Вопрос: Можно ли создать несколько реплик одной основной таблицы?

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

Вопрос: Сколько стоит межрегиональная репликация таблицы?

Межрегиональная репликация в DynamoDB включается с использованием библиотеки DynamoDB Cross-region Replication Library. За использование библиотеки для межрегиональной репликации дополнительная плата не взимается, вы платите только за ресурсы, используемые в процессе работы, по стандартным тарифам. Клиент оплачивает:

  • выделенный объем пропускной способности (запись и чтение) и хранение реплик таблиц;
  • передачу данных между регионами;
  • чтение данных из DynamoDB Streams для обеспечения синхронизации таблиц;
  • выделенные инстансы EC2 для размещения процесса репликации (стоимость инстансов зависит от выбранного типа инстанса и региона, в котором они будут размещаться).

Вопрос: В каком регионе находится инстанс Amazon EC2, на котором выполняется межрегиональная репликация?

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

Вопрос: Выполняется ли автоматическое масштабирование инстанса Amazon EC2 при изменении объема и пропускной способности основной таблицы и ее реплик?

В настоящее время автоматическое масштабирование инстанса EC2 не выполняется. Размер инстанса нужно выбирать при настройке межрегиональной репликации DynamoDB.

Вопрос: Что произойдет при сбое инстанса Amazon EC2, управляющего репликацией?

Инстанс Amazon EC2 работает в группе auto scaling, поэтому будет выполнен автоматический аварийный переброс приложения на другой инстанс. Лежащее в основе приложение использует клиентскую библиотеку Kinesis (KCL), которая создает контрольные точки копии. В случае сбоя инстанса приложение определяет контрольную точку и с нее возобновляет работу.

Вопрос: Можно ли работать с таблицей DynamoDB во время создания реплики чтения?

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

 

Вопрос: Сколько времени занимает создание реплики?

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

Вопрос: Изменится ли выделенная пропускная способность реплики при изменении выделенной пропускной способности основной таблицы?

После создания реплики изменения выделенной пропускной способности основной таблицы не приведут к изменению выделенной пропускной способности реплики.

 

Вопрос: Будут ли индексы реплик совпадать с индексами основной таблицы?

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

 

Вопрос: У реплики будет такая же выделенная пропускная способность, что и у основной таблицы?

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

 

Вопрос: Какая модель непротиворечивости используется для реплик?

Реплики обновляются асинхронно. DynamoDB подтвердит успешность операции записи, когда она будет принята основной таблицей. После этого запись будет распространена на все реплики. Соответственно, перед распространением на все реплики будет наблюдаться небольшая задержка.

Вопрос: Доступны ли метрики CloudWatch для межрегиональной репликации?

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

Вопрос: Можно ли создать реплику в том же регионе, что и основная таблица?

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

Вопрос: Можно ли добавить или удалить реплику после создания группы репликации?

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

Вопрос: Можно ли удалить группу репликации после ее создания?

Да, при удалении группы репликации будет автоматически удален инстанс EC2 этой группы. Однако вам потребуется удалить таблицу метаданных DynamoDB.

Вопрос: Что такое триггеры DynamoDB?

Триггеры DynamoDB – это функция, которая позволяет выполнять пользовательские действия на основе обновлений элементов таблицы DynamoDB. Пользовательское действие можно задать в коде триггера.

Вопрос: Для чего предназначены триггеры DynamoDB?

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

Вопрос: Как работают триггеры DynamoDB?

Пользовательский код триггера DynamoDB хранится в функции AWS Lambda в виде кода. Чтобы создать триггер для данной таблицы, можно связать функцию AWS Lambda с потоком (посредством DynamoDB Streams) в таблице DynamoDB. При появлении обновлений таблицы они публикуются в DynamoDB Streams. В свою очередь, AWS Lambda считывает обновления соответствующего потока и приводит код в действие.

Вопрос: Какова стоимость использования триггеров DynamoDB?

Используя триггеры DynamoDB, вы платите только за число запросов своей функции AWS Lambda и за время ее выполнения. Дополнительную информацию о ценах сервиса AWS Lambda см. здесь. Плата за выполнение функцией AWS Lambda операций чтения соответствующего потока (посредством DynamoDB Streams) не взимается.

Вопрос: Имеются ли ограничения на количество триггеров для таблицы?

Ограничений на количество триггеров для таблицы нет.

Вопрос: Какие языки программирования можно использовать для триггеров DynamoDB?

В настоящее время для создания триггеров DynamoDB можно использовать языки JavaScript, Java и Python.

Вопрос: Имеются ли API для создания, редактирования или удаления триггеров DynamoDB?

Нет, в настоящее время собственных API для создания, редактирования или удаления триггеров DynamoDB нет. Чтобы создать функцию AWS Lambda и связать ее с потоком DynamoDB Streams, используйте консоль AWS Lambda. Дополнительные сведения см. на странице вопросов и ответов о сервисе AWS Lambda.

Вопрос: Как создать триггер DynamoDB?

Чтобы создать триггер, необходимо создать функцию AWS Lambda и связать источник события функции с потоком DynamoDB Streams. Дополнительные сведения см. на странице вопросов и ответов о сервисе AWS Lambda.

Вопрос: Как удалить триггер DynamoDB?

Удалить триггер можно путем удаления связанной функции AWS Lambda. Чтобы удалить функцию AWS Lambda, воспользуйтесь консолью AWS Lambda или выполните вызов API AWS Lambda. Дополнительные сведения см. на странице вопросов и ответов о сервисе AWS Lambda и на странице документации.

Вопрос: Как создать триггер DynamoDB с использованием существующей функции AWS Lambda?

Вы можете изменить источник события функции AWS Lambda таким образом, чтобы он указывал на поток DynamoDB Streams. Это можно сделать в консоли DynamoDB. В таблице, для которой запущен поток, выберите поток, нажмите кнопку «Привязать функцию Lambda», после чего из списка функций Lambda выберите функцию, которую нужно использовать для триггера DynamoDB.

Вопрос: В каких регионах доступны триггеры DynamoDB?

Триггеры DynamoDB доступны во всех регионах AWS, где доступны сервисы AWS Lambda и DynamoDB.

Вопрос: Что такое DynamoDB Streams?

Функция DynamoDB Streams предоставляет упорядоченную по времени последовательность изменений элементов, внесенных в данные таблицы в течение последних 24 часов. Доступ к потоку DynamoDB Streams осуществляется с помощью простого вызова API. Поток используется для обновления других хранилищ данных в соответствии с последними изменениями DynamoDB или для выполнения действий на основе внесенных в таблицу изменений.

Вопрос: Каковы преимущества DynamoDB Streams?

Используя API DynamoDB Streams, разработчики могут собирать информацию об обновлениях и получать данные на уровне элементов до и после внесения изменений. Это дает возможность создавать расширения приложений, построенных на основе DynamoDB. Например, разработчик глобальной многопользовательской игры на основе DynamoDB может использовать API DynamoDB Streams для создания множественной топологии и синхронизировать основные серверы, получая данные по каждому из них из DynamoDB Streams и воспроизводя обновления на удаленных основных серверах. С помощью API DynamoDB Streams можно также разрабатывать мобильные приложения для автоматического оповещения мобильных устройств всех друзей некоторого круга при загрузке одним из пользователей нового селфи. Функция DynamoDB Streams может использоваться разработчиками для синхронизации средств хранения данных, таких как Amazon Redshift, со всеми изменениями таблицы DynamoDB для аналитики в реальном времени. DynamoDB также интегрируется с Elasticsearch с помощью плагина Logstash Amazon DynamoDB, что позволяет разработчикам использовать поиск произвольного текста в контенте DynamoDB.

Подробнее о DynamoDB Streams см. в документации.

Вопрос: В течение какого времени изменения таблицы DynamoDB остаются доступными в DynamoDB Streams?

DynamoDB Streams хранит записи обо всех изменениях таблицы на протяжении 24 часов. По истечении это времени данные удаляются.

Вопрос: Как включить DynamoDB Streams?

DynamoDB Streams необходимо включать отдельно для каждой таблицы. Чтобы включить DynamoDB Streams для существующей таблицы DynamoDB, выберите таблицу в Консоли управления AWS, перейдите на вкладку «Overview», щелкните кнопку «Manage Stream», выберите тип просмотра и затем щелкните «Enable».

Дополнительную информацию см. в документации.

Вопрос: Как убедиться, что функция DynamoDB Streams включена?

После включения DynamoDB Streams поток будет отображен в Консоли управления AWS. Выбрав таблицу, перейдите на вкладку «Overview». В сведениях о потоке убедитесь, что параметр включения потока установлен в значение «Yes».

Вопрос: Как выполнить обращение к потоку DynamoDB Streams?

Обращения к потокам DynamoDB Streams выполняются посредством простого вызова API с помощью SDK DynamoDB или клиентской библиотеки Kinesis (KCL). KCL позволяет получать и обрабатывать данные из потока и управлять заданиями, такими как балансирование нагрузки между множеством средств чтения, реагирование на сбои инстансов и создание контрольных точек обработанных записей.

Подробнее о работе с DynamoDB Streams см. в документации.

Вопрос: DynamoDB Streams отображает все обновления таблицы DynamoDB в порядке их применения?

Изменения отдельного элемента отображаются в порядке их применения. Изменения разных элементов могут отображаться в DynamoDB Streams в порядке, отличном от порядка их применения.

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

  • Обновление 1. Лучший результат игрока 1: 100 очков.
  • Обновление 2. Лучший результат игрока 2: 50 очков.
  • Обновление 3. Лучший результат игрока 1: 125 очков.

Обновление 1 и обновление 3 связаны с одним и тем же элементом (игрок 1), поэтому в DynamoDB Streams обновление 3 будет отображено после обновления 1. Это позволяет извлекать самую последнюю запись рекорда для каждого игрока. Поток может не отобразить все три обновления в порядке их применения (т. е. то, что обновление 2 выполнено после обновления 1 и перед обновлением 3), но обновления записи каждого игрока будут выведены в порядке их применения.

Вопрос: Нужно ли управлять пропускной способностью потока DynamoDB Streams?

Нет, в DynamoDB Streams управление пропускной способностью потока выполняется автоматически. При значительном увеличении трафика таблицы DynamoDB сервис DynamoDB автоматически отрегулирует пропускную способность потока, чтобы обеспечить принятие всех обновлений.

Вопрос: С какой скоростью можно считывать обновления из DynamoDB Streams?

Обновления из потока DynamoDB Streams можно считывать со скоростью, которая до двух раз превышает величину выделенной пропускной способности записи в таблицу DynamoDB. Например, если выделить пропускную способность, достаточную для обновления 1000 элементов таблицы DynamoDB в секунду, из потока можно считывать до 2000 обновлений в секунду.

Вопрос: Повлечет ли удаление таблицы DynamoDB за собой удаление потока DynamoDB Streams?

Да, но не сразу. Поток будет существовать в DynamoDB Streams в течение 24 часов, что позволит считать последние обновления, примененные к таблице. Через 24 часа поток будет автоматически удален из DynamoDB Streams.

Вопрос: Что произойдет при выключении функции DynamoDB Streams для таблицы?

При выключении функции DynamoDB Streams поток будет существовать в течение 24 часов, но в него не будут внесены никакие дополнительные изменения таблицы DynamoDB.

Вопрос: Что произойдет при выключении функции DynamoDB Streams и ее повторном включении?

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

Вопрос: Возможно ли дублирование или пропуск данных в потоке DynamoDB Streams?

Нет, функция DynamoDB Streams спроектирована таким образом, что каждое обновление, примененное к таблице, будет отражено в потоке не более и не менее одного раза.

Вопрос: Какие данные входят в поток DynamoDB Streams?

Поток DynamoDB Streams содержит данные как о предшествующем, так и о новом значении элемента,  а также о типе изменения (INSERT, REMOVE или MODIFY) и о первичном ключе измененного элемента.

Вопрос: Как выбрать, какие данные будут включены в поток DynamoDB Streams?

Для новых таблиц выполните вызов API CreateTable и укажите параметр ViewType, чтобы выбрать данные для включения в поток.
Для существующих таблиц выполните вызов API UpdateTable и укажите параметр ViewType, чтобы выбрать данные для включения в поток.

Параметр ViewType может принимать следующие значения:

ViewType: {
                    { KEYS_ONLY,
                      NEW_IMAGE,
                      OLD_IMAGE,
                      NEW_AND_OLD_IMAGES}
                }

Расшифровка значений. KEYS_ONLY: в поток будет включено только имя ключа измененного элемента.

  • NEW_IMAGE: в поток будет включено имя ключа и элемент после обновления (новый элемент).
  • OLD_IMAGE: в поток будет включено имя ключа и элемент до обновления (старый элемент).
  • NEW_AND_OLD_IMAGES: в поток будет включено имя ключа, элемент до обновления (старый элемент) и после обновления (новый элемент).

Вопрос: Можно ли для работы с DynamoDB Streams использовать клиентскую библиотеку Kinesis?

Да, разработчики, знакомые с API Kinesis, могут легко получать данные из потока DynamoDB Streams. С помощью переходной библиотеки DynamoDB Streams, которая реализует интерфейс Amazon Kinesis, вы обеспечите использование вашим приложением клиентской библиотеки Amazon Kinesis (KCL) для работы с DynamoDB Streams. Подробнее об использовании KCL для работы с DynamoDB Streams см. в документации.

Вопрос: Можно ли изменить тип данных, включаемых в поток DynamoDB Streams?

Чтобы после создания потока изменить тип сохраняемых в нем данных, необходимо отключить поток и создать новый поток с помощью API UpdateTable.

Вопрос: Через какой промежуток времени изменения таблицы DynamoDB будут отображены в потоке DynamoDB Streams?

Как правило, изменения отображаются в потоке DynamoDB Streams менее чем через секунду.

Вопрос: Будут ли данные об удалении элемента включены в поток DynamoDB Streams?

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

Вопрос: Через какой промежуток времени после включения функции DynamoDB Streams для таблицы можно будет начать считывание данных из потока?

Для получения текущего состояния потока воспользуйтесь API DescribeStream. При изменении состояния на ENABLED все обновления таблицы будут представлены в потоке.

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

Вопрос: Что такое плагин Logstash Amazon DynamoDB для Elasticsearch?

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

Вопрос: Какова стоимость плагина Logstash Amazon DynamoDB?

Плагин Logstash Amazon DynamoDB можно загрузить и использовать бесплатно.

Вопрос: Как загрузить и установить плагин Logstash Amazon DynamoDB?

Плагин Logstash Amazon DynamoDB доступен в репозитории GitHub. Дополнительную информацию об установке и запуске плагина см. в нашей документации.


Вопрос: Что такое серверная часть хранилища DynamoDB для Titan?

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

Вопрос: Что такое графовая БД?

Графовая БД – это хранилище вершин и направленных ребер, соединяющих эти вершины. Как вершины, так и ребра могут иметь свойства, хранящиеся в виде пар «ключ-значение».

Графовая БД использует списки смежности для хранения ребер с целью упрощения обхода графа. Обход графа в графовой БД можно выполнять либо по определенным типам ребер, либо по всем ребрам графа. Графовые БД могут описывать связи элементов путем использования действий, отношения владения, происхождения и т. д.

Вопрос: Какие приложения лучше всего подходят для работы с графовыми БД?

Графовая БД является оптимальным вариантом, когда основу данных, которые вы пытаетесь моделировать, составляют связи или отношения между элементами. Поэтому графовые БД полезны при моделировании социальных сетей, деловых отношений, зависимостей, движений грузов, а также при выполнении запросов к таким системам.

Вопрос: Как начать использовать серверную часть хранилища DynamoDB для Titan?

Самый простой способ начать работу – это запустить инстанс EC2, на котором работает Gremlin Server с серверной частью хранилища DynamoDB для Titan, с помощью шаблонов CloudFormation, упомянутых на странице документации. Также можно клонировать проект из репозитория GitHub и начать работу на своем компьютере, следуя инструкциям по работе с графами Marvel и Graph-Of-The-Gods, представленным в документации. Когда вы будете готовы расширить масштабы тестирования или запустить систему в рабочей среде, вы сможете переключить серверную часть на использование сервиса DynamoDB. Дальнейшие инструкции см. в документации AWS.

Вопрос: Чем отличается серверная часть хранилища DynamoDB от других серверных частей хранилища Titan?

DynamoDB – это управляемый сервис, поэтому использование его в качестве серверной части хранилища для Titan позволяет запускать рабочие нагрузки, связанные с обработкой графа, без необходимости управления собственным кластером для хранения графа.

Вопрос: Является ли серверная часть хранилища DynamoDB для Titan полностью управляемым сервисом?

Нет. Серверная часть хранилища DynamoDB для Titan управляет уровнем хранилища для ваших рабочих нагрузок Titan. Однако плагин не осуществляет выделение ресурсов и управление на стороне клиента. Для простого выделения ресурсов при работе с Titan существует шаблон CloudFormation, который настраивает серверную часть хранилища DynamoDB для Titan с Gremlin Server (см. инструкции здесь).

Вопрос: Какова стоимость использования серверной части хранилища DynamoDB для Titan?

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

Вопрос: Обеспечивает ли серверная часть хранилища DynamoDB полную совместимость с набором функций Titan других серверных частей?

Таблица, в которой сравниваются наборы функций разных серверных частей хранилища Titan, доступна в документации.

Вопрос: Какие версии Titan поддерживает плагин?

На данный момент выпущены плагины серверной части хранилища DynamoDB для Titan версий 0.5.4 и 1.0.0.

Вопрос: Я использую Titan с другой серверной частью. Могу ли я перейти на использование DynamoDB?

Конечно. Серверная часть хранилища DynamoDB для Titan включает интерфейс Titan KCV Store, что позволяет вам переключиться с другой серверной части хранилища на DynamoDB с минимальными изменениями в приложении. Для полного сравнения серверных частей хранилища для Titan см. нашу документацию.

Вопрос: Я использую Titan с другой серверной частью. Как мне перейти на использование DynamoDB?

Можно использовать пакетную загрузку для копирования графа из одной серверной части хранилища в серверную часть хранилища DynamoDB для Titan.

Вопрос: Как подключить инстанс Titan к DynamoDB с помощью плагина?

Если вы создаете граф и инстанс с сервером Gremlin с установленной серверной частью хранилища DynamoDB для Titan, то для подключения к DynamoDB вам необходимо просто указать принципал безопасности или набор учетных данных в цепочке поставщика учетных данных AWS по умолчанию. Это можно сделать в профиле инстанса EC2, с помощью переменных среды или файла учетных данных в вашей домашней папке. После этого необходимо будет указать адрес/URL сервера DynamoDB, к которому требуется подключиться.

Вопрос: Насколько надежно хранятся мои данные при использовании серверной части хранилища DynamoDB для Titan?

При использовании серверной части хранилища DynamoDB для Titan DynamoDB обеспечивает надежную защиту ваших данных, работая на базе надежных ЦОД Amazon с высокой степенью доступности. Сервис выполняет репликацию данных на трех серверах региона AWS в целях обеспечения отказоустойчивости при выходе сервера из строя или аварийном отключении зоны доступности.

Вопрос: Насколько защищена серверная часть хранилища DynamoDB для Titan?

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

Вопрос: Как осуществляется масштабирование серверной части хранилища DynamoDB для Titan?

Серверная часть хранилища DynamoDB для Titan масштабируется аналогично любой другой рабочей нагрузке DynamoDB. Можно увеличить или уменьшить требуемую пропускную способность в любое время.

Вопрос: Сколько вершин и ребер может содержать граф?

Ограничения определяются ограничениями Titan, которые равны (2^60) для максимального числа ребер и половине максимального количества вершин в графе, если вы используете многоэлементную модель для таблицы edgestore. Если вы используете одноэлементную модель, то количество ребер, которые вы можете хранить в определенном ключе точки сочленения графа, ограничено максимальным размером элемента DynamoDB, который в настоящее время составляет 400 КБ.

Вопрос: Насколько объемными могут быть свойства вершин и ребер?

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

Вопрос: Сколько существует моделей хранения данных? Какие отличия между ними?

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

Вопрос: Какую модель данных мне лучше использовать?

В общем случае мы рекомендуем использовать многоэлементную модель данных для таблиц edgestore и graphindex. В противном случае вы либо ограничите количество ребер/свойств вершин, которое вы можете хранить для одной точки сочленения графа, либо ограничите количество элементов, которые можно индексировать по определенной паре имя-значение в индексе графа. В общем случае вы можете использовать одноэлементную модель данных для других 4 хранилищ KCV в Titan версий 0.5.4 и 1.0.0, поскольку каждый из элементов, хранящихся в них, обычно имеет размер менее 400 КБ. Полный список таблиц, которые создает плагин Titan в DynamoDB, см. здесь.

Вопрос: Нужно ли создавать схему для графовых БД Titan?

Titan поддерживает автоматическое создание типов, поэтому новые свойства ребер/вершин и метки регистрируются на лету при первом использовании (см. подробности по ссылке). По умолчанию используется схема Gremlin (Edge labels=MULTI, Vertex properties=SINGLE).

Вопрос: Можно ли изменить схему графовой БД Titan?

Да, но при этом вы не можете изменить схему существующих свойств вершин и ребер, а также меток. Подробнее см. по ссылке.

Вопрос: Как серверная часть хранилища DynamoDB для Titan взаимодействует с суперузлами?

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

Вопрос: Поддерживает ли серверная часть хранилища DynamoDB для Titan операции пакетной обработки графов?

Да, серверная часть хранилища DynamoDB для Titan поддерживает операции пакетной обработки графов с помощью API BatchGraph интерфейса Blueprints, а также с помощью параметров конфигурации массовой загрузки.

Вопрос: Поддерживает ли серверная часть хранилища DynamoDB для Titan транзакции?

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

Вопрос: Может ли инстанс Titan, расположенный в одном регионе, получить доступ к DynamoDB в другом регионе?

Доступ к адресу/URL DynamoDB в регионе, отличном от региона расположения инстанса EC2 Titan, возможен, но не рекомендуется. При запуске сервера Gremlin за пределами EC2 мы рекомендуем подключаться к адресу/URL сервера DynamoDB в регионе вашего инстанса EC2, чтобы уменьшить влияние задержек при межрегиональных запросах. Мы также рекомендуем запускать инстанс EC2 в VPC для повышения производительности сети. Шаблон CloudFormation сможет выполнить всю эту настройку за вас.

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

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


Вопрос: Передаются ли метрики Amazon DynamoDB в CloudWatch?

Да, сервис Amazon DynamoDB отправляет в CloudWatch несколько метрик на уровне таблиц. На основании этих метрик можно принимать текущие решения по работе таблиц Amazon DynamoDB или выполнять специальные действия, например отправку предупреждений. Полный список передаваемых метрик см. в разделе «Мониторинг работы DynamoDB с помощью CloudWatch».

Вопрос: Где можно просмотреть метрики CloudWatch для таблиц Amazon DynamoDB?

В консоли Amazon DynamoDB выберите таблицу, метрики которой хотите просмотреть, а затем перейдите на вкладку «Метрики».

Вопрос: С какой периодичностью отправляются метрики?

Большинство метрик CloudWatch для Amazon DynamoDB отправляются каждую минуту, остальные – с интервалом в пять минут. Подробности см. в разделе «Мониторинг работы DynamoDB с помощью CloudWatch».


Вопрос: Что такое тег?

Тег – это метка, назначаемая ресурсу AWS. Каждый тег состоит из ключа и значения; оба эти параметра определяются пользователем. В AWS теги используются для упорядочения расходов на ресурсы в отчете по распределению расходов. Подробнее о создании тегов см. в Руководстве пользователя AWS по работе со счетами и управлению расходами.

Вопрос: Для каких ресурсов DynamoDB можно назначать теги?

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

Вопрос: Почему стоит использовать теги для DynamoDB?

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

Вопрос: Как использовать теги для управления распределением расходов?

Теги распределения расходов позволяют группировать и отслеживать расходы на сервисы AWS. AWS Cost Explorer и подробные финансовые отчеты поддерживают распределение расходов на сервисы AWS по тегам. Чаще всего используются бизнес-теги, относящие расходы к конкретному центру или подразделению, клиенту или проекту. Это позволяет перевести расходы на AWS в традиционный формат распределения расходов. Однако в отчет по распределению расходов можно включить и любые другие теги. Это позволяет распределить расходы по техническим параметрам или аспектам безопасности, связав их с конкретными приложениями, средами или программами по обеспечению соответствия требованиям.

Вопрос: Как можно просмотреть расходы на ресурсы AWS, которым назначены теги?

С расходами на ресурсы AWS, которым назначены теги, можно ознакомиться с помощью инструмента Cost Explorer или в отчете по распределению расходов.

Cost Explorer – это бесплатный инструмент AWS для просмотра расходов за прошедший период (до 13 месяцев) и прогнозирования расходов на следующие три месяца. Чтобы ознакомиться с расходами по определенному тегу, используйте фильтр «Tag», указав в нем ключ и значение тега (если значение тега не определено, выберите «No tag»).

В отчете по распределению расходов приведены все расходы на сервисы AWS за каждый расчетный период. Отчет включает расходы на ресурсы с тегами и без, что позволяет понятно распределить стоимость используемых ресурсов. Например, если использовать в качестве тега для ресурсов название приложения, можно легко отследить стоимость использования конкретного приложения, потребляющего эти ресурсы. Подробнее о распределении расходов см. в Руководстве пользователя AWS по работе со счетами и управлению расходами.

Вопрос: Можно ли назначать теги для потоков DynamoDB?

Нет, в настоящее время назначение тегов для потоков DynamoDB не поддерживается.

Вопрос: Будет ли в счете под тегами для используемой таблицы отображаться потребление зарезервированных ресурсов?

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

Вопрос: Будет ли в счете под тегами для используемой таблицы отображаться стоимость использования данных?

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

Вопрос: Необходимо ли указывать численное значение для каждого тега?

Нет, значения тегов могут быть пустыми.

Вопрос: Теги обрабатываются с учетом регистра?

Да, ключи и значения тегов обрабатываются с учетом регистра.

Вопрос: Сколько тегов можно назначить для одной таблицы DynamoDB?

Для одной таблицы DynamoDB можно назначить до 50 тегов. Теги с префиксом «aws:» создаются только автоматически, они не учитываются при определении лимита тегов

Вопрос: Можно ли назначить теги для таблиц DynamoDB задним числом?

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

Вопрос: Если удалить тег таблицы DynamoDB до конца месяца, будет ли этот тег отражен в счете?

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

Вопрос. Что происходит с созданными тегами при удалении таблицы DynamoDB?

При удалении таблицы DynamoDB теги автоматически удаляются.

Вопрос. Что будет, если добавить тег с тем же ключом, что и ключ другого существующего тега?

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


Вопрос: Что такое Время жизни (TTL) DynamoDB?

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

Вопрос: Зачем использовать TTL?

Существуют два основных сценария использования TTL:

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

Вопрос: Как действует TTL DynamoDB?

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

Фоновый сканер DynamoDB выполняет мониторинг всех элементов БД. Если временная отметка достигнута, процесс отметит элемент как устаревший и поставит его в очередь на удаление.

Примечание. Для использования TTL необходимо использовать числовые атрибуты таблиц DynamoDB с временными отметками в формате POSIX, включающими критерии устаревания данных. При указании значения атрибута TTL нужно действовать внимательно, так как некорректный атрибут может привести к досрочному удалению объекта.

Вопрос: Как указать значение TTL?

Чтобы указать TTL, сначала включите опцию TTL в таблице и укажите, какой из атрибутов использовать для хранения значения TTL. При добавлении новых элементов в таблицу вы сможете указывать для них атрибуты TTL, чтобы сервис DynamoDB автоматически удалял их по истечении срока жизни. Значение атрибута TTL – это время устаревания в формате POSIX. Об остальном позаботится DynamoDB. TTL можно установить через консоль из вкладки обзора таблицы. Можно также установить TTL элементов таблицы с помощью TTL API. См. документацию и руководство по API.

Вопрос: Можно ли создать TTL для существующих таблиц?

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

Вопрос: Можно ли создать TTL для всей таблицы и удалить ее целиком?

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

Вопрос: Можно ли указать TTL для определенной подгруппы элементов таблицы?

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

Вопрос: В каком формате указывается TTL?

Значение TTL указывается в формате времени POSIX – это время в секундах, прошедшее с наступления 1 января 1970 г. по времени UTC. Если в атрибуте TTL будет указано значение в неправильном формате, то оно будет проигнорировано и объект не будет удален.

Вопрос: Как считывать значения TTL элементов таблицы?

Атрибут TTL ничем не отличается от обычных атрибутов элементов. Его значение читается так же, как значение любого другого атрибута. Чтобы удобней следить за значениями TTL, в Консоли DynamoDB можно навести курсор мыши на атрибут TTL и увидеть местное время и время UTC в нормальном формате.

Вопрос: Можно ли создать индекс на основании значений TTL элементов таблицы?

Да. TTL работает, как и любой другой атрибут элемента. Индексы для них создаются так же, как и для других атрибутов.

Вопрос: Можно ли проецировать атрибут TTL на индекс?

Да. Атрибут TTL можно проецировать на индекс, как и любой другой атрибут.

Вопрос: Можно ли редактировать значение TTL объекта после того, как оно уже было установлено?

Да. Значение атрибута TTL можно менять абсолютно так же, как и значения других атрибутов объектов.

Вопрос: Можно ли изменить атрибут TTL таблицы?

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

Вопрос: Можно ли использовать Консоль управления AWS для просмотра и редактирования значений TTL?

Да. Консоль управления AWS позволяет без труда просматривать, задавать и обновлять значения TTL.

Вопрос: Можно ли задать атрибут в документе JSON в качестве атрибута TTL?

Нет. В настоящее время функция использования атрибута документа JSON в качестве атрибута TTL не поддерживается. Чтобы задать значение TTL, необходимо явно задать атрибут TTL для каждого объекта.

Вопрос: Можно ли задать значение TTL для отдельного элемента внутри документа JSON?

Нет. Значение TTL можно задать только для всего документа. Удаление отдельных элементов документа JSON по окончании срока жизни не поддерживается.

Вопрос: Как удалить TTL определенных объектов?

Чтобы удалить TTL, достаточно удалить назначенное для атрибута TTL значение или удалить сам атрибут объекта.

Вопрос: Можно ли установить временную отметку TTL задним числом?

Да, вы можете установить уже прошедшее время в TTL. Когда фоновый процесс, обнаруживающий устаревшие объекты, найдет измененный объект, он отметит его и отправит в очередь на удаление. Однако если значение атрибута TTL содержит дату в формате POSIX, которая наступила пять или более лет назад, DynamoDB проигнорирует ее и не удалит объект. Это сделано для того, чтобы избежать случайного удаления объектов с подозрительно низким значением атрибута TTL.

Вопрос: Сколько времени проходит с момента истечения срока жизни объекта до его фактического удаления?

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

Вопрос: Что будет, если сделать запрос или просканировать объекты, отмеченные на удаление системой TTL?

Учитывая, что элементы, отмеченные как устаревшие, удаляются не сразу, запросы к устаревшим, но еще не удаленным объектам будут проходить, как обычно. Если такие результаты нужно исключить, их можно отфильтровать по значению TTL.

Вопрос: Что будет с данными в локальном вторичном индексе (LSI), если его время жизни истечет?

Результат будет тем же, что и при операции удаления. Локальный вторичный индекс хранится на том же разделе, что и сам объект. Поэтому удаляемый объект автоматически исключается из локального вторичного индекса.

Вопрос: Что будет с данными в глобальном вторичном индексе (GSI), если его время жизни истечет?

Результат будет тем же, что и при операции удаления. Глобальный вторичный индекс (GSI) включает потенциально непротиворечивые данные, так что после того, как устаревший объект будет удален, обновление GSI займет еще какое-то время.

Вопрос: Как TTL работает с DynamoDB Streams?

Устаревание данных в таблице в результате инициации значением TTL удаления записывается как операция удаления. Таким образом, эта операция удаления также будет записана в потоки. У этой записи об удалении будет специальное примечание, по которому можно будет отличить удаление с помощью TTL от пользовательского удаления. Запись заносится в поток в момент удаления, а не в момент истечения времени жизни объекта, и отражает фактическое время удаления. См. документацию и руководство по API.

Вопрос: Когда следует использовать операцию удаления, когда – TTL?

TTL идеально подходит для удаления из таблицы устаревших объектов. При этом TTL удаляет ненужные данные по принципу наименьших затрат и не дает гарантий по сроку удаления. Таким образом, если данные из таблицы необходимо удалить в строго определенный срок (обычно сразу же), рекомендуется использовать команду удаления.

Вопрос: Можно ли контролировать доступ к указанию и обновлению значений TTL?

Да. Атрибут TTL не отличается от других атрибутов таблицы. Вы можете контролировать доступ к нему на уровне атрибута таблицы. Атрибут TTL подчиняется правилам доступа, установленным для всей таблицы.

Вопрос: Можно ли восстановить данные, удаленные в результате истечения времени жизни?

Нет. Для устаревших объектов не создается резервных копий перед удалением. Для слежения за изменениями в таблице и восстановления значений можно использовать DynamoDB Streams. Удаленные элементы хранятся в DynamoDB Streams в течение 24 часов после удаления.

Вопрос: Как узнать, включен ли TTL в таблице?

Статус TTL можно узнать с помощью API DescribeTable или в разделе информации о таблице в консоли DynamoDB. См. документацию и руководство по API.

Вопрос: Как можно отслеживать, какие объекты удаляет TTL?

Если вы используете DynamoDB Streams, все удаления TTL будут записаны в них и отмечены как системные, чтобы их можно было отличить от непосредственных удалений пользователем. Объекты из потоков при необходимости можно считать и обработать. Можно также разработать Lambda-функцию для их отдельного архивирования. См. документацию и руководство по API.

Вопрос: Подлежит ли использование TTL для моих данных дополнительной оплате?

Нет. Активация TTL выполняется бесплатно.

Вопрос: Как активация TTL скажется на совокупном потреблении ресурсов?

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

Вопрос: Придется ли мне платить за операции сканирования для мониторинга TTL?

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

Вопрос: Придется ли мне оплачивать хранение удаляемых устаревших объектов?

Да. Устаревшие объекты добавляются в очередь для последующего удаления. Но до момента фактического удаления для них, как и для любых других объектов, открыт доступ на чтение и запись и взимается стоимость за хранение.

Вопрос: Если я создам запрос к устаревшему объекту, будет ли он учитываться в моем объеме запросов?

Да. Работает тот же принцип, что и при создании запроса к объекту, которого нет в таблице.


Вопрос: Что такое Amazon DynamoDB Accelerator (DAX)?

Amazon DynamoDB Accelerator (DAX) – это полностью управляемый, высокодоступный кэш в памяти для DynamoDB, который позволяет использовать преимущество высокопроизводительной обработки данных в памяти для требовательных к ресурсам приложений. DAX повышает производительность рабочих нагрузок DynamoDB с большим объемом операций чтения, при этом результаты повторного чтения кэшированных данных могут быть выданы немедленно, с чрезвычайно низкой задержкой, без необходимости обработки повторного запроса к DynamoDB. При отсутствии данных в кэше DAX автоматически извлекает их из таблиц DynamoDB. Операции записи являются сквозными (данные сначала записываются в DynamoDB, а затем обновляются в кэше DAX).

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

Чтобы начать работу, нужно создать кластер DAX, загрузить DAX SDK для Java или Node.js (совместимый с API DynamoDB), заново скомпоновать приложение под использование клиента DAX вместо клиента DynamoDB и, наконец, указать клиент DAX в качестве конечной точки кластера DAX. Внедрять дополнительную логику кэширования в приложение не требуется, поскольку клиент DAX реализует те же вызовы API, что и DynamoDB.

Вопрос: Что означает «совместимость с DynamoDB»?

Это означает, что большая часть кода, приложений, драйверов и инструментов, используемых сегодня с базами данных DynamoDB, может использоваться с DAX с незначительными модификациями или вовсе без них. Ядро DAX поддерживает вызовы API DynamoDB для операций чтения и изменения данных в DynamoDB. Операции управления таблицами, такие как CreateTable, DescribeTable, UpdateTable, DeleteTable, не поддерживаются.

Вопрос: Что такое кэширование в памяти и как оно может помочь моему приложению?

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

Вопрос: Какая модель непротиворечивости используется в DAX?

При чтении данных из DAX пользователи могут указать модель непротиворечивости чтения: чтение потенциально непротиворечивых данных или строго непротиворечивых данных.

Чтение потенциально непротиворечивых данных (модель по умолчанию) позволяет максимально увеличить пропускную способность чтения и сократить задержки до минимума. При успешном поиске данных в кэше клиент DAX возвращает результат непосредственно из кэша. При отсутствии данных в кэше DAX выполняет запрос к DynamoDB, обновляет кэш и возвращает результат запроса. Следует отметить, что при чтении потенциально непротиворечивых данных результат может не отражать недавно завершенные операции записи. Если приложение требует полностью непротиворечивых данных, рекомендуется использовать модель чтения строго непротиворечивых данных.

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

Вопрос: Каковы наиболее распространенные примеры использования DAX?

Для DAX существуют несколько примеров использования, при этом они не являются взаимоисключающими.

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

Приложения, которые читают небольшое количество элементов чаще, чем другие элементы. Например, представьте себе систему интернет-коммерции, которая проводит однодневную распродажу популярного продукта. Во время распродажи спрос на этот продукт (и на его данные в DynamoDB) резко увеличится по сравнению со всеми другими продуктами. Чтобы смягчить влияние «горячего» ключа и неравномерного распределения данных, можно перенаправить операции чтения в кэш DAX до завершения однодневной распродажи.

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

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

Принципы работы

Вопрос: Какие виды управления берет на себя DAX?

DAX – это полностью управляемый кэш для DynamoDB. Он управляет настройкой выделенных узлов кэширования, от выделения ресурсов сервера до установки программного обеспечения DAX. Когда кластер кэша DAX настроен и работает, сервис автоматически выполняет основную часть стандартных административных задач, таких как обнаружение сбоев и восстановление, а также установка исправлений ПО. DAX предоставляет подробные метрики мониторинга CloudWatch, связанные с кластером, позволяя очень быстро обнаруживать неполадки и реагировать на них. Используя эти метрики, можно настроить пороговые значения для получения предупреждений CloudWatch. DAX выполняет все кэширование, извлечение и вытеснение данных, поэтому приложению клиента не нужно заниматься этими операциями. Можно просто использовать API DynamoDB для записи и извлечения данных, а DAX в фоновом режиме будет выполнять всю логику кэширования, чтобы повысить производительность.

Вопрос: Какие типы данных кэширует DAX?

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

Приведенные ниже вызовы API приводят к анализу кэша. При нахождении в кэше элемент будет возвращен. При неуспешном поиске в кэше запрос будет проходить транзитом, и после успешного извлечения элемент будет помещен в кэш и возвращен в виде результата.

• GetItem
• BatchGetItem
• Query
• Scan

Приведенные далее вызовы API являются сквозными операциями записи.

• BatchWriteItem
• UpdateItem
• DeleteItem
• PutItem

Вопрос: Как DAX выполняет вытеснение данных?

DAX выполняет вытеснение данных из кэша тремя различными способами. Во-первых, он использует значение времени жизни (TTL), которое обозначает предельный период времени, в течение которого элемент доступен в кэше. Во-вторых, когда кэш заполнен, кластер DAX использует алгоритм «дольше всего не используемый» (LRU) для определения того, какие элементы будут вытеснены. В-третьих, при использовании функционала сквозной записи DAX вытесняет более старые значения, поскольку новые значения записываются через DAX. Это помогает поддерживать кэш данных DAX в соответствии с базовым хранилищем данных, используя один вызов API.

Вопрос: Работает ли DAX с глобальными и локальными вторичными индексам DynamoDB?

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

Вопрос: Как DAX обрабатывает результирующие наборы данных запросов и сканирования?

В кластере DAX имеются два разных кэша: 1) кэш элементов и 2) кэш запросов. Кэш элементов обрабатывает запросы GetItem, PutItem и DeleteItem для отдельных пар ключ-значение. Кэш запросов управляет результирующими наборами данных запросов Scan и Query. В этом случае текст запроса Scan/Query является «ключом», а результат – «значением». Хотя кэш элементов и кэш запросов находятся в одном кластере (и можно указать разные значения TTL для каждого кэша), они не перекрываются. Например, сканирование таблицы не заполняет кэш элементов, а вместо этого добавляет запись в кэш запросов, и в этой записи хранится результирующий набор данных сканирования.

Вопрос: Приводит ли обновление кэша элементов к обновлению или аннулированию результирующих наборов данных в кэше запросов?

Нет. Лучший способ уменьшить несоответствие между результирующими наборами данных в кэше элементов и кэше запросов – установить TTL для кэша запросов на приемлемое значение периода времени, при котором приложение может обрабатывать такие несоответствия.

Вопрос: Можно ли подключиться к кластеру DAX, находясь за пределами соответствующего VPC?

Единственный способ подключения к кластеру DAX из точки, находящейся вне соответствующего VPC, – это VPN-подключение.

Вопрос: Что произойдет, если при использовании DAX операции с базовыми таблицами DynamoDB будут ограничены?

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

Вопрос: Поддерживает ли DAX предварительную инициализацию кэша?

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

Вопрос: Как DAX работает с возможностью TTL в DynamoDB?

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

В контексте DAX TTL указывает продолжительность времени, в течение которого действителен элемент в кэше. Например, если TTL установлено на 5 минут, после того как элемент будет загружен в кэш, он будет оставаться действительным и выдаваться из кэша до истечения 5-минутного периода. Следует также заметить, хотя это и не самый важный момент в обсуждаемом вопросе, что TTL может быть замещен с помощью записи в кэш того же элемента или при наличии дефицита памяти на узле DAX и вытеснении элементов по алгоритму «дольше всего не используемый» (LRU).

Хотя TTL для DynamoDB и DAX будет работать в очень разных временных масштабах (TTL DAX работает в диапазоне минут/часов, а TTL DynamoDB работает в диапазоне недель/месяцев/лет), клиентам следует понимать, как эти две возможности влияют друг на друга. Давайте представим ситуацию, в которой значение TTL для DynamoDB меньше значения TTL для DAX. В этом случае элемент может быть кэширован в DAX и впоследствии удален из DynamoDB с помощью функции TTL DynamoDB. Результатом будет несогласованный кэш. Мы не ожидаем частого повторения такой ситуации, поскольку временные масштабы для этих двух возможностей, как правило, отличаются на порядок, однако рекомендуем разобраться, как эти две возможности связаны друг с другом.

Вопрос: Поддерживает ли DAX межрегиональную репликацию?

В настоящее время DAX поддерживает только таблицы DynamoDB в том же регионе AWS, в котором находится кластер DAX.

Вопрос: Поддерживается ли DAX в качестве типа ресурса в AWS CloudFormation?

Да. С помощью AWS CloudFormation можно создавать, обновлять и удалять кластеры DAX, группы параметров и группы подсетей.

Начало работы

Вопрос: Как начать работу с DAX?
Создать новый кластер DAX для получения конечной точки кластера DAX можно через Консоль AWS или AWS SDK. Клиент, совместимый с DAX, должен быть загружен и использован в приложении с новой конечной точкой DAX.

Вопрос: Как создать кластер DAX?

Кластер DAX можно создать с помощью Консоли AWS или интерфейса командной строки DAX. Кластеры DAX имеют кэш от 13 ГиБ (dax.r3.large) до 216 ГиБ (dax.r3.8xlarge) в инстансах типа R3 и кэш от 15,25 ГиБ (dax.r4.large) до 488 ГиБ (dax.r4.16xlarge) в инстансах типа R4. Для увеличения пропускной способности с помощью нескольких щелчков мышью в консоли AWS или одного вызова API можно добавить в кластер реплики чтения (до 10 реплик).

Конфигурация, включающая один узел, позволяет начать работу с DAX быстро и недорого, а затем увеличивать количество узлов по мере необходимости. Многоузловая конфигурация включает в себя основной узел, который управляет записью, и до девяти узлов реплик чтения. Основной узел выделяется автоматически.

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

Вопрос: Требуется ли для использования DAX, чтобы все мои данные помещались в памяти?

Нет. DAX будет использовать доступную память на узле. Когда объем памяти закончится, будут использованы TTL и/или алгоритм LRU для вытеснения элементов и освобождения места для новых данных.

Вопрос: Какие языки поддерживает DAX?

DAX предоставляет пакеты SDK DAX для Java и Node.js, которые уже доступны для скачивания. Мы работаем над поддержкой дополнительных клиентов.

Вопрос: Можно ли использовать DAX и DynamoDB одновременно?

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

Вопрос: Можно ли использовать несколько кластеров DAX для одной и той же таблицы DynamoDB?

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

Вопрос: Как узнать, какой тип узла DAX потребуется для конкретной рабочей нагрузки?

Определение размера кластера DAX выполняется методом последовательных приближений. Рекомендуется выделять кластер с тремя узлами (для высокой доступности) и достаточным объемом памяти, чтобы в ней помещался рабочий набор данных приложения. В зависимости от производительности и пропускной способности приложения, загрузки кластера DAX и коэффициента попадания в кэш/кэш-промахов, для достижения желаемых результатов может понадобиться масштабирование кластера DAX.

Вопрос: На каких типах инстансов EC2 может работать DAX?

Допустимы следующие типы узлов.

R3:

• dax.r3.large (13 ГиБ)
• dax.r3.xlarge (26 ГиБ)
• dax.r3.2xlarge (54 ГиБ)
• dax.r3.4xlarge (108 ГиБ)
• dax.r3.8xlarge (216 ГиБ)

R4:

• dax.r4.large (15,25 ГиБ)
• dax.r4.xlarge (30,5 ГиБ)
• dax.r4.2xlarge (61 ГиБ)
• dax.r4.4xlarge (122 ГиБ)
• dax.r4.8xlarge (244 ГиБ)
• dax.r4.16xlarge (488 ГиБ)

Вопрос: Поддерживает ли DAX зарезервированные инстансы или уровень бесплатного пользования AWS?

В настоящее время DAX поддерживает только инстансы по требованию.

Вопрос: Как определяются цены на DAX?

Оплата за использование DAX начисляется за каждый час работы узла с момента его запуска до момента остановки. Каждый частично использованный час работы узла оплачивается как полный. Оплачивается работа каждого отдельного узла в кластере DAX. Например, если используется кластер DAX с тремя узлами, необходимо будет оплатить работу каждого отдельного узла (то есть всех трех узлов) на почасовой основе.

Доступность

Вопрос: Как с помощью кластера DAX можно добиться высокой доступности?

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

Вопрос: Что произойдет в случае отказа узла DAX?

Если происходит отказ основного узла, DAX автоматически обнаруживает сбой, выбирает одну из доступных реплик чтения и назначает ее новым основным узлом. Кроме того, DAX выделяет новый узел в той же зоне доступности, где находился отказавший основной узел; этот новый узел заменяет реплику чтения, которая была назначена основным узлом. Если отказ основного узла произошел из-за нарушений в работе зоны доступности, новая реплика будет запущена сразу после восстановления функционирования зоны доступности. При отказе кластера, состоящего из одного узла, DAX запускает новый узел в той же зоне доступности.

Масштабирование

Вопрос: Какой тип масштабирования поддерживает DAX?

В настоящее время DAX поддерживает два варианта масштабирования. Первый вариант – масштабирование операций чтения для получения дополнительной пропускной способности путем добавления в кластер реплик чтения. Один кластер DAX поддерживает до 10 узлов, обслуживающих миллионы запросов в секунду. Добавление или удаление дополнительных реплик выполняется без остановки работы. Второй способ масштабирования кластера – масштабирование в нужном направлении путем выбора типов инстансов r3 большего или меньшего размера. Более крупные узлы позволяют кластеру хранить больший объем набора данных приложения в памяти, при этом уменьшаются кэш-промахи и увеличивается общая производительность приложения. При создании кластера DAX все узлы в кластере должны использовать один и тот же тип инстанса. Кроме того, если требуется изменить тип инстанса для кластера DAX (например, масштабировать вверх с r3.large до r3.2xlarge), нужно создать новый кластер DAX с требуемым типом инстанса. DAX в настоящее время не поддерживает операции масштабирования с изменением типа инстансов без остановки работы.

Вопрос: Как можно масштабировать приложение для операций записи?

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

Мониторинг

Вопрос: Как можно выполнять мониторинг производительность кластера DAX?
Метрики загрузки ЦПУ, количество попаданий в кэш/кэш-промахов и трафик чтения/записи в кластер DAX доступны через Консоль управления AWS или API Amazon CloudWatch. Можно также создать дополнительные пользовательские метрики с помощью функциональных возможностей Amazon CloudWatch по созданию специальных метрик. Помимо метрик CloudWatch, DAX также предоставляет информацию о попаданиях в кэш, кэш-промахах, запросах и производительности кластера через Консоль управления AWS.

Обслуживание

Вопрос: Что такое окно обслуживания? Доступен ли кластер DAX во время обслуживания программного обеспечения?

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

Установка необходимых исправлений планируется автоматически только для исправлений, затрагивающих безопасность или надежность данных. Такие исправления устанавливаются нечасто, как правило, раз в несколько месяцев. Если предпочтительное еженедельное окно обслуживания не было указано при создании кластера, оно будет назначено по умолчанию. При необходимости изменить время проведения обслуживания это можно сделать, изменив кластер в Консоли управления AWS или с помощью API UpdateCluster. Для каждого из кластеров можно задать свое окно обслуживания.

Для кластеров с несколькими узлами обновления в кластере выполняются последовательно, узлы обновляются по очереди, один за другим. После обновления узла он синхронизируется с одним из других узлов кластера, чтобы обновленный узел содержал актуальный рабочий набор данных. Для одноузлового кластера выделяется реплика (бесплатно для клиента), реплика синхронизируется с последними данными, затем выполняется переключение и новая реплика становится основным узлом. Таким образом, во время обновления кластера с одним узлом данные не теряются.  

Вопрос: Что такое конечные точки VPC (VPCE) для DynamoDB?

Amazon Virtual Private Cloud (VPC) – это сервис AWS, который предоставляет пользователям виртуальное частное облако путем выделения логически изолированного раздела облака Amazon Web Services (AWS). Конечная точка VPC (VPCE) для DynamoDB является логическим объектом в VPC, который создает частное соединение между VPC и DynamoDB через устройство NAT или VPN-подключение, то есть не требуя доступа через Интернет. Дополнительную информацию о конечных точках VPC см. в Руководстве пользователя Amazon VPC.

Вопрос: Почему следует использовать VPCE для DynamoDB?

Раньше основным способом доступа к DynamoDB из облака VPC было использование выхода в Интернет, что могло потребовать сложных конфигураций с использованием брандмауэров и VPN. Конечные точки VPC для DynamoDB повышают конфиденциальность и безопасность путем предоставления частного доступа к DynamoDB из VPC без необходимости использования интернет-шлюза или шлюза NAT. Это особенно важно для клиентов, имеющих дело с конфиденциальными рабочими нагрузками, которые должны обеспечивать соответствие требованиям, в том числе требованиям аудита. Кроме того, конечные точки VPC для DynamoDB поддерживают политики AWS Identity and Access Management (IAM) для упрощения управления доступом к DynamoDB, поэтому теперь можно легко ограничить доступ к таблицам DynamoDB, разрешив доступ только через конкретную конечную точку VPC.

Вопрос: Как начать работу с VPCE для DynamoDB?

VPCE для DynamoDB можно создать с помощью Консоли управления AWS, SDK или интерфейса командной строки (CLI) AWS. Требуется указать VPC, существующие таблицы маршрутизации в VPC и описать политику IAM для подключения к конечной точке. Маршрут автоматически добавляется в каждую из таблиц маршрутизации указанного VPC.

Вопрос: Гарантирует ли использование VPCE для DynamoDB, что трафик не будет направляться за пределы сети Amazon?

Да, при использовании VPCE для DynamoDB пакеты данных, пересылаемых между DynamoDB и VPC, останутся в пределах сети Amazon.

Вопрос: Можно ли с помощью VPCE для DynamoDB подключиться к таблице DynamoDB в регионе, отличном от региона, в котором создано облако VPC?

Нет, конечные точки VPC могут быть созданы только для таблиц DynamoDB, размещенных в том же регионе, что и само облако VPC.

Вопрос: Ограничивает ли VPCE для DynamoDB пропускную способность обмена данными с DynamoDB?

Нет, пропускная способность обмена данными с DynamoDB будет такой же, как ранее, при использовании в VPC инстанса с публичным IP-адресом.

Вопрос: Какова стоимость использования VPCE для DynamoDB?

За использование VPCE для DynamoDB дополнительная плата не взимается.

Вопрос: Можно ли получить доступ к потокам DynamoDB Streams с помощью VPCE для DynamoDB?

В настоящее время получить доступ к потокам DynamoDB Streams, используя VPCE для DynamoDB, нельзя.

Вопрос: В данный момент я использую для отправки запросов в DynamoDB интернет-шлюз и шлюз NAT. Придется ли менять код приложения, чтобы использовать VPCE?

Код приложения менять не потребуется. Просто создайте конечную точку VPC, обновите таблицу маршрутизации, чтобы направить трафик DynamoDB на VPCE для DynamoDB, и обращайтесь к DynamoDB напрямую. Вы можете использовать для доступа к DynamoDB тот же код и те же имена DNS.

Вопрос: Можно ли использовать одну и ту же VPCE для DynamoDB и другого сервиса AWS?

Нет, каждая VPCE поддерживает только один сервис. Но можно создать одну VPCE для DynamoDB, а другую – для другого сервиса AWS и указать обе VPCE в таблице маршрутизации. 

Вопрос: Можно ли иметь несколько конечных точек VPC в одном облаке VPC?

Да, в одном облаке VPC можно иметь несколько конечных точек VPC. Например, у вас может быть одна VPCE для S3 и одна VPCE для DynamoDB.

Вопрос: Можно ли иметь несколько VPCE для DynamoDB в одном облаке VPC?

Да, вы можете иметь несколько VPCE для DynamoDB в одном облаке VPC. Разные VPCE могут иметь разные политики для VPCE. Например, одна VPCE может быть доступна только для операций чтения, а другая может быть доступна для операций чтения и записи. При этом одна таблица маршрутизации в VPC может быть связана только с одной VPCE для DynamoDB, так как эта таблица маршрутизации направляет весь трафик в DynamoDB через указанную VPCE.

Вопрос: Каковы различия между VPCE для S3 и VPCE для DynamoDB?

Основное различие заключается в том, что эти две VPCE поддерживают разные сервисы – S3 и DynamoDB.

Вопрос: Какой IP-адрес будет указан в журналах AWS CloudTrail для трафика, поступающего от VPCE в DynamoDB?

Журналы AWS CloudTrail для DynamoDB будут содержать частный IP-адрес инстанса EC2 в облаке VPC и идентификатор VPCE (например, sourceIpAddress=10.89.76.54, VpcEndpointId=vpce-12345678).

Вопрос: Как можно управлять VPCE, используя интерфейс командной строки (CLI) AWS?

Для управления VPCE можно использовать следующие команды интерфейса командной строки: create-vpc-endpoint, modify-vpc-endpoint, describe-vpc-endpoints, delete-vpc-endpoint и descrive-vpc-endpoint-services. При этом нужно указывать точное имя сервиса DynamoDB для вашего VPC и региона DynamoDB, например: com.amazon.us.east-1.DynamoDB. Дополнительные сведения можно найти здесь.

Вопрос: Для использования VPCE для DynamoDB обязательно знать публичные IP-адреса DynamoDB и уметь управлять ими?

Нет, клиентам не требуется знать публичные диапазоны IP-адресов для DynamoDB или уметь управлять ими. AWS предоставляет список префиксов для использования в таблицах маршрутизации и группах безопасности. AWS поддерживает диапазоны адресов, указанные в списке. Имя списка префиксов: com.amazonaws. .DynamoDB. Например: com.amazonaws.us-east-1.DynamoDB.

Вопрос: Можно ли использовать политики IAM с VPCE для DynamoDB?

Да. Вы можете подключить политику IAM к своей VPCE, и эта политика будет применяться ко всему трафику, проходящему через конечную точку. Например, VPCE, использующая эту политику, позволяет совершать только вызовы API describe*:
{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:describe*",
            "Effect": "Allow",
            "Resource": "arn:aws:dynamodb:region:account-id:table/table-name",
            "Principal": "*"
        }
    ]
}

Вопрос: Можно ли ограничить доступ к моей таблице DynamoDB через конечную точку VPC?

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

Это можно сделать, указав в политике IAM таблицу DynamoDB в качестве элемента Resource и aws:sourceVpce в качестве ключа элемента Condition. Подробнее об этом см. в Руководстве пользователя IAM.

Например, следующая политика IAM ограничивает доступ к таблицам DynamoDB, если sourceVpce не совпадает со значением vpce-111bbb22

{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:*",
            "Effect":"Deny",
            "Resource": "arn:aws:dynamodb:region:account-id:*",
            "Condition": { "StringNotEquals" : { "aws:sourceVpce": "vpce-111bbb22" } }
        }
    ]
}

Вопрос: Поддерживает ли VPCE для DynamoDB условия политик IAM для точного контроля доступа (FGAC)?

Да. VPCE для DynamoDB поддерживает все ключи доступа FGAC. Вы можете использовать условия политик IAM для FGAC для контроля доступа к отдельным элементам и атрибутам данных. Дополнительные сведения о FGAC можно найти здесь.

Вопрос: Можно ли использовать AWS Policy Generator для создания политик конечных точек VPC для DynamoDB?

Да, AWS Policy Generator можно использовать для создания политик конечных точек VPC.

Вопрос: Поддерживает ли DynamoDB политики на основе ресурсов, подобные тем, что используются для корзин S3?

Нет, DynamoDB не поддерживает политики на основе ресурсов, относящиеся к отдельным таблицам, элементам и т. д.