Compression methods on exadata use parallel to speed up compression - part 3 of 6 , paratab

+

Nella parte 1 e parte 2 della serie di blog, vi mostro gli esempi per la creazione di tabelle comprimere utilizzando CREATE TABLE e ALTER TABLE SPOSTA. Per piccole tabelle nell'esempio, potrebbe essere ok non utilizzare il parallelismo. Ma per grandi tavoli, il parallelismo è altamente raccomandato proprio come le foto di cui sopra. Bisogna avere molte linee sulla strada principale per consentire un elevato throughput. Vorrei che l'aggiunta di una nuova linea su strada potrebbe essere facile come cambiare DOP in SQL. Questo post discute il parallelismo per i metodi di compressione. Come il comando sarà simile per diversi tipi di metodo di compressione, prendo un metodo HCC e testare i tempi per i diversi valori DOP. Come QUERY LOW dà un rapporto di compressione più basso ed è molto improbabile che sto per uso in produzione, in modo QUERY LOW è fuori. Diamo un'occhiata a ARCHIVIO ALTA, anche se può dare un rapporto di compressione molto meglio, il tempo di elaborazione è di solito più volte più a lungo rispetto ad altri metodi di HCC. Dato che potrebbe anche richiedere più tempo per decomprimere i dati quando abbiamo bisogno di spostare i dati in ambiente non Exadata, sarò molto improbabile che utilizzare questo metodo per la produzione a meno che non ho davvero bisogno di risparmiare notevole spazio importo. Così lascia con Query HIGH e LOW ARCHIVIO. Entrambi utilizzano ZLIB algoritmo di compressione (gzip). I rapporti di temporizzazione e di compressione sembrano abbastanza vicino dalla mia esperienza. Quindi, o uno di loro è bene per la mia prova e scegliere il metodo di compressione elevato Query come la base per il nostro test. Ho anche aumentare la dimensione della tabella di prova a 80 milioni di righe. Sembra che ho bisogno di fare il commit prima che io possa fare ulteriormente operazione di inserimento. Scopriamo quali sono le dimensioni per questa tabella. Quindi creare altri tre tabelle simili. All'aumentare DOP, il tempo di elaborazione riduce in modo lineare. Il tempo di compressione per un tavolo 9G riduce da tre minuti e mezzo a meno della metà minuto con DOP di 8. Un'altra parte interessante è che la dimensione compressione finale è leggero differente con differente valore DOP.