Как смоделировать очень-очень-очень много отношений в MongoDB

Question

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

Мое понимание состоит в том, что если вы собираетесь всегда рассматривать одно сущность в контексте другого объекта, это вложение - путь.

Однако данные (геномные) имеет так много объектов каждого типа, что даже просто хранить поле _id во встроенном документе ставит меня предельный размер 16 Мб:

Genome 
{ 
    ... 
    has_reactions:[id1, id2, ... idn] // Where n is really large 
} 

Я также попытался моделирования по-другому, но ударил же ограничение:

Reaction 
{ 
    ... 
    in_genomes:[id1, id2, ... idn] // Still really large 
} 

MongoDB documentation дает большие примеры для один-к-одному и один-ко-многим отношениям, но не имеет много говорить о многочастичных слишком много.

В традиционном SQL я бы моделировал это с помощью Genome, Reaction и GenomeReaction набора таблиц. Это единственный способ пойти сюда?

Edit:

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

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

Мы не выбрали Mongo в качестве решения, мы просто оцениваем его как возможное решение. Это выглядело привлекательно, потому что оно объявлено как способное обрабатывать «наборы данных huMONGOus», поэтому я был немного удивлен этим ограничением.

Во всех наших других случаях использования Mongo хорошо работает. Именно эти отношения я не могу передать из mysql в mongo без использования наборов коллекций Genome, Reaction и GenomeReaction. Я легко могу это сделать, но я надеялся, что с ним будет работать более mongoy.

Возможно, монго не справляется со многими отношениями ко многим, что объясняет его заметное отсутствие из списка data model scenarios в его документах.

Answer 1

После того, как вы спросили об этом в официальном списке рассылки mongo-db, я обнаружил, что рекомендуемый способ обработки сценариев, подобных этому, - либо использовать три сопоставления коллекции, упомянутые мной в моем первоначальном сообщении, либо использовать «hybrid schema design», где одна из коллекций хранится в ведрах.

Таким образом, вы бы что-то вроде:

// genomes collection 
{ 
    _id: 1, 
    genome_thingee: 'blah blah' 
    ... 
} 

// reaction_buckets collection 
{ 
    _id: ObjectId(...), 
    genome_id: 1, 
    count: 100, 
    reactions: [ 
    { reaction-key1: value, reaction-key 2: value}, 
    { reaction-key1: value, reaction-key 2: value}, 
    { reaction-key1: value, reaction-key 2: value}, 
    { reaction-key1: value, reaction-key 2: value}, 
    { reaction-key1: value, reaction-key 2: value}, 
    ...] 
} 

Как вы можете себе представить, есть все виды последствий для такого рода модели, что ваше приложение должно принимать во внимание при adding or querying data.

В конце концов, этот подход мне не очень нравится (и поэтому я решил посмотреть на Neo4j по предложению Филиппа), я думал, что опубликую решение на тот случай, если кто-то еще захочет решить подобную проблему и не против гибридного/ковшового подхода.