Ένα πλαίσιο για την ανάλυση του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL.

Πανεπιστήμ ιο Πειραιά Τμήμ α Πληροφορικής Ένα πλαίσιο για την ανάλυση του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL Πτυχιακή Εργασία του Ιωάννη ( ΑΜ: Π 01053) Επιβλέπων καθηγητής: Θεοδωρίδης Ιωάννης Πειραιάς, Ιούνιος 2008

Πίνακας Περιεχομένων 1. Εισαγωγή...4 1.1. Κίνητρο της μελέτης...4 1.2. Στόχοι της μελέτης...5 1.3. Δομ ή της μελέτης...5 2. Υπόβαθρο μελέτης...6 2.1. Συστήμ ατα διαχείρισης βάσεων δεδομένων...6 2.1.1. SQL...7 2.2. Τα benchmark στον χώρο των βάσεων δεδομένων...7 2.2.1. Wisconsin benchmark...8 2.2.2. AS3AP benchmark...9 2.2.3. OSDB benchmark...9 2.3. MySQL και γιατί χρησιμ οποιείται στην μελέτη...11 2.4. Ο SQL optimizer...12 2.4.1. Ο sql optimizer στην MySQL...14 2.5. Σύνοψη...15 3. Το πλαίσιο ανάλυσης φόρτου εργασίας του SQL optimizer...17 3.1. Η δομ ή του framework...17 3.2. Περιγραφή των τμημ άτων του benchmark...18 3.2.1. MySQL server και code profiling...18 3.2.2. Μετατροπές στον MySQL server...19 3.2.3. Η αποθήκευση των πληροφοριών...20 3.2.4. MySQL proxy...21 3.2.5. benchmarking client...23 3.2.6. Στατιστικά στοιχεία...23 3.2.7. Χρήση όλων των στοιχείων μαζί...23 3.3. Σύνοψη...24 4. Χρήση του framework...25 4.1. Σενάρια χρήσης...25 4.2. Εγκατάσταση του framework...26 4.3. Αποτελέσμ ατα χρήσης του benchmark...27 4.4. Αξιολόγηση του framework...29 4.5. Σύνοψη...29 5. Συμπεράσμ ατα Περαιτέρω έρευνα...30 5.1. Σύνοψη της έρευνας...30 5.2. Περαιτέρω έρευνα...30 6. Βιβλιογραφικές Αναφορές...32 7. Γλωσσάρι...33 8. Παράρτημ α Ι: τα SQL αιτήμ ατα του OSDB benchmark...34 8.1. Δημ ιουργία της βάσης...34 8.2. SQL αιτήμ ατα εκτός της δημ ιουργίας της βάσης δεδομένων...36 Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 2

9. Παράρτημ α ΙΙ: MySQL server και profiling API...40 9.1. Η βάση δεδομ ένων του profiling API...40 9.2. Η συλλογή των αθροιστικών στατιστικών...41 10. Παράρτημ α: Το script του MySQL proxy...46 11. Παράρτημ α : MySQL server patches...58 11.1. Σενάριο Β...58 11.2. Σενάριο C...60 12. Εκτέλεση του framework...64 Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 3

1. Εισαγωγή Τα υπολογιστικά συστήμ ατα έχουν διεισδύσει πλέον στην καθημ ερινή ζωή και το πλήθος των δεδομ ένων που παράγουν είναι ολοένα και αυξανόμ ενο. Η διαχείριση του ολοένα αυξανόμ ενου όγκου δεδομ ένων, η οποία είναι ευθύνη των Συστημάτων Δ ιαχείρισης Βάσεων Δεδομ ένων, είναι ένα θέμ α το απασχολεί τον χώρο της πληροφορικής τόσο ερευνητικά όσο και επιχειρημ ατικά. Το αποτέλεσμ α είναι ένα μ εγάλο πλήθος από προγράμμ ατα διαχείρισης βάσεων δεδομ ένων και ποικίλη έρευνα η οποία έχει δημ ιουργήσει νέου κλάδους όπως η Εξόρυξη Γνώσης, τα Γεωγραφικά Συστήμ ατα Πληροφοριών και άλλα. Τα Σχεσιακά Συστήμ ατα Βάσεων Δεδομ ένων (RDBMS) είναι ο καθιερωμένος τρόπος, αυτήν την στιγμ ή, για την αποθήκευση μ εγάλου όγκου των δεδομ ένων. Υπάρχουν πολλοί παράγοντες που επηρεάζουν την απόδοση ενός RDBMS, κατά την ανάγνωση και την εγγραφή των δεδομ ένων. Η ύπαρξη αυτών των παραγόντων έχουν οδηγήσει στην αυτομ ατοποίηση της εύρεση του καλύτερου τρόπου μ ε τον οποίο μ πορεί το RDBMS να προσπελάσει τα δεδομ ένα. Ένα από τα πιο σημ αντικά τμήματα του RDBMS, το οποίο είναι υπεύθυνο για αυτήν την εύρεση του βέλτιστου τρόπου προσπέλασης των δεδομ ένων, είναι ο SQL optimizer. Αντικείμ ενο της παρούσης εργασίας είναι η μ ελέτη της λειτουργίας του SQL optimizer και πιο συγκεκριμ ένα μ ελετάται ο τρόπος μ ε τον οποίο μ πορεί να υλοποιηθεί ένα framework για την μ έτρηση του φόρτου εργασίας του SQL optimizer στο Σχεσιακό Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων (RDBMS) MySQL. 1.1. Κίνητρο της μελέτης Ο SQL optimizer ενός RDBMS είναι ένα νευραλγικό σημ είο του συστήμ ατος, στο οποίο οφείλεται σημ αντικό μ έρος της απόδοσης του συστήμ ατος. Η εύρεση ενός ικανοποιητικού ή ακόμ α καλύτερα βέλτιστου πλάνου εκτέλεσης ενός αιτήμ ατος, μ πορεί να ελαχιστοποιήσει την χρήση των πόρων του συστήμ ατος και να μειώσει δραμ ατικά τον χρόνο εκτέλεσής του. Η εύρεση των πιο χρονοβόρων τμημ άτων του SQL optimizer μ πορεί να βοηθήσει σημ αντικά την περαιτέρω ανάπτυξη του RDBMS συστήμ ατος. Το ανθρώπινο δυναμ ικό και η προσπάθεια που μ πορεί να συγκεντρωθεί στην περαιτέρω ανάπτυξη είναι πεπερασμ ένη και συγκεκριμ ένη κάθε φορά. Επομ ένως, όταν βελτιώνονται ήδη υπάρχοντα τμήμ ατα ενός προγράμμ ατος, είναι προτιμ ότερο να επικεντρώνεται η προσπάθεια στην βελτίωση των πιο προβλημ ατικών τμημ άτων ή των τμημ άτων τα οποία μ πορούν να προσφέρουν τα μ έγιστα στην βελτίωση της απόδοσης του προγράμμ ατος. Συμπερασμ ατικά, η ενασχόληση μ ε την απόδοση των τμημ άτων ενός SQL optimizer αγγίζει ένα σημ αντικό παράγοντα της υλοποίησης ενός RDBMS. Η εύρεση Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 4

των τμημ άτων του SQL optimizer, των οποίων η βελτίωση μ πορεί να επιφέρει το μ εγαλύτερο όφελος στην ανάπτυξη είναι ένα σημ αντικό κίνητρο για την εκπόνηση της μ ελέτης αυτής. 1.2. Στόχοι της μελέτης Για τις ανάγκες της ανάλυσης υλοποιείται ένα framework ( πλαίσιο) το οποίο είναι υπεύθυνο για την ενεργοποίηση του SQL optimizer της MySQL και τη συλλογή δεδομ ένων κατά την εκτέλεσή του SQL optimizer. Το πλαίσιο αποτελείται από έναν client, ο οποίος στέλνει αιτήμ ατα στο RDBMS MySQL και μ ιας διαδικασίας, η οποία παρεμ βαίνει στην λειτουργία του RDBMS MySQL προκειμ ένου να συλλέξει και να τελικά να καταγράψει τα ζητούμ ενα μ εγέθη. Ο client πρέπει να είναι τέτοιος ώστε να παράγει ερωτήμ ατα που καταφέρνουν να ενεργοποιήσουν τον SQL optimizer και τα οποία χρίζουν βασικής βελτιστοποίησης. Για τον λόγο αυτό χρησιμ οποιούνται benchmark προορισμ ένα για βάσεις δεδομ ένων. Οι παρεμ βάσεις στην MySQL πρέπει να είναι σχεδιασμ ένες έτσι ώστε: να απαιτείται η ελάχιστη παρέμ βαση στον πηγαίο κώδικα της MySQL. να επιβαρύνεται η εκτέλεση της MySQL όσο το δυνατό λιγότερο. να υπάρχει επεκτασιμ ότητα και ευελιξία, όσον αφορά τα μ εγέθη τα οποία καταγράφονται και μ ετρούνται. να υπάρχει επεκτασιμ ότητα, όσον αφορά τον client/benchmark, ο οποίος χρησιμ οποιείται για την αποστολή αιτημ άτων στην MySQL. να μ ην απαιτούνται αλλαγές στο client/benchmark, το οποίο χρησιμ οποιείται, κάνοντας την διαδικασία της καταγραφής των δεδομ ένων διαφανή στο client/benchmark. Συμπερασμ ατικά, ο στόχος μ ας είναι η δημ ιουργία ενός framework για την ανάλυση του φόρτου εργασίας ( χρόνου εκτέλεσης) των τμημ άτων από τα οποία αποτελείται ο SQL optimizer της MySQL και η εύρεση των πιο χρονοβόρων από αυτά, λαμ βάνοντας υπόψιν τις παραπάνω προϋποθέσεις. 1.3. Δομ ή της μελέτης Στο κεφάλαιο 2 αναπτύσσονται θέμ ατα, που αφορούν το υπόβαθρο, το οποίο είναι απαραίτητο για την κατανόηση του περικειμ ένου του θέμ ατος που μ ας απασχολεί. Στο 3 ο κεφάλαιο περιγράφουμ ε την δομ ή και την υλοποίηση του πλαισίου της μ ελέτης. Στο 4 ο κεφάλαιο δίνεται ένα παράδειγμ α χρήσης του πλαισίου. Στο κεφάλαιο 5 αναφέρουμ ε συμπεράσμ ατα και περαιτέρω έρευνα που μ πορεί να εκκινήσει μ ε αφορμ ή την παρούσα μ ελέτη. Στο κεφάλαιο 6 δίνονται οι βιβλιογραφικές αναφορές και στο κεφάλαιο 7 ένα γλωσσάρι μ ε την αντιστοιχία ελληνικών και αγγλικών όρων που εμ φανίστηκαν στο κείμ ενο. Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 5

