Κεφάλαιο 1 Εισαγωγή στα συστήµατα ρευµάτων δεδοµένων

Κεφάλαιο 1 Εισαγωγή στα συστήµατα ρευµάτων δεδοµένων 1.1 Εισαγωγή Les flots roulant au loin leurs frissons de volets! Arthur Rimbaud, Le bateau ivre (1871) Τα συµβατικά Συστήµατα ιαχείρισης Βάσεων εδοµένων (Σ Β, DBMS) έχουν σχεδιαστεί µε γνώµονα την αποτελεσµατική αποθήκευση µεγάλου όγκου δεδοµένων επί των οποίων οι χρήστες του συστήµατος έχουν τον πρώτο λόγο, άλλοτε υποβάλλοντας ερωτήµατα (queries) κι άλλοτε εκτελώντας διαφόρων ειδών δοσοληψίες (transactions), όπως εισαγωγή νέων στοιχείων, διαγραφή ή τροποποίηση παλαιότερων κ.ά. Ωστόσο, το ενδιαφέρον συνήθως εστιάζεται στα τρέχοντα περιεχόµενα της βάσης δεδοµένων, χωρίς να δίνεται µεγάλη σηµασία σε προηγούµενα στιγµιότυπά της. Έτσι, επιτυγχάνεται συγχρονισµός των δεδοµένων, αποκλείοντας αντιφάσεις µεταξύ στοιχείων που θα αναφέρονταν σε διαφορετικές χρονικές περιόδους ή καταστάσεις. Εάν τυχόν κάποιος ενδιαφερθεί να µάθει παλαιότερες τιµές κάποιου στοιχείου, το πιθανότερο είναι ότι θα υποχρεωθεί να ανατρέξει στο ηµερολόγιο (log) που τηρείται από το σύστηµα, µήπως βρει κάτι σχετικό έπειτα από µια µάλλον κοπιαστική αναζήτηση. Ένα τυπικό Σ Β παρέχει ακριβείς απαντήσεις στα ερωτήµατα που υποβάλλουν οι χρήστες, θεωρώντας ότι όλα τα στοιχεία που χρειάζονται στους υπολογισµούς είναι άµεσα διαθέσιµα. Τέτοιες απαντήσεις είναι πολύ πιθανό να χρειάζονται αρκετό χρόνο µέχρι να προκύψουν, όµως ενδεχόµενες απαιτήσεις για απόκριση σε πραγµατικό χρόνο (real-time response) δεν µπορούν να καλυφθούν πάντοτε από τα συµβατικά Σ Β. Τα τελευταία χρόνια έχει αρχίσει να εµφανίζεται µια νέα κατηγορία εφαρµογών, οι εφαρµογές παρακολούθησης (monitoring applications), η οποία επίσης σχετίζεται µε τη διαχείριση δεδοµένων, αλλά όπου οι προδιαγραφές ενός τυπικού Σ Β είναι άκρως περιοριστικές. Πρόκειται για εφαρµογές όπου τα στοιχεία παρουσιάζονται όχι πλέον µε τη µορφή στατικών σχέσεων (relations), αλλά ως δεδοµένα συνεχούς ροής µέσα σε δίκτυο, δηλαδή ως ρεύµα δεδοµένων (data stream). Έτσι, τα δεδοµένα δεν αντιµετωπίζονται πια ως περιεχοµένα κάποιων γνωστών αποθηκευµένων αρχείων, αλλά ως 3

Εισαγωγή στα συστήµατα ρευµάτων δεδοµένων. στοιχεία που βρίσκονται µονίµως σε κίνηση (λ.χ. µέσα σε κάποιο τηλεφωνικό δίκτυο ή το Internet). Η ρευστότητα που υπονοεί ένα τέτοιο µοντέλο δεδοµένων, επιβάλλει τη δραστική αναθεώρηση τόσο του παγιωµένου τρόπου υποβολής των ερωτηµάτων, όσο και της επεξεργασίας που οδηγεί στον υπολογισµό των αντίστοιχων απαντήσεων. Χαρακτηριστικά παραδείγµατα τέτοιων εφαρµογών θα µπορούσαν να περιλάβουν συστήµατα εποπτείας δικτύων υπολογιστών, διαχείρισης τηλεπικοινωνιακών συνδιαλέξεων, παρακολούθησης της διακύµανσης οικονοµικών µεγεθών (λ.χ. χρηµατιστηριακοί δείκτες), διαχείρισης δικτύων αισθητήρων, παρακολούθησης της κίνησης πιστωτικών καρτών, στρατιωτικών εφαρµογών κ.ά. Στα πλαίσια της εργασίας αυτής, θα µελετηθεί διεξοδικότερα η περίπτωση των συστηµάτων παρακολούθησης µεγάλου αριθµού κινούµενων αντικειµένων (moving objects), λ.χ. ενός στόλου οχηµάτων που κινείται στο οδικό δίκτυο µιας περιοχής. 1.2 Η ανεπάρκεια των συµβατικών Σ Β Η αρχιτεκτονική ενός τυπικού Σ Β ακολουθεί ένα συγκεκριµένο (pull-based) µοντέλο προσπέλασης των δεδοµένων: όταν ο χρήστης χρειάζεται δεδοµένα, υποβάλλει ένα ερώτηµα στο σύστηµα, το οποίο του επιστρέφει κάποια απάντηση. Αντίθετα, στις εφαρµογές που εµπλέκουν ρεύµατα δεδοµένων, τα στοιχεία προωθούνται στο σύστηµα (push-based), κι εκείνο οφείλει να παράγει τα αποτελέσµατα των ερωτηµάτων ανταποκρινόµενο στις διάφορες καταστάσεις που ανιχνεύονται. Έπειτα, οι απαντήσεις διοχετεύονται προς τους χρήστες ή τις εφαρµογές που τις αναµένουν. Το γεγονός ότι δεν είναι πλέον ο χρήστης εκείνος που δροµολογεί τη ροή των δεδοµένων, αλλά οι ίδιες οι πηγές, αποτελεί την ειδοποιό διαφορά µε το πρότυπο των συµβατικών Σ Β. Επιπλέον, το ίδιο το σύστηµα αναλαµβάνει την ευθύνη να ειδοποιήσει το χρήστη για τυχόν απρόβλεπτες καταστάσεις (λ.χ. απροσδόκητα µεγάλες τιµές κάποιας ένδειξης, βλάβη κάποιας συσκευής). Έτσι, ο χρήστης περιορίζεται στον µάλλον «παθητικό» ρόλο του παρατηρητή, αρκούµενος να ρυθµίζει τις παραµέτρους του συστήµατος και να υποβάλλει ερωτήµατα, αν και χρειάζεται να βρίσκεται σε συνεχή αλληλεπίδραση µε το «ενεργητικό» σύστηµα. Αλλά και τα ερωτήµατα είναι πια διαφορετικά: εκτός από τα συνήθη ερωτήµατα στιγµιοτύπου (one-time ή snapshot queries) που υποβάλλονται σποραδικά όταν οι χρήστες επιθυµούν να λάβουν κάποιες συγκεκριµένες τρέχουσες πληροφορίες, υπάρχουν πλέον και τα ερωτήµατα διαρκείας (continuous queries) που εκτελούνται στο σύστηµα επί µακρόν και αποτελούν ένα από τα πλέον ενδιαφέροντα χαρακτηριστικά των ρευµάτων δεδοµένων. Οι χρήστες δεν χρειάζεται να τα θέσουν επίτηδες, αρκεί απλώς να τα ενεργοποιήσουν όταν χρειάζονται τις απαντήσεις ή να τα διακόψουν. Ούτως ή άλλως, το αποτέλεσµα της επεξεργασίας τους δεν µπορεί παρά να υπολογίζεται σταδιακά (incrementally), συµβαδίζοντας µε το ρυθµό άφιξης των στοιχείων, χωρίς να µπορεί να αποκλειστεί το ενδεχόµενο ότι η απάντηση τελικά θα είναι προσεγγιστική. Τα χαρακτηριστικά των δεδοµένων δεν είναι εκ των προτέρων γνωστά, γεγονός που δυσκολεύει σηµαντικά οποιαδήποτε προσπάθεια βελτιστοποίησης ερωτηµάτων 4

