Mange til mange forhold til MongoDB i stor skala

Dette er et godt spørgsmål, som illustrerer problemerne med overebedding, og hvordan man håndterer det.

Eksempel:Post likes

Lad os holde os til eksemplet med brugere, der kan lide indlæg, hvilket er et simpelt eksempel. De andre relationer skulle håndteres i overensstemmelse hermed.

Du har fuldstændig ret i, at med at gemme likes inde i opslaget ville det før eller siden føre til det problem, at meget populære opslag ville nå størrelsesgrænsen.

Så du faldt korrekt tilbage for at oprette en post_likes kollektion. Hvorfor kalder jeg dette korrekt? Da det passer til dine use cases og funktionelle og ikke-funktionelle krav!

• Den skalerer uendeligt (nå, der er en teoretisk grænse, men den er enorm)
• Det er nemt at vedligeholde (opret et unikt indeks over post_id og liked_user_id ) og brug (både brugeren og indlægget er kendt, så tilføjelse af et like er en simpel indsættelse eller mere sandsynligt en upsert)
• Du kan nemt finde ud af, hvilke brugere kan lide hvilket indlæg, og hvilket indlæg hvilke brugere kan lide

Jeg vil dog udvide samlingen en smule for at forhindre unødvendige forespørgsler til visse brugstilfælde, som er hyppige.

Lad os nu antage, at indlægstitler og brugernavne ikke kan ændres. I så fald kunne følgende datamodel give mere mening

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

Lad os nu antage, at du vil vise brugernavnet på alle brugere, der kunne lide et opslag. Med modellen ovenfor ville det være en enkelt, ret hurtig forespørgsel:

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

Med kun id'erne gemt, ville denne ret sædvanlige opgave kræve mindst to forespørgsler og - givet den begrænsning, at der kan være et uendeligt antal likes for et indlæg - potentielt enormt hukommelsesforbrug (du skal gemme bruger-id'erne i RAM).

Indrømmet, dette fører til en vis redundans, men selv når millioner af mennesker kan lide et indlæg, taler vi kun om nogle få megabyte relativt billig (og let skalerbar) diskplads, mens vi opnår meget ydeevne med hensyn til brugeroplevelse.

Nu kommer sagen:Selvom brugernavne og indlægstitler kan ændres, behøvede du kun at lave en multiopdatering:

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

Du handler med, at det tager et stykke tid at gøre nogle ret sjældne ting som at ændre et brugernavn eller et indlæg for ekstrem hastighed for brugstilfælde, der sker ekstremt ofte.

Bundlinje

Husk, at MongoDB er en dokumentorienteret database. Så dokumentér de begivenheder, du er interesseret i, med de værdier, du har brug for til fremtidige forespørgsler, og modeller dine data derefter.