Mönstren Extended Reference och Subset

MongoDB:s steg $lookup sammanfogar samlingar vid frågetillfället genom att utföra en hash-join i minnet. För frekventa frågor med hög trafik kan kostnaden för denna sammanfogning dominera svarstiden. Om din endpoint för orderlistor utför en $lookup för att hämta kundnamn och e-postadresser för varje order i varje anrop betalar du kostnaden för sammanfogningen varje gång. Extended Reference-mönstret eliminerar denna kostnad genom att bädda in en riktad delmängd av det refererade dokumentets fält.

Extended Reference-mönstret bäddar in en noggrant utvald delmängd av fälten från ett refererat dokument direkt i det refererande dokumentet. I stället för att bara lagra kundens _id i en order och slå upp kunden varje gång ordern visas, bäddar du in kundens name och email – de fält som behövs för att visa ordern – direkt i orderdokumentet. Den fullständiga kundposten finns fortfarande separat för uppdateringar.

Duplicera bara fält som läses ofta tillsammans med det refererande dokumentet och ändras sällan. En kunds namn och e-postadress är bra kandidater – de behövs för att visa order och ändras sällan. Kundens faktureringsadress eller saldo av lojalitetspoäng är sämre kandidater – de ändras ofta och skulle kräva att alla inbäddade kopior uppdateras varje gång. Målet är att eliminera sammanfogningar i den kritiska läsvägen utan att skapa en omöjlig synkroniseringsbörda.

När en kund ändrar sitt namn, vilket är en ovanlig händelse, måste du uppdatera kundens huvuddokument och alla orderdokument som bäddar in namnet. Detta kallas write fan-out. Använd updateMany() för att sprida ändringen. Den viktiga insikten är att denna sällsynta skrivkostnad är värd att ta om den eliminerar kostnaden för sammanfogningar i tusentals dagliga läsningar.

Subset-mönstret hanterar en annan utmaning: när ett dokument bäddar in en array som växer sig mycket stor över tid hämtar varje läsning hela arrayen – även om programmet bara visar de första N elementen. En produkt med 5 000 recensioner bäddar in alla 5 000 i ett enda dokument, men användargränssnittet visar bara de 10 främsta. Subset-mönstret delar upp arrayen: behåll de senast tillagda eller mest relevanta N elementen i huvud dokumentet och flytta resten till en separat samling.

Håll den inbäddade delmängden uppdaterad genom att använda $push med modifieraren $slice. När du har lagt till en ny recension i arrayen recentReviews med $push använder du $slice: -10 för att begränsa arrayen till de 10 sista elementen. Detta är en enda atomisk operation – MongoDB utför push och slice atomiskt i samma uppdatering.

I det vanligaste fallet – att visa en produktsida med de senaste recensionerna – läser du produktens huvuddokument och använder den inbäddade recentReviews. För ”läs in fler” eller paginering frågar du samlingen reviews med produktens _id. Denna tvånivåmetod ger snabb prestanda i det vanligaste fallet utan att begränsa möjligheten att komma åt alla recensioner när det behövs.

Extended Reference duplicerar fält från ett refererat dokument till det refererande dokumentet för att eliminera sammanfogningar vid läsning. Det hanterar fallet med en-till-många-relationer där ”ena”-sidans fält behövs tillsammans med varje post på ”många”-sidan. Subset-mönstret duplicerar de mest relevanta N elementen i en stor array till huvud dokumentet för att undvika att tusentals element läses in vid varje läsning. Båda mönstren byter ökad komplexitet vid skrivning mot bättre läsprestanda.

Undvik dessa mönster när de duplicerade uppgifterna ändras ofta – kostnaden för write fan-out blir då orimligt hög. Om kunders e-postadresser ändras dagligen är det opraktiskt att sprida ändringarna till miljontals order. Undvik dem också när datakonsistens är avgörande och fördröjd spridning inte kan accepteras – under tiden mellan en namnändring och slutförandet av write fan-out kommer vissa order att visa gamla uppgifter. För krav på strikt konsistens bör du använda referenser och acceptera kostnaden för sammanfogningen.

I en e-handelsplattform läses order mycket oftare än kunder uppdaterar sina profiler. Att bädda in en ögonblicksbild av kundens leveransadress när ordern skapas (Extended Reference) är faktiskt korrekt ur verksamhetens perspektiv – ordern bör behålla adressen som användes vid köpet även om kunden flyttar senare. Detta är ett fall där mönstret följer domänlogiken, inte bara prestandakraven, vilket gör det dubbelt lämpligt.

Innan du tillämpar dessa mönster mäter du baslinjeprestandan med explain('executionStats') för att identifiera var läsfördröjningen faktiskt uppstår. Mät sedan på nytt efter att du har tillämpat ett mönster för att bekräfta förbättringen. Använd db.collection.stats() för att jämföra genomsnittliga dokumentstorlekar och kontrollera att de inbäddade fälten inte gör att dokumenten närmar sig gränsen på 16 MB. Mönster bör motiveras av data, inte antas vara till hjälp i alla situationer.

I den här lektionen lärde du dig att Extended Reference-mönstret bäddar in utvalda fält från ett refererat dokument för att eliminera sammanfogningar i kritiska läsvägar – bäst för fält som läses ofta och ändras sällan, att Subset-mönstret behåller de mest relevanta N elementen i en array i huvud dokumentet och arkiverar resten i en separat samling, och att båda mönstren byter sällsynta write fan-out-operationer mot betydligt snabbare läsningar. Härnäst utforskar vi Polymorphic- och Schema Versioning-mönstren.