Κεφάλαιο 3 ιατύπωση και επεξεργασία ερωτηµάτων

Transcript

1 Κεφάλαιο 3 ιατύπωση και επεξεργασία ερωτηµάτων 3.1 Εισαγωγή Know all men, he said, time's ruins build eternity's mansions. James Joyce, Ulysses, 14: Oxen of the Sun (1922) Έχει ήδη επισηµανθεί ότι ένα αποθηκευµένο σύνολο δεδοµένων είναι χρήσιµο ιδίως όταν σηµαντικά τµήµατά του εµπλέκονται επανειληµµένα σε ερωτήµατα, ενώ οι αλλαγές ή τροποποιήσεις των στοιχείων δεν είναι συχνές και κατά κανόνα αφορούν µικρό µόνο αριθµό εγγραφών. Αντίθετα, όταν τα δεδοµένα υφίστανται διαρκείς αλλαγές (ακόµη και απλώς εισαγωγές νέων στοιχείων), τότε η µορφή του ρεύµατος δεδοµένων κρίνεται καταλληλότερη. Ο ίδιος ισχυρισµός ευσταθεί και όταν δεν υπάρχει λόγος ή δεν συµφέρει να υποβάλλονται αλλεπάλληλα τα ίδια ερωτήµατα σε µεγάλο όγκο στοιχείων. Αν είναι δυνατόν, τα δεδοµένα θα πρέπει να περάσουν από ταυτόχρονη επεξεργασία για όλα τα ερωτήµατα στα οποία εµπλέκονται, χωρίς να χρειάζεται να καθηλωθεί η εκτέλεση κάποιων άλλων ή να διακοπεί η εισροή νέων στοιχείων. Σε καµιά περίπτωση δεν συµφέρει να εκτελείται κάθε ερώτηµα χωριστά, εφόσον είναι ευνόητο ότι ανάµεσα στο πλήθος των ερωτηµάτων θα υπάρχουν αρκετά που εµφανίζουν οµοιότητες µεταξύ τους (λ.χ. στις συνθήκες επιλογής πλειάδων). Εκ πρώτης όψεως, φαίνεται ότι η γλώσσα ερωταποκρίσεων (query language) για τα συστήµατα ρευµάτων δεδοµένων θα ήταν δυνατόν να προκύψει από κάποια ήδη υπάρχουσα, λ.χ. µια σχεσιακή γλώσσα όπως η SQL, αντικαθιστώντας απλώς τις αναφορές σε σχέσεις µε τα αντίστοιχα ρεύµατα. Πράγµατι, η σηµασιολογία των ερωτηµάτων όταν καλύπτει περιπτώσεις όπου συµβαίνει απλώς προσθήκη νέων δεδοµένων (append-only) δεν εµφανίζει σηµαντικές διαφοροποιήσεις. Ωστόσο, αν τα ερωτήµατα γίνουν πιο σύνθετα, εµπλέκοντας τελεστές συνάθροισης (aggregates), υποερωτήµατα (subqueries) ή συσχετισµούς µε στατικούς πίνακες, τότε αναµφίβολα απαιτούνται σηµαντικές τροποποιήσεις και προσθήκες στις συντακτικές δοµές της γλώσσας ερωταποκρίσεων. 61

2 ιατύπωση και επεξεργασία ερωτηµάτων. Λεπτοµερή στατιστικά στοιχεία για τα ρεύµατα δεδοµένων δεν είναι δυνατόν να συλλεγούν ώστε να υποβοηθήσουν τη βελτιστοποίηση ερωτηµάτων. Απεναντίας, η ύπαρξη αστάθµητων παραγόντων, όπως πιθανή απώλεια δεδοµένων κατά τη µετάδοση, οι απρόοπτες βλάβες στο δίκτυο µεταφοράς των στοιχείων, η πολυπλοκότητα των πηγών των δεδοµένων (που µπορεί να είναι και αρκετά αποµακρυσµένες), καθιστούν ακόµη δυσχερέστερη την επεξεργασία των ερωτηµάτων. Με την πάροδο του χρόνου, δεν αποκλείεται το σύνολο των ερωτηµάτων που είναι ενεργά στο σύστηµα να µεταβάλλεται, καθώς οι χρήστες αποσύρουν παλιότερα ερωτήµατα και υποβάλλουν καινούργια. Εάν το σύστηµα επιδεικνύει προσαρµοστικότητα (adaptivity) στην τρέχουσα κατάσταση, τότε η εκτέλεση των ερωτηµάτων θα µπορούσε να διευκολυνθεί δραµατικά. Επιπλέον, εφόσον η εκτέλεση ενός ερωτήµατος εντάσσεται στο πλαίσιο µιας γενικότερης επεξεργασίας, είναι ευνόητο ότι τα αποτελέσµατα κάποιων ερωτηµάτων µπορεί να επηρεάζουν την εξέλιξη κάποιων άλλων. Αφού λοιπόν οι χρήστες βρίσκονται σε διαρκή αλληλεπίδραση µε το σύστηµα, είναι πιθανόν να τροποποιούν παραµέτρους ή και την ίδια τη δοµή των ερωτηµάτων τους βασισµένοι στα πιο πρόσφατα στοιχεία που έχουν προκύψει. Άρα, καθώς τα δεδοµένα εξάγονται, η επεξεργασία των ερωτηµάτων θα πρέπει να προσαρµόζεται οµαλά στις επικρατούσες συνθήκες. Στα κατά κύριο λόγο αλληλεπιδραστικά συστήµατα ρευµάτων δεδοµένων το κλασικό επαναληπτικό µοντέλο του επεξεργαστή ερωτηµάτων δεν κρίνεται αποδοτικό. Όντως, δεν φαίνεται καθόλου λογικό η επεξεργασία να καθυστερεί αναµένοντας να ολοκληρωθεί η εκτέλεση κάποιων ερωτηµάτων, µήτε να επιστραφούν αποτελέσµατα από αργόσυρτες ιστοσελίδες ή από αισθητήρες που έχουν προσωρινά τεθεί εκτός λειτουργίας. Σε ένα συµβατικό Σ Β, τα ερωτήµατα εκτελούνται όταν ο χρήστης απαιτήσει την εκτέλεσή τους, η οποία οδηγεί σε µια ακολουθία δοσοληψιών (transactions), κατά την υλοποίηση των οποίων, όπως είναι γνωστό, το σύστηµα εγγυάται τις ιδιότητες ACID: την αυτονοµία (Atomicity), δηλαδή ότι όλες οι ενέργειες που ορίζονται από τη δοσοληψία θα ενταχθούν στη βάση δεδοµένων ή δεν θα ισχύσει καµµία, τη συνέπεια (Consistency) ως προς την εκπλήρωση των περιορισµών που τίθενται, λ.χ. από τους συσχετισµούς, την αποµόνωση (Isolation), που υποδηλώνει ότι κάθε δοσοληψία πρέπει να εµφανίζεται ότι εκτελείται ανεξάρτητα από τις υπόλοιπες και τη µονιµότητα (Durability), ορίζοντας ότι, όταν η δοσοληψία ολοκληρωθεί, τότε τα αποτελέσµατά της δεν θα µπορούν πλέον να αναιρεθούν. Αντίθετα, σ ένα Σύστηµα ιαχείρισης Ρεύµατος εδοµένων αναµένεται να κυριαρχούν τα ερωτήµατα διαρκείας. Ο έλεγχος αυτών των ερωτηµάτων γίνεται από το σύστηµα, το οποίο πρέπει να είναι σε θέση να παρακολουθεί το ρυθµό µεταβολής των στοιχείων, τον τρόπο υπολογισµού των συνθηκών και την παραγωγή των αποτελεσµάτων, πάντοτε σε συνδυασµό µε ενδεχόµενες παρεµβάσεις των χρηστών κατά τη διάρκεια της εκτέλεσης. Άρα, τεχνικές όπως τα κυλιόµενα παράθυρα, οι συνόψεις, οι προσεγγιστικές απαντήσεις και η προσαρµοστικότητα της επεξεργασίας των ερωτηµάτων αποκτούν ιδιαίτερη σηµασία. Επιπλέον, ουσιώδη συστατικά στοιχεία ενός Σ Β ενδεχοµένως 62