1.2 Η ανεπάρκεια των συµβατικών Σ Β (query optimization). Αντίθετα, τα παραδοσιακά Σ Β στοχεύουν στην παραγωγή λεπτοµερών απαντήσεων µε βάση κάποια στατικά προσχέδια εκτέλεσης ερωτηµάτων (query plans), τα οποία βοηθούνται κι από το φυσικό σχεδιασµό της βάσης δεδοµένων (λ.χ. δεικτοδότηση κάποιων πινάκων). Συνεπώς, ο επεξεργαστής ερωτηµάτων (query processor) δεν έχει πλέον δυνατότητα συνδροµικότητας στη διαχείριση των δοσοληψιών, αλλά πρέπει να καταστεί ικανός ν ανταποκριθεί στη συνεχή άφιξη των πληροφοριών. Τα δεδοµένα που συλλέγονται καλύπτουν ένα ορισµένο χρονικό διάστηµα και διογκώνονται συνεχώς, καθώς νέα στοιχεία συνεχίζουν να καταφθάνουν. Τα Σ Β αναµφισβήτητα προσφέρονται για διαχείριση µεγάλων ποσοτήτων δεδοµένων, αφού θεωρητικά έχουν απεριόριστες δυνατότητες για προσθήκη αποθηκευτικού χώρου (επιπλέον σκληροί δίσκοι). Έτσι θα ήταν εφικτό να δηµιουργηθούν ογκώδεις αποθήκες δεδοµένων (data warehouses), όπου µπορούν να καταχωρούνται τα στοιχεία (off-line). Όµως, η προσπέλαση τόσου µεγάλου όγκου στοιχείων είναι πρακτικά πολύ δύσκολη έως αδύνατη. Άρα, για να µπορεί να γίνει αποτελεσµατική επεξεργασία των ρευµάτων δεδοµένων, καθώς τα στοιχεία καταφθάνουν online, θα πρέπει να παραµένουν στην κύρια µνήµη και οι σχετικοί αλγόριθµοι να πραγµατοποιούν µόνο ένα «πέρασµα» από τα δεδοµένα κατά τη σειρά άφιξής τους στο σύστηµα. Επιπροσθέτως, συνήθως οι χρήστες δεν ενδιαφέρονται µόνο για τις πλέον πρόσφατες τιµές, αλλά επιθυµούν ικανοποιητική προσπέλαση όλης της ιστορικής εξέλιξής τους (sequential access). Για παράδειγµα, οι χρονοσειρές (time-series) των µετρήσεων που καταγράφηκαν θα µπορούσαν να εισαχθούν σε κατάλληλα δοµηµένους πίνακες ενός Σ Β, αλλά µε επακόλουθο τη διάσπαση της ακολουθίας των στοιχείων σε χωριστές εγγραφές. Μια τέτοια υλοποίηση διευκολύνει ίσως τη σποραδική αναζήτηση µεµονω- µένων στοιχείων (random access), όµως η απάντηση σ ένα υποθετικό ερώτηµα που αφορά µια συνεχόµενη χρονική περίοδο θα επέβαλε την ανασύσταση της χρονικής σειράς, διαδικασία που επιβαρύνει ιδιαίτερα το σύστηµα. Το ακριβώς ανάποδο θα συνέβαινε στην περίπτωση που για την υλοποίηση προκρινόταν η λύση των BLOBs (Binary Large OBjects), σε µια προσπάθεια αποκατάστασης της φυσικής συνάφειας των στοιχείων, µε αναπόφευκτο τίµηµα τη δυσκολία αναζήτησης µεµονωµένων τιµών. εν αποκλείεται µάλιστα ο ρυθµός παραγωγής των δεδοµένων να γίνει υπερβολικά υψηλός, τόσος που το σύστηµα να µην µπορεί να ανταποκριθεί σε αντίστοιχο καταιγιστικό ρυθµό άφιξης των στοιχείων. Σε τέτοιες περιπτώσεις, αντιµετωπίζεται το ενδεχοµένο επιλεκτικής απόρριψης δεδοµένων, ώστε να µειωθεί σε λογικά επίπεδα ο φόρτος του συστήµατος (load shedding). Από την άλλη πλευρά, δεν είναι καθόλου απίθανα τα φαινόµενα απώλειας δεδοµένων ή εσκεµµένης παράλειψης ορισµένων τµηµάτων τους για να διευκολυνθεί η µετάδοση, ενώ τα στοιχεία που τελικά εισρέουν στο σύστηµα αναπότρεπτα γίνονται όλο και πιο παρωχηµένα µε την πάροδο του χρόνου. Τέτοια φαινόµενα καθιστούν ανώφελη οποιαδήποτε προσπάθεια να δοθούν ακριβείς απαντήσεις στα ερωτήµατα, µην αφήνοντας περιθώρια παρά µόνο για προσεγγίσεις (approximations) των πραγµατικών αποτελεσµάτων. Η έντονα δικτυακή φύση των νέων εφαρµογών επιτείνει την αστάθεια του περιβάλλοντος (λ.χ. απώλεια δεδοµένων). Επιπλέον, η εγγενής µεταβλητότητα των 5

Εισαγωγή στα συστήµατα ρευµάτων δεδοµένων. στοιχείων συνηγορεί στη δηµιουργία µηχανισµών που θα µπορούν να διαγνώσουν εγκαίρως ασυνήθιστες συνθήκες και να προβούν στις κατάλληλες ενέργειες. Οι σκανδαλιστές (triggers) και τα συστήµατα επιφυλακής (alerters) που έχουν ήδη ενσωµατωθεί στις δυνατότητες πολλών Σ Β αποτελούν µια πρώτη, καλή προσέγγιση του ζητήµατος, µόνο που µπορούν να αναφέρονται σ έναν µόνο πίνακα. υστυχώς, ούτε µπορούν να επεκταθούν σε βαθµό τέτοιο ώστε να καλύψουν την ποικιλία των περιπτώσεων που µπορεί να ανακύψουν, ούτε βέβαια αντιµετωπίζουν καθόλου το ενδεχόµενο ελέγχου περίπλοκων συνθηκών προκειµένου για πολλαπλά ρεύµατα δεδοµένων που προέρχονται από διαφορετικές πηγές. Επειδή λοιπόν δεν είναι εφικτό να οριστούν παρά µόνο λίγοι triggers για κάθε πίνακα της βάσης, µια εύλογη εναλλακτική προσέγγιση θα ήταν να εισαχθούν όσοι επιπλέον χρειάζονται σε κάποια ενδιάµεση εφαρµογή, εκτός του Σ Β. Εκτιµάται όµως ότι οι επιδόσεις µιας τέτοιας λύσης δεν θα ήταν ικανοποιητικές, αφού η ενδιάµεση εφαρµογή θα πρέπει να διερευνά συνεχώς για νέα δεδοµένα επί των οποίων θα έχουν υλοποιηθεί οι triggers και οι alerters, ενώ θα εµφανίζει και δυσχέρειες στη βελτιστοποίηση. Τέλος, οι περισσότερες εφαρµογές που ασχολούνται µε ρεύµατα δεδοµένων επιβάλλουν απαντήσεις σε πραγµατικό χρόνο (real-time response), καθώς τα στοιχεία µπορεί να αφορούν παραµέτρους κρίσιµες από άποψη ασφάλειας (λ.χ. θερµοκρασία σε έναν πυρηνικό αντιδραστήρα) ή αποτελεσµατικότητας (δροµολόγηση πακέτων δεδοµένων µέσω δικτύου υπολογιστών). Η ιδιαιτερότητα αυτή επιβάλλει στα συστήµατα ρευµάτων δεδοµένων µια περισσότερο αποδοτική διαχείριση πόρων (resource management) και βελτιωµένη µεθοδολογία επεξεργασίας των ερωτηµάτων (query processing). Εξαιτίας των µειονεκτηµάτων των ήδη καθιερωµένων Σ Β στη διαχείριση της αποθήκευσης και στην επεξεργασία των ερωτηµάτων που αφορούν ρεύµατα δεδοµένων, οι περισσότερες σχετικές εφαρµογές τείνουν είτε να χρησιµοποιούν τα Σ Β για βοηθητική αποθήκευση στοιχείων εκτός γραµµής παραγωγής (offline) είτε καθόλου. Περιλήψεις Ρεύµατα εισόδου Ενδιάµεσος χώρος τήρησης δεδοµένων (buffers) Επεξεργαστής ερωτηµάτων Ρεύµατα εξόδου Στατικές σχέσεις Ερωτήµατα διαρκείας Σχέδιο 1.1: Γενικό διάγραµµα της αρχιτεκτονικής για ένα Σύστηµα ιαχείρισης Ρευµάτων εδοµένων. 6

1.3 Το µοντέλο ρεύµατος δεδοµένων 1.3 Το µοντέλο ρεύµατος δεδοµένων Το ρεύµα δεδοµένων (data stream) µπορεί να θεωρηθεί ως µια ακολουθία στοιχείων που παράγονται διαρκώς από µια πηγή. Ανάλογα µε την εφαρµογή, η πηγή δεδοµένων (data source) µπορεί να είναι ένας αισθητήρας µέτρησης κάποιου φυσικού µεγέθους (λ.χ. θερµοκρασίας σε έναν πυρηνικό αντιδραστήρα), µια αυτόµατη ταµειακή µηχανή (ΑΤΜ) για ανάληψη/κατάθεση χρηµάτων µέσω ενός τραπεζικού λογαριασµού ή µια µετοχή που η διακύµανση της τιµής της παρακολουθείται στο χρηµατιστήριο κ.ά. Βέβαια, τα µεµονωµένα στοιχεία του ρεύµατος είναι δυνατόν να έχουν επίσης τη µορφή σχεσιακών πλειάδων (relational tuples), π.χ. καταγραφές τηλεφωνικών κλήσεων, επισκέψεις ιστοσελίδων, µετρήσεις αισθητήρων. Όµως, αυτές οι πλειάδες δεν καταχωρούνται πλέον σε στατικούς πίνακες όπως στα τυπικά Σ Β, αλλά καταφθάνουν διαρκώς online µε απρόβλεπτο ενίοτε δε καταιγιστικό ρυθµό, χωρίς περιορισµούς ως προς το µέγεθος ή τις ιδιότητές τους. Άρα, ένα τουλάχιστον τµήµα ή και το σύνολο των δεδοµένων εισόδου δεν είναι εσαεί διαθέσιµα για επεξεργασία από το δίσκο ή την κύρια µνήµη, αλλά καταφθάνουν µε τη µορφή ενός ή περισσοτέρων ρευµάτων δεδοµένων. Συνήθως, στις πλειάδες υπάρχει καταγεγραµµένη η ταυτότητα της πηγής από την οποία προέρχονται, καθώς κι ένα χρονικό ορόσηµο (timestamp), ώστε να υπάρχει ένδειξη της χρονικής στιγµής άφιξης ή παραγωγής της πληροφορίας. Τέτοιες χρονικές ενδείξεις ή η διάταξη (order) των πλειάδων είναι εξαιρετικά πολύτιµες παράµετροι σε διάφορα ερωτήµατα που µπορεί να τεθούν στα δεδοµένα. Το σύστηµα δεν έχει καµιά δυνατότητα ελέγχου επί της σειράς µε την οποία τα δεδοµένα φθάνουν για επεξεργασία, είτε πρόκειται για ένα ρεύµα είτε για συγκερασµό στοιχείων από περισσότερα ρεύµατα. Από τη στιγµή που η επεξεργασία κάποιας πλειάδας ενός ρεύµατος δεδοµένων ολοκληρωθεί, αυτή θα απορριφθεί ή θα αρχειοθετηθεί, συνήθως µε τη µορφή περιλήψεων (data synopses, summaries). Αυτό σηµαίνει ότι το συγκεκριµένο στοιχείο δεν είναι δυνατόν να ανακτηθεί εύκολα (backtracking), εκτός κι εάν έχει φυλαχθεί επίτηδες στην κύρια µνήµη. Εν τούτοις, το διαθέσιµο µέγεθος κύριας µνήµης είναι συνήθως αρκετά µικρό για να καταφέρει να διατηρήσει πλήρως όλο τον όγκο ενός ρεύµατος δεδοµένων. Συνήθως, µπορεί να κρατηθεί µόνο κάποιο µικρό τµήµα των πιο πρόσφατων περιεχοµένων ή ένα αυθαίρετα ορισµένο τµήµα των στοιχείων είτε τέλος, κάποιας µορφής συνοπτική πληροφορία σχετική µε τα χαρακτηριστικά των στοιχείων που έχουν ήδη εισρεύσει στο σύστηµα. εν αποκλείεται τα δεδοµένα να εισέρχονται στο σύστηµα έχοντας ήδη ανακατευτεί µε παρόµοια στοιχεία από άλλες πηγές (συνενωµένα ρεύµατα δεδοµένων, concatenated data streams), λ.χ. να καταφθάνουν στοιχεία από πολλαπλούς αισθητήρες για διαφορετικές χρονικές περιόδους. Επίσης, υπάρχει το ενδεχόµενο πολυδιάστατων ρευµάτων δεδοµένων (multidimensional data streams), όπου τα στοιχεία αναφέρονται σε περισσότερες από µια πηγές δεδοµένων. Χαρακτηριστική περίπτωση είναι ένα ρεύµα τηλεφωνικών κλήσεων αποτελούµενο από πλειάδες, που στην καθεµιά καταγράφεται τόσο ο συνδροµητής που καλεί όσο κι εκείνος που καλείται. 7