2. Υπόβαθρο μελέτης Για τις ανάγκες της παρούσας ανάλυσης, υλοποιείται ένα framework το οποίο πραγμ ατοποιεί την συλλογή των δεδομ ένων, όσον αφορά τον φόρτο εργασίας του SQL optimizer στο RDBMS MySQL. Το framework αποτελείται από ένα client/benchmark το οποίο στέλνει αιτήμ ατα στο RDBMS MySQL και μιας διαδικασίας, η οποία παρεμ βαίνει στην λειτουργία του RDBMS MySQL προκειμένου να καταγράψει ορισμ ένα μ εγέθη. Στο παρόν εισαγωγικό κεφάλαιο παρουσιάζονται θέμ ατα, τα οποία είναι απαραίτητα για την κατανόηση του χώρου, στον οποίο ανήκει η μ ελέτη και το framework, των εργαλείων που εμ πλέκονται καθώς και των προκλήσεων που παρουσιάζονται. Η δομ ή του κεφαλαίου έχει ως εξής: στην ενότητα 2.1 παρουσιάζουμ ε τους λόγους ύπαρξης των συστημ άτων διαχείρισης βάσεων δεδομ ένων. Στην ενότητα 2.2 αναφερόμ αστε στα benchmark που αφορούν τον χώρο των βάσεων δεδομ ένων, και πως καταλήξαμ ε στην χρήση του OSDB benchmark για την παρούσα μ ελέτη. Στην ενότητα 2.3 παρουσιάζουμ ε το RDBMS MySQL, το οποίο είναι αντικείμ ενο της μ ελέτης, και τους λόγους για τους οποίου χρησιμ οποιείται στην μ ελέτη. Στην ενότητα 2.4 αναπτύσσουμ ε την ανάγκη για την ύπαρξη του SQL optimizer και το περίγραμμα της υλοποίησής του στην MySQL. Στην ενότητα 2.5 δίνεται η σύνοψη του κεφαλαίου. 2.1. Συστήμ ατα διαχείρισης βάσεων δεδομένων Ορισμ ένα από τα ζητήμ ατα που πρέπει να επιλυθούν κατά την διαχείριση μεγάλου όγκου δεδομ ένων εμ φανίζονται συχνά. Τέτοια ζητήμ ατα είναι (Ramakrishnan & Gehrke, 2002): η εγγραφή και η ανάγνωση των δεδομ ένων από και προς διαφορετικά μέσα αποθήκευσης: μ έσω δικτύου, τοπικά, σε ένα αρχείο, σε πολλά αρχεία, κατανεμημ ένα σε ένα υπολογιστικό σύστημ α, κατανεμημ ένα σε διαφορετικά υπολογιστικά συστήμ ατα (cluster) κτλ. η διαχείριση της μνήμ ης και η μ εταφορά των δεδομ ένων από το μ έσο όπου είναι αποθηκευμ ένα μόνιμ α. ο συγχρονισμ ός πολλών χρηστών και κλείδωμ α των δεδομ ένων έτσι ώστε να μην εμ φανιστούν ασυνέπειες στα δεδομ ένα από την εγγραφή και την ανάγνωση από διαφορετικούς χρήστες. ο έλεγχος της πρόσβασης στα δεδομ ένα ανάλογα μ ε τα δικαιώμ ατα κάθε χρήστη. Ακριβώς επειδή τα ζητήμ ατα αυτά εμ φανίζονται πολύ συχνά, δημιουργήθηκαν κάποια συστήμ ατα, τα οποία υλοποιούν εσωτερικά αυτές τις λειτουργίες και παρουσιάζουν στον χρήστη μ ια διεπαφή για την διαχείριση αυτών των ζητημ άτων. Τα συστήμ ατα αυτά ονομ άζονται Συστήμ ατα Δ ιαχείρισης Βάσεων Δεδομ ένων ή DBMS Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 6

(DataBase Management System) και ουσιαστικά παρέχουν ένα επίπεδο αφαίρεσης πάνω από τα πραγμ ατικά δεδομ ένα και την διαχείρισή τους. Με αυτόν τον τρόπο, κρύβουν τις λεπτομ έρειες της υλοποίησης των ζητημ άτων αυτών και προσφέρουν στον τελικό χρήστη του DBMS μ ια απλούστερη εικόνα για την διαχείριση των δεδομ ένων. Το 1970 προτάθηκε ένα σχήμ α αναπαράστασης των δεδομ ένων το οποίο ονομ άζεται σχεσιακό μ οντέλο δεδομ ένων (Codd, 1970). Τα συστήμ ατα βάσεων δεδομ ένων τα οποία υλοποιούν αυτό το σχήμ α για την αναπαράσταση των δεδομένων ονομ άζονται Σχεσιακά Συστήμ ατα Δ ιαχείρισης Βάσεων Δεδομ ένων ή αλλιώς RDBMS (Relational DataBase Management System). 2.1.1. SQL Η γλώσσα SQL έχει καθιερωθεί ως το προγραμμ ατιστικό πρότυπο, μ έσω του οποίου ο χρήστης διαχειρίζεται ένα RDBMS και τα δεδομ ένα τα οποία είναι αποθηκευμένα σε αυτό. Όπως αναφέρεται στα (Hare, 2006) και (Lans, 1989), το 1986 ολοκληρώθηκε το πρώτο standard το οποίο έγινε δεκτό από τα ινστιτούτο ANSI (American National Standards Institute) και τον οργανισμ ό ISO (International Standards Organization). Επεκτάσεις και αναθεωρήσεις εκδόθηκαν το 1989 και 1992. Στην συνέχεια η προσπάθεια της προτυποποίησης διαχωρίστηκε σε διαφορετικές ομ άδες, οι οποίες κατά καιρούς συγχώνευαν τις εργασίες που είχαν ολοκληρωθεί. Σημ αντικοί σταθμ οί είναι το πρότυπο SQL 92, το SQL:1999 και το SQL:2003 >>>( αυθεντικό reference). 2.2. Τα benchmark στον χώρο των βάσεων δεδομένων Στον χώρο της πληροφορικής, το benchmark είναι η διαδικασία κατά την οποία εκτελούνται ένα ή περισσότερα προγράμμ ατα, μ ε σκοπό την μ έτρηση της απόδοσης ενός υπολογιστικού συστήμ ατος ή προγράμμ ατος. Χαρακτηριστικά παραδείγματα benchmark είναι η σύγκριση της απόδοσης μ εταξύ διαφορετικών επεξεργαστών, compiler, συστημ άτων βάσεων δεδομ ένων κτλ. (Gray, 1993). Ένα benchmark, βοηθά στην απάντηση ερωτημ άτων όπως: Ποιο υπολογιστικό σύστημ α ή τμήμ α ενός συστήμ ατος είναι το πιο συμ φέρον προς επένδυση. Ποιο μ έρος ενός συστήμ ατος δημ ιουργεί την μ εγαλύτερη συμ φόρηση. Αυτό το οποίο επιβάλλεται, είναι ο ορισμ ός των μ εγεθών πάνω στο οποίο θα μ ετρηθεί η απόδοση και ο ορισμ ός της διαδικασίας μ ε την οποία θα γίνει αυτό (Gray, 1993). Επίσης είναι σημ αντική η εξέταση του περιβάλλοντος στο οποίο βρίσκεται το υπό εξέταση υπολογιστικό σύστημ α ώστε να μ ελετηθούν παράγοντες οι οποίοι μπορούν να επηρεάσουν την μ έτρηση της απόδοσης (Patterson &Hennessy, 2005). Στην παρούσα ανάλυση το μ έγεθος το οποίο αποτελεί αντικείμ ενο έρευνας είναι ο χρόνος, ο οποίος δαπανάται συνολικά στην εκτέλεση του SQL optimizer, και ο χρόνος ο Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 7

