What is the best way to structure mongodb data?

Question

MongoDB

Briefly, the essence is this: there is a user, he has friends, and friends have their own unique properties in relation to this user. Thinking about the data structure:
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'
    }
  }]
}

That is, in the first case, everything will be in one collection and, moreover, in one document, in the other case, everything will be in different collections. The nuance is that in the first case there will be an average of 20-30 thousand friends, and there can be several tens of thousands of users themselves.
In the second case, in the second collection we will have several million documents that already refer to 1 collection. Some JOIN such.
All these friends must be constantly changed and updated (their unique parameters in relation to only one user-y) The
question is which structure will be more advantageous. Or is it generally desirable to do this all not on mongo to implement this? Thanks in advance for your reply.

Answer 1

The first option is further divided into 2: storing properties in the user's document, and storing properties in the friend's document.
If all (or many) properties need to be obtained every time (often), then the 1st option is better, because will give all the data in a minimum of requests, and it can run hundreds/thousands of times faster than fiddling with a million collection.
There will also be savings on indexes, + better data compression.
If you only need one / two properties at a time, then the 2nd one will most likely be better.
You also need to take into account the limit of 16MB per document.

Answer 2

I must say that you managed to amaze me.
You can talk quite a lot about which connected data and for which queries it is better to use relational and graph databases. At what depth of transitions on relational links will it be enough (and even better than them), and at what depth is it already better than graph.
But you did the impossible. You modeled the classic "friends of friends" task in the most inappropriate data model for this - document. And now you want
So, once again, get acquainted: a graph database . From specific representatives, I recommend looking at Neo4j and OrientDB .
It is important that both DBMSs have facilities for storing "relationships with properties", i.e. your
Here is an example from the Neo4j docs :
Picture .
Similar concept in OrientDB:
Yes, speaking of documents. OrientDB is positioned as a document-graph, so it is quite possible that you will find it easier with it. Here is their self-comparison with Mongo: orientdb.com/orientdb-vs-mongodb
PS Yes, marketing is a great power. This is me about MongoDB.
It's good that you dare to ask yourself this question. It is right.