Как лучше структуризировать данные mongodb?

Question

[mozart1337]

Кратко суть такая: есть пользователь, у него есть друзья и у друзей свои уникальные свойства по отношению к этому пользователю. Размышляю над структурой данных:
1.

{
	name: 'userName',
	friends: [{
		name: 'friendName1',
		uniqueParams: {
			param1: 'value1'
		}
	}, {
		name: 'friendName2',
		uniqueParams: {
			param1: 'value2'
		}
	}]
}

2.

// 1 коллекция
{
	name: 'userName'
}
// 2 коллекция
{
	name: 'friendName1',
	iFriendForUsers: [{
		name: 'userName',
		uniqueParams: {
			param1: 'value1'
		}
	}]
}

То есть в первом случае все будет в одной коллекции и к тому же в одном документе, в другом случае все по разным коллекциям. Нюанс в том, что friend-ов в первом случае будет в среднем 20-30 тысяч, ну и самих user-ов может быть несколько десятков тысяч.
Во втором случае мы во второй коллекции будем иметь по нескольку миллионов документов, которые уже ссылаются на 1 коллекцию. Неких JOIN такой.
Все эти friend-ы должны постоянно изменяться и обновляться (свои уникальные параметры по отношению только к одному user-y)

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

Answer 1

[lega]

Первый вариант ещё делится на 2: хранение свойств в документе пользователя, и хранить свойства в документе друга.

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

Если вам нужно за раз только одно/два свойства, то скорее 2-й будет лучше.

Также нужно учесть лимит в 16мб на документ.

Answer 2

[Станислав Макаров]

Надо сказать, что вам удалось меня поразить.

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

Но вы сделали невозможное. Вы смоделировали классическую задачу "друзья друзей" в максимально неподходящей для этого модели данных - документной. И теперь вы хотите

Неких JOIN такой.

Итак, еще раз, знакомьтесь: графовая БД. Из конкретных представителей рекомендую посмотреть Neo4j и OrientDB.
Важно, что обе СУБД имеют средства для хранения "отношений со свойствами", т.е. ваших

у друзей свои уникальные свойства по отношению к этому пользователю

Вот пример из доков по Neo4j:

Relationships between nodes are a key part of a graph database. They allow for finding related data. Just like nodes, relationships can have properties.

Картинка.
Аналогичная концепция в OrientDB:

In addition to mandatory properties, each vertex or edge can also hold a set of custom properties. These properties can be defined by users, which can make vertices and edges appear similar to documents.

Да, кстати о документах. OrientDB позиционируется как документно-графовая, так что вполне возможно вам с ней будет проще. Вот их самосравнение с Монгой: orientdb.com/orientdb-vs-mongodb

P.S. Да, маркетинг - великая сила. Это я про MongoDB.

Или вообще для реализации данного желательно делать это все не на mongo?

Хорошо, что вы осмеливаетесь задавать себе такой вопрос. Это правильно.