La normalizzazione ha davvero danneggiato le prestazioni nei siti ad alto traffico?

Sto progettando un database e vorrei normalizzare il database. In una query mi unirò a circa 30-40 tabelle. Ciò danneggerebbe le prestazioni del sito Web se dovesse diventare estremamente popolare? Questa sarà la query principale e verrà chiamata il 50% delle volte. Le altre domande mi unirò a due tavoli.La normalizzazione ha davvero danneggiato le prestazioni nei siti ad alto traffico?

Ho una scelta in questo momento per normalizzare o non normalizzare, ma se la normalizzazione diventa un problema in futuro, potrei dover riscrivere il 40% del software e potrebbe volerci molto tempo. La normalizzazione fa davvero male in questo caso? Dovrei denormalizzare ora mentre ho il tempo?

fonte

2010-04-24 Luke101

Non dovresti dover rischiare un numero così grande di riscritture (40% del tuo) codice. Se inizi a normalizzare, ma con le viste per fornire le astrazioni necessarie per la maggior parte del tuo codice ... allora dovrebbe ovviare alla maggior parte delle modifiche al codice nel caso in cui tu debba denormalizzare nello schema che le tue viste presentano come dovrebbe essere il livello di astrazione. –

Essere consapevoli del sovraccarico (in termini di quantità di lavoro) coinvolti quando è necessario aggiornare tabelle denormalizzate - se si modifica un indirizzo client, invece di cambiarlo in un punto ora è necessario eseguire la scansione di ogni riga nella tabella denormalizzata per cambiare esso. Forse una vista è l'opzione migliore e, se è ancora troppo lento, allora alloca più risorse hardware al database. – slugster

Mi piacerebbe sapere perché hai bisogno di 30-40 tavoli in primo luogo e perché questi devono essere uniti. Questo non mi sembra giusto quindi vorrei che tu spiegassi cosa stanno facendo i tavoli. –

cito: "normalizzare la correttezza, denormalizzare per la velocità - e solo quando necessario"

vi rimando a: In terms of databases, is "Normalize for correctness, denormalize for performance" a right mantra?

HTH.

fonte

2010-04-24 00:13:54 Sunny

+1. Non si normalizza un database - _always_ inizia con 3NF. Ripristina i livelli più bassi per la velocità se, _e solo se_, diventa necessario. E assicurati di comprendere le conseguenze e le soluzioni. Esistono modi per mitigare i problemi causati dalla denormalizzazione (trigger, colonne calcolate e così via). Cerca anche YAGNI :-) – paxdiablo

Quindi pensi che i tavoli da 30 a 40 non costituiranno un problema? Inoltre, se la normalizzazione diventa un problema, è possibile aggiungere hardware migliore per compensare i costi di normalizzazione? – Luke101

@Luke: no, potrebbe essere un problema unire 40 tabelle, a questo punto dovresti prendere in considerazione la denormalizzazione (ma solo dopo che il problema appare, non in previsione di un problema che potrebbe non esistere - misurare, non indovinare). Ma sarei molto interessato a uno schema 3NF che richiedesse un join di quella tabella. Nella mia esperienza, non ho mai incontrato una situazione così estrema. Forse se avessi aggiunto più dettagli su questo aspetto, potremmo entrambi capire meglio e offrire consigli più mirati. – paxdiablo

Non eseguire le ottimizzazioni anticipate. La denormalizzazione non è l'unico modo per accelerare un sito web. La tua strategia di caching è anche abbastanza importante e se la query delle 30-40 tabelle è di dati abbastanza statici, il caching dei risultati potrebbe rivelarsi una ottimizzazione migliore.

Inoltre, prendere in considerazione il numero di scritture sul numero di letture. Se stai facendo circa 10 letture per ogni inserto o aggiornamento, potresti dire che i dati sono abbastanza statici, quindi dovresti tenerlo nella cache per un certo periodo di tempo.

Se si finisce per denormalizzare lo schema, anche le scritture diventano più costose e potenzialmente rallentano anche le cose.

Analizzare veramente il problema prima di fare troppe ottimizzazioni e attendere anche di vedere dove i colli di bottiglia nel sistema sono davvero come si potrebbe essere sorpresi di ciò che si dovrebbe ottimizzare in primo luogo.

fonte

2010-04-24 00:19:54 jamesaharvey

le 30-40 tabelle non saranno affatto statiche. In una giornata normale ci aspettiamo circa 1000 aggiornamenti e inserti. – Luke101

Fare 1000 aggiornamenti in un giorno è inferiore a 1 al minuto. Lo definirei abbastanza statico. – Gabe

concordato. E supponendo che tu stia facendo più letture che scritture, la strategia del caching si rivelerà molto importante. – jamesaharvey

Quando la performance è un problema, ci sono alternative di solito migliori rispetto denormalizzazione:

Creazione di indici e statistiche appropriate sui tavoli coinvolte
Caching
viste materializzate (viste indicizzate in MS SQL Server)
Avere una copia denormalizzata delle tabelle (utilizzata esclusivamente per le query che ne hanno bisogno), oltre alle tabelle normalizzate utilizzate nella maggior parte dei casi (richiede la scrittura del codice di sincronizzazione, che può essere eseguito come un tri gger o un lavoro programmato in base all'accuratezza dei dati necessaria)

fonte

2010-04-24 00:34:22 ckarras

La normalizzazione può compromettere le prestazioni. Tuttavia questo non è un motivo per denormalizzare prematuramente.

Inizia con la normalizzazione completa e poi vedrai se hai problemi di prestazioni. Alla velocità che stai descrivendo (1000 aggiornamenti/inserti al giorno) non credo che ti imbatterai in problemi a meno che i tavoli non siano enormi.

E anche se ci sono tonnellate di opzioni di ottimizzazione del database (indici, stored procedure preparate, viste materializzate, ...) che è possibile utilizzare.

fonte

2010-04-24 00:45:19 Foxfire

Forse mi manca qualcosa qui. Ma se la tua architettura richiede di unire 30-40 tabelle in una singola query, la query dell'annuncio è l'uso principale del tuo sito, quindi hai problemi più grandi.

Sono d'accordo con gli altri, non ottimizzare prematuramente il tuo sito. Tuttavia, dovresti ottimizzare la tua architettura per tener conto del tuo caso d'uso principale. un 40 join tabella per una query eseguita oltre il 50% del tempo non è ottimizzato IMO.

fonte

2010-04-24 02:47:59

La normalizzazione ha davvero danneggiato le prestazioni nei siti ad alto traffico?

risposta

Problemi correlati