sql >> Databasteknik >  >> NoSQL >> MongoDB

Dokumentdatabaser:Redundanta data, referenser etc. (MongoDB specifikt)

Det finns i princip två scenarion:fresh och inaktuella .

Färsk data

Det är enkelt att lagra dubbletter av data. Att underhålla dubblettdata är den svåra delen. Så det enklaste du kan göra är att undvika underhåll, genom att helt enkelt inte lagra några dubbletter av data till att börja med. Detta är främst användbart om du behöver nya data . Lagra endast referenserna och fråga efter samlingarna när du behöver hämta information.

I det här scenariot kommer du att ha en del omkostnader på grund av de extra frågorna. Alternativet är att spåra alla platser för dubbletter av data och uppdatera alla instanser vid varje uppdatering. Detta involverar också overhead, särskilt i N-till-M-relationer som den du nämnde. Så hur som helst, du gör ha lite overhead om du behöver nya data. Du kan inte ha det bästa av två världar.

Inaktuella data

Om du har råd att ha inaktuella data blir det mycket enklare. För att undvika frågeoverhead kan du lagra dubbletter av data. För att undvika att behöva underhålla dubblettdata, kommer du inte att lagra dubblettdata. Åtminstone inte aktivt .

I det här scenariot vill du också bara lagra referenserna mellan dokument. Använd sedan ett periodiskt map-reduce-jobb för att generera dubblettdata. Du kan sedan fråga det enda kartförminskningsresultatet, snarare än separata samlingar. På så sätt undviker du sökningen, men du behöver inte heller leta efter dataändringar.

Sammanfattning

Spara endast referenser till andra dokument. Om du har råd med inaktuella data, använd periodiska kartreducerande jobb för att generera dubbletter av data. Undvik att underhålla dubbletter av data; den är komplex och felbenägen.



  1. Redis INCRBY med limits

  2. Selleri skapar en ny anslutning för varje uppgift

  3. mongodb lägg till räknare till varje hämtat dokument

  4. ServiceStack Entities ID-fältnamn