Как смоделировать данные для работы с DynamoDB на базе NoSQL Amazon Web Services.

Почему NoSQL?

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

Почему DynamoDB?

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

Понимание основ

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

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

Ключ раздела

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

Горячие разделы

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

Например, предположим, что ваша таблица разделена на 3 раздела и что вы подготовили для своей таблицы 3 RCU (единицы чтения). Это означает, что каждый раздел будет иметь доступ к 1 RCU. Если 1 раздел подвергается атаке гораздо чаще, чем 2 других, вы рискуете быть задушенным, поскольку вы можете использовать весь этот 1 RCU; тем временем вы все еще платите за 3 RCU.

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

Ключ сортировки

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

Пример моделирования данных

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

Очень распространенный подход к моделированию данных в NoSQL - думать в терминах иерархии. Итак, что находится на вершине нашей иерархии? Что ж, подумайте об этом так: без турнира у нас не было бы команд, игроков или матчей. Турнир предоставляет контекст, который объединяет все остальные предметы. Итак, для каждого турнира мы хотим сгруппировать все элементы рядом друг с другом, чтобы мы могли эффективно получить все данные турнира в одном запросе.

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

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

{
  "TableName": "tournaments",
  "KeyConditionExpression": "partitionKey = :tournamentId",
  "ExpressionAttributeValues": {
    ":tournamentId": "983d39a3-bdd6-4b61-88d5-58595d555b81"
  }
}

Что, если вам нужны команды только для данного идентификатора турнира?

Здесь пригодится префикс team-. Поскольку мы снабдили все ключи сортировки элементов команды префиксом team-, мы можем выполнить специальную функцию в нашем KeyConditionExpression - begins_with. Этот вызов запроса получит все команды для данного идентификатора турнира (ключа раздела).

{
  "TableName": "tournaments",
  "KeyConditionExpression": "partitionKey = :tournamentId and begins_with(sortKey, :teamPrefix)",
  "ExpressionAttributeValues": {
    ":teamPrefix": "team-",
    ":tournamentId": "983d39a3-bdd6-4b61-88d5-58595d555b81"
  }
}

Что, если вам нужны только основные детали?

Мы можем просто выполнить вызов DynamoDB get item, поскольку мы знаем и ключ раздела, и ключ сортировки.

{
  "TableName": "tournaments",
  "Key": {
    "partitionKey": "983d39a3-bdd6-4b61-88d5-58595d555b81",
    "sortKey": "tournament-details"
  }
}

Заключение

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

Если вы хотите узнать больше об сервисах AWS



Начало работы с AWS Websockets API
Знакомство с возможностями AWS WebSocket API реального времени на базе AWS Lambda medium.com



Спасибо за чтение и удачи в ваших проектах! Оставьте комментарий или напишите мне, если у вас есть вопросы.