Лучшая модель данных для массивных отношений в MongoDB

Question

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

Мы должны поддерживать трехсторонние отношения междупользователи, предметы и списки.Пользователь может иметь много элементов и много списков.В списке будет один пользователь и много элементов.Элемент может принадлежать многим пользователям и множеству списков.Последнее особенно важно - элемент может принадлежать к потенциально огромному количеству списков: тысячи, конечно, и, возможно, десятки или сотни тысяч.Возможно, даже миллионы в будущем.Нам необходимо иметь возможность перемещаться по этим отношениям в обоих направлениях: например, получить все элементы списка или все списки, к которым принадлежит элемент.Нам также нужно, чтобы решение было универсальным, чтобы мы могли добавить еще много типов документов и отношений между ними, если нам нужно.

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

Для второй модели требуется новый тип документа, «документ отношений», в котором хранятся идентификаторы каждого из них.партнер и имя отношения.Это хранит больше данных в целом и, таким образом, повлияет на дисковое пространство.Это также выглядит как «неестественный» способ решения этой проблемы в NoSQL.

Производительность, пространство, архитектура, что лучше и почему?

Приветствия, Мэтт

Answer 1

Это зависит от ваших шаблонов доступа.

• Встроенный массив идентификаторов лучше для чтения.При одном быстром чтении вы получаете идентификаторы всех связанных объектов и теперь можете пойти и получить их.Но если у вас высокая частота обновления, у вас будут некоторые проблемы, так как mongodb придется копировать один и тот же (уже большой) объект снова и снова, поскольку он выходит за границы диска.

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

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

  Учитывая ваши цифры («вероятно, даже миллионы в будущем»), я бы пошел с этим решением.Вы всегда можете добавить некоторое оборудование для ускорения запросов.Масштабирование записей традиционно является самой сложной частью, и в этом решении записи выполняются быстро и легко.

Answer 2

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

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

В конечном счете, таким образом вы не будете хранить намного больше данных, потому что, если вам нужно найти отношения с обеих сторон («Какие элементы в каких списках есть у этого пользователя?» И «У каких пользователей есть этот элемент вих списки? ") вам все равно нужно дублировать ссылки.

Это кажется реляционным, но иногда это лучшее решение.