Εισαγωγή στα συστήµατα ρευµάτων δεδοµένων. Η ύπαρξη ρευµάτων δεδοµένων δεν αποκλείει την παρουσία στο σύστηµα κι άλλων δεδοµένων µε τη µορφή αποθηκευµένων σχέσεων. Απεναντίας, συχνά είναι απαραίτητη η σύνδεση (join) µεταξύ δυναµικών ρευµάτων δεδοµένων και στατικών σχεσιακών δεδοµένων. Ειδικά σε ό,τι αφορά τα σχεσιακά δεδοµένα, γίνεται συνήθως η υπόθεση ότι τα περιεχόµενά τους παραµένουν σε σηµαντικό βαθµό αµετάβλητα. Γι αυτό και απλοποιείται σηµαντικά το ζήτηµα της διαχείρισης δοσοληψιών (transaction processing), αφού σπανίως θα συµβαίνουν ταυτόχρονα µεταβολές τόσο σε στατικές σχέσεις όσο και στην επεξεργασία των ρευµάτων δεδοµένων. 1.4 Ερωτήµατα σε ρεύµατα δεδοµένων Σε γενικές γραµµές, τα ερωτήµατα που µπορούν να τεθούν σε ρεύµατα δεδοµένων εµφανίζουν κάποιες οµοιότητες µε τα αντίστοιχα που υποβάλλονται σε ένα τυπικό Σ Β. Ως προς τον τύπο των ερωτηµάτων αυτών συνήθως γίνονται δύο βασικοί διαχωρισµοί. Η πρώτη διάκριση επιχειρεί να διαφοροποιήσει τα ερωτήµατα που τίθενται µόνο µια φορά από εκείνα που εκτελούνται επί µακρόν. Τα ερωτήµατα στιγµιοτύπου (snapshot ή one-time queries), όταν υποβληθούν στο σύστηµα, υπολογίζονται έχοντας ως αναφορά την τρέχουσα κατάσταση (στιγµιότυπο) της βάσης δεδοµένων. Με την ολοκλήρωση των υπολογισµών, η απάντηση επιστρέφεται στο χρήστη. Τέτοια είναι τα ερωτήµατα που κατά κόρον διεκπεραιώνονται από τα συµβατικά Σ Β, όπου ο χρήστης πρέπει να ενεργήσει ώστε να αντλήσει τις πληροφορίες που τον ενδιαφέρουν (pull model). Απεναντίας, οι απαντήσεις στα ερωτήµατα διαρκείας (continuous queries) υπολογίζονται συνεχώς καθώς τα δεδοµένα του ρεύµατος εξακολουθούν να καταφθάνουν αθρόα. Τα ερωτήµατα διαρκείας εκτελούνται µονίµως επί µεγάλο χρονικό διάστηµα, µέχρις ότου ο χρήστης τα αποσύρει ή αναστείλει τον υπολογισµό τους. Το ίδιο το σύστηµα αναλαµβάνει να προωθήσει τα νέα αποτελέσµατα προς το χρήστη (push model), όποτε αυτά καταστούν διαθέσιµα, χωρίς εκείνος να είναι υποχρεωµένος να υποβάλλει αλλεπάλληλα το ίδιο ερώτηµα. Οι απαντήσεις που δίνονται µπορούν να αποθηκεύονται και να ανανεώνονται ανάλογα µε το ρυθµό άφιξης των δεδοµένων, αλλά είναι δυνατόν να λαµβάνουν οι ίδιες τη µορφή ρευµάτων δεδοµένων. Έτσι, συνήθως κρίνεται σκόπιµο να αποθηκεύονται οι απαντήσεις σε ερωτήµατα συνάθροισης (aggregate queries), αφού οι πλειάδες του αποτελέσµατος είναι συνήθως λίγες και τυχόν συχνές αλλαγές δεν έχουν ισχυρό αντίκτυπο στη λειτουργία του συστήµατος. Αντίθετα, σε ερωτήµατα σύνδεσης (join queries) είναι προτιµότερο οι ταχύτατα παραγόµενες και ποσοτικά απεριόριστες απαντήσεις να εξάγονται ως ρεύµατα δεδοµένων. Για παράδειγµα, σε συστήµατα διαχείρισης δικτύων υπολογιστών, χρειάζονται ερωτήµατα διαρκείας για να ελέγχουν online την οµαλή λειτουργία τους και να ανιχνεύσουν τυχόν ανωµαλίες (λ.χ. συµφόρηση συνδέσεων) ή τις αιτίες τους (λ.χ. βλάβη στο υλικό ή απειλή για την ασφάλεια του δικτύου από επιθέσεις τρίτων). Σε οικονοµικού περιεχοµένου εφαρµογές, ερωτήµατα διαρκείας µπορούν να τεθούν για να εντοπίζονται τάσεις της αγοράς ή χρηµατιστηριακές ευκαιρίες της στιγµής. 8

1.4 Ερωτήµατα σε ρεύµατα δεδοµένων Παράδειγµα 1.4.1. Ερώτηµα στιγµιοτύπου: «Να δοθεί η χρονοσειρά των θερµοκρασιών που καταγράφηκαν στο µετρητικό σταθµό κατά τη διάρκεια του περασµένου µήνα». Το ερώτηµα ορίζεται πάνω στις χρονοσειρές που υπάρχουν διαθέσιµες µέχρι τη χρονική στιγµή υποβολής του ερωτήµατος, καλύπτοντας µόνο δεδοµένα του παρελθόντος και του παρόντος. Ερώτηµα διαρκείας: «Να δίνεται η χρονοσειρά της θερµοκρασίας που θα καταγράφεται στο µετρητικό σταθµό καθηµερινά στις 10 το πρωί για τις επόµενες τρεις εβδοµάδες». Το ερώτηµα καλύπτει όχι µόνο τις χρονοσειρές που υπάρχουν όταν αυτό τίθεται, αλλά και όσες αλλαγές συµβούν µελλοντικά µέχρι τον τερµατισµό της εκτέλεσης, αφού τα ερωτήµατα διαρκείας καλύπτουν περασµένα, τωρινά και µελλοντικά δεδοµένα. Ο δεύτερος διαχωρισµός γίνεται µεταξύ ερωτηµάτων που είναι γνωστά εκ των προτέρων και εκείνων που τίθενται όταν ήδη κάποιος όγκος στοιχείων έχει εισρεύσει στο σύστηµα. Τα προκαθορισµένα ερωτήµατα (predefined queries) έχουν υποβληθεί στο σύστηµα πριν την άφιξη οποιουδήποτε τµήµατος του ρεύµατος δεδοµένων. Συνήθως, τα προκαθορισµένα ερωτήµατα είναι ερωτήµατα διαρκείας, χωρίς να αποκλείεται η περίπτωση να προδιαγραφεί η µελλοντική υποβολή ερωτηµάτων που θα τεθούν σποραδικά (ερωτήµατα στιγµιοτύπου). Από την άλλη πλευρά, τα µη προβλέψιµα ερωτήµατα (ad hoc queries) υποβάλλονται online αφού τα στοιχεία αρχίσουν να καταφθάνουν. Πρόκειται κυρίως για ερωτήµατα διαρκείας που τίθενται δυναµικά στο σύστηµα σε κάποια επόµενη φάση και γι αυτό περιπλέκουν σε µεγάλο βαθµό το σχεδιασµό ενός συστήµατος διαχείρισης ρευµάτων δεδοµένων. Προφανώς, αφού τα ερωτήµατα δεν είναι εκ των προτέρων γνωστά, δεν µπορούν να ληφθούν υπόψη κατά το στάδιο της βελτιστοποίησης ερωτηµάτων (query optimization), της ταυτοποίησης κοινών υποεκφράσεων µεταξύ ερωτηµάτων κ.λ.π. Κυρίως όµως, η απάντηση στο ερώτηµα είναι πιθανόν να απαιτεί αναφορά σε δεδοµένα που έχουν ήδη παρέλθει, δηλαδή ιστορικά στοιχεία που ίσως δεν έχουν τηρηθεί, οπότε δεν υπάρχει καµιά δυνατότητα ανάκτησής τους στο µέλλον. Με λίγα λόγια, σε ένα συµβατικό Σ Β, η υποβολή των ερωτηµάτων είναι εκείνη που επιβάλλει προσπέλαση στα (αποθηκευµένα) δεδοµένα, ενώ αντίθετα η άφιξη των ρευµάτων δεδοµένων ενεργοποιεί ένα σύνολο (υποβληθέντων) ερωτηµάτων. Ακόµη περισσότερο, δεν µπορεί να αποκλειστεί το ενδεχόµενο οι συνθήκες που επικρατούν στο σύστηµα (λ.χ. ο φόρτος, τα χαρακτηριστικά ή ο ρυθµός προσέλευσης δεδοµένων) να µεταβληθούν, οπότε και τα ερωτήµατα µπορεί να τροποποιηθούν. Εκ των πραγµάτων λοιπόν, η επεξεργασία των ερωτηµάτων που υποβάλλονται σε ένα Σύστηµα ιαχείρισης Ρεύµατος εδοµένων (Σ Ρ ) αποτελεί ένα πολύπλοκο ζήτηµα. Επιπλέον, σε επιµέρους πτυχές είναι δυνατόν να υπάρχουν διαφορετικές εναλλακτικές προσεγγίσεις, όπως παρουσιάζεται σε επόµενο κεφάλαιο. Στον πίνακα 1.1 της επόµενης σελίδας, συνοψίζονται επιγραµµατικά τα κυριότερα χαρακτηριστικά των ρευµάτων δεδοµένων σε αντιπαραβολή προς τα τυπικά συστήµατα διαχείρισης βάσεων δεδοµένων. 9

