Моделирование данных – это процесс определения того, как именно приложение хранит данные в определенной базе данных. Процедура моделирования данных при работе с базой данных 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 (Пользователь), Friend (Друг), Photo (Фотография) и Reaction (Реакция) в одной таблице. В реляционной базе данных они моделируются как четыре отдельных таблицы.
  • Слишком много вторичных индексов: пользователи часто пытаются создать вторичный индекс для каждого дополнительного шаблона доступа. DynamoDB, как и ваши индексы, работает без схем. Гибкость атрибутов позволяет использовать один вторичный индекс для множества типов данных в таблице. Это называется совмещением индекса.

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

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


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

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

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

    • User
    • Photo
    • Reaction
    • Friendship

    Сущность User может иметь много сущностей Photos, а сущность Photo может иметь много сущностей Reactions. Наконец, сущность Friendship представляет отношение между сущностями User по модели «многие ко многим», поскольку сущность User может быть подписана на множество сущностей User и иметь в подписчиках множество других сущностей User.

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

    Module_2_Step_1

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

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

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

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

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

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

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

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

    Теперь рассмотрим шаблоны доступа к фотографиям.

    Наше мобильное приложение позволяет пользователям загружать фотографии и делиться ими с друзьями, как вInstagram или Snapchat. После загрузки фотографии пользователем вам необходимо будет сохранить такую информацию, как время загрузки и расположение файла в сети доставки контента (CDN).

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

    В этом разделе мы имеем следующие шаблоны доступа:

    • Загрузка фотографии пользователя (Запись)
    • Просмотр последних фотографий пользователя (Чтение)
    • Реакция на фотографию (Запись)
    • Просмотр фотографии и реакций (Чтение)
       
  • Шаг 4. Шаблоны доступа во время и после игры

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

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

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

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

    • Подписка на пользователя (Запись)
    • Просмотр подписчиков пользователя (Чтение)
    • Просмотр подписок пользователя (Чтение)

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

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