doc2,2,2,2,2,2
download 
Reclamo Transcript
2,2,2,2,2,2
NETEZZA APPLIANCE Danilo De Benedictis – [email protected] NETEZZA SQL – DAY 3 PROSSIMI ARGOMENTI: GESTIONE TABELLE CLUSTERED BASED TABLES JOIN TRA TABELLE GESTIONE TABELLE PERFORMANCE SU RDBMS TRADIZIONIALI Utilzzo degli Indici Partitioning, ma utlizzo di Indici all’interno di ciascuna Partition NETEZZA PARTITION Con Netezza le performance estreme sono raggiunte tramite parallelizzazione massiva dei table scan sugli Storage Server Utilizzo ZoneMap Per ogni query di estrazione dati… Select colA, colB from tableA where colC > 38 ; …la query è inviata alle 100+ SPU, ed ogni SPU esegue un Full Table Scan per costruire il Result Set Al termine i Result Set vengono uniti e restituiti al Client. GESTIONE TABELLE INTRODOTTE CON TWINFIN LE CLUSTERED BASED TABLE (CBT): COSA SONO CREATE TABLE ... [ORGANIZE ON {(<column>) | NONE}] 1..4 organizing key: sono campi scelti per il clustering dei record di tabella. I dati ‘organizzati’ vengono salvati nella stessa data-slice (o vicine) Vengono create le Zone-Map per le ORG K. Esempio: tabella CBT ordinata per: TRANSACTION_DATE poi ORGANIZED per: TRANSACTION_TYPE (stesso colore): GESTIONE TABELLE CLUSTERED BASED TABLE (CBT): COME SCEGLIERE: Le Organized keys aiutano a reperire più velocemente i dati, grazie alle Zone Maps, quindi... ...le Organized keys vanno scelte in base ai filtri maggiormente utilizzati dalle query. Nell’esempio precedente, il filtro maggiormente utilizzato è per TRANSACTION_TYPE. GESTIONE TABELLE CLUSTERED BASED TABLE (CBT): BENEFICI Le CBT supportano le Multidimension Lookups: da 1 a 4 campi Le Organize Keys impongo ulteriori Zone Maps i.e. Migliori performance, se il datatype dei campi è supportato dalle Zone Maps: ZM default: date, timestamp, byteint, smallint, integer, bigint ZM x M.VIEW ORDER BY o ORG.K: char, varchar, nchar, nvarchar (solo i primi 8 bytes vengono utilizzati), numeric, float, double, bool, time, timetz, interval. CBT riducono la necessita di pre-ordinare i dati prima del caricamento. CBT non replica dati, o alloca ulteriore spazio, come invece fanno indici, Mview. GESTIONE TABELLE CLUSTERED BASED TABLE (CBT) VS ZONE MAPS: Le ZM riassumono il RANGE dei dati di una colonna presenti nel disco. Le ORG.K. restringono i tempi di estrazione dei dati ‘avvicinando’ le righe che hanno uguali valori nei campi selezionati, riducendo i tempi del fulltable-scan. GESTIONE TABELLE CLUSTERED BASED TABLE (CBT): UTILIZZO Tipicamente, se una tabella è interrogata per un campo FIELD_1 di tipo DATE, caricarla ORDER BY FIELD_1, per sfruttare a pieno le Zone Maps. Se le query filtrano per più campi diversi (multidimension) usare la ORGANIZE. Dopo l’aggiunta (ALTER TABLE) di campi ORGANIZEd, Netezza NON riorganizza: lanciare la GROOM TABLE: GESTIONE TABELLE GROOME TABLE <table_name> Organizza i record secondo la definizione della ORGANIZE, avvicinando i record che partecipano alla ORGANIZE: stesso disk extent oppure vicino. Rimuove lo spazio deleted o outdated (nzreclaim). No lock sulla tabella. nzreclaim deprecated dalla 6.0: usare GROOME. GENERATE STATISTICS Collect info sulle tabelle, in modo da creare EXECUTION PLAN ottimali Best practice: eseguire dopo ogni LOAD/INS/UPD/DEL GESTIONE TABELLE DELETE FROM <table> WHERE … Cancella righe da una tabella, lasciano allocato lo spazio vuoto che non viene recuperato. TRUNCATE TABLE <table> Cancella tutto il contenuto della tabella, liberando lo spazio su disco che al successivo clean-up [GROOME] viene reso disponibile. Non può essere eseguito in una TRAN DROP TABLE <table> Elimina una tabella, liberando lo spazio su disco che al successivo clean-up [GROOME] viene reso disponibile. GESTIONE TABELLE ALTER (VARCHAR(LEN)), DROP COLUMN ALTER TABLE t3 MODIFY COLUMN (col1 VARCHAR(6)); Varchar Len -< up to 64000 RENAME TABLE fornitori RENAME COLUMN indirizzo TO citta; JOIN TRA TABELLE INNER JOIN equivale a select .. from tab1 , tab2 Esempio: SELECT COUNT(1) FROM TAB1 T1 INNER JOIN TAB2 T2 ON T1.FIELD_A = T2.FIELD_A JOIN TRA TABELLE LEFT OUTER JOIN Esempio: SELECT T1.AAA, T1.BBB, T2.CCC FROM TAB1 T1 LEFT OUTER JOIN TAB2 T2 ON T1.FIELD_A = T2.FIELD_A TUTTE LE RIGHE DI T1 T1.AAA, T1.BBB SEMPRE VALORIZZATI DOVE MATCH, LE RIGHE DI T2 NOT MATCH => T2.CCC = NULL MATCH => T2.CCC VALORIZZATO JOIN TRA TABELLE RIGHT OUTER JOIN (simmetrica di LOJ) Esempio: SELECT T1.AAA, T1.BBB, T2.CCC FROM TAB1 T1 RIGHT OUTER JOIN TAB2 T2 ON T1.FIELD_A = T2.FIELD_A TUTTE LE RIGHE DI T2 T2.CCC SEMPRE VALORIZZATO DOVE MATCH, LE RIGHE DI T1 NOT MATCH => T1.AAA, T1.BBB = NULL MATCH => T1.AAA, T1.BBB VALORIZZATI JOIN TRA TABELLE SELF-JOIN JOIN DI UNA TABELLA CON SE’ STESSA Esempio (città con intervalli temperatura più ‘larghi’ delle altre città): SELECT W1.city, W1.temp_lo AS low, W1.temp_hi AS high, W2.city, W2.temp_lo AS low, W2.temp_hi AS high FROM weather W1, weather W2 WHERE W1.temp_lo < W2.temp_lo AND W1.temp_hi > W2.temp_hi; JOIN TRA TABELLE FULL OUTER JOIN RESTITUISCE TUTTE LE RIGHE DELLE TABELLE IN JOIN SELECT * FROM cows_one FULL OUTER JOIN cows_two ON cows_one.cnumber = cows_two.cnumber; COMPARAZIONE CON LOGICHE FUZZY Levenshtein Edit Distance: <int4 value> = le_dst(<str_1>, <str_2>) Esempio: le_dst('sow','show') = 1 ‘h’ in più Esempio: le_dst('hello','Hollow') = 3 H maiuscola ‘o’ al posto di ‘e’ ‘w’ in più COMPARAZIONE CON LOGICHE FUZZY Damerau-Levenshtein Edit Distance: <int4 value> = dle_dst (<str_1>, <str_2>) Simile al precedente, ma la trasposizione di caratteri vale 1 non 2: Esempio: select le_dst('two','tow') = 2 select dle_dst(‘two',‘tow') = 1 PROSSIMI ARGOMENTI: COMBINE TRA TABELLE TRANSACTION ISOLATION COMBINE TRA TABELLE UNION Unione dei risultati di 2+ query Eliminazione dei risultati ridondati UNION OR UNION ALL Mostra tutte le righe, anche quelle ridondate {0,1,2,2,2,2,3,N,N} UNION ALL {1,2,2,3,5,5,N,N,N} = {0,1,1,2,2,2,2,2,2,3,3,5,5,N,N,N,N,N} COMBINE TRA TABELLE INTERSECT Intersezione dei risultati di 2+ query INTERSECT AND INTERSECT ALL In caso di righe ridondate, mostra tutte le righe con minore cardinalità. {0,1,2,2,2,2,3,N,N} {1,2,2,3,5,5,N,N,N} = {1,2,2,3,N,N} INTERSECT ALL COMBINE TRA TABELLE EXCEPT / MINUS Delta tra i risultati di 2 query (Q1 – Q2) Eliminazione dei risultati ridondati {0,1,2,2,2,2,3,N,N} = EXCEPT {1,2,2,3,5,5,N,N,N} {0} EXCEPT / MINUS ALL In caso di righe ridondate, mostra tutte le righe IN Più DELLA PRIMA TABELLA. {0,1,2,2,2,2,3,N,N} = {0,2,2} EXCEPT ALL{1,2,2,3,5,5,N,N,N} COMBINE TRA TABELLE PRECEDENZE: UNION ED EXCEPT/MINUS HANNO LA STESSA PRIORITA’: VENGONO ESEGUITE IN ORDINE LEFT -> RIGHT INTERCEPT HA PRIORITA’ SU UNION E EXCEPT/MINUS. S1 UNION S2 EXCEPT S3 UNION S4 => (((S1 UNION S2) EXCEPT S3) UNION S4) S1 UNION S2 INTERSECT S3 MINUS S4 => ((S1 UNION (S2 INTERSECT S3)) MINUS S4) PER EVITARE CONFUSIONE O FORZARE PRIORITA’ DESIDERATE: USARE LE PARENTESI. (S1 UNION S2) INTERSECT (S3 MINUS S4) COMBINE TRA TABELLE GESTIONE NULL: NELLA COMPARE TRA CAMPI, UN CAMPO CONTENENTE NULL NON E’ UGUALE AD UN ALTRO CAMPO CONTENENTE NULL: (NULL = NULL) => UNKWOWN COMBINE TRA TABELLE, NULL E’ TRATTATO UGUALMENTE AGLI ALTRI VALORI: NELLA (NULL = NULL) => TRUE COMBINE TRA TABELLE PROMOTION TRA DATATYPE NUM/CHAR: COMBINE TRA TABELLE PROMOTION TRA DATATYPE NON NUM/CHAR: GESTIONE TRANSAZIONI CONCORRENTI Prevenzione delle tipologie di READ ‘sporche’: DIRTY READS: una T0 può leggere dati scritti da una T1 concorrente, non ancora committed. NONREPEATABLE READS: una T0 ri-legge dati già letti, e rileva dati modificati, committate da una T1 che nel frattempo termina. PHANTOM READ: una T0 ri-esegue una query con search condition, e riceve un set di dati diverso dalla precedente query, committate da una T1 che nel frattempo termina. GESTIONE TRANSAZIONI CONCORRENTI Isolation Level: 4 livelli read committed read uncommitted repeatable read serializable Netezza supporta tutti i 4 livelli ma... ... Implementa solo il ‘Serializable’ ! PROSSIMI ARGOMENTI: VISTE VISTE MATERIALIZZATE GESTIONE VISTE VIEW: PER SEMPLIFICARE L’ACCESSO AI DATI, PER UTENTI CON VISIBILITA’ NON DEEP SUI DATI. PER METTERE IN SICUREZZA I DATI PRESENTI SU TABELLA: DEFINITA INTERFACCIA VERSO APPLICATIVI, INVARIANTE ALLA STRUTTURA DATI ACCESSO CONSENTITO ALLA VIEW ACCESSO NON CONSENTITO ALLA TABELLA SOTTOSTANTE EVENTUALMENTE SI MODIFICA LA QUERY SOTTOSTANTE LA VIEW, MA NON LA STRUTTURA DELLA STESSA. INTERFACCIA VERSO APPLICATIVI RIMANE INVARIATA SINTASSI: CREATE VIEW viewname AS SELECT query; CREATE OR REPLACE: USATA PER MANTENERE LE ACL DELLA VIEW ORIGINARIA ALLA NUOVA VIEW DROP, ALTER per RENAME, ALTER X CHANGE OWNER GESTIONE VISTE MATERIALIZZATE SORTED, PROJECTED, AND MATERIALIZED VIEWS (SPM) Proiezione di un subset delle colonne di una tabella, ordinate su uno specifico subset delle colonne in proiezione. Le Viste materializzate vengono memorizzate su una tabella fisica (su disco) con l’ordinamento richiesto. Servono ad ottimizzare l’accesso a Tabelle molto grandi. GESTIONE VISTE MATERIALIZZATE Il query planner utilizza le SPM View per (eventualmente) ottimizzare l’accesso a tabelle, anche se non richiesto esplicitamente, quindi non è necessario modificare le applicazioni. Performance migliorate grazie ad: una riduzione della quantità di dati letti da disco Dati già ordinati ottimizzazione utilizzo ZoneMaps Ottimali se utilizzate per tabelle piccole (lookup) GESTIONE VISTE MATERIALIZZATE BLOCK NUMBER DELLA TABELLA BASE Netezza System aggiunge automaticamente una colonna alle colonne scelte per le SPM La colonna contiene – per ogni riga - il Block Number della riga originaria (puntatore) Il Block number viene utilizzato come indice per la tabella base, ottimizzando l’accesso alla stessa. GESTIONE VISTE MATERIALIZZATE I dati delle SPM sono allocati sugli stessi data-slice della corrispondente tabella base, per ottimizzarne l’accesso. CREATE MATERIALIZED VIEW customers_mview AS SELECT customer_name, customer_id FROM customers ORDER BY customer_id; GESTIONE VISTE MATERIALIZZATE REGOLE PER CREAZIONE SPM: Una sola tabella base nella FROM Non è consentito utilizzare la WHERE nella creazione delle SPM Le colonne possono essere solo colonne della tabella base, non espressioni. Quindi non sono permessi: aggregazioni, operatori matematici, casting, DISTINCT, etc.. GESTIONE VISTE MATERIALIZZATE REGOLE PER CREAZIONE SPM: La ORDER BY può essere applicata solo su colonne presenti nella SELECT (projection list) Se non è specificata la ORDER BY, l’ordinamento è uguale a quello della tabella base Non si può usare NULLS LAST o DESC nell’ORDER BY La tabella base non può essere EXTERNAL, temporary oppure di sistema GESTIONE VISTE MATERIALIZZATE MANUTENZIONE : SPM: Se si inseriscono righe sulla tabella base, esse: vengono aggiunte anche alle SPM costruite su di essa; Vengono ‘appese’ in un’area unsorted, quindi è necessario fare un refresh della SPM, periodicamente. Modifiche alla struttura della tabella base, invalidano la SPM: ERROR: Base table/view 'WEATHER' attr 'CITY' has changed (precision); rebuild view 'WEATHER_V‘ Le righe cancellate dalla tabella base, vengono automaticamente cancellate anche dalle SPM collegate. GESTIONE VISTE MATERIALIZZATE MANUTENZIONE : REBUILD: CREATE OR REPLACE MATERIALIZED VIEW weather_v AS SELECT city, temp_lo, temp_hi FROM weather ORDER BY city; Non usare la DROP/CREATE, perchè cambia object ID della SPM=> impatto sugli oggetti che referenziano la SPM. GESTIONE VISTE MATERIALIZZATE MANUTENZIONE : DROP della SPM: DROP VIEW customers_mview; (non DROP MATERIALIZED...) libera spazio allocato per la SPM DROP della tabella base: DROP anche della SPM Netezza mantiene la definizione, trasformandola in una VIEW normale Successivi accessi alla SPM danno errore GESTIONE VISTE MATERIALIZZATE MANUTENZIONE : ALTER VIEW customers_mview MATERIALIZE [option]: Option = SUSPEND: Sospende l’utilizzo della SPM e degli oggetti referenzianti. Truncate della SPM Redirect alla tabella base Usare SUSPEND per attività di manutenzione sui DB, come la RECLAIM, la RESTORE, o le NZLOAD. Option = REFRESH: Ri-materializza la SPM, ricostruendo la projected structure. Si usa dopo la SUSPEND Si usa per ri-ordinare le SPM dopo: La SUSPEND Pe ottimizzare gli accessi Per ordinare le righe unsorted (inserite sulla tabella base dopo la CREATE SPM) GESTIONE VISTE MATERIALIZZATE MANUTENZIONE : REFRESH threshold: Con GRANT da amministratore, è possibile impostare un limite ai dati non ordinati, dopo il quale il sistema forza la REFRESH della SPM. SET SYSTEM DEFAULT MATERIALIZE THRESHOLD TO <number>; <number> rappresenta una percentuale: Da 1 a 99 Default = 20 GESTIONE VISTE MATERIALIZZATE QUERY: Non possiamo fare INSERT sulle SPM, ma solo SELECT In caso di SELECT sulla tabella base, l’ottimizzatore verifica l’eventuale esistenza di SPM collegate: esistono, l’ottimizzatore decide se usarle in base al predicted cost and performace. Se Le SELECT sulle SPM possono richiedere più memoria delle SELECT sulle tabelle base, a causa delle righe un-sorted. GESTIONE VISTE MATERIALIZZATE MIRRORING: Le SPM vengono trattate su disco in maniera analoga alle tabelle base. Quindi: data slice contenente è in mirror con un’altra partizione, presente su un altro disco In caso di fail, il failover e la regeneration avvengono anche per i dati delle SPM. Il GESTIONE VISTE MATERIALIZZATE RECLAIM: Non è possibile fare RECLAIM sulle SPM In caso di RECLAIM sulle tabelle base: 1) le SPM afferenti vengono temporaneamente SUSPENDED 2) La RECLAIM gira sulle tabelle base 3) Al termine, le SPM vengono riattivate, ma rimangono SUSPENDED (necessario quindi un REFRESH manuale) Le operazioni sopra descritte, vengono fatte in maniera transazionale. GESTIONE VISTE MATERIALIZZATE NZLOAD ed SMP: Non è possibile fare NZLOAD sulle SPM. In caso di NZLOAD sulle tabelle base: Le righe delle SPM afferenti vengono automaticamente aggiornate Process slow down Best practice: SUSPEND le SPM prima di NZLOAD REFRESH le SPM dopo NZLOAD GESTIONE VISTE MATERIALIZZATE NZ_BACKUP: In caso di backup di un DB: vengono salvate le definizioni delle SPM (come delle viste normali) Non vengono salvati i dati delle SPM In caso di restore di un DB (o table-level restore) Le SPM vengono rigenerate al termine del restore GESTIONE VISTE MATERIALIZZATE ZONE MAPS: Netezza system crea Zone Maps per un campo della SPM se: Il campo è di tipo INTEGER, DATE, TIMESTAMP Per un campo della ORDER BY, di tipo: integers — 1-byte, 2-byte, 4-byte, and 8-byte date timestamp char — all sizes, but only the first 8 bytes are used in the zone map varchar — all sizes, but only the first 8 bytes are used in the zone map nchar — all sizes, but only the first 8 bytes are used in the zone map nvarchar — all sizes, but only the first 8 bytes are used in the zone map numeric — all sizes except 128-bit numerics float double bool time time w/timezone interval GESTIONE VISTE MATERIALIZZATE BEST PRACTICES: Tabelle con molte colonne, ma poche sono le più utilizzate. Colonne maggiormente restrittive: se una colonna: è spesso utilizzata nei filtri… …i filtri escludono la maggior parte dei dati (es. Condizione per intervallo temporale)… …allora usare la colonna nell’ORDER BY. Creare SPM con minor numero di colonne possibile, incluse quelle più restrittive, in modo che Netezza le possa usare come index verso la tabella base. Ridurre al massimo le SPM insistenti sulla stessa tabella base Causerebbe degrado prestazionale nelle query, a causa dei tempi spesi dall’optimizer. PROSSIMI ARGOMENTI: SUBQUERY FUNZIONI DI AGGREGAZIONE SUBQUERY REGULAR SUBQUERY: query annidata in altre query, racchiusa da parentesi: Esempio: SELECT StoreId FROM Stores WHERE TotalSale > 0.01* (SELECT SUM(TotalSales) FROM Stores); TIPOLOGIE DI SUBQUERY: ROW SUBQ: restituisce 0/1 riga, 1/n colonne TABLE SUBQ: restituisce 0/n righe, 1/n colonne SINGLETON SUBQ: restituisce esattamente 0/1 riga, con 1 colonna. Le SUBQ vengono calcolate per prime, e vengono temporaneamente memorizzate per l’utilizzo finale. SUBQUERY CORRELATED SUBQUERY: query annidata in altre query, ma che referenzia oggetti della query esterna. Viene calcolata ripetutamente, diversamente dalle SUBQ. Esempio: SELECT FROM WHERE StoreID Stores S S.TotalSales*0.1 < (SELECT SUM(i.Price) FROM Item i WHERE S.StoreID = I.StoreId and I.ItemType = "Dairy"); In questo esempio, viene calcolata la somma dei Price nell’ambito dello stesso StoreID. SUBQUERY CORRELATED SUBQUERY: spesso può essere convertita in normale SUBQ in join: Esempio precedente, equivale a: SELECT S.StoreId FROM Stores S , (SELECT I.StoreId, Sum(Price) DairySales FROM Items I WHERE I.ItemType = "Dairy" GROUP BY I.StoreId) D WHERE S.StoreId = D.StoreId AND S.TotalSales *0.1 < D.DairySales; SUBQUERY CORRELATED SUBQUERY: RESTRIZIONI: Netezza converte le CORRELATED SUBQUERY in SUBQ with JOIN. CORR SUBQ soltanto nella WHERE CORR SUBQ in INNER JOIN soltanto con operatore = Non si possono usare: In operazioni d’insieme (UNION, INTERSECT, EXCEPT, MINUS) In aggregazioni (GROUP BY, HAVING) In OR, CASE/WHEN, nelle liste della IN, nelle liste della SELECT. PERFORMANCE EXPENSIVE: provare sempre a convertirle con la JOIN. FUNZIONI DI AGGREGAZIONE AGGREGAZIONE DI GRUPPO: restituiscono il risultato calcolato su 0-n righe. SELECT max(temp_lo) FROM weather; Es. MAX, MIN Usate anche con GROUP BY Usate anche con GROUP BY .. HAVING .. FUNZIONI DI AGGREGAZIONE AGGREGAZIONE SU FINESTRA (i.e. WINDOWS ANALYTIC FUNCTIONS) restituiscono il risultato calcolato su UN GRUPPO DI 0-n righe DEFINITE DA UNA FINESTRA. ESEMPIO: data la tabella... FUNZIONI DI AGGREGAZIONE AGGREGAZIONE SU FINESTRA: Esempio 1: SELECT year, month, salesk, avg(salesk) OVER (PARTITION BY year ORDER BY month ROWS BETWEEN 1 PRECEDING AND 1 FOLLOWING) FROM monthlysales; Ogni riga, utilizza la precedente (se esiste) e la successiva (se esiste) in una finestra con ordinamento desiderato, per fare un calcolo aggregato. FUNZIONI DI AGGREGAZIONE AGGREGAZIONE SU FINESTRA: risultato 1: AVG(20,22,25) = (20+22+25)/3 = 67/3 = 22.33333 AVG(22,25,30) = (22+25+30)/3 = 77/3 =25.66666 Dov’è l’errore ??? FUNZIONI DI AGGREGAZIONE AGGREGAZIONE SU FINESTRA: Esempio 2: SELECT *, sum(salesk) OVER (PARTITION BY year ORDER BY month ROWS UNBOUNDED PRECEDING) FROM monthlysales; Ogni riga, utilizza tutte le precedenti della PARTITION. FUNZIONI DI AGGREGAZIONE AGGREGAZIONE SU FINESTRA: risultato 2: SUM(30,35,50) = 115 ANALYTIC FUNCTIONS: UNA SESSIONE SUCCESSIVA!!! <EOF> REFUSI NETEZZA SQL INTRODUCTION 1. ACCESSO A NETEZZA SQL CON NZSQL 1. 2. 3. 4. 5. 2. nzsql COMMANDS 1. 2. 3. 4. 5. 6. 3. Logging On Risposta ai Command Management delle Sessioni Supporto SSL per i Client Variabili SQL di Sessione Input Output Options Miscellaneous Slash Query Buffer nzsql EXIT CODE