οποίος δαπανάται σε κάθε τμήμ α του. Ο χρόνος αυτός μ πορεί να επηρεαστεί από την απόδοση Ι/ Ο. Αυτή μ ε την σειρά της επηρεάζεται από hardware και software παράγοντες: αρχιτεκτονική του συστήμ ατος δοκιμ ής, ταχύτητα προσπέλασης δίσκου και μνήμ ης, άλλες I/O δραστηριότητες, ρυθμ ίσεις του λειτουργικού συστήμ ατος και άλλων υπο συστημ άτων που παίζουν ρόλο όπως συστημ άτων αρχείων, κτλ. Επίσης σημ αντικό ρόλο διαδραμ ατίζουν οι επιλογές κατά την διαδικασία της μεταγλώττισης του πηγαίου κώδικα του RDBMS, για την παραγωγή του εκτελέσιμ ου προγράμμ ατος, καθώς και οι ρυθμ ίσεις των παραμ έτρων του RDBMS κατά την εκτέλεσή του. Επομ ένως, τα αποτελέσμ ατα που θα εξαχθούν πρέπει να μ ελετηθούν λαμβάνοντας υπόψιν όλα αυτά τα θέμ ατα. Για να είναι εφικτό να εξαχθούν ασφαλή συμπεράσμ ατα, πρέπει να ληφθούν υπόψιν οι εξής παράγοντες που ενδέχεται να επηρεάσουν την απόδοση ενός συστήμ ατος: αρχιτεκτονική της μηχανής λειτουργικό σύστημα compilation της εφαρμογής caching σε διάφορα επίπεδα ( πυρήνας, σύστημ α αρχείων) σύστημ α αρχείων Η δοκιμ ή πολλών συνδυασμ ών αυτών των παραμ έτρων είναι ο μ όνος τρόπος για να επιβεβαιωθούν τα κοινά, σε όλες ή στις περισσότερες περιπτώσεις, χρονοβόρα τμήμ ατα. Η δοκιμ ή οφείλει να περιλαμ βάνει πολλές αρχιτεκτονικές, μηχανήμ ατα, πυρήνες, συστήμ ατα αρχείων, ρυθμ ίσεων στο compilation, ρυθμ ίσεις στο σύστημα αρχείων κτλ. Δ ίχως την δοκιμ ή πολλών συνδυασμ ών, τα δεδομ ένα τα οποία εξάγονται, δεν μ πορούν παρά να έχουν ενδεικτικό χαρακτήρα και να μ ην μ πορούν να χρησιμ οποιηθούν ως επιβεβαιωμ ένα. 2.2.1. Wisconsin benchmark Στις αρχές της δεκαετίας του 80 στο πανεπιστήμ ιο του Wisconsin αναπτύχθηκε μια ένα υπολογιστικό σύστημ α επιφορτισμ ένο μ ε την εκτέλεση συστημ άτων βάσεων δεδομ ένων το οποίο ονομ αζόταν DIRECT (Gray, 1993). Το 1983 δημ ιουργήθηκε το Wisconsin benchmark το οποίο αποσκοπούσε στην αξιολόγηση της μηχανής DIRECT, τόσο ως προς τον εαυτό της όσο και προς σχεσιακά συστήμ ατα βάσεων δεδομ ένων τα οποία έτρεχαν σε υπολογιστές γενικής χρήσης (Date, 2004). Λίγο μετά την δημ οσίευσή του, το benchmark αυτό έγινε δημ οφιλές επειδή ήταν το πρώτο benchmark στον χώρο των βάσεων δεδομ ένων το οποίο προσέφερε απλότητα και ταυτόχρονα αποτελέσμ ατα από διαφορετικά συστήμ ατα και αρχιτεκτονικές. Η αποδοχή του ήταν τέτοια ώστε για αρκετά χρόνια ήταν βιομ ηχανικό στάνταρ. Οι περιορισμ οί του αφορούσαν την έλλειψη επεκτασιμ ότητας και παραμ ετροποίησης, επειδή τόσο το μ έγεθος της βάσης δεδομ ένων όσο και το πλήθος των χρηστών ( ένας ) έμ εναν σταθερά και αμ ετάβλητα. Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 8

2.2.2. AS3AP benchmark Αν και πετυχημ ένο, το Wisconsin benchmark παρουσίαζε ελλείψεις. Το κίνητρο για την δημ ιουργία του AS3AP (ANSI SQL Standard Scaleable and Portable) >>>( αυθεντικό reference) ήταν η δημ ιουργία ενός benchmark το οποίο θα κάλυπτε αυτές τις ελλείψεις, θα παρείχε την απλότητα του Wisconsin και θα πρόσφερε επιπλέον επεκτασιμ ότητα, συνάφεια και ευκολία στην διαχείριση (Gray, 1991). Πιο συγκεκριμ ένα οι στόχοι του AS3AP είναι: η παροχή ενός κατανοητού και εύκολου στην διαχείριση συνόλου από τεστ για την μ ελέτη της επεξεργαστικής ισχύος, όσον αφορά τις βάσεις δεδομ ένων. να είναι επεκτάσιμ ο και φορητό σε διαφορετικές αρχιτεκτονικές. να απαιτείται ελάχιστη ανθρώπινη παρέμ βαση στην υλοποίηση και την εκτέλεση. η παροχή ενός ομοιόμ ορφου μετρήσιμ ου μ εγέθους. Για ένα συγκεκριμ ένο RDBMS, το AS3AP ορίζει ως αποτέλεσμ α το μ έγεθος μιας βάσης δεδομ ένων. Το μ έγεθος αυτό είναι το μ έγιστο μ έγεθος της βάσης δεδομ ένων, για το οποίο το σύστημ α είναι εφικτό να εκτελέσει το AS3AP τεστ, για έναν και πολλούς χρήστες, σε χρονικό διάστημ α κάτω των 12 ωρών. Το μ έγεθος της βάσης δεδομ ένων είναι ένα απόλυτο μ έγεθος μ έτρησης της απόδοσης το οποίο μ ε την σειρά του μ πορεί να χρησιμ οποιηθεί για την παραγωγή και άλλων μ εγεθών. Το AS3AP χωρίζεται σε δύο τμήμ ατα: Το τεστ ενός χρήστη, τα οποία περιλαμ βάνουν: 1. εργαλεία για το φόρτωμ α και την κατασκευή της βάσης 2. αιτήμ ατα τα οποία είναι σχεδιασμ ένα να ελέγξουν τις μεθόδους πρόσβασης στα δεδομ ένα και βασικές SQL βελτιστοποιήσεις όπως : επιλογές, απλές συνδέσεις, προβολές, συναθροίσεις και τροποποιήσεις. Το τεστ πολλών χρηστών, τα οποία μ οντελοποιούν διαφορετικούς τύπους φόρτου της βάσης: 1. εργασίες άμ εσης επεξεργασίας συναλλαγών (OLTP) 2. εργασίες ανάκτησης πληροφοριών (information retrieval) 3. μ εικτές εργασίες που περιλαμ βάνουν σύντομ ες συναλλαγές, αιτήματα για την σύνταξη αναφορών (report queries), πλήρη σάρωση μιας σχέσης (relation scan) και μ εγάλες συναλλαγές. 2.2.3. OSDB benchmark Το OSDB benchmark (Open Source Database Benchmark) δημ ιουργήθηκε για μια μ ελέτη στην εταιρία Compaq Computer Corporation μ ε σκοπό την μ έτρηση της απόδοσης στην I/O διαπερατότητα και στη γενικότερη επεξεργαστική δύναμ η του συστήμ ατος GNU Linux/Alpha (OSDB, 2008). Για την υλοποίηση της μ ελέτης αποφασίστηκε να μ ην γίνει χρημ ατική επένδυση σε κάποιο ήδη υπάρχον εμ πορικό benchmark. Επιλέχθηκε η υλοποίηση ενός benchmark βασισμ ένου στην επίσημ η περιγραφή του AS3AP benchmark όπως αυτό είναι τεκμηριωμ ένο στο (Gray, 1993). Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 9

Αν και το OSDB είναι βασισμ ένο στην περιγραφή του AS3AP υπάρχουν ορισμ ένες διαφορές (OSDB, 2008): Μετρήσιμ α μ εγέθη: το AS3AP αναφέρει ένα μ όνο μ έγεθος: το μ έγεθος της μ εγαλύτερης βάσης δεδομ ένων η οποία μ πορεί να χρησιμ οποιηθεί για να ολοκληρωθεί το benchmark σε λιγότερες από 12 ώρες. Αντίθετα, το OSDB αναφέρει πληθώρα ξεχωριστών αποτελεσμ άτων για την κάθε φάση της δοκιμ ής. Έλλειψη λειτουργικότητας: το AS3AP απαιτεί συμ φωνία μ ε μ ια πλήρως συμβατή SQL υλοποίηση ώστε να εκτελεστεί. Αντίθετα, το OSDB μ πορεί να εκτελεστεί και σε μ ερικώς συμ βατές SQL υλοποιήσεις καθώς και σε υλοποιήσεις που δεν ακολουθούν την SQL. Αποσαφηνίσεις: στο specification του AS3AP ορισμ ένα σημ εία είναι διφορούμ ενα. Επειδή το OSDB αποτελεί υλοποίηση, αυτές τις περιπτώσεις έχουν αποσαφηνιστεί μ ε συγκεκριμ ένο τρόπο. Αυθαίρετες αλλαγές: έχουν γίνει διάφορες αλλαγές μ ε σκοπό να διαχωριστούν οι επαναλαμβανόμ ενες ενέργειες από αυτές που πραγμ ατοποιούνται μ όνο μ ια φορά π. χ. αρχική δημ ιουργία της βάσης δεδομ ένων και ενέργειες που επαναλαμ βάνονται κάθε μ έρα. Αυτό που πρέπει να τονιστεί είναι πως, στην παρούσα εργασία, το OSDB δεν χρησιμ οποιείται για τα αποτελέσμ ατα τα οποία παράγονται από την εκτέλεση του. Τα αποτελέσμ ατα αυτά δεν λαμ βάνονται καθόλου υπόψιν για 2 λόγους: Μας ενδιαφέρουν αποτελέσμ ατα από συγκεκριμ ένο τμήμ α της εκτέλεσης του αιτήμ ατος (SQL optimizer) που στέλνει ο OSDB client. Το OSDB benchmark λαμ βάνει υπόψιν του το συνολικό χρονικό διάστημ α από την στιγμ ή, που ο OSDB client έστειλε το αίτημ α, έως ότου λάβει την απάντηση για την εκτέλεσή του, μ έγεθος το οποίο δεν αφορά την παρούσα μ ελέτη. Τα αποτελέσμ ατα που λαμ βάνει το benchmark είναι παραποιημ ένα. Ανάμ εσα στον RDBMS server και στον OSDB client παρεμ βάλλεται ένας proxy server. Προκειμ ένου αυτός να πετύχει συγχρονισμ ό για την αποθήκευση των αποτελεσμ άτων, που χρειάζονται για την παρούσα ανάλυση, υπάρχει καθυστέρηση χρονικά στην απάντηση που στέλνει ο server στον client. Επομ ένως ο OSDB client παραλαμ βάνει παραποιημ ένα χρονικά αποτελέσμ ατα. Τα αιτήμ ατα που στέλνει το OSDB benchmark, κατά την διάρκεια της εκτέλεσής του, εκτός από κάποια CREATE, JOINs, INSERT, DELETE ανήκουν στην συντριπτική τους πλειοψηφία τους ( πάνω από 98%) σε μ ια από τις επόμ ενες 2 κατηγορίες: 1. SELECT col_key, col_code, col_date, col_signed, 2. col_name 3. FROM updates 4. WHERE col_key = CONSTANT 5. UPDATE updates 6. SET col_signed=col_signed+1 7. WHERE col_key = CONSTANT Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 10