Εισαγωγή στα συστήµατα ρευµάτων δεδοµένων. Σύστηµα διαχείρισης βάσεων δεδοµένων Σύστηµα διαχείρισης ρευµάτων δεδοµένων Στατικές σχέσεις Εφήµερα ρεύµατα δεδοµένων Ερωτήµατα στιγµιοτύπου (One-time queries) Ερωτήµατα διαρκείας (Continuous queries) Τυχαία προσπέλαση πλειάδων (random access) ιαδοχική προσπέλαση πλειάδων (sequential access) «Απεριόριστος» αποθηκευτικός χώρος Πεπερασµένη ποσότητα κύριας µνήµης Μόνο το τρέχον στιγµιότυπο της βάσης δεδοµένων έχει σηµασία Ο χώρος όπου τηρούνται τα δεδοµένα είναι «παθητικός» (απλώς για την αποθήκευση). (pull-model) Σχετικά χαµηλός ρυθµός αλλαγών στα δεδοµένα, έπειτα από ενέργειες των χρηστών Η σειρά άφιξης των πλειάδων στο σύστηµα έχει σηµασία Τα πρόσφατα δεδοµένα τηρούνται στη µνήµη, και η άφιξή τους ενεργοποιεί τα ερωτήµατα. (push model) Πιθανόν να καταφθάνουν ραγδαία ογκώδη δεδοµένα (πολλά GB από τις πηγές δεδοµένων) Τα δεδοµένα θεωρούνται ακριβή Τα δεδοµένα πιθανόν να είναι παρωχηµένα ή να περιέχουν ανακρίβειες και ελλείψεις Η απάντηση δεν απαιτείται σε πραγµατικό χρόνο, αλλά θα είναι ακριβής Η εκτέλεση των προσχεδίων ερωτηµάτων εξαρτάται από τον επεξεργαστή και το φυσικό σχεδιασµό της βάσης δεδοµένων Η απάντηση απαιτείται σε πραγµατικό χρόνο (real-time response), έστω και προσεγγιστικά Ο ρυθµός άφιξης των δεδοµένων και τα χαρακτηριστικά τους θεωρούνται µεταβαλλόµενα και µη προβλέψιµα Πίνακας 1.1: Αντιπαραβολή χαρακτηριστικών µεταξύ Συστηµάτων ιαχείρισης Βάσεων εδοµένων (DBMS) και Ρευµάτων εδοµένων (DSMS) 1.5 Ένα ολοκληρωµένο παράδειγµα Χαρακτηριστικό παράδειγµα συστήµατος όπου βρίσκει εφαρµογή η λογική των ρευµάτων δεδοµένων αποτελούν οι συνδιαλέξεις που γίνονται µέσω ενός τηλεφωνικού δικτύου. Οι κλήσεις που αφορούν κάθε συνδροµητή, µπορούν να χαρακτηριστούν είτε ως εισερχόµενες (Incoming), όταν αυτός δέχεται κάποιες κλήσεις, είτε ως εξερχόµενες (Outgoing) όταν εκείνος καλεί κάποιους άλλους τηλεφωνικούς αριθµούς. Άρα οι εισερχόµενες και οι εξερχόµενες κλήσεις µπορούν να θεωρηθούν ως δύο ρεύµατα δεδοµένων µε παράλληλη χρονική εξέλιξη. Για λόγους ευκολίας, ας υποτεθεί ότι τα πεδία των εγγραφών που καταγράφονται στο τηλεφωνικό κέντρο - τόσο για τις εξερχόµενες όσο και για τις εισερχόµενες κλήσεις - είναι αυτά που αναφέρονται στον παρακάτω πίνακα: 10

1.5 Ένα ολοκληρωµένο παράδειγµα Call_ID Call_number Timestamp Event Type O µοναδικός κωδικός της κλήσης (δίνεται από το κέντρο) Ο τηλεφωνικός αριθµός του καλούντος (εξερχόµενες) ή του καλούµενου (εισερχόµενες) Η χρονική στιγµή που καταγράφηκε η συνδιάλεξη Έναρξη ή λήξη της συνδιάλεξης (START/END) Η κατηγορία της συνδιάλεξης (αστική, υπεραστική, διεθνής) Παράδειγµα 1.5.1. Μια από τις προφανείς ερωτήσεις που ίσως θελήσει να θέσει κάποιος από τους διαχειριστές του τηλεφωνικού δικτύου είναι «Ποιές συνδιαλέξεις έχουν χρονική διάρκεια πάνω από 3 λεπτά;». Πρόκειται για ένα µη προβλέψιµο (ad hoc) ερώτηµα που είναι δυνατόν να υποβληθεί στο σύστηµα οποτεδήποτε θελήσει ο χρήστης µε τη χρονική παράµετρο της αρεσκείας του. Μια πιθανή εκδοχή αυτού του ερωτήµατος σε µορφή SQL είναι: SELECT O1.Call_ID, O1.Call_number FROM Outgoing O1, Outgoing O2 WHERE O1.Call_ID=O2.Call_ID AND O1.Call_Number=O2.Call_Number AND O1.Event='START' AND O2.Event='END' AND (O2.Timestamp - O1.Timestamp > 3) Όπως είναι εµφανές, στην περίπτωση αυτή υπάρχει σύνδεση ενός ρεύµατος δεδοµένων (Outgoing) µε τον εαυτό του (self-join). Το αποτέλεσµα της σύνδεσης απαιτεί απεριόριστο χώρο αποθήκευσης, ο οποίος φυσικά δεν µπορεί να διατεθεί από την κύρια µνήµη. Πάντως, το αποτέλεσµα µπορεί να λάβει τη µορφή ρεύµατος δεδοµένων, όπου επίσης µπορούν να καταγραφούν συνδιαλέξεις που ενδεχοµένως δεν έχουν ακόµη ολοκληρωθεί (δεν υπάρχει ακόµη ένδειξη END), αλλά έχουν ξεπεράσει την απαιτούµενη χρονική διάρκεια. Παράδειγµα 1.5.2. Ένα άλλο ουσιαστικό ερώτηµα διαρκείας που µπορεί να τεθεί στο πλαίσιο ενός συστήµατος ρεύµατος δεδοµένων θα ήταν «Μεταξύ ποιων αριθµών γίνονται συνδιαλέξεις;». Η έκφραση του ερωτήµατος σε SQL µπορεί να διατυπωθεί ως εξής: SELECT I.Call_number AS Called, O.Call_number AS Caller FROM Incoming I, Outgoing O WHERE O.Call_ID=I.Call_ID Και πάλι, το αποτέλεσµα της σύνδεσης (join) µεταξύ των δύο ρευµάτων θα είναι επίσης ρεύµα δεδοµένων, που κατά πάσα πιθανότητα απαιτεί ανεξάντλητο προσωρινό χώρο αποθήκευσης για τον υπολογισµό. Οι ανάγκες είναι δυνατόν να περιοριστούν µόνο στην περίπτωση που τα δύο συνδεόµενα ρεύµατα είναι συγχρονισµένα, δηλαδή εξελίσσονται παράλληλα εντός µικρού σχετικά χρονικού παραθύρου. Παράδειγµα 1.5.3. Χρήσιµο ερώτηµα θα ήταν και το «Πότε κλήθηκε για τελευταία φορά κάθε συνδροµητής;». Βεβαίως πρόκειται για ερώτηµα διαρκείας (continuous query), αφού το αποτέλεσµα θα πρέπει να υπολογίζεται ξανά κάθε φορά που συµβαίνει κάποια συνδιάλεξη: 11

