När du ska bädda in eller referera till data

  • 2 minuter

I föregående lektion inbäddade vi kundadress- och lösenordsdata i ett nytt kunddokument. Den åtgärden minskar antalet begäranden, vilket förbättrar prestandan och minskar kostnaderna. Du kan dock inte alltid bädda in data. Det finns regler för när du ska bädda in data i ett dokument i stället för att referera till dem på en annan rad.

När ska du bädda in data?

Bädda in data i ett dokument när följande villkor gäller för dina data:

  • Läsa eller uppdatera tillsammans: Data som läss eller uppdateras tillsammans modelleras nästan alltid som ett enda dokument. Detta minskar antalet begäranden som är vårt mål att vara effektiva. I vårt scenario läs- eller skrivs alla kundentiteter tillsammans.
  • 1:1-relation: Kunden och CustomerPassword har till exempel en 1:1-relation.
  • 1:Få relationer: I en NoSQL-databas är det nödvändigt att särskilja 1:Många relationer som avgränsade eller obundna. Kunden och CustomerAddress har en begränsad 1:Många-relation eftersom kunder i ett e-handelsprogram normalt bara har en handfull adresser att skicka till. När relationen är begränsad är detta en 1:Few-relation.

När ska du referera till data?

Referera till data som separata dokument när följande villkor gäller för dina data:

  • Läs eller uppdateras oberoende av varandra: Detta gäller särskilt när du kombinerar entiteter som skulle resultera i stora dokument. Uppdateringar i Azure Cosmos DB kräver att hela objektet ersätts. Om ett dokument har några egenskaper som uppdateras ofta tillsammans med ett stort antal mestadels statiska egenskaper är det mycket mer effektivt att dela upp dokumentet i två. Ett dokument innehåller sedan den mindre uppsättningen egenskaper som uppdateras ofta. Det andra dokumentet innehåller de statiska, oförändrade värdena.

  • 1:Många relationer: Detta gäller särskilt om relationen är obundna. Om du har ett dokument som ökar i storlek en okänd eller obegränsad mängd gånger fortsätter kostnaden och svarstiden för dessa uppdateringar att öka. Detta beror på den ökande storleken på uppdateringen som kostar fler RU/s och nyttolaster som går över nätverket, vilket också är ineffektivt.

  • Många:Många-relationer: Vi utforskar ett exempel på den här relationen i en senare enhet med produkttaggar.

    Om du separerar dessa egenskaper minskar dataflödesförbrukningen för mer effektivitet. Det minskar också svarstiden för bättre prestanda.