όπου 0 <= CONSTANT <= 9999. Επίσης να σημ ειωθεί πως στην στήλη updates.col_keys, δημ ιουργείται ένα ευρετήριο UNIQUE. Τα αιτήμ ατα που αφορούν την δημ ιουργία της βάσης δεδομ ένων του OSDB καθώς και τα υπόλοιπα αιτήμ ατα, που στέλνονται από το OSDB κατά την διάρκεια της εκτέλεσής του, βρίσκονται στο Παράρτημ α 8. Συμπερασμ ατικά, το OSDB benchmark καλύπτει τους στόχους της ανάλυση, ανάλυσης που προτείνουμ ε στην παρούσα εργασία, όσον αφορά τις προϋποθέσεις που πρέπει να πληρεί ο client/benchmark του framework. Το OSDB benchmark χρησιμ οποιείται στην παρούσα μ ελέτη ως βάση, μ όνο για τα SQL αιτήμ ατα που στέλνει στον server. Το σύνολο των SQL αιτημ άτων τα οποία περιλαμ βάνονται στο OSDB benchmark καλύπτουν ένα δείγμ α καθημ ερινών ενεργειών που λαμβάνουν χώρα σε ένα RDBMS. Αυτό που δεν καλύπτεται είναι ευρεία χρήση αιτημ άτων που χρίζουν σοβαρής βελτιστοποίησης, έτσι ώστε να δοκιμ αστούν οι αντοχές του SQL optimizer. 2.3. MySQL και γιατί χρησιμ οποιείται στην μελέτη Η MySQL είναι ένα RDMBS το οποίο αναπτύσσεται από την εταιρία MySQL AB. Το σύστημ α αυτό είναι ένα δημ οφιλές client/server RDBMS στον χώρο του ανοικτού/ ελεύθερου λογισμ ικού αλλά και στον ευρύτερο χώρο των βάσεων δεδομένων (MySQL, 2007), (MySQL, 2008). Η MySQL διανέμ εται υπό διπλή άδεια: διανέμ εται υπό την άδεια GPL (GNU General Public License) αλλά διατίθεται και μ ε εμ πορική άδεια σε περίπτωση που ζητούμ ενο είναι να παρακαμ φθούν οι όροι της GPL ([MySQL, 2008]). Σύμ φωνα με το (FSF, 2008 a), η άδεια GPL πληρεί τις προϋποθέσεις για να χαρακτηριστεί μια άδεια διανομ ής ως άδεια ελεύθερου λογισμ ικού, οι οποίες είναι οι εξής, σύμ φωνα με το (FSF, 2008 b): ελευθερία χρήσης του προγράμμ ατος για οποιοδήποτε λόγο ελευθερία μ ελέτης του τρόπου λειτουργίας του προγράμμ ατος και μ ετατροπής του ώστε να καλύπτει τις προσωπικές ανάγκες του καθενός. Η πρόσβαση στον πηγαίο κώδικα είναι μ ια προϋπόθεση για αυτό. ελευθερία διανομ ής αντιγράφων του προγράμματος ελευθερία βελτίωσης του προγράμμ ατος και διανομ ής των βελτιώσεων στο κοινό. Η πρόσβαση στον πηγαίο κώδικα είναι μ ια προϋπόθεση για αυτό. Η MySQL χρησιμ οποιείται στην παρούσα μ ελέτη, αντί άλλων γνωστών εμπορικών λύσεων ( π. χ. Oracle, MS SQL Server) για δύο λόγους. 1. Η άδεια GPL, υπό την οποία κυκλοφορεί η MySQL, μ ας δίνει την δυνατότητα να δούμ ε τον κώδικα του προγράμμ ατος. Αυτό μ ας επιτρέπει, να μελετήσουμ ε την υλοποίηση των τμημ άτων του προγράμμ ατος που μ ας ενδιαφέρουν. Επιπλέον η χρήση του προγράμμ ατος είναι ελεύθερη, άρα και η δημοσίευση αποτελεσμ άτων από την χρήση του είναι ελεύθερη. Επομ ένως, μ ας δίνεται η δυνατότητα να τρέξουμ ε το benchmark και να δημοσιεύσουμ ε τα αποτελέσματά Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 11

του δίχως περιορισμ ούς. Σε αντίθεση, σε ένα σύστημ α κλειστού κώδικα δεν παρέχεται η δυνατότητα μ ελέτης του πηγαίου κώδικα, εφόσον δεν παρέχεται ο κώδικας. Επιπλέον, απαγορεύεται η μ ελέτη του κώδικα που βρίσκεται στην μνήμ η μ έσω της διαδικασίας του reverse engιneering. Απαγορεύεται δηλαδή η μ ελέτη της υλοποίησης τμημ άτων του προγράμμ ατος. Επιπλέον, απαγορεύεται η δημ οσίευση αποτελεσμ άτων benchmark δίχως την συμ φωνία της εταιρίας που το εκδίδει. 2. Η άδεια GPL, υπό την οποία κυκλοφορεί η MySQL, μ ας δίνει την δυνατότητα να μεταβάλουμ ε τον κώδικα του προγράμμ ατος επομ ένως μπορούμ ε να εισάγουμε κώδικα ο οποίος μ ας βοηθά στην εύρεση των λεπτομ ερειών που ζητά η ανάλυση. Σε αντίθεση, σε ένα σύστημ α κλειστού κώδικα απαγορεύεται η μ ετατροπή του προγράμμ ατος και του κώδικα μ ηχανής στην μνήμ η. Επομένως δεν είναι εφικτή η παρέμ βαση κατά την εκτέλεση του προγράμμ ατος. Συμπερασμ ατικά, η MySQL χρησιμ οποιείται ως αντικείμ ενο μ ελέτης επειδή: 1. είναι ένα δημ οφιλές RDBMS, επομ ένως η μ ελέτη του εμ φανίζει ενδιαφέρον για μ εγάλο τμήμ α του χώρου της πληροφορικής, και 2. μπορούμ ε να μελετήσουμ ε και να παρέμβουμ ε στο πρόγραμμ α μ ε τρόπο που διευκολύνει και διευρύνει τους στόχους της μ ελέτης. 2.4. Ο SQL optimizer Η βελτιστοποίηση παρουσιάζει τόσο μ ια πρόκληση όσο και μ ια ευκαιρία για ένα RDBMS σύστημ α. Πρόκληση παρουσιάζει, επειδή η βελτιστοποίηση είναι απαραίτητη αν είναι επιθυμ ητό ένα αποδεκτό επίπεδο απόδοσης. Ευκαιρία παρουσιάζει, επειδή η δομ ή του σχεσιακού μ οντέλου ευνοεί την αυτόματη βελτιστοποίηση. Το σχεσιακό μ οντέλο είναι ένα μ οντέλο το οποίο παρέχει αφαίρεση σε υψηλό επίπεδο, σε αντίθεση μ ε τα μη σχεσιακά μ οντέλα όπου για την βελτιστοποίηση είναι υπεύθυνος ο ίδιος ο χρήστης (Date, 2004),(Ramakrishnan & Gehrke, 2002). Ο SQL optimizer είναι το τμήμ α ενός RDBMS το οποίο ευθύνεται για την εύρεση ενός ικανοποιητικού σχεδίου υπολογισμ ού για την εκτέλεση κάθε αιτήμ ατος. Ο λόγος για τον οποίο η εύρεση ενός ικανοποιητικού σχεδίου υπολογισμ ού καθίσταται αναγκαία, είναι η ύπαρξη πολλών διαφορετικών τρόπων για την ανάκτηση των δεδομ ένων προκειμ ένου να δοθεί απάντηση στο αίτημ α. Ο χώρος των πιθανών εναλλακτικών σχεδίων σχετίζεται μ ε την αλγεβρική αναπαράσταση του κάθε αιτήμ ατος. Όσο μ εγαλύτερος είναι ο αριθμ ός των τελεστών που λαμ βάνουν χώρα στο αίτημ α, τόσο περιπλοκότερη γίνεται η αλγεβρική παράσταση. Επιπλέον, κάθε RDBMS χρησιμ οποιεί κάποιου είδους ευρετήρια προκειμ ένου να βελτιστοποιήσει τον χρόνο αναζήτησης των αποθηκευμ ένων δεδομ ένων. Ένας ακόμ α στόχος του optimizer είναι η βέλτιστη διαχείριση των υπαρχόντων ευρετηρίων. Στο επόμ ενο σχήμ α παρουσιάζεται μ ία σύνοψη της δομ ής ενός SQL optimizer: Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 12

