La compressione dei dati di SQL Server è categoricamente valida per i database di sola lettura?

Alcune pubblicazioni sulla compressione dei dati di SQL Server che ho letto affermano che il costo di scrittura aumenta a circa quattro volte quello che sarebbe normalmente richiesto. Sembra anche implicare che questo è il principale svantaggio della compressione dei dati, il che implica fortemente che per un database di archivio di sola lettura, le prestazioni (con poche eccezioni) saranno migliorate dall'uso della compressione dei dati di pagine riempite al 100%.

Le affermazioni sopra sono vere?
Quali sono le principali "variazioni" tra compressione dei dati e altro (per la lettura)
- "CPU + x%"?
- "IO -y%"?
- ricorrenza suddivisa in pagine?
- utilizzo tempdb?
- Utilizzo della RAM?
E per scrivere?

Ai fini di questa domanda, è possibile limitare il contesto alla compressione a livello di PAGINA di un database di grandi dimensioni (> 1 TB) , ma sono sempre ben accetti commenti aggiuntivi.

Riferimenti:

Blog di SQL Server Storage Engine (lo scenario DW mostra che la compressione è molto vantaggiosa)
Compressione dei dati: strategia, pianificazione della capacità e best practice

Un approccio più dettagliato per decidere cosa comprimere comporta l'analisi delle caratteristiche del carico di lavoro per ogni tabella e indice. Si basa sulle seguenti due metriche:

U: la percentuale di operazioni di aggiornamento su una tabella, un indice o una partizione specifici, rispetto alle operazioni totali su quell'oggetto. Più basso è il valore di U (ovvero, la tabella, l'indice o la partizione viene aggiornata di rado), migliore sarà la compressione della pagina.
S: la percentuale di operazioni di scansione su una tabella, un indice o una partizione, rispetto alle operazioni totali su quell'oggetto. Più è alto il valore di S (ovvero, la tabella, l'indice o la partizione è per lo più sottoposta a scansione), migliore è il candidato per la compressione della pagina.

Entrambi i precedenti sono dimostrati in modo dimostrabile nel raccomandare la compressione delle pagine per database in stile DW (operazioni ad alta intensità di lettura / esclusive, big data).

— 孔夫子
fonte

Quale letteratura in particolare? Ci sarà sempre un sovraccarico della CPU sia per comprimere / decomprimere ma, come per le letture, stai scrivendo anche su un numero inferiore di pagine. In effetti, penso che il lato di scrittura trarrebbe beneficio anche più del lato di lettura poiché il lato di lettura avrà spesso le pagine compresse archiviate in memoria (questo non è sempre, ma il caso migliore dipende dalla dimensione dei dati e dalla memoria allocata).

— Aaron Bertrand

Sarà molto difficile fornire una qualsiasi delle metriche richieste perché dipende interamente dalla natura dei dati e dalla capacità di comprimerli (e questo sarà diverso a seconda della riga rispetto alla pagina, ). Alcune persone hanno riportato un rapporto di compressione fino al 90% che avrà un impatto sull'utilizzo della memoria (in modo positivo) e sulla CPU per eseguire tale compressione. Questo documento contiene un sovraccarico della CPU al 10% per la compressione delle righe e superiore per la pagina . Quello che osservi potrebbe essere abbastanza diverso.

— Aaron Bertrand

Per un database di archivio di sola lettura, suppongo che la domanda sarebbe se si adatta alla memoria. Se può contenere tutto in memoria, una volta caricato nel pool di buffer non vi è alcun vantaggio reale nel comprimerlo. Se, tuttavia, non si adatta tutto alla memoria, potresti comunque vedere alcuni vantaggi nello scambiare un numero minore di pagine dentro e fuori dalla cache anche se ci sarà del lavoro da eseguire per decomprimerlo.

— Aaron Bertrand