Εισαγωγή στα συστήµατα ρευµάτων δεδοµένων. SELECT Call_number AS Called, ΜΑΧ(Timestamp) AS Last_Call FROM Incoming GROUP BY Call_number Πάντως, ενδεχόµενη αποθήκευση της απάντησης σε έναν στατικό πίνακα µε τη µορφή υλοποιηµένης όψης (materialized view) δεν ενδείκνυται, αφού πολύ συχνά διάσπαρτες εγγραφές του πίνακα θα πρέπει να ενηµερώνονται ως προς το πότε συνέβη η τελευταία κλήση. Παράδειγµα 1.5.4. Εύλογο είναι το ενδιαφέρον που έχουν οι τηλεφωνικές εταιρείες σχετικά µε το συνολικό χρόνο συνδιαλέξεων για κάθε συνδροµητή, στοιχείο που φυσικά καθορίζει και το ύψος της αντίστοιχης χρέωσης. Για τη δοµή των δεδοµένων που έχει περιγραφεί, το ερώτηµα συντάσσεται µε χρήση τελεστή συνάθροισης και οµαδοποίηση των στοιχείων: SELECT O1.Call_number AS Caller, SUM(O2.Timestamp-O1.Timestamp) AS Charge_time FROM Outgoing O1, Outgoing O2 WHERE O1.Call_ID=O2.Call_ID AND O1.Event='START' AND O2.Event='END' GROUP BY O1.Call_number [ORDER BY Charge_time DESC] Παρά την αναµφισβήτητη αξία του, δεν υπάρχει τρόπος να απαντηθεί επαρκώς το ερώτηµα όταν συνεχώς καταφθάνουν νέα στοιχεία, διότι τότε επιβάλλεται διαρκής επανυπολογισµός του αποτελέσµατος. Μια πιθανή λύση θα ήταν να αποθηκευτεί προσωρινά ένα ενδιάµεσο αποτέλεσµα το οποίο θα ενηµερώνεται εφεξής. Τότε το σύστηµα θα µπορούσε να δίνει για κάθε συνδροµητή ως συνολικό χρόνο οµιλίας την τελευταία επικαιροποιηµένη τιµή που έχει διαθέσιµη. Και πάλι όµως, λόγω του γνωστού περιορισµού στην ποσότητα µνήµης που µπορεί να δεσµευτεί, αυτό το αποτέλεσµα είναι αδύνατον να αποθηκευτεί στο σύνολό του και να ενηµερώνεται δυναµικά. Σε ενδεχόµενη πρόσθετη απαίτηση τα αποτελέσµατα να παρουσιάζονται κατά φθίνουσα σειρά βάσει του χρόνου οµιλίας (όπως επιτάσσει η τελευταία γραµµή της εντολής), η κατάσταση επιδεινώνεται περαιτέρω, αφού προστίθεται και δεύτερος ανασχετικός τελεστής (blocking operator) που αφορά την ταξινόµηση. Παράδειγµα 1.5.5. Αξιοπρόσεκτο είναι και το ακόλουθο ερώτηµα διαρκείας: «Ποιες ώρες ο αριθµός των εξερχοµένων κλήσεων κάθε συνδροµητή υπερβαίνει ένα καθορισµένο όριο;», µε το οποίο γίνεται απόπειρα να εντοπιστούν οι λεγόµενες «ώρες αιχµής» όπου γίνονται τα περισσότερα τηλεφωνήµατα. Στην εντολή SQL που παρουσιάζεται παρακάτω, η υποθετική συνάρτηση GetHour έχει οριστεί από τον χρήστη και εξυπηρετεί προφανώς στον προσδιορισµό της ώρας του τηλεφωνήµατος. Κατ αυτόν τον τρόπο, όλες οι συνοµιλίες ανάγονται σε κάποιο χρονικό διάστηµα της µιας ώρας (λ.χ. 00:00-01:00, 01:00-02:00,...κ.ο.κ.) βάσει του χρονικού τους οροσήµου (timestamp): SELECT GetHour(O.Timestamp) AS Peak_Hour, COUNT(O.Call_ID) AS Total_Calls FROM Outgoing O GROUP BY GetHour(O.Timestamp) HAVING COUNT(O.Call_ID) > T Ο ισχυρισµός ότι το ερώτηµα θα µπορούσε να απαντηθεί και από ένα ενεργό σύστηµα βάσεων δεδοµένων (active database), µε χρήση των κατάλληλων triggers, αφήνει ακάλυπτη την περίπτωση όπου ο αριθµός των καταγραφόµενων στοιχείων είναι υπερβολικά µεγάλος. Άρα µόνο κάποια 12

1.5 Ένα ολοκληρωµένο παράδειγµα προσεγγιστική απάντηση είναι εφικτή, καταφεύγοντας λ.χ. σε µεθόδους τυχαίας δειγµατοληψίας, οι οποίες βεβαίως δεν παρέχονται από τέτοια συστήµατα. Παράδειγµα 1.5.6. Η παρατήρηση του όγκου των τηλεφωνικών συνδιαλέξεων µεταξύ περιοχών έχει επίσης ενδιαφέρον, αφού µπορεί να διαπιστωθεί αφενός µεν η ανάγκη βελτίωσης της τηλεπικοινωνιακής υποδοµής (λ.χ. χρήση οπτικών ινών µεταξύ µεγάλων αστικών κέντρων), αφετέρου δε ξαφνική υπερφόρτωση τµηµάτων του δικτύου. Μια ενδεχόµενη διατύπωση αυτού του ερωτήµατος θα ήταν «Μεταξύ ποιών περιοχών εντοπίζεται ο µεγαλύτερος αριθµός (έστω το ανώτερο 10%) των τηλεφωνικών συνδιαλέξεων;». Βεβαίως, οι περιοχές µπορούν να προσδιοριστούν από τα πρώτα ψηφία των αριθµών κλήσης (π.χ. τα πρώτα 5 ψηφία για την Ελλάδα). Στην εντολή SQL που ακολουθεί, υποτίθεται ότι υπάρχει ήδη ορισµένη από τον χρήστη η συνάρτηση GetAreaExt, η οποία λαµβάνει ως παράµετρο τον αριθµό (π.χ. 210 64 38 206) και επιστρέφει το τηλεφωνικό κέντρο (210 64). Σηµειώνεται επίσης, ότι για τη διευκόλυνση της διατύπωσης του ερωτήµατος χρησιµοποιείται η δοµή WITH που προβλέπεται από την SQL-99 (µολονότι δεν υλοποιείται από διάφορους κατασκευαστές λογισµικού): WITH Load AS (SELECT GetAreaExt(O.Call_number) AS Area_Caller, GetAreaExt(I.Call_number) AS Area_Called, COUNT(*) AS Num_Calls FROM Incoming I, Outgoing O WHERE O.Call_ID=I.Call_ID GROUP BY GetAreaExt(O.Call_number), GetAreaExt(I.Call_number)) SELECT Area_Caller, Area_Called, Num_Calls FROM Load L1 WHERE (SELECT COUNT(*) FROM Load L2 WHERE L2.Num_Calls < L1.Num_Calls) > (SELECT 0.9 * COUNT(*) FROM Load)) ORDER BY Num_Calls Η πολυπλοκότητα αυτού του σύνθετου ερωτήµατος διαρκείας, σε σχέση µε τα προηγούµενα, είναι εµφανής. Πέραν της σύνδεσης δύο ρευµάτων δεδοµένων, η κατάσταση επιβαρύνεται ιδιαίτερα από την παρουσία ανασχετικών τελεστών (blocking operators), όπως η ταξινόµηση (ORDER BY) και οι τελεστές συνάθροισης που επιβάλλουν οµαδοποίηση των στοιχείων (GROUP BY). Η τακτική που εφαρµόζουν µεγάλοι τηλεπικοινωνιακοί οργανισµοί είναι συνήθως η αποθήκευση στοιχείων των συνδιαλέξεων σε κάποιο σύστηµα διαχείρισης βάσεων δεδοµένων και η επεξεργασία τους εκ των υστέρων (offline). Για παράδειγµα, τα στοιχεία όλων των ηµερήσιων κλήσεων µέσω καρτοτηλεφώνων διοχετεύονται µαζικά στο κεντρικό σύστηµα του ΟΤΕ και µάλιστα, κατά τις νυχτερινές ώρες όταν η κίνηση στο δίκτυο είναι µειωµένη. Φυσικά, λόγω του υπερβολικού τους όγκου, δεν µπορούν να διατηρηθούν παρά για µικρό µόνο χρονικό διάστηµα (µερικές εβδοµάδες), οπότε καταχωρούνται µόνο βασικά στατιστικά στοιχεία. Μια άλλη αντιµετώπιση, που υιοθετείται από την ΑΤ&Τ, προκρίνει την υλοποίηση µιας ειδικής γλώσσας µε την οποία διατυπώνονται όλα τα ερωτήµατα (βλ. Hancock στην επόµενη ενότητα). Στην περίπτωση αυτή, η αναγκαιότητα ύπαρξης βάσης δεδοµένων εκλείπει εντελώς και για τα ερωτήµατα πρέπει να γραφεί ειδικός κώδικας, ο οποίος βεβαίως µπορεί να επιτυγχάνει ικανοποιητικούς χρόνους απόκρισης, αξιοποιώντας ήδη γνωστά χαρακτηριστικά της πληροφορίας. 13