SQL Αίτημα Συντακτική Ανάλυση Αιτημάτων Συντακτικά Αναλυμένο Αίτημα Βελτιστοποίηση Αιτημάτων Γεννήτρια Σχεδίων Εκτέλεσης Προσδιορισμός Κόστους Σχεδίου Εκτέλεσης Διαχείριση Καταλόγων Βέλτιστο Σχέδιο Εκτέλεσης Επεξεργασία Σχεδιου Εκτέλεσης Εικόνα 1: Συντακτική ανάλυση, βελτιστοποίηση και επεξεργασία SQL αιτήματος Αρχικά λαμ βάνει χώρα η συντακτική ανάλυση, η οποία ευθύνεται για τον γραμμ ατικό έλεγχο των αιτημ άτων και την μ ετατροπή της SQL σε μ ία δομ ή, η οποία είναι κατανοητή από το RDBMS. Μετά την συντακτική ανάλυση, το αίτημ α δίνεται στον βελτιστοποιητή αιτημ άτων (query optimizer). Ευθύνη του βελτιστοποιητή είναι ο προσδιορισμ ός ενός αποδοτικού σχεδίου εκτέλεσης για το τρέχον αίτημ α. Ο βελτιστοποιητής παράγει εναλλακτικά σχέδια για την εκτέλεση του αιτήμ ατος και επιλέγει εκείνο το οποίο αντιστοιχεί στο ελάχιστο αναμενόμ ενο κόστος. Στον υπολογισμ ό του αναμενόμ ενου κόστους χρησιμοποιείται πληροφορία από τους καταλόγους του συστήμ ατος. Για να γίνει κατανοητή η ανάγκη για την ύπαρξη του βελτιστοποιητή θα δώσουμε ένα παράδειγμ α. Ας υποθέσουμ ε πως έχουμ ε μ ια βάση δεδομ ένων, όπου είναι καταχωρημ ένα τα τηλέφωνα, το επίθετο και η περιοχή όλων των κατοίκων της Ελλάδας. Ας υποθέσουμ ε οτι ζητούμ ε από το RDBMS όλα τα τηλέφωνα των κατοίκων της Αττικής των οποίο το επίθετο αρχίζει από το γράμμ α ωμ έγα. Ας υποθέσουμ ε πως υπάρχουν 10.000.000 τηλέφωνα και πως το καθένα αντιστοιχεί σε ένα επίθετο. Από αυτά εμ πειρικά είναι ασφαλές να θεωρήσουμ ε πως το 40% βρίσκεται στην Αττική και το 5% έχει επίθετο που ξεκινά από ωμ έγα. Στην περίπτωση το RDBMS δεν έχει ευρετήρια τα οποία του δίνουν πρόσβαση σε στατιστικά στοιχεία είναι υποχρεωμ ένο να προβεί σε πλήρη σάρωση των δεδομ ένων, Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 13

για να επιλέξει τα επίθετα που ξεκινούν από ωμ έγα και ταυτόχρονα η περιοχή να είναι η Αττική. Κόστος ανάγνωσης 10.000.000 εγγραφές. Στην περίπτωση που το RDBMS έχει πρόσβαση σε ένα ευρετήριο που αφορά μόνο την περιοχή, μ πορεί να προβεί στην ανάγνωση του 40% των εγγραφών. Με αυτόν τον τρόπο μ πορεί να επιλέξει τα τηλέφωνα της Αττικής και σε αυτά να βρει ποια επίθετα ξεκινούν από ωμ έγα. Κόστος ανάγνωσης 4.000.000 εγγραφές. Στην περίπτωση που το RDBMS έχει πρόσβαση σε 2 ευρετήρια, ένα για το επίθετο και ένα για την περιοχή, τότε 2 επιλογές: 1. Να επιλέξει πρώτα τα τηλέφωνα ανά περιοχή και μ ετά να βρεί ποια από αυτά έχουν επίθετο που ξεκινά από ωμ έγα. Κόστος ανάγνωσης 4.000.000 εγγραφές. 2. Να επιλέξει πρώτα τα τηλέφωνα ανά επίθετο και μ ετά να βρει ποια από αυτά βρίσκονται στην Αττική. Κόστος ανάγνωσης 500.000 εγγραφές. Από το παραπάνω απλό παράδειγμ α, καταρχάς, είναι φανερό πως η ίδια ερώτηση μ πορεί να απαντηθεί μ ε διαφορετικά σχέδια εκτέλεσης και πως η διαφορά στην απόδοση ενδέχεται να είναι σημ αντική. Επομ ένως τόσο οι μ έθοδοι για την επιτάχυνση της ανάγνωσης και εγγραφής των δεδομ ένων, όσο και η εύρεση ενός βέλτιστου σχεδίου εκτέλεσης ενός SQL αιτήμ ατος είναι αναγκαία θέμ ατα που πρέπει να λύσει ένα RDBMS. 2.4.1. Ο sql optimizer στην MySQL Ο sql optimizer, στην MySQL, υλοποιείται στα αρχεία sql/sql_select.cc και πιο συγκεκριμ ένα στην συνάρτηση JOIN::optimize(). Το παρακάτω διάγραμμ α δείχνει την δομ ή του κώδικα που αναλαμ βάνει ένα αίτημ α στον server: 1. handle_select() 2. mysql_select() 3. JOIN::prepare() 4. setup_fields() 5. JOIN::optimize() /* ο optimizer ξεκινά εδώ... */ 6. optimize_cond() 7. opt_sum_query() 8. make_join_statistics() 9. get_quick_record_count() 10. choose_plan() 11. optimize_straight_join() 12. /* Εύρεση μ ερικώς βέλτιστου πλάνου */ 13. /* μ εταξύ όλων & υποσυνόλων από όλα τα */ 14. /* πιθανά πλάνα. ελέγχεται το βάθος */ 15. /* (exhaustiveness) της έρευνας */ 16. greedy_search() 17. /* exhaustive έρευνα για βέλτιστο πλάνο*/ 18. find_best() 19. make_join_select() /*... έως εδώ */ 20. JOIN::exec() Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 14

Στο διάγραμμ α, ένα κομμ άτι κώδικα καλεί τον κώδικα που βρίσκεται στοιχισμένος πιο δεξιά. Όπως φαίνεται από την παραπάνω δομ ή ο SQL optimizer της MySQL αποτελείται από τις συναρτήσεις optimize_cond, opt_sum_query και make_join_statistics. Η optimize_cond ( γραμμ ή 6) είναι υπεύθυνη για θέμ ατα που αφορούν τις συνθήκες WHERE και HAVING. Η συνάρτηση opt_sum_query ( γραμμ ή 7) είναι υπεύθυνη για την βελτιστοποίηση των συναθροιστικών συναρτήσεων min, max και count. Η make_join_statistics ( γραμμ ή 8) είναι η συνάρτηση όπου αποφασίζεται ο τρόπος με τον οποίο θα εκτελεστεί το JOIN. Πιο συγκεκριμ ένα, μ ε την συνάρτηση get_quick_record_count ( γραμμ ή 9) βρίσκεται μ ια πρώτη εκτίμ ηση του πλήθους των πιθανών σειρών που θα επιστραφούν από τους πίνακες. Με την συνάρτηση choose_plan ( γραμμ ή 10) γίνεται ο υπολογισμ ός του βέλτιστου πλάνου. Υπάρχουν δύο περιπτώσεις: να περιλαμ βάνει το query STRAIGHT JOIN. Σε αυτήν την περίπτωση, μ ε την optimize_straight_join ( γραμμ ή 11) ο βελτιστοποιητής προσπαθεί να κάνει την βελτιστοποίηση λαμ βάνοντας υπόψιν την σειρά μ ε την οποία έχουν δοθεί οι πίνακες του STRAIGHT JOIN. να μ ην περιλαμ βάνει το query STRAIGHT JOIN. Σε αυτήν, την πιο συνηθισμένη περίπτωση, υπάρχουν 2 τρόποι μ ε τους οποίος βρίσκεται το βέλτιστο πλάνο, με βάση το πλήθος των σειρών που θα αντληθούν από τους πίνακες. 1. αν οι πίνακες είναι λίγοι στο πλήθος, ερευνώνται όλα τα πιθανά πλάνα εκτέλεσης μ ε την συνάρτηση find_best ( γραμμ ή 18). 2. αν οι πίνακες είναι πολλοί στο πλήθος τότε και τα πιθανά πλάνα εκτέλεσης είναι πολλά. Επομ ένως ο βελτιστοποιητής δεν τα ελέγχει όλα, αλλά περιορίζεται από κάποιες παραμ έτρους που αφορούν το εύρος της έρευνας. Με την greedy_search ( γραμμ ή 16) ο βελτιστοποιητής προσπαθεί να βρει το μ ερικώς βέλτιστο πλάνο, ένα πλάνο δηλαδή το οποίο είναι βέλτιστο, λαμ βάνοντας υπόψιν αυτές τις παραμ έτρους. Ανάλογα μ ε τις παραμ έτρους, όσο πιο μ εγάλο είναι το δυνατό εύρος της έρευνας, τόσο το μ ερικώς βέλτιστο πλάνο πλησιάζει την απόδοση του συνολικά βέλτιστου πλάνου. 2.5. Σύνοψη Στην ενότητα αυτή αναλύθηκαν οι λόγοι για τους οποίους το framework δομ είται με τα εργαλεία και τα προγράμμ ατα που αναφέρθηκαν πιο πάνω: Η MySQL χρησιμ οποιείται ως αντικείμ ενο μ ελέτης διότι είναι ένα δημοφιλές RDBMS σύστημ α και διότι μπορούμ ε να επέμβουμ ε σε βάθος στον πηγαίο κώδικά της. Ο SQL optimizer της MySQL παρουσιάζει ενδιαφέρον επειδή έχουμ ε πρόσβαση στον πηγαίο κώδικά του και μπορούμ ε να μελετήσουμ ε εκτεταμ ένα. Το OSDB benchmark χρησιμ οποιείται για τα SQL αιτήμ ατα που στέλνει στην MySQL, επειδή βασίζεται στο AS3AP, ένα καθιερωμ ένο και γνωστό Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 15

