NETEZZA APPLIANCE - di. · PDF fileNETEZZA APPLIANCE Danilo De Benedictis –[email protected] NETEZZA SQL –DAY 3

NETEZZA

APPLIANCEDanilo 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 sugliStorage 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 esegueun 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 full-

table-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 (multi-dimension) 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 ogniLOAD/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


TUTTE LE RIGHE DI T1 T1.AAA, T1.BBB SEMPRE VALORIZZATI

DOVE MATCH, LE RIGHE DI T2NOT 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


TUTTE LE RIGHE DI T2 T2.CCC SEMPRE VALORIZZATO

DOVE MATCH, LE RIGHE DI T1NOT 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} INTERSECT ALL

{1,2,2,3,5,5,N,N,N}

= {1,2,2,3,N,N}

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} EXCEPT ALL{1,2,2,3,5,5,N,N,N}

= {0,2,2}

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

NELLA COMBINE TRA TABELLE, NULL E’

TRATTATO UGUALMENTE AGLI ALTRI

VALORI:

(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: ACCESSO CONSENTITO ALLA VIEW

ACCESSO NON CONSENTITO ALLA TABELLA SOTTOSTANTE

DEFINITA INTERFACCIA VERSO APPLICATIVI, INVARIANTE ALLA STRUTTURA DATI 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 memorizzatesu una tabella fisica (su disco) con l’ordinamento richiesto.

Servono ad ottimizzare l’accesso a Tabellemolto grandi.


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à ordinatiottimizzazione utilizzo ZoneMaps

Ottimali se utilizzate per tabelle piccole (lookup)


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.


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;


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..


REGOLE PER CREAZIONE SPM:

La ORDER BY può essere applicata solo sucolonne presenti nella SELECT (projection list)

Se non è specificata la ORDER BY, l’ordinamento è uguale a quello della tabellabase

Non si può usare NULLS LAST o DESC nell’ORDER BY

La tabella base non può essere EXTERNAL, temporary oppure di sistema


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 è necessariofare un refresh della SPM, periodicamente.

Modifiche alla struttura della tabella base, invalidanola 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.


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 chereferenziano la SPM.


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


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)


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


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:

Se esistono, l’ottimizzatore decide se usarle in base al

predicted cost and performace.

Le SELECT sulle SPM possono richiedere più

memoria delle SELECT sulle tabelle base, a

causa delle righe un-sorted.


MIRRORING:

Le SPM vengono trattate su disco in maniera

analoga alle tabelle base. Quindi:

Il 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.


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.


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


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


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


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. Condizioneper 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 stessatabella baseCauserebbe 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 StoreID

FROM Stores S

WHERE 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.


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 ..


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...


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.


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 ???


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.


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 NZSQL1. Logging On

2. Risposta ai Command

3. Management delle Sessioni

4. Supporto SSL per i Client

5. Variabili SQL di Sessione

2. nzsql COMMANDS1. Input

2. Output

3. Options

4. Miscellaneous

5. Slash

6. Query Buffer

3. nzsql EXIT CODE

Documents

NETEZZA APPLIANCE - di. · PDF fileNETEZZA APPLIANCE Danilo De Benedictis –[email protected] NETEZZA SQL –DAY 3