Εισαγωγή στα συστήµατα ρευµάτων δεδοµένων. Είναι αναµενόµενο ότι σε όλες τις παραπάνω καταστάσεις, τεχνικές που θα παρουσιαστούν στα επόµενα κεφάλαια, όπως η προσαρµοζόµενη επεξεργασία ερωτηµάτων (adaptive query processing), θα µπορούσαν να αποβούν χρήσιµες, λαµβάνοντας υπόψη τον κυµαινόµενο βαθµό φόρτισης ενός τηλεφωνικού δικτύου. 1.6 Επισκόπηση των κυριότερων συστηµάτων ρευµάτων δεδοµένων Στην ενότητα αυτή θα παρουσιαστούν συνοπτικά τα κυριότερα συστήµατα που ασχολούνται µε ρεύµατα δεδοµένων ή υποστηρίζουν ερωτήµατα διαρκείας. Έµφαση θα δοθεί κυρίως στην αρχιτεκτονική δοµή του καθενός, καθώς και στους περιορισµούς που ισχύουν σχετικά µε τα χαρακτηριστικά των στοιχείων που επεξεργάζονται. Θίγονται επίσης ζητήµατα που άπτονται της διατύπωσης και επεξεργασίας ερωτηµάτων, της διαχείρισης πόρων και του περιβάλλοντος αλληλεπίδρασης µε το χρήστη. Εκτενέστερη αναφορά γίνεται σε τέσσερα από αυτά (Aurora, NiagaraCQ, STREAM, TelegraphCQ), που έχουν εµφανιστεί πιο πρόσφατα, κρίνοντας ότι είτε εµφανίζουν πιο ολοκληρωµένη οπτική αντιµετώπισης των ιδιαίτερων θεµάτων που ανακύπτουν σχετικά µε τα ρεύµατα δεδοµένων είτε προτείνουν µερικές πρωτότυπες ιδέες ή αλγορίθµους. Στοιχεία αυτών των συστηµάτων θα αναλυθούν διεξοδικότερα και σε επόµενα κεφάλαια, εξετάζοντας µε περισσότερες λεπτοµέρειες την προσέγγισή τους σε ό,τι αφορά τα ερωτήµατα διαρκείας. 1.6.1 Alert Η υλοποίηση του Alert το 1991 από την IBM βασίστηκε στο Starburst ως επέκταση ενός συµβατικού Σ Β, µε στόχο τη µετατροπή του από παθητικό (passive) σε ενεργό (active). Έτσι, αντί να χρειάζεται οι χρήστες να κατευθύνουν το σύστηµα µε προγράµµατα που υποβάλλουν (program-driven), αρκεί να δηλώσουν ποιες πληροφορίες ενδιαφέρονται να λάβουν (data-driven). Εποµένως, το σύστηµα τελικά δίνει απαντήσεις όχι µόνο για τα δεδοµένα που υπάρχουν εκείνη τη στιγµή, αλλά παραµένει σε εγρήγορση ώστε να παράσχει και δεδοµένα που θα προκύψουν µελλοντικά. Το Alert επιτρέπει στους χρήστες να ορίσουν ενεργούς πίνακες (active tables), όπου µόνο η εισαγωγή νέων εγγραφών είναι δυνατή (append-only). Τα ενεργά ερωτήµατα (active queries) που εφαρµόζονται πάνω στους πίνακες αυτούς, αλλά και σε συσχετισµούς µε τυπικούς πίνακες, είναι περισσότερο πολύπλοκα από τους triggers που έχουν ενσωµατωθεί στις συµβατικές βάσεις δεδοµένων. Εποµένως, είναι δυνατόν να έχουν οριστεί πάνω σε πολλαπλούς πίνακες ή και όψεις (views), ενώ επιτρέπεται η ένθεσή τους (nesting), καθώς και οι συνδέσεις (joins). Από πλευράς υλοποίησης, η σύνταξη των εντολών SQL παραµένει σχεδόν ανέπαφη, µε τη µόνη προσθήκη ότι πλέον τα ερωτήµατα αναφέρονται και σε ενεργούς πίνακες. Έτσι, οι διαθέσιµες δυνατότητες σηµασιολογικού ελέγχου, βελτιστοποίησης και εκτέλεσης των ερωτηµάτων εξακολουθούν να ισχύουν στο ακέραιο. Η υλοποίηση των ενεργών ερωτηµάτων εξαρτάται απολύτως από την εγγενή δυνατότητα του συστήµατος όπου θα αναπτυχθούν να τα υποστηρίξει αποτελεσµατικά. Οι κανόνες παραγωγής (production rules) που συµπεριλαµβάνονται στο σύστηµα είναι ενεργά ερωτήµατα που ορίζονται µε τον ίδιο τρόπο όπως οι όψεις (views): οι συνθήκες διατυπώνονται στις προτάσεις FROM και WHERE, ενώ οι ενέργειες - που θα εκτελεστούν όταν οι συνθήκες επαληθευτούν παρατίθενται στην πρόταση SELECT. Οι κανόνες ενεργοποιούνται και 14

1.6 Επισκόπηση των κυριότερων συστηµάτων ρευµάτων δεδοµένων απενεργοποιούνται µε τις κατάλληλες εντολές, οπότε ο ίδιος κανόνας είναι δυνατόν να εφαρµοστεί ταυτόχρονα από διαφόρους χρήστες κατά διαφορετικούς τρόπους. Το υποσύστηµα των κανόνων ελέγχει την επικοινωνία µεταξύ των δοσοληψιών, τη δυνατότητα συγχρονισµού τους, καθώς και τη χρονική στιγµή εκτέλεσης. Η αρχιτεκτονική του συστήµατος προβλέπει την ύπαρξη ενός επόπτη (monitor), ο οποίος διαχειρίζεται τους ενεργούς πίνακες και επιτηρεί τις αλλαγές που συµβαίνουν στην κατάσταση της βάσης δεδοµένων, φροντίζοντας µε το κατάλληλο φιλτράρισµα να αποφεύγει τον έλεγχο εγγραφών άσχετων προς το ερώτηµα. Για το σκοπό αυτό, αφενός τηρείται κατάλογος µε τους πίνακες που εµπλέκονται σε κάθε ενεργό ερώτηµα, ενώ συµφέρει η χρήση δεικτών για την αποδοτικότερη αναζήτηση των σχετικών πλειάδων. ([SPAM91]) 1.6.2 AURORA Το AURORA είναι ένα γενικού σκοπού Σύστηµα ιαχείρισης Ρευµάτων εδοµένων που σχεδιάζεται και υλοποιείται από το 2001 µε τη σύµπραξη των Πανεπιστηµίων Brandeis και Brown καθώς και του M.I.T. Για την επεξεργασία των ρευµάτων, στο σύστηµα AURORA προτείνεται µια προσέγγιση βασισµένη σε ένα γραφικό περιβάλλον µε «κουτιά» και «βέλη» (boxes and arrows), θυµίζοντας ένα διάγραµµα ροής δεδοµένων. Οι πρωτογενείς τελεστές («κουτιά») χρησιµοποιούνται για να συνθέσουν το ερώτηµα που πρέπει να υποβληθεί στο σύστηµα, ενώ βάσει αυτών υλοποιούνται και άλλοι, πιο πολύπλοκοι, όπως οι γνωστοί τελεστές συγχώνευσης (merge,+), σύνδεσης (join, ), επιλογής (filter, σ), κατάργησης (drop, δ) πλειάδων κ.ά. Οι χρήστες µπορούν επίσης να διατυπώνουν τα ερωτήµατά τους σε µια δηλωτική γλώσσα (όπως µια επέκταση της SQL), έπειτα όµως είναι απαραίτητος ο µετασχηµατισµός τους στην αναπαράσταση που αντιλαµβάνεται το σύστηµα (µε «κουτιά» και «βέλη»). Ουσιαστικά λοιπόν, το σύστηµα µοιάζει µε ένα δίκτυο που αποτελείται από έναν µεγάλο αριθµό triggers, στο οποίο ο διαχειριστής των εφαρµογών µπορεί δυναµικά να προσθαφαιρεί τελεστές. Ο χρονοπρογραµµατιστής (scheduler) αποτελεί το συνδετικό κρίκο όλων των τµηµάτων των αρχιτεκτονικής του συστήµατος, όπως εικονίζεται και στο διπλανό σχήµα 1.2. Αυτός αποφασίζει ποια «κουτιά» θα τρέξουν στη συνέχεια, µέσω µιας διαδικασίας που λέγεται train scheduling. Βάσει αυτής, προσδιορίζεται τόσο ο αριθµός των πλειάδων που θα τελούν εν αναµονή επεξεργασίας µπροστά σε κάποιο τελεστή, όσο και η πορεία των στοιχείων διαµέσου των τελεστών προς την έξοδο. Οι πλειάδες που καταλήγουν στην έξοδο παρακολουθούνται µονίµως από τον Επόπτη Ποιότητας (QoS Monitor), επιση- µαίνοντας στον χρονοπρογραµµατιστή χρήσιµα στοιχεία για τις επιδόσεις του συστήµατος. Σχέδιο 1.2: Αρχιτεκτονική του Συστήµατος ιαχείρισης Ρευµάτων εδοµένων AURORA. (Πηγή: [CCC+02]) 15

