Βάσεις Δεδομένων Ι Ευρετήρια/Indexes. (...και επιδόσεις ΣΔΒΔ) Views (Όψεις) Φώτης Κόκκορας (MSc/PhD) Τμήμα Τεχνολογίας Πληροφορικής & Τηλεπ/νιών

Μέγεθος: px

Εμφάνιση ξεκινά από τη σελίδα:

Download "Βάσεις Δεδομένων Ι - 06. Ευρετήρια/Indexes. (...και επιδόσεις ΣΔΒΔ) Views (Όψεις) Φώτης Κόκκορας (MSc/PhD) Τμήμα Τεχνολογίας Πληροφορικής & Τηλεπ/νιών"

Αγαθίας Φλέσσας
8 χρόνια πριν
Προβολές:

1 Βάσεις Δεδομένων Ι - 06 Ευρετήρια/Indexes (...και επιδόσεις ΣΔΒΔ) Views (Όψεις) Φώτης Κόκκορας (MSc/PhD) Τμήμα Τεχνολογίας Πληροφορικής & Τηλεπ/νιών ΤΕΙ Λάρισας

2 Τι είναι τα ευρετήρια; Ευρετήριο/Index: δομή δεδομένων που χρησιμοποιείται για την επιτάχυνση της πρόσβασης στις πλειάδες μιας σχέσης, με βάση τις τιμές κάποιων γνωρισμάτων. Η δομή μπορεί να είναι hash table ή ένα B-Tree (το συνηθέστερο σε ΣΔΒΔ) παράδειγμα B-Tree απεικονίζεται στο εξώφυλλο 1 ο slide Ο ρόλος ενός ευρετηρίου είναι να επιτρέπει γρήγορη αναζήτηση καθώς η υπολογιστική πολυπλοκότητα αναζήτησης σε B-Tree είναι πολύ μικρότερη της κλασικής (σειριακής) αναζήτησης σε πίνακα. Κατά προσέγγιση (καθώς ξεφεύγει του παρόντος), στην κλασική αναζήτηση, οι έλεγχοι που απαιτούνται είναι ανάλογοι του μεγέθους του πίνακα στον οποίο ψάχνουμε. Στην αναζήτηση σε B-Tree είναι ανάλογη του λογαρίθμου του μεγέθους του πίνακα. Πρόχειρο παράδειγμα: Σε πίνακα 1 εκατομμυρίου εγγραφών, μια τυπική αναζήτηση, χωρίς ευρετήριο, απαιτεί κατά μέσο όρο 500 χιλιάδες ελέγχους (το μισό του πλήθους των εγγραφών). Με ευρετήριο, στον ίδιο πίνακα απαιτούνται περίπου log(10 6 ) = 6 έλεγχοι. Μιλάμε για χαώδη διαφορά! Φ. Κόκκορας / ΤΠΤ ΤΕΙ Λάρισας Βάσεις Δεδομένων Ι

υπολογιστική πολυπλοκότητα αναζήτησης σε B-Tree είναι πολύ μικρότερη της κλασικής (σειριακής) αναζήτησης σε πίνακα.

$..) [index_type] όπου: index_col_name: col_name [(length)] [ASC DESC] και index_type: USING {BTREE HASH} Συνήθεις τύποι ευρετηρίου index: απλό ευρετήριο επιτρέπονται πολλαπλότητες (default τύπος)$

3 Δήλωση Ευρετηρίου Δεν υπάρχει τυποποίηση! Εξαρτάται από το ΣΔΒΔ. Σε MySQL γίνεται ως εξής: CREATE [UNIQUE FULLTEXT SPATIAL] INDEX index_name [index_type] ON table_name (index_col_name,...) [index_type] όπου: index_col_name: col_name [(length)] [ASC DESC] και index_type: USING {BTREE HASH} Συνήθεις τύποι ευρετηρίου index: απλό ευρετήριο επιτρέπονται πολλαπλότητες (default τύπος) unique: σαν το προηγούμενο αλλά δεν επιτρέπει την ίδια τιμή δεύτερη φορά fulltext: επιτρέπει πολύπλοκη αναζήτηση σε κείμενα μόνο σε πεδία με CHAR ή VARCHAR ή TEXT τύπο δεδομένων για την ώρα υπάρχει μόνο σε MyISAM πίνακες σύντομα (?) και σε InnoDB πίνακες οι αγκύλες δηλώνουν προαιρετικά στοιχεία! τρόπος υλοποίησης Τυπικά παραδείγματα δήλωσης ευρετηρίου (μετά τη δημιουργία του πίνακα): CREATE INDEX Beer_Index ON Beers(manf); CREATE UNIQUE INDEX SellIndex ON Sells(bar DESC, beer) USING BTREE; Φ. Κόκκορας / ΤΠΤ ΤΕΙ Λάρισας Βάσεις Δεδομένων Ι

