Дизайн схемы MongoDB: песни / пьесы / лайки

Question

Это мой первый проект с использованием базы данных NoSQL, и мне интересно, как структурировать мои данные наиболее эффективным способом.

Я делаю небольшой сервис, в котором хранятся все песни, проигранные радиостанцией. Пользователи могут «любить» песни. Итак, в основном у меня есть следующие данные:

Song: Id, Artist, Title
Play: SongId, Time (when was the song played)
Like: SongId, UserName, Time (when did the user click the like button)

Мне нужно выполнить различные запросы к этим данным. Например: последние сыгранные песни Х +, такие как количество, самые популярные песни за последние дни Х, кому понравилась конкретная песня и т. Д.

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

Я также думал о кешировании некоторых наиболее часто используемых запросов в памяти. Есть ли общие рекомендации, когда вы делаете что-то подобное?

Answer 1

Если запросы усложняются с использованием вложенной структуры, у вас есть несколько вариантов:

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

2. Держите его вложенным, но при этом клиент может вставить дополнительные документы-заглушки, которые создают обратную связь.То есть денормализовать данные.В распределенных хранилищах данных, таких как Mongo, денормализация ваших данных более приемлема, чем в мире реляционных БД.

3. Используйте запросы mapreduce для агрегирования нужных данных.Это может стать дорогостоящим по мере роста данных, так что вам может быть лучше с другим хранилищем данных документов, например CouchDB, который сможет непрерывно запускать ваши картографы при поступлении новых данных. (Я не знаю, есть ли у Mongo такая возможность ещеили нет).

4. (И, пожалуйста, не понижайте меня за это) Используйте базу данных SQL.Ваши данные довольно нормальны, так как характеристики песни, пьесы и т. П. Не изменятся от записи к записи.Таким образом, использование реляционной базы данных даст вам гибкость запросов, к которой вы стремитесь, без ущерба для гибкости данных (поскольку вам это не нужно).СУБД не масштабируются по горизонтали, но это проблема производительности, которую вы можете решить позже, как только добьетесь успеха.

Вот как я это вижу - удачи!

Answer 2

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

Я хотел бы денормализовать помещение информации о песне в документ Play и в документ Like, чтобы вы могли отображать плейлист и лайки для любого пользователя без необходимости каких-либо объединений.'назад к коллекции песен.

Песня: Id, Исполнитель, Название
Воспроизведение: SongId, Время (когда была воспроизведена песня), Исполнитель, Название
Как:SongId, UserName, Time (когда пользователь нажал кнопку «Мне нравится»), Artist, Title, UserId