Προχωρημένα Θέματα Τεχνολογίας και Εφαρμογών Βάσεων Δεδομένων Επεξεργασία και βελτιστοποίηση ερωτήσεων Πάνος Βασιλειάδης Σεπτέμβρης

2 Θεματολόγιο Γενικές αρχές της επεξεργασίας ερωτήσεων Parsing Βελτιστοποίηση ερωτήσεων: Επανεγγραφή ερωτήσεων Παραγωγή εναλλακτικών πλάνων Αποτίμηση πλάνων Πρόβλεψη μεγέθους Πολλές ευχαριστίες στους Γ. Ιωαννίδη, Τ. Σελλή, Ε. Πιτουρά για την επαναχρησιμοποίηση κειμένων/διαφανειών τους Οι εικόνες για την DB2 είναι από “DB2 Universal Optimizer” – παρουσίαση του G. Lohman

3 Θεματολόγιο Γενικές αρχές της επεξεργασίας ερωτήσεων Parsing Βελτιστοποίηση ερωτήσεων: Επανεγγραφή ερωτήσεων Παραγωγή εναλλακτικών πλάνων Αποτίμηση πλάνων Πρόβλεψη μεγέθους

4 Server processes : και τι γίνεται εκεί?

5 Επεξεργασία ερωτήσεων Οι clients θέτουν μια ερώτηση SQL στο server Χαρακτηριστικά: δηλωτική γλώσσα + το μόνο που πρέπει να ξέρει ο χρήστης είναι ονόματα πινάκων και γνωρισμάτων To DBMS μέσω της server process κάνει τα εξής: Parsing Έλεγχο συντακτικής ορθότητας Σύνθεση ενός αλγεβρικού πλάνου εκτέλεσης (μέσω ενός δέντρου τελεστών) Εκτέλεση του πλάνου και επιστροφή του αποτελέσματος

6 Επεξεργασία ερωτήσεων Query Parser Query Optimizer Query Processor SQL Εσωτερική αναπαράσταση Αλγεβρικό [φυσικό] πλάνο (procedural) Επιστροφή αποτελέσματος

7 Επεξεργασία ερωτήσεων Query Parser Query Optimizer Query Processor SQL Εσωτερική αναπαράσταση Αλγεβρικό [φυσικό] πλάνο (procedural) Επιστροφή αποτελέσματος

8 Παράδειγμα Ερώτησης SELECT DISTINCT q1.partno, q1.descr, q2.suppno FROM inventory q1, quotations q2 WHERE q1.partno = q2.partno AND q1.descr = 'engine' AND q2.price <= ALL ( SELECT q3.price FROM quotations q3 WHERE q2.partno = q3.partno ); Query blocks

9 Query Graph Model

10 Επεξεργασία ερωτήσεων Query Parser Query Optimizer Query Processor SQL Εσωτερική αναπαράσταση Αλγεβρικό [φυσικό] πλάνο (procedural) Επιστροφή αποτελέσματος

11 Επεξεργασία ερωτήσεων Δοθέντος του πλάνου, κάθε λογικός τελεστής (π.χ., σ, π,  ) έχει περισσότερους του ενός τρόπους να εκτελεστεί φυσικά (δηλ., στην πράξη). Στην προηγούμενη διάλεξη εξετάσαμε τέτοιους διαφορετικούς φυσικούς τρόπους εκτέλεσης για τους πιο σημαντικούς τελεστές της σχεσιακής άλγεβρας.

12 Επεξεργασία ερωτήσεων Query Parser Query Optimizer Query Processor SQL Εσωτερική αναπαράσταση Αλγεβρικό [φυσικό] πλάνο (procedural) Επιστροφή αποτελέσματος

13 Αφαιρετική δομή του βελτιστοποιητή Rewriter Planner “Δηλωτική” Βελτιστοποίηση “Διαδικαστική” Βελτιστοποίηση Αλγεβρικός χώρος Μέθοδοι Προσπέλασης Μοντέλο κόστους Αποτίμηση μεγέθους αποτελέσματος Κατασκευή πιθανών πλάνωνΑποτίμηση παραγόμενων πλάνων