benchmark, το οποίο έχει ένα καλό δείγμ α SQL αιτημ άτων, τα οποία απαιτούν βασικές ικανότητες βελτιστοποίησης. Επίσης δόθηκε και μ ια δομ ή του SQL optimizer της MySQL, σε υψηλό επίπεδο. Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 16

3. Το πλαίσιο ανάλυσης φόρτου εργασίας του SQL optimizer Στην ενότητα αυτή αναλύονται η δομ ή του framework το οποίο προτείνουμ ε καθώς και λεπτομ έρειες υλοποίησής του. Η δομ ή του κεφαλαίου έχει ως εξής: στην ενότητα 3.1 γίνεται μ ια εισαγωγή στην δομ ή του framework. Στην ενότητα 3.2 περιγράφονται αναλυτικά τα τμήμ ατα από τα οποία αποτελείται το framework καθώς και ο τρόπος μ ε τον οποίο αλλελεπιδρούν. Στην ενότητα 3.3 δίνεται η σύνοψη του κεφαλαίου. 3.1. Η δομ ή του framework Το framework αποτελείται από 3 προγράμμ ατα τα οποία αλληλεπιδρούν προκειμένου να παραχθούν και να αποθηκευτούν τα επιθυμ ητά αποτελέσμ ατα. Αυτά είναι: ένας MySQL server. ένας MySQL proxy server. ένας client ο οποίος στέλνει αιτήμ ατα στον server, στην περίπτωσή της ανάλυσης ένα benchmark. Το παρακάτω σχήμ α παρουσιάζει την δομ ή του framework: client (benchmark) SQL αίτημα MySQL proxy Εικόνα 2: Δομ ή των τμημ άτων της μ ελέτης και ροή δεδομένων SQL αίτημα αποθήκευση δεδομένων μελέτης MySQL server Η ροή των δεδομ ένων έχει ως εξής: το benchmark στέλνει αιτήμ ατα στον server, δίχως να γνωρίζει την ύπαρξη του proxy server. Τα αιτήμ ατα αυτά χρησιμ οποιούνται από την μ ελέτη για βρεθεί ο φόρτος εργασίας του SQL optimizer. ο MySQL proxy αναλαμ βάνει να προωθήσει τα αιτήμ ατα στον MySQL server. Όταν επιστρέφει στον MySQL proxy η απάντηση του αιτήμ ατος, τότε ο MySQL proxy δεν στέλνει αμ έσως την απάντηση στον client. Αντιθέτως, στέλνει στην βάση ένα σύνολο αιτημ άτων, μ ε το οποίο γίνεται η αποθήκευση μ ετρήσεων της μ ελέτης, σε μ ία βάση δεδομ ένων στον server. Όταν πραγμ ατοποιηθεί η αποθήκευση, τότε ο MySQL proxy επιστρέφει στον client την απάντηση του server. Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 17

ο MySQL server δέχεται τα αιτήμ ατα τα οποία και προσπαθεί να εξυπηρετήσει. Ο MySQL server, που χρησιμ οποιείται στην μ ελέτη, είναι ένας τροποποιημένος server. Χάρη σε αυτήν την μ ετατροπή γίνονται οι μ ετρήσεις για την ανάλυση του φόρτου εργασίας στον SQL optimizer. Όμ ως τα δεδομ ένα που παράγονται από την ανάλυση, είναι προσωρινά αποθηκευμ ένα στην μνήμ η και θα χαθούν μ όλις ο client αποσυνδεθεί. Για αυτόν τον λόγο, ο MySQL proxy αναλαμβάνει να αποθηκεύσει τα δεδομ ένα στον server, μόνιμ α σε μ ία βάση δεδομ ένων. Στην συνέχεια έχουμ ε την δυνατότητα να τα επεξεργαστούμ ε και να προχωρήσουμε στην ανάλυση των δεδομ ένων. 3.2. Περιγραφή των τμημ άτων του benchmark Στις επόμ ενες ενότητες θα παρουσιάσουμ ε μ ε λεπτομ έρειες τα τμήμ ατα που αποτελούν το benchmark καθώς και τον τρόπο μ ε τον οποίο αλληλεπιδρούν. 3.2.1. MySQL server και code profiling Όπως αναφέραμ ε πιο πάνω, χρειάζεται να επέμβουμ ε στον πηγαίο κώδικα του server προκειμ ένου να προσθέσουμ ε κώδικα, ο οποίος καταγράφει τα δεδομ ένα που ζητούνται. Για την επέμ βαση αυτή χρησιμοποιούμ ε το SHOW PROFILES API ( ή πιο απλά profiling API) το οποίο ήδη υπάρχει στην MySQL. Το API αυτό αποτελεί μέρος των community features τα οποία δεν περιλαμ βάνονται στις binary εκδόσεις των server, πέραν της τρέχουσας έκδοσης παραγωγής. Η χρήση του API είναι απλή. Γενικά, το API καταμ ετρά το χρονικό διάστημ α, το οποίο περνά ένα αίτημ α μ έσα στον MySQL server, από την στιγμ ή που μ παίνει στον server μ έχρι την στιγμ ή που ο server επιστρέφει την απάντηση. Μέσα στον κώδικα του MySQL server υπάρχει ένα πλήθος από σημ εία ελέγχου. Το API μ ετρά το χρονικό διάστημ α από την στιγμ ή που η εκτέλεση του κώδικα συναντήσει ένα σημείο ελέγχου έως ότου συναντήσει το επόμ ενο σημ είο ελέγχου. Στον κώδικα της MySQL, υπάρχουν ήδη τοποθετημ ένα κάποια τέτοια σημ εία ελέγχου, τα οποία καταμ ετρούν το χρονικό διάστημ α που δαπανάται σε σημ αντικά σημ εία κατά την εκτέλεση ενός αιτήμ ατος. Το κάθε σημ είο ελέγχου υλοποιείται μ ε την κλήση της συνάρτησης thd_proc_info(). Κάθε φορά που το profiling API συναντά αυτή την συνάρτηση μ ηδενίζει ένα χρονόμ ετρο και μ ετρά τον χρόνο έως ότου συναντήσει ξανά μ ια κλήση της συνάρτησης. Για να προστεθεί ένα καινούργιο σημ είο ελέγχου μ έσα στον κώδικα, χρειάζεται η προσθήκη μ ιας συνάρτησης thd_proc_info() στον κώδικα. Τα δεδομ ένα, τα οποία καταμ ετρούνται από το profiling API, αποθηκεύονται στον πίνακα profiling της βάσης δεδομ ένων information_schema. Ο πίνακας αυτός χρησιμ οποιεί την μ ηχανή αποθήκευσης MEMORY η οποία αποθηκεύει τον πίνακα αποκλειστικά στην μνήμ η. Επομ ένως, μ ετά την αποσύνδεση του client από τον server τα δεδομ ένα που είναι αποθηκευμ ένα στον πίνακα χάνονται. Επίσης για κάθε client υπάρχει διαφορετικό στιγμ ιότυπο του πίνακα στην μνήμ η. Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 18

