Strategier til denormalisering

I traditionelle relationsdatabaser normaliserer vi data for at undgå redundans. Men NoSQL-databaser som Firebase Realtime Database har ofte fordel af det modsatte: denormalisering.

Denormalisering indebærer, at man med vilje tilføjer redundante data eller grupperer data for at optimere læseydeevnen. Det er en vigtig strategi til at opnå høj hastighed i NoSQL.

Firebase Realtime Database er fremragende til opdateringer i realtid og hurtig læsning. Komplekse forespørgsler på tværs af flere datastier kan dog være langsomme og dyre.

• Flade strukturer: Firebase fungerer bedst med flade datastrukturer.
• Færre læsninger: Denormalisering kan reducere antallet af læsninger, der kræves til almindelige forespørgsler.
• Begrænsninger i forespørgsler: NoSQL-databaser har mere begrænsede forespørgselsmuligheder end SQL.

Der er flere måder at denormalisere dine data på. To almindelige mønstre er:

• Duplikering: Det samme stykke data gemmes flere steder.
• Aggregering: Forudberegnede opsummeringer eller optællinger gemmes.
• Fan-out: Data skrives til flere stier samtidigt (bruges ofte sammen med duplikering).

Vi fokuserer detaljeret på de to første.

Forestil dig en social app, hvor brugere skriver opslag. Hvert opslag skal vise forfatterens navn.

I stedet for at hente brugerens profil, hver gang du viser et opslag, kan du duplikere brugerens navn direkte i opslagets objekt, når det oprettes. Det gør visningen af opslag meget hurtigere.

// Original structure (normalized)
posts: {
  postId1: {
    text: "My first post!",
    authorId: "userId123"
  }
},
users: {
  userId123: {
    name: "Alice"
  }
}

// Denormalized structure
posts: {
  postId1: {
    text: "My first post!",
    authorId: "userId123",
    authorName: "Alice" // Duplicated!
  }
}

Sådan kan du skrive data, der indeholder duplikerede brugeroplysninger. Når en bruger skriver et opslag, tilføjer vi brugerens navn direkte til opslagets objekt.

En anden almindelig denormaliseringsteknik er at gemme aggregerede data, f.eks. optællinger eller summer, direkte på et overordnet objekt.

Hvis du f.eks. har et blogopslag og hurtigt vil vise antallet af kommentarer, kan du gemme en egenskab med navnet commentCount på selve opslaget. Så undgår du at hente alle kommentarer blot for at tælle dem.

// Without aggregation
posts: {
  postId1: {
    title: "My Blog Post"
  }
},
comments: {
  commentId1: { postId: "postId1", text: "..." },
  commentId2: { postId: "postId1", text: "..." }
}

// With aggregation
posts: {
  postId1: {
    title: "My Blog Post",
    commentCount: 2 // Aggregated!
  }
}

Når der tilføjes en ny kommentar, kan vi øge en tæller på det overordnede opslag. På den måde er optællingen altid opdateret og let tilgængelig.

Denormalisering er et effektivt værktøj, men det er ikke altid løsningen. Overvej det, når:

• Læseydeevne er afgørende: Du har brug for at vise data hurtigt og ofte.
• Forespørgsler er komplekse: Din app skal ofte hente relaterede data, der findes i forskellige stier.
• Data ændres sjældent: De duplikerede eller aggregerede data ændres ikke ofte.

Afvej altid fordelene mod kompleksiteten.

Den største udfordring ved denormalisering er at bevare datakonsistensen. Hvis du duplikerer en brugers navn, og brugeren ændrer det, skal du opdatere det alle steder, hvor det er duplikeret.

• Øget kompleksitet ved skrivning: Der kræves flere skrivninger for at holde data synkroniserede.
• Mulighed for inkonsistens: Hvis en opdatering mislykkes, kan data komme ud af synkronisering.
• Cloud Functions: Firebase Cloud Functions bruges ofte til automatisk at sikre konsistens for denormaliserede data.

Vi har lært, at denormalisering er en vigtig teknik til at optimere læseydeevnen i Firebase Realtime Database ved med vilje at tilføje redundante eller aggregerede data.

• Det hjælper med at skabe fladere datastrukturer.
• Almindelige mønstre omfatter duplikering og aggregering.
• Det gør læsninger hurtigere, men øger kompleksiteten ved skrivninger og kræver omhyggelig håndtering af konsistens, ofte ved hjælp af Cloud Functions.

Overvej dine hyppigste læsemønstre, når du beslutter, hvor og hvordan du skal denormalisere.