Indexes και Views - (οι όψεις καλύπτονται επιγραμματικά)

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

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

3. Φ. Κόκκορας / Τμ. Μηχανικών Πληροφορική ΤΕ / ΤΕΙ Θεσσαλίας ‐ 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 πίνακες (το δεύτερο σε σχετικά νέες εκδόσεις MySQL)
 Περισσότερα: http://dev.mysql.com/doc/refman/5.7/en/fulltext-search.html
 Τυπικά παραδείγματα δήλωσης ευρετηρίου (μετά τη δημιουργία του πίνακα):
CREATE INDEX Beer_Index ON Beers(manf);
CREATE UNIQUE INDEX SellIndex ON Sells(bar DESC, beer) USING BTREE;
οι αγκύλες δηλώνουν
προαιρετικά στοιχεία!
τρόπος υλοποίησης

4. Φ. Κόκκορας / Τμ. Μηχανικών Πληροφορική ΤΕ / ΤΕΙ Θεσσαλίας ‐ 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 του πίνακα
στον οποίο ανήκει γιατί πρέπει επιπλέον να ενημερωθεί και το ευρετήριο!

5. Φ. Κόκκορας / Τμ. Μηχανικών Πληροφορική ΤΕ / ΤΕΙ Θεσσαλίας ‐ 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) δεν εξυπηρετεί σε κάτι
και κακώς το φτιάξαμε.
 Άλλη Χρήση: Ένα ευρετήριο UNIQUE σε κάποιο γνώρισμα (π.χ. email) μπορεί να
χρησιμοποιηθεί για να εξασφαλιστεί (σε επίπεδο RDBMS) ότι δεν θα υπάρξει 2η
ίδια
τιμή στο γνώρισμα. Βέβαια, θα πρέπει να ληφθούν υπόψη και οι λοιποί παράγοντες.
 ΑΡΑ, τα ευρετήρια πρέπει να χρησιμοποιούνται με φειδώ! Τα βάζουμε εκεί που
ξέρουμε ότι θα ωφελήσουν και δεν είναι πάντα απαραίτητο να φτιαχτούν εξ αρχής.
 ...δεν είναι όμως εύκολο να βρούμε τα σωστά ευρετήρια σε μια σύνθετη database!

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

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

8. Φ. Κόκκορας / Τμ. Μηχανικών Πληροφορική ΤΕ / ΤΕΙ Θεσσαλίας ‐ 8 ‐ Βάσεις Δεδομένων Ι
Όψεις / Views
 Μια όψη (view) είναι μια σχέση (relation) που ορίζεται δυναμικά με βάση:
 άλλες πρωτογενείς σχέσεις (πίνακες) (ονομάζονται βασικοί πίνακες – base tables)
 άλλες όψεις
 Υπάρχουν δύο είδη:
 Εικονικές Όψεις (Virtual Views)
 Δεν είναι αποθηκευμένες στην database! Είναι απλά
queries που όταν εκτελεστούν δημιουργούν μια σχέση.
 Πραγματικές Όψεις (Materialized Views)
 Πρόκειται για πραγματικές σχέσεις, δημιουργημένες και αποθηκευμένες!
 Ο MySQL Server ΔΕΝ υποστηρίζει materialized views!
Υπάρχουν (στην βιβλιογραφία και στο web) διάφορες προσεγγίσεις για "πλάγια"
υποστήριξη τέτοιων όψεων. Για παράδειγμα: http://www.materialized.info/
Δήλωση Όψης
 Φτιάχνουμε όψεις με τον ακόλουθο SQL κώδικα:
CREATE [MATERIALIZED] VIEW <name> AS <query>;
 αν δεν ζητήσουμε ρητά materialized view, θα δημιουργηθεί virtual που είναι το default
 <name> είναι το όνομα που δίνουμε και <query> το SQL ερώτημα που υλοποιεί την όψη.

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