Το profiling API χρησιμ οποιήθηκε γιατί καλύπτει τις προϋποθέσεις που τέθηκαν στους στόχους της μ ελέτης όσον αφορά την μ ετατροπή του MySQL server. Με την χρήση του profiling API δεν χρειάζεται η προσθήκη καινούργιων ορισμ ών, συναρτήσεων ούτε η μ ετατροπή στον πηγαίο κώδικα, σε οποιοδήποτε σημείο του προγράμμ ατος. Εφόσον το profiling API είναι τμήμ α του κώδικα της MySQL απαιτείται απλά η κλήση του. Επιπλέον η χρήση του είναι ιδιαιτέρως απλή ( κλήση μ ίας συνάρτησης). Επομ ένως, απαιτείται ελάχιστη παρέμβαση στον πηγαίο κώδικα της MySQL Το profiling API, αποθηκεύει τα δεδομ ένα που συλλέγονται σε μ ία βάση δεδομ ένων μ έσα στον MySQL server. Η μ ηχανή αποθήκευσης των πινάκων είναι η MEMORY η οποία αποθηκεύει τα δεδομ ένα στην μνήμ η του συστήμ ατος δίχως να γίνεται χρήση του σκληρού δίσκου. Επομ ένως η I/O επιβάρυνση κατά την εκτέλεση του αιτήμ ατος είναι η ελάχιστη και κατά συνέπεια, επιβαρύνεται η εκτέλεση της MySQL όσο το δυνατό λιγότερο. Είναι δυνατή η προσθήκη σημ είων ελέγχου σε οποιοδήποτε σημ είο του κώδικα, δίνοντας έτσι την δυνατότητα για μ ετρήσεις σε οποιαδήποτε τμήμ ατα της εκτέλεσης ενός αιτήμ ατος. Επομ ένως, προσφέρει επεκτασιμ ότητα και ευελιξία, όσον αφορά τα μ εγέθη τα οποία καταγράφονται και μ ετρούνται. 3.2.2. Μετατροπές στον MySQL server Στον πηγαίο κώδικα της MySQL υπάρχουν ήδη 2 σημ εία ελέγχου του profiling API, τα οποία καλύπτουν την εκτέλεση του SQL optimizer, τα optimizing και statistics. Τα 2 αυτά σημ εία έχουν αφαιρεθεί και έχουν προστεθεί περισσότερα ( καινούργια) τα οποία καλύπτουν τον ίδιο κώδικα. Για τις ανάγκες της μ ελέτης πρέπει να εξεταστεί ο κώδικας τον οποίο καλύπτουν τα σημ εία αυτά, μ ε περισσότερη λεπτομ έρεια. Για υπάρχει ομ οιότητα μ ε τα παλιά σημ εία ελέγχου, τα καινούργια έχουν ονομ αστεί optimizing: ΧΥΖ και statistics: ΧΥΖ όπου ΧΥΖ μ ια ονομ ασία που χαρακτηρίζει το σημ είο αυτό. Συγκεκριμ ένα: Στην συνάρτηση JOIN::optimize επεκτείνεται το σημ είο ελέγχου optimizing στα επιμ έρους σημ εία: 1. optimizing: init : ξεκίνημ α της JOIN::optimize, δέσμ ευση μεταβλητών και αρχικοποίηση αυτών. 2. optimizing: conds": βελτιστοποίηση των conditionals ( συνάρτηση optimize_cond) 3. optimizing: sums : βελτιστοποίηση των count, min, max ( συνάρτηση opt_sum_query) Στη συνάρτηση make_join_statistics επεκτείνεται το σημ είο ελέγχου statistics : 1. "statistics: init": ξεκίνημ α της make_join_statistcs, δέσμευση μ εταβλητών και αρχικοποίηση αυτών.. 2. "statistics: const tables": Εύρεση των const πινάκων ( η έννοια εξηγείται στην συνέχεια). Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 19

3. "statistics: index stats": Ανανέωση των πληροφοριών για τα ευρετήρια που μ πορούν να χρησιμ οποιηθούν. 4. "statistics: count rows": Υπολογισμ ός του πιθανού πλήθος των γραμμών κάθε πίνακα. 5. "statistics: join order": Εύρεση του βέλτιστου πλάνου για τα JOIN. Αυτό που πρέπει να σημ ειωθεί είναι πως το τελευταίο σημ είο ελεγχου μ ετρά όντως τον χρόνο του κώδικα της συνάρτησης make_join_statistics και όχι και επιπλέον κώδικα μ ετά το τέλος της συνάρτησης αυτής. Αυτό συμ βαίνει διότι αμ έσως μ ετά το τέλος της make_join_statistics υπάρχει ένα επόμ ενο σημ είο ελέγχου, το "preparing. Επιπλέον σκόπιμ ο είναι να εξηγηθεί τι ορίζεται ως πίνακας const: Ένας πίνακας μ ε 0 ή μ ε 1 μ όνο γραμμ ή. Μια έκφραση, που περιέχει πίνακα, η οποία περιορίζεται από μ ια συνθήκη WHERE, η οποία περιέχει συνθήκες της μ ορφής στήλη= σταθερά για: 1. όλες τις στήλες του πρωτεύοντος κλειδιού ή 2. για όλες τις στήλες οποιουδήποτε από τα unique κλειδιά του πίνακα (με την προϋπόθεση πως οι στήλες έχουν οριστεί ως NOT NULL). Αφού γίνει το compile του server ο server χρησιμ οποιείται για το benchmark. 3.2.3. Η αποθήκευση των πληροφοριών Το profiling API παρέχει ένα πλήθος από πληροφορίες. Μία πλήρης καταγραφή των πληροφοριών βρίσκεται στο Παράρτημ α 7. Από αυτές τις πληροφορίες, στην ανάλυση χρειάζονται συγκεκριμ ένες μ όνο. Στον MySQL server δημ ιουργείται μια βάση δεδομ ένων όπου θα αποθηκευτούν μόνιμ α τα δεδομ ένα, που παρέχει το profiling API, για περαιτέρω επεξεργασία. Η βάση αυτή περιλαμ βάνει τους εξής πίνακες: 1. queries( ID, query, session, session_time) 2. details( ID, seq, state, duration) O Πίνακας queries αποθηκεύει το αποτύπωμ α του κάθε αιτήμ ατος, δίχως τις λεπτομ έρειες που το αφορούν. Αποτελείται από τα πεδία: ID: ένας μ οναδικός αριθμ ός (id) του κάθε αιτήμ ατος που εξυπηρετεί ο server. Ο αριθμ ός αυτός είναι ανεξάρτητος από τον client που στέλνει το αίτημ α, σχετίζεται μ όνο μ ε την σειρά μ ε την οποία ο server εξυπηρετεί τα αιτήμ ατα που δέχεται QUERY: η SQL που αποτελεί το αίτημ α. SESSION: το id του thread το οποίο εξυπηρετεί τον κάθε client. Είναι μοναδικό αν ο server δεν κλείσει. Αν γίνει επανεκκίνηση του server η αρίθμ ηση ξεκινά από την αρχή. Αυτό το δεδομ ένο μ πορεί να χρησιμ εύσει αν θέλουμ ε να εξετάσουμ ε τη σειρά μ ε την οποία καταφθάνουν στον server οι client. SESSION_TIME: η χρονοσφραγίδα στην οποία έγινε η αυθεντικοποίηση του client από τον server. Αυτό το δεδομ ένο μ πορεί να χρησιμ εύσει αν θέλουμ ε να εξετάσουμ ε τη σειρά και τη χρονική απόσταση μ ε την οποία οι client καταφθάνουν στον server. Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 20

O Πίνακας details αποθηκεύει τις λεπτομ έρειες που αφορούν το κάθε αίτημ α. Για το κάθε αίτημ α αποθηκεύεται ένα πλήθος από σειρές. Η κάθε σειρά περιέχει τις πληροφορίες από την εκτέλεση του κώδικα που αντιστοιχεί από ένα σημ είο ελέγχου του profiling API έως το επόμ ενο. Αποτελείται από τα πεδία: ID: το id του κάθε αιτήμ ατος που εξυπηρετεί ο server ( βλ πίνακα queries). SEQ: ένας αύξων αριθμ ός που δηλώνει την σειρά του σημ είου ελέγχου ανάμεσα στα σημ εία ελέγχου ενός συγκεκριμ ένου αιτήμ ατος. STATE: το όνομ α που δίνεται από το profiling API στο σημ είο ελέγχου το οποίο χρονομ ετρεί η γραμμ ή. DURATION: ο χρόνος που χρειάστηκε για την ολοκλήρωση του σημ είου ελέγχου. Ο κώδικας του script της δημ ιουργίας της βάσης δεδομ ένων για την μόνιμη αποθήκευση των δεδομ ένων, βρίσκεται στο Παράρτημ α 9.1. 3.2.4. MySQL proxy Ο MySQL proxy είναι ένας proxy server ο οποίος παρεμ βάλλεται ανάμ εσα στον MySQL server και τους πελάτες του. Ο proxy server μ πορεί να μ εταβάλλει και να επεξεργαστεί οποιαδήποτε κίνηση δεδομ ένων από τον client προς στον server και αντίστροφα, η οποία χρησιμ οποιεί το MySQL Network protocol και η οποία περνά μ έσω της port στην οποία ακούει ο server. Η διαχείριση και η επεξεργασία γίνεται από ένα script, το οποίο διαβάζει ο proxy κάθε φορά που ένας καινούργιος πελάτης προσπαθεί να συνδεθεί. Για τις ανάγκες της ανάλυσης δημ ιουργήθηκε ένα script το οποίο αναλαμ βάνει την προώθηση του αιτήμ ατος του client στον server και ύστερα την αποθήκευση των δεδομ ένων του profiling API για το συγκεκριμ ένο αίτημ α. Ο αλγόριθμ ος που υλοποιεί το script είναι ο ακόλουθος ( ο πλήρης κώδικας του script βρίσκεται στο Παράρτημ α 10): Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 21

state -2 O proxy server δέχεται αίτηση για αυθεντικοποίηση. Την στέλνει στον server και στέλνει και ένα επιπλέον αίτημα ώστε να θέσει σε λειτουργία τον μηχανισμό του profiling API state -1 O proxy server δέχεται 2 απαντήσεις: στέλνει την απάντηση της αυθεντικοποίησης στον client απορρίπτει την απάντηση που αφορούσε το profiling API state 0 O proxy server δέχεται αίτηση ενα αίτημα. Στέλνει στον server 2 αιτήματα: το αρχικό αίτημα του client ένα επιπλέον αίτημα που ζητά το id του αιτήματος του client από το profiling API state 1 O proxy server δέχεται 2 απαντήσεις: την απάντηση στο αρχικό αίτημα του client την οποία αποθηκεύει και δεν προωθεί στον client την απάντηση του αιτήματος από το profiling API για το id του αιτήματος του client state 2 O proxy server στέλνει στον server 2 αιτήματα (τύπου INSERT) με τα οποία αποθηκεύονται μόνιμα οι πληροφορίες του profiling API για το αρχικό αίτημα του client, στη βάση δεδομένων profiling. state 3 O proxy server δέχεται 2 απαντήσεις που αφορούν την αποθήκευση των πληροφοριών. Δεν τις προωθεί στον client και τις απορρίπτει. state 4 O proxy server στέλνει στον client την αποθηκευμένη απάντηση του αρχικού αιτήματος Εικόνα 3: ο αλγόριθμ ος του script του MySQL proxy Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 22