unique: σαν το προηγούμενο αλλά δεν επιτρέπει την ίδια τιμή δεύτερη φορά fulltext: επιτρέπει πολύπλοκη αναζήτηση σε κείμενα http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.

4 Χρήση Ευρετηρίου (1/2) Δοθείσας μιας τιμής v, το ευρετήριο επιστρέφει μόνο τις πλειάδες για τις οποίες το v υπάρχει μέσα στα γνωρίσματα του ευρετηρίου. Παράδειγμα (με τα Beer_Index και SellIndex του προηγούμενου slide): Βρες τις τιμές των μπυρών που κατασκευάζονται από τον Anheuser-Busch και πωλούνται από το Club 175. SELECT price FROM Beers, Sells WHERE name=beer AND manf='anheuser-busch' AND bar='club 175'; μέσω του Beer_Index θα βρεθούν οι μπύρες που κατασκευάζει ο Anheuser-Busch μέσω του SellIndex θα βρεθούν οι τιμές των παραπάνω μπυρών για το bar Club 175 Βλέπετε ότι δεν αλλάζει κάτι στο ερώτημα σε σχέση με τα ευρετήρια! Σε τυπικά σενάρια, η χρήση των ευρετηρίων είναι διάφανη (transparent), δηλαδή δεν κάνουμε κάτι επιπλέον το ΣΔΒΔ τα χρησιμοποιεί αυτόματα! Ένα σημαντικό ζήτημα στη δημιουργία μιας γρήγορης database είναι το τι ευρετήριο να φτιάξουμε. Ο λόγος είναι η ύπαρξη αντικρουόμενων καταστάσεων (trade off): ΥΠΕΡ: επιταχύνει την αναζήτηση στα ερωτήματα που το χρησιμοποιούν ΚΑΤΑ: καθυστερεί όλες τις λειτουργίες INSERT και UPDATE του πίνακα στον οποίο ανήκει γιατί πρέπει επιπλέον να ενημερωθεί και το ευρετήριο! Φ. Κόκκορας / ΤΠΤ ΤΕΙ Λάρισας Βάσεις Δεδομένων Ι

SELECT price FROM Beers, Sells WHERE name=beer AND manf='anheuser-busch' AND bar='club 175'; μέσω του Beer_Index θα βρεθούν οι μπύρες που κατασκευάζει ο Anheuser-Busch μέσω του SellIndex θα βρεθούν

5 Χρήση Ευρετηρίου (2/2) Έστω ότι αυτό που κάνουμε στην mybeersdb database είναι: Εισαγωγή νέων εγγραφώ σε πίνακα, στο 10% των περιπτώσεων. Εύρεση τιμής για δεδομένη μπύρα σε δεδομένο bar, στο 90% των περιπτώσεων. και επιπλέον έχουμε τα ευρετήρια του slide 3: CREATE INDEX Beer_Index ON Beers(manf); CREATE UNIQUE INDEX SellIndex ON Sells(bar DESC, beer) USING BTREE; Είναι ΟΚ η επιλογή ευρετηρίων που κάναμε??? Απάντηση: Το ευρετήριο SellIndex στον πίνακα Sells(bar,beer,price) είναι πολύ σωστά ορισμένο γιατί θα επιταχύνει το 90% της δραστηριότητάς μας με τον πίνακα. Το ευρετήριο Beer_Index στον πίνακα Beers(manf) δεν εξυπηρετεί σε κάτι και κακώς το φτιάξαμε. ΑΡΑ, τα ευρετήρια πρέπει να χρησιμοποιούνται με φειδώ! Τα βάζουμε εκεί που ξέρουμε ότι θα ωφελήσουν......δεν είναι όμως εύκολο να βρούμε τα σωστά ευρετήρια σε μια σύνθετη database! Φ. Κόκκορας / ΤΠΤ ΤΕΙ Λάρισας Βάσεις Δεδομένων Ι

και επιπλέον έχουμε τα ευρετήρια του slide 3: CREATE INDEX Beer_Index ON Beers(manf); CREATE UNIQUE INDEX SellIndex ON Sells(bar DESC, beer) USING BTREE; Είναι ΟΚ η επιλογή ευρετηρίων που κάναμε?

