Как спроектировать связи в MongoDB?

Question

[Александр]

Решил БД карточной игры перевести на MongoDB, но в силу работы с реляционными БД не совсем понимаю как правильно (с точки зрения наименьшей нагрузки) это сделать.

Есть множество карт которые могут создавать игроки и добавлять себе в коллекцию, все карты кроме всего прочего объединены в группы (кланы).

Дано:

• Документ cards - где список всех карт с их id
  
• Документ players - где кроме всего прочего список имеющихся у игрока карт
  
• Документ clans - где список карт определённого клана
  

В реляционной БД я бы просто хранил и для players и для clans список id по которым делал выборку из cards.
В документоориентированной БД более правильным путём (насколько я понимаю) было бы хранить в players и clans карту целиком, благодаря чему не пришлось бы делать лишних запросов.

Меня этот вариант устраивает, но получается что если карта обновится в cards, то мне придётся перебрать все документы чтобы привести копии этой карты к актуальному состоянию? Не будет ли это ещё более затратным чем постоянная выборка карт из одного документа по id?

Помогите разобраться, пожалуйста.

Answer 1

[Сергей Протько]

Решил БД карточной игры перевести на MongoDB

Зачем? Если у вас есть хотя бы 10% вероятность того что между записями появятся отношения/связи, то монга вам не подходит.

Монгу стоит использовать исключительно для хранения денормализованных данных. То есть обычно все хранят в реляционной базе и потом делают агрегации данных в денормализованном виде что бы ускорить выборки. В этом случае у нас может быть одна база данных в нормализованном виде (mysq/postgres/etc) и много инстансов монги из которой данные только читаются, но ничего не пишется (кроме как агрегации инициированные изменением данных в реляционной бд.

И то это нужно только если у вас возникают проблемы с реляционной базой (много джойнов например приходится делать в случае сложных выборок). Если у вас один-два джойна то расставить индексы и не париться.

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

Comments

[Александр]

Спасибо, попробую переосмыслить всё с учётом выше сказанного.

[Alexander Litvinenko]

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

[bro-dev]

А что мешает хранить в монге в нормализованом виде? а о джойнах позаботится монгусь, и я предполагаю это всеравно будет быстрее работать чем (mysq/postgres/etc). Если уж будут проблемы с производительностью тогда да делать инстансы монги с 1 выборкой 1 документ.

Answer 2

[Aleks]

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

Comments

[Александр]

Такой вариант тоже рассматривался, спасибо за ответ.

Answer 3

[Пума Тайланд]

ну глупо данные реляционные запихивать в документоориентированную монгу

Comments

[Александр]

Это единственный момент который меня смутил в этом плане и мне интересно как организовать подобные данные в документоориентированном стиле.

[Пума Тайланд]

Александр: хорошо это сделать никак
либо жить с дополнительными запросами, либо менять кучу строк при изменении карты.