esecuzione query - Dipartimento di Ingegneria dell`Informazione

Transcript

ESECUZIONE QUERY
• Decomposizione query
–
–
–
–
Normalizzazione
Analisi di correttezza
Eliminazione delle ridondanze
Ristrutturazione
• Localizzazione dei dati
– Programma di localizzazione
– Riduzioni per framm. orizzontale, verticale, derivata, ibrida
• Ottimizzazione query
– Modello di costo (funzione costo, statistiche database,
caratteristiche risultati intermedi)
– Spazio di ricerca e strategia di ricerca
– System R: ottimizzazione centralizzata e distribuita
– Ottimizzazione con semijoin
F.Cesarini - Basi Dati
Distribuite
esecuzione query
1
Decomp. query + Localizzazione dati
• I due passi Decomposizione query + Localizzazione dati
trasformano una query (SQL) su relazioni distribuite
in una query su frammenti di relazione
• La trasformazione effettua anche una sorta di
ottimizzazione che però è indipendente dalle
caratteristiche dei frammenti (p.es. cardinalità)
• Il terzo passo di Ottimizzazione cerca la strategia di
esecuzione migliore, cioè l’ordine migliore in cui le
operazioni possono essere eseguite
Distribuite
esecuzione query
2
1
Decomposizione query
•
•
•
Facciamo riferimento a query SQL; la query in input è supposta
sintatticamente corretta
Output: espressione in algebra relazionale ( operator tree ) che
specifica la query in modo semanticamente corretto e in modo da
evitare lavoro ridondante
I passi sono
–
–
–
–
Normalizzazione
Analisi di correttezza
Eliminazione delle ridondanze
Ristrutturazione
Distribuite
esecuzione query
3
Decomposizione query / normalizzazione
•
•
Trasformazione della WHERE in forma normalizzata, es. forma
normale congiuntiva
( p11 ∨ p12 … ∨ p1n ) ∧ … ∧ (pm1 ∨ pm2 … ∨ pmn )
Esempio
– SELECT Ename FROM EMP, ASG
WHERE EMP.Eno = ASG.Eno
AND ASG.Jno = ‘P1’ AND (Dur = 12 OR Dur = 24)
– Forma normale congiuntiva:
EMP.Eno=ASG.Eno ∧ ASG.Jno=‘P1’ ∧ (Dur=12 ∨ Dur=24)
– Forma normale disgiuntiva
(EMP.Eno=ASG.Eno ∧ ASG.Jno=‘P1’ ∧ Dur=12) ∨
(EMP.Eno=ASG.Eno ∧ ASG.Jno=‘P1’ ∧ Dur=24)
•
La forma normale congiuntiva in genere è più pratica di quella
disgiuntiva
Distribuite
esecuzione query
4
2
Decomp. query / analisi di correttezza
• Correttezza per i tipi
– Nomi di relazione o di attributo inesistenti
– Operatori non applicabili al tipo di attributo
• Ename > 200
• Correttezza dal punto di vista della semantica
– Nella query compaiono componenti che non
contribuiscono alla generazione del risultato
– Assenza della condizione di join
SELECT Ename, Resp
FROM EMP, ASG, PROJ
AND Jname=‘CAD/CAM’ AND Dur >16 AND
Title=‘Programmer’
Distribuite
esecuzione query
5
Dec. query / eliminazione delle ridondanze
•
Le query effettuate sulle viste vengono arricchite con i predicati
con cui le viste sono state definite, quindi il risultato può essere
ridondante
SELECT Title
FROM EMP
WHERE (NOT (Title=‘Programmer’)
AND (Title=‘Programmer’ OR Title=‘Elect.Eng.’)
AND NOT (Title=‘Elect.Eng.’))
OR Ename=‘P.Rossi’
(¬
¬p1 ∧ (p1 ∨ p2) ∧ ¬p2) ∨ p3
SELECT Title
FROM EMP
WHERE Ename = ‘P.Rossi’
Distribuite
esecuzione query
6
3
Decomposizione query / ristrutturazione
•
•
•
La query viene riscritta in algebra relazionale
Successivamente viene ristrutturata per migliorare le prestazioni
Semplice euristica:
– Applicare gli operatori unari (selezione/proiezione) il prima possibile
per ridurre la dimensione delle relazioni intermedie
•
Esempio
SELECT EMP.Ename
FROM PROJ, ASG, EMP
WHERE ASG.Eno = EMP.Eno
AND ASG.Jno = PROJ.Jno
AND EMP.Ename ≠ ‘J.Doe’
AND PROJ.Jname = ‘CAD/CAM’
AND (ASG.Dur =12 OR ASG.Dur = 24)
Distribuite
esecuzione query
7
RISTRUTTURAZIONE / ESEMPIO
πEname
σDur = 12 ∨ Dur = 24
σJname = ‘CAD/CAM’
σEname ≠ ‘J.Doe’
• Jno
• Eno
PROJ
Distribuite
ASG
EMP
esecuzione query
8
4
ALBERO RISTRUTTURATO
πEname
•
Jno
πJno, Ename
•
πJno
σJname = ‘CAD/CAM’
PROJ
Distribuite
πJno, Eno
Jno
πEno, Ename
σDur = 12 ∨ Dur = 24
σEname ≠ ‘J.Doe’
ASG
EMP
esecuzione query
9
Note all’esempio di ristrutturazione
•
•
Si ricordi che l’esecuzione del query tree è dalle foglie verso la
radice
Nell’esempio di ristrutturazione del query tree
– Le selezioni sono state avvicinate alle foglie
– Sono state introdotte delle proiezioni
•
•
Nell’espressione relazionale sono stati scambiati degli operatori e
introdotte delle operazioni
Manipolazione algebrica delle espressioni relazionali
– Ci sono regole (dimostrate formalmente) che possono essere applicate
– Proprietà commutativa di certi operatori, proprietà distributiva, …
•
La manipolazione algebrica delle espressioni relazionali è uno
degli strumenti che si hanno per l’ottimizzazione
Distribuite
esecuzione query
10
5
Localizzazione dei dati
•
Programma di localizzazione: un programma in algebra relazionale
che opera sui frammenti e ricostruisce la relazione globale da cui
sono stati generati i frammenti
– I frammenti sono stati generati con regole di frammentazione che
sono query relazionali
•
•
Supponiamo che i frammenti non siano replicati
Approccio naif per localizzare i dati distribuiti
– La query (che opera su relazioni globali) viene trasformata
sostituendo tutte le occorrenze di ogni relazione globale con il suo
programma di localizzazione
•
•
La query ottenuta (query generica) è inefficiente e necessita di
ristrutturazioni e semplificazioni
Possiamo considerare alcune regole di riduzione per ottimizzare la
query generica da applicare a seconda di come è stata ottenuta la
frammentazione
Distribuite
esecuzione query
11
Framm. Orizz. Primaria – riduzione con sel. (1)
•
•
•
•
Sia R frammentata in R1, … Rw con Ri = σpi R
Programma di localizzazione: R1 ∪ R2 … ∪ Rw
Inserendo il programma di localizzazione nell’albero di una query
che effettua una selezione ( ad es. con un predicato pi ) si possono
avere dei sottoalberi che generano relazioni vuote, questi vanno
eliminati
Regola 1
– σpi Rj = ∅ se ∀x in R : ¬ (pi (x) ∧ pj (x))
•
x indica una tupla
Esempio: si consideri la frammentazione
EMP1 = σEno ≤ ‘E3’ EMP
EMP2 = σ’E3’ < Eno ≤ ‘E6 EMP
EMP3 = σEno > ‘E6’ EMP
•
Il programma di localizzazione è
EMP = EMP1 ∪ EMP2 ∪ EMP3
Distribuite
esecuzione query
12
6
Framm. Orizz. Primaria – riduzione con sel. (2)
Query:
query globale
SELECT * FROM EMP WHERE Eno = ‘E5’
query generica
query ridotta
σEno = ‘E5’
σEno = ‘E5’
σEno = ‘E5’
∪
EMP
EMP1
Distribuite
EMP2
EMP3
EMP2
esecuzione query
13
Framm. Orizz. Primaria – riduzione con join (1)
•
•
La ristrutturazione e semplificazione dell’albero nel caso ci siano
join può avvenire utilizzando la regola distributiva dei join ed
unione, e eliminando i join inutili
Proprietà distributiva
– (R1 ∪ R2 ) • S = ( R1 • S ) ∪ ( R2 • S)
•
Regola 2 ( supponendo Ri e Rj definiti in accordo a pi e pj sullo
stesso attributo)
•
Invece del calcolo di un join possiamo avere due calcoli paralleli di
join parziali
La query generica può essere migliore quando i join parziali sono
molti (caso peggiore: ogni frammento di una relazione deve essere
messo in join con ogni frammento dell’altra)
La query ridotta può essere migliore se il numero di join parziali è
piccolo e possono essere eseguiti in parallelo
– Ri • Rj = ∅ se ∀x in Ri , ∀y in Rj : ¬(pi (x) ∧ pj (y))
•
•
Distribuite
esecuzione query
14
7
Framm. Orizz. Primaria – riduzione con join (2)
•
•
•
•
Esempio: EMP(Eno, Ename, Title)
EMP sia frammentata in
– EMP1 = σEno ≤ ‘E3’ EMP
– EMP2 = σ’E3’ < Eno ≤ ‘E6 EMP
– EMP3 = σEno > ‘E6’ EMP
ASG sia frammentata secondo
– ASG1 = σEno ≤ ‘E3’ ASG
– ASG2 = σEno > ‘E3’ ASG
Si abbia la query
SELECT *
FROM EMP, ASG
Distribuite
ASG(Eno, Jno, Dur)
esecuzione query
15
Query generica / Query ridotta
non vengono considerati i join che danno risultato vuoto
•
E no
∪
EMP1
EMP2
∪
EMP3
ASG1
ASG2
∪
•
EMP1
•
E no
ASG1
Distribuite
EMP2
•
E no
ASG2
EMP3
esecuzione query
E no
ASG2
16
8
Frammentazione verticale (1)
•
•
Per come si effettua una frammentazione verticale, il programma
di localizzazione effettua un join
Esempio: sia EMP frammentata secondo
– EMP1 = πEno, Ename EMP
– EMP2 = πEno, Title EMP
•
Il programma di localizzazione è
– EMP = EMP1 •
•
•
•
Eno
EMP2
Una query può essere ridotta esaminando se ci sono relazioni
intermedie inutili
⊆{A1, … An}
Sia R(A1, A2, … An) e Ri = πA’ R con A’⊆
Regola 3
– πD,K Ri è inutile se D non è contenuto in A’ (K è la chiave di R)
Distribuite
esecuzione query
17
Frammentazione verticale (2)
•
•
Si consideri la query
SELECT Ename FROM EMP
Si può osservare che la proiezione su EMP2 è inutile perché Ename
non è fra gli attributi di EMP2
query generica
πEname
•
EMP1
Distribuite
query ridotta
πEname
E no
EMP1
EMP2
esecuzione query
18
9
Frammentazione derivata (1)
•
Supponiamo che
– S sia frammentata in accordo a un predicato di selezione
– R sia in relazione di join con S in modo tale che ad ogni tupla di R
corrisponda una sola tupla di S, e che ad una tupla di S corrispondano
più tuple di R
– R sia frammentata in accordo con la frammentazione di S
– I frammenti di R siano allocati nello stesso sito dei frammenti
corrispondenti di S
•
La frammentazione derivata si ottiene con i semijoin, il
programma di localizzazione si basa sull’unione, quindi si possono
fare controlli analoghi a quelli visti prima
Distribuite
esecuzione query
19
•
Esempio:
–
–
–
–
•
EMP1 = σTitle = ‘programmatore’ EMP
EMP2 = σTitle ≠ ‘programmatore’ EMP
ASG1 = ASG • Eno EMP1
ASG2 = ASG • Eno EMP2
Programma di localizzazione:
– ASG = ASG1 ∪ ASG2
•
Query:
SELECT * FROM EMP, ASG
WHERE ASG.Eno = EMP.Eno AND Title = ‘Mech.Eng.’
•
Trasformazioni
– Abbassando le selezioni, il predicato è in conflitto con quello che ha
generato EMP1 , quindi EMP1 viene rimosso
– Proprietà distributiva del join sull’unione
– Il sottoalbero sinistro è un join che produce una relazione vuota per
come sono stati costruiti i frammenti
Distribuite
esecuzione query
20
10
query generica – query con selezioni abbassate
•
σTitle = ‘Mech.Eng.’
∪
ASG1
E no
∪
ASG2
EMP1
•
E no
∪
ASG1
EMP2
ASG2
EMP2
Distribuite
esecuzione query
21
query con selezioni abbassate – query con unione alzata
•
∪
ASG1
E no
ASG2
EMP2
∪
•
•
E no
ASG1
Distribuite
EMP2
E no
ASG2
esecuzione query
EMP2
22
11
query con unione alzata – query ridotta
∪
•
•
E no
E no
ASG1
EMP2
ASG2
•
EMP2
E no
ASG2
Distribuite
EMP2
esecuzione query
23
Frammentazione ibrida
•
Esempio
πEno, Ename EMP)
– EMP1 = σEno ≤ ‘E4’ (π
πEno, Ename EMP)
– EMP2 = σEno > ‘E4’ (π
– EMP3 = πEno, Title EMP
•
Programma di localizzazione
– EMP = (EMP1 ∪ EMP2) •
•
Eno
EMP3
Query
– SELECT Ename FROM EMP WHERE Eno = ‘E5’
•
Trasformazioni
– La selezione viene spinte in basso eliminando EMP1
– La proiezione viene spinta in basso eliminando EMP3
Distribuite
esecuzione query
24
12
Esempio di frammentazione ibrida
query generica – query ridotta
πEname
πEname
σEno = ‘E5’
•
σEno = ‘E5’
E no
EMP2
∪
EMP1
Distribuite
EMP2
EMP3
esecuzione query
25
Frammentazione ibrida: regole generali
•
Per la frammentazione ibrida si possono combinare le regole viste
per la frammentazione orizzontale primaria, frammentazione
verticale e frammentazione orizzontale derivata
– Rimuovere le relazioni vuote generate in contraddizione con le
selezioni usate per generare i frammenti orizzontali
– Rimuovere le relazioni che non servono, generate da proiezioni su
frammenti verticali
– Distribuire i join sulle unioni per isolare e rimuovere i join inutili
Distribuite
esecuzione query
26
13
OTTIMIZZAZIONE DI QUERY
DISTRIBUITE
•
•
•
•
•
•
L’obbiettivo è trovare l’ordinamento ottimo delle operazioni da
eseguire
Trovare la strategia ottima per l’esecuzione di una query è un
problema NP-hard nel numero di relazioni [ozvald99]
L’obbiettivo è quindi trovare una strategia vicina alla ottima, e
comunque evitare cattive strategie
La strategia prodotta dall’ottimizzatore viene chiamata strategia
ottima (anche se non lo è strettamente)
Output dell’ottimizzatore: query execution plan con query
algebriche su frammenti e operazioni di comunicazione
Verranno tipicamente considerate query con join, selezioni e
proiezioni
Distribuite
esecuzione query
27
Ottimizzazione query
• Viene prodotto un piano di esecuzione della query che
rappresenta una strategia di esecuzione della query
stessa.
• Il piano scelto minimizza una funzione costo obbiettivo
• L’ottimizzatore consiste di tre componenti
– Spazio di ricerca: è l’insieme di tutti i piani di esecuzione che
possono essere associati alla query; i piani sono equivalenti nel
senso che producono lo stesso risultato ma sono diversi per
l’ordine delle operazioni e/o per la loro implementazione
– Modello di costo: predice il costo di un piano di esecuzione
– Strategia di ricerca: esplora lo spazio di ricerca e sceglie il
piano migliore sulla base del modello di costo
Distribuite
esecuzione query
28
14
Modello di costo
• Il modello di costo si basa su funzioni di costo che
devono prendere in considerazione sia le operazioni
effettuate sia gli operandi a cui vengono applicate
(relazioni di base o loro parti e risultati intermedi)
• Abbiamo quindi
– Funzione di costo
– Statistiche sul data base (caratteristiche delle relazioni di base)
– Caratteristiche dei risultati intermedi
Distribuite
esecuzione query
29
Modello di costo / funzione di costo
•
•
•
Tipiche funzioni di costo considerate sono il tempo totale di
esecuzione e il tempo di risposta
Il tempo totale di esecuzione, come dice il termine, somma tutti i
tempi di esecuzione di tutte le operazioni effettuate
Il tempo di risposta invece può tener conto delle operazioni
effettuate in parallelo
Distribuite
esecuzione query
30
15
Modello di costo
Funzione di costo: tempo totale
TEMPO TOTALE DI ESECUZIONE
• Il tempo totale è la somma di tutti i tempi componenti
– Tempo di elaborazione locale
• Tempo di CPU per l’esecuzione delle istruzioni
• Tempo di I/O
– Tempo di comunicazione
• Tempo fisso per iniziare la trasmissione di un messaggio
• Tempo per la trasmissione dei dati
Total_time = TCPU × #instr + TI/O × # I/Os + Tmsg × #msgs + TTR × #bytes
•
Il tempo di comunicazione può essere considerato dominante nelle
Wide Area Networks (Internet), non nelle LAN, e comunque deve
essere fatto riferimento alla tecnologia attuale
Distribuite
esecuzione query
31
Modello di costo
Funzione di costo: tempo di risposta
TEMPO DI RISPOSTA
• È il tempo trascorso fra l’inizio e il completamento
della query
• Devono essere considerate le elaborazioni locali e le
comunicazioni effettuate in parallelo
Response_time =
TCPU × seq_#instr + TI/O × seq_# I/Os +
Tmsg × seq_#msgs + TTR × seq_#bytes
Dove seq_#x indica il massimo numero di x che devono essere
effettuati in sequenza per eseguire la query
Distribuite
esecuzione query
32
16
Modello di costo / Statistiche sul database
•
•
•
•
•
•
•
Elenchiamo i dati statistici più interessanti per una relazione
frammentata (se la relazione non è frammentata è immediato
ottenere le statistiche equivalenti)
Sia R(A1, … An)
frammentata in
R1, … Rr
∀ Ai , length( Ai ): lunghezza in byte dell’attributo
∀ Ai in Rj, card( πAi ( Rj )): numero di valori distinti di Ai in Rj
∀ Ai , card( dom (Ai )): numero di valori distinti del dominio di Ai
∀ Ai definito su un insieme di valori ordinati, min( dom (Ai ))
max( dom (Ai ))
∀ Rj , card( Rj ): numero di tuple in Rj
Distribuite
esecuzione query
33
Modello di costo
Cardinalità dei risultati intermedi (1)
•
•
•
Supponiamo che i valori di un attributo in una relazione abbiano
distribuzione uniforme (controesempio: città di residenza per gli
studenti iscritti all’Ateneo di Firenze)
Supponiamo che gli attributi siano indipendenti
Indichiamo con SFop il fattore di selettività (selectivity factor) della
operazione op, ad esempio per la selezione e il join abbiamo
SFS(F) = card (σ
σF (R)) / card(R)
SFJ (R, S) = card (R • S) / (card(R) × card(S))
Distribuite
esecuzione query
34
17
Modello di costo
SELEZIONE
(p(Ai) indica un predicato su Ai)
σF (R)) = SFS(F) × card(R)
card (σ
πA(R))
SFS(A=val) = 1 / card(π
SFS(A>val) = (max(A)-val) / (max(A)-min(A))
SFS(A<val) = (val-min(A)) / (max(A)-min(A))
SFS(p(Ai) ∧ p(Aj)) = SFS(p(Ai)) × SFS(p(Aj))
SFS(p(Ai) ∨ p(Aj)) = SFS(p(Ai)) + SFS(p(Aj)) –
(SFS(p(Ai)) × SFS(p(Aj)))
∈{values}) = SFS(A=val) × card({values})
SFS(A∈
Distribuite
esecuzione query
35
Modello di costo
PROIEZIONE
– È di difficile valutazione; nel caso che gli attributi di proiezione
includano la chiave si ha banalmente
πA(R)) = card(R)
card(π
PRODOTTO CARTESIANO
card(R × S) = card(R) × card(S)
JOIN
– Il limite superiore è la cardinalità del prodotto cartesiano
• Distributed INGRES usa questo valore (pessimistico)
• R* lo divide per una costante
– Nel caso in cui si abbia un equijoin fra la chiave A di R e una
chiave straniera B di S (riferita a A.R)
card(R • A=B S) = card(S)
Distribuite
esecuzione query
36
18
Spazio di ricerca – Strategia di ricerca
• Un piano di esecuzione è descritto da un operator tree,
arricchito della specifica dell’algoritmo usato per ogni
operazione
– Lo spazio di ricerca è quindi costituito dall’insieme di tutti i
possibili operator tree
• Euristica per limitare la dimensione dello spazio di
ricerca:
– Evitare i prodotti cartesiani se possibile
– Fare le selezioni e le proiezioni quando viene fatto accesso alle
relazioni di base (si fa un filtro sulla lettura)
Distribuite
esecuzione query
37
Esempio di euristica
dei tre alberi equivalenti, il terzo viene scartato
•
•
EMP
•
Pno
E no
ASG
Distribuite
•
PROJ
ASG
•
E no
Pno
EMP
PROJ
esecuzione query
E no,Pno
×
PROJ
ASG
EMP
38
19
Ott. query / centralizzato vs distribuito
•
•
•
•
•
I tre moduli di un ottimizzatore sono presenti sia in ambiente
centralizzato che distribuito
I dettagli dell’ambiente sono catturati dallo spazio di ricerca e dal
modello di costo
Conoscere le tecniche di ottimizzazione centralizzata è un
prerequisito per l’ottimizzazione distribuita per due motivi
– Una query distribuita è trasformata in query locali elaborate
in modo centralizzato
– Le tecniche di ottimizzazione distribuita sono spesso estensioni
delle tecniche per i sistemi centralizzati
L’ottimizzazione centralizzata è un problema più semplice della
distribuita poiché mancano i costi di comunicazione
La trattazione seguente si ispira all’approccio seguito dal System
R
Distribuite
esecuzione query
39
Ottimizzazione centralizzata (System R)
• Viene effettuata una ottimizzazione statica della query
basata su una ricerca esaustiva dello spazio delle
soluzioni
– Gli alberi candidati sono ottenuti permutando l’ordine dei join,
sulla base delle regole associativa e commutativa
• il numero degli alberi costruiti è ridotto utilizzando tecniche di
programmazione dinamica: quando due join sono equivalenti per
la commutatività, viene mantenuto quello di costo minore
– Viene associato un costo ad ogni albero candidato
• Il modello di costo considera sia il costo di CPU che di I/O
• Per la valutazione del costo della maggior parte degli operatori è
necessario sia conoscere le statistiche del database (p.es.
cardinalità delle relazioni di base) sia stimare quella dei risultati
intermedi (cfr. fattore di selettività degli operatori)
– Viene tenuto l’albero con costo minimo
Distribuite
esecuzione query
40
20
modello di costo
• Viene considerata una formula di costo per ciascuna
operazione di basso livello, p.es.
– Scansione sequenziale
– Selezione con predicato di range tramite un B-tree
• Le formule di costo si basano sulla cardinalità degli
operandi (tranne il match esatto)
– Statistiche sul database
– Stima dei risultati intermedi
Distribuite
esecuzione query
41
algoritmi di join
•
•
•
In un join fra R e S in cui viene prima letta R e poi trovate le tuple
di S che si accordano con quelle di R, R viene detta la relazione
esterna e S la relazione interna
Algoritmo nested loops: per ciascuna tupla della relazione esterna,
vengono trovate le tuple della interna che soddisfano il predicato
di join
– Se esiste un indice sulla relazione interna, viene utilizzato
– In assenza di indice l’algoritmo ha costo #pagR × #pagS
Algoritmo merge join: viene fatto il merge di due relazioni ordinate
sull’attributo di join
– Indici sull’attributo di join possono essere usati come cammino di
accesso
– Il costo dell’equijoin su relazioni ordinate è #pag R + #pagS
– Una relazione di n pagine può essere ordinata con un costo n log n
– Può convenire effettuare l’ordinamento se una relazione è grande
Distribuite
esecuzione query
42
21
algoritmo di ottimizzazione
•
•
•
Consideriamo “select-project-join” query
Per ciascuna relazione presente nella query viene scelto il metodo
di accesso migliore ad essa (considerata singolarmente)
Vengono considerate tutte le possibili permutazioni dei join
– Prima vengono considerati i join (a due) di ogni relazione con le altre
(scegliendo per ogni coppia l’algoritmo migliore), inoltre per la prima
relazione della coppia viene usato il metodo di accesso determinato nel
passo precedente
– Di ogni coppia viene fatto il join con una terza relazione, e così via
•
•
Viene scelta la strategia a costo minore
In realtà ad ogni passo se possibile viene scartata qualche
permutazione (il numero delle strategie esaminate è 2n invece che
n!)
– fra due join equivalenti per la commutatività viene mantenuto solo
quello a costo minore
– Vengono scartate le permutazioni con prodotti cartesiani
Distribuite
esecuzione query
43
algoritmo di ottimizzazione
System R optimization algorithm / simplified version [OZVAL99]
input: QT – query tree with n relations
output: output – the result of execution
begin
for each relation Ri ∈ QT do
begin
for each access path Apij to Ri do
determine cost(Apij) end-for
best_Api ← Apij with minimum cost
end-for
for each order (Ri1, Ri2, … Rin) with i=1, … n! do
begin
build strategy (… ((best APi1 • Ri2) • Ri3) • … Rin )
compute the cost of strategy
end-for
output ← strategy with minimum cost
end
Distribuite
esecuzione query
44
22
alg. ottimizzazione / esempio (1)
•
•
•
Query: si vuole il nome degli impiegati che lavorano al progetto
CAD/CAM
SELECT Emp.ename
FROM Emp, Asg, Proj
WHERE Emp.eno=Asg.eno AND Asg.jno=Proj.jno
AND jname = “CAD/CAM”
Supponiamo esistano i seguenti indici
– Emp:
– Asg:
– Proj:
•
un indice su eno
un indice su jno
un indice su jno
e un indice su jname
Supponiamo che il primo passo dell’algoritmo scelga i cammini di
accesso seguenti
– Emp: scansione sequenziale (perché non c’è selezione su Emp)
“
“
Asg
– Asg: scansione sequenziale “
– Proj: indice su jname (perché c’è una selezione su Proj.jname)
Distribuite
esecuzione query
45
EMP • ASG
pruned
PROJ
ASG
EMP
EMP × PROJ
ASG • EMP
ASG • PROJ
pruned
pruned
(ASG • EMP) • PROJ
Distribuite
PROJ • ASG
esecuzione query
PROJ × EMP
pruned
(PROJ • ASG) • EMP
46
23
•
•
•
•
Il numero di ordinamenti considerato è inferiore a 3!, infatti le
operazioni “ pruned” sono eliminate dinamicamente
Il primo livello dell’albero indica il metodo di accesso migliore per
una singola relazione
Il secondo livello indica per ogni relazione il metodo di join
migliore con ognuna delle altre
Di questi alcuni sono “pruned”
– I prodotti cartesiani possono essere evitati con altre strategie
– Altri due join vengono tagliati perché si suppone che il join
equivalente per la commutatività abbia costo minore
•
Al terzo livello abbiamo ora due possibilità: quello a destra ha
costo minore perché ha un indice su Proj utile per la selezione e
indici da utilizzare per i join
Distribuite
esecuzione query
47
•
Query: si vuole il nome degli impiegati che lavorano al progetto
CAD/CAM
SELECT Emp.ename
FROM Emp, Asg, Proj
WHERE Emp.eno=Asg.eno AND Asg.jno=Proj.jno AND jname=“CAD/CAM”
•
Supponiamo esistano i seguenti indici:
un indice su eno
– Emp:
un indice su jno
– Asg:
un indice su jno
e un indice su jname
– Proj:
•
Strategia scelta dall’ottimizzatore:
1 - Selezione su Proj usando l’indice su jname
2 - Join con Asg usando l’indice su jno
3 - Join con Emp usando l’indice su eno
Distribuite
esecuzione query
48
24
Ottimizzazione distribuita / R*
• L’algoritmo di ottimizzazione distribuita di R* è una
estensione di quello sviluppato per il System R
• L’algoritmo usa un approccio compilativo con una
analisi esaustiva di tutte le strategie
• L’obbiettivo è minimizzare il costo totale (tempo di
elaborazione locale con costo di I/O e CPU, dimensione
dei messaggi, numero di messaggi)
• Usa informazioni statistiche sui dati: cardinalità delle
relazioni e numero di valori unici per attributo
• La versione implementata di R* non supporta né
frammentazione né replicazione
Distribuite
esecuzione query
49
Ottimizzazione distribuita / R* (2)
• La compilazione della query è un task distribuito
coordinato da un master site, dove è iniziata la query
• L’ottimizzatore del master site prende le decisioni
“inter -site”, come ad esempio la scelta dei siti per
l’esecuzione e la modalità di trasferimento dati
• Gli apprentice sites, dove risiedono le altre relazioni
coinvolte nella query,prendono le altre decisioni locali,
come l’ordine dei join su quel sito, e generano piani di
accesso locali
• Poiché l’elaborazione locale è ottimizzata dal DBMS
locale, deve essere data opportuna attenzione alle
operazioni binarie che coinvolgono dati su siti diversi
Distribuite
esecuzione query
50
25
trasferimento dati
Trasferimento dati da un sito all’altro
•
•
•
•
•
Ship-whole: tutta la relazione è inviata al sito del join ed è
memorizzata in una relazione temporanea. Se l’algoritmo è il
merge join, la relazione non è memorizzata e le tuple vengono
elaborate in modo pipe line via via che arrivano
Fetch-as-needed: la relazione esterna viene scandita
sequenzialmente, per ciascuna tupla il valore di join viene inviato
al sito della relazione interna che invia indietro le tuple che
soddisfano il join.
Ship-whole genera trasferimenti di dati più grandi ma meno
messaggi del fetch-as needed
Ship-whole è conveniente quando le relazioni sono piccole
Fetch-as-needed è conveniente con relazioni grandi e buona
selettività del join
Distribuite
esecuzione query
51
strategie di join (1)
Strategie di join
R: relazione esterna, S: relazione interna, A: attributo di join
LT: local processing time (I/O+CPU), CT: communication time
il costo della produzione del risultato viene ignorato
s: numero medio di tuple di S che si accordano con una tupla di R
s = card( S • R) / card(R)
Strategia 1: tutta la relazione esterna viene inviata al sito della relazione
interna. Le tuple esterne possono essere messe in join con s via via
che arrivano
total_cost =
Distribuite
LT (retrieve card(R) tuple di R) +
CT (size(R)) +
LT (retrieve s tuple da S) × card(R)
esecuzione query
52
26
Strategia 2: l’intera relazione interna viene inviata al sito della relazione
esterna. Le tuple interne devono essere memorizzate in una relazione
temporanea T
total_cost =
LT (retrieve card(S) tuple da S) +
CT (size(S)) +
LT (store card(S) tuple in T) +
LT (retrieve card(R) tuple da R) +
LT (retrieve s tuple da T) × card(R)
Strategia 3: recupero delle tuple della relazione interna come necessario per
ciascuna tupla della esterna. Per ciascuna tupla di R, il valore
dell’attributo di join viene inviato al sito di S che invia indietro le s tuple
di S che si accordano con esso.
total_cost =
Distribuite
CT (length(A)) × card(R) +
LT (retrieve s tuple da S) × card(R) +
CT (s × length(S)) × card(R)
esecuzione query
53
Strategia 4: spostare ambedue le relazioni su un terzo sito e là calcolare
il join. Prima viene spostata la relazione interna sul terzo sito e
memorizzata in T. Poi viene spostata la relazione esterna e viene
fatto il join via via che le tuple arrivano
total_cost =
Distribuite
LT (retrieve card(S) tuple da S) +
CT (size(S)) +
LT (store card(S) tuple in T) +
CT (size(R)) +
LT (retrieve s tuple da T) × card(R)
esecuzione query
54
27
Ottimizzazione distribuita / R* - esempio
•
•
Join di PROJ (relazione esterna) con ASG (relazione interna)
sull’attributo Jno
PROJ e ASG sono memorizzate su siti diversi
ASG ha un indice su Jno
Le quattro strategie sono:
1 – Trasferimento di tutta PROJ al sito di ASG
2 – Trasferimento di tutta ASG al sito di PROJ
3 – Recupero delle tuple di ASG per ciascuna tupla di PROJ
4 – Spostamento di ASG e PROJ su un terzo sito
•
•
•
La 4 viene eliminata perché successivamente non c’è un terzo join
Se size(PROJ) è molto più grande di size(ASG), la 2 minimizza il costo di
comunicazione e può essere la migliore se il tempo di elaborazione locale
non è troppo alto rispetto a 1 e 3. Si noti il tempo di elaborazione locale di
1 e 3 è forse migliore di 2 perché può sfruttare l’indice.
Altrimenti la scelta è fra 1 e 3. Il costo locale è identico. Se PROJ è grande
e solo poche tuple di ASG si accordano, la 3 ha costo di comunicazione più
basso; altrimenti se PROJ è piccola e molte tuple di ASG vanno in join è
migliore la 1.
Distribuite
esecuzione query
55
Ottimizzazione distribuita / semijoin
•
•
•
L’ottimizzazione di R* fa parte dei metodi che non prendono in
considerazione i semi-join
Un’altra categoria di metodi si basa invece sull’utilizzo dei semijoin
R • AS
⇔ (R • A S) • A S
⇔ R • A ( S • A R)
⇔ ( R• AS) • A ( S • A R)
La prima di queste espressioni può essere calcolata come segue:
1 - πA(S) → sito 1
2 – calcolo sul sito 1 di R’ = R •
3 – R’ → sito 2
4 – calcolo sul sito 2 di R’ •
•
•
A
A
S
S
Si confronta con il calcolo del join effettuato trasferendo tutta R
Il tempo di trasmissione per i semijoin è minore se
size ( πA(S)) + size ( R •
Distribuite
A
S)
< size (R)
esecuzione query
56
28
Esempio [2]
SELECT Nome, Direttore FROM IMP, DIP
WHERE DIP.Sigla=IMP.Dipart AND IMP.Qual=‘Analista’ AND
DIP.Loc=‘Roma’
πDipart IMP) = card(π
πSigla DIP) = 40
card(IMP) = 2000 card(DIP) = 40 card(π
πQual IMP) = card(π
πLoc DIP) = 10 length(IMP) = 50
card(π
length(Dipart) = length(Sigla) = 5
card(IMP’ = σQual = ‘Analista’ IMP) = 200 card(DIP’ = σLoc = ‘Roma’ DIP) = 4
Costo di trasmissione
CT = c0 + c1 × qd dove
qd indica la quantità di dati trasferiti, c0 e c1 dipendono dalla rete
•
Strategia banale
– IMP’ viene trasferito in ND
CT = c0 + c1 × (card(IMP’) × length(IMP)) = c0 + c1 × 10000
Distribuite
esecuzione query
57
Esempio [2]
•
Strategia con semijoin
– Passo 1
esecuzione di πSigla DIP’ nel nodo ND con costo trasmissione nullo
– Passo 2
trasmissione di πSigla DIP’ ad NI con costo
costo = c0 + c1 × ( card(π
πSigla DIP’) × length(Sigla)) = c0 + c1 × 20
– Passo 3
esecuzione di IMP’ • Dipart= Sigla πSigla DIP’ in NI (costo trasm nullo)
– Passo 4
trasferimento del risultato a ND
Deve essere stimata la card del semijoin. Sia fSJ la frazione di tuple di
R che partecipano alla giunzione con S
fSJ ( R • X_R = X_S S) = card( πX_S S) / card (π
πX_R R) = 4/40 =0.1
costo = c0 + c1 × ( 0.1 × card(IMP’) × length(IMP)) = c0 + c1 × 1000
Distribuite
esecuzione query
58
29
Esempio [2]
•
Strategia con semijoin
– Passo 5
esecuzione del join in ND con costo di trasmissione nullo
Costo complessivo della strategia con semijoin
C = 2c0 + c1 × 1020
se c0 << c1 allora questo costo è inferiore a quello della strategia banale
Distribuite
esecuzione query
59
30

esecuzione query - Dipartimento di Ingegneria dell`Informazione

Transcript

Documenti analoghi

PIPERNO CASE Vende, permuta, acquista LA CASA

CREARE UNA QUERY DI ACCESS

INTRODUZIONE Motivazioni e Obbiettivi

Esercizi su IR e Web

Come creare Query in Active Directory per documentazione SOX

ACCa8_2013 Tabelle, Maschere e Query

MySQL Query Performance Optimization