sql >> Database >  >> NoSQL >> MongoDB

MongoDB - onderliggende en bovenliggende structuur

U moet rekening houden met het type query's dat u moet uitvoeren en hoe vaak elk type nodig is. Toen ik aan iets soortgelijks werkte, bedacht ik zes mogelijke acties:

  • Doe iets met de ouder
  • Doe iets met de kinderen
  • Doe iets met de voorouders (ouders van ouders, ouders van ouders van ouders, etc.)
  • Doe iets met de nakomelingen (kinderen van kinderen, kinderen van kinderen van kinderen, enz.)
  • Relaties wijzigen (knopen toevoegen/verplaatsen/verwijderen in de hiërarchie)
  • Wijzig de hoofdgegevens in het huidige knooppunt (bijv. de waarde in het veld "titel" wijzigen)

U wilt inschatten hoe belangrijk elk van deze is voor uw toepassing.

Als het meeste van je werk bestaat uit het werken met opgeslagen gegevens voor een bepaald artikel, inclusief de directe ouder en kinderen, is het eerste idee is het handigst. In MongoDB is het inderdaad heel gewoon om alle informatie die je nodig hebt in hetzelfde document te plaatsen in plaats van er extern naar te verwijzen, zodat je maar één ding hoeft op te halen en alleen met die gegevens hoeft te werken. De laatste vier acties in de lijst zijn echter lastiger.

In dit geval moet u met name door de boom gaan om voorouders en afstammelingen op te halen, door tussenliggende documenten te gaan en een pad te volgen, ook al geeft u misschien alleen om het laatste document in het pad. Dit kan traag zijn voor lange hiërarchieën. Bij het wijzigen van relaties kan het nodig zijn om veel informatie in meerdere documenten te verplaatsen vanwege alle gegevens die in elk document aanwezig zijn. Maar zelfs het wijzigen van een enkel veld zoals "titel" kan vervelend zijn, omdat u er rekening mee moet houden dat dit veld in meerdere verschillende documenten aanwezig is, hetzij als hoofdveld of onder de bovenliggende of onderliggende velden.

Kortom, je eerste idee werkt het beste in meer statische applicaties waar u de gegevens niet veel zult wijzigen nadat u ze voor het eerst hebt gemaakt, maar waar u ze regelmatig moet lezen.

De MongoDB-documentatie heeft vijf aanbevolen benaderingen voor het hanteren van boomachtige (hiërarchische) structuren. Ze hebben allemaal verschillende voor- en nadelen, hoewel ze het allemaal gemakkelijk maken om de belangrijkste gegevens in een artikel bij te werken door dit slechts in één document te hoeven doen.

  • Ouderreferenties :elk knooppunt bevat een verwijzing naar zijn ouder.
  • Voordelen :
    • Snel opzoeken van ouder (opzoeken op "_id" =uw documenttitel, veld "ouder" retourneren)
    • Snel opzoeken van kinderen (opzoeken op "ouder" =uw documenttitel, die alle onderliggende documenten retourneert)
    • Het bijwerken van relaties is slechts een kwestie van het veld "ouder" wijzigen
    • Het wijzigen van de onderliggende gegevens vereist wijzigingen in slechts één document
  • Nadelen :
    • Zoeken op voorouders en afstammelingen is traag en vereist een omweg
  • Kinderreferenties :elk knooppunt bevat een referentiearray naar zijn kinderen
    • Voordelen :
      • Snel ophalen van kinderen (return the children array)
      • Snelle relatie-update (update de kinderarray waar nodig)
    • Nadelen :
      • Om een ​​ouder te vinden, moet u uw _id opzoeken in alle onderliggende arrays van alle documenten totdat u deze vindt (aangezien de ouder het huidige knooppunt als een kind zal bevatten)
      • Voor het zoeken naar voorouders en afstammelingen moet de boom worden doorkruist
  • Array van voorouders :elk knooppunt bevat een verwijzing naar een array van zijn voorouders en zijn ouder
    • Voordelen :
      • Snel ophalen van voorouders (geen traversal vereist om een ​​specifieke te vinden)
      • Eenvoudig op te zoeken ouder en kinderen volgens de "Ouderreferentie"-aanpak
      • Om afstammelingen te vinden, zoek je gewoon de voorouders op, omdat alle afstammelingen dezelfde voorouders moeten bevatten
    • Nadelen :
      • Je moet je zorgen maken over het up-to-date houden van de reeks voorouders en het bovenliggende veld wanneer er een wijziging is in relaties, vaak in meerdere documenten.
  • Gematerialiseerde paden :elk knooppunt bevat een pad naar zichzelf - vereist regex
    • Voordelen :
      • Gemakkelijk om kinderen en nakomelingen te vinden met regex
      • Kan een pad gebruiken om ouder en voorouders op te halen
      • Flexibiliteit, zoals het vinden van knooppunten via gedeeltelijke paden
    • Nadelen :
      • Relatiewijzigingen zijn moeilijk omdat ze mogelijk wijzigingen in paden over meerdere documenten vereisen
  • Geneste sets :Elk knooppunt bevat een veld "links" en "rechts" om subbomen te helpen vinden
    • Voordelen :
      • Eenvoudig op een optimale manier afstammelingen terug te vinden door te zoeken tussen "links" en "rechts"
      • Net als bij de "Ouderreferentie"-aanpak is het gemakkelijk om ouders en kinderen te vinden
    • Nadelen :
      • Moet de structuur doorkruisen om voorouders te vinden
      • Relatiewijzigingen presteren hier het slechtst dan elke andere optie, omdat elk afzonderlijk document in de boomstructuur mogelijk moet worden gewijzigd om ervoor te zorgen dat "links" en "rechts" nog steeds zinvol zijn als er iets verandert in de hiërarchie