6 Ρύθμιση Ευρετηρίων σε ΒΔ Σημαντικό ερευνητικό πεδίο, καθώς η ρύθμιση "με το χέρι" είναι εξαιρετικά επίπονη. Κατάλληλα λογισμικά (tuning advisors) υποβοηθούν στον ορισμό ευρετηρίων! Πώς λειτουργεί ένας tuning advisor; δίνουμε στον advisor ένα μεγάλο σετ ερωτήσεων (query load) μπορεί να προέρχεται από καταγραφή των queries που τρέχουν στο σύστημα σε τυπική χρήση μπορεί να είναι ερωτήματα που παρέχει ο σχεδιαστής της database o advisor δημιουργεί υποψήφια ευρετήρια (candidate indexes) και ελέγχει την απόδοσή τους με βάση το query load κάθε ερώτημα εκτελείται στη λογική ότι υπάρχει μόνο το υπό εξέταση ευρετήριο καταγράφεται ο μέσος χρόνος (βελτίωσης ή επιδείνωσης) που απαιτείται για να τρέξουν όλα τα ερωτήματα Προφανώς στο τέλος προτιμούνται τα ευρετήρια που βελτιώνουν τις επιδόσεις! Το καλό με τα ευρετήρια είναι ότι μπορεί να οριστούν και εκ των υστέρων, όταν δηλαδή διαπιστωθεί ανάγκη βελτίωσης των επιδόσεων μιας database. Φ. Κόκκορας / ΤΠΤ ΤΕΙ Λάρισας Βάσεις Δεδομένων Ι

ερωτήματα που παρέχει ο σχεδιαστής της database o advisor δημιουργεί υποψήφια ευρετήρια (candidate indexes) και ελέγχει την απόδοσή τους με βάση το query load κάθε ερώτημα εκτελείται στη λογική ότι

Ευρετήρια σε MySQL Workbench Έχει ήδη αναφερθεί κάτι σχετικό στo πακέτο 02-... (slide 22). Για να τα ξαναδούμε.

7 Ευρετήρια σε MySQL Workbench Έχει ήδη αναφερθεί κάτι σχετικό στo πακέτο (slide 22). Για να τα ξαναδούμε... Στην καρτέλα Columns στο Workbench τα checkboxes UN ορίζουν ευρετήριο στο εκάστοτε γνώρισμα, που όμως είναι τύπου UNIQUE, δηλαδή δεν θα επιτρέπονται ίδιες τιμές σε αυτό το γνώρισμα, σε διαφορετικές πλειάδες. π.χ. αν το πεδίο είναι για καταχώριση του επώνυμου, δεν θα επιτρέπονται ίδια επώνυμα! Τα επιπλέον είδη ευρετηρίου που αναφέραμε υποστηρίζονται στην καρτέλα Indexes αλλά χειροκίνητα. Στην διπλανή εικόνα ορίζεται ένα απλό ευρετήριο (τύπου INDEX) στο πεδίο stusurname, με όνομα stusurname_index, και με ταξινόμηση ASC. Φ. Κόκκορας / ΤΠΤ ΤΕΙ Λάρισας Βάσεις Δεδομένων Ι

το γνώρισμα, σε διαφορετικές πλειάδες. π.χ. αν το πεδίο είναι για καταχώριση του επώνυμου, δεν θα επιτρέπονται ίδια επώνυμα!

8 Όψεις / Views Μια όψη (view) είναι μια σχέση (relation) που ορίζεται δυναμικά με βάση: άλλες πρωτογενείς σχέσεις (πίνακες) (ονομάζονται βασικοί πίνακες base tables) άλλες όψεις Υπάρχουν δύο είδη: Εικονικές Όψεις (Virtual Views) Δεν είναι αποθηκευμένες στην database! Είναι απλά queries που όταν εκτελεστούν δημιουργούν μια σχέση. Πραγματικές Όψεις (Materialized Views) Πρόκειται για πραγματικές σχέσεις, δημιουργημένες και αποθηκευμένες! Δήλωση Όψης Φτιάχνουμε όψεις με τον ακόλουθο SQL κώδικα: CREATE [MATERIALIZED] VIEW <name> AS <query>; αν δεν ζητήσουμε ρητά materialized view, θα δημιουργηθεί virtual που είναι το default <name> είναι το όνομα που δίνουμε και <query> το SQL ερώτημα που υλοποιεί την όψη. Φ. Κόκκορας / ΤΠΤ ΤΕΙ Λάρισας Βάσεις Δεδομένων Ι