3 3.1 Εισαγωγή απαιτούν αναθεώρηση, όπως η γλώσσα ερωταποκρίσεων (query language), η διαχείριση πόρων και ιδιαίτερα του αποθηκευτικού χώρου, οι διεπαφές (interface) χρηστών και εφαρµογών καθώς και η υποστήριξη δοσοληψιών (transaction support). 3.2 Γλώσσα ερωταποκρίσεων ρευµάτων δεδοµένων Αναµφίβολα, οι χρήστες θα πρέπει να είναι σε θέση να διατυπώνουν τα ερωτήµατά τους προς ένα σύστηµα διαχείρισης ρευµάτων δεδοµένων µε σαφή και εύληπτο τρόπο. Πέραν αυτού, η αναγκαιότητα δηµιουργίας µιας ειδικής γλώσσας ερωταποκρίσεων (Stream query language), θα πρέπει να συνεξεταστεί και µε άλλους παράγοντες, όπως λ.χ. η απαίτηση περιορισµού των αναγκών σε µνήµη (και αποθηκευτικό χώρο εν γένει), η δυνατότητα εξαγωγής του αποτελέσµατος επίσης µε τη µορφή ρεύµατος δεδοµένων ή η χρήση περιλήψεων στοιχείων από το παρελθόν. Μεγάλο ρόλο παίζει επίσης η φύση των ερωτηµάτων: είναι αναµενόµενο ότι ιδιαίτερο χειρισµό απαιτούν ορισµένοι τύποι ερωτηµάτων που υπολογίζουν λ.χ. αποτελέσµατα συναθροίσεων (aggregates) ή προβαίνουν σε συνδέσεις (joins) µεταξύ ρευµάτων. Ανάµεσα στα πρωτότυπα συστήµατα ρευµάτων δεδοµένων που έχουν αρχίσει να υλοποιούνται, υπάρχει διχογνωµία στο καθοριστικό ζήτηµα της γλώσσας ερωταποκρίσεων. Μερικά συστήµατα (STREAM, Cougar, TelegraphCQ) προκρίνουν µια εκδοχή της SQL (Structured Query Language) µε πρόσθετους τελεστές, δηλαδή µια δηλωτική (declarative) γλώσσα, ενώ σε άλλα (AURORA, Hancock) υπερισχύει ένας διαδικαστικός (procedural) τρόπος διατύπωσης των ερωτηµάτων. Η υιοθέτηση της SQL ως γλώσσας ερωταποκρίσεων αποτελεί ασφαλώς την πλέον προφανή επιλογή, κι όχι µόνο χάρη στην εξοικείωση µ αυτήν ενός µεγάλου αριθµού χρηστών συστηµάτων βάσεων δεδοµένων. Η SQL παρέχει µια πολύ καλή βάση για την επιζητούµενη γλώσσα, αφού η σηµασιολογία (semantics) των σχεσιακών τελεστών είναι ήδη σαφώς ορισµένη, άρα διαθέσιµη προς αξιοποίηση και για περιπτώσεις ρευµάτων δεδοµένων. Ως προς τις επεκτάσεις της, εκείνες που κρίνονται θεµελιώδεις αφορούν δοµές για την υποστήριξη χρονικών ή άλλης µορφής παραθύρων (windows), µεθόδων δειγµατοληψίας (sampling) καθώς και τον από κοινού χειρισµό ρευµάτων δεδοµένων και στατικών σχέσεων (πινάκων). Ωστόσο, δεν µπορεί να αποκλειστεί το ενδεχόµενο οι χρήστες να θέσουν προς επεξεργασία ερωτήµατα που περιέχουν περίπλοκες εκφράσεις σε SQL. Τότε, δεν µπορεί να προβλεφθεί επακριβώς η αποτελεσµατικότητα της επεξεργασίας τους, σε σχέση µε τους περιορισµούς που επιβάλλονται από το µοντέλο ρευµάτων δεδοµένων. Χρησιµοποιώντας δηλωτικά ερωτήµατα οι χρήστες δεν είναι απαραίτητο να υπεισέρχονται σε ζητήµατα, όπως ο τρόπος παραγωγής ή η δοµή τήρησης των δεδοµένων στην πηγή ή ποιος είναι ο καταλληλότερος τρόπος επεξεργασίας των στοιχείων, ώστε να υπολογιστεί τελικά η απάντηση. Εποµένως, τα ερωτήµατα τίθενται µ έναν «αφαιρετικό» τρόπo, πανοµοιότυπο ως προς τις δοµές της διατύπωσής τους (λ.χ. εντολές SELECT-PROJECT-JOIN), αφήνοντας στο σύστηµα την ευθύνη εκλογής του βέλτιστου τρόπου υπολογισµού των αντίστοιχων απαντήσεων. 63

4 ιατύπωση και επεξεργασία ερωτηµάτων. Αντίθετα, ένας διαδικαστικός µηχανισµός υποβολής των ερωτηµάτων επιβάλλει στους χρήστες να ασχοληθούν σχολαστικά µε τις λεπτοµέρειες της υλοποίησης του αντίστοιχου εξειδικευµένου προγράµµατος, παρέχοντάς τους µεγαλύτερη δυνατότητα ελέγχου σε ό,τι αφορά την ακολουθία των ενεργειών που τελικά οδηγούν στη διεκπεραίωση του ερωτήµατος. Κατά συνέπεια, θα πρέπει λ.χ. να οριστούν µεταβλητές για την αναπαράσταση των ποικίλων πηγών δεδοµένων ή για τους γράφους που απεικονίζουν τη ροή των στοιχείων εντός του συστήµατος, δηλαδή την αλληλουχία των τελεστών που οδηγεί στην έξοδο. Επιγραµµατικά, όταν υιοθετείται µια δηλωτική γλώσσα, το σύστηµα καθορίζεται περισσότερο από τα δεδοµένα που πρόκειται να δεχθεί (datadriven), παρά από τα προγράµµατα που θα κληθεί να υποστηρίξει (program-driven) όταν τα ερωτήµατα υλοποιούνται ως διαδικασίες. Παρόλα αυτά, είναι χαρακτηριστικό ότι κάποια συστήµατα παρέχουν εναλλακτικούς τρόπους υποβολής ερωτηµάτων: λ.χ. στο STREAM υπάρχει ένας µηχανισµός απευθείας υποβολής προσχεδίων εκτέλεσης ερωτηµάτων. Τα προσχέδια αυτά εκφράζονται σε επίπεδο άλγεβρας ρευµάτων δεδοµένων, το οποίο αποτελεί τη βάση δόµησης της αντίστοιχης γλώσσας ερωταποκρίσεων. Παροµοίως, το AURORA επιτρέπει στους χρήστες να διατυπώσουν τα ερωτήµατά τους και σε SQL, αν και στη συνέχεια οι εκφράσεις µετατρέπονται σε γράφους τελεστών που συµβολίζουν τη ροή των δεδοµένων προς την έξοδο. Τέλος, για ορισµένου τύπου εφαρµογές (λ.χ. δίκτυα αισθητήρων, χρηµατοοικονοµικά συστήµατα) η γνώση της ακολουθίας (sequence) των πλειάδων που αποτελούν το ρεύµα δεδοµένων έχει ιδιάζουσα σηµασία. Κατά συνέπεια, ήδη ανεπτυγµένες επεκτάσεις της SQL µε ενσωµατωµένη υποστήριξη χρονοσειρών ή κάποιες άλλες που επιτρέπουν χειρισµό διατεταγµένων σχέσεων (ordered relations), θα µπορούσαν να συνεισφέρουν σε σηµαντικό βαθµό στη διαµόρφωση της γλώσσας ερωταποκρίσεων. Γλώσσα ερωταποκρίσεων Είσοδος Τελεστές Παραθυρικές δοµές Εφαρµογές ATLaS Ρεύµατα Σχεσιακοί, UDAs? (Επαναληπτική εκτέλεση)? (Περιοδική εκτέλεση) Εξόρυξη δεδοµένων Cougar Ρεύµατα Σχεσιακοί (κυρίως αθροιστικοί) Σχεσιακοί, απεικόνισης σχέσεων σε ρεύµατα ίκτυα αισθητήρων STREAM CQL TelegraphCQ Ρεύµατα, σχέσεις Ρεύµατα, σχέσεις Σχεσιακοί Κυλιόµενα (προς το παρόν) Κυλιόµενα, Χρονικού οροσήµου, Χρονικής ζώνης Γενικού σκοπού ίκτυα αισθητήρων Πίνακας 3.1: Οι κυριότερες γλώσσες ερωταποκρίσεων για ρεύµατα δεδοµένων (µε βάση SQL). 64