De vijf benaderingen worden in meer detail besproken in de MongoDB-documentatie .

Uw tweede idee combineert de "ouderverwijzingen" en "kinderverwijzingen"-benaderingen die hierboven zijn besproken. Deze benadering maakt het gemakkelijk om zowel de onderliggende als de ouder te vinden en maakt het gemakkelijk om relaties en de hoofdgegevens van een artikel bij te werken (hoewel u zowel de bovenliggende als de onderliggende velden moet bijwerken), maar u moet er nog steeds doorheen gaan voorouders en afstammelingen te vinden.

Als u geïnteresseerd bent in het vinden van voorouders en afstammelingen (en u hier meer belang aan hecht dan dat u eenvoudig relaties kunt bijwerken), kunt u overwegen een voorouderarray aan uw tweede idee toe te voegen, zodat u ook gemakkelijk naar voorouders en afstammelingen kunt zoeken. Natuurlijk wordt het bijwerken van relaties een echte pijn als je dit echter doet.

Conclusie:

  • Uiteindelijk hangt het er allemaal van af welke acties het meest nodig zijn. Aangezien u werkt met artikelen waarvan de onderliggende gegevens (zoals de titel) vaak kunnen veranderen, wilt u misschien het eerste idee vermijden, omdat u niet alleen het hoofddocument voor dat artikel moet bijwerken, maar ook alle onderliggende documenten, evenals de ouder.

  • Uw tweede idee maakt het gemakkelijk om de directe ouder en kinderen terug te vinden. Het bijwerken van relaties is ook niet zo moeilijk (het is zeker beter dan sommige van de andere beschikbare opties).

  • Als u het echt gemakkelijk wilt maken om voorouders en afstammelingen te vinden ten koste van het zo gemakkelijk bijwerken van relaties, kiest u ervoor om een ​​reeks voorouderverwijzingen op te nemen.

  • Probeer in het algemeen het aantal vereiste traversals te minimaliseren, omdat ze een soort iteratie of recursie vereisen om bij de gewenste gegevens te komen. Als u waarde hecht aan de mogelijkheid om relaties bij te werken, moet u ook een optie kiezen die minder knooppunten in de boom verandert (ouderverwijzingen, onderliggende verwijzingen en uw tweede idee kan dit doen).



  1. Time-out voor Jedis configureren

  2. Hoe in Jongo meerdere documenten van Mongodb te vinden door middel van een lijst met ID's

  3. Een mangoest-databasemodule exporteren

  4. Fout:Kan client niet initialiseren | mongo-connect express-sessie