Previsione dei vantaggi della denormalizzazione del database

Dovresti conoscere i flussi di dati tra le tabelle per essere in grado di vedere come si comporta il modello DB. Una volta ottenuto ciò, è possibile calcolare il cambiamento delle prestazioni per una data denormalizzazione (ad es. Se si decide di duplicare i dati)

Alcune stime approssimative possono essere dedotte dal numero di nuovi indici necessari dopo le fasi di denormalizzazione. Ogni nuovo indice deve essere aggiornato e interrogato separatamente, il che comporterà un colpo di rendimento proporzionale al numero di nuovi indici.

Big blob di dati binari dovrebbero in ogni caso essere memorizzati in una tabella separata e non copiati in giro. Sono (di solito) non interrogati ma restituiti come parte del set di risultati finali dopo una query rispetto ad altri gruppi di tabelle.

Non sono sicuro che ci sia qualche ricerca accademica su quando la denormalizzazione può aiutare (IMHO c'è una grande differenza tra ciò che viene insegnato sulla normalizzazione del DB e come funziona nella pratica).

Tuttavia, ci sono molti articoli e blog interessanti su questo argomento - Jeff Atwood parla della normalizzazione in il suo blog , e c'è un " rispondi " a lui ad alta scalabilità.

Quando denormalizzi, ti suggerisco di prestare attenzione a

• numero e tipo di query per unità di tempo; se usi insert e / o update più di read, denormalizing non sarebbe di grande aiuto.
• con quale frequenza le informazioni duplicate verranno aggiornate
• le caratteristiche del DBMS che utilizzerai
• quante volte le informazioni sono duplicate; se hai le stesse informazioni in 4-5 tabelle, potrebbe essere più veloce conservarlo in una tabella separata invece di copiarlo tante volte
• la quantità prevista di dati conservati nel DB; cosa potrebbe funzionare per piccole quantità di dati, può portare a un disastro se aumenta il numero di record. E viceversa (intendo il principio KISS e non aggiustando ciò che non è rotto).

I imagine that de-normalizing too much would waste space and time

Lo spazio non deve preoccuparsi della maggior parte delle applicazioni OLTP Line of Business di medie dimensioni. Quindi lascia lo spazio da parte. Tempo e presumendo che tu intenda le prestazioni della query, è qualcosa che di solito può essere migliorato e non causa un problema reale a meno che tu non abbia una progettazione errata, risorse insufficienti, un database estremamente grande, un numero molto elevato di transazioni o tutte quanto sopra. La maggior parte delle applicazioni che utilizzano i database di oggi raramente presentano problemi di prestazioni solo perché il database è normalizzato.

giant blobs are duplicated or it because harder to maintain consistency because you have to update multiple fields using a transaction.

Normalizzare il tuo database ti assicura che la progettazione sarà:

1. Non disponi di dati ridondanti.

2. Non causa la creazione di un enorme numero di enterite di log (ad esempio, con una tabella di 2 milioni di clienti: UPDATE Customer Set Country="USA" WHERE Country="US")

3. Essere supportati completamente da query SQL. Questo punto è molto importante.

4. Troverà un codice di applicazione pulito.

5. Forza un alto grado di coerenza dei dati tramite il database senza appesantire l'applicazione.

6. Condividi le regole aziendali definite nel database da diverse applicazioni senza codificare lo stesso codice in diverse applicazioni.

Detto questo, la normalizzazione produce una struttura ottimale per tutte le colonne e le tabelle. Questo potrebbe non essere sempre necessario nella tua particolare applicazione, quindi potresti determinare, dato che hai compreso il tuo dominio e la tua applicazione, per de-normalizzare alcune delle tabelle / colonne come un compromesso per la velocità. Tuttavia, sarebbe una decisione consapevole piuttosto che una supervisione.

Given a 3NF FD set, and a set of queries, how do I predict the speedup/slowdown of de-normalization?

Non è possibile prevedere con precisione le prestazioni senza test (cosa che si può fare prima di scrivere il codice dell'applicazione). Tuttavia, è possibile eliminare e rilevare i fattori che potrebbero causare prestazioni errate in base alla progettazione. Ad esempio, è possibile identificare quale strategia di indice utilizzare come segue (potrebbero esistere altre tecniche):

1. Crea una matrice di query e colonne interessate da tali query.

2. Trova le colonne più utilizzate.

3. Considera la possibilità di creare indici su tali colonne.

Questo è principalmente un lavoro in cui il tuo DBA potrebbe aiutarti. C'è più prestazioni rispetto alla normalizzazione. Ci sono aspetti della distribuzione dei dati su volumi del disco, divisione verticale della tabella, partizionamento, tipi di indice e buffering dell'indice per nominarne alcuni. Tutte queste tecniche dovrebbero essere trattate nei libri e nella documentazione del fornitore in "Database Design" e "Database Performance Tuning". Tutte le discussioni precedenti presuppongono che l'applicazione sia un'applicazione OLTP.

Uno dei principali motivi per normalizzare è l'ottimizzazione per i casi di uso generale, mentre la denormalizzazione tende a ottimizzare le prestazioni per casi d'uso specializzati (con sanzioni significative per altri casi d'uso). Questo è uno dei motivi per cui solitamente i carichi di lavoro OLTP traggono vantaggio principalmente dalla normalizzazione (ci sono eccezioni qui ma sono rari).

Per poter prevedere i vantaggi, ciò che devi veramente sapere è esattamente ciò che stai denormalizzando e per quali flussi di lavoro. Ci sono anche domande sulla dimensione del set di dati e su quali potrebbero essere gli impatti del caching. Pertanto, è probabile che la risposta dipenda da un numero molto elevato di elementi, tra cui la dimensione del database, la parte che è probabile che rimanga ancora in memoria, la pianificazione del sovraccarico di query complesse e simili. Questa è una questione molto complicata, specifica per l'implementazione, e dipende molto dal database e dal tuo RDBMS. Questi vantaggi saranno maggiori nei carichi di lavoro OLAP e in genere gli svantaggi saranno maggiori nei carichi di lavoro OLTP.

Quindi non vedo che qui c'è una sola risposta oltre a guardare i piani di query e considerare la possibilità di visualizzazioni materializzate per dati denormalizzati. Dal mio punto di vista l'approccio migliore è quello di avere un database OLTP relativamente normalizzato e denormalizzare a fini di reporting solo se necessario.

Normalmente den-normalizzi il tuo modello di dati per ottimizzare le prestazioni per un caso d'uso particolare . Questo di solito ha un effetto negativo sulle prestazioni di altri casi d'uso. per esempio. la ripetizione dei dati in più righe può accelerare l'elaborazione delle query eliminando un join, ma l'elaborazione degli aggiornamenti sarà rallentata.

In effetti 3NF offre prestazioni ottimali per qualsiasi numero di accessi arbitrari al tuo database, ma, per particolari join e selezioni, potrebbero esserci modelli migliori.

Quindi tratta la de-normalizzazione come faresti con qualsiasi altra ottimizzazione. Ad esempio, non farlo a meno che tu non abbia effettivamente un problema di prestazioni, e assicurati che la tua "correzione" non causi più problemi di quanti ne risolva.