5 3.2 Γλώσσα ερωταποκρίσεων ρευµάτων δεδοµένων Η SQL ως βάση της γλώσσας ερωταποκρίσεων ρευµάτων δεδοµένων Όπως ήδη αναφέρθηκε, η SQL παρέχει συµπαγή και συνάµα επαρκή βάση για τον ορισµό γλώσσας ερωταποκρίσεων σε συστήµατα που πρόκειται να διαχειριστούν ρεύµατα δεδοµένων. Όµως, αφενός θα πρέπει να γίνουν οι απαραίτητες προσθήκες, αφετέρου δε η σηµασιολογία (semantics) κάποιων δοµών της γλώσσας θα πρέπει ν αλλάξει ή να επαυξηθεί κατάλληλα. Καταρχάς, στην πρόταση FROM των εντολών SQL µπορεί να αναφέρονται πλέον και ρεύµατα δεδοµένων, πέραν βεβαίως των συνήθων στατικών σχέσεων. Σε ό,τι αφορά τις στατικές σχέσεις (relations) που είναι δυνατόν να υπάρχουν στο σύστηµα, αυτές θεωρούνται µη διατεταγµένες. Φυσικά, επιτρέπονται οι συνήθεις δοσοληψίες (transactions) όπως και στα τυπικά Σ Β, δηλαδή εισαγωγή (insertion), διαγραφή (deletion) και ενηµέρωση (update) εγγραφών, µε την προσθήκη του κατάλληλου χρονικού οροσήµου (timestamp) στην καθεµιά. Ως αποτέλεσµα της επεξεργασίας ερωτηµάτων ή υποερωτη- µάτων σε ρεύµατα δεδοµένων είναι δυνατόν να προκύψουν στατικές σχέσεις. Ωστόσο, η ουσιαστική αλλαγή σε σχέση µε την τυπική δοµή της SQL συνίσταται στον τρόπο χειρισµού των χρονικών παραµέτρων, κυρίως του χρονικού οροσήµου (timestamp) των στοιχείων. Έτσι, κρίνεται απαραίτητη η επέκταση της γλώσσας ώστε να παρασχεθεί δυνατότητα ορισµού χρονικών παραθύρων (λ.χ. κυλιόµενων παραθύρων, sliding windows). Η τυπική SQL προβλέπει την έννοια του χρονικού προσδιορισµού (timestamps) ώστε ο χρήστης µπορεί να αναφερθεί ρητώς σε αυτούς, αλλά ο σχηµατισµός ερωτηµάτων µε κυλιόµενα παράθυρα είναι µάλλον δυσχερής. Η νεότερη εκδοχή της γλώσσας SQL-99, επιτρέπει τη σύνταξη εντολών που εµπλέκουν κυλιόµενα παράθυρα, παρέχοντας δοµές για τον υπολογισµό κινούµενων µέσων όρων (moving averages) καθώς και τελεστές συνάθροισης (aggregates) σε κυλιόµενα παράθυρα. Μολονότι οι προσθήκες αυτές οπωσδήποτε διευκολύνουν το χειρισµό ορισµένων κυρίως συναθροιστικών ερωτηµάτων σε ρεύµατα δεδοµένων, εν τούτοις δεν επαρκούν όταν χρειαστεί να εφαρµοστούν και σε άλλες λειτουργίες, λ.χ. τη σύνδεση (join). Ο ορισµός παραθύρων στα στοιχεία του ρεύµατος έχει νόηµα µόνο εάν τα δεδοµένα καταφθάνουν στο σύστηµα µε κάποια διάταξη. Μια πρώτη προσέγγιση θα µπορούσε να είναι η καταγραφή από το σύστηµα της σειράς άφιξης κάθε στοιχείου σε ένα πρόσθετο πεδίο που δηµιουργείται ειδικά, ως έµµεσος (implicit) τρόπος προσδιορισµού της σειράς. Ωστόσο, υπάρχουν περιπτώσεις όπου κρίνεται σκόπιµο η πληροφορία της σειράς ταξινόµησης να αποτελεί µέρος του ίδιου του ρεύµατος. Όταν ακολουθείται αυτή η τακτική, ένα πεδίο του ρεύµατος χαρακτηρίζεται ρητώς (explicitly) ως εκείνο που φέρει χρονική ένδειξη. Τότε, το ρεύµα δεδοµένων µπορεί να θεωρηθεί ως ένα σύνολο ζευγών (πλειάδα, χρονικός προσδιορισµός) της µορφής S={(s 1, t 1 ), (s 2, t 2 ),, (s n, t n ), όπου το στοιχείο (s i, t i ) δηλώνει ότι η πλειάδα s i καταφθάνει στο σύστηµα τη χρονική στιγµή t i. Θα πρέπει επίσης να ληφθεί υπόψη ότι ρεύµατα δεδοµένων δεν εισέρχονται µόνο από τις πηγές δεδοµένων, αλλά προκύπτουν κι ως απαντήσεις σε υφιστάµενα ερωτήµατα ή υποερωτήµατα. Ο προσδιορισµός της ταξινόµησης µπορεί λοιπόν να έχει την µορφή ενός χρονικού οροσήµου (timestamp) αλλά θα µπορούσε να είναι και ένας αύξων αριθµός στην ακολουθία, υπό τον όρο ότι το πεδίο ορισµού των τιµών επιτρέπει ολική διάταξη 65

6 ιατύπωση και επεξεργασία ερωτηµάτων. (totally ordered domain) και η απόσταση µεταξύ τιµών µπορεί να µετρηθεί (λ.χ. χρονικό διάστηµα ή διαφορά αύξοντος αριθµού) ώστε να µπορεί να δηλωθεί το παράθυρο. Στη συνέχεια σκιαγραφούνται επιλεκτικά στοιχεία κάποιων γλωσσών ερωταποκρίσεων που έχουν προταθεί για τη διαχείριση ρευµάτων δεδοµένων Η γλώσσα ερωταποκρίσεων του συστήµατος Cougar Τα ερωτήµατα που τίθενται στο σύστηµα Cougar ακολουθούν την εξής διάταξη: SELECT <attributes, aggregates> FROM <Streamed Sensordata> WHERE <predicates> GROUP BY <attributes> HAVING <predicate> DURATION <time interval> EVERY <time span ε> Η σηµασιολογία των ερωτηµάτων αρκετά προφανής: η πρόταση SELECT περιλαµβάνει τις ιδιότητες και τους πιθανούς τελεστές συνάθροισης (MAX, MIN, AVG, SUM, COUNT) οι οποίοι θα εφαρµοστούν επί των πλειάδων των ρευµάτων που αναφέρονται στην πρόταση FROM. Ας σηµειωθεί ότι µετά το FROM µπορεί να αναφέρονται πολλαπλά ρεύµατα, δηλαδή υπάρχει πρόνοια για συνδέσεις (join) µεταξύ ρευµάτων. Κατά τη γνωστή σύνταξη της SQL, στην πρόταση WHERE παρατίθενται οι συνθήκες επιλογής των πλειάδων που θα συµµετάσχουν στους υπολογισµούς, και ακολουθεί η προαιρετική οµαδοποίηση (GROUP BY) των στοιχείων βάσει των αντίστοιχων ιδιοτήτων, εφόσον ζητούνται συναθροιστικά στοιχεία γι αυτές, µε ενδεχόµενη χρήση κριτηρίων (HAVING). Ιδιαίτερη σηµασία έχουν οι προσθήκες που έγιναν για την υποστήριξη των ερωτηµάτων διαρκείας. Εφόσον τέτοια ερωτήµατα προβλέπεται ότι θα εκτελούνται επί µακρόν, η πρόταση DURATION προορίζεται για το παράθυρο από το οποίο θα επιλεγούν οι πλειάδες βάσει της χρονικής τους ένδειξης. Επιπλέον, η παραγωγή των αποτελεσµάτων προχωρά σταδιακά, δηλαδή ανά τακτά χρονικά διαστήµατα που το οµοιόµορφο µέγεθός τους (η περίοδος ε) δηλώνεται στην πρόταση EVERY. Βεβαίως, επειδή το σύστηµα αποσκοπεί στη διαχείριση δικτύου αισθητήρων, οι οποίοι είναι διεσπαρµένοι στο χώρο, πιθανότατα και άλλα στοιχεία της γλώσσας ίσως όχι µόνο χωρικοί τελεστές ή παράµετροι πρέπει να επεκταθούν ή να οριστούν εξαρχής. Παράδειγµα Στο ακόλουθο ερώτηµα θα πρέπει να δηλωθεί εκ νέου η σηµασιολογία του τελεστή IN, ο οποίος εξετάζει τη θέση κάθε αισθητήρα σε σχέση µε την περιοχή µελέτης (Region) που πιθανόν ορίζεται. Το ερώτηµα υπολογίζει το µέσο όρο (AVG) κάποιων µετρήσεων ενός ρεύµατος δεδοµένων, όπως θα καταγραφούν στην επόµενη ώρα (3600 δευτερόλεπτα) και το αποτέλεσµα θα εκδίδεται κάθε 10 δευτερόλεπτα, εφόσον υπερβαίνει µια τιµή κατωφλίου T: SELECT AVG(S.value) FROM StreamData S WHERE S.location IN Region HAVING AVG(S.value)>T 66

7 3.2 Γλώσσα ερωταποκρίσεων ρευµάτων δεδοµένων DURATION (now, now+3600) EVERY Η γλώσσα ερωταποκρίσεων του συστήµατος STREAM Το σύστηµα STREAM προχωρά στον ορισµό µιας δηλωτικής γλώσσας ερωταποκρίσεων (declarative query language) µε την ονοµασία CQL (Continuous Query Language), ειδικά για τα ερωτήµατα διαρκείας. Οι κύριες διαφοροποιήσεις από την σύνταξη των εντολών επιλογής της SQL εντοπίζονται στον ορισµό των παραθύρων και στην δειγµατοληψία των στοιχείων του ρεύµατος. Η τυπική δοµή ενός ερωτήµατος είναι η ακόλουθη: SELECT <attributes, aggregates> FROM <Relations> <Streams> [PARTITION BY <Stream attributes> ROWS <number of rows> { PRECEDING RECENT } RANGE <time> PRECEDING WHERE <filtering predicates>] SAMPLE <percentage sampling rate> WHERE <predicates> GROUP BY <attributes> HAVING <predicates> Ο προσδιορισµός παραθύρων στα στοιχεία ενός ρεύµατος αποτελεί µια προσθήκη στην SQL και παριστάνεται µε αγκύλες [ ], αµέσως µετά την αναφορά του ρεύµατος δεδοµένων στην πρόταση FROM της εντολής. Η χρήση του παραθύρου είναι προαιρετική και αποτελείται από τα εξής συστατικά στοιχεία: Προηγείται µια προαιρετική πρόταση διαµέρισης (partition) των στοιχείων σε διάφορες οµάδες, για καθεµιά από τις οποίες υπολογίζεται ένα παράθυρο, επιλέγονται τα επιµέρους στοιχεία και τελικά αυτά συγχωνεύονται σ ένα συνολικό αποτέλεσµα. Για να αποφευχθεί τυχόν σύγχυση µε τα ερωτήµατα συνάθροισης (aggregates) που πραγµατοποιούν οµαδοποιήσεις των αποτελεσµάτων, η γνωστή πρόταση GROUP BY αντικαθίσταται από την PARTITION BY. Η δήλωση του µεγέθους του παραθύρου είναι υποχρεωτική, είτε καθορίζοντας τον αριθµό των στοιχείων (λ.χ. οι 10 πιο πρόσφατες εγγραφές), που βρίσκονται εντός του παραθύρου («φυσικές» ενότητες), είτε τον χρονικό ορίζοντα (π.χ. 24 ώρες) που καλύπτει το παράθυρο («λογική» ενότητα). Ακολουθώντας πιστά τις προδιαγραφές της SQL-99, οι φυσικές ενότητες συντάσσονται µε τον όρο ROWS (λ.χ. ROWS 10 PRECEDING), ταξινοµηµένες κατ απόλυτη σειρά βάσει του χρονικού τους οροσήµου. Για τις λογικές ενότητες υπάρχει η δοµή RANGE (π.χ. RANGE 24 HOURS PRECEDING). Εναλλακτικά, οι «φυσικές» ενότητες µπορούν να οριστούν µε τη δοµή RECENT, µε την οποία δηλώνεται πάλι ένα κυλιόµενο παράθυρο που περικλείει έναν συγκεκριµένο αριθµό πλειάδων, χωρίς ωστόσο να τίθεται κανείς περιορισµός σχετικά µε την σειρά ταξινόµησής τους, η οποία αφήνεται στην ευχέρεια του Σ Ρ. Αυτός ο δεύτερος τρόπος ορισµού του παραθύρου έχει µεγάλη σηµασία όταν κρίνεται 67

8 ιατύπωση και επεξεργασία ερωτηµάτων. απαραίτητο να επιταχυνθεί η επεξεργασία του ερωτήµατος, χωρίς τις καθυστερήσεις που συνεπάγεται τυχόν απόπειρα ταξινόµησης των ενδιάµεσων αποτελεσµάτων (βλ. ενότητα 3.2.6). Τέλος, µπορεί να προστεθεί προαιρετικά και µια συνθήκη επιλογής στοιχείων (filtering predicate), µε χρήση της τυπικής έκφρασης WHERE, ώστε να περιοριστούν βάσει των επιθυµητών κριτηρίων οι πλειάδες που επιστρέφονται από την εφαρµογή του παραθύρου. Αξίζει να τονιστεί η διαφορά αυτού του τρόπου επιλογής πλειάδων, σε σχέση µε την πρόταση WHERE που ακολουθεί στο κύριο σκέλος του ερωτήµατος, η οποία θα εφαρµοστεί όταν το παράθυρο θα έχει δώσει ένα υποσύνολο των πλειάδων. Εάν δεν προσδιοριστεί κανένα παράθυρο, εξ ορισµού θεωρείται ως παράθυρο η έκφραση [RANGE UNBOUNDED PRECEDING]. Επιπλέον, το αποτέλεσµα ενός ερωτήµατος χωρίς τελεστές συνάθροισης, το οποίο περιλαµβάνει τουλάχιστον ένα ρεύµα δεδοµένων, θα πρέπει να θεωρηθεί ότι λαµβάνει πάντοτε τη µορφή ρεύµατος δεδοµένων. Εκτός από τον ορισµό παραθύρων, το σύστηµα STREAM προβλέπει την προαιρετική δειγµατοληψία των στοιχείων του ρεύµατος, αντί να ληφθεί το σύνολο των δεδοµένων. Έτσι, η απάντηση σε κάποιο ερώτηµα µπορεί να υπολογιστεί επί ενός τυχαίου δείγµατος (random sample) των πλειάδων του ρεύµατος. Η διατύπωση της έκφρασης γίνεται µε τη λέξη κλειδί (keyword) SAMPLE και παράµετρο το ρυθµό δειγµατοληψίας (sampling rate), µε τον οποίο ο χρήστης εκτιµά την πιθανότητα κάποιου µεµονωµένου στοιχείου να περιληφθεί στο δείγµα. Παρατίθενται ακολούθως µερικά διαφωτιστικά παραδείγµατα σχετικά µε την υλοποίηση των ερωτηµάτων. Παράδειγµα Έστω ότι το ρεύµα δεδοµένων αποτελείται από εγγραφές τηλεφωνικών κλήσεων, καταγράφοντας στοιχεία όπως η ταυτότητα του καλούντος, η κατηγορία της συνδιάλεξης (δηλαδή εάν είναι αστική, υπεραστική ή διεθνής), η διάρκεια µε χρονική ανάλυση που φτάνει σε επίπεδο πρώτου λεπτού, βάσει της οποίας αποφασίζεται η χρέωση, καθώς και το απαραίτητο χρονικό ορόσηµο. Οι ιδιότητες (attributes) του ρεύµατος δεδοµένων είναι λοιπόν κατ αντιστοιχία: customer_id, type, minutes, timestamp. Ας υποτεθεί λοιπόν ότι κάποιος χρήστης θέλει να υπολογίσει τη µέση διάρκεια των συνδιαλέξεων, αλλά εξετάζοντας µόνο τις δέκα πιο πρόσφατες υπεραστικές συνδιαλέξεις που έχει κάνει κάθε συνδροµητής. Το ερώτηµα συντάσσεται τότε ως εξής: SELECT AVG(S.minutes) FROM Calls S [PARTITION BY customer_id ROWS 10 PRECEDING WHERE S.type= Long Distance ] όπου η έκφραση εντός των αγκυλών προσδιορίζει το χρονικό παράθυρο που ενδιαφέρει. Παράδειγµα ιαφοροποιώντας το προηγούµενο ερώτηµα, ο χρήστης µπορεί να θελήσει τον υπολογισµό της µέσης διάρκειας των τηλεφωνηµάτων, αλλά λαµβάνοντας υπόψη µόνο όσες υπεραστικές συνδιαλέξεις συγκαταλέγονται στις 10 πιο πρόσφατες κλήσεις από κάθε πελάτη. Σε αντίθεση µε το προηγούµενο παράδειγµα, η συνθήκη σχετικά την κατηγορία των συνδιαλέξεων αναφέρεται πλέον στο σύνολο των συνδιαλέξεων που καταγράφονται στο ρεύµα δεδοµένων, έπειτα από την 68

9 3.2 Γλώσσα ερωταποκρίσεων ρευµάτων δεδοµένων εφαρµογή του παραθύρου που προσκοµίζει τις 10 πιο πρόσφατες. Γι αυτό και η συνθήκη εντάσσεται όχι στον ορισµό του παραθύρου, αλλά στο κυρίως σώµα της εντολής: SELECT AVG(S.minutes) FROM Calls S [PARTITION BY customer_id ROWS 10 PRECEDING] WHERE S.type= Long Distance Παράδειγµα Τα ερωτήµατα µπορούν να γίνουν πιο σύνθετα, όπως λ.χ. εάν ζητηθεί να υπολογιστεί η µέση διάρκεια µόνο των αστικών κλήσεων σε δείγµα 10% επί των συνδιαλέξεων που έχει πραγµατοποιήσει την τελευταία εβδοµάδα µια συγκεκριµένη κατηγορία συνδροµητών, λ.χ. όσοι διαθέτουν εταιρικό τηλέφωνο (Corporate). SELECT AVG(V.minutes) FROM ( SELECT S.type, S.minutes FROM Customers T, Calls [RANGE 7 DAYS PRECEDING] S WHERE S.customer_id=T.customer_id AND T.class= Corporate ) V SAMPLE(10) WHERE S.type= Local Το ενδιαφέρον στοιχείο στο ερώτηµα αυτό είναι ότι η σύνδεση (join) γίνεται µεταξύ ενός ρεύµατος δεδοµένων και µιας στατικής σχέσης, στο αποτέλεσµα της οποίας τελικά εφαρµόζεται δειγµατοληψία. Έτσι, η απάντηση προκύπτει βάσει µόνο ενός δείγµατος του αποτελέσµατος της σύνδεσης, δηλαδή το 10% των στοιχείων που αφορούν τις καταγεγραµµένες συνδιαλέξεις. Αφού ληφθεί το δείγµα, εφαρµόζεται ο τελεστής συνάθροισης AVG στις χρονικές διάρκειες αποκλειστικά των αστικών κλήσεων που περιέχονται σ αυτό Η γλώσσα ερωταποκρίσεων του συστήµατος ATLaS Το σύστηµα ATLaS αποτελείται από δύο κύρια µέρη: έναν διαχειριστή του αποθηκευτικού χώρου της βάσης δεδοµένων και τον επεξεργαστή της γλώσσας ερωταποκρίσεων που αποτελεί επέκταση της SQL. Ο αρχικός στόχος ήταν η εξυπηρέτηση διαφόρων εφαρµογών εξόρυξης δεδοµένων (data mining), ωστόσο η ανάπτυξη του συστήµατος επιχειρεί σταδιακά να καλύψει και εφαρµογές διαχείρισης ρευµάτων δεδοµένων. Οι δοµές που προτείνονται από το ATLaS αποτελούν επεκτάσεις της SQL προς την κατεύθυνση της ενίσχυσης των τελεστών συνάθροισης (aggregates) σε ερωτήµατα επιλογής, προβολής ή σύνδεσης (SELECT-PROJECT-JOIN), τα οποία υπολογίζονται σταδιακά (incrementally) χρησιµοποιώντας παράθυρα πάνω στα στοιχεία του ρεύµατος. Οι τελεστές µπορούν να οριστούν από τους χρήστες (User Defined Aggregates UDAs), οπότε υπάρχουν δυνατότητες προσδιορισµού µεγάλης ποικιλίας τελεστών. Η γενική µορφή που ακολουθείται στη δήλωση των παραθυρικών UDAs είναι η εξής: AGGREGATE <aggregate name> (<parameters list>) : <return type> { TABLE (<field list>) STREAM (<field list>) SOURCE <stream>; INITIALIZE : { <SQL statements> } ITERATE : { <SQL statements> } REVISE : { <SQL statements> } } 69

10 ιατύπωση και επεξεργασία ερωτηµάτων. Το ρεύµα εισόδου δηλώνεται έπειτα από τη δοµή SOURCE και το σύστηµα αναλαµβάνει να χαρακτηρίσει κάθε πλειάδα µε ένα χρονικό ορόσηµο βάσει του χρόνου άφιξής της. Οι δοµές των παραθύρων ακολουθούν σύνταξη πανοµοιότυπη µ εκείνη του συστήµατος STREAM. Ο υπολογισµός που επιτάσσει η σηµασιολογία των τελεστών συνάθροισης σε κάθε παράθυρο στηρίζεται στην παρακολούθηση της µεταβολής των περιεχοµένων του µε την πάροδο του χρόνου (delta-based computation), αξιοποιώντας τις τρεις καταστάσεις (states) που ορίζονται. Οι δύο πρώτες (INITIALIZE, ITERATE) παραµένουν ενεργές κατά τη µεταβατική περίοδο, όταν το ερώτηµα τίθεται αρχικά και δεν έχει προσεγγιστεί ακόµη το νεότερο άκρο του παραθύρου. Όταν αυτό συµβεί, όλη η επεξεργασία διεκπεραιώνεται πλέον από την κατάσταση REVISE. Το σύστηµα διατηρεί ειδικές δοµές τόσο για την τήρηση των αποτελεσµάτων (RETURN), όσο και για τις πλειάδες που απορρίπτονται (EXPIRED). Παράδειγµα Για τον υπολογισµό του µέσου όρου στα στοιχεία ενός ρεύµατος, µπορεί να οριστεί ο ακόλουθος τελεστής: AGGREGATE MyAVG(Next Int) : Real { TABLE state(tsum Int, cnt Int); INITIALIZE : { INSERT INTO state VALUES (Next, 1); } ITERATE : { UPDATE state SET tsum=tsum+next, cnt=cnt+1; } REVISE : { UPDATE state SET tsum=tsum+next-sum(select Next FROM EXPIRED), cnt=cnt+1-count(select * FROM EXPIRED); INSERT INTO RETURN SELECT tsum/cnt FROM state; } } Ο πίνακας state χρησιµεύει για τη δυναµική τήρηση του προσωρινού αθροίσµατος (tsum) και του πλήθους των στοιχείων (cnt) που έχει διέλθει από το παράθυρο. Ο τελεστής λαµβάνει κάθε φορά την επόµενη πλειάδα του ρεύµατος (Next) και αναθεωρεί τις δύο µεταβλητές, ενηµερώνοντας την έξοδο (RETURN), ενώ το σύστηµα τηρεί αυτοµάτως τις πλειάδες που εκπνέουν (EXPIRED) Η γλώσσα ερωταποκρίσεων του συστήµατος TelegraphCQ Το σύστηµα TelegraphCQ χρησιµοποιεί επίσης µια δηλωτική γλώσσα ερωταποκρίσεων (declarative query language) µε την οποία αποδίδεται ιδιαίτερη έµφαση στην περιγραφή των διαφόρων τύπων παραθύρων. Στην τυπική δοµή ενός ερωτήµατος SQL προσαρτάται µια επαναληπτική δοµή (FOR-loop) δηλώνοντας την ακολουθία των παραθύρων που θα χρησιµοποιηθούν για να αποµονώσουν τα στοιχεία των ρευµάτων που θα συµµετάσχουν στους υπολογισµούς: SELECT <attributes, aggregates> FROM <Relations> <Streams> WHERE <predicates> GROUP BY <attributes> 70

11 3.2 Γλώσσα ερωταποκρίσεων ρευµάτων δεδοµένων HAVING <predicate> FOR (t=<initial_value>;<continue_condition(t)>;<change(t)>) { WINDOWIS(<Stream A >, <left_end(t)>, <right_end(t)>); WINDOWIS(<Stream B >, <left_end(t)>, <right_end(t)>);... } Καθώς ο επαναληπτικός βρόχος εκτελείται, η µεταβλητή t διατρέχει το χρόνο και υπολογίζονται αλλεπάλληλα οι συνθήκες συνέχισης (continue_condition(t)) της εκτέλεσης και το χρονικό της βήµα (change(t)). Ακολουθεί µια σειρά από παράθυρα, καθένα από τα οποία (WINDOWIS) ορίζεται από κοινού για οµάδες ρευµάτων της πρότασης FROM, που ο χρήστης επιθυµεί να έχουν τον ίδιο ρυθµό χρονικής προόδου. Για κάθε παράθυρο δηλώνονται τα χρονικά του άκρα, δηλαδή το εύρος του σε σχέση µε τη µεταβλητή t. Εάν δεν υπάρχει ορισµένο παράθυρο για κάποια δοµή εισόδου η οποία αναφέρεται µετά το FROM, τότε αυτή εκλαµβάνεται ως στατική σχέση (πίνακας). Παρεµπιπτόντως, ο βρόχος FOR θα πρέπει να θεωρηθεί περισσότερο ως ένας χαµηλού επιπέδου µηχανισµός ελέγχου της εκτέλεσης, παρά ως µια δοµή διατύπωσης των ερωτηµάτων από τους χρήστες, εξαιτίας της πολυπλοκότητάς της. Τέλος, σηµειώνεται η αυτόµατη διακοπή της εκτέλεσης των ερωτηµάτων όταν η συνθήκη συνέχισης παύει να επαληθεύεται. Παράδειγµα Το ερώτηµα κυλιόµενου παραθύρου που τίθεται στο παράδειγµα του προηγούµενου κεφαλαίου, µπορεί να εκφραστεί ως εξής στο σύστηµα TelegraphCQ: SELECT AVG(S.minutes) FROM Calls S WHERE S.customer_id = <###> FOR (t= 05-Jan-2003 ;t<= 31-Dec-2003 >;t=+7) {WINDOWIS(S, t-6, t-2)} Προφανώς η ηµέρα θεωρείται ως χρονική µονάδα των παραθύρων, το χρονικό βήµα είναι επτά ηµέρες και τα αποτελέσµατα εξάγονται κάθε Κυριακή µε το τέλος της εβδοµάδας. Ως έναρξη της εκτέλεσης προσδιορίζεται η πρώτη Κυριακή του χρόνου (που µπορεί να προκύπτει κι από µια συνάρτηση ορισµένη από το χρήστη, λ.χ. GetFirstSunday), ενώ κάθε παράθυρο περιλαµβάνει µόνο τις πέντε εργάσιµες ηµέρες της εβδοµάδας, από ευτέρα (t-6) έως Παρασκευή (t-2). Αξίζει να παρατηρηθεί το χρονικό άλµα που γίνεται, εξαιρώντας όσα στοιχεία του ρεύµατος αφορούν τα Σαββατοκύριακα Σηµασιολογία των ερωτηµάτων διαρκείας Το βασικό στοιχείο που υποκρύπτεται πίσω τις γλωσσικές δοµές που παρουσιάστηκαν, είναι η ευχέρεια απεικόνισης (mapping) των ρευµάτων δεδοµένων σε στατικές σχέσεις (relations) και αντίστροφα. Ο στόχος είναι διττός: αφενός µεν τα δυναµικά ρεύµατα και οι στατικές σχέσεις να µπορούν να υπακούουν στη σηµασιολογία (semantics) της SQL, αφετέρου δε να µπορούν να συνδυαστούν απρόσκοπτα µεταξύ τους. Το παράθυρο εφαρµόζεται σ ένα ρεύµα δεδοµένων µέχρι µια συγκεκριµένη χρονική στιγµή t και το αποτέλεσµα είναι ένα πεπερασµένο σύνολο πλειάδων που µπορεί 71

12 ιατύπωση και επεξεργασία ερωτηµάτων. να θεωρηθεί εφεξής ως σχέση. Το ίδιο ισχύει φυσικά και στην περίπτωση δειγµατοληψίας των στοιχείων. Από την άλλη πλευρά, οι σχέσεις µπορούν να θεωρηθούν ως ρεύµατα, εφόσον σε κάθε εγγραφή τους προσαρτάται ένα χρονικό ορόσηµο (timestamp) που δηλώνει τη χρονική στιγµή εισαγωγής, ενηµέρωσης ή διαγραφής τους. Βάσει αυτού του χρονικού προσδιορισµού, κάποια πλειάδα s i της σχέσης εισέρχεται στο ρεύµα τη χρονική στιγµή t i (άρα δεν υφίσταται ως εγγραφή του αντίστοιχου πίνακα τη χρονική στιγµή t i-1 ), ενώ διαγράφεται όταν παύει να περιλαµβάνεται στον πίνακα τη χρονική στιγµή t i, όντας αναφερόµενη για το χρονικό διάστηµα µέχρι t i-1. Σε ένα ερώτηµα λοιπόν που υποβάλλεται τη χρονική στιγµή t, η απάντηση προκύπτει λαµβάνοντας τις εµπλεκόµενες σχέσεις τη χρονική στιγµή t, καθώς και τα ρεύµατα δεδοµένων που µετατρέπονται σε σχέσεις προσδιορίζοντας παράθυρα µε χρονικό ορίζοντα µέχρι τη στιγµή t. Το αποτέλεσµα, έπειτα από την εφαρµογή των κατάλληλων τελεστών, µπορεί να είναι είτε µια σχέση ή να διοχετευτεί στους χρήστες ως ρεύµα δεδοµένων Χρονικά ορόσηµα στις πλειάδες των αποτελεσµάτων Όταν στο σύστηµα εισέρχονται δεδοµένα από ένα µόνο ρεύµα, η διάταξη των πλειάδων προσδιορίζεται είτε από το χρονικό ορόσηµο (timestamp) είτε µε κάποιον αύξοντα αριθµό που δηλώνει τη σειρά άφιξης. Όπως άλλωστε εξηγήθηκε στην ενότητα 2.3.4, κάτι τέτοιο αρκεί για την περιγραφή των χρονικών παραθύρων. Εν τούτοις, παρα- µένει αδιευκρίνιστος ο χρονικός προσδιορισµός των πλειάδων που προκύπτουν ως αποτέλεσµα της επεξεργασίας στοιχείων από πολλαπλά ρεύµατα δεδοµένων. Αντιπροσωπευτικό παράδειγµα, αποτελεί η χρονική ένδειξη που πρέπει να αποδοθεί στο αποτέλεσµα της σύνδεσης δύο ρευµάτων, ιδίως µάλιστα όταν τα συνδεόµενα ρεύµατα χαρακτηρίζονται από διαφορετικού τύπου χρονικές αναφορές. Το ζήτηµα του χρονικού προσδιορισµού των αποτελεσµάτων ανακύπτει ιδιαίτερα σε δύο περιπτώσεις αυξηµένου ενδιαφέροντος: αφενός µεν όταν πολλαπλά ρεύµατα συνδυάζονται σε ένα, λ.χ. σε µια εφαρµογή εποπτείας του Παγκόσµιου Ιστού (Web monitoring), αφετέρου δε όταν τα ρεύµατα δεδοµένων είναι κατανεµηµένα, όπως στην περίπτωση ενός δικτύου αισθητήρων (sensor network), οπότε η αντιπαραβολή των χρονικών ενδείξεων µπορεί να αποκαλύψει τη συνάφεια µεταξύ των στοιχείων του ρεύµατος. Μια προφανής λύση στο ζήτηµα είναι να απονέµεται ως χρονική ένδειξη σε κάθε πλειάδα αποτελέσµατος η χρονική στιγµή παραγωγής της. Η τεχνική αυτή ( best-effort ), παρέχει αρκετή ευελιξία και προσιδιάζει σε περιπτώσεις όπου καταγράφονται έµµεσες (implicit) χρονικές ενδείξεις, δηλαδή το ίδιο το σύστηµα αποφασίζει τη χρονική σήµανση των πλειάδων που εισέρχονται σ αυτό (που µπορεί να είναι λ.χ. η χρονική στιγµή εισόδου ή απλοί αύξοντες αριθµοί). Η σιωπηρή υπόθεση που γίνεται είναι ότι οι πλειάδες που φτάνουν νωρίτερα, περνούν νωρίτερα κι από τους τελεστές (λ.χ. σύνδεση), µολονότι η ακριβής ταξινόµηση των πλειάδων του αποτελέσµατος εναπόκειται στις λεπτοµέρειες της 72

13 3.2 Γλώσσα ερωταποκρίσεων ρευµάτων δεδοµένων υλοποίησης της επεξεργασίας των ερωτηµάτων και του χρονοπρογραµµατισµού (scheduling). Η προσέγγιση αυτή µειονεκτεί ως προς το γεγονός ότι δεν µπορούν να οριστούν επακριβώς κυλιόµενα παράθυρα που θα καλύπτουν τα αποτελέσµατα ενδεχόµενων υποερωτηµάτων. Εναλλακτικά, µπορεί να εναπόκειται στο χρήστη να αποφασίζει κατά περίπτωση ποιο χρονικό ορόσηµο θα αποδοθεί στο αποτέλεσµα της λειτουργίας ενός δυαδικού τελεστή, τακτική που είναι δυνατόν να επεκταθεί για να καλύψει πολλαπλά ρεύµατα δεδοµένων. Για παράδειγµα, ανεξάρτητα από τον τύπο των χρονικών οροσήµων (ρητά ή έµµεσα) για τις πλειάδες που εισέρχονται, ο χρονικός προσδιορισµός των απαντήσεων µπορεί να λαµβάνεται βάσει της σειράς αναγραφής των ρευµάτων δεδοµένων στην πρόταση FROM της εντολής SQL. Προεξοφλείται λοιπόν ότι ο χρήστης δηλώνει εν γνώσει του αυτή τη σειρά προτεραιότητας µεταξύ των ρευµάτων. Κατά συνέπεια, το χρονικό ορόσηµο που έχει καταγραφεί στην πλειάδα του πρώτου ρεύµατος της σύνδεσης χρησιµοποιείται αυτούσιο και για την εξαγόµενη πλειάδα. Τυχόν ταυτόσηµες χρονικές ενδείξεις στο αποτέλεσµα, δηλαδή πλειάδες µε ίδιο ορόσηµο, µπορούν να επιλυθούν δευτερογενώς, αξιοποιώντας τους χρονικούς προσδιορισµούς των επόµενων - κατά σειρά αναγραφής - ρευµάτων εισόδου. Ωστόσο, είναι πιθανόν αυτή η δεύτερη, πιο αυστηρή, προσέγγιση να έχει ανεπιθύµητες επιπλοκές από πλευράς υλοποίησης. Εάν τυχόν το ερώτηµα επιβάλλει την παραγωγή χρονικά ταξινοµηµένων αποτελεσµάτων λ.χ. της σύνδεσης δύο ρευµάτων, ο αντίστοιχος τελεστής θα πρέπει να δεσµεύσει κάποιον προσωρινό αποθηκευτικό χώρο για τις παραγόµενες πλειάδες ώστε να ολοκληρωθεί η ταξινόµησή τους. Έτσι, δεν θα εξάγονται πλειάδες παρά µόνον όταν υπάρχει βεβαιότητα ότι άλλες επικείµενες δεν θα ανατρέψουν τη συντελούµενη διάταξη, δηλαδή δεν θα προκύψουν εκ των υστέρων άλλες πλειάδες µε παλαιότερο χρονικό ορόσηµο). εν µπορεί φυσικά να αποκλειστεί η περίπτωση κατά την οποία η σύνδεση δύο ρευµάτων δίνει µεταγενέστερα κάποια πλειάδα που οφείλει να τεθεί χρονικά πριν από κάποια άλλη που έχει προκύψει προηγουµένως, αλλά η οποία εξακολουθεί να παραµένει εντός του τρέχοντος παραθύρου! Το φαινόµενο πιθανόν να εκδηλώνεται συχνά είτε επειδή ο αντίστοιχος τελεστής απορροφά στοιχεία όχι µόνο από δύο, αλλά από πολλαπλά ρεύµατα δεδοµένων είτε διότι το ερώτηµα είναι αρκετά σύνθετο (λ.χ. περιλαµβάνει πολλαπλές συνδέσεις). Τότε είναι σχεδόν σίγουρο ότι η επιπλέον υστέρηση (latency) στην εξαγωγή των ενδιάµεσων πλειάδων θα επιβαρύνει όλο και περισσότερο τις συνδέσεις που αποµένουν. Αν µάλιστα δεν έχει προβλεφθεί εντελώς η χρήση χρονικών παραθύρων (λ.χ. κυλιόµενα παράθυρα) για την κατεργασία µόνο µέρους των στοιχείων εισόδου, δεν θα πρέπει να αναµένεται ότι ο τελεστής θα είναι σε θέση να δώσει ταξινοµηµένα αποτελέσµατα µε ικανοποιητική αξιοπιστία. Σε ένα Σ Ρ, είναι πολύ πιθανόν να εφαρµόζονται, ανάλογα µε τη συγκυρία, και οι δύο τεχνικές: µέσω της διαθέσιµης γλώσσας ερωταποκρίσεων (query language) ο χρήστης οφείλει κάθε φορά να επιλέξει την καταλληλότερη για τους σκοπούς του ερωτήµατός του. Όταν π.χ., προσδιορίζονται κυλιόµενα παράθυρα που εξυπηρετούν περισσότερο στην αποτελεσµατικότερη επεξεργασία των ερωτηµάτων, τότε η πρώτη προσέγγιση ( best-effort ) είναι προτιµότερη, αφού επιτρέπει αρκετή χαλαρότητα στη 73