Σχετικά μ ε τον παραπάνω αλγόριθμ ο επεξηγούνται στην συνέχεια ορισμένα σημ εία: Ο αλγόριθμ ος αρχίζει όταν ένας client αρχίζει την διαδικασία αυθεντικοποίησης στον server. Ο αλγόριθμ ος τερμ ατίζει όταν διακοπεί η σύνδεση του client μ ε τον server είτε με κανονικό τρόπο είτε λόγω σφάλμ ατος. Η αρίθμ ηση των καταστάσεων ( 2 έως 4) έχει καθαρά ενδεικτικό χαρακτήρα. Στις καταστάσεις πριν το 0 δεν έχει ενεργοποιηθεί ακόμ α το profiling API ενώ στις καταστάσεις μ ετά το 0 έχει ενεργοποιηθεί. Ο αλγόριθμ ος κατά την κύρια λειτουργία του ( καταστάσεις 0 έως 4) είτε εξυπηρετεί ένα αίτημ α ( καταστάσεις 1 έως 4) είτε αναμ ένει ένα αίτημα ( κατάσταση 0) 3.2.5. benchmarking client Το benchmark συνδέεται στη θύρα όπου ακούει ο proxy server και αρχίζει να στέλνει αιτήμ ατα στον MySQL server (μ έσω του proxy server). Τότε, τα δεδομ ένα του profiling API, για κάθε αίτημ α, αποθηκεύονται στον MySQL server. Μόλις τελειώσει το benchmark στην βάση δεδομ ένων profiling είναι αποθηκευμ ένα όλα τα στατιστικά για όλα τα αιτήμ ατα που στέλνονται. Το πλήθος των αιτημ άτων είναι περίπου 450.000, αριθμ ός ο οποίος, περιλαμ βάνει και ένα αίτημα BEGIN και ένα COMMIT για κάθε αίτημ α τύπου SELECT και UPDATE. Το πλήθος των αιτημ άτων δίχως τα BEGIN, COMMIT είναι περίπου 150.000. 3.2.6. Στατιστικά στοιχεία Μετά την εκτέλεση του benchmark υπάρχει πλέον η δυνατότητα να μ ετρηθούν τα μ εγέθη που χρειάζεται η ανάλυση. Στην παρούσα μ ελέτη σχεδιάσαμ ε 2 στατιστικά μ εγέθη. Συγκεκριμ ένα, για κάθε αίτημ α υπολογίζονται οι λόγοι: Συνολικός χρόνος εκτέλεσης του αιτήμ ατος προς τον χρόνο εκτέλεσης όλου του SQL optimizer ( σε ποσοστό %) Συνολικός χρόνος εκτέλεσης του αιτήμ ατος προς τον χρόνο εκτέλεσης του κάθε μ έρους του SQL optimizer ( σε ποσοστό %). Αυτό περιλαμ βάνει τα 8 μ έρη του SQL optimizer όπως αυτά περιγράφηκαν σε προηγούμ ενη ενότητα ( 3.2.2). 3.2.7. Χρήση όλων των στοιχείων μαζί Για την αυτόμ ατη εκτέλεση όλων των μ ερών του framework χρησιμ οποιείται ένα shell script, ο κώδικας του οποίου παρουσιάζεται στο παράρτημ α της ενότητας 12. Το script αυτό αναλαμ βάνει να εκτελέσει αυτόμ ατα τα διαφορετικά σενάρια του MySQL server, ένα συγκεκριμ ένο αριθμ ό φορών το καθένα. Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 23

3.3. Σύνοψη Στο κεφάλαιο αυτό παρουσιάστηκε η δομ ή και η υλοποίηση του framework και των τμημ άτων που το αποτελούν. Στον MySQL server έχει ενεργοποιηθεί το profiling API το οποίο κρατά στατιστικά κατά την διάρκεια της εκτέλεσης των SQL αιτημ άτων. Τα SQL αιτήμ ατα τα στέλνει ένας client, στην περίπτωση της μ ελέτης το OSDB benchmark. Προκειμ ένου να καταγράφονται τα στατιστικά στοιχεία που θέλουμ ε, στον κώδικα της MySQL έγιναν οι κατάλληλες προσθήκες, εισάγοντας κλήσεις του profiling API. Τα δεδομ ένα όμ ως, που μ ας παρέχει το API αυτό, αποθηκεύονται προσωρινά, επομ ένως φτιάξαμ ε μ ια βάση δεδομ ένων στην οποία θα αποθηκεύονται μόνιμ α τα δεδομ ένα. Προκειμ ένου να υλοποιηθεί η αυτόμ ατη αποθήκευση των δεδομ ένων, χρησιμ οποιήθηκε ο MySQL proxy, ο οποίος παρεμ βάλλεται ανάμεσα στον server και στον client. Κάθε φορά που έρχεται ένα SQL αίτημ α, ο MySQL proxy φροντίζει να επιλέξει από το profiling API τα δεδομ ένα που θέλουμ ε και να τα αποθηκεύσει μόνιμ α στην βάση δεδομ ένων που έχουμ ε δημ ιουργήσει. Για την αυτόμ ατη εκτέλεση διαφορετικών περιπτώσεων και την συλλογή των στατιστικών χρησιμ οποιείται ένα shell script το οποίο φροντίζει για την ομ αλή και διαδοχική εκτέλεση όλων των λειτουργιών. Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 24

4. Χρήση του framework Στο κεφάλαιο αυτό, το framework που αναλύθηκε στο προηγούμ ενο κεφάλαιο, χρησιμ οποιείται μ ε στόχο καταρχάς να γίνει επίδειξη της λειτουργίας του και κατά δεύτερον την εξαγωγή κάποιων πρώτων συμπερασμ άτων από την χρήση μ ε το OSDB benchmark. Η δομ ή του κεφαλαίου είναι η εξής: στην ενότητα 4.1 θα αναφέρουμ ε τα σενάρια τα οποία χρησιμ οποιήθηκαν στην μ ελέτη. Στην ενότητα 4.2 γίνεται μ ια παρουσίαση του περιβάλλοντος στο οποίο έγινε η χρήση του framework και η διαδικασία εγκατάστασης. Στην ενότητα 4.3 παρουσιάζουμ ε τα αποτελέσμ ατα της χρήσης του OSDB benchmark και την επιβάρυνση που επιφέρει η χρήση του framework και του profiling API στην εκτέλεση των SQL αιτημ άτων από τον server. Στην ενότητα 4.4 αξιολογείται το framework και στην ενότητα 4.5 δίνεται η σύνοψη του κεφαλαίου. 4.1. Σενάρια χρήσης Το framework χρησιμ οποιήθηκε στα εξής 3 σενάρια, μ ε το profiling API ενεργοποιημ ένο σε όλα: Σενάριο Α: δεν έχουν προστεθεί σημ εία ελέγχου εκτός από αυτά που ήδη υπάρχουν στον πηγαίο κώδικα. Σενάριο Β: έχουν προστεθεί επιπλέον σημ εία ελέγχου μ έσα στον κώδικα του sql optimizer. Από αυτά που αναφέρονται στην ενότητα ( 3.2.2) χρησιμοποιήθηκαν μ όνο όσα αφορούν το τμήμ α statistics. Σενάριο C: έχουν προστεθεί επιπλέον σημ εία ελέγχου μ έσα στον κώδικα του sql optimizer. Από αυτά που αναφέρονται στην ενότητα ( 3.2.2) χρησιμοποιήθηκαν όσα αφορούν τόσο το τμήμ α statistics όσο και το τμήμ α optimizing. Στο σενάριο Α ο MySQL server έγινε build από τον πηγαίο κώδικα, αυτούσιο όπως διανέμ εται από το site της εταιρίας. Στα σενάρια Β και C ο MySQL server έγινε build αφού πρώτα έχει προστεθεί το κατάλληλο patch στον πηγαίο κώδικα. Τα patch παρουσιάζονται στο Παράρτημ α 9. Ο λόγος για τον οποίο εκτελούνται τα 3 διαφορετικά σενάρια είναι για να βρεθεί η επιβάρυνση που επιφέρει το profiling API στην εκτέλεση του προγράμμ ατος. Δεν βρέθηκε τρόπος να μ ετρηθεί η επιβάρυνση για όλο το API, συγκρίνοντας δηλαδή τον χρόνο εκτέλεσης ενός αιτήμ ατος μ ε το API ενεργοποιημ ένο και απενεργοποιημ ένο. Ωστόσο είναι εφικτές οι μ ετρήσεις μ ε διαφορετική, σε έκταση, χρήση του API. Έτσι στο σενάριο Α υπάρχει η μ ικρότερη χρήση του API, στο Β υπάρχει περισσότερη χρήση και στο C ακόμ α περισσότερη. Βρίσκοντας τις διαφορές στον χρόνο εκτέλεσης των αιτημ άτων στα διαφορετικά σενάρια μ πορεί να μ ετρηθεί η σχετική επιβάρυνση μ εταξύ των σεναρίων. Πλαίσιο ανάλυσης του φόρτου εργασίας του SQL optimizer στο Σύστημ α Δ ιαχείρισης Βάσεων Δεδομ ένων MySQL 25