14 Επίπεδα βελτιστοποίησης Υπάρχει ένα επίπεδο «δηλωτικής» βελτιστοποίησης, ή επανεγγραφής, όπου παράγουμε λογικά ισοδύναμους τρόπους να εκφράσουμε μια ερώτηση μέσω του rewriter select * from emp where emp.dno in (select dept.dno from dept) and sal > 100K select name,age,sal,ndo from emp, dept where emp.dno = dept.dno and sal > 100K

15 Επίπεδα βελτιστοποίησης Υπάρχει ένα επίπεδο «διαδικαστικής» βελτιστοποίησης, όπου παράγουμε (όλα τα) διαφορετικά πλάνα εκτέλεσης μέχρι να διαλέξουμε το πιο αποδοτικό. Η δουλειά αυτή ανατίθεται στον planner. Ο planner οφείλει: Να αποφασίσει ποια πλάνα εκτέλεσης θα δημιουργηθούν Ποιο εξ αυτών είναι το καλύτερο

16 Θεματολόγιο: Επανεγγραφή Rewriter Planner “Δηλωτική” Βελτιστοποίηση “Διαδικαστική” Βελτιστοποίηση Αλγεβρικός χώρος Μέθοδοι Προσπέλασης Μοντέλο κόστους Αποτίμηση μεγέθους αποτελέσματος Κατασκευή πιθανών πλάνωνΑποτίμηση παραγόμενων πλάνων

17 Επίπεδα βελτιστοποίησης Υπάρχει ένα επίπεδο «δηλωτικής» βελτιστοποίησης, ή επανεγγραφής, όπου παράγουμε λογικά ισοδύναμους τρόπους να εκφράσουμε μια ερώτηση μέσω του rewriter Αυτό συμπεριλαμβάνει, συνήθως: Μετατροπή εκφράσεων σε «βολική» μορφή Απλοποίηση εμφωλευμένων ερωτήσεων Σημασιολογικά έξυπνες μετατροπές

18 Ισοδυναμίες της σχεσιακής άλγεβρας ( Commute ) Προβολή: (Cascade) Σύνδεση: R (S T) (R S) T (Associative) (R S) (S R) (Commute) R (S T) (T R) S + Δ.Ο.: (Cascade) Επιλογή:

19 Σύνθετες ισοδυναμίες σ θ (π Α (R))  π Α (σ θ (R)), αρκεί τα πεδία που εμπλέκονται στη συνθήκη θ να είναι υποσύνολο των πεδίων του Α σ θ (R  S)  (R  θ S), αρκεί τα πεδία που εμπλέκονται στη συνθήκη θ να είναι από τις σχέσεις R και S σ θ (R  S)  σ θ (R)  S, αρκεί τα πεδία που εμπλέκονται στη συνθήκη θ να είναι αποκλειστικά της R π Α (R  S)  π Α’ (R)  S, με την Α’ να περιέχει (α) τα πεδία που είχε η Α (αρκεί να είναι αποκλειστικά της R) και (β) τα πεδία που εμπλέκονται στη συνθήκη σύνδεσης Δ.Ο. ισχύουν τα παραπάνω…

