Normalizza o denormalizza nei siti Web con traffico elevato

Question

Quali sono le migliori pratiche per la progettazione e la normalizzazione del database per i siti Web con traffico elevato come stackoverflow?

Si dovrebbe utilizzare un database normalizzato per la conservazione dei registri o una tecnica normalizzata o una combinazione di entrambi?

È ragionevole progettare un database normalizzato come database principale per la conservazione dei registri per ridurre la ridondanza e allo stesso tempo mantenere un'altra forma denormalizzata del database per la ricerca rapida?

o

caso in cui il database principale denormalizzato ma con vista normalizzati a livello di applicazione per le operazioni di database veloci?

o qualche altro approccio?

Answer 1

Denormalizzare il db per ridurre il numero di join necessari per le query intense è uno dei molti modi diversi di ridimensionamento. Dovendo fare un minor numero di join vuol dire che il db è meno pesante e il disco è economico.

Detto questo, per quantità ridicole di traffico può essere difficile ottenere buone prestazioni relazionali in db. Questo è il motivo per cui molti siti più grandi utilizzano negozi di valore chiave (ad esempio memcached) e altri meccanismi di memorizzazione nella cache.

The Art of Capacity Planning è abbastanza buono.

Answer 2

Primo: definire per lei che cosa hight-traffico significa:

• 50,000 Pagina-Viewss al giorno?
• 500.000 Page-Views al giorno?
• 5.000.000 Page-Views al giorno?
• altro?

Quindi calcolare questo valore in basso per visualizzare le pagine picco al minuto e al secondo. Successivamente, pensa ai dati che vuoi interrogare per visualizzazione di pagina. I dati sono nella cache? Quanto sono dinamici i dati, quanto sono grandi i dati?

Analizza le tue esigenze individuali, programma del codice, esegui alcuni test di carico, ottimizza. Nella maggior parte dei casi, prima che sia necessario ridimensionare i server di database, è necessario ridimensionare i server Web.

Il database relazionale può essere, se completamente ottimizzato, incredibilmente veloce, quando si uniscono le tabelle!

Un database relazionale può essere colpito raramente quando come back-end, per compilare una cache o riempire alcune tabelle di dati denormalizzate. Non farei della denomralizzazione l'approccio predefinito.

(Lei ha parlato di ricerca, ad esempio, guardare in Lucene o qualcosa di simile, se avete bisogno di ricerca full-text.)

La migliore risposta best-practice è sicuramente: Dipende ;-)

Answer 3

Per un progetto a cui sto lavorando, siamo andati per la tabella denormalizzata perché ci aspettiamo che le nostre tabelle principali abbiano un elevato rapporto di scritture da leggere (invece di tutti gli utenti che hanno colpito le stesse tabelle, li abbiamo denormalizzati e imposta ciascun "set utente" per usare un particolare frammento).È possibile leggere http://highscalability.com/ per esempi di come i "siti di grandi dimensioni" fanno fronte al volume - Stack Overflow è stato recentemente pubblicato.

Answer 4

Il successo della partecipazione è spesso sovrastimato. I prodotti di database come Oracle sono progettati per unirsi in modo molto efficiente. Spesso i join vengono considerati male quando il vero colpevole è un modello di dati scadente o una strategia di indicizzazione scadente. Le persone dimenticano anche che i database denormalizzati si comportano molto male quando si tratta di inserire o aggiornare i dati.

La cosa fondamentale da tenere a mente è il tipo di applicazione che stai costruendo. La maggior parte dei famosi siti Web non sono come le normali applicazioni aziendali. Ecco perché Google, Facebook, ecc. Non utilizzano i database relazionali. C'è stato un sacco di discussioni su questo argomento recentemente, che è I have blogged about.

Quindi, se state costruendo un sito Web che riguarda principalmente la consegna di shedloads di contenuto semi-strutturato, probabilmente non volete usare un database relazionale, denormalizzato o altro. Ma se stai costruendo un sito web altamente transazionale (come una banca online) hai bisogno di un design che garantisca la sicurezza e l'integrità dei dati, e lo fa altrettanto bene. Ciò significa un database relazionale in almeno una terza forma normale.

Answer 5

Non importa se non si memorizza correttamente nella cache.

Answer 6

si può ascoltare una discussione su questo argomento dai creatori di overflow dello stack sul loro Podcast a:
http://itc.conversationsnetwork.org/shows/detail3993.html