Какой принцип использовать для хранения данных в MongoDB?

Question

[makerkz]

Пишется веб-сервис (скажем, для каталога книг). Используются node.js + MongoDB. Возник вопрос по хранению данных в базе. Какой подход лучше использовать? Есть два основных типов данных - пользователь, книга. Присутствие дополнительных типов зависит от варианта.

Есть 2 варианта:
1) Не использовать дополнительные типы данных, то есть все данные о произведении хранить в отдельном документе коллекции "Произведения" (то есть отзывы о нём, имя автора, категория и т.д.)
2) Использовать дополнительные типа данных, то есть создавать связанные коллекции с "Произведениями" - "Отзывы", "Категории произведений", "Авторы".

В будущем потребуется хранить и редактировать огромные объёмы информации, и поэтому интересно, что же будет лучше в плане масштабирования системы?

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

Answer 1

[Александр Кит]

Рекомендую почитать "50 Tips and Tricks for MongoDB". Текста не много, а информации полно. Здесь в ответах немного напутали - то, что у вас под 1ым пунктом - это денормализованная коллекция. Плюсы в том, что за один запрос имеете всю информацию по обьекту, ну а минусы соответственно, что сложно применять правки. А 2ой пункт, это уже нормализованная - и тут всё наоборот. Но главное, это грамотно балансировать между ними, а не выбирать одну из сторон. Структура очень зависит не только от структуры данных, но и того - как мы используем эти данные (какие выборки делать будем) и на сколько важна их актуальность. Пару советов из разных сторон:
- если идете по первому пути - то можете хранить также все подсущности в отдельных коллекциях. Изменяя подсущность, изменяете её в своей коллекции, и не бойтесь писать скрипты для нормализации, которые по крону будут актуализировать основную коллекцию.
- а если по второму, то храните не только `_id` подсущностей, но также часть обьекта, которая всегда будет нужна, что бы минимизировать запросы.

Answer 2

[lega]

Зависит от использования, например если отзывы будут выводится на странице книги и больше с ними ничего не будет происходить, то их удобно сделать вложенными, + экономия на запросах, одним запросом будет доставаться книга и отзывы.
А вот авторов лучше (можно) в отдельную коллекцию, т.к. их данные будут изменятся (имя, фотка, описание, теги?), Хотя если эти изменения очень редкие или вовсе нет, то можно сделать вложенными, при этом будет больший расход диска, но экономия на запросах.

Comments

[makerkz]

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

Answer 3

[Андрей]

Тут нужна разумная нормализация. Как писали выше, одна сущность - один документ. Но не забываем при этом, что излишнее дублирование информации (вроде автора) не есть хорошо. Ибо, если у автора что-то изменится, надо будет перелопачивать все документы с этим автором.

Прелесть schemaless именно в отсутствии схемы. То есть вы можете разным сущностям придать разные атрибуты, при этом держать все в одной коллекции и индексировать все эти атрибуты. Если же структура предполагается более регулярной, если схема будет присутствовать - то стоит обратиться к хранилищам со схемой.

Comments

[makerkz]

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

[makerkz]

Если буду использовать монго, то буду использовать mongohq, что скажете? Или же лучше у себя хранить?

[makerkz]

Каким образом лучше хранить историю изменений?

[lega]

> Будут ли еще какие то плюшки кроме динамической схемы?
Масштабирование, разные типы индексов: geo, ttl и др. Очень удобны массивы, попробуйте на sql сделать поиск по нескольких тегам.

[lega]

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

[Андрей]

Вот товарищ выше ответил. Хранить я бы стал у себя, но у меня 50 серверов. Вам надо понимать для себя, что удобнее/лучше.

Answer 4

[lega]

В будущем потребуется хранить и редактировать огромные объёмы информации

На счет объемов, у вас наверняка для книг будут картинки (постеры), дак вот они могут занимать большую часть хранилища (+ большую часть расхода), я работал с одним книжным сайтом - на каждую книгу с отзывами (~4kb) есть несколько картинок (~120kb), т.е. ~97% (от книг) это картинки.

Comments

[makerkz]

Может лучше хранить картинки в файлах? Дабы не захламлять хранилище БД блобами.

[lega]

Я не предлагал место хранения файлов, просто указал акцент, что это не малая (большая) часть при хранении.
Можно в файлах, можно в S3, а вообще удобно хранить в gridFS, сами по шардам будут разъезжаться и т.п., в Я.Диске как раз его вроде и используют.

Answer 5

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

Книги все таки хорошо ложатся в реляционную модель, зачем там монго?

Comments

[makerkz]

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

[lega]

Книги все таки хорошо ложатся в монго, зачем там реляционная модель?

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

А что у них много разных полей?