Εισαγωγή στα συστήµατα ρευµάτων δεδοµένων. Υπάρχει επίσης ένας διαχειριστής αποθήκευσης (Storage Manager) που αναλαµβάνει να οδηγήσει τις πλειάδες σε ενδιάµεσες ουρές (buffer queues). Αυτό θα συµβεί όταν διαπιστωθεί ότι εξαντλείται η διαθέσιµη ποσότητα µνήµης, κάτι που δεν µπορεί να αποκλειστεί όταν τα ιστορικά στοιχεία που συσσωρεύονται στα σηµεία σύνδεσης διογκωθούν υπερβολικά. Κάθε τελεστής δέχεται ρεύµατα εισόδου (τα «βέλη» εισόδου), τα µετασχηµατίζει µε κάποιο συγκεκριµένο τρόπο, ανάλογα µε τη σηµασιολογία του και τελικά παράγει ένα ή περισσότερα ρεύµατα (τα «βέλη» εξόδου). Εποµένως, τα στοιχεία του ρεύµατος διέρχονται µέσα από το δίκτυο των τελεστών, που µπορεί να θεωρηθεί ως ένας άκυκλος κατευθυνόµενος γράφος (loop-free directed graph) εκτελούµενων λειτουργιών. Τελικά τα στοιχεία καταλήγουν στην έξοδο, οι πλειάδες της οποίας τροφοδοτούν κάποια εφαρµογή κατά ασύγχρονο τρόπο, ανάλογα δηλαδή προς το ρυθµό παραγωγής τους. Η πλειοψηφία των ερωτηµάτων που εκτελούνται στο σύστηµα είναι ερωτήµατα διαρκείας, ενώ η υποβολή µη προβλέψιµων ερωτηµάτων µπορεί να γίνει σε συγκεκριµένα σηµεία σύνδεσης (connection points), δηλαδή προκαθορισµένες θέσεις στο δίκτυο τελεστών όπου φυλάσσονται ιστορικά δεδοµένα. Οι χρήστες έχουν την ευχέρεια να ορίσουν διάφορες απαιτήσεις σχετικά µε την ποιότητα υπηρεσιών (Quality of Service, QoS) των ερωτηµάτων που θέτουν στο σύστηµα. Χαρακτηριστικά όπως η αξιοπιστία, οι επιδόσεις και η ακρίβεια των αποτελεσµάτων που προκύπτουν στο ρεύµα εξόδου χρησιµοποιούνται για να σχηµατίσουν έναν δείκτη χρησιµότητας (utility value) των απαντήσεων για την εφαρµογή που τις λαµβάνει στη συνέχεια. Οι ακριβείς απαντήσεις µπορεί να µην επιτευχθούν, εάν ο υψηλός φόρτος του συστήµατος επιβάλλει την απόρριψη κάποιων στοιχείων, αλλά µπορεί να είναι και ανεπιθύµητες, όταν τα δεδοµένα καταφθάνουν µε τόσο αργούς ρυθµούς και οι εφαρµογές περιµένουν αποτελέσµατα πολύ σύντοµα. Έτσι, ανάλογα και µε την εφαρµογή, το σύστηµα προορίζεται να παρέχει συνεχώς ικανοποιητικές απαντήσεις, που βεβαίως εµφανίζουν µετρήσιµες αποκλίσεις ως προς την ακρίβειά τους. Ο βασικός στόχος που τίθεται λοιπόν είναι η µεγιστοποίηση του αθροιστικού µεγέθους της ποιότητας υπηρεσιών (QoS) που λαµβάνεται, συνυπολογίζοντας όλους τους τελεστές («κουτιά»). Βεβαίως, είναι ιδιαίτερα δύσκολο να ληφθούν εκτιµήσεις του QoS για τους εσωτερικούς κόµβους («κουτιά») του συστήµατος, γι αυτό και υπολογίζονται προσεγγιστικά, αξιοποιώντας διαθέσιµα στατιστικά στοιχεία (λ.χ. συντελεστές επιλεκτικότητας τελεστών ή µέσο επεξεργαστικό κόστος) για κάθε «κουτί». Οι προδιαγραφές χρησιµεύουν στη συνέχεια για να αποφασιστεί µε ποιο τρόπο και σε ποιες περιστάσεις θα αποβληθεί κάποιο µέρος των δεδοµένων, ελαφρύνοντας το φόρτο του συστήµατος (load shedding). Εάν το σύστηµα διαπιστώσει ότι η τεχνική αυτή δεν αποδίδει αρκετά, µπορεί να προσπαθήσει να αναδιατάξει το δίκτυο των τελεστών, χρησιµοποιώντας γνωστές µεθόδους βελτιστοποίησης, όπως αυτές που στηρίζονται στην αντιµεταθετικότητα (commutativity) τελεστών. Το AURORA κατεφεύγει σε αυτή την τακτική σπανιότερα, ενώ ως έσχατη λύση για τη βελτιστοποίηση είναι η αναπροσαρµογή του χρονοπρογραµµατιστή (scheduler) συλλέγοντας επιπλέον στατιστικά στοιχεία επιδόσεων ή εναλλάσσοντας τις προτεραιότητες εκτέλεσης που έχουν τεθεί. Κατά συνέπεια, η βελτιστοποίηση ερωτηµάτων στο AURORA επιτυγχάνεται είτε κατά το χρόνο µεταγλώττισης (compile-time optimization) αναδιατάσσοντας το δίκτυο των τελεστών, είτε κατά το χρόνο εκτέλεσης (run-time optimization) µε την ανίχνευση υπερβολικού φόρτου και την επιλεκτική αποβολή πλειάδων. Από τις αρχές του 2003, το σύστηµα επεκτάθηκε ώστε να καλύψει την περίπτωση κατασκευής ενός µεγάλης κλίµακας κατανεµηµένου Σ Ρ. Οι δύο περιπτώσεις που αντιµετωπίζονται είναι το ενδεχόµενο κοινοπραξίας πολλαπλών κόµβων άλλοτε (Intra-participant version) στον ίδιο δικτυακό τόπο (domain) και κάποτε σε διαφορετικό (Inter-participant version). 16

1.6 Επισκόπηση των κυριότερων συστηµάτων ρευµάτων δεδοµένων Στην πρώτη εκδοχή, για Intranet εφαρµογές, προτείνεται το σύστηµα AURORA*, που σχηµατίζεται από πολλούς απλούς κόµβους, σε καθέναν από τους οποίους η παρουσία του AURORA θεωρείται δεδοµένη, όµως το αποκεντρωµένο δίκτυο µπορεί να αναδιαταχθεί δυναµικά. Στη δεύτερη εκδοχή που αναφέρεται σε Internet εφαρµογές, το σύστηµα λέγεται MEDUSA και συντίθεται από κόµβους που ποικίλλουν: άλλοι είναι κόµβοι AURORA, ενώ άλλοι µπορεί να είναι PDA ή αισθητήρες που προµηθεύουν στοιχεία στο σύστηµα. Είναι προφανές ότι το κυριότερο ζήτηµα που ανακύπτει σε τέτοιας κλίµακας συστήµατα είναι η διαχείριση του φόρτου, δηλαδή η δυναµική προσαρµογή της κατανοµής των πόρων και της επεξεργασίας µεταξύ των συνεργαζόµενων κόµβων. Επιπλέον, ο σχεδιασµός καλείται να αντιµετωπίσει προβλήµατα όπως πιθανές βλάβες στους εξυπηρέτες (servers) και στη µεταξύ τους επικοινωνία, σφάλµατα στο λογισµικό, αλλά και αυξηµένα επίπεδα συµφόρησης δεδοµένων. Σε περίπτωση που διαπιστώνεται διακοπή λειτουργίας (failure detection) κάποιων κόµβων, ο µηχανισµός ανάνηψης (recovery) προβλέπει την προσοµοίωση της εκτέλεσης σε κάποιον γειτονικό κόµβο µε συνακόλουθη κατανοµή του φόρτου, αφού, ούτως ή άλλως, λαµβάνεται πρόνοια να αποθηκεύονται οι πλειάδες που τελούν υπό επεξεργασία. ([CCC+02], [CBB+03]) 1.6.3 Cougar Το πρόγραµµα Gougar (µαζί µε το πρόγραµµα Amazon) βρίσκεται σε εξέλιξη στο Πανεπιστήµιο Cornell και αποσκοπεί κυρίως στη διαχείριση κατανεµηµένων δικτύων αισθητήρων (distributed sensor networks). Σε τέτοιο περιβάλλον, αντί τα στοιχεία να συλλέγονται σε κάποιο κεντρικό επεξεργαστή (ίσως εκτός του δικτύου), προτείνεται ένα µέρος της επεξεργασίας να µεταφερθεί στους ίδιους τους κόµβους. Οργανώνοντάς τους σε συστοιχίες (clusters), είναι δυνατόν να ανατεθούν σ αυτούς διεργασίες, όπως ο υπολογισµός ερωτηµάτων συνάθροισης ή η απαλοιφή διπλοτύπων, ώστε να µειωθεί το µέγεθος των στοιχείων που χρειάζεται να µεταδοθούν. Η εκλογή των κόµβων που θα ηγηθούν των αντιστοίχων συστοιχιών πρέπει να γίνει κατά τρόπο που να αντιµετωπίζονται πιθανές εµπλοκές στο δίκτυο (λ.χ. απώλεια δεδοµένων, βλάβη αισθητήρων κ.ά.), ενώ οι επιλεγέντες κόµβοι πρέπει να πλεονεκτούν και από άποψη χωροθέτησης για µείωση του κόστους µετάδοσης. Η µετάδοση των µηνυµάτων µέσω του δικτύου στηρίζεται αφενός στον προσδιορισµό της διαδροµής που θα ακολουθηθεί, όσο και στην διατήρησή της (ή την αποκατάστασή της, εάν διακοπεί). Η αρχιτεκτονική του συστήµατος προβλέπει τρία επίπεδα. Σε κάθε κόµβο υπάρχει ένας αντιπρόσωπος του ερωτήµατος (Query Proxy layer), που παρεµβάλλεται µεταξύ της δροµολόγησης (όπου συµµετέχουν όλοι οι κόµβοι) και των εφαρµογών. Οι κόµβοι µπορούν να ενεργήσουν είτε ως ηγέτες (leaders) των οµάδων όπου ανήκουν είτε να εκτελούν επεξεργασία των δεδοµένων που καταγράφουν οι ίδιοι. Γι αυτό το λόγο, στους κόµβους υπάρχει ένα µικρό τµήµα βάσης δεδοµένων (database component) που έχει δυνατότητες διερµηνείας (interpret) και εκτέλεσης ερωτηµάτων. Συνεπώς, υιοθετείται ένα ιεραρχικό µοντέλο επικοινωνίας και επεξεργασίας των στοιχείων, καθώς οι κόµβοι-ηγέτες µπορούν να συναθροίσουν πλειάδες απ όλους τους άλλους κόµβους της οµάδας πριν τα στείλουν στο ανώτερο επίπεδο. Το δεύτερο επίπεδο παρουσίασης (FrontEnd), αποτελείται από τους κύριους κόµβους (gateway nodes) του συστήµατος που έχουν ισχυρότερες ικανότητες επεξεργασίας ερωτηµάτων από εκείνες των απλών κόµβων. Προκειµένου να επιτυγχάνεται συγχρονισµός της εκτέλεσης, έχουν αναπτυχθεί ειδικές δοµές ελέγχου, ενώ καθώς προχωρούν οι υπολογισµοί (λ.χ. µερικά αθροίσµατα), οι πλειάδες αρχίζουν να συσσωρεύονται στον κύριο κόµβο. Αξίζει να σηµειωθεί ότι όλα τα µηνύµατα που ανταλλάσσονται µεταξύ των κόµβων είναι σε µορφή XML, εποµένως υπάρχει δυνατότητα σύνδεσης και µε άλλα λογισµικά εκτός του δικτύου. Ο βελτιστοποιητής 17