20 Επανεγγραφή Ερωτήσεων (παράδειγμα από IBM DB2) Distribute NOT... WHERE NOT(COL1 = 10 OR COL2 > 3) γίνεται... WHERE COL1 <> 10 AND COL2 <= 3 Μετασχηματισμοί τιμών:...WHERE COL = YEAR(` ') γίνεται... WHERE COL = 1994 Μεταβατική κλειστότητα δοθέντος: T1.C1 = T2.C2, T2.C2 = T3.C3, T1.C1 > 5 προστίθενται... T1.C1 = T3.C3 AND T2.C2 > 5 AND T3.C3 > 5

21 Αφαιρετική δομή του βελτιστοποιητή Rewriter Planner “Δηλωτική” Βελτιστοποίηση “Διαδικαστική” Βελτιστοποίηση Αλγεβρικός χώρος Μέθοδοι Προσπέλασης Μοντέλο κόστους Αποτίμηση μεγέθους αποτελέσματος Κατασκευή πιθανών πλάνωνΑποτίμηση παραγόμενων πλάνων

22 Επίπεδα βελτιστοποίησης Υπάρχει ένα επίπεδο «διαδικαστικής» βελτιστοποίησης, όπου παράγουμε (όλα τα) διαφορετικά πλάνα εκτέλεσης μέχρι να διαλέξουμε το πιο αποδοτικό. Η δουλειά αυτή ανατίθεται στον planner. Ο planner οφείλει: Να αποφασίσει ποια πλάνα εκτέλεσης θα δημιουργηθούν Ποιο εξ αυτών είναι το καλύτερο

23 Ο planner οφείλει... Να κατασκευάσει ένα σύνολο πλάνων, με βάση Ένα αλγεβρικό χώρο για τη σειρά εκτέλεσης των λειτουργιών (π.χ., να αποφασίσει με ποια σειρά θα κάνει το R  S  T) Ένα σύνολο από μεθόδους προσπέλασης στα δεδομένα (π.χ., full- index scan, full table scan, …) Να αποτιμά κάθε πλάνο που παράγει, μέχρι στο τέλος να βρει το πιο αποδοτικό, με βάση Ένα μοντέλο κόστους που προβλέπει πόσο χρόνο/disk I/O/… κοστίζει το κάθε πλάνο Ένα μοντέλο πρόβλεψης του μεγέθους, κυρίως των ενδιάμεσων αποτελεσμάτων Προσοχή: η αποτίμηση είναι πάντα προσέγγιση/πρόβλεψη και όχι ακριβής υπολογισμός...

24 Υποθέσεις... Θα κάνουμε τις εξής υποθέσεις εργασίας (που αφορούν πρακτικά το σύνολο των DBMS) σε ότι αφορά τις εναλλακτικές λύσεις που θα εξετάσουμε: Οι μέθοδοι προσπέλασης που έχουμε είναι (α) πλήρες διάβασμα ενός πίνακα (β) προσπέλαση μέσω ενός Β+ ευρετηρίου Οι μέθοδοι σύνδεσης που έχουμε είναι (α) nested loops και (β) merge-join, στα οποία χρησιμοποιούμε και των δύο ειδών τις μεθόδους προσπέλασης

25 Σύνδεση με Nested Loops Για κάθε D  Dept [& Dname=‘Toys’] Για κάθε E  Emp Αν ταιριάζουν στο πεδίο Dno Τότε επέστρεψε E.ename, D.mgr Ερώτηση κρίσεως: το Dept ή το Emp πρέπει να βγει ως η εξωτερική σχέση? SELECT E.ename, D.mgr FROM Emp E, Dept D WHERE D.dname=‘Toys’ AND E.dno=D.dno

26 Σύνδεση με Merge-Join Ταξινόμησε τα Emp, Dept με βάση το πεδίο Dno Για κάθε D  Dept [& Dname=‘Toys’] Για κάθε E  Emp με ίδιο Dno Επέστρεψε E.ename, D.mgr SELECT E.ename, D.mgr FROM Emp E, Dept D WHERE D.dname=‘Toys’ AND E.dno=D.dno

27 Αλγεβρικός χώρος: τι είναι ένα πλάνο Το πλάνο εκτέλεσης μιας SQL ερώτησης είναι ένα δέντρο, με: Τις σχέσεις που συμμετέχουν στην ερώτηση, για φύλλα Αλγεβρικούς τελεστές για ενδιάμεσους κόμβους και συγκεκριμένα τους π, σ και  Το πλάνο έχει σειρά εκτέλεσης από κάτω και αριστερά προς τα πάνω. Κοιτώντας ένα ενδιάμεσο κόμβο, ξέρουμε ότι τα παιδιά του έχουν εκτελεστεί και αυτός στέλνει το αποτέλεσμα προς τα πάνω

28 Πλάνα εκτέλεσης select name, floor from emp, dept where emp.dno = dept.dno and sal > 100K

29 Πλάνα εκτέλεσης Για μια απλή SELECT-FROM-WHERE ερώτηση SQL, ο αριθμός των ισοδύναμων εναλλακτικών πλάνων είναι τεράστιος. Υπάρχουν κάποιοι λογικοί κανόνες, που επιτρέπουν στον βελτιστοποιητή να μειώσει τον αλγεβρικό χώρο πλάνων

30 Λογικοί κανόνες βελτιστοποίησης Σπρώξε όλες τις επιλογές όσο πιο χαμηλά στο δέντρο γίνεται Ενσωμάτωσε τις προβολές μέσα στους άλλους τελεστές... και πάλι όμως, ο αλγεβρικός χώρος παραμένει τεράστιος...

31 Λογικοί κανόνες βελτιστοποίησης Η βασική αιτία είναι οι ιδιότητες της σύνδεσης: R  S  S  R (R  S)  Τ  R  ( S  Τ ) Το αποτέλεσμα είναι ότι για Ν σχέσεις στο FROM clause έχω Ν! διατάξεις... Επιπλέον κανόνας: Ποτέ μην κάνεις καρτεσιανά γινόμενα, εκτός κι αν πρέπει...

32 Ποτέ μην κάνεις καρτεσιανά γινόμενα ΠΡΟΣΟΧΗ! select name, floor, balance from emp, dept, acnt where emp.dno = dept.dno and dept.ano = acnt.ano

33 Αριστεροβαθή Δέντρα Ακόμα και τώρα όμως, ο αλγεβρικός χώρος είναι μεγάλος Όλα τα σύγχρονα DBMS έχουν εισάγει τον ακόλουθο πρακτικό κανόνα: Η εσωτερική σχέση ενός τελεστή είναι ΠΑΝΤΑ μια σχέση της ΒΔ και ποτέ ενδιάμεσο αποτέλεσμα! Τα δέντρα που προκύπτουν έτσι, λέγονται αριστεροβαθή (left-deep)

34 Αριστεροβαθές πλάνο Δεξιοβαθές πλάνο Θαμνώδες (bushy) πλάνο Selectname, floor, balance, bank from emp,dept,acnt,bank where emp.dno = dept.dno and dept.ano = acnt.ano and acnt.bno = bank.bno

35 Αριστεροβαθή Δέντρα Κέρδη από αριστεροβαθή δέντρα: Μπορούμε εύκολα να χρησιμοποιούμε ευρετήρια για τις σχέσεις! Τα αποτελέσματα από μια σύνδεση μπορούν να γίνουν pipeline σε μια επόμενη σύνδεση! Ερώτηση κρίσεως: Γιατί??

36 Ωραία, και με ποια σειρά? Ακόμα δεν μας είπες για τη σειρά των συνδέσεων! (R  S)  Τ  R  ( S  Τ ) Ο planner, σε όλα τα εμπορικά DBMS χρησιμοποιεί ένα αλγόριθμο δυναμικού προγραμματισμού για να ανακαλύψει τη σειρά

37 Selinger et al, SIGMOD 1979 Selinger, Astrahan, Chamberlain, Lorie & Price: "Access Path Selection in a Relational Database Management System." SIGMOD Conference 1979: Για την ακρίβεια, το τρίτο πιο cited database paper, μετά το ER και το σχεσιακό μοντέλο...

38 Επεξεργασία μιας SQL εντολής Parsing Optimization Code generation Execution

39 Code generation “translates ASL trees into machine language code to execute the plan chosen by the OPTIMIZER. In doing this Uses a relatively small number of code templates, one for each type of join method (including no join). Nested queries are treated as "subroutines" which return values to the predicates in which they occur. During code generation, the parse tree is replaced by executable machine code and its associated data structures. Either control is immediately transfered to this code or the code is stored away in the database for later execution, depending on the origin of the statement

40 Code Execution “ … when the code is ultimately executed, it calls upon the System R internal storage system (RSS) via the storage system interface (RSI) to scan each of the physically stored relations in the query…”

41 Storage manager: the Research Storage System (RSS) O Storage Manager (στο System R, RSS) είναι υπεύθυνος για Την αποθήκευση των δεδομένων Την προσπέλαση των δεδομένων (access paths) Locking Logging

42 Storage manager: the Research Storage System (RSS) Αποθήκευση των δεδομένων Πίνακες: σύνολα πλειάδων(tuples). Κάθε πλειάδα είναι σύνολο συνεχόμενων γνωρισμάτων. Pages: 4K, περιέχουν πλειάδες Segment: οι πλειάδες ενός πίνακα πέφτουν μέσα σε ένα segment Προσπέλαση των δεδομένων (access paths) Segment scans: φέρε μου όλες τις πλειάδες ενός πίνακα Index scan, μέσω Β+ δέντρων

43 Storage manager: the Research Storage System (RSS) Πόσες φορές προσπελάζω μια σελίδα? Segment scan: ακριβώς μία Index scan: κάθε σελίδα του index την προσπελάζω ακριβώς μία φορά – για τις σελίδες του πίνακα αυτό δεν είναι σαφές Clustered index: αν οι εγγραφές του πίνακα εγγράφονται στο δίσκο με την ίδια σειρά που έχει και ο index

44 Storage manager: the Research Storage System (RSS) Και τι εύρος του index ψάχνω? Ανάλογα με το τι ερώτηση κάνεις... Search arguments (SARGS): σύνολο συνθηκών που αν τις αποτιμήσω σε μια πλειάδα, μου επιστρέφουν true/false Π.χ., SAL > 30K AND AGE < 35 Αν έχω ένα index πάνω στα SAL,AGE με συμφέρει... ΠΡΟΣΟΧΗ: τα SARGS αφορούν κλήσεις στο δίσκο για σελίδες!

45 Storage manager: the Research Storage System (RSS) “The primary way of accessing tuples in a relation is via an RSS scan. A scan returns a tuple at a time along a given access path. OPEN, NEXT, and CLOSE are the principal commands on a scan.”

46 Αρχιτεκτονική System R Relational Data System (RDS) Research Storage System (RSS) Λειτουργεί σε επίπεδο tuples Λειτουργεί σε επίπεδο pages Disk NEXT() = getNextTuple(EMP) getNextPage(EMPsegment) RSI SELECT * FROM EMP

47 Μοντέλο κόστους “The OPTIMIZER examines both the predicates in the query and the access paths available on the relations referenced by the query and formu1ates a cost prediction for each access plan, using the following formula:” COST = PAGE FETCHES + W * (RSI CALLS) RSI Calls: πόσες πλειάδες θα χρειαστεί να επεξεργαστεί το λογικό επίπεδο RDS W: scale factor

48 Μοντέλο κόστους For each relation T, NCARD(T) the cardinality of relation T = πόσες εγγραφές έχει TCARD(T) the number of pages in the segment that hold tuples of relation T = πόσες σελίδες έχει το segment της Τ. P(T), the fraction of data pages in the segment that hold tuples of relation T. P(T) = TCARD(T1 / (no. of non-empty pages in the segment). For each index I on relation T, ICARD(Ι) number of distinct keys in index I. NINDX(I) the number of pages in index I. Για κάθε συνθήκη επιλογής: selectivity F = the expected fraction of tuples which will satisfy the predicate. Η F υπολογίζεται ως ακολούθως...

49

50 Μοντέλο κόστους Query cardinality (QCARD) : εκτίμηση των πόσων πλειάδων θα προκύψουν από ένα query στις σχέσεις T i με F j selectivities για κάποιους Boolean factors j QCARD = Π NCARD(T i ) * Π Fj The number of expected RSI calls (RSICARD) = πόσες πλειάδες θα κάνω τελικά process RSICARD = Π NCARD(T i ) * Π Sj με S j selectivities of the sargable boolean factor

51 Interesting Order Using an index access path or sorting tuples produces tuples in the index value or sort key order. We say that a tuple order is an interesting order if that order is one specified by the query block's GROUP BY or ORDER BY clauses. Αν δεν υπάρχει κάποια ταξινόμηση στο query, τότε λαμβάνουμε υπ’ όψη και την «μη ταξινόμηση» ως πιθανή interesting order Επίσης, interesting order συνιστούν και τα πεδία που συμμετέχουν σε ένα join T1.attr1 = T2.attr2

52 Cost for single-relation queries Αν δεν υπάρχει group-by/order by: Το κόστος του πιο φτηνού από τα διαθέσιμα access paths Αλλιώς, το min cost ανάμεσα σε: Κόστος του access path με το σχετικό interesting order Κόστος του access path χωρίς interesting order + κόστος ταξινόμησης QCARD πλειάδων Και ποιες είναι οι φόρμουλες για τα access paths?

53 Cost for single-relation queries

54 Multi-relation queries: joins! Εκτός από τα single-relation queries, δεν εξετάσαμε τα multi-relation queries, που πρακτικά είναι τα queries με joins. Αυτό που δεν έχουμε δει ακόμα είναι η σειρά των συνδέσεων! Π.χ., ποια είναι η σειρά στην ερώτηση (R  S)  Τ, δοθέντος ότι: (R  S)  Τ  R  ( S  Τ ) Ο planner, σε όλα τα εμπορικά DBMS χρησιμοποιεί ένα αλγόριθμο δυναμικού προγραμματισμού για να ανακαλύψει τη σειρά

55 Δυναμικός προγραμματισμός Εφαρμόζεται σε προβλήματα, στα οποία η λύση μπορεί να εκφρασθεί ως μια ακολουθία αποφάσεων Εκμεταλλεύεται το principle of optimality: μια ακολουθία αποφάσεων (λύση) δεν μπορεί να είναι βέλτιστη, αν μια υπακολουθία της δεν είναι βέλτιστη αβγ

56 Δυναμικός προγραμματισμός για επεξεργασία ερωτήσεων R1R2  R3  Ri  Βήμα 2 Βήμα 3... Βήμα i Εν παραλλήλω, φτιάχνω πολλά δέντρα. Σιγά σιγά όμως, μειώνω τον αριθμό τους...

57 Βασικές υπενθυμίσεις/υποθέσεις του άρθρου Από το 1976, οι Blasgen & Eswaran είχαν δείξει πειραματικά ότι το nested loops και το merge-join είναι πολύ κοντά στο optimal πλάνο για οποιοδήποτε join Τα Ν-way joins αποτιμώνται με βάση κάποια αριστεροβαθή δέντρα Δεν εξετάζουμε καρτεσιανά γινόμενα, και σπρώχνουμε τις επιλογές όσο πιο χαμηλά γίνεται στο δέντρο

58 Interesting orders again Ομαδοποιούμε τα joins με βάση το interesting order των πλειάδων που παράγονται Ορίζουμε κλάσεις ισοδυναμίας για τα interesting orders, π.χ., αν E.DNO = D.DNO AND D.DNO = F.DNO τότε τα τρία γνωρίσματα ανήκουν στην ίδια interesting order Κατασκευάζουμε ένα χώρο λύσεων που, ως ακολουθία αποφάσεων, είναι και αυτός ένα δέντρο: κάθε κόμβος του δέντρου, σε βάθος i είναι ένα πλάνο με i το πλήθος joins Για κάθε interesting order, κάθε φορά, κρατάμε το πιο φτηνό πλάνο

59 Δυναμικός προγραμματισμός για επεξεργασία ερωτήσεων Πρόβλημα: ποια η σωστή σειρά για να εκτελέσω το R 1  R 2  …  R n ? 1. Θα βρω όλους τους τρόπους για να προσπελάσω κάθε σχέση χωριστά 2. Θα πάρω κάθε τέτοιο τρόπο προσπέλασης και θα φτιάξω το καλύτερο υποδέντρο με δύο φύλλα που αντιστοιχεί σε κάθε interesting order. 3. Θα πάρω κάθε τέτοιο υποδέντρο και θα φτιάξω το καλύτερο υποδέντρο με τρία φύλλα που αντιστοιχεί σε κάθε interesting order 4. Ο αλγόριθμος τελειώνει στο δέντρο με n-joins και επιστρέφει το φθηνότερο πλάνο (ανάλογα με το order, μπορεί να χρειαστεί και μια επιπλέον ταξινόμηση στο τέλος) Ο αριθμός λύσεων είναι 2^n * αρ. interesting orders. To pruning, όμως το μειώνει σημαντικά

60 Kossmann, CSUR 32(4), 2000

61 Παράδειγμα

62 Παράδειγμα

63 Παράδειγμα

64 Παράδειγμα

65 Παράδειγμα

66 Cost formulae C-outer(path1)/ C-inner(path2) : cost of scanning the outer/inner relation via pathl/path2 N: the cardinality (number) of the outer relation tuples which satisfy the applicable predicates. Then, the cost for the NL join and the merge part of the MJ join is: c-join(pathl,path2) = C-outer(path1) + N * C-inner(path2) The difference between nested-loops and merge join is in the access paths followed each time, with the inner scan being possibly cheaper for merge-join

67 Nested queries Αν δεν υπάρχει correlation, κάνουμε πρώτα το nested query και μετά χρησιμοποιούμε το αποτέλεσμά του για να αποτιμήσουμε το εξωτερικό query Αν υπάρχει correlation, τότε για κάθε tuple του εξωτερικού query τρέχουμε το εσωτερικό query ξανά

68 Nested queries SELECT NAME FROM EMPLOYEE WHERE DEPARTMENT-NUMBER IN (SELECT DEPARTMENT-NUΜBER FROM DEPARTMENT WHERE LOCATION='DENVER‘) SELECT NAME FROM EMPLOYEE X WHERE SALARY > (SELECT SALARY FROM EMPLOYEE WHERE EMPLOYEE-NUMBER = X.MANAGER) SELECT NAME FROM EMPLOYEE WHERE DEPARTMENT-NUMBER IN {12, 14, 143} Για κάθε Χ, τρέχω το έσω query

69 Τώρα κάνουμε κάτι καλύτερο (παράδειγμα από IBM DB2) Αρχική Ερώτηση SELECT PS_SUPPLYCOST FROM PARTSUPP WHERE PS_PARTKEY <> ALL (SELECT L_PARTKEY FROM LINEITEM WHERE PS_SUPPKEY = L_SUPPKEY) Μετασχηματισμένη Ερώτηση SELECT PS_SUPPLYCOST FROM PARTSUPP WHERE NOT EXISTS (SELECT * FROM LINEITEM WHERE PS_SUPPKEY = L_SUPPKEY AND PS_PARTKEY = L_PARTKEY)

70 Επανάληψη Rewriter Planner “Δηλωτική” Βελτιστοποίηση “Διαδικαστική” Βελτιστοποίηση Αλγεβρικός χώρος Μέθοδοι Προσπέλασης Μοντέλο κόστους Αποτίμηση μεγέθους αποτελέσματος Κατασκευή πιθανών πλάνωνΑποτίμηση παραγόμενων πλάνων R1R2  R3 

71 Appendix Ιστογράμματα Από ΙΒΜ DB2

72 Εκτίμηση μεγέθους Για να δουλέψουν οι φόρμουλες κόστους που έχουμε, πρέπει να μπορούμε να αποτιμήσουμε το μέγεθος των ενδιάμεσων αποτελεσμάτων Εν γένει, δεν είμαστε πολύ καλοί σ’ αυτό, πρακτικά οι τρόποι εκτίμησης που έχουμε δουλεύουν σε δέντρα με ύψος πάνω από 5... Η πιο καλή τεχνική που έχουμε είναι τα ιστογράμματα

73 Ιστογράμματα Σ’ ένα ιστόγραμμα, διαιρούμε το εύρος των τιμών ενός πεδίου σε κάδους (αγγλιστί: buckets) Για κάθε τιμή που παίρνει το πεδίο, μετράω τον αριθμό που αυτή εμφανίζεται age # εμφανίσεων # εμφανίσεων Ιστόγραμμα με 3 κάδους

74 Ιστογράμματα Και πώς αποφασίζω πόσους κάδους? Ιστογράμματα ίσου πλάτους: κάθε κάδος έχει τον ίδιο αριθμό τιμών στον άξονα των x Ιστογράμματα ίσου ύψος: κάθε κάδος έχει το ίδιο ύψος στον άξονα των y Σειριακά ιστογράμματα: οι συχνότητες ενός κάδου είναι μεγαλύτερες από αυτές του προηγούμενου

75 Ιστογράμματα Αν κάνω μια επιλογή σ age > 43 (emp) το DBMS μπορεί να εκτιμήσει περίπου πόσες εγγραφές θα μου επιστραφούν Αντίστοιχα, αν κάνω μια σύνδεση R  S πάλι μπορεί να κάνει την αντίστοιχη εκτίμηση ανά ζεύγος κάδων.

76 Ιστογράμματα Είναι σαφές ότι όσο πιο πολλές πράξεις, τόσο πιο πολύ απομακρύνεται η εκτίμηση από την πραγματικότητα... (Λανθασμένες) Υποθέσεις εργασίας: οι τιμές των πεδίων είναι ισοπίθανα μοιρασμένες + τα πεδία είναι ανεξάρτητα μεταξύ τους... Και τι γίνεται όταν έχω INS/DEL/UPD ?

77 NameSalaryDepartment Zeus100KGeneral Manager Poseidon80KDefense Pluto80KJustice Aris50KDefense Ermis60KCommerce Apollo60KEnergy Hefestus50KEnergy Hera90KGeneral Manager Athena70KEducation Aphro60KDomestic Affairs Demeter60KAgriculture Hestia50KDomestic Affairs Artemis60KEnergy Department Frequency General Manager2 Defense2 Education1 Domestic Affairs2 Agriculture1 Commerce1 Justice1 Energy3 Ιστογράμματα

78 Ιστογράμματα Department Απόλυτη Συχνότητα Συχνότητα Κάδου Agriculture11.50 Commerce11.50 Defense21.50 Domestic Affairs21.50 Education11.75 Energy31.75 General Manager21.75 Justice11.75 Ιστόγραμμα ίσου πλάτους: κάθε κάδος έχει τον ίδιο αριθμό τιμών στον άξονα των x Εδώ: δύο κάδοι, ο πρώτος από A – D και ο άλλος από E-Z Συχν. Κάδου: Σ(x)/count(x), x  κάδο #πραγματικών εμφανίσεων εκτίμηση ιστογράμματος

79 Ιστογράμματα Department Απόλυτη Συχνότητα Συχνότητα Κάδου Agriculture11.33 Commerce11.33 Defense21.33 Education11.33 General Manager21.33 Justice11.33 Domestic Affairs22.50 Energy32.50 Ιστόγραμμα σειριακό: οι συχνότητες του δεύτερου κάδου είναι μεγαλύτερες από αυτές του πρώτου #πραγματικών εμφανίσεων εκτίμηση ιστογράμματος

80 Appendix Ιστογράμματα Από ΙΒΜ DB2

81 Δομή του optimizer της IBM DB2

82 Επανεγγραφή Ερωτήσεων (παράδειγμα από IBM DB2) Distribute NOT... WHERE NOT(COL1 = 10 OR COL2 > 3) γίνεται... WHERE COL1 <> 10 AND COL2 <= 3 Μετασχηματισμοί τιμών:...WHERE COL = YEAR(` ') γίνεται... WHERE COL = 1994 Μεταβατική κλειστότητα δοθέντος: T1.C1 = T2.C2, T2.C2 = T3.C3, T1.C1 > 5 προστίθενται... T1.C1 = T3.C3 AND T2.C2 > 5 AND T3.C3 > 5

83 Επανεγγραφή Ερωτήσεων (παράδειγμα από IBM DB2) Αρχική Ερώτηση SELECT ps.* FROM tpcd.partsupp ps WHERE ps.ps_partkey IN (SELECT p_partkey FROM tpcd.parts WHERE p_name LIKE 'forest%'); Μετασχηματισμένη Ερώτηση SELECT ps.* FROM parts, partsupp ps WHERE ps.ps_partkey = p_partkey AND p_name LIKE `forest%';

84 Επανεγγραφή Ερωτήσεων (παράδειγμα από IBM DB2) Αρχική Ερώτηση SELECT SUM(O_TOTAL_PRICE) AS OSUM, AVG(O_TOTAL_PRICE) AS OAVG FROM ORDERS; Μετασχηματισμένη Ερώτηση SELECT OSUM, OSUM/OCOUNT AS OAVG FROM (SELECT SUM(O_TOTAL_PRICE) AS OSUM, COUNT(O_TOTAL_PRICE) AS OCOUNT FROM ORDERS) AS SHARED_AGG; Από 2 sum και 1 count σε 1 sum και 1 count!

85 Επανεγγραφή Ερωτήσεων (παράδειγμα από IBM DB2) Αρχική Ερώτηση SELECT PS_SUPPLYCOST FROM PARTSUPP WHERE PS_PARTKEY <> ALL (SELECT L_PARTKEY FROM LINEITEM WHERE PS_SUPPKEY = L_SUPPKEY) Μετασχηματισμένη Ερώτηση SELECT PS_SUPPLYCOST FROM PARTSUPP WHERE NOT EXISTS (SELECT * FROM LINEITEM WHERE PS_SUPPKEY = L_SUPPKEY AND PS_PARTKEY = L_PARTKEY)