14 ιατύπωση και επεξεργασία ερωτηµάτων. διάταξη των πλειάδων που θα συγκροτήσουν την απάντηση. Όταν όµως η ταξινόµηση των πλειάδων που παράγονται από τη σύνδεση πολλαπλών ρευµάτων δεδοµένων έχει ιδιαίτερη σηµασία, δηλαδή τα παράθυρα αποτελούν τµήµα της σηµασιολογίας (semantics) του ερωτήµατος, τότε η δεύτερη, αυστηρότερη τεχνική, µολονότι µειωµένης αποτελεσµατικότητας, είναι εκείνη που συνήθως υπερισχύει. ιαγράµµατα εκτέλεσης ερωτηµάτων Ρεύµατα δεδοµένων εξόδου Q 8 Q 9 Εφαρµογές υποβάλλουν ερωτήµατα διαρκείας Syn3 Syn4 Syn5 π Οι χρήστες θέτουν µη προβλέψιµα ερωτήµατα και ερωτήµατα διαρκείας Q 5 Q 6 Q 7 σ Syn1 σ Syn2 Q 1 Q 2 Q 3 Q 4 Ο διαχειριστής εποπτεύει την εκτέλεση των ερωτηµάτων και ρυθµίζει κατάλληλα τις παραµέτρους εκτέλεσης Αποθήκη ιστορικών στοιχείων Ρεύµατα δεδοµένων εισόδου Σχέδιο 3.1: Η αρχιτεκτονική απεξεργασίας ερωτηµάτων σε ένα Σύστηµα ιαχείρισης Ρεύµατος εδοµένων, όπως αντιµετωπίζεται από τα συστήµατα STREAM και AURORA. [Πηγή: [BBD+02] (προσαρµογή) 74

15 3.3 Επεξεργασία ερωτηµάτων σε ρεύµατα δεδοµένων 3.3 Επεξεργασία ερωτηµάτων σε ρεύµατα δεδοµένων Σε ένα Σύστηµα ιαχείρισης Ρεύµατος εδοµένων, είναι αναµενόµενο ότι τόσο τα ερωτήµατα διαρκείας όσο και τα δεδοµένα στα οποία αναφέρονται, εξακολουθούν να υφίστανται για µεγάλα χρονικά διαστήµατα. Όταν λοιπόν τίθεται ένα ερώτηµα στο Σύστηµα, παράγεται ένα προσχέδιο εκτέλεσης του ερωτήµατος (query execution plan), όπως και στις συµβατικές βάσεις δεδοµένων, το οποίο καθοδηγεί την επεξεργασία αλλά εξακολουθεί να ισχύει για όσο χρονικό διάστηµα υφίσταται το ερώτηµα. Ωστόσο, είναι φανερό ότι προοδευτικά διάφοροι παράγοντες θα εµφανίζουν σηµαντικές αυξοµειώσεις, όπως λ.χ. τα χαρακτηριστικά των ρευµάτων που καταφθάνουν, ο κυµαινόµενος ρυθµός άφιξης ή παραγωγής δεδοµένων ή ο αριθµός των ερωτηµάτων διαρκείας που πρέπει να εκτελούνται ταυτόχρονα. Προκειµένου το σύστηµα να µπορεί να ανταποκριθεί σε τέτοιες, απρόβλεπτες ή και ραγδαίες µεταβολές, θα πρέπει να εµφανίζει ικανότητα προσαρµογής. Πρέπει λοιπόν να βρεθεί πότε ανακύπτει ζήτηµα βελτιστοποίησης των επιδόσεων (sub-optimal performance) εξαιτίας διαφορών µεταξύ του εκτιµώµενου και του µετρούµενου παράγοντα επιλεκτικότητας (selectivity) του ερωτήµατος, αλλά κατά το χρόνο εκτέλεσης (run-time). Όταν διαπιστωθεί τέτοια περίπτωση, το προσχέδιο µεταβάλλεται δυναµικά ώστε να βελτιώσει τις συνολικές επιδόσεις. Το ζήτηµα της προσαρµοστικότητας (adaptivity) σε µεταβαλλόµενες συνθήκες αναδεικνύεται σε καθοριστικό, αφού δεν αφορά αποκλειστικά παραµέτρους όπως η µνήµη, αλλά πιθανόν να επηρεάζει και άλλους πόρους, λ.χ. την αναγκαιότητα χρήσης του δίσκου ή την επαύξηση της ενδιάµεσης µνήµης (buffers), επιδεινώνοντας την υστέρηση (latency) στην απόκριση του συστήµατος. Επιπλέον, δεν αποκλείεται να εµφανίζουν διακυµάνσεις και άλλες παράµετροι της επεξεργασίας (λ.χ. µεταβλητός βαθµός προσέγγισης των αποτελεσµάτων) που θα ελέγχονται από τους χρήστες. Άλλωστε, θα πρέπει να αντιµετωπιστεί το λογικό ενδεχόµενο να υποβληθούν ερωτήµατα όταν µεγάλο µέρος των ιστορικών στοιχείων του ρεύµατος θα έχει οριστικά χαθεί. Συνεπώς, θα πρέπει να ληφθεί πρόνοια σε σχέση µε τα παρελθόντα δεδοµένα, αφού είναι δυνατόν να έχουν πια απορριφθεί ή αρχειοθετηθεί από το σύστηµα. Σε τελική ανάλυση, η προσαρµογή στο διαρκώς εξελισσόµενο περιβάλλον επεξεργασίας των ερωτηµάτων ανάγεται στην αναζήτηση µιας αποδοτικής ισορροπίας µεταξύ της καλύτερης δυνατής κατανοµής της διαθέσιµης µνήµης και της επιθυµητής ακρίβειας, ώστε ο βελτιστοποιητής ερωτηµάτων (query optimizer) να καταστρώνει αποτελεσµατικά το καλύτερο προσχέδιο εκτέλεσης. Πρόκειται φυσικά για δυσεπίλυτο ζήτηµα σ ένα πραγµατικό σύστηµα που θα κληθεί να διαχειριστεί ένα µεγάλο αριθµό ερωτηµάτων διαρκείας. Κάθε τελεστής θα προσπαθεί να εκµεταλλευτεί την ποσότητα µνήµης που θα του εκχωρηθεί, επιδιώκοντας να µεγιστοποιήσει την ακρίβεια της προσεγγιστικής απάντησης που θα δώσει. Έτσι, απρόσµενες µεταβολές στην κατανοµή Χαρακτηριστικότερο παράδειγµα τέτοιας προσέγγισης είναι οι δοµές των Eddies, µε κύρια ιδιότητα την online προσαρµοζόµενη επεξεργασία των ερωτηµάτων, παρά το γεγονός ότι µέχρι πρόσφατα (τέλη 2002) δεν αντιµετώπιζαν καθόλου την περίπτωση των ερωτηµάτων διαρκείας. 75

16 ιατύπωση και επεξεργασία ερωτηµάτων. της µνήµης θα πρέπει να αντιµετωπιστούν µε προνοητικότητα, αφού κατά την εκτέλεση, η µνήµη ανά πάσα στιγµή µπορεί να αφαιρεθεί από έναν τελεστή και να προσφερθεί σε κάποιον άλλον που έχει λ.χ. µεγαλύτερη προτεραιότητα. Ακόµη, δεν είναι εύκολο να διευκρινιστεί η προσέγγιση που επιτυγχάνεται όταν υπάρχουν σύνθετοι τελεστές στα προσχέδια εκτέλεσης ερωτηµάτων. Τέλος, αφού οι περιλήψεις δεδοµένων ενδέχεται κατά περίπτωση να εξυπηρετήσουν πολλαπλά προσχέδια εκτέλεσης, τα αντίστοιχα ερωτήµατα θα ήταν ίσως σκόπιµο να αξιολογούνται ως προς τη σηµασία τους, προκειµένου οι σχετικές περιλήψεις να συντηρούνται µε ανάλογη συχνότητα. Χαρακτηριστικό παράδειγµα αποτελεί η χρήση ενός τελεστή σύνδεσης µε χρήση κυλιόµενων παραθύρων (sliding window join operator), ώστε να είναι εφικτό να προσεγγιστεί ικανοποιητικά το αποτέλεσµα µιας σύνδεσης που αφορά όλο το ιστορικό των αντίστοιχων ρευµάτων. Εποµένως, όσο µεγαλύτερο είναι το εύρος των παραθύρων, τόσο καλύτερη θα είναι και η προσέγγιση που θα επιτευχθεί, όπως εξηγείται στη σχετική ενότητα παρακάτω. Αντίστοιχη αντιµετώπιση µπορεί να έχουν λειτουργίες όπως η απαλοιφή διπλοτ υπων (duplicate elimination) µε χρήση µικρού µεγέθους πινάκων κερµατισµού (limited-size hash tables) ή η δειγµατοληψία µε χρήση αποθεµατικού (reservoirs). Η τακτική που υιοθετούν τα πλέον φιλόδοξα συστήµατα (AURORA, STREAM) συνηγορεί στην δηµιουργία ενός καθολικού προσχεδίου εκτέλεσης (global query plan) για όλα τα ερωτήµατα διαρκείας που υποβάλλονται στο σύστηµα, το οποίο και τροποποιείται αναλόγως κάθε φορά που προστίθεται ή αφαιρείται κάποιο ερώτηµα. Μάλιστα, από το AURORA παρέχεται στους χρήστες η δυνατότητα απευθείας υποβολής προσχεδίων, αξιοποιώντας τυχόν κοινά τµήµατα (εκφράσεις, υποερωτήµατα) µεταξύ πολλαπλών ερωτηµάτων. Όµως, είναι δυνατόν να ισχύει και η εναλλακτική λογική (STREAM), αφήνοντας κάθε ερώτηµα ως ανεξάρτητη ενότητα, οπότε παράγεται για το καθένα χωριστό προσχέδιο. Εάν υπάρχουν κοινά τµήµατα µεταξύ προσχεδίων, τότε αυτά µπορούν να συνδυαστούν, οδηγώντας πιθανόν σε ένα καθολικό προσχέδιο. Στο σύστηµα STREAM κάθε τελεστής που συµπεριλαµβάνεται στο προσχέδιο διατηρεί τη δική του ουρά, η οποία το τροφοδοτεί µε στοιχεία. Αντίθετα, το AURORA και τα Eddies, προκρίνουν µια µοναδική κοινή ουρά που διαχειρίζεται όλη τη ροή δεδοµένων µεταξύ των τελεστών αντί για χωριστές ουρές που παρεµβάλλονται µεταξύ τους. Σ αυτά τα συστήµατα ακολουθείται µια λεπτοµερής στρατηγική ως προς το χρονοδιάγραµµα εκτέλεσης, σε κάθε στάδιο της οποίας ο χρονοπρογραµµατιστής (scheduler) επιλέγει µια πλειάδα από τη µοναδική ουρά που υφίσταται στο σύστηµα και την προωθεί στον κατάλληλο τελεστή για περαιτέρω επεξεργασία. Αξίζει, τέλος, να γίνει ειδική µνεία στις διεπαφές χρηστών και εφαρµογών (user and application interfaces), δεδοµένου του δυναµικού χαρακτήρα που προσλαµβάνει ένα Σ Ρ. Τέτοιες διεπαφές επιτρέπουν τόσο στους χρήστες όσο και στους διαχειριστές του συστήµατος να παρακολουθούν την εξέλιξη της εκτέλεσης των ερωτηµάτων, εποπτεύοντας παράλληλα τόσο τη δεσµευόµενη µνήµη, όσο και το βαθµό προσέγγισης που επιτυγχάνεται. Επίσης, θα πρέπει να παρέχεται δυνατότητα ρύθµισης παραµέτρων του συστήµατος, όπως η κατανοµή µνήµης ή ο ορισµός χρονοδιαγράµµατος εκτέλεσης 76

17 3.3 Επεξεργασία ερωτηµάτων σε ρεύµατα δεδοµένων (scheduling) ερωτηµάτων, σε συνθήκες δυναµικών µεταβολών ή ακόµη και κατά τη διάρκεια εκτέλεσης των ερωτηµάτων Υπολογισµός και βελτιστοποίηση ερωτηµάτων Καθήκον του βελτιστοποιητή ερωτηµάτων (query optimizer) σε οποιοδήποτε σύστηµα διαχείρισης βάσεων δεδοµένων (Σ Β ) είναι να διαλέξει εκ των προτέρων το διαφαινόµενο ως «καλύτερο» προσχέδιο εκτέλεσης (query execution plan) για κάθε ερώτηµα. Η κατ εκτίµηση επιλογή γίνεται βάσει στατιστικών στοιχείων που τηρούνται από το σύστηµα ειδικά για το σκοπό αυτό. Ένα προσχέδιο έχει συνήθως δενδρική δοµή, µε τους τελεστές στους ενδιάµεσους κόµβους και σχέσεις ή δείκτες (indexes) στα φύλλα του δένδρου, ενώ το αποτέλεσµα προκύπτει από τη ρίζα του. Η εκτέλεση του προσχεδίου ξεκινά από πάνω προς τα κάτω (top-down) σε µια αλληλουχία (pipeline) των τελεστών, οι οποίοι «τραβούν» (pull) δεδοµένα εισόδου από τα παιδιά τους, καταλήγοντας τελικά στα φύλλα. Από την άλλη πλευρά, σε συστήµατα διαχείρισης ρευµάτων δεδοµένων (Σ Ρ ), ο επεξεργαστής ερωτηµάτων διαρκείας προορίζεται πάλι για το έργο της επιλογής αντίστοιχων προσχεδίων εκτέλεσης, αλλά µε µια σηµαντική διαφοροποίηση: η επιλογή του «βέλτιστου» προσχεδίου δεν ενδείκνυται να γίνεται πάντοτε εκ των προτέρων, αφού συνήθως τα ερωτήµατα διαρκείας υφίστανται στο σύστηµα επί µακρόν, ενώ και η συγκέντρωση στατιστικών στοιχείων εµφανίζει δυσχέρειες. Το επιθυµητό θα ήταν λοιπόν η κατάστρωση και η προσαρµογή των προσχεδίων εκτέλεσης στις επικρατούσες συνθήκες να αποφασίζεται δυναµικά (on-the-fly). Αυτό πρακτικά σηµαίνει ότι το προσχέδιο εκτέλεσης όχι µόνο δεν οριστικοποιείται αµέσως µετά τη διατύπωση του ερωτήµατος, αλλά ενδέχεται να τροποποιηθεί κατά την εξέλιξη της εκτέλεσής του, ανάλογα µε τις συνθήκες που επικρατούν στο σύστηµα. Στην περίπτωση των ερωτηµάτων διαρκείας, προβλέπεται ότι η άφιξη µιας νέας πλειάδας ενός ρεύµατος, αυτοµάτως ενεργοποιεί το προσχέδιο εκτέλεσης ερωτηµάτων που αφορούν το συγκεκριµένο ρεύµα, φαινόµενο που θυµίζει αρκετά τη συµπεριφορά των triggers στις ενεργές βάσεις δεδοµένων (active databases). Ωστόσο, υπάρχει µια ριζική διαφορά προς τα συµβατικά προσχέδια εκτέλεσης ερωτηµάτων: τώρα τα ίδια τα ρεύµατα εισόδου «σπρώχνουν» (push) δεδοµένα προς τους τελεστές. Κατά συνέπεια, η σηµασιολογία των κλασικών σχεσιακών τελεστών θα πρέπει να υποστεί, όπου χρειάζεται, ορισµένες τροποποιήσεις, ώστε αυτοί να µπορούν να εφαρµοστούν και σε ρεύµατα δεδοµένων. Στη συνέχεια, παρουσιάζονται ακροθιγώς οι ενδεχοµένως σηµαντικές αλλαγές που προβλέπεται να χρειαστούν στη συµπεριφορά µερικών κύριων κατηγοριών τελεστών: i. Τελεστές αλληλουχίας (Pipeline operators) Πρόκειται για τελεστές που τροφοδοτούν µε τα αποτελέσµατα που παράγουν άλλους τελεστές που ακολουθούν στο προσχέδιο εκτέλεσης. Η µεταβίβαση συµβαίνει στη µνήµη, χωρίς να χρειάζεται να αποθηκευτούν µόνιµα τα ενδιάµεσα δεδοµένα, χρησιµοποιώντας πιθανόν κάποια επαναληπτική δοµή για τον έλεγχο της ροής των 77

18 ιατύπωση και επεξεργασία ερωτηµάτων. στοιχείων. Σε ό,τι αφορά τους τελεστές επιλογής (selections), δεν φαίνεται να µπαίνουν ιδιαίτερα προσκόµµατα ως προς την προσαρµογή των παραδοσιακών προσχεδίων εκτέλεσης ερωτηµάτων. Το πρόβληµα εντοπίζεται κυρίως στις συνδέσεις (joins), όπου δεν απαιτείται µόνο η αλληλουχία (pipeline) των τελεστών, αλλά και η δυνατότητά τους να λειτουργούν αποδοτικά υπό καθεστώς περιορισµών στον αποθηκευτικό χώρο, ακόµη κι όταν τα ρεύµατα δεδοµένων είναι ανεξάντλητα. Μια εφικτή τακτική που θα µπορούσε να προκριθεί ως λύση όταν διαπιστωθεί ότι πλέον ο χώρος δεν επαρκεί, θα ήταν να υπολογιστεί µια προσεγγιστική απάντηση για τη σύνδεση, ελαχιστοποιώντας κατά το δυνατόν την συνακόλουθη απώλεια πληροφορίας. ii. Ανασχετικοί τελεστές (Blocking operators) Σε ό,τι αφορά τους ανασχετικούς τελεστές (λ.χ. ταξινόµηση, οµαδοποίηση, βλ. ενότητα σχετικά), εκτιµάται ότι, µε τις απαραίτητες τροποποιήσεις, οι τεχνικές της άµεσης επεξεργασίας (όπως online aggregation), καθώς και της σταδιακής συντήρησης όψεων (incremental view maintenance), θα µπορούσαν να φανούν ευεργετικές σε περιβάλλον ρευµάτων δεδοµένων µε ερωτήµατα διαρκείας. iii. Τελεστές σύνοψης (Synopsis operators) Η αναγκαιότητα εξαγωγής προσεγγιστικών αποτελεσµάτων αξιοποιώντας περιλήψεις (summaries) παλαιότερων δεδοµένων, πιθανώς αντιµετωπίζεται µε τη χρήση ειδικών τελεστών σύνοψης (synopsis operators). Η επιλογή τέτοιων τελεστών θα µπορούσε να ανατεθεί στον βελτιστοποιητή ερωτηµάτων ανάλογα µε τη φύση και τις απαιτήσεις που προβάλλει κάθε ερώτηµα. Σε επόµενο στάδιο, θα ήταν δυνατόν να γίνονται κατάλληλες ρυθµίσεις σε παραµέτρους που καθορίζουν τη συµπεριφορά του τελεστή είτε σε σχέση µε την ακρίβεια και το επίπεδο εµπιστοσύνης που αποδίδεται στην προσεγγιστική απάντηση είτε κρίνοντας από τον µέγιστο απαιτούµενο αποθηκευτικό χώρο. Εφοδιασµένος µε τέτοιες δυνατότητες, ο βελτιστοποιητής ερωτηµάτων θα ήταν σε θέση να καταστρώσει αποτελεσµατικότερα προσχέδια εκτέλεσης, βάσει της µορφής του ερωτήµατος και του διαθέσιµου χώρου Συνδέσεις ρευµάτων µε χρήση κυλιόµενων παραθύρων Πρακτικά, η σύνδεση µεταξύ ανεξάντλητων ρευµάτων δεδοµένων µπορεί να επιτευχθεί µε χρήση παραθύρων, περιορίζοντας τον αριθµό των πλειάδων που θα εξεταστούν για κάθε ρεύµα. Αντί λοιπόν να επιχειρηθεί η σύνδεση όλων των πλειάδων δύο ρευµάτων S 1 και S 2, ο τελεστής αρκείται να συνδέσει τις πλειάδες του S 1 που έχουν καταφθάσει στο πρόσφατο χρονικό διάστηµα t 1 µε τις πλειάδες του S 2 που αντιστοιχούν στο επίσης πρόσφατο χρονικό διάστηµα t 2. εδοµένης της ανεπάρκειας της µνήµης να χειριστεί τον όγκο των στοιχείων, η επιβολή λοιπόν χρονικών περιορισµών είναι αναγκαία, ώστε η σύνδεση µε χρήση παραθύρων (window join) να παράγει νέα αποτελέσµατα, καθώς στο σύστηµα καταφθάνουν συνεχώς καινούργια στοιχεία κι άλλα παλαιότερα διαγράφονται µε την πάροδο του χρόνου. 78

19 Έστω ότι ζητείται ο υπολογισµός του µέσου όρου των εσόδων όλων των υποκαταστηµάτων µιας επιχείρησης ανά γεωγραφικές περιοχές. Σε SQL το ερώτηµα θα µπορούσε να διατυπωθεί µε τον ακόλουθο τρόπο: SELECT Region, AVG(revenue) FROM Sales, Branches WHERE Sales.id = Branches.id GROUP BY Region Ιδιαίτερα όταν οι πίνακες (Sales, Branches) περιέχουν µεγάλο αριθµό στοιχείων, η παραγωγή του αποτελέσµατος µε την παραδοσιακή µέθοδο ενδεχοµένως καθυστερεί, αφού προηγουµένως απαιτείται να εξεταστούν όλες οι εγγραφές. Ιδίως όταν ο χρήστης θέλει να αποκτήσει µια γενική µόνο εικόνα από έναν µεγάλο όγκο πληροφοριών, το σύστηµα προκρίνει τον υπολογισµό της απάντησης µε ακρίβεια που είναι µάλλον υπερβολική. Μια καλή εναλλακτική λύση για να περιοριστεί η καθυστέρηση, θα ήταν να παρασχεθεί πολύ σύντοµα ένα προσεγγιστικό αποτέλεσµα (approximation), το οποίο θα γίνεται προοδευτικά περισσότερο ακριβές, µε ολοένα ελαττούµενα περιθώρια σφάλµατος. Η καινοτοµική αυτή τεχνική, που αποκαλείται online aggregation, µπορεί να χειριστεί αποτελεσµατικά µεγάλης διάρκειας ερωτήµατα που περιέχουν τελεστές συνάθροισης. Η εφαρµογή της µεθόδου στο προηγούµενο ερώτηµα, απεικονίζεται γραφικά ως εξής: Για το αποτέλεσµα κάθε οµάδας, παρέχεται ένα διάστηµα διακύµανσης (interval), υπάρχει πιθανοτική εκτίµηση του επιπέδου εµπιστοσύνης (confidence) της απάντησης, ενώ ο δείκτης προόδου (status bar) δείχνει το ποσοστό του αποτελέσµατος που έχει υπολογιστεί µέχρι στιγµής. Το Σ Β διαθέτει περισσότερους πόρους για υπολογισµούς που αφορούν οµάδες που έχουν προτεραιότητα, αλλά ο χρήστης έχει την ευχέρεια να περέµβει δυναµικά και να αλλάξει τη σειρά προτεραιότητας καθώς το ερώτηµα εκτελείται. Επιπλέον, υπάρχει η δυνατότητα να διακοπεί προσωρινά ή και να τερµατιστεί ο υπολογισµός για κάποιες οµάδες, επιταχύνοντας έτσι τους υπολογισµούς για τις υπόλοιπες. Αυτός ο βαθµός αλληλεπίδρασης που επιτρέπει στον χρήστη να εκφράσει την εύνοιά του προς κάποιες οµάδες ειδικού ενδιαφέροντος ή να µεταβάλει την επιθυµητή ακρίβεια ανάλογα µε τη διαίσθησή του, όπως κι η διαρκής παρακολούθηση της εξέλιξης των υπολογισµών, καθιστούν τη συγκεκριµένη τεχνική ιδιαίτερα ελκυστική. Άµεση συνάθροιση (Online aggregation) 79 Ως προς την υλοποίηση, το Σ Β οφείλει να συµπεριλάβει στατιστικές µεθόδους για την εκτίµηση των επιπέδων εµπιστοσύνης των προσεγγιστικών απαντήσεων που δίνονται, ενώ θα πρέπει να χρησιµοποιηθούν µη ανασχετικοί τελεστές (non blocking operators). Ειδικότερα, είναι προτιµότεροι οι αλγόριθµοι που βασίζονται σε µεθόδους κερµατισµού (hash-based aggregation) για να δώσουν συναθροιστικά αποτελέσµατα, υποθέτοντας µικρό αριθµό οµάδων άρα και µικρούς πίνακες κερµατισµού, σε σύγκριση µε τεχνικές που στηρίζονται σε ταξινόµηση (sort-based aggregation), οπότε τα αποτελέσµατα προκύπτουν στο σύνολό τους ένα-ένα για κάθε οµάδα. Χρειάζεται λοιπόν να οριστούν οι κατάλληλες συναρτήσεις συνάθροισης (aggregate functions), οι οποίες θα παρέχουν τις τρέχουσες εκτιµήσεις των υπολογισµών (SUM, COUNT, AVG, VAR, ST DEV), όπως και οι αντίστοιχες συναρτήσεις για τα τρεχούµενα επίπεδα εµπιστοσύνης (running confidence intervals). Προκειµένου αυτά τα επίπεδα εµπιστοσύνης να έχουν και στατιστική σηµασία, θα πρέπει φυσικά οι πλειάδες να ανακτώνται κατά τυχαίο τρόπο, ώστε να θεωρούνται ένα όντως τυχαίο δείγµα του συνόλου των δεδοµένων. Ζήτηµα δηµιουργείται επίσης και από τα ένθετα ερωτήµατα συνάθροισης (nested queries), όπου εµφανίζονται συναθροιστικοί τελεστές σε υποερωτήµατα. Τα ενδιάµεσα αποτελέσµατα είναι απαραίτητο να οπτικοποιηθούν µέσω ενός κατάλληλα διαµορφωµένου API, µε το οποίο θα επιτρέπεται ο επαρκής έλεγχος της εξέλιξης της εκτέλεσης των ερωτηµάτων και η παρακολούθηση των επιπέδων εµπιστοσύνης. Σε τελική ανάλυση, το ζήτηµα µετατοπίζεται από τον χρόνο υπολογισµού της πλήρους απάντησης στα ερωτήµατα στον χρόνο λήψης µιας ικανοποιητικά ακριβούς απάντησης. Ουσιαστικά λοιπόν, ανάγεται στην αποτελεσµατική εξισορρόπηση (tradeoff) µεταξύ των απαιτήσεων σε αποθηκευτικό χώρο, του αναγκαίου επεξεργαστικού χρόνου, του αριθµού περασµάτων των αλγορίθµων πάνω από τα δεδοµένα και του ανεκτού βαθµού προσέγγισης των απαντήσεων. Ωστόσο, πρέπει να τονιστεί ότι η τελική ευθύνη ανήκει στο χρήστη, ο οποίος καλείται να προσδιορίσει τις αντίστοιχες παραµέτρους. Συµπερασµατικά, η σύλληψη της µεθόδου αντιµετωπίζει τα επεξεργαζόµενα στοιχεία ως πεπερασµένου µεγέθους ρεύµατα δεδοµένων, διατρέχοντάς τα σε ένα πέρασµα και παρέχοντας ενδιάµεσες απαντήσεις πολύ σύντοµα. Η προσπάθεια επικεντρώνεται στην υποστήριξη των ερωτηµάτων του χρήστη επιτρέποντάς του να ελέγξει, να κατευθύνει και να βελτιώσει βαθµηδόν τις απαντήσεις στα εκτελούµενα ερωτήµατα βάσει των ενδιάµεσων αποτελεσµάτων. Έτσι, έχοντας επεξεργαστεί πολύ νωρίς τα δεδοµένα που τον ενδιαφέρουν, µπορεί να προχωρήσει σε περαιτέρω ανάλυση των στοιχείων. ( [HHW97],[RRH99],[GR00] )