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

Базы данных NoSQL (нереляционные) направлены на скорость работы и масштабирование, а не на гибкость. Производительность реляционной базы данных может снижаться по мере увеличения масштаба, а горизонтально масштабируемые базы данных, например DynamoDB, обеспечивают стабильную производительность при любом масштабе. Размер таблиц некоторых пользователей DynamoDB превышает 100 ТБ, а скорость чтения и записи данных в этих таблицах не увеличилась с тех пор, как их размер составлял всего 1 ГБ.

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

1. Уделите основное внимание шаблонам доступа
Любой тип моделирования данных начинается со схемы отношения сущностей, которая содержит различные объекты (или сущности) приложения и описывает связи (или отношения) между ними.

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

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

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

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

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

Первичные ключи
Вторичные индексы
Транзакции

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

Наиболее распространенные анти-паттерны (неэффективные ответы на повторяющиеся проблемы), которые пробуют использовать в DynamoDB:

  •  Нормализация: в реляционной базе данных вы нормализуете данные, чтобы устранить их избыточность и уменьшить объем хранилища, а затем используете объединения для комбинирования нескольких разных таблиц. Однако при масштабировании объединения медленно работают и дорого обходятся. DynamoDB не допускает использования объединений, потому что они замедляют работу по мере увеличения размера таблицы.
  • Один тип данных на таблицу: в вашу таблицу DynamoDB часто будут входить разные типы данных. В нашем примере в одной таблице содержатся сущности User, Game и UserGameMapping. В реляционной базе данных такие сущности разносятся на три разных таблицы.
  • Слишком много вторичных индексов: пользователи часто пытаются создать вторичные индексы для каждого дополнительного шаблона доступа. DynamoDB, как и ваши индексы, работает без схем. Гибкость атрибутов позволяет использовать один вторичный индекс для нескольких типов данных в таблице. Это называется перегрузкой индексатора.

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

Время, необходимое для прохождения модуля: 20 минут


  • Шаг. 1. Создание схемы «сущность-связь»

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

    В нашем приложении используются следующие сущности:
    • User
    • Game
    • UserGameMapping

    Сущность User представляет в приложении пользователя. Пользователь может создать несколько сущностей Game, а создатель игры определит, на какой карте и когда начнется игра. Сущность User может создать несколько сущностей Game, поэтому между User и Game установлены отношения «один-ко-многим».

    Кроме того, сущность Game содержит несколько сущностей User, а сущность User может играть в несколько разных сущностей Game. Поэтому между User и Game установлены отношения «многие ко многим». Мы можем выразить эту взаимосвязь через сущность UserGameMapping.

    Схема с данными сущностями и отношениями между ними показана ниже.

    Module2-step1

    (Нажмите, чтобы увеличить изображение.)

    Module2-step1
  • Шаг 2. Анализ шаблонов доступа к профилями пользователей

    & nbsp;Пользователям нашей игры необходимо создавать профили пользователей. В эти профили входят следующие данные: имя пользователя, аватар, игровая статистика и другая информация о каждом пользователе. Игра отображает профиль пользователя, когда пользователь входит в систему. Другие пользователи могут просматривать профиль пользователя, игровую статистику и другие сведения.

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

    Основываясь на этой информации, мы получаем три модели доступа:

    •  Создать профиль пользователя (Запись)
    •  Обновить профиль пользователя (Запись)
    • Получить профиль пользователя (Чтение)
  • Шаг 3. Анализ шаблонов доступа перед началом игры

    Жанр нашей игры – Battle Royale. Игроки могут создать матч на определенной карте, а другие игроки могут присоединиться к нему. Когда к матчу присоединяется 50 игроков, начинается игра, к которой не могут присоединиться новые игроки.

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

    Основываясь на этой информации, мы получим семь шаблонов доступа:

    • Создать игру (Запись)
    • Найти открытые игры (Чтение)
    • Найти открытые игры по карте (Чтение)
    • Просмотреть игру (Чтение)
    • Просмотр пользователей в игре (Чтение)
    • Присоединить пользователя к игре (Запись)
    • Начать игру (Запись)
  • Шаг 4. Шаблоны доступа во время и после игры

    В завершение давайте рассмотрим шаблоны доступа во время и после игры.

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

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

    Основываясь на этой информации, мы получаем три модели доступа:

    • Обновить игру для пользователя (Запись)
    • Обновить игру (Запись)
    • Найти все прошлые игры пользователя (Чтение)

    Мы сопоставили все шаблоны доступа в игре. В следующих модулях мы реализуем эти шаблоны доступа с помощью DynamoDB.

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