Nessuno dei link aggiunti sembra fare menzione di questa penalità 4x per la scrittura. Ricordi dove l'hai raccolto? Mi piacerebbe vedere il contesto.

— Aaron Bertrand

Bene, se non riesci ad adattare i dati in memoria di quello scenario è un po 'discutibile, giusto? :-)

— Aaron Bertrand

Risposte:

Solo i miei 2 centesimi dai miei esperimenti su hardware di 1-2 anni:

Operazioni di sola lettura (scansioni, ordinamenti in stile DW, ecc.) Su tabelle compresse in pagine (~ 80row / pagina) che ho trovato in pareggio alla riduzione delle dimensioni di compressione di ~ 3x.

Ad esempio, se le tabelle si adattano comunque alla memoria, la compressione della pagina migliora le prestazioni solo se la dimensione dei dati si è ridotta di oltre 3 volte. Puoi scansionare meno pagine in memoria, ma ci vuole più tempo per scansionare ogni pagina.

Mi immagino che la tua situazione potrebbe essere diversa se i vostri piani sono nested-loop e cercano pesante. Tra l'altro, ciò dipende anche dall'hardware (penalità di accesso al nodo NUMA esterno, velocità della memoria, ecc.).

Quanto sopra è solo una regola empirica che seguo, basata sulle mie esecuzioni di test utilizzando le mie query sul mio hardware (Dell Poweredge 910 e precedenti). Non è vangelo eh!

Modifica: ieri l'eccellente presentazione SQLBits XI di Thomas Kejser è stata resa disponibile come video. Abbastanza rilevante per questa discussione, mostra il lato "brutto" del costo della CPU per la compressione della pagina: aggiornamenti rallentati di 4x, blocchi bloccati per un po 'più a lungo.

Tuttavia , Thomas sta utilizzando l'archiviazione FusionIO e ha scelto una tabella che è solo "solo" idonea per la compressione delle pagine. Se l'archiviazione fosse su una tipica SAN e i dati utilizzati fossero compressi 3x-4x, l'immagine avrebbe potuto essere meno drammatica.

— John Alan
fonte

Può essere il vecchio hardware? Sul nuovo hardware, SSD nudo Per l'archiviazione, trovo che i core non siano in grado di tenere il passo con i dischi facilmente. Nondimeno, a mio avviso, il vantaggio darebbe inizio a MOLTO più facilmente: una riduzione del 50% nell'IO vale la pena quando non si apportano molti cambiamenti.

— TomTom,

TomTom, Storage non entra in gioco per queste cifre. Il confronto è tra tabelle non compresse in memoria e tabelle compresse in memoria.

— John Alan,

Non ho mai visto un DWH abbastanza buono per la memoria. Sul serio. Tornerai al disco.

— TomTom,

Sì, certo, di tanto in tanto tornerai al disco - la lettura dal disco è dove la compressione della pagina ha quasi sempre un vantaggio (supponendo che i dati siano abbastanza comprimibili!). Ma se il tuo carico di lavoro viene caricato dal disco una volta e poi manipola tutto in memoria per il resto della giornata, quanto peso daresti alla lettura del disco e quanto alle operazioni in memoria?

— John Alan,

Ho appena incontrato una presentazione pertinente di SQLBits 2013 di Thomas Kejser: slideshare.net/fusionio/…

— John Alan,

Posso aggiungere alcune parole dal mio ambiente Data Warehouse.

L'implementazione della compressione (PAGINA nel mio caso) su una tabella di test con 30 milioni di righe (18 GB) riduce le dimensioni della tabella da 18 GB a 3 GB! (efficienza di archiviazione sicura) ma aumenta il tempo di caricamento (scrittura) da 22 a 36 minuti.

Quindi per leggere o leggere e conservare i dati in memoria potrebbe essere una buona soluzione, ma per il caricamento giornaliero dei dati potrebbe causare il downgrade delle prestazioni.

— Tomasz Wieczorkowski
fonte