Моделирование данных игроков с помощью Amazon DynamoDB

Моделирование данных – это процесс определения того, как именно приложение хранит данные в определенной базе данных. Процедура моделирования данных при работе с базой данных 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. В следующих модулях мы составим таблицу с учетом этих шаблонов доступа.