Много към много връзки с MongoDB в голям мащаб

Това е добър въпрос, който илюстрира проблемите с прекомерното легло и как да се справите с него.

Пример:Публикувайте харесвания

Нека се придържаме към примера с потребители, харесващи публикации, който е прост пример. Другите отношения ще трябва да се третират съответно.

Вие сте напълно прав, че съхраняването на харесвания в публикацията рано или късно ще доведе до проблема, че много популярни публикации ще достигнат ограничението за размер.

Така че правилно се отказахте да създадете post_likes колекция. Защо наричам това правилно? Тъй като отговаря на вашите случаи на употреба и функционални и нефункционални изисквания!

• Мащабира се неограничено (е, има теоретично ограничение, но е огромно)
• Поддържа се лесно (създайте уникален индекс върху post_id и liked_user_id ) и използване (както потребителят, така и публикацията са известни, така че добавянето на харесване е просто вмъкване или по-вероятно връщане)
• Можете лесно да разберете кои потребители коя публикация харесват и коя публикация кои потребители харесват

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

Нека засега приемем, че заглавията на публикациите и потребителските имена не могат да се променят. В такъв случай следният модел на данни може да има повече смисъл

{
  _id: new ObjectId(),
  "post_id": someValue,
  "post_title": "Cool thing",
  "liked_user_id": someUserId,
  "user_name": "JoeCool"
}

Сега да приемем, че искате да покажете потребителското име на всички потребители, които са харесали публикация. С модела по-горе това ще бъде една, доста бърза заявка:

db.post_likes.find(
  {"postId":someValue},
  {_id:0,user_name:1}
)

Със съхранени само идентификатори, тази доста обичайна задача ще се нуждае от поне две заявки и - предвид ограничението, че може да има безкраен брой харесвания за публикация - потенциално огромна консумация на памет (ще трябва да съхранявате потребителските идентификатори в RAM).

Разбира се, това води до известна излишност, но дори когато милиони хора харесат публикация, говорим само за няколко мегабайта относително евтино (и лесно за мащабиране) дисково пространство, като същевременно печелим много производителност по отношение на потребителското изживяване.

Сега идва нещото:Дори ако потребителските имена и заглавията на публикациите подлежат на промяна, трябва само да направите многократна актуализация:

db.post_likes.update(
  {"post_id":someId},
  { $set:{ "post_title":newTitle} },
  { multi: true}
)

Разменяте, че отнема известно време, за да направите някои доста редки неща, като промяна на потребителско име или публикация за изключителна скорост за случаи на употреба, които се случват изключително често.

Долен ред

Имайте предвид, че MongoDB е база данни, ориентирана към документи. Затова документирайте събитията, които ви интересуват, със стойностите, от които се нуждаете за бъдещи заявки, и моделирайте данните си по съответния начин.