Является ли MongoDB неподходящим инструментом для решения этой проблемы «многие ко многим»?

Question

В настоящее время я разрабатываю систему магазинов с этими сущностями:

• Аккаунт (Миллионы), имя пользователя, адрес электронной почты, пароль ...
• Продукт (Миллионы), название, описание, рейтинг ...

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

Текущая концепция: продукт имеет массив лицензированных учетных записей, поэтому я могу использовать find(licensed_accounts: ObjectId("4d731fe3cedc351fa7000002")).

Я ожидаю много аккаунтов. Для популярных продуктов этот массив может содержать миллионы ObjectIds (12 байтов * 1 000 000 = 12 МБ). Один миллион уже приблизит документ к его текущему пределу размера в 16 МБ.

Есть ли лучший способ справиться с этим? Или MongoDB - неподходящий инструмент для такого количества отношений?

Answer 1

Посмотрите на этот слайд: http://www.10gen.com/presentation/mongosf2011/schemabasics. Существует множество примеров с несколькими альтернативами.

В вашем случае вы должны хранить идентификаторы ваших продуктов в учетной записи:

accounts:
  { _id: ObjectId("..."),
    name: "ACME",
    product_ids: [ ObjectId("..."), ObjectId("...")]}

Один продукт может иметь много учетных записей, но одна учетная запись должна иметь только несколько продуктов? Не так ли?

Чтобы отобразить все товары для учетной записи:

> db.products.find({_id : {$in: account.product_ids});

Answer 2

как насчет концепции типа "таблица соединений"? У вас есть Продукты, Учетные записи и Лицензии. Лицензия имеет идентификатор продукта и идентификатор учетной записи. Таким образом, вы не будете оплачивать стоимость больших документов и все равно сможете выполнить то, что пытаетесь сделать.

Монго против других вещей имеет компромиссы, одна из тех вещей, что многие ко многим действительно отстой в базе данных документов (компромисс один к многим, в значительной степени бесплатный) (или еженедельно, или что-то еще) запрос map-Reduce, чтобы получить данные в то, что облегчает вашу работу (и монго). Сокращение карт невероятно гибкое, и вы можете сказать, чтобы оно сохраняло результаты как коллекцию, оно также хорошо масштабируется в кластере, но производительность одного узла очень низкая (именно поэтому я бы сделал это как ночной)

Answer 3

Сначала вы должны прочитать: Когда использовать MongoDB или другие системы баз данных, ориентированные на документы?

Главной силой MongoDB и nosql является идея sharding .В этом случае неясно, какие значения лучше всего использовать в качестве ключа шарда.

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

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