6 советов по предотвращению коллапса при разработке для DynamoDB от AWS

В недавней работе над проектами я обнаружил, что все больше и больше работаю с DynamoDB. База данных является очень дешевой как по времени разработки, так и по эксплуатационным затратам, при этом достигается истинная бессерверная цель масштабирования от 0 до бесконечности. Объекты - это просто капли JSON любого типа, которые можно быстро сохранить и получить по идентификатору, который вы задаете сами. Кроме того, интеграция почти со всеми другими сервисами AWS означает, что DynamoDB часто является необходимой частью любой облачной системы.

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

Время жизни (TTL) встроено

При настройке таблицы вы можете определить конкретный атрибут, который будет использоваться для определения TTL для каждой строки. Затем DynamoDB прочитает это значение и определит, следует ли и когда удалить строку БЕСПЛАТНО. Эта операция не требует затрат на чтение или запись. Кроме того, это можно связать с потоками DynamoDB, чтобы инициировать действие, когда это произошло, например, запись быстрой копии в S3 для архивирования. Подробнее здесь.

Используйте ключи секций для отношений "один ко многим"

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

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

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

Воспользуйтесь преимуществами запросов «begin_with» по ключам сортировки

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

Например, если данные о местоположении хранятся в нескольких разных доменах, рассмотрите идентификатор в виде:

{country}-{regoin/state}-{city}-{street}-{name}

Примером такого имени может быть:

USA - MARYLAND - COLLEGE_PARK - UNIVERISTY_DRIVE - STAMP_STUDENT_UNION

Используя параметр запроса «begin_with» в приведенном выше примере, вы можете эффективно получить 5-уровневый ключ раздела для сортировки данных. Запрос «начинается с USA-MARYLAND» даст вам отсортированный список всех элементов в этом домене.

Самостоятельно поддерживать такие свойства, как created_at и modified_at.

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

Кем создан (например, какой сервис или какой автор создал этот объект)
Последнее изменение (когда это было последнее изменение)
Изменено (кто его последний раз касался)
Версия (схема будет меняться со временем)

Если просмотр истории определенного фрагмента данных важен, вы можете рассмотреть возможность создания для него отдельного отношения «один ко многим», например, как показано ниже.

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

Используйте инвертированные индексы для отношений "многие-ко-многим"

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

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

Сначала рассмотрите свои запросы

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

Еще несколько быстрых советов

Чем меньше таблиц, тем лучше, SQL любит десятки взаимосвязанных таблиц. Динамо нет.
Схем нет. Все атрибуты, кроме атрибутов в индексах, DynamoDB не проверяет. Типы данных могут не совпадать. Воспользуйтесь этим.
Dynamo имеет ограничение на размер 400 КБ на строку. Поместите большие объекты или объекты неопределенного размера в S3 и вместо этого сохраните ссылку на них в строке.

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

Я в основном публикую контент о блокчейне, поэтому подписывайтесь на меня, если хотите это увидеть.

Больше контента на plainenglish.io

6 советов по предотвращению коллапса при разработке для DynamoDB от AWS