Wanneer moet u gegevens insluiten of ernaar verwijzen

  • 2 minuten

In de vorige les hebben we het klantadres en wachtwoord ingesloten in een nieuw klantdocument. Deze actie vermindert het aantal aanvragen, waardoor de prestaties worden verbeterd en de kosten worden verlaagd. U kunt echter niet altijd gegevens insluiten. Er zijn regels voor wanneer u gegevens insluit in een document in plaats van ernaar te verwijzen in een andere rij.

Wanneer moet u gegevens insluiten?

Gegevens insluiten in een document wanneer de volgende criteria van toepassing zijn op uw gegevens:

  • Samen lezen of bijwerken: gegevens die samen worden gelezen of bijgewerkt, worden bijna altijd gemodelleerd als één document. Dit vermindert het aantal aanvragen dat ons doel is om efficiënt te zijn. In ons scenario worden alle klantentiteiten samen gelezen of geschreven.
  • 1:1-relatie: Klant en CustomerPassword hebben bijvoorbeeld een 1:1-relatie.
  • 1:Weinig relatie: In een NoSQL-database is het nodig om 1:Veel relaties te onderscheiden als gebonden of niet-gebonden. Klant en CustomerAddress hebben een gebonden 1:Veel-relatie omdat klanten in een e-commercetoepassing normaal gesproken slechts een aantal adressen hebben om naar te verzenden. Wanneer de relatie is gebonden, is dit een 1:Weinig-relatie.

Wanneer moet u verwijzen naar gegevens?

Referentiegegevens als afzonderlijke documenten wanneer de volgende criteria van toepassing zijn op uw gegevens:

  • Onafhankelijk lezen of bijgewerkt: dit geldt met name wanneer entiteiten worden gecombineerd die leiden tot grote documenten. Voor updates in Azure Cosmos DB moet het hele item worden vervangen. Als een document een aantal eigenschappen heeft die vaak worden bijgewerkt naast een groot aantal voornamelijk statische eigenschappen, is het veel efficiënter om het document in tweeën te splitsen. Eén document bevat vervolgens de kleinere set eigenschappen die regelmatig worden bijgewerkt. Het andere document bevat de statische, onveranderlijke waarden.

  • 1:Veel-relatie: dit is vooral waar als de relatie niet afhankelijk is. Als u een document hebt dat een onbekend of onbeperkt aantal keren groter wordt, blijven de kosten en latentie voor deze updates toenemen. Dit komt door de toenemende grootte van de update die meer RU/s kost en de nettoladingen die via het netwerk zelf gaan, zijn ook inefficiënt.

  • Veel:Veel-relaties: We verkennen een voorbeeld van deze relatie in een latere eenheid met producttags.

    Het scheiden van deze eigenschappen vermindert het doorvoerverbruik voor meer efficiëntie. Het vermindert ook de latentie voor betere prestaties.