Εισαγωγή στα συστήµατα ρευµάτων δεδοµένων. ερωτηµάτων (query optimizer) αναλαµβάνει να διανείµει τα προσχέδια εκτέλεσης ερωτηµάτων (query plans) που προδιαγράφουν αφενός µεν τη ροή των δεδοµένων µεταξύ όσων κόµβων εµπλέκονται στους υπολογισµούς, αφετέρου δε την επεξεργασία που καλείται να κάνει ο καθένας, και µάλιστα σε ένα δυναµικά µεταβαλλόµενο περιβάλλον (λ.χ. όταν συµβαίνει απενεργοποίηση κόµβων). Αξιοσηµείωτο είναι ότι η έννοια του κόστους ενός προσχεδίου στην περίπτωση αυτή σχετίζεται περισσότερο µε την ισχύ που θα καταναλωθεί για να µεταδοθεί το µήνυµα, παρά µε το χρόνο εκτέλεσης του ερωτήµατος και τη διαχείριση των άλλων πόρων του συστήµατος. Έχει παρατηρηθεί ότι η τοπολογία των αισθητήρων και ο συντελεστής επιλεκτικότητας (selectivity) των διαφόρων τελεστών που υπεισέρχονται στα ερωτήµατα επηρεάζουν καθοριστικά την επιλογή του κατάλληλου προσχεδίου. Τέλος, προβλέπεται ένα γραφικό περιβάλλον διεπαφής (interface) που θα χρησιµεύει στους χρήστες για τον έλεγχο του συστήµατος και φυσικά την υποβολή ερωτηµάτων (στιγµιοτύπου ή διαρκείας) σε SQL. Επίσης, υπάρχει ενσωµατωµένη δυνατότητα οπτικοποίησης της τοπολογίας του δικτύου και ελέγχου της κατάστασης κάθε µεµονωµένου κόµβου ανεξάρτητα. ([YG02], [YG03]) 1.6.4 Gigascope Πρόκειται για ένα σύστηµα βάσης ρευµάτων δεδοµένων που αναπτύσσεται από την AT&T σε συνεργασία µε το Πανεπιστήµιο Carnegie Mellon. Το Gigascope χρησιµοποιείται στη διαχείριση δικτύου τηλεπικοινωνιών ή υπολογιστών και εφαρµόζεται (µέχρι στιγµής πειραµατικά) στην εποπτεία δικτύων οπτικών ινών υψηλών ταχυτήτων, µε ικανότητα µεταφοράς εκατοµµυρίων πακέτων το δευτερόλεπτο. Το σύστηµα έχει χρησιµοποιηθεί σε διάφορες εφαρµογές, όπως ανάλυση δικτύων, ανάλυση πρωτοκόλλων, ανίχνευση µη εξουσιοδοτηµένης διείσδυσης σε δίκτυο, καθώς και ερευνητικούς σκοπούς (λ.χ. video streams). Προκειµένου να είναι εφικτή η επεξεργασία των ρευµάτων εισόδου και η συνακόλουθη µετατροπή τους σε ρεύµατα εξόδου, σε όλες τις πλειάδες προσκολλάται χρονικό ορόσηµο έπειτα από την εκτέλεση των σχετικών ερωτηµάτων διαρκείας. Ειδικά τα ερωτήµατα που άπτονται της ανάλυσης του δικτύου κάνουν ρητή αναφορά στο χρονικό προσδιορισµό των στοιχείων. Σε αντίθεση µε παρόµοιες εφαρµογές τηλεπικοινωνιών που χρησιµοποιούν διαδικαστικές γλώσσες ερωταποκρίσεων, στο Gigascope προτιµήθηκε για λόγους ευελιξίας µια παραλλαγή της SQL (GSQL). Πρόκειται για µια συνεπτυγµένη µορφή της SQL (λ.χ. δεν επιτρέπονται outer joins), αλλά µε ορισµένους πρόσθετους τελεστές (όπως ο τελεστής merge για τη συγχώνευση ρευµάτων δεδοµένων, διατηρώντας όµως τη διάταξη των χρονικών οροσήµων). Οι χρήστες, µέσω ενός µηχανισµού δήλωσης όψεων (views) έχουν τη δυνατότητα ορισµού συναρτήσεων ή τελεστών για εξειδικευµένες λειτουργίες, οι οποίες κατόπιν µπορούν να τεθούν στη διάθεση και των υπολοίπων χρηστών. Όταν υποβάλλονται ερωτήµατα στο σύστηµα, περνούν από τη διαδικασία µεταγλώττισης (compiler) και εξάγονται τµήµατα κώδικα σε C και C++, τα οποία και τελικά εκτελούνται, επιστρέφοντας στους χρήστες τα εξαγόµενα ρεύµατα δεδοµένων. Τα αποτελέσµατα των ερωτηµάτων µπορούν να διοχετευτούν σε αποθήκες δεδοµένων (data warehouses) για περαιτέρω επεξεργασία. ([CJSS03]) 1.6.5 Hancock Η Hancock είναι µια εξειδικευµένη γλώσσα προγραµµατισµού βασισµένη στη C και σχεδιασµένη για να διευκολύνει την εξόρυξη δεδοµένων (data mining), κυρίως από στοιχεία τηλεφωνικών συνδιαλέξεων. Αναπτύσσεται από το 1999 στα εργαστήρια της AT&T σε συνεργασία µε το Πανεπιστήµιο Cornell, αντικαθιστώντας παλαιότερα προγράµµατα σε C που εµφάνιζαν 18

1.6 Επισκόπηση των κυριότερων συστηµάτων ρευµάτων δεδοµένων αξιοσηµείωτες δυσκολίες τόσο στη συντήρηση όσο και στην επαλήθευση της ορθότητάς τους. Βασικός άξονας της υλοποίησης ήταν να δοθεί η ευχέρεια στους προγραµµατιστές να συγγράφουν κώδικα εξαγωγής «υπογραφών» των ρευµάτων δεδοµένων µε αποτελεσµατικό κι αξιόπιστο τρόπο, ανιχνεύοντας τα κυρίαρχα στοιχεία («υπογραφές», signatures) που ενδιαφέρουν περισσότερο τους χρήστες, ανεξαρτήτως του όγκου της επεξεργαζόµενης πληροφορίας. Τα δεδοµένα παραµένουν αποθηκευµένα στο δίσκο, ωστόσο η φυσική τους αναπαράσταση στα αρχεία µετατρέπεται δυναµικά σε µια λογική αναπαράσταση σε εγγραφές για τη διευκόλυνση των υπολογισµών, οπότε τα στοιχεία µπορούν να ταξινοµηθούν κατά διαφόρους τρόπους. Έχοντας τα στοιχεία ταξινοµηµένα, η οµαδοποίηση βάσει των ιδιοτήτων που ζητούνται µπορεί να αποκαλύψει συνάφειες των περιεχοµένων των ρευµάτων. Αξιοποιώντας λοιπόν δοµές που έχουν προκαθορίσει, οι προγραµµατιστές µπορούν να υλοποιήσουν αλγορίθµους που πραγµατοποιούν πολλαπλά επαναληπτικά «περάσµατα». Σε κάθε επανάληψη, υπολογίζονται τα επιθυµητά µεγέθη µε χρήση κατάλληλων συναρτήσεων (λ.χ. αθροίσµατα) και ενηµερώνονται τα αντίστοιχα τµήµατα της «υπογραφής». Είναι επίσης εφικτός ο προσεγγιστικός υπολογισµός κάποιων ποσοτήτων όπου προσδιορίζεται το είδος της πληροφορίας που θα πρέπει να διατηρηθεί, συµπιέζοντας το µέγεθος των εξαγόµενων αρχείων µε ειδικές δοµές (views). Ως προς τη διερεύνηση κάποιων ειδικών χαρακτηριστικών ή περιπτώσεων µεταξύ των δεδοµένων, παρέχεται η ευχέρεια ορισµού ειδικών συναρτήσεων (event detection functions) βασισµένων σε παράθυρα, που το εύρος τους συνήθως καθορίζεται από τον αριθµό των πλειάδων που θα καλύπτουν. Επιπλέον, υφίστανται µηχανισµοί προστασίας των δεδοµένων από ακούσιες διαγραφές ή παραποιήσεις των «υπογραφών» που έχουν ήδη υπολογιστεί. Βέβαια, η επεξεργασία που πραγµατοποιείται εµπλέκει έναν πολύ µεγάλο αριθµό εγγραφών και αναγνώσεων από το δίσκο (disk I/Os), αφού λόγω του µεγέθους τους τα στοιχεία δεν µπορούν να τηρούνται στη µνήµη, γι αυτό και η βελτιστοποίηση των προγραµµάτων που υπολογίζουν τις «υπογραφές» είναι επιβεβληµένη. Επιπλέον, ο µηχανισµός που παρέχεται προβλέπει τον ορισµό ειδικών συναρτήσεων (προγραµµάτων), ακολουθώντας µια διαδικαστική (procedural) προσέγγιση, αντί να παρέχεται στο χρήστη η δυνατότητα διατύπωσης του ερωτήµατός του λ.χ. σε SQL. Θετικά µπορεί να αξιολογηθεί το γεγονός ότι η γλώσσα Hancock τελικά µπορεί να ανταπεξέλθει σε κλιµακούµενο όγκο στοιχείων (scalability), αφήνοντας ελεύθερο το πεδίο στους προγραµµατιστές να επικεντρωθούν στην ανάλυση που κατά κύριο λόγο τους ενδιαφέρει. ([CFP+00]) 1.6.6 NiagaraCQ Το NiagaraCQ είναι ένα από τα υποσυστήµατα του πρωτότυπου προγράµµατος Niagara που σχεδιάζεται στο Πανεπιστήµιο του Wisconsin από το 1999, µε γνώµονα την εξυπηρέτηση εφαρµογών Internet. Στόχος του είναι η ανάπτυξη σε περιβάλλον JAVA ενός κατανεµηµένου συστήµατος βάσεων δεδοµένων σε ένα περιβάλλον όπου τα ερωτήµατα υποβάλλονται και αποσύρονται δυναµικά, ειδικά για κατανεµηµένα δεδοµένα σε µορφή XML µε χρήση µιας γλώσσας ερωταποκρίσεων όπως η XML-QL. Θεωρητικά, ένας µεγάλος αριθµός χρηστών θα πρέπει να έχει τη δυνατότητα να θέσει ερωτήµατα διαρκείας σε αυτή τη γλώσσα, οπότε το σύστηµα θα πρέπει να µπορεί να υποστηρίξει έναν κλιµακούµενο (scalable) αριθµό από triggers, δηλαδή περίπλοκα ερωτήµατα σε δεδοµένα Internet. Προκειµένου λοιπόν να ανταπεξέρχεται στις απαιτήσεις εκατοµµυρίων ερωτηµάτων, θα πρέπει να µπορεί να τα οµαδοποιήσει βάσει των κοινών τους στοιχείων, αφού είναι αναµενόµενο ότι πολλά ερωτήµατα θα έχουν µεταξύ τους αρκετές οµοιότητες. 19