Πραγματικές Όψεις (Materialized Views) Πρόκειται για πραγματικές σχέσεις, δημιουργημένες και αποθηκευμένες!

9 Παραδείγματα Ορισμός Όψης: Να οριστεί η όψη CanDrink(drinker,beer) που "περιέχει" τα ζευγάρια drinker-beer για τα οποία ο drinker συχνάζει τουλάχιστον σε ένα bar που σερβίρει την μπύρα. CREATE VIEW CanDrink AS SELECT drinker, beer FROM Frequents, Sells WHERE Frequents.bar = Sells.bar; Τρέχοντας αυτόν τον κώδικα στο Workbench, θα φτιαχτεί μια όψη με όνομα CanDrink. Χρήση Όψης Για να χρησιμοποιήσουμε μια όψη, απλά την αντιμετωπίζουμε σαν βασικό πίνακα! Υπάρχει περιορισμένη δυνατότητα εισαγωγής/τροποποίησης σε δεδομένα όψεων. Μόνο αν έχει νόημα η ενέργεια ως εισαγωγή/τροποποίηση σε έναν πίνακα. Αν εμπλέκονται πολλοί πίνακες στην όψη, τότε συνήθως δεν είναι εφικτό παρά μόνο με πλάγιους τρόπους (π.χ. μηχανισμούς trigger θα το δείτε σε Βάσεις Δεδομένων ΙΙ) SELECT beer FROM CanDrink WHERE drinker = 'Mike'; Φ. Κόκκορας / ΤΠΤ ΤΕΙ Λάρισας Βάσεις Δεδομένων Ι

Χρήση Όψης Για να χρησιμοποιήσουμε μια όψη, απλά την αντιμετωπίζουμε σαν βασικό πίνακα! Υπάρχει περιορισμένη δυνατότητα εισαγωγής/τροποποίησης σε δεδομένα όψεων.

10 Πραγματικές Όψεις (Materialized Views) Πρόβλημα: κάθε φορά που μεταβάλλεται κάποιος βασικός πίνακας που συμμετέχει στην όψη, η materialized view πρέπει να αλλάξει επίσης. Σε μεγάλο όγκο δεδομένων δεν είναι υπολογιστικά υποφερτό να γίνεται επαναϋπολογισμός της όψης σε κάθε μεταβολή βασικού πίνακα! Λύση: Κάνουμε περιοδική επανακατασκευή (reconstruction) της materialized όψης η οποία προφανώς σε άλλο χρονικό σημείο θα θεωρείται ότι δεν ανταποκρίνεται πλήρως στην πραγματικότητα (out of date). Παράδειγμα Η αλυσίδα καταστημάτων Walmart, αποθηκεύει κάθε πώληση, σε κάθε υποκατάστημα, σε μια database. Κάθε βράδυ, οι ημερήσιες καταχωρήσεις πωλήσεων χρησιμοποιούνται για να υπολογιστούν materialized views συγκεντρωτικών μεγεθών (π.χ. συνολικές πωλήσεις) που αποθηκεύονται σε ειδικές databases (data warehouses). Τα data warehouses χρησιμοποιούνται από αναλυτές για να προβλέψουν τάσεις της αγοράς, να παράγουν συγκεντρωτικά reports, κτλ. Φ. Κόκκορας / ΤΠΤ ΤΕΙ Λάρισας Βάσεις Δεδομένων Ι

Λύση: Κάνουμε περιοδική επανακατασκευή (reconstruction) της materialized όψης η οποία προφανώς σε άλλο χρονικό σημείο θα θεωρείται ότι δεν ανταποκρίνεται πλήρως στην πραγματικότητα (out of date).

Σχετικά έγγραφα

Βάσεις Δεδομένων Ι - 05. SQL Μέρος 3 ο. (Constraints & Joins) Φώτης Κόκκορας (MSc/PhD) Τμήμα Μηχανικών Πληροφορικής ΤΕ

Βάσεις Δεδομένων Ι - 05. SQL Μέρος 3 ο. (Constraints & Joins) Φώτης Κόκκορας (MSc/PhD) Τμήμα Μηχανικών Πληροφορικής ΤΕ Βάσεις Δεδομένων Ι - 05 SQL Μέρος 3 ο (Constraints & Joins) Φώτης Κόκκορας (MSc/PhD) Τμήμα Μηχανικών Πληροφορικής ΤΕ ΤΕΙ Θεσσαλίας Πρόσθετες Διαφάνειες σε Προηγούμενα Θέματα...σε Διαγραφή Πλειάδων Σημασιολογία