Optimal Load Balancing in Distributed NoSQL Databases

Transcript

1 ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΤΜΗΜΑ ΜΗΧΑΝΙΚΩΝ Η/Υ ΚΑΙ ΠΛΗΡΟΦΟΡΙΚΗΣ ΠΡΟΓΡΑΜΜΑ ΜΕΤΑΠΤΥΧΙΑΚΩΝ ΣΠΟΥΔΩΝ «ΕΠΙΣΤΗΜΗ ΚΑΙ ΤΕΧΝΟΛΟΓΙΑ ΥΠΟΛΟΓΙΣΤΩΝ» ΜΕΤΑΠΤΥΧΙΑΚΗ ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ Optimal Load Balancing in Distributed NoSQL Databases Βέλτιστη Εξισορρόπηση Φόρτου σε Κατανεμημένες NoSQL Βάσεις Δεδομένων Μάριος Κενδέα ΑΜ: 985 ΠΑΤΡΑ, ΣΕΠΤΕΜΒΡΙΟΣ 2016

2

3 Επιβλέπων Καθηγητής: Αθανάσιος Κ. Τσακαλίδης, Καθηγητής Τριμελής Επιτροπή: Αθανάσιος Τσακαλίδης, Καθηγητής Ιωάννης Γαροφαλάκης, Καθηγητής Χρήστος Μακρής, Επίκουρος Καθηγητής Συνεπιβλέποντες: Σπύρος Σιούτας, Αναπληρωτής Καθηγητής, Ιόνιο Πανεπιστήμιο Γιάννης Τζήμας, Μόνιμος Επίκουρος Καθηγητής, Τ.Ε.Ι. Δυτικής Ελλάδας

4 Η παρούσα εργασία εκπονήθηκε σε συνεργασία με το Εργαστήριο Γραφικών, Πολυμέσων και Γεωγραφικών Συστημάτων του Τμήματος Μηχανικών Η/Υ & Πληροφορικής.

5 Ευχαριστίες Αρχικά θα ήθελα να ευχαριστήσω τον επιβλέποντα καθηγητή µου κο Αθανάσιο Τσακαλίδη καθώς και τους συνεπιβλέποντες καθηγητές κο Σπύρο Σιούτα και κο Γιάννη Τζήμα για την επιστημονική καθοδήγηση που μου πρόσφεραν αλλά και για την εμπιστοσύνη, την εμψύχωση και το χρόνο που απλόχερα διέθεσαν. Επίσης, θερμές ευχαριστίες θα ήθελα να εκφράσω προς τους καθηγητές κο Γαροφαλάκη Ιωάννη και κο Μακρή Χρήστο για την τιμή που µου έκαναν να είναι μέλη της τριμελούς επιτροπής. Θα ήθελα επίσης να ευχαριστήσω τους φίλους και συνεργάτες στο Εργαστήριο Γραφικών, Πολυμέσων και Γεωγραφικών Συστημάτων για την υποστήριξη, την βοήθεια και την συνεργασία όλο αυτό το διάστημα. Οι στιγμές εντός αλλά κυρίως εκτός εργαστηρίου θα μου μείνουν για πάντα αξέχαστες. Ένα μεγάλο ευχαριστώ στους παιδικούς μου φίλους που ακόμα και για τα μεγάλα διαστήματα που είμαστε μακριά, η σκέψη τους μου δίνει δύναμη σε κάθε πλευρά της ζωής. Ένα ακόμη μεγάλο ευχαριστώ στην Αθανασία για την υπομονή που έδειξε και την ζωντάνια που με γεμίζει. Τέλος, θα ήθελα να ευχαριστήσω του γονείς μου, Ανδρέα και Χριστίνα, καθώς και όλη μου την οικογένεια για την αμέριστη στήριξη και αγάπη που μου χαρίζουν απλόχερα.

6

7 Περίληψη Οι πάροχοι υπηρεσιών νέφους υπολογιστών αποθηκεύουν για τους χρήστες και τις εφαρμογές τους όλο και αυξανόμενο μέγεθος δεδομένων. Αυτά τα δεδομένα μπορεί να είναι πολυδιάστατα, δεδομένα τοποθεσιών και άλλα που πιθανών να ακολουθούν άγνωστες κατανομές. Οι εφαρμογές που χρησιμοποιούν αυτά τα δεδομένα, και τα αποθηκεύουν σε κατανεμημένες NoSQL βάσεις δεδομένων, πρέπει να έχουν κάποιο τύπο δεικτοδότησης τόσο σε επίπεδο υπολογιστικού κόμβου αλλά και σε επίπεδο αρχιτεκτονικής για την δεικτοδότηση των ίδιων των υπολογιστικών κόμβων. Σε συνδυασμό αυτά πρέπει να επιτυγχάνουν εξισορρόπηση φόρτου (load balancing) ώστε τα ερωτήματα εύρους μεγάλης κλίμακας (Large- Scale Range Queries), τα οποία εκτελούνται να έχουν καλή απόδοση. Στην παρούσα εργασία παρουσιάζονται οι αρχιτεκτονικές των ευρετηρίων ΗΒ+-tree για δεικτοδότηση πολυδιάστατων δεδομένων και NSM-tree για δεικτοδότηση δεδομένων τοποθεσιών και εκτέλεση ερωτημάτων εύρους σε αυτές. Το HB+-tree (HBase B+-tree) είναι ένα βασισμένο στο Hadoop (κατανεμημένο σύστημα) κατανεμημένο Β+-δέντρο το οποίο ορίζει ένα ευρετήριο στους υπολογιστικούς κόμβους της HBase (κατανεμημένη βάση δεδομένων). Στην συνέχεια παρουσιάζεται μια πειραματική αξιολόγηση για την εκτέλεση ερωτημάτων δύο βασικών ειδών κατανεμημένων βάσεων και πως το HB+-δέντρο μπορεί να επηρεάσει θετικά στην απόδοση κατά την εκτέλεση ερωτημάτων στη μια από αυτές. Η μία βάση είναι η στήλοπροσανατολισμένη HBase και η άλλη είναι η βάση δεδομένων για γράφους Neo4j. Επίσης, με τα αποτελέσματα της συγκεκριμένης σύγκρισης προκύπτουν λύσεις σε προβλήματα εξισορρόπησης φόρτου στην εκτέλεση ερωτημάτων όταν μπορεί να εφαρμοστεί ο μηχανισμός προώθησης ερωτημάτων στην ανάλογη βάση δεδομένων. Τέλος, παρουσιάζεται με χρήση της αλγοριθμικής τεχνικής «μπάλες σε κάδους» ένας σχεδιασμός ευρετηρίου για την βέλτιστη εξισορρόπηση φόρτου κλειδιών στους διατεθειμένους υπολογιστικούς πόρους. Η επίτευξη βέλτιστου load balancing στα κλειδιά και κατά συνέπεια και στον όγκο των δεδομένων αποτελεί το «θεμέλιο» δημιουργίας ενός αποδοτικού κατανεμημένου ευρετηρίου (Distributed Overlay or Infrastructure) με τη χρήση του οποίου θα επιτυγχάνεται η βέλτιστη εκτέλεση ερωτημάτων εύρους. Το Overlay αυτό ονομάζεται HB 3 -tree (HBase Balls in Bins tree). Η εργασία υποστηρίζεται από τις ακόλουθες δημοσιεύσεις: 1. Kaplanis A., Kendea M., Sioutas S., Makris C., and Tzimas G HB+tree: use hadoop and HBase even your data isn't that big. In Proceedings of the 30th Annual ACM Symposium on Applied Computing (SAC '15). ACM, DOI: 2. Kendea M., Gkantouna V., Rapti A., Sioutas S., Tzimas G., Dimitrios Tsolis Graph DBs VS. Column-Oriented Stores: A Pure Performance Comparison, Algocloud 2015, Algorithmic Aspects of Cloud Computing, Volume 9511 of the series Lecture Notes in Computer Science pp Kokotinis I., Kendea M., Nodarakis N., Rapti A., Sioutas S., Tsakalidis A., Tsolis D., and Panagis Y NSM-Tree: Efficient Indexing on Top of NoSQL Databases, Algocloud 2016

8 Λέξεις Κλειδιά Εξισορρόπηση φόρτου, Ευρετήρια, Κατανεμημένα Συστήματα, NoSql Βάσεις Δεδομένων, Hadoop, HBase, MapReduce, HB+-tree, NSM-Tree, HB 3 +-tree, Δομές Δεδομένων, Ερωτήματα Εύρους.

9 Abstract Cloud providers store on databases for their users an increasing large amount of data. These data are most of the time multi-dimensional, location data and other that probably have a nonuniform distribution. Applications that use this data, and store them in distributed NoSQL databases, must have some type of indexing both inside cluster nodes but also at the level of indexing the set of cluster nodes. All these come together and result to have load balancing on data resulting the Large-Scale Range Queries performance to be optimal. The context of this thesis includes the architecture of ΗΒ+-tree overlay and index that index multidimensional data and also includes the NSM-tree indexing of location data. The experimental evaluation is presented. The HB+-tree (HBase B+-tree) is a Hadoop-based (distributed middleware) distributed B+-tree, which index HBase nodes. Next, an experimental evaluation for benchmarking the queries execution times on two distributed NoSql Databases and how the HB+-tree overlay and index can affect the performance of those queries. The first one is the column-oriented HBase and the other is the graph database Neo4j. Τhe results of this comparison can give solutions for load balancing problems in cases of executing queries when the query forwarding mechanism can be applied. At the end, a new novel indexing on both compute nodes and data is presented. The method uses the algorithmic technic «balls in bins» an architecture solution for optimal load balancing the keys inside the resources. Achieving optimal load balancing on keys and thus to the volume of data will be the "foundation" of creating an efficient distributed index (Distributed Overlay or Infrastructure). The Overlay is called HB 3 - tree (HBase Balls in Bins - tree) that will achieve optimal performance on range queries. Different parts of this thesis are published in the following papers: 1. Kaplanis A., Kendea M., Sioutas S., Makris C., and Tzimas G HB+tree: use hadoop and HBase even your data isn't that big. In Proceedings of the 30th Annual ACM Symposium on Applied Computing (SAC '15). ACM, DOI: 2. Kendea M., Gkantouna V., Rapti A., Sioutas S., Tzimas G., Dimitrios Tsolis Graph DBs VS. Column-Oriented Stores: A Pure Performance Comparison, Algocloud 2015, Algorithmic Aspects of Cloud Computing, Volume 9511 of the series Lecture Notes in Computer Science pp Kokotinis I., Kendea M., Nodarakis N., Rapti A., Sioutas S., Tsakalidis A., Tsolis D., and Panagis Y NSM-Tree: Efficient Indexing on Top of NoSQL Databases, Algocloud 2016

10 Keywords Load Balancing, Indexing Methods, Distributed Systems, NoSql Databases, Hadoop, HBase, MapReduce, HB+-tree, NSM-Tree, HB 3 +-tree, Data Structures, Range Queries

11 Πίνακας περιεχομένων 1 Big Data και Cloud Computing Big Data Cloud Computing Εισαγωγή Τι είναι και τι δεν είναι νέφος υπολογιστών Τα νέφη υπολογιστών σήμερα Σημαντικότητα Cloud Computing Αρχιτεκτονική Cloud Γενικά χαρακτηριστικά Επίπεδα Υπηρεσιών Apache Hadoop Κατανεμημένο υπολογιστικό σύστημα Χαρακτηριστικά Apache Hadoop Hadoop Distributed File System - HDFS Αρχιτεκτονική του HDFS Χαρακτηριστικά και Εργαλεία του HDFS MapReduce Παράδειγμα MapReduce Αρχιτεκτονική του MapReduce Χαρακτηριστικά και Εργαλεία του MapReduce Άλλες πληροφορίες NoSQL Βάσεις Δεδομένων Γενικά Κατανεμημένων Βάσεων Δεδομένων Ιδιότητες ACID Μοντέλα Συνέπειας Θεώρημα CAP Είδη NoSQL βάσεων δεδομένων HBase (Column-Oriented DB) Αρχιτεκτονική της HBase... 30

12 3.2.2 Μοντέλο δεδομένων Client API Διεπαφή για προγραμματιστή Βασικά χαρακτηριστικά HBase Άλλες λειτουργίες και εργαλεία Neo4j (Graph DB) Γενικά Βάσεων Δεδομένων για Γράφους Εισαγωγή στο Neo4j Σύγκριση Graph βάσης με Key-Value store Μοντέλο δεδομένων Neo4j Αρχιτεκτονική Neo4j Αρχιτεκτονική και λειτουργία Neo4j HA Βασικά χαρακτηριστικά του Neo4j Cypher γλώσσα ερωτημάτων Λειτουργίες και εργαλεία Load Balancing και Ευρετήρια Load Balancing (Εξισορρόπηση φόρτου) Query Load Balancing Ευρετήρια Βάσεων Δεδομένων Κατανεμημένο υπολογιστικό σύστημα και ευρετήρια HB+ tree Ευρετήριο HB+ tree Αρχιτεκτονική Σχεδίαση ΗΒ+-tree Εξισορρώπηση φόρτου δεδομένων και ερωτήματα εύρους NSM-Tree Ευρετήριο NSM-Tree Αρχιτεκτονική Σχεδίαση NSM-tree Εξισορρόπηση φόρτου δεδομένων και ερωτήματα εύρους Πειραματική Σύγκριση HBase και Neo4j Προετοιμασία Πειραμάτων Συλλογή δεδομένων Προεπεξεργασία δεδομένων Κατασκευή πινάκων στην HBase... 66

13 5.1.4 HBase Schema Αποθηκευτικός Χώρος Neo4j Schema Δημιουργία και εκτέλεση ερωτημάτων Ερωτήματα και Αποτελέσματα Πειραμάτων Ανάλυση Ερωτημάτων Ανάλυση Αποτελεσμάτων Επέκταση Τεχνικών Load Balancing Γενική Ιδέα Balls in Bins Game Εφαρμογή σε Κατανεμημένες ΒΔ Βιβλιογραφία Παράρτημα Εγκατάστασης Hadoop, HBase, Neo4j Εγκατάσταση Apache Hadoop Εγκατάσταση Apache HBase Εγκατάσταση Neo4j HA cluster... 94

14 Πίνακας σχημάτων Σχήμα 1.1 Κατηγορίες Cloud σε σχέση με τις υποδομές... 4 Σχήμα 1.2 Πως συνδέονται οι χρήστες στο Cloud Σχήμα 1.3 Η αρχιτεκτονική πίσω από ένα cloud computing σύστημα... 7 Σχήμα 1.4 Κατηγορίες υπηρεσιών από γνωστές εταιρίες Σχήμα 2.1 Υποδομή cluster Σχήμα 2.2 Δομικά στοιχεία του Apache Hadoop Σχήμα 2.3 Αρχιτεκτονική HDFS και ροή πληροφορίας Σχήμα 2.4: Διαχωρισμός εισόδου σε blocks Σχήμα 2.5 Replication blocks στους κόμβους Σχήμα 2.6 Αρχιτεκτονική MapReduce Σχήμα 2.7 Διαδικασία MapReduce Σχήμα 2.8 Διάγραμμα παραδείγματος MapReduce για WordCount Σχήμα 2.9 Αρχιτεκτονική και ροή πληροφορίας MapReduce (M=3, R=2) Σχήμα 3.1 Το τρίγωνο CAP με παραδείγματα συστημάτων Σχήμα 3.2 Η αρχιτεκτονική της HBase και ο τρόπος σύνδεσης με το HDFS Σχήμα 3.3 Ιεραρχία αρχείων region ενός πίνακα Σχήμα 3.4 Παράδειγμα γραμμής ενός πίνακα στην HBase Σχήμα 3.5 Κατηγοριοποίηση συστημάτων Graph Databases Σχήμα 3.6 Αντιστοίχιση από Key-Value Store (αριστερά) σε γράφο (δεξιά) Σχήμα 3.7 Αρχιτεκτονική Neo4j Σχήμα 3.8 Δομή και ροή πληροφορίας σε ένα Neo4j HA cluster Σχήμα 4.1 Lazy B-tree Σχήμα 4.2 Αρχιτεκτονική HB+-tree Σχήμα 4.3 Γραμμή αποθήκευσης κόμβου του HB+-tree Σχήμα 4.4 Χρονοι Κατασκευής Ευρετηρίου και Υπολογισμού Ερωτημάτων Εύρους HB+-tree.. 58 Σχήμα 4.5 Αντικείμενο δρομολόγησης Or με ακτίνα r(or) και υπο-δέντρο T(Or) Σχήμα 4.6 Γραμμή αποθήκευσης κόμβου του NSM-tree Σχήμα 4.7 Αναζήτηση ενός αντικειμένου με διαφορετικές ακτίνες Σχήμα 4.8 Αναζήτηση 1000 αντικειμένων με ίδια ακτίνα Σχήμα 4.9 Αναζήτηση ενός αντικειμένου με 1000 διαφορετικές ακτίνες Σχήμα 5.1 Αποθηκευτικός Χώρος Υλοποιήσεων Σχήμα 5.2 Μέρος του Neo4j γράφου Σχήμα 5.3 Αποτελέσματα Πειραμάτων Σύγκρισης Ερωτημάτων Σχήμα 6.1 Balls in Bins κατανομές Σχήμα 6.2 Αρχιτεκτονική ΗΒ 3 +tree... 82

15 Big Data και Cloud Computing Κεφάλαιο 1 1 Big Data και Cloud Computing Σε έναν κόσμο που βλέπει τις νέες τεχνολογικές τάσεις να ανθούν και να εξασθενούν σχεδόν σε καθημερινή βάση, μία πολύ πρόσφατη τάση έχει αποδείξει ότι θα έχει πολύ μεγάλη διάρκεια ζωής. Η τάση αυτή ονομάζεται cloud computing, και έχει έρθει για αλλάξει τον τρόπο που χρησιμοποιούμαι τον υπολογιστή και το διαδίκτυο. Ένας άλλος όρος που έχει μπει για τα καλά στην ζωή μας είναι ο όρος bid data (μεγάλα δεδομένα). Κάθε λεπτό δημιουργούνται στον πλανήτη 1,7 δισεκατομμύρια bytes δεδομένων, που ισοδυναμούν σε περισσότερα από 6 megabytes δεδομένων για κάθε άτομο ανά ημέρα και ο ρυθμός αυτός αυξάνεται κατά 40% ανά έτος. Εκτιμάται πως το σύνολο των δεδομένων που υπάρχουν σε όλο τον κόσμο ξεπερνά τα 1,8 zettabytes, όπου ένα zettabyte ισούται με bytes, με τον ρυθμό δημιουργίας δεδομένων να αυξάνεται εκθετικά. 1.1 Big Data Τα Big Data είναι ένας όρος που περιγράφει το μεγάλο όγκο των δεδομένων, τόσο δομημένων όσο και αδόμητων, που κατακλύζει μια επιχείρηση σε μια ημέρα με την ημέρα. Αλλά δεν είναι η ποσότητα των δεδομένων που είναι το σημαντικό. Το σημαντικό και αυτό που έχει σημασία είναι το πώς χρησιμοποιεί και τι κάνει ένας οργανισμός με αυτά τα δεδομένα. Τα μεγάλα δεδομένα μπορούν να αναλυθούν και να οδηγήσουν σε καλύτερες αποφάσεις και στρατηγικές επιχειρηματικές κινήσεις. Ενώ ο όρος «μεγάλα δεδομένα» είναι σχετικά νέος, η πράξη της συλλογής και της αποθήκευσης μεγάλων ποσοτήτων πληροφοριών για την ενδεχόμενη ανάλυση είναι χρησιμοποιείται από παλιά. Η έννοια επιταχύνθηκε στις αρχές της δεκαετίας του 2000, όταν ο αναλυτής βιομηχανίας Doug Laney θεμελίωσε στην ενσωμάτωση του ορισμού των μεγάλων δεδομένων τα 3 V. Volume, Variety, Velocity. Ο μεγάλος όγκος (Volume) δεδομένων χαρακτηρίζει πολλές μοντέρνες εφαρμογές με τα δεδομένα να έρχονται σε διάφορες μορφές (Variety) όπως σχεσιακά δεδομένα, εικόνα, ήχος, video. Τέλος, η παραγωγή των δεδομένων μπορεί να γίνεται με εκθετικά αυξανόμενους ρυθμούς και η εξαγωγή συμπερασμάτων να πρέπει να γίνει σε πραγματικό χρόνο (Velocity) 1

16 Big Data και Cloud Computing Η σπουδαιότητα των Big Data Η σημασία των μεγάλων δεδομένων δεν περιστρέφεται μόνο γύρω από τον όγκο των δεδομένων που μπορεί να έχουμε, αλλά τι κάνουμε με αυτά. Μπορούμε να πάρουμε τα δεδομένα από οποιαδήποτε πηγή και να τα αναλύσουμε για να βρούμε τις απαντήσεις που επιτρέπουν α) τη μείωση του κόστους, β) μείωση του χρόνου, γ) την ανάπτυξη νέων προϊόντων και βελτιστοποιημένες προσφορές, και 4) τη λήψη έξυπνων αποφάσεων. Όταν συνδυαστούν τα μεγάλα δεδομένων με μεγάλης ισχύος Analytics, μπορούν να ολοκληρωθούν εργασίες που αφορούν τις επιχειρήσεις, όπως: Καθορισμός βασικών αιτίων των αποτυχιών, θέματα και ελαττώματα σε σχεδόν πραγματικό χρόνο. Παραγωγή κουπονιών σε σημεία πώλησης με βάση αγοραστικές συνήθειες του πελάτη. Τον εκ νέου υπολογισμό ολόκληρου του χαρτοφυλακίου των κινδύνων μέσα σε λίγα λεπτά. Ανίχνευση δόλιας συμπεριφοράς πριν επηρεάσει κάποιον οργανισμό. 1.2 Cloud Computing Εισαγωγή Ο όρος cloud computing είναι μια σχετικά πρόσφατη έννοια, κερδίζει εξέχουσα θέση το 2007, ως μέσο περιγραφής που βασίζεται στο Internet κατανεμημένων υπολογιστών και των συναφών εφαρμογών του. Με την ανάπτυξη του διαδικτύου, δεν υπήρχε ανάγκη να περιοριστεί η συνεργασία σε μια ομάδα σε ένα ενιαίο δίκτυο μίας επιχείρησης. Οι χρήστες από πολλαπλές τοποθεσίες εντός μιας εταιρείας, καθώς και από πολλούς οργανισμούς, είναι επιθυμητό να συνεργάζονται σε έργα που ξεπερνούν τα γεωγραφικά και μη όρια της εταιρείας. Για να γίνει αυτό, τα έργα πρέπει να στεγάζονται στο «σύννεφο» του διαδικτύου, και να είναι προσβάσιμα από οποιοδήποτε internet θέση. Το cloud computing έφερε μαζί του μια μεγάλη αλλαγή στον τρόπο που αποθηκεύονται πληροφορίες και να τρέχουν εφαρμογές. Αντί να εκτελούνται προγράμματα σε έναν ατομικό υπολογιστή desktop που περιέχει και τα δεδομένα, τα πάντα φιλοξενούνται στο «σύννεφο», μια νεφελώδεις συνάθροιση από υπολογιστές και servers που είναι προσβάσιμοι μέσω του διαδικτύου. Σε ένα νέφος υπολογιστών επιτρέπει να έχουμε πρόσβαση σε όλες τις εφαρμογές και τα έγγραφά μας από οπουδήποτε στον κόσμο, απελευθερώνοντας μας από την όρια της επιφάνειας εργασίας και καθιστώντας ευκολότερο για τα μέλη μιας ομάδας σε διαφορετικές τοποθεσίες για να συνεργαστούν. 2

17 Big Data και Cloud Computing Η εμφάνιση του cloud computing είναι το ισοδύναμο στην τεχνολογία υπολογιστών όσο η επανάσταση στον τομέα της ηλεκτρικής ενέργειας πριν από έναν αιώνα. Πριν από την έλευση του ηλεκτρικού ρεύματος από τις επιχειρήσεις κοινής ωφέλειας, όσοι ασχολούνταν με τις γεωργικές εκμεταλλεύσεις και τις επιχειρήσεις παρήγαγαν την δική τους ηλεκτρική ενέργεια από ανεξάρτητες γεννήτριες. Μετά από την δημιουργία του ηλεκτρικού δικτύου, αγροκτήματα και επιχειρήσεις έκλεισαν τις γεννήτριες και αγόρασαν ηλεκτρική ενέργεια από τις επιχειρήσεις κοινής ωφελείας, σε πολύ χαμηλότερη τιμή (και με πολύ μεγαλύτερη αξιοπιστία) από ό, τι θα μπορούσαν να παράγουν μόνοι τους. Κατά παρόμοιο τρόπο η ίδια επανάσταση έχει συμβεί με το cloud computing. Η επιτραπέζιο-κεντρική αντίληψη των υπολογιστών που έχουμε συνηθίσει μέχρι σήμερα είναι υποχρεωμένη να αλλάξει αφού πλέον αναμένουμε να έχουμε καθολική πρόσβαση, 24/7, αξιοπιστία, και πολλαπλή συνεργασία όπως υποσχέθηκε το cloud computing. Είναι το παρόν και το μέλλον Τι είναι και τι δεν είναι νέφος υπολογιστών Με τον παραδοσιακό υπολογιστή desktop, μπορούμε να εκτελέσουμε αντίγραφα των προγραμμάτων λογισμικού σε κάθε υπολογιστή που διαθέτουμε. Τα έγγραφα που δημιουργούμε αποθηκεύονται στον υπολογιστή για τον οποία δημιουργήθηκαν. Παρά το γεγονός ότι τα έγγραφα μπορούν να προσπελαστούν από άλλους υπολογιστές στο δίκτυο, δεν μπορούν να είναι προσβάσιμα από υπολογιστές που βρίσκονται εκτός του δικτύου. Αυτό είναι η επιτραπέζιο-κεντρική αντίληψη. Με το cloud computing, τα προγράμματα λογισμικού που χρησιμοποιούνται δεν τρέχουν από τον προσωπικό υπολογιστή, αλλά είναι αποθηκευμένα σε διακομιστές που είναι προσβάσιμοι μέσω του διαδικτύου. Εάν ο υπολογιστής κολλάει, το λογισμικό εξακολουθεί να είναι διαθέσιμο για χρήση από άλλους. Το ίδιο ισχύει και για τα έγγραφα που δημιουργούνται καθώς είναι αποθηκευμένα σε μια συλλογή από servers που είναι προσβάσιμοι μέσω διαδικτύου. Ο οποιοσδήποτε έχει άδεια χρήσης μπορεί να έχει πρόσβαση στα έγγραφα, αλλά μπορεί επίσης να τα επεξεργαστεί και να συνεργαστεί επί των εγγράφων αυτών σε πραγματικό χρόνο. Φυσικά αυτό είναι μια απλούστευση. Ας δούμε με περισσότερες λεπτομέρειες στο τι είναι ή όχι το cloud computing. Ένα νέφος υπολογιστών δεν είναι δίκτυο υπολογιστών. Με το δίκτυο υπολογιστών, εφαρμογές και έγγραφα που φιλοξενούνται στον server μιας και μοναδικής εταιρίας και η πρόσβαση υπάρχει μέσω του δικτύου της εταιρείας. Το cloud computing είναι κάτι πολύ μεγαλύτερο από αυτό. Μπορεί να περιλαμβάνει πολλαπλές εταιρίες, πολλούς διακομιστές και πολλαπλά δίκτυα. Επιπλέον, σε αντίθεση με τα δίκτυα υπολογιστών, οι cloud υπηρεσίες αποθήκευσης είναι προσβάσιμες από οπουδήποτε στον κόσμο μέσω μιας σύνδεσης στο Internet ενώ με δίκτυο υπολογιστών η πρόσβαση υπάρχει μόνο μέσω του δικτύου της εταιρείας και μόνο. Το cloud 3

18 Big Data και Cloud Computing computing δεν είναι παραδοσιακό outsourcing, δηλαδή, όταν μια εταιρεία δίνει υπεργολαβία τις υπηρεσίες πληροφορικής της σε μια εξωτερική εταιρεία. Ενώ η εξωτερική επιχείρηση ανάθεσης μπορεί να φιλοξενήσει δεδομένα και εφαρμογές της εταιρείας, τα εν λόγω έγγραφα και τα προγράμματα είναι προσβάσιμα μόνο στους υπαλλήλους της εταιρείας, μέσω του δικτύου της εταιρείας, αλλά όχι σε όλο τον κόσμο μέσω του διαδικτύου. Έτσι, παρά τις επιφανειακές ομοιότητες, η δικτύωση υπολογιστών και το outsourcing δεν είναι cloud computing. Το κλειδί για τον ορισμό του cloud computing είναι το «σύννεφο» το ίδιο [17]. Για τους σκοπούς μας, το σύννεφο είναι μια μεγάλη ομάδα διασυνδεδεμένων υπολογιστών. Οι υπολογιστές μπορούν να είναι προσωπικοί υπολογιστές ή διακομιστές δικτύου που μπορούν να είναι δημόσιοι ή ιδιωτικοί. Έτσι προκύπτει ανάγκη για κατηγοριοποίηση των υπηρεσιών cloud ανάλογα με τις υποδομές που χρησιμοποιούνται. Συγκεκριμένα εντοπίζονται τρία είδη cloud computing, το public cloud, το private cloud και ο συνδυασμός των δύο, το hydrid cloud. Σχήμα 1.1 Κατηγορίες Cloud σε σχέση με τις υποδομές Δημόσιο cloud (public) Tο δημόσιο cloud αποτελείται από ένα σύνολο μηχανημάτων και υποδομής δικτύου, και χρησιμοποιείται για την παροχή υπολογιστικών πόρων και υπηρεσιών στο ευρύ κοινό αποκλειστικά μέσω μιας σύνδεσης στο Internet. Οι υπηρεσίες παρέχονται είτε με χρέωση είτε χωρίς όπως τους πανεπιστημιακούς παρόχους. Ιδιωτικό cloud (private) Πρόκειται στην ουσία για ένα cloud, το οποίο δημιουργείται για ένα συγκεκριμένο αριθμό χρηστών εντός της εκάστοτε επιχείρησης ή οργανισμού και περιορίζει την πρόσβαση σε αυτή την ομάδα χρηστών και μόνο. Η υποδομή μπορεί να βρίσκεται οπουδήποτε και το βάρος της ασφάλειας και την αξιοπιστίας πέφτει στον πάροχο. 4

19 Big Data και Cloud Computing Υβριδικό cloud (hybrid) Πρόκειται για ένα συνδυασμό του δημόσιου και ιδιωτικού. Σε ένα μοντέλο hybrid cloud για παράδειγμα, οι εργαζόμενοι μίας επιχείρησης έχουν πρόσβαση τόσο στο «εσωτερικό» (private) cloud της εταιρείας, όσο και στο δημόσιο (public), με το τελευταίο να είναι προσβάσιμο από πελάτες, συνεργάτες και προμηθευτές. Γενικά συνδυάζει τα πλεονεκτήματα των άλλων τύπων και έχει ανοχή σε σφάλματα (fault-tolerant). Για παράδειγμα, η Google φιλοξενεί ένα σύννεφο που αποτελείται από μικρούς προσωπικούς υπολογιστές και μεγαλύτερους servers. Το νέφος της Google είναι ένα ιδιωτικό (δηλαδή το κατέχει η Google), που είναι δημόσια προσβάσιμο στο κοινό (από χρήστες της Google). Αυτό το σύννεφο υπολογιστών επεκτείνεται πέρα από μια και μόνο εταιρεία ή επιχείρηση. Οι εφαρμογές και τα δεδομένα που προσφέρονται και εξυπηρετούνται από το σύννεφο είναι διαθέσιμες σε ευρύτερη ομάδα χρηστών, διεπιχειρησιακό (cross - enterprise) και ανάμεσα σε πολλαπλές πλατφόρμες (cross-platform). Η πρόσβαση γίνεται μέσω του διαδικτύου. Κάθε εξουσιοδοτημένος χρήστης μπορεί να έχει πρόσβαση σε αυτά τα αρχεία και εφαρμογές από οποιονδήποτε υπολογιστή πάνω από οποιαδήποτε σύνδεση στο Internet. Για το χρήστη, η τεχνολογία και οι υποδομές πίσω από το σύννεφο είναι αόρατες. Δεν είναι εμφανής (και στις περισσότερες περιπτώσεις, δεν έχει σημασία) εάν οι υπηρεσίες cloud βασίζονται σε HTTP, HTML, XML, JavaScript, ή άλλες ειδικές τεχνολογίες. Με λίγα λόγια, το cloud computing κάνει μια μετατόπιση από τον υπολογιστή στον χρήστη, από τις εφαρμογές στα καθήκοντα, καθώς και από μεμονωμένα δεδομένα σε δεδομένα που μπορούν να προσπελαστούν από οπουδήποτε και να μοιράζονται σε όλους. Αυτό που πλέον έχει σημασία για τον χρήστη είναι ότι πλέον τα δεδομένα είναι στο νέφος και πλέον άμεσα προσβάσιμα από όποιον έχει άδεια πρόσβασης Τα νέφη υπολογιστών σήμερα Είμαστε σήμερα στην επανάσταση του cloud computing. Παρά το γεγονός ότι πολλές υπηρεσίες cloud είναι διαθέσιμες σήμερα, όλο και περισσότερες ενδιαφέρουσες εφαρμογές είναι ακόμα σε εξέλιξη. Το cloud computing σήμερα προσελκύει τις καλύτερες και μεγαλύτερες εταιρείες από όλη τη βιομηχανία υπολογιστών, οι οποίες ελπίζουν να δημιουργήσουν κερδοφόρα επιχειρηματικά μοντέλα που βασίζονται στο cloud. Ίσως το πιο αξιοσημείωτο παράδειγμα σήμερα εταιρείας που αγκαλιάζει το μοντέλο του cloud computing είναι το Google. Η Google προσφέρει μια ισχυρή συλλογή από web-based εφαρμογές, όπου όλες εξυπηρετούνται μέσω της cloud αρχιτεκτονική της. Προσφέρει υπηρεσίες cloud-based επεξεργασίας κειμένου (Google Docs), λογισμικό παρουσίασης (Google presentation), ηλεκτρονικού ταχυδρομείου (Gmail), ημερολόγιου (Google Calendar). Και το καλύτερο από όλα, η Google είναι έμπειρη να πάρει όλες τις web-based εφαρμογές της και να τις διασυνδέσει με άλλες. Οι υπηρεσίες cloud τους διασυνδέονται προς όφελος του χρήστη. Άλλες μεγάλες εταιρείες συμμετέχουν επίσης στην ανάπτυξη των υπηρεσιών cloud. Η Microsoft, για παράδειγμα, προσφέρει το SkyDrive καθώς και η Apple μέσα από το icloud προσφέρει πολλές υπηρεσίες. Η Amazon έχει το Elastic Compute 5

20 Big Data και Cloud Computing Cloud της (EC2) [3], μια διαδικτυακή υπηρεσία που προσφέρει cloud-based δυνατότητα αλλαγής μεγέθους υπολογιστικής ικανότητας για προγραμματιστές εφαρμογών. Η IBM έχει δημιουργήσει ένα «Κέντρο Cloud Computing» για την παροχή υπηρεσιών cloud και την έρευνα για τους πελάτες της. Και πολλές μικρότερες επιχειρήσεις έχουν ξεκινήσει τις δικές τους webbased εφαρμογές τους, κυρίως (αλλά όχι αποκλειστικά) για να εκμεταλλευτούν τη συνεργατική φύση των υπηρεσιών cloud. Στην Ελλάδα το Εθνικό Δίκτυο Έρευνας & Τεχνολογίας προσφέρει το υπολογιστικό νέφος της εκπαίδευσης (Okeanos Cloud Computing Service και Pithos online Storage Service) τις οποίες παρέχει σε όλα τα μέλη της εκπαιδευτικής και ερευνητικής κοινότητας, με προηγμένα και περιβαλλοντικά φιλικά υπολογιστικά κέντρα Σημαντικότητα Cloud Computing Γιατί είναι σημαντικό το cloud computing; Υπάρχουν πολλές επιπτώσεις της τεχνολογίας cloud, τόσο για τους προγραμματιστές όσο και για τους τελικούς χρήστες. Για τους προγραμματιστές, το cloud computing παρέχει αυξημένες ποσότητες χώρου αποθήκευσης και υπολογιστικής δύναμης για να τρέχουν τις εφαρμογές που αναπτύσσουν. Το Cloud computing δίνει επίσης νέους τρόπους για να έχουν πρόσβαση σε πληροφορίες, τη διαδικασία και ανάλυση των δεδομένων, καθώς και τη σύνδεση ανθρώπων και πόρων από οποιαδήποτε θέση σε όλο τον κόσμο. Με το cloud computing, οι προγραμματιστές δεν είναι πλέον εγκλωβισμένοι από φυσικά εμπόδια. Για τους τελικούς χρήστες, το cloud computing προσφέρει όλα αυτά τα οφέλη και περισσότερο. Ένα άτομο που χρησιμοποιεί μια web-based εφαρμογή δεν είναι συνδεδεμένο φυσικά με έναν υπολογιστή, τη θέση, ή το δίκτυο. Οι εφαρμογές και τα έγγραφα του είναι προσβάσιμα από όπου κι αν βρίσκεται, όποτε θέλει. Επιπλέον εξαφανίζεται ο φόβος της απώλειας δεδομένων εάν ένας υπολογιστής χαλάσει. Τα έγγραφα που φιλοξενούνται στο σύννεφο υπάρχουν πάντα, χωρίς να έχει σημασία τι θα συμβεί στο μηχάνημα του χρήστη. Και έπειτα υπάρχει το όφελος της συνεργασίας της ομάδας. Οι χρήστες από όλο τον κόσμο μπορούν να συνεργάζονται για τα ίδια έγγραφα, εφαρμογές και προγράμματα, σε πραγματικό χρόνο. Το cloud computing τα κάνει όλα αυτά με χαμηλότερο κόστος, επειδή το σύννεφο επιτρέπει την αποδοτικότερη κατανομή των πόρων από το παραδοσιακό δίκτυο υπολογιστών. Με το cloud computing, το υλικό δεν πρέπει να είναι σωματικά δίπλα στο γραφείο της επιχείρησης ή του κέντρου δεδομένων. Υποδομές Cloud μπορούν να βρίσκονται οπουδήποτε, και κυρίως προτιμούνται οι περιοχές με χαμηλότερο κόστος ακινήτων και ηλεκτρικής ενέργειας. Επιπλέον, τα IT τμήματα δεν χρειάζεται να εξυπηρετούν τον μέγιστο φόρτο, επειδή το επιπλέον φορτίο μπορεί να εξαπλωθεί έξω από τα στοιχεία ενεργητικού του νέφους. Και, επειδή οι πρόσθετοι πόροι cloud είναι πάντα σε ετοιμότητα, οι εταιρείες δεν χρειάζεται πλέον να αγοράσουν περιουσιακά στοιχεία για τις σπάνιες εντατικές υπολογιστικές εργασίες. Εάν χρειάζεται περισσότερη επεξεργαστική ισχύ, είναι πάντα εκεί στο σύννεφο και η πρόσβαση σε μια οικονομικά αποδοτική λύση. 6

21 1.2.5 Αρχιτεκτονική Cloud Big Data και Cloud Computing Cloud Servers Σχήμα 1.2 Πως συνδέονται οι χρήστες στο Cloud. Όπως φαίνεται και στο σχήμα 1.2, ανεξάρτητοι χρήστες συνδέονται στο Cloud από τον προσωπικό τους υπολογιστή ή φορητή συσκευή μέσω του Internet. Σε όλους αυτούς τους ξεχωριστούς χρήστες, το νέφος φαίνεται σαν μια απλή εφαρμογή, ένα αρχείο ή μία συσκευή. Το υλικό στο cloud και το λειτουργικό σύστημα που διαχειρίζεται την σύνδεση μεταξύ των διαφόρων συσκευών του cloud είναι αόρατο προς τον χρήστη. Αυτή η αρχιτεκτονική cloud είναι απατηλά απλή, στην πραγματικότητα απαιτείται κάποια έξυπνη διαχείριση για να συνδεθούν όλοι αυτοί οι ηλεκτρονικοί υπολογιστές καθώς και να ανατεθεί η διαχείριση του πλήθους των χρηστών. User Interface System Management Provisioning Services Cloud Servers Web Application Σχήμα 1.3 Η αρχιτεκτονική πίσω από ένα cloud computing σύστημα Όπως μπορούμε να δούμε στο σχήμα 1.3, όλα ξεκινούν με το περιβάλλον front-end που παρουσιάζεται στους μεμονωμένους χρήστες. Αυτός είναι ο τρόπος με τον οποίο οι χρήστες επιλέγουν μια εργασία ή υπηρεσία (είτε ξεκινώντας μια εφαρμογή ή το άνοιγμα ενός 7

22 Big Data και Cloud Computing εγγράφου). Το αίτημα του χρήστη, στη συνέχεια περνά από τη διαχείριση του συστήματος, η οποία βρίσκει τους σωστούς πόρους και στη συνέχεια καλεί κατάλληλες υπηρεσίες παροχής του συστήματος. Οι υπηρεσίες αυτές υποδεικνύουν τους αναγκαίους πόρους στο σύννεφο, ξεκινούν την κατάλληλη εφαρμογή web, και είτε δημιουργεί ή ανοίγει το έγγραφο που ζητήθηκε. Αφού η web εφαρμογή έχει ξεκινήσει, οι διαδικασίες παρακολούθησης και μέτρησης του συστήματος παρακολουθούν τη χρήση του cloud, έτσι ώστε οι πόροι να κατανέμονται και να αποδοθούν στους σωστούς χρήστες. Όπως φαίνεται, το κλειδί για την έννοια του cloud computing είναι η αυτοματοποίηση πολλών εργασιών διαχείρισης. Το σύστημα δεν είναι σύννεφο αν απαιτεί διαχείριση από ανθρώπους για να διαθέσει πόρους σε διαδικασίες. Για το σύστημα για να επιτευχθεί καθεστώς cloud, η διαχείριση θα πρέπει να υποκατασταθεί από αυτοματοποιημένες διαδικασίες Γενικά χαρακτηριστικά Ευελιξία Βελτιώνεται με τη δυνατότητα των χρηστών για την εκ νέου παροχή τεχνολογικών πόρων υποδομής. Διασύνδεση προγραμματισμού εφαρμογών (API) Πρόσβαση σε λογισμικό που επιτρέπει σε μηχανές να αλληλοεπιδρούν με το λογισμικό του cloud με τον ίδιο τρόπο που ένα παραδοσιακό περιβάλλον εργασίας χρήστη (π.χ. έναν επιτραπέζιο υπολογιστή) διευκολύνει την αλληλεπίδραση μεταξύ ανθρώπων και υπολογιστών. Τα Cloud computing συστήματα συνήθως χρησιμοποιούν «Αναπαραστάσεις Μεταφοράς Κατάστασης» (REST-based APIs). Κόστος Οι πάροχοι cloud ισχυρίζονται ότι μειώνουν το κόστος πληροφορικής. Το κόστος εξοικονόμησης εξαρτάται από το είδος των δραστηριοτήτων και το είδος των διαθέσιμων υποδομών. Ανεξαρτησία τοποθεσίας και συσκευής Επιτρέπει στους χρήστες την πρόσβαση σε συστήματα μέσω ενός web browser, ανεξάρτητα από τη θέση τους ή ποια συσκευή χρησιμοποιούν (π.χ. PC, κινητό τηλέφωνο). Αφού η υποδομή είναι off-site (συνήθως παρέχεται από τρίτους) και είναι προσβάσιμη μέσω του διαδικτύου, οι χρήστες μπορούν να συνδεθούν από οπουδήποτε. Τεχνολογία εικονικοποίησης (Virtualization) Επιτρέπει την κοινή χρήση των servers και συσκευών αποθήκευσης και την αύξηση της χρησιμοποίησης τους. Οι εφαρμογές μπορούν εύκολα να μεταφερθούν από ένα φυσικό server στον άλλο. Πολύ-ενοικίαση (Multitenancy) Επιτρέπει την κοινή χρήση των πόρων και των δαπανών σε μια μεγάλη ομάδα χρηστών επιτρέποντας έτσι: 8

23 Big Data και Cloud Computing Την συγκέντρωση των υποδομών σε περιοχές με χαμηλότερο κόστος (όπως η ακίνητη περιουσία, ηλεκτρισμός, κλπ.) Να αυξάνεται ο μέγιστος φόρτος της παραγωγικής ικανότητας Αξιοποίηση και βελτίωση της αποδοτικότητας για συστήματα που συχνά μόνο χρησιμοποιηθούν το 10-20%. Αξιοπιστία (Reliability) Βελτιώνεται με τη χρήση πολλαπλών αντιγράφων, γεγονός που καθιστά ένα καλά σχεδιασμένο cloud computing σύστημα να είναι κατάλληλο για την επιχειρησιακή συνέχεια και αποκατάσταση μετά από καταστροφή. Επεκτασιμότητα και ελαστικότητα (Scalability and elasticity) Mέσω δυναμικής (on-demand) τροφοδότησης με πόρους, με βάση self-service σε σχεδόν πραγματικό χρόνο, χωρίς οι χρήστες να χρειάζεται να κάνουν κάτι όταν θέλουν περισσότερους πόρους. Απόδοση (Performance) Παρακολουθούνται οι επιδόσεις. Οι συνεπείς και χαλαρά συνδεδεμένες αρχιτεκτονικές έχουν κατασκευαστεί χρησιμοποιώντας διαδικτυακές υπηρεσίες όπως και το περιβάλλον εργασίας του συστήματος. Ασφάλεια (Security) Μπορεί να βελτιωθεί χάρη στην συγκέντρωση των δεδομένων κλπ., αλλά οι ανησυχίες μπορεί να παραμείνουν για την απώλεια του ελέγχου επί ορισμένων ευαίσθητων δεδομένων, καθώς και η έλλειψη ασφάλειας σε αποθηκευμένους πυρήνες. Η ασφάλεια είναι συχνά το ίδιο καλή ή και καλύτερη από άλλα παραδοσιακά συστήματα, εν μέρει επειδή οι πάροχοι είναι σε θέση να διαθέσουν πόρους για την επίλυση των ζητημάτων της ασφάλειας όπου πολλοί πελάτες δεν μπορούν να αντιμετωπίσουν οικονομικά. Ωστόσο, η πολυπλοκότητα της ασφάλειας αυξάνεται σημαντικά όταν τα δεδομένα διανέμονται σε μια ευρύτερη περιοχή ή σε ένα μεγαλύτερο αριθμό των συσκευών. Ιδιωτικές εγκαταστάσεις cloud είναι εν μέρει ως κίνητρο για την επιθυμία των χρηστών να διατηρούν τον έλεγχο της υποδομής και να αποφευχθεί η απώλεια του ελέγχου της ασφάλειας των πληροφοριών. Συντήρηση (Maintenance) Οι εφαρμογές cloud computing μπορούν ευκολότερα να συντηρηθούν, επειδή δεν χρειάζεται να εγκατασταθούν στον υπολογιστή του κάθε χρήστη και μπορούν να προσπελαστούν από διαφορετικές θέσεις Επίπεδα Υπηρεσιών Αντίστοιχα με την κατηγοριοποίηση των υπηρεσιών cloud ανάλογα με τις υποδομές που χρησιμοποιούνται, υπάρχει και κατηγοριοποίηση ανάλογα με τον έλεγχο των χρηστών στους 9

24 Big Data και Cloud Computing υπολογιστικούς πόρους. Οι cloud computing πάροχοι προσφέρουν τις υπηρεσίες τους, σύμφωνα με αρκετά θεμελιώδεις μοντέλα: των υποδομών ως υπηρεσία (infrastructure as a service-iaas), την πλατφόρμα ως υπηρεσία (platform as a service-paas), και το λογισμικό ως υπηρεσία (software as a service-saas), όπου IaaS είναι η πιο βασική και κάθε υψηλότερο επίπεδο είναι αφαιρετικό από τα στοιχεία των πιο κάτω μοντέλων. Το 2012, το δίκτυο ως υπηρεσία (NaaS) και η επικοινωνία ως υπηρεσία (CaaS) είχαν συμπεριληφθεί επίσημα από την ITU (Διεθνής Ένωση Τηλεπικοινωνιών), στο πλαίσιο των βασικών μοντέλων cloud computing, και αναγνωρίζονται ως οι κατηγορίες υπηρεσιών του οικοσυστήματος cloud τηλεπικοινωνιών. SaaS PaaS IaaS Σχήμα 1.4 Κατηγορίες υπηρεσιών από γνωστές εταιρίες Υποδομές ως υπηρεσία (Infrastructure as a service-iaas) Στο πιο βασικό μοντέλο cloud υπηρεσιών, οι πάροχοι IaaS προσφέρουν φυσικές ή (πιο συχνά) εικονικές μηχανές και άλλους πόρους. Σύννεφα IaaS συχνά προσφέρουν πρόσθετους πόρους όπως μια βιβλιοθήκη εικονικών μηχανών δίσκων, raw (block) και file-based αποθήκευση, τείχους προστασίας, εξισορροπητές φόρτου, IP διευθύνσεις, εικονικά τοπικά δίκτυα (VLANs), και πακέτα λογισμικού. Τα IaaS σύννεφα παρέχουν αυτούς τους πόρους on-demand από τις μεγάλες πισίνες τους που είναι εγκατεστημένα σε κέντρα δεδομένων. Για ευρείας ζώνης σύνδεση, οι πελάτες μπορούν να χρησιμοποιήσουν είτε το Internet ή τα σύννεφα φορέων (αφιερωμένα εικονικά ιδιωτικά δίκτυα). Για να αναπτύξουν τις εφαρμογές τους, οι χρήστες του cloud εγκαθιστούν το λειτουργικό σύστημα και το λογισμικό των εφαρμογών τους στην υποδομή cloud. Σε αυτό το μοντέλο, ο χρήστης διατηρεί τα λειτουργικά συστήματα και τα λογισμικά εφαρμογών. Πάροχοι Cloud συνήθως τιμολογούν τις υπηρεσίες IaaS με βάση τη χρήση των υπολογιστών και το κόστος αντανακλά το ύψος των πόρων που διατίθενται και καταναλώνονται. 10

25 Big Data και Cloud Computing Πλατφόρμα ως υπηρεσία (Platform as a service-paas) Στο μοντέλο PaaS, οι πάροχοι cloud παραχωρούν μια υπολογιστική πλατφόρμα, συνήθως συμπεριλαμβανομένου του λειτουργικού συστήματος, το περιβάλλον εκτέλεσης της γλώσσας προγραμματισμού, βάσεις δεδομένων και web server. Οι προγραμματιστές εφαρμογών μπορούν να αναπτύξουν και να τρέξουν το λογισμικό τους σε μια πλατφόρμα cloud χωρίς το κόστος και την πολυπλοκότητα της αγοράς και τη διαχείριση του υλικού και του λογισμικού υποστρώματος. Με κάποιες προσφορές PaaS, η υπολογιστική δύναμη και ο χώρος αποθήκευσης κλιμακώνεται αυτόματα για να ταιριάζει με τη ζήτηση από την εφαρμογή έτσι ώστε ο χρήστης να μην χρειάζεται να επέμβει χειροκίνητα. Εφαρμογές ως υπηρεσία (Software as a Service-SaaS) Στο μοντέλο των επιχειρήσεων που χρησιμοποιούν το λογισμικό ως υπηρεσία (SaaS), παρέχονται στους χρήστες πρόσβαση σε λογισμικό εφαρμογών και βάσεων δεδομένων. Πάροχοι Cloud διαχειρίζονται την υποδομή και τις πλατφόρμες που τρέχουν τις εφαρμογές. Το SaaS μερικές φορές αναφέρεται ως «on-demand λογισμικό» και συνήθως τιμολογούνται με payper-use τρόπο. Οι SaaS παροχείς γενικά τιμολογούν τις εφαρμογές χρησιμοποιώντας μια συνδρομή. Στο μοντέλο SaaS, οι πάροχοι εγκαθιστούν και λειτουργούν το λογισμικό εφαρμογής στο νέφος και οι χρήστες έχουν πρόσβαση στο λογισμικό. Οι χρήστες Cloud δεν διαχειρίζονται την υποδομή cloud και την πλατφόρμα όπου εκτελείται η εφαρμογή. Αυτό εξαλείφει την ανάγκη για εγκατάσταση και εκτέλεση της εφαρμογής στου υπολογιστές του χρήστη, το οποίο απλοποιεί τη συντήρηση και την υποστήριξη. Οι εφαρμογές Cloud είναι διαφορετικές από τις άλλες εφαρμογές τους αφού η επεκτασιμότητα μπορεί να επιτευχθεί από την κλωνοποίηση της διεργασίας σε πολλαπλές εικονικές μηχανές κατά το χρόνο εκτέλεσης. Εξισορροπητές φόρτου διανέμουν την εργασία πάνω από το σύνολο των εικονικών μηχανών. Αυτή η διαδικασία είναι διαφανής για το χρήστη cloud, ο οποίος βλέπει μόνο ένα ενιαίο σημείο πρόσβασης. Για να φιλοξενηθεί ένας μεγάλος αριθμός χρηστών στο σύννεφο κάθε μηχανή μπορεί να εξυπηρετεί περισσότερους από έναν χρήστη cloud. Το μοντέλο τιμολόγησης για SaaS εφαρμογές είναι συνήθως μια μηνιαία ή ετήσια κατ αποκοπή αμοιβή ανά χρήστη, έτσι ώστε η τιμή είναι κλιμακούμενη και ρυθμιζόμενη αν οι χρήστες προστίθενται ή αφαιρούνται σε οποιοδήποτε σημείο. Με τις εφαρμογές που φιλοξενούνται σε κεντρικό επίπεδο, οι ενημερώσεις μπορούν να κυκλοφορήσουν χωρίς την ανάγκη για τους χρήστες να εγκαταστήσουν νέο λογισμικό. Ένα μειονέκτημα του μοντέλου SaaS είναι ότι τα δεδομένα των χρηστών αποθηκεύονται στο διακομιστή του φορέα παροχής νέφους. Ως αποτέλεσμα, θα μπορούσε να υπάρξει μη εξουσιοδοτημένη πρόσβαση στα δεδομένα. 11

26 Big Data και Cloud Computing 12

27 Apache Hadoop Κεφα λαιο 2 2 Apache Hadoop Ένα βασικό middleware framework, που χρησιμοποιήθηκε κατά κόρον στα πλαίσια αυτής της διπλωματικής, είναι το Apache Hadoop [11] που προσφέρει ένα αξιόπιστο, κλιμακούμενο, κατανεμημένο υπολογιστικό σύστημα. Ο όρος «Middleware» είναι πολύ συχνά χρησιμοποιημένος για να περιγράψει το λογισμικό που επιτρέπει και λειτουργεί την επικοινωνία και τη διαχείριση των δεδομένων σε κατανεμημένες εφαρμογές. Δεν αποτελεί λειτουργικό σύστημα ή σύστημα διαχείρισης βάσης δεδομένων, αλλά παρέχει συμπληρωματικές υπηρεσίες που δεν προσφέρει το λειτουργικό σύστημα. 2.1 Κατανεμημένο υπολογιστικό σύστημα Με την ανάπτυξη της τεχνολογίας και την πάροδο των ετών οι υπολογιστές καλούνταν να επιλύσουν προβλήματα που γίνονταν όλο και πιο πολύπλοκα με αποτέλεσμα η επεξεργαστική ισχύ ενός μηχανήματος δεν ήταν αρκετή για την παραγωγή αποτελεσμάτων γρήγορα. Τότε αναπτύχθηκε η ιδέα των παράλληλων κατανεμημένων συστημάτων ώστε να μπορούν να χωρίζουν το πολύπλοκα προβλήματα πολλά κομμάτια ώστε να μειώσουν αυτό το χρόνο. Αυτά τα συστήματα αναπτύχθηκαν παράλληλα με τα πρώτα δίκτυα υπολογιστών καθώς επιταχύνεται και είναι πλέον γεγονός η διασύνδεση υπολογιστικών πόρων. Το cluster αποτελείται από πολλά ίδια μηχανήματα, με ίδιο λειτουργικό σύστημα και filesystem, με το καθένα μηχάνημα να αναλαμβάνει κάποιο κομμάτι του παράλληλου πλέον προβλήματος. Συνέπεια του πιο πάνω ήταν και η ανάγκη για γρήγορη και απομακρυσμένη αποθήκευση δεδομένων καθώς οι ανάγκες για αποθηκευτικό χώρο. Έτσι έκανε την εμφάνιση του ο κλάδος του distributed data store. Αυτά τα συστήματα διαθέτουν μηχανισμούς συνδέσεων και αναπαραγωγής των δεδομένων σε διάφορα σημεία του συστήματος για ασφάλεια σε περιπτώσεις προβλημάτων. Με βάση αυτές τις ιδέες υλοποιήθηκε και η πλατφόρμα Apache Hadoop [2][7][20][23]. Εκτός από τον αποθηκευτικό χώρο μας ενδιαφέρει και η ταχύτητα επεξεργασίας δεδομένων σε τέτοια συστήματα. Το Hadoop με το MapReduce [10] αντιμετωπίζουν το πρόβλημα με επιτυχημένο και δοκιμασμένο τρόπο, έτσι ώστε να παρέχουν ένα σύστημα σταθερό και ευέλικτο για αποθήκευση μεγάλου όγκου δεδομένων και την ανάλυσή τους. Τα πιο πάνω δεν είναι φανταστικά και θεωρητικά. Στο εργαστήριο του CERN, όπου υπάρχει o μεγάλος επιταχυντής συγκρουόμενων δεσμών αδρονίων (Large Hadron Collider - LHC), το 13

28 Apache Hadoop datacenter έχει αυτή την στιγμή περίπου 100 petabytes δεδομένα, με τα 75 petabytes να έχουν αποθηκευτή τα τελευταία 3 χρόνια [27]. Επίσης τα δεδομένα του Facebook αυξάνονται κατά 0,5 petabyte κάθε 24 ώρες. Σχήμα 2.1 Υποδομή cluster 2.2 Χαρακτηριστικά Apache Hadoop To Apache Hadoop [11] είναι ένα framework ανοιχτού κώδικα για την ανάπτυξη κατανεμημένων εφαρμογών. Επιτρέπει την διαχείριση μεγάλου όγκου κατανεμημένων δεδομένων τα οποία είναι αποθηκευμένα σε clusters. Είναι σχεδιασμένο να έχει υψηλή κλιμάκωση καθώς μπορεί να λειτουργήσει από μερικά μέχρι χιλιάδες ανομοιόμορφα μεταξύ τους μηχανήματα. Προσφέρει επίσης το MapReduce που είναι ίσως και η πιο γνωστή υλοποίηση του μοντέλου που πρωτοπαρουσιάστηκε από την Google [14]. Είναι γραμμένο σε γλώσσα Java. Επίσης προσφέρει το Hadoop Distributed File System (HDFS) το οποίο προσφέρει υψηλό throughput στην πρόσβαση στα δεδομένα. Αυτά τα δύο θα αναλυθούν παρακάτω εκτενέστερα καθώς για να λειτουργήσει η κατανεμημένη βάση δεδομένων HBase πρέπει να υπάρχει εγκατεστημένο αυτό το framework. Επίσης κατά την διαδικασία της προ-επεξεργασίας των δεδομένων που χρησιμοποιούνται στα πειράματα το MapReduce είναι ένα πανίσχυρο όπλο. Προβλήματα τύπου αστοχίας μηχανημάτων και διαχείρισης σφαλμάτων χρειάζεται να αντιμετωπιστούν. Αυτό γίνεται στο επίπεδο του middleware, με την αυτόματη ανακατανομή των εργασιών στους διαθέσιμους κάθε στιγμή κόμβους. Τα κυριότερα χαρακτηριστικά του είναι: Προσβασιμότητα To Hadoop εφαρμόζεται σε μεγάλα clusters με μέσου κόστους υλικό και σε συστήματα υπηρεσιών cloud. Αξιοπιστία Σε συστήματα που έχουμε να κάνουμε με υλικό πρέπει η αστοχία κόμβων ή αποθηκευτικών μονάδων να θεωρείται δεδομένη. Το Hadoop μπορεί να τα αντιμετωπίσει αυτά τα προβλήματα αφού διαθέτει τους κατάλληλους μηχανισμούς. 14

29 Apache Hadoop Επεκτασιμότητα Μπορούν να προστεθούν νέοι κόμβοι στο cluster καθώς πραγματοποιεί γραμμικό scaling. Ευκολία Με τις βιβλιοθήκες που προσφέρει καθώς και την ενσωματωμένη χρήση του MapReduce το οποίο μπορεί να αλληλοεπιδρά και με άλλα συστήματα του Hadoop προσφέρει ευκολία και ευελιξία. Hadoop HDFS MapReduce Σχήμα 2.2 Δομικά στοιχεία του Apache Hadoop Μέρος του Hadoop είναι και ο ZooKeeper [28] είναι μια κεντρική υπηρεσία για τη διατήρηση πληροφοριών διαμόρφωσης, την ονοματοδοσία, την παροχή κατανεμημένου συγχρονισμού, και την παροχή υπηρεσιών ομάδας. Όλα αυτά τα είδη των υπηρεσιών χρησιμοποιούνται σε κάποια μορφή στις κατανεμημένες εφαρμογές. Κάθε φορά που εφαρμόζονται, έπεται πολλή εργασία για καθαρισμό των bugs και συνθηκών ανταγωνισμού που είναι αναπόφευκτες. Λόγω της δυσκολίας της εφαρμογής αυτού του είδους των υπηρεσιών, οι εφαρμογές συνήθως αμελούν να τις εφαρμόσουν πράγμα που τις κάνει εύθραυστες. Ο ZooKeeper φροντίζει να διορθώνει τα λάθη που παρουσιάζονται, κυρίως μέσω δικτύου. Η απλή αρχιτεκτονική του, τον καθιστά ως μία πολύ επεκτάσιμη πλατφόρμα. 2.3 Hadoop Distributed File System - HDFS Το Hadoop για να λειτουργήσει έχει το δικό του σύστημα αρχείων, το Hadoop Distributed File System (HDFS) [9]. Το HDFS είναι η ανοιχτού κώδικα υλοποίηση του Google File System που είχε παρουσιαστεί το 2003 [23]. Αρχικά είχε δημιουργηθεί για το Apache Nutch ένα project για μηχανές αναζήτησης. Τώρα είναι μέρος του Hadoop. Το HDFS είναι αυτό το οποίο μπορεί να χειριστεί τα δεδομένα και τον τρόπο αποθήκευσής τους σε ένα Hadoop Cluster. Είναι υψηλά ανεχτικό σε σφάλματα (fault-tolerant) και είναι σχεδιασμένο να λειτουργεί πάνω από φθηνό υλικό. Οι εφαρμογές που τρέχουν χρειάζονται ροή στα σύνολα δεδομένων τους. Το HDFS έχει σχεδιαστεί περισσότερο για batch επεξεργασία και όχι για αμφίδρομη χρήση από τους χρήστες. Η έμφαση δίνεται στην υψηλή απόδοση της πρόσβασης στα δεδομένα και όχι στο χαμηλό latency, δηλαδή την χρονική καθυστέρηση της πρόσβασης στα δεδομένα. Είναι το ιδανικότερο για εφαρμογές που έχουν πολύ μεγάλο μέγεθος 15

30 Apache Hadoop δεδομένων. Το σημαντικότερο ίσως είναι ότι, αυτό που πραγματικά γίνεται, μεταφέρεται ο υπολογισμός αντί να μεταφέρονται δεδομένα γιατί είναι πολύ φθηνότερο Αρχιτεκτονική του HDFS Το Hadoop και κατ επέκταση το HDFS είναι υλοποιημένο στην αρχιτεκτονική client - server για τις λειτουργίες τις αποθήκευσης δεδομένων αλλά και εκτέλεσης υπολογισμών. Το κάθε μηχάνημα που λειτουργεί με το Apache Hadoop, περιέχει βασικές διεργασίες για να λειτουργήσει. Κάποια από τα υποσυστήματα πρέπει να υπάρχουν μόνο μια φορά, όπως ο NameNode και ο JobTracker, ενώ άλλα υποσυστήματα, όπως ο DataNode και ο TaskTracker, υπάρχουν μία ή περισσότερες φορές σε ένα ή περισσότερα μηχανήματα. Παρακάτω αναλύονται αυτά τα τμήματα. NameNode Σε κάθε cluster υπάρχει ένας master κόμβος, ο οποίος αντιπροσωπεύεται από έναν NameNode, και ο οποίος διαχειρίζεται το namespace του filesystem και δρομολογεί τους χρήστες, με βάση τις αιτήσεις τους, στους DataNodes ώστε να κάνουν εγγραφές χαμηλού επιπέδου για να αποθηκεύονται τα δεδομένα. O NameNode είναι ο υπεύθυνος ο οποίος γνωρίζει με βάση τα metadata που έχει, που και ποια δεδομένα είναι αποθηκευμένα. Δεν διατηρεί μόνο την τελική τοποθεσία του αρχείου σε σχέση με τον κόμβο, αλλά και το τρόπο που είναι κατανεμημένο σε τμήματα τα blocks, ώστε να μπορεί να το επαναφέρει σε σωστή κατάσταση. Λαμβάνει περιοδικά heartbeats από τους DataNodes για επιβεβαίωση της λειτουργίας τους. Επίσης ο NameNode πρέπει να παρακολουθεί την διαθεσιμότητα των δεδομένων και των αντιγράφων τους. Όταν ένα αρχείο πρέπει να αποθηκευτεί ο NameNode λαμβάνει αίτηση για να δρομολογηθεί το αρχείο απευθείας στους DataNodes. Ο NameNode συνήθως είναι το μοναδικό μηχάνημα υψηλότερων επιδόσεων από τους υπόλοιπους κόμβους. Όταν υπάρχει αίτηση για πρόσβαση σε αρχεία, ο NameNode στέλνει στους clients μια λίστα με τους DataNodes που διατηρούν τα ζητούμενα δεδομένα. Μόνο αυτός έχει αυτά τα στοιχεία γι αυτό και καθίσταται ως το μοναδικό αδύναμο σημείο του κατανεμημένου συστήματος (single point of failure), διότι σε περίπτωση αστοχίας είτε του υλικού είτε του λογισμικού, όλο το σύστημα τίθεται εκτός λειτουργίας. DataNode Οι DataNodes αποτελούν όλους τους κόμβους (slaves) του δικτύου που προορίζονται για αποθήκευση και επεξεργασία του cluster. Είναι υπεύθυνοι για την ανάγνωση και εγγραφή των blocks δεδομένων που υποβάλλουν οι χρήστες. Οι DataNodes επικοινωνούν με τον NameNode αλλά και με άλλους Datanodes ώστε να γίνεται και διατήρηση αντιγράφων (replication) σε άλλους κόμβους του συστήματος. Δίνουν αναφορά στον NameNode σχετικά με τον κατάλογο blocks που περιέχουν, σε κάθε αλλαγή που πραγματοποιείται καθώς και της κατάστασης τους, για τον εντοπισμό αυτών που αντιμετωπίζουν κάποιο πρόβλημα. 16

31 Apache Hadoop Secondary NameNode, Checkpoint Node και Backup Node Οι πιο πάνω κόμβοι έχουν υποβοηθητικό ρόλο και συμβάλουν στην ασφάλεια και ειδικά στο πρόβλημα του NameNode κρατώντας συνεχώς αντίγραφα ασφαλείας και διαδικασιών (log). Αξίζει να σημειωθεί ότι σε πιο πρόσφατες εκδόσεις του Hadoop έχουν προστεθεί εργαλεία για εξυπηρέτηση εφαρμογών που επιβάλλουν υψηλή διαθεσιμότητα (High Availability) και σε αυτή την υλοποίηση υπάρχουν δύο τύπου NameNodes με το ένα να είναι ενεργό και τον άλλο σε ετοιμότητα. Σχήμα 2.3 Αρχιτεκτονική HDFS και ροή πληροφορίας Χαρακτηριστικά και Εργαλεία του HDFS Το HDFS παρέχει ένα web interface από το οποίο μπορεί ο χρήστης να δει τι υπάρχει ανά πάσα στιγμή στο HDFS, τις τοποθεσίες των αρχείων του στο cloud καθώς και το περιεχόμενο αν είναι αποθηκευμένο σε μορφή που είναι αναγνώσιμη και έχει την επιλογή να το κατεβάσει τοπικά στον δίσκο του. Όπως αναφέρεται και προηγουμένως ο αριθμός των μηχανημάτων μπορεί να είναι πολύ μεγάλος και οποιοδήποτε ανά πάσα στιγμή μπορεί να αποτύχει. Έτσι για να υπάρχει αξιοπιστία, διαθεσιμότητα και γρήγορη απόκριση στις εφαρμογές προσφέρονται κάποια εργαλεία ώστε να εντοπίζονται οι μη διαθέσιμοι κόμβοι και να μπορεί το πρόβλημα να αντιμετωπιστεί χωρίς να υπάρξει πρόβλημα στην εμπειρία του χρήστη. Εκτέλεση κοντά στα δεδομένα Ο κώδικας εκτελείται όσο πιο κοντά γίνεται στα δεδομένα για να ελαχιστοποιείται η κίνηση στο δίκτυο και να αυξάνεται το ολικό throughput. 17

32 Apache Hadoop Replication Τα αρχεία χωρίζονται σε blocks ίσου μεγέθους και αντιγράφονται στους DataNodes που ορίζει ο NameNode. Το μέγεθος των blocks και ο αριθμός των αντιγράφων μπορούν να οριστούν από τον χρήστη για κάθε αρχείο αλλά υπάρχει και κεντρική ρύθμιση. Συνήθως προτιμάται ένα αντίγραφο να αποθηκεύεται ταυτόχρονα σε κόμβο στο ίδιο και σε διαφορετικό rack με σαφές θετικό αντίκτυπο στην κίνηση. Οι παρακάτω τεχνικές χρησιμοποιούνται στο Replication Rebalancer: Ανακατανομή των δεδομένων στους DataNodes για να υπάρχει όσο καλύτερη κατανομή όταν παρατηρηθούν μεγάλες αποκλείσεις. Rack Awareness: Σε περίπτωση που έχουμε μεγάλης κλίμακας clusters είναι καλό οι κόμβοι που επικοινωνούν συχνά μεταξύ τους να είναι στο ίδιο rack. Safemode: Είναι η κατάσταση που μπαίνει ο NameNode κατά την εκκίνηση του μέχρι να ενημερωθεί από όλους του DataNodes για τα περιεχόμενα τους ώστε να μην υπάρχει θέμα να υπάρχουν περισσότερα replicas. Block 64ΜΒ Α C Α B B D E Block 64ΜΒ Δεδομένα εισόδου Block 64ΜΒ Node 1 Node 2 B C Α C D E D E Block 64ΜΒ Node 3 Node 4 Σχήμα 2.4: Διαχωρισμός εισόδου σε blocks 2.4 MapReduce Σχήμα 2.5 Replication blocks στους κόμβους Το Hadoop MapReduce [10] είναι ένα framework για δημιουργία εφαρμογών οι οποίες εκτελούνται σε τεράστιες ποσότητες δεδομένων (multi-terabyte data-sets) παράλληλα σε πολύ μεγάλα clusters (χιλιάδων κόμβων), μέσου κόστους μηχανημάτων, με αξιοπιστία και ανοχή σε σφάλματα. Μία MapReduce διαδικασία, στην βιβλιογραφία να αναφέρεται σαν job, συνήθως σπάει τα δεδομένα εισόδου σε ανεξάρτητα κομμάτια (chuncks) που υφίστανται επεξεργασία από τις map tasks με ένα εντελώς παράλληλο τρόπο. Εφαρμόζει δηλαδή την τεχνική διαίρει και βασίλευε. Τα δεδομένα εξόδου των maps αφού ταξινομηθούν προωθούνται στις reduce tasks. Τυπικά τόσο η είσοδος τόσο και η έξοδος της εργασίας αποθηκεύονται σε ένα σύστημα αρχείων. Το framework φροντίζει για τον χρονοπρογραμματισμό των εργασιών, την παρακολούθησή τους και την εκ νέου εκτέλεση σε περίπτωση που αποτύχει. 18

33 Apache Hadoop Το MapReduce προσφέρει όλες τις μεθόδους και τους μηχανισμούς που χρειάζονται για την επίλυση προβλημάτων, για την παράλληλη επεξεργασία μεγάλου όγκου δεδομένων γι αυτό και αποτελεί βασικό κομμάτι του Hadoop. Οι υπολογιστικοί και αποθηκευτικοί κόμβοι στο framework είναι οι ίδιοι με αυτούς που αποθηκεύονται τα δεδομένα στο HDFS. Προσφέρεται ένας αποδοτικός χρονοπρογραμματισμός των εργασιών στους κόμβους όπου είναι είδη αποθηκευμένα τα δεδομένα με αποτέλεσμα ένα πολύ υψηλό συνολικό εύρος ζώνης σε όλο το cluster. Έτσι υπάρχει και εδώ η ανάγκη οι κόμβοι να αποκτήσουν κάποιους ρόλους. JobTracker Ο JobTracker, που είναι μοναδικός στο σύστημα, είναι η μοναδική διεργασία η οποία καθορίζει τον τρόπο εκτέλεσης των εργασιών που δημιουργούνται από τους χρήστες. Ο JobTracker ορίζει τον τρόπο που θα εκτελεστεί ο κώδικας, θα ελέγξει σε ποιους κόμβους βρίσκονται τα δεδομένα, θα ορίσει τις δουλειές του κάθε κόμβου και θα παρακολουθεί την εξέλιξη της εκτέλεσης. Σε περίπτωση που κάποιος κόμβος παρουσιάσει πρόβλημα αναθέτει την εκτέλεση σε κάποιο άλλο κόμβο. Σε περίπτωση αποτυχίας στην εκτέλεση κάποιου προγράμματος επανεκκινά την εκτέλεση του. TaskTracker Από την στιγμή που έχει δρομολογηθεί μια εργασία, από τον JobTracker αναλαμβάνει ο TaskTracker την διεκπεραίωση του. Ο TaskTracker είναι ένας σε κάθε κόμβο και εκτελεί παράλληλα διεργασίες map-reduce. Ανά τακτά χρονικά διαστήματα ο κάθε TaskTracker αναφέρει την πρόοδο του στον JobTracker. Σχήμα 2.6 Αρχιτεκτονική MapReduce Το Hadoop MapReduce framework από την είσοδο στους mappers, στα ενδιάμεσα στάδια και στην τελική έξοδο, παράγει και επεξεργάζεται δεδομένα τύπου key-value. Τα δεδομένα μπορούν να θεωρηθούν από το σύστημα όπως επιθυμεί ο προγραμματιστής ώστε ανάλογα με 19

34 Apache Hadoop τον τύπο τους, που ορίζεται για κάθε MapReduce εργασία, να υπάρχει ευελιξία στην ανάλυση όσο το δυνατό περισσότερων τύπων δεδομένων. input <k1,v1> map <k2,v2> combine <k2,v2> reduce <k3,v3> Σχήμα 2.7 Διαδικασία MapReduce Παράδειγμα MapReduce Ας θεωρήσουμε ότι έχουμε μια συλλογή από αρχεία και θέλουμε να μετρήσουμε τις συνολικές εμφανίσεις κάθε λέξης που περιέχεται σε αυτά τα αρχεία. Στην περίπτωση του διαδικαστικού προγραμματισμού, ο ψευδοκώδικας που φαίνεται παρακάτω περιγράφει αυτή την διαδικασία. define wordcount as set; for each document in documentset { wordset = tokenize(document); for each token in wordset { wordcount[token]++; } } Ο παραπάνω κώδικας εκτελεί επαναλήψεις μέσα στα έγγραφα, αναζητά λέξεις και δίνει σε κάθε μια μοναδική λέξη μια ταυτότητα. Για κάθε λέξη που επαναλαμβάνεται, η οποία βρίσκεται ήδη στην λίστα των λέξεων, αυξάνει τον μετρητή της κατά ένα. Αυτό το πρόγραμμα μπορεί να λειτουργήσει καλά για μικρά έγγραφα, όμως είναι πολύ χρονοβόρο όταν πρέπει να επεξεργαστεί τεράστια αρχεία, όπως είναι τα αρχεία καταγραφής (log files) ή τα χωροχρονικά δεδομένα. Αυτό το πρόβλημα σε ένα MapReduce πρόγραμμα έχει μια πολύ αποδοτική λύση καθώς δεν υπάρχουν προβλήματα που θα μπορούσαν να υπάρξουν σε μια απλή παράλληλη προγραμματιστική υλοποίηση του πιο πάνω. Τα περιεχόμενα των αρχείων δρομολογούνται στους mappers όπου ο κάθε mapper βρίσκει τις λέξεις και τις προωθεί με την λέξη ως κλειδί και τιμή τον αριθμό «1». Οι reducers αφού ξέρουν ότι οι τιμές για κάθε μοναδικό κλειδί που παίρνουν είναι πολλαπλές αθροίζουν τα «1» για κάθε λέξη και εξάγουν το αποτέλεσμα. Παρακάτω φαίνονται σε ψευδοκώδικα τα πιο πάνω και το σχήμα 2.8 που περιγράφει την διαδικασία με τρείς mappers και δύο reducers. map(key, value): //Map Function // key: document name // value: document contents for each word w in value: emit (w, 1 ); 20

35 Apache Hadoop reduce(key, Iterator values): // Reduce Function // key: a word // values: an iterator over counts int result = 0; for each v in values: result += ParseInt(v); emit(result); (d1, w1 w2 w4 ) (d2, w1 w2 w3 w4 ) (d3, w2 w3 w4 ) (w1,2) (w2,3) (w3,2) (w4,3) (w1,2) (w1,3) (w1,3) (w1,7) (w2,3) (w2,15) (w2,4) (d4, w1 w2 w3 ) (d5, w1 w3 w4 ) (w1,3) (w2,4) (w2,3) (d6, w1 w4 w2 w2 ) (w3,2) (d7, w4 w2 w1 ) (w4,3) (w3,2) (w3,2) (w3,4) (w3,8) (d8, w2 w2 w3 ) (d9, w1 w1 w3 w3 ) (d10, w2 w1 w4 w3 ) (w1,3) (w2,3) (w3,4) (w4,1) (w4,3) (w4,3) (w4,1) (w4,7) Σχήμα 2.8 Διάγραμμα παραδείγματος MapReduce για WordCount Αρχιτεκτονική του MapReduce Για το MapReduce οι slave κόμβοι ονομάζονται workers και ο master κόμβος εκτελεί τα καθήκοντα του διαχειριστή των εργασιών και του κόμβου που είναι υπεύθυνος για την διαχείριση αστοχιών του συστήματος. Ο master κόμβος αναθέτει τις εργασίες στους workers και καθορίζει ποιοι κόμβοι θα κάνουν map και ποιοι reduce ανάλογα με τον configuration που επιβάλει το σύστημα ή η εφαρμογή. Στο πρώτο στάδιο ο master χωρίζει σε M κομμάτια τα δεδομένα που θα υποστούν επεξεργασία και τα κατανέμει στους map κόμβους για παράλληλη επεξεργασία. Τα δεδομένα περνούν από τον input reader, ο οποίος παράγει τα key-value ζεύγη για κάθε δεδομένο. Συνήθως ο input reader διαβάζει τα δεδομένα ανά γραμμή. Οι mappers εφαρμόζουν την map συνάρτηση στα key-value δεδομένα. Στην συνέχεια ο master κόμβος χωρίζει (shuffling) τα ενδιάμεσα δεδομένα 21

36 Apache Hadoop με βάση μια συνάρτηση κατακερματισμού ώστε κάθε reducer να λάβει περίπου ίδιο ποσοστό δεδομένων προς επεξεργασία για να υπάρχει ισοκατανομή του φόρτου. Αυτή η συνάρτηση (partitioner) είναι συνήθως η hash(key) mod R, όπου R είναι το πλήθος των reducers όπως αυτά ορίζονται από τον χρήστη. Το Hadoop στη συνέχεια ταξινομεί (sort), με βάση το key, λεξικογραφικά εχτός αν οριστεί κάτι διαφορετικό. Ο master ειδοποιεί τους reducers για την τοποθεσία των ενδιάμεσων key-value ζευγών δεδομένων ώστε αυτοί, με την σειρά τους, να τα διαβάσουν και να εφαρμόσουν την reduce συνάρτηση και να παράγουν τα αποτελέσματα τα οποία προωθούνται στον OutputCollector, ο οποίος καθορίζει την τελική μορφή που θα πάρουν τα δεδομένα. Αυτός μπορεί να γράψει τα δεδομένα στο HDFS και αυτά τα αρχεία είναι συνήθως όσα και οι reducers και καθορίζονται από την εφαρμογή. Σχήμα 2.9 Αρχιτεκτονική και ροή πληροφορίας MapReduce (M=3, R=2) Προαιρετικά ανάμεσα στους mappers και στους reducers μπορεί να υπάρχουν και οι combiners, ένας ανά κόμβο, οι οποίοι είναι υπεύθυνοι για την συνένωση των output των map tasks πριν την αποστολή τους στους reducers. Αν οριστούν combine tasks το sort γίνεται μετά την επιστροφή του combine. Στην συνέχεια όπως και πριν ομαδοποιούνται και περνούν στους reducers. Ο combine χρησιμοποιείται για την μείωση του όγκου δεδομένων που μεταφέρεται ανάμεσα στον mapper και τον reducer βελτιώνοντας την απόδοση των εφαρμογών. Πρακτικά η συνάρτηση combine έχει την ίδια λειτουργία με την reduce Χαρακτηριστικά και Εργαλεία του MapReduce Ο κατανεμημένος τρόπος χειρισμού των δεδομένων προκαλεί την ανάγκη για την ύπαρξη μηχανισμών για την ανάπτυξη, τον έλεγχο, τον χειρισμό, το debugging και την δοκιμή προγραμμάτων που χρησιμοποιούν το MapReduce. 22

37 Apache Hadoop Μετρητές (Counters) Οι μετρητές αναπαριστούν global μετρητές, που ορίζονται είτε από το MapReduce framework είτε από τις εφαρμογές. Χρησιμοποιούνται για την παρουσίαση της συνολικής απόδοσης των εφαρμογών. Για παράδειγμα, η μέτρηση των εγγράφων που απορρίπτονται κατά την εφαρμογή του MapReduce δίνει μια καλή εικόνα για την συμπεριφορά της εφαρμογής και την απόδοση της. Κατανεμημένη μνήμη (Distributed cache) Είναι ο μηχανισμός του Hadoop για την αποδοτική κατανομή read-only αρχείων σε όλους τους κόμβους του cluster που χρειάζονται οι εφαρμογές. Τα δεδομένα αυτά αποθηκεύονται στην cache των κόμβων πριν την εκτέλεση των tasks που θα τα χρειαστούν. Τα αρχεία αυτά δεν πρέπει να υποστούν επεξεργασία όσο χρόνο εκτελείται το task. Ένα παράδειγμα είναι τα αρχεία με stopwords που χρησιμοποιούνται σε διάφορες εφαρμογές. Isolation Runner Σε περίπτωση που κάποιο task αποτύχει έχει την ευθύνη να το επανεκτελέσει με ακριβώς την ίδια είσοδο. Μόνο τα map tasks μπορούν να τύχουν αυτής της ιδιότητας. Παράκαμψη προβληματικών εγγραφών (Skipping Bad Records) Τα δεδομένα πολλές φορές είναι τόσο μεγάλα που δεν μπορούν να ελεγχθούν αν η δομή τους είναι η επιθυμητή παντού. Στην περίπτωση όπου κάποιες από τις εγγραφές στα δεδομένα δεν είναι στη επιθυμητή μορφή και υπάρχουν λάθη υπάρχει ο μηχανισμός που ενεργοποιείται από τους διαχειριστές για να αντιμετωπίσει αυτές τις καταστάσεις. Συγκεκριμένα εντοπίζονται οι εγγραφές, διαγράφονται και επαναδρομολογείται το αρχείο για εκτέλεση. JobTracker διεπαφή Web Για την παρακολούθηση των εργασιών ο JobTracker παρέχεται ένα web interface στο οποίο φαίνονται οι διεργασίες σε πιο στάδιο βρίσκονται, τα σφάλματα αν υπάρχουν και όλα τα configurations της διεργασίας με το όνομα της όπως της ανατέθηκε. Συμπίεση (Compression) Περιλαμβάνονται διάφορα εργαλεία συμπίεσης και αποσυμπίεσης δεδομένων ώστε να μειώνεται όσο το δυνατό περισσότερο η κίνηση μεταξύ των κόμβων με αποτέλεσμα να μειώνεται η κίνηση στο δίκτυο όσο γίνεται περισσότερο. Υπάρχουν επίσης κάποιες λειτουργίες οι οποίες επιτρέπουν στον χρήστη να πραγματοποιήσει πιο σύνθετες και εξελιγμένες λειτουργίες με το Hadoop MapReduce. Πολλές MapReduce διαδικασίες μπορούν να συνενωθούν με την σύνδεση μεταξύ τους και την αυτόματη δρομολόγηση των αποτελεσμάτων από την μια στην επόμενη. Επίσης υπάρχουν και κάποιες τεχνικές joins. Τα joins είναι εφαρμόσιμα σε περιπτώσεις όπου έχουμε δύο ή περισσότερα datasets που θέλουμε να τα συνδυάσουμε. Τέτοιο παράδειγμα είναι αν θέλουμε να συνδυάσουμε τους χρήστες με τα log files που περιέχουν τις λεπτομέρειες με την δραστηριότητα τους. Υπάρχουν τρεις στρατηγικές που το κάνουν αυτό με τα joins να γίνονται είτε στην φάση 23

38 Apache Hadoop του map είτε στην φάση του reduce εκμεταλλευόμενοι την sort-merge αρχιτεκτονική του MapReduce [23]. Το Repartition join όπου είναι ένα reduce-side join για περιπτώσεις όπου συνενώνονται δύο ή περισσότερα μεγάλα datasets μαζί. Το δεύτερο είναι το Replication join όπου είναι map-side join για περιπτώσεις όπου το ένα dataset είναι αρκετά μικρό ώστε να μπορεί να χωρεί στην μνήμη cache. Το τρίτο είναι το Semi join όπου και αυτό είναι map-side join όπου το ένα dataset είναι πάρα πολύ μεγάλο να χωρέσει στην μνήμη αλλά μετά από κάποιο filtering μπορεί να γίνει μικρότερο και να χωρέσει στην μνήμη. 2.5 Άλλες πληροφορίες Πάνω από το middleware σύστημα μπορούν να εγκαθιστούν και να τρέχουν άλλα συστήματα όπως διάφορες NoSQL βάσεις που θα παρουσιαστούν σε επόμενο κεφάλαιο. Κάποια συστήματα NoSQL, όπως το Neo4j, που χρησιμοποιείται παρακάτω δεν χρειάζονται middleware σύστημα καθώς δεν κατανέμουν την πληροφορία αλλά απλά την αντιγράφουν και στους υπόλοιπους κόμβους του cluster. Σε παλαιότερες εκδόσεις το Neo4j, χρησιμοποιούσε τον Zookeeper που αναφέρεται πιο πάνω. Στις νεότερες εκδόσεις αυτό το σύστημα εγκαταλείφθηκε και η βάση δεδομένων Neo4j δεν χρειάζεται υποστήριξη από άλλα συστήματα. 24

39 NoSQL Βάσεις Δεδομένων Κεφα λαιο 3 3 NoSQL Βάσεις Δεδομένων Σε αυτό το κεφάλαιο παρουσιάζονται οι βασικές αρχές και χαρακτηριστικά του κομματιού λογισμικού που ίσως να εγκαθίσταται πάνω από το επίπεδο middleware και αποτελεί την σύνδεση στην επικοινωνία του με τις τελικές εφαρμογές που αναπτύσσονται από τους χρήστες. Το λογισμικό αυτό αφορά στις NoSQL βάσεις δεδομένων. Μια βάση δεδομένων είναι μια συλλογή δεδομένων όπου ανάλογα με το είδος της έχει συγκεκριμένη δομή και ακολουθεί συγκεκριμένους κανόνες. Η βάση δεδομένων έρχεται σε συνδυασμό με ένα Σύστημα Διαχείρισης Βάσεων Δεδομένων το γνωστό Database Management System (DBMS) [22]. Υπάρχουν διάφορα μοντέλα DBMS καθώς και η γλώσσα προγραμματισμού για τον χειρισμό τους. Σε αντίθεση με τις παραδοσιακές βάσεις δεδομένων, που χρησιμοποιούν το σχεσιακό DBMS (RDBMS) και την γλώσσα SQL, οι NoSQL όπως υποδηλώνεται και από το όνομα τους (Not Only SQL) επιτρέπουν σε SQL-like γλώσσες να χρησιμοποιούνται. Κίνητρα αυτής της προσέγγισης είναι η απλότητα του σχεδιασμού, η οριζόντια κλιμάκωση, ο καλύτερος έλεγχος διαθεσιμότητας, η πολυμορφία και η αύξηση της επίδοσης των εφαρμογών. 3.1 Γενικά Κατανεμημένων Βάσεων Δεδομένων Ιδιότητες ACID To ACID είναι ένα σύνολο ιδιοτήτων το οποίο εγγυάται ότι οι συναλλαγές (transactions) στην βάση δεδομένων λειτουργούν αξιόπιστα [18]. Η ιδέα του ACID είναι να αξιολογεί την δομή των βάσεων δεδομένων και την εφαρμογών. Όσον αφορά τις βάσεις δεδομένων, μια λογική ενέργεια που έχει να κάνει με τα δεδομένα της αποκαλείται συναλλαγή. Το 1983 ο Andreas Reuter και ο Theo Haerder χρησιμοποίησαν το ακρωνύμιο ACID για να περιγράψουν αυτές τις ιδιότητες [30]. Ατομικότητα (Atomicity) Η ατομικότητα απαιτεί ότι η τροποποίηση που θα γίνει στην βάση τηρεί τον κανόνα όλα ή τίποτα. Κάθε συναλλαγή η οποία είναι ατομική ονομάζεται έτσι επειδή αν ένα μέρος της αποτύχει, όλη η συναλλαγή αποτυγχάνει και η βάση μένει όπως ήταν πριν εκτελεστεί η συναλλαγή. Είναι πολύ κρίσιμο το DBMS να διατηρεί την ατομικότητα κάθε συναλλαγής ανεξάρτητα από το είδος της εφαρμογής, του λειτουργικού συστήματος ή τις αστοχίες του υλικού. Με την ατομικότητα οι χρήστες είναι απαλλαγμένοι από τον φόβο μη ολοκληρωμένων συναλλαγών. Οι συναλλαγές μπορούν να αποτύχουν για πολλούς και διάφορους λόγους όπως 25

40 NoSQL Βάσεις Δεδομένων η αποτυχία υλικού δηλαδή ένας δίσκος μπορεί να χαλάσει, αποτρέποντας μερικές αλλαγές στη βάση από το να πραγματοποιηθούν. Επίσης υπάρχει περίπτωση ο χρήστης να χάσει την σύνδεση του με το σύστημα πριν ολοκληρώσει τις εργασίες του. Η εφαρμογή η οποία χειρίζεται την βάση δεδομένων προσπαθεί να βάλει δεδομένα τα οποία παραβιάζουν τους κανόνες που έχει επιβάλλει η βάση δεδομένων. Συνέπεια (Consistency) Η ιδιότητα της συνέπειας διασφαλίζει ότι η βάση διατηρείται σε μια συνεπή κατάσταση. Συγκεκριμένα, κάθε συναλλαγή θα οδηγεί την βάση δεδομένων από την μια συνεπή κατάσταση στη άλλη. Η ιδιότητα της συνέπειας δεν λέει πως ένα DBMS πρέπει να χειρίζεται μια ασυνέπεια αλλά λέει πώς να είναι καθαρή η βάση στο τέλος μιας συναλλαγής. Αν για κάποιο λόγο μια συναλλαγή παραβιάζει την συνέπεια της βάσης όλη η συναλλαγή ακυρώνεται (επανέρχεται στην κατάσταση πριν εκτελεστεί η συναλλαγή). Οι δημιουργοί εφαρμογών είναι υπεύθυνοι για διατήρηση τις συνέπειας όσο αφορά τις εφαρμογές τους, επιπλέον από τους προσφερόμενους κανόνες του DBMS. Έτσι, αν ένας χρήστης κάνει μια ανάληψη κεφαλαίου και το νέο υπόλοιπο είναι χαμηλότερο από το επιτρεπόμενο όριο τότε όσον αφορά το DBMS η βάση είναι σε συνεπή κατάσταση αν και ο κανόνας που το ελέγχει αυτό έχει παραβιαστεί. Απομόνωση (Isolation) Η απομόνωση αναφέρεται στην απαίτηση ότι όλες οι συναλλαγές δεν μπορούν να έχουν πρόσβαση ή να δουν δεδομένα τα οποία τροποποιούνται εκείνη την στιγμή από μια άλλη συναλλαγή η οποία δεν έχει ακόμα ολοκληρωθεί. Κάθε συναλλαγή δεν πρέπει να ξέρει αν υπάρχουν άλλες συναλλαγές που εκτελούνται ταυτόχρονα, αλλά πρέπει να περιμένουν την ολοκλήρωση μιας συναλλαγής ώστε να δουν ή να τροποποιήσουν τα δεδομένα τα οποία χρειάζεται και η άλλη συναλλαγή. Το τελικό αποτέλεσμα θα πρέπει να είναι το ίδιο αν όλα τα transactions έτρεχαν σειριακά. Μονιμότητα (Durability) Η μονιμότητα εγγυάται στον χρήστη ότι αν τελειώσει μια συναλλαγή επιτυχώς τότε τα αποτελέσματα της δεν θα χαθούν. Οι αλλαγές που έχει κάνει η συναλλαγή δεν θα χαθούν έστω και να πέσει το σύστημα και όλες οι προϋποθέσεις ακεραιότητας ισχύουν, έτσι ώστε το DBMS δεν θα χρειαστεί να ακυρώσει αυτή τη συναλλαγή. Πολλά DBMS επιτυγχάνουν μονιμότητα με το να τηρούν ένα αρχείο συναλλαγών (log) το οποίο μπορεί να χρησιμοποιηθεί και να επαναφέρει την κατάσταση του συστήματος ακριβώς όπως ήταν πριν να πέσει. Μια συναλλαγή αποκαλείται commit μόνο όταν καταχωρηθεί σε αυτό το αρχείο Μοντέλα Συνέπειας Σε κατανεμημένα συστήματα, όπως σε συστήματα κατανεμημένων βάσεων δεδομένων χρησιμοποιούνται consistency models τα οποία ορίζουν κανόνες για την σειρά των updates των δεδομένων. Τα δεδομένα αποθηκεύονται σε ένα ή περισσότερα σημεία και γίνεται πρόσβαση σε αυτά με reads και writes. Υπάρχουν δύο σημαντικά μοντέλα συνέπειας, το strong consistency και το eventual consistency [25]. 26

41 NoSQL Βάσεις Δεδομένων Θεωρούμαι ότι N είναι ο αριθμός των αντιγράφων των δεδομένων που διατηρεί η βάση, R είναι ο αριθμός των αντιγράφων που θα πρέπει να διαβαστούν για να είναι έγκυρο ένα read και W είναι ο αριθμός των αντιγράφων που πρέπει να ενημερωθούν πριν να ολοκληρωθεί το write. Η κάθε βάση επιλέγει τέτοια N, R, W ανάλογα με τις χρήσεις της. Αν θέλουμε υψηλή διαθεσιμότητα πρέπει να έχουμε μεγάλο N και R=1. Βάσεις με περισσότερα reads επιλέγουν μικρό R και μεγάλο W. Αντίστοιχα, βάσεις με περισσότερα writes επιλέγουν μικρό W και μεγάλο R. Strong Consistency Σε αυτό το μοντέλο κάθε χρονική στιγμή όλες οι διεργασίες του κατανεμημένου συστήματος βλέπουν τα ίδια δεδομένα. Οι ενημερώσεις γίνονται άμεσα σε όλα τα αντίγραφα και είναι διαθέσιμα για ανάγνωση μέχρι την επόμενη ενημέρωση. Σε περιπτώσεις σφαλμάτων επικοινωνίας κόμβων το σύστημα δεν είναι διαθέσιμο μέχρι την αποκατάσταση του προβλήματος. Για να εξασφαλίσουμε strong consistency πρέπει W+R>N. Ο αριθμός των αντιγράφων που γράφονται σε ένα write και ο αριθμός των αντιγράφων που διαβάζονται σε ένα read είναι αρκετά μεγάλος ώστε να επικαλύπτονται. Έτσι υπάρχει εγγύηση ότι θα διαβαστεί αντίγραφο που περιέχει τα ενημερωμένα δεδομένα με την τελευταία έκδοση. Eventual Consistency Σε αυτό το μοντέλο εξασφαλίζεται ότι μετά το πέρας ενός χρονικού διαστήματος δεν γίνονται άλλες ενημερώσεις. Υπάρχει μια περίπτωση ασυνέπειας, ένα διάστημα που μπορεί να διαβαστούν παλαιότερες εκδόσεις δεδομένων αφού δεν ενημερώθηκε ακόμα ο κόμβος. Σε περίπτωση αστοχίας ή προβλημάτων επικοινωνίας των κόμβων η βάση συνεχίζει να είναι διαθέσιμη. Σε σύστημα με τέτοια συνέπεια ισχύει R+W N. Τέτοιες υπηρεσίες με eventual consistency, συχνά χαρακτηρίζονται ως παροχή BASE (Basically Available, Soft State, Eventual Consistency) σημασιολογικά, σε αντίθεση με τις παραδοσιακές ACID. Η eventual consistency μερικές φορές επικρίθηκε, αυξάνοντας την πολυπλοκότητα των κατανεμημένων εφαρμογών. Αυτό είναι εν μέρει επειδή εγγυάται ζωντάνια (όλοι θα δουν κάποια τιμή) αλλά δεν εγγυάται ασφάλεια. Το είδος της εφαρμογής και η σημαντικότητα του θα καθορίσουν την τελική συμπεριφορά για την συνέπεια του συστήματος Θεώρημα CAP O Eric Brewer το 2000 σε ένα συμπόσιο για τα κατανεμημένα υπολογιστικά συστήματα έκανε μια εικασία σχετικά με τα trade-offs που πρέπει να ληφθούν στην ανάπτυξη ενός κατανεμημένου συστήματος δεδομένων [6]. Στην συνέχεια, από τους Seth Gilbert και Nancy Lynch ήρθε η απόδειξη που δημοσιεύθηκε ως CAP Τheorem [29]. Σύμφωνα με αυτό το θεώρημα μόνο δύο ιδιότητες από τις Consistency, Availability και Partition Tolerance μπορούν να ικανοποιούνται ταυτόχρονα. 27

42 NoSQL Βάσεις Δεδομένων Συνέπεια (Consistency) Όλοι οι κόμβοι του συστήματος θα βλέπουν την ίδια χρονική στιγμή τα ίδια δεδομένα, ώστε ο καθένας που χρησιμοποιεί το σύστημα θα πάρει τα τελευταία στοιχεία. Διαθεσιμότητα (Availability) Όλοι μπορούν να βρουν κάποιο αντίγραφο των δεδομένων, ακόμη και αν υπάρχει αποτυχία υλικού σε κάποιους κόμβους. Το σύστημα είναι πάντα ενεργό και σταματά από ελάχιστα έως καθόλου για ανανεώσεις και συντήρηση. Ανοχή κατανομής (Partition Tolerance) Το σύστημα συνεχίζει να λειτουργεί ως σύνολο, ακόμη και αν η επικοινωνία με ένα διακομιστή έχει προσωρινά χαθεί. Δεν πέφτει όλο το σύστημα επειδή προκλήθηκε πρόβλημα σε ένα σημείο του. Ένα σύστημα για να είναι κατανεμημένο πρέπει σίγουρα να ικανοποιεί Partition Tolerance. Έτσι πρέπει να ο σχεδιαστής να επιλέξει ανάμεσα στην συνέπεια και την διαθεσιμότητα. Σχήμα 3.1 Το τρίγωνο CAP με παραδείγματα συστημάτων Στα επόμενα κεφάλαια και κατά την πειραματική αξιολόγηση χρησιμοποιούνται οι NoSQL βάσεις δεδομένων HBase και το Neo4j. Η HBase είναι consistence και partition tolerance ενώ το Neo4j είναι consistence και available αφού δεν κατανέμει σε κόμβους τα δεδομένα. Φυσικά υπάρχει λειτουργία Neo4j High Availability η οποία προσφέρει σε κόμβους την δυνατότητα να έχουν τα ίδια δεδομένα (replicate data) που έχουν οι υπόλοιποι και όλοι να επιδέχονται ενημερώσεις και εγγραφές. Έτσι κατά ένα τρόπο ικανοποιείται και το partition tolerance Είδη NoSQL βάσεων δεδομένων Υπάρχουν διάφορες προσεγγίσεις για την κατηγοριοποίηση των NoSQL βάσεων δεδομένων, η καθεμιά με διαφορετικές κατηγορίες και υποκατηγορίες. Λόγω της ποικιλίας των προσεγγίσεων 28

43 NoSQL Βάσεις Δεδομένων και των επικαλύψεων είναι δύσκολο να υπάρξει και να διατηρηθεί μια τελική. Παρόλα αυτά, η βασική κατάταξη που οι περισσότεροι θα συμφωνήσουν βασίζεται στο μοντέλο δεδομένων [4]. Document store Στις document-οriented βάσεις τα δεδομένα αποθηκεύονται σε αρχεία με κάποιο συγκεκριμένο μοτίβο και όχι σχηματίζοντας πίνακες. Τα αρχεία μπορούν να είναι XML, JSON, BSON και άλλα. Κάθε αρχείο έχει ένα μοναδικό κλειδί γνωστό ως Universal Unique Identifier (UUID) που παράγεται αυτόματα χωρίς να επιτρέπει την ύπαρξη αρχείων σε διαφορετικά σημεία του κατανεμημένου συστήματος με ίδιo αναγνωριστικό. Οι προσθήκες εγγραφών και πεδίων στα αρχεία δεν επηρεάζουν τα υπόλοιπα αρχεία. Χαρακτηριστικά παραδείγματα τέτοιων βάσεων είναι οι MongoDB και CouchDB. Key-Value store Είναι ο τρόπος αποθήκευσης σε μορφή ζευγαριών κλειδιού-τιμής. Στην τιμή αποθηκεύονται δεδομένα σε μορφή αντικειμένων και άλλων τύπων δεδομένων. Επιτρέπουν στις εφαρμογές να αποθηκεύουν με ένα schema-less τρόπο. Χαρακτηριστικά παραδείγματα τέτοιων βάσεων είναι οι Dynamo, Riak, Redis, Cache, Project Voldemort. Column-Oriented store Σε αυτές τις βάσεις τα δεδομένα αποθηκεύονται στου πίνακες κατά στήλες και οι γραμμές προσπελαύνονται με το κλειδί. Κάθε γραμμή δεν έχει αναγκαία τα ίδια πεδία με τις υπόλοιπες. Χαρακτηριστικά παραδείγματα τέτοιων βάσεων είναι οι BigTable, HBase, Accumulo. Graph Database Οι graph βάσεις σχεδιάστηκαν για δεδομένα που μπορούν να αναπαρασταθούν καλύτερα με την μορφή γράφων. Αποτελείται από κόμβους και σχέσεις που μπορούν να έχουν χαρακτηριστικά και επιδέχονται indexing. Δεν απαιτούν πολύπλοκα joins και δεν απαιτούν αυστηρό schema. Χαρακτηριστικά παραδείγματα τέτοιων βάσεων είναι οι Neo4J, Allegro, Virtuoso. Παρόλα αυτά μεταξύ τους κάποιες έχουν μικρές επικαλύψεις στην λογική, που κάνουν την κατηγοριοποίηση να επιδέχεται επιείκεια στον τρόπο που αναφερόμαστε σε αυτές. Όπως για παράδειγμα η HBase όπου ακολουθεί Key-Value λογική όσον αφορά στον τρόπο που προσπελαύνονται τα δεδομένα με το Key να αποτελείται, μεταξύ άλλων, σε αυτή την περίπτωση από το κλειδί της γραμμής, την οικογένεια στήλης και την υποστήλη. Αυτή η συμπεριφορά δεν μας απαγορεύει να αναφερόμαστε σε αυτήν ως Key-Value. 3.2 HBase (Column-Oriented DB) H HBase [12][15][20] είναι ένα project της Apache το οποίο είναι ένα κατανεμημένο, επεκτάσιμο αποθηκευτικό σύστημα που τρέχει πάνω από το HDFS. Η HBase σχεδιάστηκε με βάση το πρότυπο της Google BigTable [8],που παρουσιάστηκε το 2006, και παρέχει την δυνατότητα για 29

44 NoSQL Βάσεις Δεδομένων την αποθήκευση σε τεράστιους πίνακες (δισεκατομμυρίων γραμμών και εκατομμυρίων στηλών) με πολύ γρήγορη πρόσβαση. Πρόκειται για ένα κατανεμημένο σύστημα αποθήκευσης δομημένων δεδομένων, το οποίο είναι κατάλληλο για αραιά δεδομένα τα οποία είναι πολύ κοινά σε περιπτώσεις χρήσης big data. Σε αντίθεση με τις σχεσιακές βάσεις δεδομένων η HBase δεν υποστηρίζει κάποια γλώσσα για δομημένα ερωτήματα (queries) όπως η SQL καθώς δεν είναι καθόλου σχεσιακή βάση δεδομένων. Οι εφαρμογές της HBase γράφονται κυρίως σε Java. Η HBase αποτελείται από ένα σύνολο πινάκων με τα δεδομένα να υποστηρίζουν διαφορετικές εκδόσεις. Κάθε πίνακας περιέχει γραμμές και στήλες, αλλά τα δεδομένα αποθηκεύονται με τρόπο προσανατολισμένο στις στήλες και όχι στις γραμμές. Ο χρήστης έχει τη δυνατότητα να τροποποιεί δυναμικά το μοντέλο και τη μορφή των δεδομένων. Ο αριθμός και τα ονόματα των στηλών, καθώς και ο τύπος των δεδομένων κάθε στήλης δεν προκαθορίζονται κατά την κατασκευή του πίνακα. Στην HBase δεν υποστηρίζονται joins μεταξύ πινάκων. Αυτό όμως μπορεί προγραμματιστικά να υποστηριχθεί αν γραφούν τα κατάλληλα προγράμματα από τον προγραμματιστή Αρχιτεκτονική της HBase Η αρχιτεκτονική της HBase μοιάζει με αυτή του HDFS. Το σύστημα αποτελείται από έναν Master Server (HMaster) και έναν αριθμό από Region Servers (HRegionServer), οι οποίοι εκτελούνται στους διαφορετικούς κόμβους του cluster. HMaster Είναι υπεύθυνος για τον έλεγχο των HRegionServers που υπάρχουν στο cluster, και είναι η διασύνδεση για την αποθήκευση των αλλαγών στα μεταδεδομένα. Σε ένα κατανεμημένο cluster συνήθως τρέχει στο μηχάνημα που αντιπροσωπεύει τον NameNode. Αν τρέχει σε ένα περιβάλλον με πολλούς masters, όλοι ανταγωνίζονται για το ποιος θα πάρει τον έλεγχο του cluster. Εάν ο ενεργός master χάσει την μίσθωση του Zookeeper [28] (ή ο master τερματίσει την λειτουργία του), στη συνέχεια, οι υπόλοιποι masters προσπαθούν να αναλάβουν τον ρόλο του ενεργού. Ακόμα, ο HMaster εκτελεί τις απαραίτητες διαδικασίες προκειμένου να υπάρχει ομοιόμορφη κατανομή του φόρτου στους διάφορους κόμβους του συστήματος καθώς επίσης είναι υπεύθυνος για την διαχείριση αστοχιών των Region Servers και τον διαχωρισμό των regions. HRegionServers Είναι υπεύθυνοι για την διαχείριση και την εξυπηρέτηση των regions. Σε ένα κατανεμημένο cluster συνήθως τρέχει στα μηχανήματα που αντιπροσωπεύουν τους DataNodes. Είναι υπεύθυνοι για την αποθήκευση, διαχείριση και ανάκτηση των δεδομένων μετά από κάποιο αίτημα του χρήστη ή κατά την διαδικασία του load balancing. Για το συγχρονισμό των διαφόρων ενεργειών πάνω στα δεδομένα, την αποθήκευση σημαντικών πληροφοριών (π.χ. το schema) και την ανακάλυψη νέων RegionServers, η HBase απαιτεί την ύπαρξη του ZooKeeper [28]. Όπως φαίνεται και στο παρακάτω σχήμα 3.2, οι HRegionServers χρησιμοποιούν το HDFS για την αποθήκευση των δεδομένων τους. 30

45 Table NoSQL Βάσεις Δεδομένων Σχήμα 3.2 Η αρχιτεκτονική της HBase και ο τρόπος σύνδεσης με το HDFS Regions Τα regions είναι το βασικό στοιχείο της διαθεσιμότητας και της κατανομής για τους πίνακες, και αποτελούνται από ένα Store per Column Family. Η ιεραρχία των αντικειμένων είναι ως εξής: Region Store MemStore StoreFile (HFile) Block Σχήμα 3.3 Ιεραρχία αρχείων region ενός πίνακα Η λογική πίσω από αυτή την ιεραρχία είναι ότι κάθε πίνακας έχει πολλά regions, με store για κάθε ColumnFamily για κάθε region του πίνακα και με τα υπόλοιπα που ακολουθούν να είναι για κάθε ένα από τα προηγούμενα της ιεραρχίας. Όταν η HBase ξεκινά ο master κοιτάει τα προϋπάρχων regions που είναι στα metadata του. Αν ο RegionServer είναι διαθέσιμος η ανάθεση των region που του είχαν είδη ανατεθεί συνεχίζει να ισχύει αλλιώς ανατίθεται με βάση τον εξισορροπιστή σε κάποιον RegionServer και αποθηκεύονται οι αλλαγές στα μεταδεδομένα. Όπως και με το HDFS ισχύει και εδώ η αντιγραφή των regions και σε άλλους κόμβους του cluster για τις περιπτώσεις αστοχίας του υλικού. Σε περίπτωση διαχωρισμού κάποιου region ο RegionServer είναι αυτός που αναλαμβάνει την διαδικασία. Το region πηγαίνει offline, γίνεται 31

46 NoSQL Βάσεις Δεδομένων split, τοποθετείται στα metadata το καινούργιο region, ξεκινά τα νέα regions και μετά ενημερώνει τον master για τον διαχωρισμό. To Store φιλοξενεί ένα MemStore και μηδέν ή περισσότερα StoreFiles (HFiles). Ένα Store αντιστοιχεί σε ένα column family για ένα table για ένα δεδομένο region. Το MemStore περιέχει τις αλλαγές σε μορφή key-value του Store. Στο StoreFile (HFile) είναι το σημείο που είναι πραγματικά τα δεδομένα τα οποία είναι χωρισμένα σε Blocks. Η κλάση KeyValue είναι η καρδιά του συστήματος αποθήκευσης στην HBase. Η KeyValue περικλείει ένα byte array για να γίνεται ερμηνεία του περιεχομένου ως Key-Value. Ένα key-value εσωτερικά ενός byte array περιέχει το μήκος του κλειδιού (keylength), το μήκος της τιμής (valuelength), το κλειδί (key) και την τιμή (value). Το κλειδί με την σειρά του διαχωρίζεται στο μήκος του κλειδιού (rowlength), στο κλειδί της γραμμής (rowkey), στο μήκος της οικογένεια στηλών (columnfamilylength), στο όνομα της οικογένειας στηλών (columnfamily), στο αναγνωριστικό της στήλης (columnqualifier), στο timestamp, λόγω της υποστήριξης εκδόσεων και στον τύπο του κλειδιού (keytype). Τα KeyValue δεν διαχωρίζονται ανάμεσα σε blocks ανεξαρτήτου μεγέθους Μοντέλο δεδομένων Το μοντέλο αυτό προέκυψε αναλύοντας τις ανάγκες αποθήκευσης δεδομένων της Google, και πιο συγκεκριμένα με σκοπό την αποθήκευση διάφορων πληροφοριών για ένα μεγάλο αριθμό ιστοσελίδων του διαδικτύου. Το μοντέλο βρήκε χρήση και εφαρμογή και από άλλες εταιρίες όπως η Facebook που χρησιμοποιεί την HBase για το σύστημα διαχείριση των μηνυμάτων των χρηστών. Σύμφωνα με το μοντέλο δεδομένων που περιγράφεται από τους δημιουργούς του BigTable [8], το οποίο ακολουθήθηκε κατά την ανάπτυξη της HBase, τα συστήματα αυτά αποθηκεύουν τα δεδομένα αραιά, κατανεμημένα και ταξινομημένα. Για την ταχύτερη πρόσβαση στα δεδομένα τα συστήματα αυτά διαθέτουν ευρετήριο όχι μόνο για τις γραμμές, αλλά και για τις στήλες, καθώς και τις διαφορετικές εκδόσεις των δεδομένων του χάρτη. Στο παρακάτω σχήμα παρουσιάζεται γραφικά η μορφή μιας γραμμής στην HBase ώστε να γίνει περισσότερο κατανοητή η ανάλυση που ακολουθεί: Σχήμα 3.4 Παράδειγμα γραμμής ενός πίνακα στην HBase 32

47 NoSQL Βάσεις Δεδομένων Πίνακας (HTable) Η HBase οργανώνει τα δεδομένα σε πίνακες. Τα ονόματα των πινάκων είναι strings που αποτελούνται από χαρακτήρες που είναι ασφαλείς να χρησιμοποιηθούν σε ένα file system path. Γραμμή (Row) Μέσα σε ένα πίνακα τα δεδομένα αποθηκεύονται ανάλογα με την γραμμή τους. Κάθε γραμμή δεδομένων περιέχει ένα μοναδικό κλειδί, το rowkey. Στο παράδειγμα, το κλειδί γραμμής είναι το «com.cnn.www». Η HBase διατηρεί τις γραμμές σε λεξικογραφική σειρά με βάση το κλειδί τους. Το διάστημα τιμών του κλειδιού διαιρείται σε ανεξάρτητα τμήματα τα οποία μοιράζονται στους RegionServers, ώστε να κατανεμηθεί το φορτίο στους διαφορετικούς κόμβους του συστήματος. Οικογένεια Στηλών (Column Family) Οι στήλες μιας γραμμής ομαδοποιούνται σε υπερσύνολα, τα «column families». Όλες οι στήλες μιας οικογένειας στήλης έχουν το ίδιο πρόθεμα. Για παράδειγμα, οι στήλες family_name:qualifier1 και family_name:qualifier2 είναι μέλη της οικογένειας στηλών family_name. Το πρόθεμα της οικογένειας στηλών πρέπει να αποτελείται από εκτυπώσιμους χαρακτήρες. Οι στήλες μιας column family μπορούν να έχουν οποιοδήποτε όνομα, το οποίο ονομάζεται qualifier. Στο παράδειγμα, έχουμε δύο column families, τις «content» και «anchor», ενώ η «anchor» περιέχει για την συγκεκριμένη γραμμή δύο στήλες με qualifiers τα «cnnsi.com» και «my.look.ca» αντίστοιχα. Οι οικογένειες στηλών πρέπει να δηλώνονται εκ των προτέρων κατά το χρόνο ορισμού του σχήματος της βάσης, ενώ οι στήλες δεν χρειάζεται να καθορισθούν από πριν. Όλα τα μέλη της οικογένειας στηλών αποθηκεύονται μαζί στο σύστημα αρχείων. Κελιά (Cells) Κάθε κελί της HBase προσδιορίζεται μονοσήμαντα από την πλειάδα {row, column, version} και περιέχει έναν πίνακα από bytes. Εκδόσεις (Versions) Η HBase παρέχει τη δυνατότητα αποθήκευσης στο ίδιο column μίας γραμμής να αποθηκευτούν περισσότερες εκδόσεις των δεδομένων, χρησιμοποιώντας όμως διαφορετικό timestamp. Η αποθήκευση στη διάσταση της έκδοσης γίνεται με φθίνουσα σειρά ως προς το timestamp, ώστε να ανακτώνται πρώτα τα πιο πρόσφατα δεδομένα. Στο παραπάνω παράδειγμα, παρατηρούμε ότι η στήλη «contents:» περιέχει τρεις διαφορετικές εκδόσεις των δεδομένων, τις t6, t5 και t Client API Διεπαφή για προγραμματιστή Οι βασικές υποστηριζόμενες λειτουργίες για το μοντέλο δεδομένων που ακολουθεί η HBase είναι η Get, Put, Scans και Delete. H Get επιστρέφει τα γνωρίσματα μιας συγκεκριμένης γραμμής ενώ το Scan επιτρέπει κινήσεις σε πολλαπλές γραμμές για συγκεκριμένα γνωρίσματα. Με το Put εισάγονται νέες γραμμές ή ενημερώνονται αυτές που υπάρχουν είδη. Η Delete διαγράφει μία γραμμή του πίνακα. Τα αποτελέσματα των λειτουργιών επιστρέφονται σε ταξινομημένη σειρά, πρώτα ανά γραμμή, μετά ανά ColumnFamily. 33

48 NoSQL Βάσεις Δεδομένων Η HBase υποστηρίζει φίλτρα (Filters) που υποβοηθούν αρκετές φορές, τόσο προγραμματιστικά όσο και αποδοτικά, στις διαδικασίες που αφορούν τα δεδομένα. Από την HBase παρέχονται ήδη κάποια προκαθορισμένα φίλτρα αλλά δίνεται η δυνατότητα από το framework για προγραμματισμό άλλων από τους προγραμματιστές. Με την χρήση των φίλτρων μπορούν να οριοθετηθούν τα αποτελέσματα που επιστρέφουν οι Get και Scan. Όλα αυτά αναφέρονται στα column families, column qualifiers, timestamps ή στα ranges, μέχρι και στον αριθμό των εκδόσεων. Υπάρχουν φίλτρα που κάνουν include ή exclude στα δεδομένα που θα επιστραφούν. Στα φίλτρα μπορούν να χρησιμοποιηθούν συγκριτικοί τελεστές ισότητας, ανισότητας, μεγαλύτερου και μικρότερου. Οι τελεστές μπορούν να εφαρμοστούν σε οποιαδήποτε δεδομένα και να χρησιμοποιούνται συγκριτές δυαδικοί, για υποσυμβολοσειρές μέχρι και συγκριτές με χρήση regular expressions. Άλλη προηγμένη λειτουργία προς τους χρήστες είναι οι μετρητές (Counters). Πολλές εφαρμογές που συλλέγουν στατιστικά, όπως χτυπήματα ή εμφανίσεις διαφημίσεων, που πριν χρησιμοποιούσαν logfiles που θα αναλύονταν αργότερα έχουν την δυνατότητα να χρησιμοποιούν σε πραγματικό χρόνο τα δεδομένα. Ο μηχανισμός αυτός, χειρίζεται τα columns σαν counters. Σε αντίθετη περίπτωση θα έπρεπε να κλειδωθεί η γραμμή, να διαβαστεί η τιμή, στην συνέχεια να αυξηθεί, να αποθηκευτεί και να ξεκλειδωθεί η γραμμή ώστε να είναι διαθέσιμη στους υπόλοιπους χρήστες. Αυτό θα μπορούσε να προκαλέσει προβλήματα σε συστήματα με υψηλό φόρτο, με πολλές γραμμές να έμεναν κλειδωμένες Βασικά χαρακτηριστικά HBase Κατανεμημένη αποθήκευση και πρόσβαση στα δεδομένα Η HBase προσφέρει κατανεμημένη αποθήκευση και πρόσβαση στα δεδομένα. Διαιρώντας το σύνολο των κλειδιών ενός πίνακα σε ανεξάρτητα τμήματα και αναθέτοντας κάθε τμήμα σε ξεχωριστό RegionServer, η HBase εξασφαλίζει την κατανομή του φόρτου στους κόμβους του συστήματος που γίνεται όσο πιο ομοιόμορφα γίνεται. Με τη δημιουργία αντιγράφων από το HDFS εξασφαλίζεται η ανοχή του συστήματος σε σφάλματα και φυσικά υπάρχει η δυνατότητα διαμοιρασμού του φόρτου αναγνώσεων μεταξύ των κόμβων ώστε η εξυπηρέτηση να γίνεται απρόσκοπτα. Μοντέλο αραιής αποθήκευσης των δεδομένων Η HBase παρέχει ένα μοντέλο αραιής αποθήκευσης των δεδομένων. Κάθε γραμμή μπορεί να αποτελείται από έναν οποιοδήποτε αριθμό στηλών και να έχει εντελώς διαφορετική δομή από την προηγούμενη. Για το λόγο αυτό, είναι απαραίτητη η δημιουργία ευρετηρίων και ως προς τις στήλες, για την γρήγορη αναζήτηση ενός στοιχείου του πίνακα. Αυτή είναι ίσως η σημαντικότερη διαφορά της HBase σε σχέση με τα παραδοσιακά συστήματα βάσεων δεδομένων και έτσι καθιστάτε κατάλληλη για την αποθήκευση δεδομένων των οποίων η δομή δεν είναι απόλυτα προκαθορισμένη. 34

49 NoSQL Βάσεις Δεδομένων Ανοχή στα σφάλματα του υλικού Χρησιμοποιώντας το HDFS για την αποθήκευση των δεδομένων που διαχειρίζεται, η HBase κληρονομεί τη δυνατότητα να αντιμετωπίζει σφάλματα στο υλικό, τα οποία είναι ιδιαίτερα συνηθισμένα όταν χρησιμοποιείται εμπορικό υλικό και το πλήθος των μηχανημάτων και των δίσκων είναι αρκετά μεγάλο. Με τη δημιουργία αντιγράφων η HBase έχει τη δυνατότητα να ανακτά τα δεδομένα ακόμα και όταν κάποιοι κόμβοι του συστήματος δεν μπορούν να χρησιμοποιηθούν για οποιαδήποτε λόγο Άλλες λειτουργίες και εργαλεία Αυτόματη επεκτασιμότητα Το βασικό στοιχείο επεκτασιμότητας και εξισορρόπησης των δεδομένων στην HBase είναι το region. Τα regions δυναμικά διαιρούνται, από το σύστημα, όταν γίνονται πολύ μεγάλα. Επίσης μπορεί να συγχωνευθούν για να μειώσουν τον αριθμό τους και τον απαιτούμενο αριθμό αρχείων. Αρχικά υπάρχει μόνο ένα region κατά την δημιουργία του πίνακα και το σύστημα κατά την εισαγωγή δεδομένων ελέγχει ώστε να μην ξεπεραστεί το μέγιστο μέγεθος τους. Συμπίεση Η HBase δεν διαγράφει τα δεδομένα άμεσα, όταν αυτό ζητηθεί, αλλά τα σημαδεύει με ένα tombstone. Αυτά τα tombstones, μαζί με τις διαγραμμένες τιμές διαγράφονται μετά από μία μεγάλη συμπίεση. Υπάρχουν δύο τύποι συμπίεσης, η μικρότερη (minor) και η μεγαλύτερη (major). Η minor συμπίεση συνήθως παίρνει κάποια μικρότερα γειτονικά StoreFiles και τα ξαναγράφει σαν ένα. Οι μικρές συμπιέσεις δεν διαγράφουν τα διαγραμμένα ή τα ληγμένα cells. Κάποιες φορές μια μικρή συμπίεση παίρνει όλα τα StoreFiles από το Store και σε αυτή την περίπτωση αναβαθμίζεται σε μεγάλη συμπίεση. Αφού γίνει μια μεγάλη συμπίεση, θα υπάρχει μόνο ένα StoreFile σε κάθε Store, και αυτό βοηθά συνήθως στην απόδοση. Οι μεγάλες συμπιέσεις ξαναγράφουν όλα τα δεδομένα και αυτό σε ένα σύστημα που τρέχει και αυτό ίσως το σύστημα να μην μπορεί να το υποστηρίξει. Αυτό οδηγεί τις μεγάλες συμπιέσεις να πρέπει να γίνουν χειροκίνητα σε μεγάλα συστήματα. Οι συμπιέσεις δεν πραγματοποιούν συνένωση regions. Υποστήριξη MapReduce (Bulk Loading) Ένα από τα σημαντικότερα χαρακτηριστικά της HBase είναι η στενή σύνδεση με το Hadoop MapReduce framework. Η HBase περιέχει αρκετούς τρόπους για την εισαγωγή δεδομένων στους πίνακες. Στο API του MapReduce υπάρχει η υποστήριξη ώστε η πηγή ή η έξοδος των δεδομένων μιας εργασίας MapReduce να είναι ένας πίνακας της HBase. Είναι επίσης δυνατό μια εργασία να έχει τόσο την είσοδο όσο και την έξοδο της, την HBase. Αυτό γίνεται κατά το configuration της εργασίας για τον τύπο της εισόδου και της εξόδου. Ωστόσο, δεν είναι πάντα ο πιο αποδοτικός τρόπος αλλά είναι ο πιο κοινός τρόπος. Το bulk load χρησιμοποιεί μία MapReduce εργασία για να εξάγει τον πίνακα σε format όπως είναι εσωτερικά ένας πίνακας της HBase, και στην συνέχεια φορτώνει απευθείας τα παραχθέντα StoreFiles σε ένα cluster που τρέχει. Η χρήση 35

50 NoSQL Βάσεις Δεδομένων του bulk load έχει ως αποτέλεσμα την λιγότερη χρήση της CPU και λιγότερο φορτίο στο δίκτυο από την χρήση του HBase API. Η διαδικασία του HBase bulk load έχει δύο βασικά βήματα. Αρχικά τα δεδομένα πρέπει να προετοιμαστούν μέσω μιας MapReduce εργασίας όπως προανέφερα. Για να υπάρχει αποτελεσματικότητα θα πρέπει κάθε αρχείο εξόδου (HFile) να χωράει σε ένα region. Για να γίνει αυτό, και να μην υπάρχει πρόβλημα στο bulk loading, θα πρέπει να χρησιμοποιηθεί o TotalOrderPartitioner του Hadoop για να κατανεμηθούν οι έξοδοι των maps σε μη επικαλυπτόμενα εύρη του χώρου των κλειδιών, αντίστοιχα του εύρους των κλειδιών των regions του πίνακα. Το δεύτερο βήμα είναι η ολοκλήρωση του ανεβάσματος των δεδομένων. Με την εκτέλεση της εντολής τερματισμού του bulk load, για το κάθε προετοιμασμένο αρχείο, καθορίζεται το region στο οποίο ανήκει το αρχείο. Στην συνέχεια, επικοινωνεί με τον κατάλληλο Region Server και υιοθετεί το HFile, μεταφέροντας τον στον χώρο αποθήκευσης και κάνει τα δεδομένα διαθέσιμα στους χρήστες. Αν τα όρια των region άλλαξαν κατά την διάρκεια της προετοιμασίας του bulk load ή στα στάδια μεταξύ της προετοιμασίας και της ολοκλήρωσης, το εργαλείο της ολοκλήρωσης του bulk load θα σπάσει αυτόματα τα αρχεία δεδομένων ώστε να ανταποκρίνονται στα νέα όρια που τέθηκαν. Αυτή η διαδικασία δεν είναι βελτιστοποιημένη, έτσι οι χρήστες θα πρέπει να φροντίσουν να ελαχιστοποιούν την καθυστέρηση μεταξύ της προετοιμασίας και του ανεβάσματος στο cluster, ειδικά αν υπάρχουν και άλλοι χρήστες που ανεβάζουν δεδομένα μέσω άλλων τρόπων. Αξίζει να αναφερθεί ότι αν δεν υπάρχει ήδη ο πίνακας στην HBase τότε θα κατασκευαστεί αυτόματα. Η όλη λειτουργία τρέχει γρήγορα και στο τέλος τα νέα δεδομένα θα είναι διαθέσιμα στο cluster. To bulk load γίνεται είτε προγραμματιστικά είτε από το έτοιμο εργαλείο που διατίθεται. Time To Live (TTL) Οι ColumnFamilies μπορούν να έχουν λήξη. Αυτό γίνεται με τον ορισμό του TTL σε δευτερόλεπτα, και η HBase αυτόματα θα διαγράψει τις γραμμές όταν περάσει ο χρόνος λήξης. Αυτό έχει εφαρμογή σε όλες τις εκδόσεις δεδομένων μιας γραμμής. Διεπαφή Web Η HBase παρέχει ένα web interface για τον Master και κάθε ένα Region Server. To Web UI του master περιέχει μια λίστα με τους υπάρχον πίνακες και τους ορισμούς τους (π.χ. ColumnFamilies, blocksize, κτλ.). Επιπλέον περιέχει λίστα με τους διαθέσιμους RegionServers στο cluster, μαζί με επιλεγμένες μετρικές υψηλού επιπέδου (requests, αριθμός regions, usedheap, maxheap). Το web UI του Master επιτρέπει την πλοήγηση σε κάθε ένα web UI των RegionServers. Το web UI ενός RegionServer περιέχει μια λίστα με τα διαθέσιμα regions και τα κλειδιά έναρξης και τέλους, καθώς και μετρικές του RegionServer (requests, regions, storefileindexsize, compactionqueuesize, κλπ.). 36

51 NoSQL Βάσεις Δεδομένων HBase Shell Το HBase προσφέρει ένα shell που μπορούμε να εκτελέσουμε με την εντολή bin/hbase shell. Μερικές χρήσιμες εντολές είναι οι παρακάτω: help: Χρησιμοποιώντας την παρέχονται πληροφορίες για όλες τις άλλες εντολές. create: Δημιουργεί ένα νέο πίνακα. Η εντολή «create 'table','cf1',cf2'» δημιουργεί ένα νέο πίνακα με δύο Column Families, τις cf1 και cf2. list: Εκτυπώνει μία λίστα από όλους τους διαθέσιμους πίνακες στο σύστημα. scan: Επιστρέφει αποτελέσματα από τον πίνακα. Η εντολή «scan 'table', {COLUMNS=>'cf1', LIMIT=>10}» επιστρέφει από το πίνακα 'table' τα δέκα πρώτα αποτελέσματα της Column Family 'cf1'. disable/enable: Με αυτές τις εντολές απενεργοποιούμε και ενεργοποιούμε έναν πίνακα. Δεν μπορεί να πραγματοποιηθεί μία εντολή αλλαγής των ιδιοτήτων του πίνακα αν δεν απενεργοποιηθεί πρώτα. drop: Διαγράφει έναν πίνακα από το σύστημα. truncate: Πρακτικά διαγράφει όλα τα στοιχεία του πίνακα. 3.3 Neo4j (Graph DB) Κατά την πρώτη δεκαετία της νέας χιλιετίας έχουν εμφανιστεί αρκετές επιχειρήσεις που άλλαξαν τον κόσμο, όπως το Google, το Facebook και το Twitter. Και υπάρχει ένα κοινό νήμα μεταξύ τους. Βάζουν ως κέντρο της επιχείρησης τους συνδεδεμένα δεδομένα. Μετά από 15 χρόνια οι γράφοι είναι πλέον παντού. Το Facebook, για παράδειγμα, ιδρύθηκε στην ιδέα ότι, ενώ υπάρχει αξία στις πληροφορίες για τους ανθρώπους, τα ονόματά τους, τι κάνουν, κλπ. υπάρχει ακόμη μεγαλύτερη αξία στις σχέσεις μεταξύ τους. Ο ιδρυτής του Facebook, Mark Zuckerberg, έχτισε μια αυτοκρατορία σαν εικόνα για να απεικονίσει αυτές τις σχέσεις στο κοινωνικό γράφημα. Ομοίως, οι Larry Page και Sergey Brin της Google έχουν βρει τον τρόπο να αποθηκεύουν και να επεξεργάζονται όχι μόνο διακριτά έγγραφα ιστού, αλλά και το πώς συνδέονται τα εν λόγω έγγραφα στο διαδίκτυο. Η Google απεικόνισε τον γράφο του Web. Σχεδόν άγνωστες πριν από μερικά χρόνια, οι graph βάσεις δεδομένων τώρα χρησιμοποιούνται σε βιομηχανίες τόσο διαφορετικές όπως η υγειονομική περίθαλψη, το λιανικό εμπόριο, το πετρέλαιο και το φυσικό αέριο, τα μέσα ενημέρωσης, σε παιχνίδια και αλλού Γενικά Βάσεων Δεδομένων για Γράφους Ένα σύστημα διαχείρισης βάσεων δεδομένων για γράφους είναι ένα online σύστημα διαχείρισης βάσης δεδομένων με λειτουργίες δημιουργίας, ανάγνωσης, ενημέρωσης και διαγραφής που καθιστούν ένα μοντέλο δεδομένων γράφων. Οι βάσεις δεδομένων για γράφους είναι γενικά χτισμένες για χρήση με συστήματα συναλλαγών (Transactional Systems). Μία graph βάση δεδομένων περιέχει κόμβους (nodes) και σχέσεις (relationships). Οι σχέσεις οργανώνουν τον γράφο, με τους κόμβους να είναι οργανωμένοι σε αυθαίρετες δομές, επιτρέποντας ένα 37

52 NoSQL Βάσεις Δεδομένων γράφημα να αποτελεί μια λίστα, ένα δέντρο, ένα χάρτη ή μια οργανωμένη οντότητα, οι οποίες μπορούν να συνδυαστούν δημιουργώντας πιο περίπλοκες και διασυνδεδεμένες δομές. Υπάρχουν δύο προσεγγίσεις που πρέπει να λαμβάνονται υπόψη κατά την μελέτη των βάσεων δεδομένων για γράφους [13]. 1. Ο υποστηριζόμενος αποθηκευτικός χώρος. Κάποιες graph βάσεις δεδομένων χρησιμοποιούν εγγενή graph αποθηκευτικό χώρο που είναι βελτιστοποιημένος και σχεδιασμένος για την αποθήκευση και τη διαχείριση γράφων. Δεν χρησιμοποιούν όλες οι graph βάσεις δεδομένων εγγενή graph αποθηκευτικό χώρο. Κάποιες σειριοποιειούν τα δεδομένα του γράφου σε μια relational βάση δεδομένων, σε μια object oriented βάση δεδομένων, ή κάποιον άλλο γενικής χρήσης χώρο δεδομένων. 2. Η μηχανή επεξεργασίας. Κάποιοι ορισμοί απαιτούν ότι μια graph βάση δεδομένων δεν χρησιμοποιεί ευρετήρια γειτνίασης, πράγμα που σημαίνει ότι οι συνδεδεμένοι κόμβοι δείχνουν με φυσικό τρόπο μεταξύ τους στο database. Κάθε βάση δεδομένων που από τη σκοπιά του χρήστη συμπεριφέρεται όπως μια Graph βάση δεδομένων (δηλαδή, υποστηρίζει τις λειτουργίες δημιουργίας, ανάγνωσης, ενημέρωσης και διαγραφής) μπορεί να θεωρηθεί ως Graph βάση δεδομένων. Αναγνωρίζοντας τα πλεονεκτήματα στην απόδοση των index-free γειτνιάσεων, και ως εκ τούτου, χρησιμοποιείται ο όρος native graph processing για να περιγραφούν οι graph βάσεις δεδομένων που εκμεταλλεύονται τις index-free γειτνιάσεις. Οι σχέσεις, στο μοντέλο των graph βάσεων δεδομένων, είναι πολίτες πρώτης κατηγορίας, σε αντίθεση με άλλα συστήματα διαχείρισης βάσεων δεδομένων, τα οποίες απαιτούν από τον χρήστη να συμπεράνει τις συνδέσεις μεταξύ των φορέων που χρησιμοποιούν ξένα κλειδιά ή με επεξεργασία δεδομένων με MapReduce. Με τη συναρμολόγηση κόμβων και σχέσεων σε συνδεδεμένες δομές επιτρέπεται να οικοδομηθούν εξελιγμένα μοντέλα που χαρτογραφούνται στενά με το πρόβλημα. Τα προκύπτοντα μοντέλα είναι απλούστερα και ταυτόχρονα πιο εκφραστικά από εκείνα που παράγονται με τη χρήση παραδοσιακών σχεσιακών βάσεων δεδομένων και από άλλα NoSQL συστήματα. 38

53 NoSQL Βάσεις Δεδομένων Σχήμα 3.5 Κατηγοριοποίηση συστημάτων Graph Databases Οι NoSQL βάσεις δεδομένων στερούνται σχέσεων. Οι περισσότερες NoSQL βάσεις δεδομένων key-value store, document store, ή column-oriented store αποθηκεύουν συλλογές από μη συνδεδεμένα αρχεία/τιμές/στήλες. Αυτό τις καθιστά δύσκολο να χρησιμοποιηθούν για συνδεδεμένα δεδομένα και γράφους. Μια γνωστή στρατηγική για την προσθήκη των σχέσεων σε τέτοια συστήματα είναι να ενσωματωθεί στο αναγνωριστικό σε ένα πεδίο που ανήκει σε ένα άλλο αναγνωριστικό-σύνολο, ουσιαστικά πρόκειται για foreignkey. Αλλά αυτό απαιτεί joins στο επίπεδο της εφαρμογής, το οποίο σε κάποιες περιπτώσεις γίνεται απαγορευτικά ακριβό. Οι Graph βάσεις δεδομένων αγκαλιάζουν τις σχέσεις Αυτό που πραγματικά προσφέρεται είναι μια συνεκτική εικόνα του συνόλου, συμπεριλαμβανομένων των συνδέσεων μεταξύ των στοιχείων. Σε αντίθεση με τις περισσότερες NoSQL, στον κόσμο των graph βάσεων, τα συνδεδεμένα δεδομένα αποθηκεύονται ως συνδεδεμένα δεδομένα. Όταν υπάρχουν σχέσεις στο domain, υπάρχουν συνδέσεις και στα δεδομένα Εισαγωγή στο Neo4j Το Neo4j είναι μια εμπορικά υποστηριζόμενη ανοιχτού κώδικα βάση δεδομένων για γράφους [24]. Σχεδιάστηκε και υλοποιήθηκε ώστε να είναι μια αξιόπιστη βάση δεδομένων, βελτιστοποιημένη για δομές γράφων, αντί για πίνακες. Δουλεύοντας με το Neo4j, μία εφαρμογή παίρνει όλη την εκφραστικότητα ενός γράφου, με όλη την αξιοπιστία μιας βάσης δεδομένων. Ως ισχυρή, επεκτάσιμη και υψηλής απόδοσης βάση δεδομένων, το Neo4j είναι κατάλληλο για την πλήρη ανάπτυξη των επιχειρήσεων ή ενός υποσυνόλου του διακομιστή και μπορεί να χρησιμοποιηθεί σε ελαφριά έργα. Το Neo4j διαθέτει ACID συναλλαγές [18], υψηλή διαθεσιμότητα, κλιμάκωση σε δισεκατομμύρια κόμβους και σχέσεις, υψηλή ταχύτητα αναζήτησης μέσω traversals και γλώσσα υποστήριξης 39

54 NoSQL Βάσεις Δεδομένων ερωτημάτων στους γράφους. Η σωστή συμπεριφορά με ACID συναλλαγές είναι το θεμέλιο της αξιοπιστίας των δεδομένων. Το Neo4j επιβάλλει ότι όλες οι πράξεις που τροποποιούν τα δεδομένα που εμφανίζονται σε μια συναλλαγή, εξασφαλίζουν συνεπή δεδομένα. Η ευρωστία αυτή εκτείνεται από χρήση του Neo4j από εγκατάσταση με ενσωμάτωση σε ένα μόνο μηχάνημα μέχρι multi-server εγκαταστάσεις υψηλής διαθεσιμότητας (cluster). H αξιόπιστη αποθηκευτική ικανότητα των γράφων μπορεί εύκολα να προστεθεί σε οποιαδήποτε εφαρμογή. Ένας γράφος μπορεί να επεκταθεί σε μέγεθος και πολυπλοκότητα καθώς η εφαρμογή εξελίσσεται, με μικρό αντίκτυπο στις επιδόσεις της. Είτε ξεκινά η ανάπτυξη νέων εφαρμογών, είτε αυξάνεται η υπάρχουσα λειτουργικότητα, το Neo4j περιορίζεται μόνο από το φυσικό υλικό. Η εγκατάσταση σε ένα μοναδικό μηχάνημα μπορεί να χειριστεί ένα γράφο δισεκατομμυρίων των κόμβων και σχέσεων. Όταν η απόδοση διεκπεραίωσης ερωτημάτων είναι ανεπαρκής, τότε η βάση δεδομένων για γράφους μπορεί να διανεμηθεί (distributed) μεταξύ πολλαπλών εξυπηρετητών για να προσφέρεται υψηλή διαθεσιμότητα. Η αποθήκευση δεδομένων σε γράφους δείχνει τις ικανότητες της κατά την αποθήκευση πλούσια συνδεδεμένων δεδομένων. Τα ερωτήματα γίνονται μέσω πλοήγησης, και μπορούν να εκτελούνται εκατομμύρια traversal ανά δευτερόλεπτο. Ένα βήμα traversal μοιάζει με ένα join σε μία σχεσιακή βάση δεδομένων (RDBMS). Το Neo4j μπορεί να υποστηρίξει περισσότερες από μία βάσεις στο ίδιο μηχάνημα και για όλες να θεωρείται το μηχάνημα αυτό ως server της βάσης Σύγκριση Graph βάσης με Key-Value store Όταν τα δεδομένα σε ένα μοντέλο Key-Value και κατ επέκταση σε μοντέλα που υποστηρίζουν Column-Families, όπως το BigTable και η HBase, τα δεδομένα αφού διασυνδέονται μεταξύ τους, μπορούν να αποθηκευτούν σε ένα μοντέλο βάσης δεδομένων για γράφους. Οι σχέσεις μεταξύ των δεδομένων πλέον γίνονται ξεκάθαρες και ρητές. Στα παρακάτω σχήματα φαίνεται γραφικά αυτή η μεταφορά. Σχήμα 3.6 Αντιστοίχιση από Key-Value Store (αριστερά) σε γράφο (δεξιά) (Κάποια κλειδιά - K* δείχνουν σε άλλα κλειδιά αλλά και τιμές -V*) 40

55 3.3.4 Μοντέλο δεδομένων Neo4j NoSQL Βάσεις Δεδομένων Κόμβοι (Nodes) Μία από τις θεμελιώδεις μονάδες στο Neo4j είναι οι κόμβοι. Οι κόμβοι είναι διαφορετικοί μεταξύ τους και μπορούν να περιέχουν διάφορες ιδιότητες. Οι κόμβοι συνήθως χρησιμοποιούνται για να αντιπροσωπεύουν τις οντότητες της βάσης. Για παράδειγμα, στον γράφο του twitter οι κόμβοι θα μπορούσαν να είναι οι χρήστες, τα μηνύματα, οι επισημάνσεις και τα links. Οι κόμβοι επιδέχονται indexing σε συγκεκριμένα properties, ανάλογα με το είδος τους με βάση την εφαρμογή, από το API του Neo4j. Στο παράδειγμα του twitter, οι κόμβοι που ανήκουν στην κάθε οντότητα θα μπορούσαν να σχηματίσουν ένα ευρετήριο. Σχέσεις (Relationships) Η δεύτερη θεμελιώδεις μονάδα στο Neo4j είναι οι σχέσεις. Οι σχέσεις μεταξύ των κόμβων είναι το ουσιαστικό μέρος μιας βάσης δεδομένων για γράφους. Ακολουθώντας τις σχέσεις βρίσκουμε σχετιζόμενα δεδομένα. Όπως και οι κόμβοι έτσι και οι σχέσεις μπορούν να έχουν διάφορες ιδιότητες. Στον γράφο του twitter, οι σχέσεις θα μπορούσαν να είναι οι σχέσεις μεταξύ των χρηστών με ιδιότητες όπως οι ημερομηνία σύνδεση τους κτλ. Μία σχέση συνδέει δύο κόμβους και είναι εγγυημένο ότι θα έχουν έγκυρους κόμβους έναρξης και προορισμού. Οι σχέσεις είναι πάντα κατευθυνόμενες και μπορούν να θεωρούνται, από το σύστημα, ως προσπίπτουσες ή προσκείμενες από κάποιο κόμβο, που είναι πολύ χρήσιμο κατά την διάσχιση του γράφου. Κάνει ερωτήματα τύπου, «Βρες για κάποιο χρήστη ποιους ακολουθεί», να είναι πιο εύκολα αφού απλά μπορεί να ψάξει τις εξερχόμενες σχέσεις τύπου «follow» από τον κόμβο του χρήστη σε βάθος ένα. Οι σχέσεις, αν χρειάζεται από την εφαρμογή, μπορούν να προσπελαστούν και προς τις δύο πλευρές ανεξαρτήτως κατεύθυνσης. Ένας κόμβος μπορεί να έχει και σχέσεις με τον εαυτό του. Όλες οι σχέσεις έχουν ένα τύπο σχέσης ανεξάρτητο της ετικέτας που φαίνεται σε μια σχηματική αναπαράσταση. Οι σχέσεις επιδέχονται indexing, από το API του Neo4j, σε συγκεκριμένα properties, ανάλογα με το είδος τους με βάση την εφαρμογή. Ιδιότητες (Properties) Οι σχέσεις και οι κόμβοι περιέχουν ιδιότητες. Οι ιδιότητες είναι ζευγάρια Key-Value όπου το κλειδί είναι πάντα μια συμβολοσειρά. Οι τιμές των ιδιοτήτων μπορούν να είναι ότι τύπου δεδομένων ζητείται ή ακόμα να είναι και πίνακες τύπων δεδομένων. Μονοπάτια (Paths) Μονοπάτι είναι ένας ή περισσότεροι συνδεδεμένοι με σχέσεις κόμβοι, οι οποίοι ανακτώνται ως αποτέλεσμα ενός ερωτήματος ή μιας διάσχισης. Αν το αποτέλεσμα είναι μόνο ένα κόμβος το μονοπάτι έχει μήκος μηδέν και αν οι κόμβοι είναι δύο έχει μήκος ένα. Πλοηγοί (Traversal) Traversing ένα γράφο (αλλιώς διάσχιση) σημαίνει επίσκεψη στους κόμβους τους, διασχίζοντας τις σχέσεις ακολουθώντας κάποιους κανόνες. Στις περισσότερες περιπτώσεις μόνο ένας υπόγράφος επισκέπτεται όπου υπάρχουν οι κόμβοι και οι σχέσεις που μας ενδιαφέρουν. Το Neo4j 41

56 NoSQL Βάσεις Δεδομένων API περιέχει ένα framework που μπορούν να οριστούν οι όροι της πλοήγησης. Σε ένα βασικό επίπεδο υπάρχει η επιλογή μεταξύ κατά μήκος ή κατά πλάτος. Επίσης, υπάρχει υποστήριξη για πλοήγηση και δημιουργία ερωτημάτων με χρήση των γλωσσών Cypher ή Germlin Αρχιτεκτονική Neo4j Η αρχιτεκτονική του σχήματος Σχήμα 3.7 περιγράφει εσωτερικά κάθε instance της Neo4j βάσης δεδομένων [13]. Traversal API Core API Cypher Node/Relationship Object Cache File System Cache Record Files Transaction Management Transaction Log Disks Σχήμα 3.7 Αρχιτεκτονική Neo4j Το Neo4j αποθηκεύει τα graph δεδομένα σε ένα πλήθος διαφορετικών αρχείων. Κάθε αρχείο περιέχει τα δεδομένα για κάθε ένα από τα μέρη του γράφου (π.χ. κόμβοι, σχέσεις, ιδιότητες). Record Files Τα Record Files αποτελούνται από τα αρχεία Node store, Relationship store, Relationship type store, Property store, Property key store, (long) String store και (long) Array store. Όλα τα δεδομένα αναπαρίστανται σε διασυνδεδεμένες λίστες με εγγραφές συγκεκριμένου μεγέθους στο δίσκο. Οι ιδιότητες, επίσης αποθηκεύονται και αυτές, σαν συνδεδεμένες λίστες από εγγραφές ιδιοτήτων με το κλειδί και την τιμή του. Κάθε κόμβος και σχέση σχετίζεται με την πρώτη εγγραφή των ιδιοτήτων. Οι κόμβοι επίσης σχετίζονται με τον πρώτο κόμβο στην αλυσίδα των σχέσεων τους. Κάθε σχέση σχετίζεται με τον κόμβο έναρξης και προορισμού. Επίσης σχετίζεται η προηγούμενη εγγραφή σχέσης για τον κόμβο έναρξης και η εγγραφή της επόμενης σχέσης για τον κόμβο προορισμού. Όσον αφορά τις ιδιότητες, οι μικρές συμβολοσειρές και οι πίνακες τιμών αποθηκεύονται στο αρχείο Property store αλλά οι long τιμές αποθηκεύονται στα άλλα ξεχωριστά αρχεία. Node/Relationship Object Cache File System Cache Υπάρχουν δύο επίπεδα μνήμης cache στο Neo4j. Το χαμηλότερο επίπεδο, File System Cache, χρησιμοποιείται για τα Record Files. Περιέχει ένα συγκεκριμένο αριθμό regions για κάθε record file (διαχωρίζει κάθε αρχείο σε αρχεία ίσου μεγέθους). Το υψηλότερο επίπεδο, το Node/Relationship Object Cache, περιέχει μια δομή πιο βελτιστοποιημένη για πλοήγηση. 42

57 NoSQL Βάσεις Δεδομένων Transaction Management Transaction Log Κάθε συναλλαγή αποτελείται από δύο μέρη. Την διαχείριση των αλλαγών που συμβαίνουν και την αποθήκευση της σε ένα αρχείο για περιπτώσεις που χρειάζεται ανάκτηση εξαιτίας διάφορων προβλημάτων που μπορεί να προκύψουν. Traversal API Core API Cypher Από την όψη του χρήστη, το Traversal API εφαρμόζεται πάνω από το Core API και με το Cypher, το οποίο είναι μια γλώσσα υποστήριξης ερωτημάτων, να βρίσκεται πάνω από το Traversal API. Όλα αυτά κατά βάση συμβάλουν στην ανάκτηση δεδομένων από την βάση, με όλα τα υπόλοιπα μέρη της αρχιτεκτονικής που αναφέρθηκαν πιο πάνω να αποτελούν τον πυρήνα Αρχιτεκτονική και λειτουργία Neo4j HA Το Neo4j, εκτός από την εφαρμογή του σε ένα μοναδικό μηχάνημα, προσφέρει και μια υψηλής διαθεσιμότητας κατανεμημένη λύση η οποία είναι διαθέσιμη μόνο στην Neo4j Enterprise Edition. Με τον όρο κατανεμημένη, δεν εννοείται το σπάσιμο και ο διαμοιρασμός του γράφου σε διάφορα μηχανήματα, αλλά η αναπαραγωγή ολόκληρου του γράφου σε όλα τα μηχανήματα του cluster. Αντίθετα με τις προηγούμενες εκδόσεις που χρησιμοποιούσαν Zookeeper [28] στην υλοποίηση, οι πιο πρόσφατες εκδόσεις υποστηρίζουν ένα μοντέλο, χωρίς coordinator, βασισμένο στην εφαρμογή του πρωτοκόλλου Paxos [16]. To Neo4j High Availability ή «Neo4j HA» έχει δύο κύρια χαρακτηριστικά. 1. Επιτρέπει την αρχιτεκτονική της βάσης δεδομένων όπου έχει ανοχή σε σφάλματα, όπου διάφορες slave Neo4j βάσεις δεδομένων μπορούν να ρυθμιστούν ώστε να είναι ακριβή αντίγραφα μιας master βάσης δεδομένων Neo4j. Αυτό επιτρέπει στον τελικό χρήστη του συστήματος σε περίπτωση αποτυχίας του υλικού να είναι πλήρως καλυμμένος λειτουργικά και για την εγγραφή και την ανάγνωση δεδομένων από την βάση δεδομένων. 2. Επιτρέπει την read-mostly αρχιτεκτονική βάση δεδομένων όπου υπάρχει οριζόντια κλιμάκωση η οποία επιτρέπει στο σύστημα να χειριστεί περισσότερο φόρτο αναζήτησης πληροφοριών από αυτόν που μπορεί να χειριστεί ένα μόνο instance της βάσης δεδομένων Neo4j. Το «Neo4j HA» έχει σχεδιαστεί για να κάνει την μεταφορά από ένα μηχάνημα σε ένα πλήθος μηχανημάτων απλά χωρίς να χρειάζεται να αλλάξει κάτι στην υπάρχον εφαρμογή. Η μοναδική διαφορά που απαιτείται από τον προγραμματιστή είναι να αλλάξει την εντολή κατασκευής της βάσης στο GraphDatabaseService από GraphDatabaseFactory σε HighlyAvailableGraphDatabaseFactory. Όταν εκτελείται το Neo4j HA υπάρχει πάντα ένας master και κανένας ή περισσότεροι slaves. Συγκριτικά με άλλες master-slave replication εγκαταστάσεις, το Neo4j HA μπορεί να υποστηρίξει αιτήσεις εγγραφών σε όλα τα μηχανήματα και δεν υπάρχει λόγος να δρομολογηθούν προς τον master κόμβο. 43

58 NoSQL Βάσεις Δεδομένων Ένας slave υποστηρίζει τις εγγραφές συγχρονίζοντας τα δεδομένα με τον master ώστε να διατηρηθεί η συνέπεια. Κατά τον συγχρονισμό των εγγραφών με τον master, που γίνονται απευθείας σε κάποιο slave, γίνονται locks σε δεδομένα και στους δύο. Οι εγγραφές προς τον master προωθούνται με βέλτιστο τρόπο προς τους slaves, αν υπάρχουν. Με την φράση βέλτιστο τρόπο εννοούμε ότι ξεκινά η αποστολή πριν να ολοκληρωθεί η συναλλαγή, αλλά αν αυτή αποτύχει πάλι η αποστολή θα είναι επιτυχείς. Φυσικά όλες οι μεταβολές διαδίδονται από τον master στους slaves με eventual συνέπεια και κατά συνέπεια μια εγγραφή σε ένα slave μπορεί να μην είναι αμέσως διαθέσιμη σε όλους τους slaves. Όλα τα ACID χαρακτηριστικά ισχύουν. Οι συναλλαγές είναι atomic, συνεπείς και ανθεκτικές. Σχήμα 3.8 Δομή και ροή πληροφορίας σε ένα Neo4j HA cluster Ένα Neo4j HA cluster λειτουργεί συνεργατικά. Κάθε database instance περιέχει την λογική που χρειάζεται ώστε να συντονίζεται με κάθε άλλο μέλος του cluster. Κατά την έναρξη του το Neo4j HA database instance προσπαθεί να συνδεθεί με ένα cluster από την δηλωμένη διαμόρφωση. Αν υπάρχει το cluster τότε το instance θα συνδεθεί με αυτό ως slave. Σε αντίθετη περίπτωση το cluster δημιουργείται και αναλαμβάνει τον ρόλο του master. Όταν μία Neo4j database δεν είναι πλέον διαθέσιμη, όπως για παράδειγμα σε αποτυχία υλικού ή σε διακοπές στο δίκτυο, τα υπόλοιπα database instances στο cluster θα το ανιχνεύσουν και θα το σημάνουν ως προσωρινά μη διαθέσιμο. Ένα database instance που γίνεται διαθέσιμο ενώ προηγουμένως ήταν προσωρινά μη διαθέσιμο προστίθεται στο cluster αυτόματα. Αν ο master γίνει μη διαθέσιμος κάποιο άλλο μέλος του cluster που είναι κατάλληλο θα εκλεγεί και από slave θα γίνει master. Όταν ο νέος master αλλάξει τον ρόλο του, τότε εκπέμπει σε όλα τα υπόλοιπα μέλη του cluster την διαθεσιμότητα του. Συνήθως ένας νέος master εκλέγεται και ξεκινά την εκτέλεση του μέσα σε πολύ λίγα δευτερόλεπτα και κατά την διάρκεια αυτή δεν επιτρέπονται εγγραφές. Συνήθως μπλοκάρονται και σε κάποιες σπάνιες περιπτώσεις πετούν exception. Αυτό δεν συμβαίνει όταν ο παλιός master έχει αλλαγές τις οποίες δεν αναπαρήγαγε σε κανένα άλλο 44

59 NoSQL Βάσεις Δεδομένων μέλος πριν να γίνει μη διαθέσιμος. Αν ο νέος master εκλεγεί και κάνει αλλαγές πριν να επανέλθει σε λειτουργία ο παλιός, τότε θα υπάρχουν δύο «branches» της βάσης δεδομένων μετά από αυτό το σημείο, όπου ο παλιός master έγινε μη διαθέσιμος. Τότε ο παλιός master θα διαγράψει ολόκληρο το branch που περιέχει και θα κατεβάσει ένα νέο αντίγραφο της βάσης από τον νέο master, και θα γίνει διαθέσιμος ως slave στο cluster. Μία τυπική εγκατάσταση του Neo4j ΗΑ χρησιμοποιεί ένα cluster τριών μηχανημάτων για να παρέχεται ανοχή σε σφάλματα και επεκτασιμότητα στις αναγνώσεις. Έχοντας τουλάχιστον τρία instances δεν απαιτείται σε όλα να τρέχουν ολόκληρη την στοίβα του Neo4j, η οποία περιλαμβάνει το μηχανισμό διαχείρισης της βάσης δεδομένων (database engine). Αντ αυτού, μπορούν να αναπτυχθούν arbiter instances (διαιτητές). Αυτοί μπορούν να θεωρηθούν ως συμμετέχοντες στο cluster και ο ρόλος τους είναι να λάβουν μέρος στην εκλογή του master με σκοπό τους την λύση των ισοψηφιών κατά την εκλογή. Αυτό καθιστά δυνατό και το σενάριο όπου υπάρχουν μόνο δυο μηχανήματα στο cluster, όπου συνεχίζει να έχει την ανοχή σε βλάβες Βασικά χαρακτηριστικά του Neo4j Ασφάλεια Δεδομένων Κάποια δεδομένα μπορεί να πρέπει να είναι προστατευμένα από πρόσβαση χωρίς εξουσιοδότηση. Το Neo4j δεν ασχολείται με κρυπτογράφηση δεδομένων, αλλά υποστηρίζει όλα όσα υποστηρίζονται από τη Java και το JVM για την προστασία των δεδομένων μέσω κρυπτογράφησης πριν από την αποθήκευση. Επιπλέον, τα δεδομένα είναι ασφαλή με το να αποθηκεύονται σε ένα κρυπτογραφημένο σύστημα αποθήκευσης δεδομένων στο επίπεδο συστήματος αρχείων. Ακεραιότητα Δεδομένων (Integrity) Για να διατηρηθεί συνέπεια στα δεδομένα, υπάρχουν μηχανισμοί και δομές που εγγυώνται την ακεραιότητα όλων των αποθηκευμένων δεδομένων. Στο Neo4j, η ακεραιότητα των δεδομένων διατηρείται από το Core Graph Engine μαζί με άλλες πηγές δεδομένων. Ο τρόπος που είναι αποθηκευμένα τα δεδομένα, με απευθείας δείκτες, διατηρούν την ακεραιότητα χωρίς την ανάγκη για αντιγραφή των δεδομένων ανάμεσα στα διάφορα store files. Σε πολλές περιπτώσεις το Core Graph Engine συνδυάζεται με άλλα συστήματα ώστε να επιτύχει βέλτιστη απόδοση για μη-γραφικά ερωτήματα. Για παράδειγμα, το Apache Lucence χρησιμοποιείται συχνά ως σύστημα ευρετηρίων. Ενοποίηση Δεδομένων (Integration) Υπάρχουν εφαρμογές οι οποίες βασίζονται κυρίως σε σχεσιακές βάσεις δεδομένων για την αποθήκευση των δεδομένων τους, αλλά αυτό μπορεί να προκαλέσει περιορισμούς στην απόδοση. Σε ορισμένες από αυτές τις περιπτώσεις, το Neo4j μπορεί να χρησιμοποιηθεί ως επέκταση για να συμπληρώσει την αναζήτηση για ταχύτερη λήψη αποφάσεων. Ωστόσο, σε καταστάσεις όπου πολλαπλές αποθήκες δεδομένων περιέχουν τα ίδια δεδομένα, ο συγχρονισμός μπορεί να είναι ένα ζήτημα. Υπάρχουν κάποιες στρατηγικές που βοηθούν στην 45

60 NoSQL Βάσεις Δεδομένων αποφυγή προβλημάτων. Αυτές είναι ο συγχρονισμός βασισμένος σε γεγονότα, ο περιοδικός συγχρονισμός και οι περιοδικές πλήρης εισαγωγές και εξαγωγές δεδομένων. Διαθεσιμότητα και αξιοπιστία Το Neo4j διαθέτει τους κατάλληλους μηχανισμούς ώστε η πιο σημαντική αποστολή του συστήματος να είναι η βάση πάντα διαθέσιμη και αξιόπιστη. Υποστηρίζει cluster υψηλής διαθεσιμότητας που μπορούν να προσπελαστούν ταυτόχρονα. Επίσης υποστηρίζεται η αποθήκευση αντιγράφων ασφαλείας σε άλλους servers. Σε περιπτώσεις βλάβης μεγάλου μέρους της υποδομής υπάρχουν μηχανισμοί άμεσης και γρήγορης επαναχρησιμοποίησης των εναπομεινάντων υπηρεσιών και δεδομένων. Χωρητικότητα Το Neo4j εκμεταλλεύεται στο έπακρο τους πόρους του συστήματος, όπως οι ελεύθεροι πυρήνες που μπορεί να χρησιμοποιήσει για τις συναλλαγές και μπορεί να υποστηρίξει περίπου 34 δισεκατομμύρια κόμβους, άλλες τόσες σχέσεις, περίπου 68 δισεκατομμύρια ιδιότητες και 32 χιλιάδες τύπους σχέσεων Cypher γλώσσα ερωτημάτων Το Cypher είναι μια δηλωτική γλώσσα για εκτέλεση graph queries η οποία επιτρέπει εκφραστικές και αποτελεσματικές αναζητήσεις και ενημερώσεις σε δομές γράφων χωρίς να χρειάζεται να εγγραφούν traversals, μέσω της δομής του γραφήματος, στον κώδικα. Το Cypher εξακολουθεί να αναπτύσσεται και να ωριμάζει, και αυτό σημαίνει ότι κατά πάσα πιθανότητα μπορεί να υπάρξουν και αλλαγές στον τρόπο σύνταξης. Επίσης δεν έχει υποβληθεί σε πολύ αυστηρές δοκιμές επιδόσεων, όπως άλλα συστατικά του Neo4j. Το Cypher έχει σχεδιαστεί για να είναι μια ανθρώπινη γλώσσα ερωτημάτων, κατάλληλη τόσο για προγραμματιστές όσο για επαγγελματίες που θέλουν να εκμεταλλευτούν τις λειτουργίες που προσφέρονται και να κάνουν ad-hoc ερωτήματα στη βάση δεδομένων. Με τον όρο ad-hoc εννοείται ότι μπορούν να υπάρχουν έτοιμα ερωτήματα σε κάποιες εφαρμογές που αλλάζουν τα ορίσματα δυναμικά. Η γλώσσα ερωτημάτων αποτελείται από κάποια βασικά στοιχεία. Παρακάτω παρουσιάζονται κάποια συνοπτικά. START: Ο κόμβος εκκίνησης στον γράφο, που λαμβάνεται μέσω αναζήτησης σε index ή από αναγνωριστικά στοιχείων. MATCH: Είναι το μοτίβο του γράφου που θέλουμε να ταυτοποιηθεί, με όριο τους κόμβους έναρξης που ορίζονται από το START. WHERE: Κριτήρια φιλτραρίσματος. RETURN: Τι θα επιστραφεί. CREATE: Κατασκευάζει κόμβους και σχέσεις. DELETE: Διαγράφει κόμβους, σχέσεις και ιδιότητες. SET: Καθορίζει τιμές στις ιδιότητες. FOREACH: Εκτελεί ενημερώσεις για κάθε στοιχείο της λίστας. 46

61 NoSQL Βάσεις Δεδομένων WITH: Διαιρεί ένα ερώτημα σε πολλαπλά και διακριτά μέρη. Ένα μέρος ενός Cypher query δεν μπορεί ταυτόχρονα να κάνει match και update. Μπορεί μόνο είτε να ανακτά και να ταυτοποιεί μοτίβα, είτε να κάνει ενημερώσεις. Κάθε query μπορεί να επιστρέφει δεδομένα. Αν το query κάνει μόνο ανάκτηση, πρέπει να επιστρέφει δεδομένα αλλιώς δεν θα υπήρχε λόγος να υπάρχει το ερώτημα και έτσι δεν είναι έγκυρο Cypher query. Ερωτήματα τα οποία ενημερώνουν τον γράφο δεν χρειάζεται να επιστρέψουν κάτι αν και μπορούν. Μετά από όλα τα μέρη του ερωτήματος υπάρχει μόνο στο τέλος το RETURN. Μαζί με το RETURN, αν αυτό είναι έγκυρο τότε μπορούν να χρησιμοποιηθούν και τα SKIP/LIMIT και ORDER BY. Όσον αφορά τις συναλλαγές, αν ένα query κάνει ενημερώσεις δεδομένων θα τρέχει σε μια συναλλαγή. Η ενημέρωση είτε θα είναι επιτυχής ή δεν θα είναι καθόλου επιτυχής. Το Cypher είτε δημιουργεί μία νέα συναλλαγή, αν δεν υπάρχει κάποια ενεργή συναλλαγή, είτε τρέχει σε μία συναλλαγή που υπάρχει ήδη και όλα τα αποτελέσματα αποθηκεύονται στο τέλος της συναλλαγής. Στα ερωτήματα μπορούν να χρησιμοποιούνται μαθηματικοί, συγκριτικοί και δυαδικοί τελεστές στις ιδιότητες καθώς και οι τελεστές «?» και «!» που αναφέρονται στις συλλογές των ιδιοτήτων. Το «?» επιστρέφει true αν δεν υπάρχει μια ιδιότητα και το «!» επιστρέφει false αν υπάρχει η ιδιότητα. Τα μοτίβα και η αντιστοίχιση μοτίβων είναι η καρδιά του Cypher. Τα μοτίβα χρησιμοποιούνται, με το MATCH, για να περιγράφουν το σχήμα των δεδομένων. Ο χρήστης περιγράφει το μοτίβο, και το Cypher καταλαβαίνει πώς να ανακτήσει τα δεδομένα για τον χρήστη. Η ιδέα είναι να σχεδιαστεί το ερώτημα σε έναν πίνακα, ονομάζοντας τα σημαντικότερα μέρη του μοτίβου, ώστε να μπορούν να χρησιμοποιηθούν στη συνέχεια οι τιμές από αυτά τα μέρη για να δημιουργηθεί το σύνολο των αποτελεσμάτων. Όλα τα μοτίβα πρέπει να είναι συνδεδεμένα με ένα σημείο έναρξης. Παρακάτω φαίνεται ένα παράδειγμα χρήσης μοτίβου. START user=node:userindex(name = Marios) MATCH (user)-[:friend]->(friend) WITH user, count(friend) as friends WHERE friends > 10 RETURN user Σε αυτό το παράδειγμα, ξεκινώντας από τους κόμβους που ανήκουν στο index, userindex, και το όνομα τους είναι Marios, με χρήση του μοτίβου βρίσκουμε με ποιους κόμβους, friend, συνδέεται με σχέση FRIEND ο κάθε κόμβος user και αυτοί καταμετρούνται. Αν αυτοί είναι περισσότεροι από 10 τότε επιστρέφεται ο user. Το Cypher επίσης δίνει την δυνατότητα να υπάρχει μέγιστη απόσταση αναζήτησης από τον κόμβο έναρξης και αντιστοίχισης κάποιου μοτίβου. 47

62 3.3.9 Λειτουργίες και εργαλεία NoSQL Βάσεις Δεδομένων Διαχείριση Συναλλαγών Προκειμένου να διατηρηθεί πλήρως η ακεραιότητα των δεδομένων και η διασφάλιση της καλής συναλλακτικής συμπεριφοράς, το Neo4j υποστηρίζει πλήρως τις ACID ιδιότητες. Ειδικότερα παρέχονται οι μηχανισμοί ώστε όλες οι μεταβολές σε δεδομένα να περιτυλίγονται από μία συναλλαγή. Το βασικό επίπεδο απομόνωσης δεδομένων δηλώνει ότι δεν μπλοκάρονται αλλά ούτε κλειδώνονται οι αναγνώσεις προς την βάση γι αυτό μπορούν να γίνονται μη επαναλαμβανόμενα reads και τα επηρεαζόμενα δεδομένα να είναι κλειδωμένα μέχρι το τέλος της συναλλαγής. Τα κλειδώματα συμβαίνουν σε επίπεδο κόμβων και σχέσεων. Τα δεδομένα τα οποία ανακτήθηκαν από κάποια διάσχιση μπορούν να μεταβληθούν από κάποια άλλη συναλλαγή. Τέλος, υπάρχει μηχανισμός για ανίχνευση αδιέξοδων (deadlocks). Εισαγωγή Δεδομένων Παρέχεται μια, υψηλής απόδοσης, διαδικασία εισαγωγής δεδομένων το λεγόμενο «Batch Insertion». Αυτή η λειτουργία παρακάμπτει τις συναλλαγές και άλλους ελέγχους για να υπάρχει καλύτερη απόδοση. Αυτή η μέθοδος είναι η πλέον χρήσιμη όταν υπάρχει ένα μεγάλο σύνολο δεδομένων που πρέπει να φορτωθεί ολόκληρο όλο μαζί. Το Batch Insertion περιλαμβάνεται στον πυρήνα του Neo4j. Η εισαγωγή είναι καλύτερα να γίνεται μόνο σε ένα κόμβο του cluster μόνο. Indexing Οι λειτουργίες indexing είναι μέρος του Neo4j index API. Κάθε index είναι συνδεδεμένο με ένα μοναδικό όνομα και μπορεί να κάνει index κόμβους ή σχέσεις με βάση συγκεκριμένες ιδιότητες και τις τιμές τους που είναι στους κόμβους ή στις σχέσεις. Η προκαθορισμένη index εφαρμογή παρέχεται από το neo4j-lucene-index η οποία περιέχεται σε όλες τις εκδόσεις του Neo4j. Το πακέτο Lucene υποστηρίζει ένα έξυπνο indexing σε αριθμούς για ερωτήματα αριθμητικής εμβέλειας και ταξινόμησης των αποτελεσμάτων. Επίσης υπάρχει δυνατότητα για ερωτήματα με πολλαπλούς όρους στο ίδιο ερώτημα. Μια επίσης σημαντική λειτουργία, είναι το αυτόματο indexing. To αυτόματο indexing ελέγχεται από την διαμόρφωση της βάση αλλά και από το API του Neo4j. Σε αυτή την περίπτωση, το Neo4j παρέχει ένα index για τους κόμβους και ένα για τις σχέσεις σε κάθε βάση τα οποία ακολουθούν τις τιμές των ιδιοτήτων καθώς προστίθενται, διαγράφονται ή αλλάζουν. Αλγόριθμοι γράφων Οι αλγόριθμοι γράφων μπορούν να βρεθούν στο στοιχείο του API, neo4j-graph-algo που περιέχεται σε όλες τις εκδόσεις Neo4j. Οι αλγόριθμοι που υποστηρίζονται είναι οι Shortest paths, all paths, all simple paths, Dijkstra και ο A*. Διεπαφή WEB Η διεπαφή Web είναι η κύρια διεπαφή για τους χρήστες του Neo4j. Με αυτήν μπορεί να παρακολουθείται ο Neo4j Server ασχέτως αν είναι master ή slave. Επίσης παρακολουθείται και 48

63 NoSQL Βάσεις Δεδομένων η κατάσταση των υπόλοιπων μηχανημάτων. Οι χρήστες, μεταξύ άλλων, μπορούν να χειριστούν και να περιηγηθούν στα δεδομένα και επίσης μπορούν αλληλοεπιδρούν με τη βάση δεδομένων μέσω διαφόρων διεπαφών όπως Cypher και Gremlin. Κονσόλα Neo4j (shell) Το Neo4j shell είναι ένα command-line shell για περιήγηση στον γράφο, με παρόμοιο τρόπο που λειτουργεί το Unix shell. Αποτελείται από δύο μέρη. Το πρώτο είναι ένας ελαφρύς client που αποστέλλει εντολές μέσω απομακρυσμένης κλήσης μεθόδων. Το δεύτερο μέρος είναι ένας server ο οποίος επεξεργάζεται τις εντολές για τις κλήσεις των μεθόδων και επιστρέφει στον client τα αποτελέσματα. Γενικά, είναι ένα καλό εργαλείο για ανάπτυξη εφαρμογών και αποσφαλμάτωση. 49

64 NoSQL Βάσεις Δεδομένων 50

65 Load Balancing και Ευρετήρια Κεφα λαιο 4 4 Load Balancing και Ευρετήρια Σε αυτό το κεφάλαιο θα παρουσιαστούν κομμάτια από δύο δημοσιεύσεις που έχουμε σε επιστημονικά συνέδρια και είχα τον ρόλο του σχεδιασμού της βασικής αρχιτεκτονικής των ευρετηρίων και των δομών έτσι ώστε τα δεδομένα να κατανέμονται ομοιόμορφα στους υπολογιστικούς κόμβους και να εκτελούνται τα διάφορα ερωτήματα εύρους ανά περίπτωση σε αυτά τα συστήματα. Σε αυτά γίνεται χρήση μόνο του κατανεμημένου συστήματος αποθήκευση του Hadoop και της κατανεμημένης βάσης Δεδομένων HBase. Τα ευρετήρια αυτά έχουν εφαρμόζουν load balancing. 4.1 Load Balancing (Εξισορρόπηση φόρτου) Στην πληροφορική, η εξισορρόπηση φόρτου βελτιώνει την κατανομή του φόρτου εργασίας σε πολλούς υπολογιστικούς πόρους, όπως υπολογιστές, ένα σύμπλεγμα υπολογιστών, συνδέσεις δικτύου, κεντρικές μονάδες επεξεργασίας ή μονάδες δίσκου. [42] Η εξισορρόπηση φόρτου στοχεύει στη βελτιστοποίηση της χρήσης των πόρων, τη μεγιστοποίηση της απόδοσης, την ελαχιστοποίηση του χρόνου απόκρισης, και να αποφευχθεί η υπερφόρτωση οποιουδήποτε μεμονωμένου πόρου. Όσο χρησιμοποιούνται περισσότερα συστατικά σε ένα σύστημα που έχουν καλή εξισορρόπηση φόρτου αντί για ένα μόνο στοιχείο αυξάνεται η αξιοπιστία και η διαθεσιμότητα μέσω πλεονασμού. Η εξισορρόπηση φόρτου συνήθως περιλαμβάνει ειδικό λογισμικό ή υλικό, όπως ένα πολυστρωματικό switch ή μία διεργασία για ένα Domain Name System. Οι πιο συχνά χρησιμοποιούμενες εφαρμογές της εξισορρόπηση φόρτου είναι να παρέχει μια ενιαία υπηρεσία Internet από πολλούς διακομιστές, μερικές φορές γνωστή ως ένα σύμπλεγμα διακομιστών (server farm). Tα πιο συνηθισμένα συστήματα στα οποία εφαρμόζεται load balancing είναι δημοφιλείς δικτυακοί ιστότοποι, μεγάλα Internet Relay Chat δίκτυα, υψηλού εύρους ζώνης File Transfer Protocol sites, Network News Transfer Protocol (NNTP) servers, Domain Name System (DNS) servers, και βάσεις δεδομένων. Σε πολύ γενικές γραμμές το Load Balancing επιτυγχάνεται είτε από την πλευρά του Client είτε από την πλευρά του server. Από την πλευρά του Client η εξισορρόπηση φόρτου γίνεται με την παράδοση μιας λίστα με διευθύνσεις IP του server στον πελάτη, και στη συνέχεια ο client επιλέγει τυχαία τη διεύθυνση IP από τη λίστα για κάθε σύνδεση. Για τις υπηρεσίες διαδικτύου, η εξισορρόπηση φόρτου γίνεται στην πλευρά του διακομιστή και αυτό είναι συνήθως ένα 51

66 Load Balancing και Ευρετήρια πρόγραμμα λογισμικού που συνδέει τους χρήστες και τους δίνει πρόσβαση στις υπηρεσίες. Ο εξισορροπηστής φόρτου προωθεί τα ερωτήματα προς τους διακομιστές της υπηρεσίας που συνήθως απαντάνε πίσω σε αυτόν. Αυτό επιτρέπει την εξισορρόπηση φόρτου απάντησης στον πελάτη, χωρίς ο πελάτης ποτέ να μάθει για τον εσωτερικό διαχωρισμό. Επίσης, αποτρέπεται η άμεση επαφή με τους back-end servers, γεγονός που μπορεί να έχει οφέλη για την ασφάλεια με την απόκρυψη της δομής του εσωτερικού δικτύου και την πρόληψη επιθέσεων. 4.2 Query Load Balancing Ο στόχος της παράλληλης εκτέλεσης ερωτημάτων ελαχιστοποιεί τον χρόνο απάντησης ερωτήματος χρησιμοποιώντας εσωτερικό και εξωτερικό παραλληλισμό. Ο εξωτερικός παραλληλισμός εκχωρεί διαφορετικά κομμάτια του σχεδίου εκτέλεσης ερωτήματος σε διακριτούς επεξεργαστές, ενώ ο εσωτερικός παραλληλισμός χρησιμοποιεί διαφορετικούς επεξεργαστές για την εκτέλεση ενός ενιαίου ερωτήματος λόγω του διαχωρισμού στην κατανομή των δεδομένων. Εννοιολογικά, παραλληλισμός ενός ερωτήματος ισοδυναμεί με διαίρεση της εργασίας του ερωτήματος σε μικρά κομμάτια ή η εκτέλεση να ανατίθενται σε διαφορετικούς επεξεργαστές. Ο χρόνος απόκρισης είναι αυτός του πιο αργού κομματιού οπότε η κύρια δυσκολία είναι το φορτίο ερώτημα είναι ομοιόμορφα εξισορροπημένο εντός των επεξεργαστών. Η εξισορρόπηση φόρτου ερωτήματος σχετίζεται με στατικές ή/και δυναμικές τεχνικές και αλγόριθμους για την εξισορρόπηση του φόρτου των ερωτημάτων ούτως ώστε ο χρόνος απόκρισης να ελαχιστοποιείται. [44] Στην παρούσα εργασία ασχολούμαστε με την εξισορρόπηση φόρτου σε κατανεμημένες βάσεις δεδομένων. Την εξισορρόπηση μπορούμε να την δούμε από δύο πλευρές. Η μία πλευρά είναι το πώς θα κατανέμονται τα δεδομένα στους servers και πως αυτά με βέλτιστο τρόπο μπορούν να απαντήσουν τα διάφορα ερωτήματα που τίθενται από τις εφαρμογές που υποστηρίζουν. Η άλλη πλευρά είναι το πώς τα ερωτήματα μπορούν να κατανεμηθούν με βέλτιστο τρόπο στους servers για να γίνεται στα μέτρα του εφικτού κατανομή του φόρτου στους servers. Οι δύο αυτές πλευρές συνδέονται καθώς κάνοντας μία καλή και οργανωμένη με σωστές δομές δεδομένων των δεδομένων τότε έχουμε καλή εξισορρόπηση φόρτου όταν ανακτούμε δεδομένα από το cluster για να απαντηθεί ένα ερώτημα. Οι πιο γνωστές κατανεμημένες βάσεις δεδομένων, όπως η HBase που περιγράφηκε πιο πάνω, χρησιμοποιούν αυτόματους μηχανισμούς κατανομής των δεδομένων στους servers αλλά αυτό σε πολλές περιπτώσεις δεν είναι αρκετό. Οι απαιτήσεις για απάντηση σύνθετων ερωτημάτων στα δεδομένα, όπως ερωτήματα εύρους σε πολυδιάστατα δεδομένα, αυτά χρειάζεται ένα overlay και συγκεκριμένος τρόπους αποθήκευσης και αναπαράστασης των δεδομένων ώστε να επιτυγχάνεται καλό Load Balancing στην απάντηση των ερωτημάτων αυτών. Έτσι ο χρόνος απόκρισης θα μικραίνει. 52

67 Load Balancing και Ευρετήρια 4.3 Ευρετήρια Βάσεων Δεδομένων Ένα ευρετήριο βάσης δεδομένων είναι μια δομή δεδομένων που βελτιώνει την ταχύτητα των λειτουργιών ανάκτησης δεδομένων σε έναν πίνακα βάσης δεδομένων με κόστος τις πρόσθετες εγγραφές και τον αποθηκευτικό χώρο για τη διατήρηση της δομής δεδομένων. Τα ευρετήρια που χρησιμοποιούνται για να εντοπίσουμε γρήγορα τα δεδομένα χωρίς να χρειάζεται να αναζητήσουμε κάθε γραμμή σε έναν πίνακα βάσης δεδομένων κάθε φορά που εκτελείται ένα ερώτημα. Ευρετήρια μπορούν να δημιουργηθεί χρησιμοποιώντας μία ή περισσότερες στήλες ενός πίνακα μιας βάσης δεδομένων. Ένας ευρετήριο είναι ένα αντίγραφο των επιλεγμένων στηλών των δεδομένων από έναν πίνακα που μπορούν να αναζητηθούν πολύ αποτελεσματικά όταν περιλαμβάνει επίσης μια διεύθυνση μπλοκ δίσκου χαμηλού επιπέδου ή την άμεση σύνδεση με την πλήρη σειρά των δεδομένων που αντιγράφηκαν Κατανεμημένο υπολογιστικό σύστημα και ευρετήρια Στα κατανεμημένα υπολογιστικά συστήματα, τα κομμάτια ενός συστήματος λογισμικού διαμοιράζονται μεταξύ πολλαπλών υπολογιστών με σκοπό τη βελτίωση της επίδοσης και της αποδοτικότητας [19]. Τα κατανεμημένα συστήματα μπορούν να διακριθούν σε δύο είδη ανάλογα με τον τρόπο υλοποίησης και λειτουργίας τους. Το σύστημα μπορεί να λειτουργεί σύμφωνα με το μοντέλο πελάτη-εξυπηρετητή (client-server) ή το μοντέλο ομότιμης υλοποίησης (peer-to-peer). Στο πρώτο μοντέλο υπάρχει ένα κεντρικός εξυπηρετητής που είναι ο διαιτητής του συστήματος και πολλοί πελάτες που επικοινωνούν με τον εξυπηρετητή και εκτελούν τις διεργασίες που τους ανατίθενται, με τους πελάτες και τους εξυπηρετητές εκτελούν εντελώς διαφορετικές εργασίες. Στο δεύτερο μοντέλο όλα τα συστήματα είναι ομότιμα μεταξύ τους. Όλα στέλνουν και λαμβάνουν δεδομένα μεταξύ τους και όλα σαν ένα σύνολο παρέχουν επεξεργαστική ισχύ και μνήμη ώστε να εκτελεστεί η συνολική εργασία. Τα κατανεμημένα υπολογιστικά συστήματα μοιάζουν πολύ με τα παράλληλα υπολογιστικά συστήματα και μπορούν τα συστήματα αυτά να χαρακτηριστούν ως παράλληλα και ως κατανεμημένα την ίδια στιγμή. Η κύρια διαφορά τους είναι ότι στα κατανεμημένα ο κάθε επεξεργαστής διαθέτει τη δική του ιδιωτική μνήμη και η πληροφορία ανταλλάζεται με τη μεταφορά μηνυμάτων μεταξύ των επεξεργαστών, ενώ στα παράλληλα συστήματα, οι επεξεργαστές μπορεί να έχουν πρόσβαση σε μια κοινή μνήμη χωρίς την ανταλλαγή μηνυμάτων. Στα κατανεμημένα συστήματα η δημιουργία του ευρετηρίου γίνεται τρόπο παρόμοιο με τη δημιουργία ευρετηρίου στις βάσεις. Κάθε υπολογιστής που ανήκει στο σύστημα περιέχει τμήμα του των δεδομένων και δημιουργείται ένα ευρετήριο πάνω σε αυτά τα δεδομένα. Τα ευρετήρια αυτά, ανάλογα με τον τύπο των δεδομένων συνοψίζονται σε ένα συνολικό ευρετήριο για το σύνολο των δεδομένων. Στην περίπτωση που το κατανεμημένο σύστημα έχει δημιουργηθεί με το Apache Hadoop η διαδικασία δημιουργίας ευρετηρίου γίνεται με MapReduce. Κάθε διαδικασία map διενεργεί στο δικό της τμήμα δεδομένων και όταν η διαδικασία map ολοκληρωθεί για το τμήμα δεδομένων που της αντιστοιχεί, το ευρετήριο που έχει δημιουργηθεί αποθηκεύεται στον δίσκο ή στο τοπικό server της HBase που τρέχει το μηχάνημα. Η διαδικασία 53

68 Load Balancing και Ευρετήρια reduce διαβάζει τα επιμέρους ευρετήρια που έχουν δημιουργηθεί από τις διαδικασίες map και δημιουργεί το τελικό ταξινομημένο ευρετήριο. [14] 4.4 HB+ tree Στο [31] γίνεται μια περιγραφή του τρόπου υλοποίησης του ευρετηρίου και του σκοπού που εξυπηρετεί το HB+-tree, καθώς και διεξαγωγή μετρήσεων υπολογισμού της επίδοσής του ευρετηρίου με την προτεινόμενη αρχιτεκτονική για κατανομή των δεδομένων στους υπολογιστικούς κόμβους και του ευρετηρίου. Αυτό οδηγεί στην εξισορρόπηση του φόρτου των δεδομένων στους διάφορους κόμβους του συστήματος. Ο κύριος στόχος της δουλειάς αυτής είναι η σύγκριση μεταξύ μιας νέας βασισμένης στο Hadoop υλοποίησης του B+ δέντρου (το λεγόμενο HB+-δέντρο: HBase Β+-δέντρο) και του παράλληλου τοπικού Β+-δέντρου [32] στο I/O μοντέλο. Το ΗΒ+-δέντρο έχει μια πολυεπίπεδη διάρθρωση που σχεδιάστηκε. Το πρώτο στρώμα είναι μια κατανεμημένη έκδοση του B+-δέντρο που δεικτοδοτεί τους HBase κόμβους και το δεύτερο στρώμα είναι ένα τοπικό lazy B-tree [9]. Το lazy B-δέντρο είναι πιο αποδοτικό από το Β+-δέντρο, επειδή μπορεί να χειριστεί ενέργειες ενημέρωσης για επαναζύγιση του με O(1) χρόνο. Το ΗΒ+-δέντρο ευρετήριο, είναι ένα δευτερεύον σχήμα δεικτοδότησης του συστήματος αποθήκευσης για το cloud το οποίο διατηρεί τις συνηθισμένες λειτουργίες όπως εισαγωγή, διαγραφή, αναζήτηση και ένα επιθυμητό εύρος κλειδιών για ανάκτηση πληροφοριών. Αποτελείται από δύο μέρη. Το ένα είναι η βιβλιοθήκη του χρήστη η οποία συνδέεται με την εφαρμογή του χρήστη και μία ομάδα από servers ευρετηρίων που αποθηκεύουν το ευρετήριο. Οι ΗΒ+-δέντρο servers του ευρετηρίου μπορούν να τρέχουν ταυτόχρονα στα ίδια φυσικά μηχανήματα με τους servers ευρετηρίου του ίδιου του συστήματος Ευρετήριο HB+ tree Το ΗΒ+-δέντρο αποθηκεύει κάθε δείκτη ως ένα ζεύγος (sk,handle), όπου sk είναι το δευτερεύον κλειδί και handle η αυθαίρετη byte συμβολοσειρά η οποία χρησιμοποιείται για να επιφέρει την αντίστοιχη τιμή στο συστήματος αποθήκευσης. Το πρωτεύον κλειδί είναι το κλειδί που αποθηκεύεται στο σύστημα αποθήκευσης με τη μορφή (κλειδί, τιμή). Ο δείκτης δεν περιέχει πληροφορίες για όλο το σύνολο δεδομένων, αλλά μια τοπική έκδοση του lazy B-tree ευρετηρίου για τα δεδομένα που περιέχει ο κάθε server ευρετηρίου. Ο server ευρετηρίου είναι υπεύθυνος για τις αιτήσεις που αφορούν κομμάτια δεδομένων που δεικτοδοτούνται από το διακομιστή. Οι διακομιστές του ευρετηρίου είναι οργανωμένοι ως κατανεμημένο Β+-δέντρο που τρέχει στο Hadoop cluster με HBase κόμβους. Κάθε κόμβος συνδέεται με τους γειτονικούς και με μια διαδικασία συλλογής κάποιων κόμβων από κάθε έναν που ξέρει ποια δεδομένα δεικτοδοτούνται από ποιον. Αυτή η αρχιτεκτονική επιλογή, δεικτοδοτεί διακομιστές, κάνει καταχωρήσεις ενημέρωσης ευρετηρίου τοπικά, και έχει ως αποτέλεσμα την επίτευξη υψηλής 54

69 απόδοσης και παραλληλίας. Load Balancing και Ευρετήρια Lazy B-tree Το lazy B-tree [33] είναι ένα απλό και βασίζεται στις τεχνικές που εισήχθησαν στο [34]. Το lazy B-tree υλοποιεί μια διεπίπεδη μέθοδο πρόσβασης, όπως απεικονίζεται στο Σχήμα 4.1 Error! Reference source not found.. Το πρώτο επίπεδο αποτελείται από ένα συνηθισμένο B-tree, ενώ το δεύτερο αποτελείται από κάδους μεγέθους O(log 2 n), όπου n είναι περίπου ίσο με τον αριθμό των στοιχείων που είναι αποθηκευμένες στην μέθοδο πρόσβασης. Κάθε κάδος αποτελείται από δύο στρώματα λίστας, L και Li, αντιστοίχως, όπου 1<i< O(log n), καθένα από τα οποία έχει O(log n) μέγεθος. Σχήμα 4.1 Lazy B-tree Το Lazy B-tree ακολουθεί το θεώρημα: Το Lazy B-Tree υποστηρίζει πράξεις αναζήτησης σε O(logB n) χειρότερης περίπτωσης μεταφοράς block και πράξεις ενημέρωσης σε O(1) χειρότερου χρόνου μεταφοράς block, αρκεί να δίνεται το σημείο ενημέρωσης Αρχιτεκτονική Σχεδίαση ΗΒ+-tree Το Σχήμα 4.2 δείχνει την αρχιτεκτονική του συστήματος δεικτοδότησης ΗΒ+-δέντρο. Το Rangecache() ευρετήριο που είναι αποθηκευμένο στο HBase master-κύριο κόμβο δεικτοδοτεί απευθείας κατά την διαδικασία της αναζήτησης απευθείας στον κατάλληλο υπολογιστικό κόμβο της HBase/ Οι κύριοι κόμβοι HBase συνδέονται με κατανεμημένο ιεραρχικό τρόπο ως δέντρο (όπως στο BATON), κατασκευάζοντας το επονομαζόμενο HB+-δέντρο επικάλυψης. Κάθε κόμβος έχει ένα lazy B-tree ευρετήριο για τα τοπικά δεδομένα του. 55

70 Load Balancing και Ευρετήρια Σχήμα 4.2 Αρχιτεκτονική HB+-tree Το HB+-δέντρο ευρετήριο είναι χτισμένο πάνω από τους HBase Region διακομιστές περιοχή και χρησιμοποιείται για να εντοπίσει τον αντίστοιχο HBase κόμβο για μια δεδομένη τιμή κλειδιού ή ένα ερώτημα εύρους. Έτσι, το πρώτο βήμα για την επεξεργασία ενός ερωτήματος είναι να αναζητηθεί στο HB+-δέντρο ευρετηρίου οι αντίστοιχοι κόμβοι της HBase βασισμένοι στο δέντρο επικάλυψης που υλοποιεί το πρωτόκολλο δρομολόγησης. Μετά από αυτό, ακολουθώντας τους δείκτες του ΗΒ+-δένδρου του ευρετηρίου, μπορούν να αναζητηθούν τα τοπικά Lazy Β-δέντρα παράλληλα. Τα αποθηκευμένα δεδομένα στο HDFS παράγουν Ν διαφορετικά κλειδιά και να κάνουν χρήση R reducers θα έχει ως αποτέλεσμα να κατασκευαστούν R δέντρα. Άμεση συνέπεια αυτού είναι ότι κάθε reducer θα πάρει ιδανικά Ν/R διαφορετικά κλειδιά. Βασικό στοιχείο εδώ είναι να επιτευχθεί η ομαλή αποθήκευση των κόμβων του δέντρου σε RegionServers χωρίς να φορτωθούν κάποιοι από αυτούς με πολύ περισσότερα δεδομένα και την ίδια στιγμή κάποιοι κόμβοι να είναι πιο αραιοί. Ένα άλλο σημείο που χρήζει προσοχής είναι ότι κάθε περιοχή ενός RegionServer πρέπει να περιέχει περισσότερες γραμμές στον πίνακα και να έχει μεγαλύτερο μέγεθος για να αποφευχθεί η άσκοπη επαφή με άλλους RegionServers. Όλα όσα περιγράφονται παραπάνω είναι αναγκαία, διότι πολύ σημαντικό ρόλο έχει ο συντελεστής εξισορρόπησης του δέντρου (fanout), ο οποίος σχετίζεται με το πλάτος και το ύψος του ΗΒ+-δέντρου. Το τελευταίο επηρεάζει την συνολική απόδοση του συστήματος, διότι σε αυτή την περίπτωση η επιλογή του funout έχει άμεση σχέση με το μέγεθος της κάθε περιοχής και μπορεί να βελτιώσει αισθητά τη συνολική απόδοσης του συστήματος. Στο Σχήμα 4.3 περιγράφεται ο τρόπος που αποθηκεύονται τα δεδομένα σε μια γραμμή της HBase ώστε να υπάρχει ομαλή λειτουργία του δέντρου. 56

71 Load Balancing και Ευρετήρια Σχήμα 4.3 Γραμμή αποθήκευσης κόμβου του HB+-tree Εξισορρώπηση φόρτου δεδομένων και ερωτήματα εύρους Λαμβάνοντας ένα ερώτημα εύρους Q, η διαδικασία που πρέπει να γίνει είναι η αναζήτηση στο ΗΒ+-δένδρο ευρετηρίου και να εντοπιστούν οι κόμβοι των οποίων έχουν περιοχές (περιφέρειες) επικάλυψης με το Q. Λαμβάνοντας υπόψη ένα ερώτημα Q=[l, u], όπου l είναι το κατώτερο όριο του Q και u είναι το ανώτερο. Η αναζήτηση μπορεί να ξεκινήσει από το κάτω όριο, αλλά για λόγους βελτιστοποίησης μπορεί να αρχίσει σε οποιοδήποτε σημείο στην περιοχή. Όταν βρεθεί σε ένα τυχαίο κόμβο επεξεργασίας στην περιοχή αναζήτησης ακολουθώντας τον πρόγονο κόμβο μπορεί να βρεθεί η ρίζα-κόμβος του ΗΒ+-δένδρου. Αυτό το υπο-δέντρο καλύπτει όλο το εύρος της έρευνας. Το ερώτημα πρέπει να μεταδοθεί στους απογόνους του υπο-δέντρου για να αυξηθεί ο παραλληλισμός. Σε κάθε κόμβο επεξεργασίας, μετά την παραλαβή της αίτησης αναζήτησης, εκτελείται στο τοπικό ευρετήριο το ερώτημα αναζήτησης. Τέλος, το αποτέλεσμα της αναζήτησης στο ευρετήριο επιστρέφεται στον αποστολέα του ερωτήματος. Εκτελέστηκαν πειράματα ώστε να βρεθεί πια είναι η καταλληλότερη παραμετροποίηση του συστήματος και επιλογών στις παραμέτρους που σχετίζονται άμεσα με την κατασκευή και την κατανομή των δεδομένων στα δέντρα. Σύμφωνα με τα πειράματα που εκτελέστηκαν επιλέγηκε το fanout (συντελεστής ύψους και πλάτους δέντρου) 121 γιατί ο χώρος που καταλάμβανε το ευρετήριο ήταν μικρότερος και ο χρόνος δημιουργίας ήταν αρκετά λογικός και μικρός και ανεξάρτητος σχεδόν του πλήθους των υπολογιστικών κόμβων που συμμετείχαν (8 κόμβοι). Στην συνέχεια με επιλογή των καλύτερων παραμέτρων από πάνω εκτελέστηκαν τα τελικά πειράματα της σύγκρισης μεταξύ του κατανεμημένου B+-δέντρου ευρετηρίου και του κεντρικοποιημένου παράλληλου Β+-δέντρου που τρέχει σε ένα μηχάνημα. Στο (a) βλέπουμε ότι το κατανεμημένο υπερτερεί κατά πολύ του κεντρικοποιημένου στην κατασκευή του δέντρου. Στο (b) φαίνονται οι χρόνοι εκτέλεσης ερωτημάτων και παρατηρείται ότι το παράλληλο υπερτερεί του κεντρικοποιημένου. Σημαντικό σημείο είναι η χρήση της μεθόδου prewarmregion-cache() η οποία ξεκινά την φόρτωση δεδομένων στην μνήμη κατά την εύρεση κόμβων στον ευρετήριο ώστε να επιστραφεί η απάντηση στον ερώτημα του χρήστη ακόμα πιο γρήγορα. Η υλοποίηση με χρήση της τεχνικής φόρτωσης των hot δεδομένων έχει ακόμα καλύτερο χρόνο στην εκτέλεση ερωτημάτων. 57

72 Load Balancing και Ευρετήρια Σχήμα 4.4 Χρονοι Κατασκευής Ευρετηρίου και Υπολογισμού Ερωτημάτων Εύρους HB+-tree Περισσότερες πληροφορίες σε σχέση με τα πειράματα μπορούν να βρεθούν στο [31] οι οποίες ξεπερνούν τα πλαίσια του θέματος που καλύπτεται. Το πολύ βασικό σε αυτό το σημείο είναι ότι η αρχιτεκτονική που σχεδιάστηκε μας δείχνει ότι η σκέψη του θεωρητικού επιπέδου για τον τρόπο που μπορούν τα δεδομένα να κατανεμηθούν και το overlay που δημιουργείται μας οδηγεί σε ένα load balancing πολύ καλό αφού ο χρόνος εκτέλεσης έχει μειωθεί σε σχέση την κεντρικοποιημένη λύση. Όσον αφορά το load balancing σημαντικό παράγοντα παίζει ο Partitioner που χρησιμοποιήθηκε για την κατανομή των δεδομένων στους Reducers που θα φτιάξουν τα τοπικά ευρετήρια. Σκοπός είναι η διαμέριση να διανείμει ομοιόμορφα τα δεδομένα. Αυτό επιτυγχάνεται με την επιστροφή ενός κωδικού. Ο κωδικός παράγεται εκείνη την στιγμή διαιρώντας την μεγαλύτερη τιμή των δεδομένων με την μικρότερη και μετά αυτό διαιρείται από τον αριθμό των Reducers που θα χρησιμοποιηθούν. Έτσι προκύπτει και Load balance στο πλήθος των δεδομένων που θα δεικτοδοτούνται από κάθε server. 4.5 NSM-Tree Στο [35] γίνεται μια περιγραφή του τρόπου υλοποίησης του ευρετηρίου και του σκοπού που εξυπηρετεί το NSM-tree, καθώς και διεξαγωγή μετρήσεων υπολογισμού της επίδοσής του ευρετηρίου με την προτεινόμενη αρχιτεκτονική για κατανομή των δεδομένων στους υπολογιστικούς κόμβους και του ευρετηρίου Ευρετήριο NSM-Tree To NSM-tree είναι το NoSQL Metric Tree. Επικεντρώνεται στην εφαρμογή του δημοφιλούς ευρετηρίου M-Tree [37] πάνω από την HBase, με το Hadoop, η οποία είναι η open-source εφαρμογή του MapReduce. Η δημιουργία του γίνεται όπως και στο προηγούμενο με την διαδικασία MapReduce. Το Metric-tree αποτελεί μια γενίκευση του B-tree και έχει εφαρμογή σε χωρικά δεδομένα. 58

73 Load Balancing και Ευρετήρια M-tree Το M-tree χρησιμοποιείται κυρίως για την δεικτοδότηση geospatial δεδομένων. Η συνάρτηση που υπολογίζει την απόσταση μεταξύ δύο σημείων στο χώρο ακολουθεί τα θεωρήματα της συμμετρίας και της τριγωνικής ανισότητας. Ο αλγόριθμος αναζήτησης του M-Tree υλοποιείται ως δυαδική αναζήτηση σε κάθε διάσταση, και είναι κατάλληλο για ερωτήματα εύρους της μορφής (x, y), όπου min x x max x και min y y max y. Τα δεδομένα που αποθηκεύονται σε ένα M-tree αποτελούνται από ένα σύνολο αντικειμένων, O = (key, value), όπου το κλειδί (key) είναι το γεωγραφικό μήκος και πλάτος της τοποθεσίας και η τιμή (value) οι πληροφορίες της τοποθεσίας. Αυτά οργώνονται σε μετρικούς χώρους M = (D, d), όπου D το κέντρο του χώρου και d η ακτίνα. Κάθε κόμβος μπορεί να κρατήσει μέχρι M εγγραφές και διαχωρίζονται σε δύο είδη: τους κόμβους-φύλλα του δέντρου που περιέχουν τα ταξινομημένα αντικείμενα και τους εσωτερικούς κόμβους που περιέχουν αντικείμενα δρομολόγησης. Για κάθε ταξινομημένο αντικείμενο που βρίσκεται σε κάποιον κόμβο-φύλλο του δέντρου αντιστοιχεί μια εγγραφή της μορφής entry(o j ) = [ O j, oid(o j ), d(o j, P(O j )) ]. Το oid(oj) αποτελεί το αναγνωριστικό της εγγραφής (η τιμή του αντικειμένου) και το d(oj, P(Oj)) την ευκλείδεια απόσταση του αντικειμένου O j από τον γονέα του P(O j ). Οι εγγραφές των εσωτερικών κόμβων του δέντρου είναι της μορφής entry(o r ) = [ O r, ptr(t(o r )), r(o r ), d(o r, P(O r )) ]. Το r(o r ) > 0 περιέχει την ακτίνα κάλυψης του αντικειμένου και ο δείκτης ptr(t(o r )) δείχνει στην ρίζα του υποδέντρου T(O r ), του δέντρου δηλαδή που καλύπτει το αντικείμενο O r. Η ακτίνα κάλυψης r(o r ) ικανοποιεί πάντα την ανισότητα d(o j, O r ) r(o r ) για κάθε αντικείμενο O j, που ανήκει στο δέντρο T(O r ), που ορίζεται από το αντικείμενο δρομολόγησης O r.[37] Σχήμα 4.5 Αντικείμενο δρομολόγησης Or με ακτίνα r(or) και υπο-δέντρο T(Or) Αρχιτεκτονική Σχεδίαση NSM-tree Στην αρχική του υλοποίηση το M-tree ακολουθεί τον top-down σχεδιασμό. Τα αντικείμενα εισάγονται σε έναν κόμβο Ν μέχρι αυτός να υπερχειλίσει, δηλαδή ο αριθμός των αντικειμένων να είναι μεγαλύτερος από το M και τότε εκτελείται η διαδικασία διαχωρισμού (split) του κόμβου. Η διαδικασία διαχωρισμού στέλνει δύο αντικείμενα δρομολόγησης του κόμβου Ν στον γονέα κόμβο, διαχωρίζει τα δεδομένα στα δύο και αποθηκεύει το ένα σύνολο στον Ν και το άλλο 59

74 Load Balancing και Ευρετήρια στον Ν. Έτσι υπάρχει πιθανότητα τα δεδομένα του αρχικού M-tree να εμφανίζονται σε περισσότερους από ένα κόμβους. Στην σχεδίαση που δημιουργήθηκε πάνω από την HBase αποφασίστηκε να κρατιέται αυτή η πληροφορία για κάθε γραμμή δεδομένων όλες τις εμφανίσεις των αντικειμένων στους διάφορους κόμβους από την ρίζα προς τα φύλλα. Το κλειδί κάθε γραμμής είναι οι γεωγραφικές συντεταγμένες. Στο Σχήμα 4.6 Γραμμή αποθήκευσης κόμβου του NSM-tree περιγράφεται ο τρόπος που αποθηκεύονται τα δεδομένα σε μια γραμμή της HBase ώστε να υπάρχει ομαλή λειτουργία του δέντρου. RowKey: longitude;latitude Cf1: areainfo Cf1: distancefromparent (Euclidian distance) Cf1: parent (rowkey) Σχήμα 4.6 Γραμμή αποθήκευσης κόμβου του NSM-tree Cf1: radious Cf2: objectapperances (Στήλες όσες το M) Όπως αναφέρθηκε και πριν ένα αντικείμενο μπορεί να εμφανιστεί σε πολλαπλούς κόμβους του δέντρου, έτσι πρέπει οι στήλες του πίνακα να καταγράφουν αυτές τις πληροφορίες. Αυτό επιτυγχάνεται με τη διατήρηση της τιμής των κλειδιών των κόμβων. οέστω έχουμε την γραμμή με κλειδί 0;1. Ο γονέας (parent) περιέχει τις τιμές των κλειδιών των αντικειμένων που έχουν κλειδί 0;1. Για παράδειγμα περιέχει τις τιμές root!0;1!0;1 που σημαίνει ότι έχουμε τις τιμές root, 0;1 και 0;1. Από αυτό αντιλαμβανόμαστε ότι στον κόμβο root περιλαμβάνεται το κλειδί και φτάνει σε βάθος 2 στο δέντρο. Καθώς όλοι οι γονείς των στοιχείων με κλειδί 0;1 είναι στοιχεία με το ίδιο κλειδί ή το κλειδί βρίσκεται και στην ρίζα τότε η στήλη distancefromparent αποτελείται μόνο από τις τιμές 0. Η στήλη radius δείχνει την ακτίνα των αντικειμένων που βρίσκονται στον κόμβο. Στην δεύτερη οικογένεια στηλών ισχύει το ίδιο για την σειρά που καταχωρούνται. Η πρώτη στήλη αντιστοιχεί στο πρώτο στοιχείο κτλ. Κάθε στήλη δείχνει σε ποιους κόμβους περιέχονται τα κλειδιά που υπάρχουν στην στήλη. Από τον αριθμό των στηλών στην δεύτερη οικογένεια στηλών του δέντρου προκύπτει το μέγεθος του Μ για το M-Tree. Στο τέλος υπάρχει και μια εγγραφή με κλειδί root και μία στήλη value που περιέχει τα κλειδιά των εγγραφών (rowkey) του δέντρου που βρίσκονται στην ρίζα του δέντρου. Για την κατασκευή του δέντρου-ευρετηρίου στην HBase η διαδικασία που ακολουθείται είναι η εξής: Αρχικά τα δεδομένα αποθηκεύονται στο HDFS και χρησιμοποιούν μια κεντρικοποιημένη μέθοδο για να κατασκευαστεί στο HDFS το serialized αρχείο. Στην συνέχεια με την χρήση ενός mapreduce job κατασκευάζεται το NSM-tree στην HBase. Ένας άλλος τρόπος για την κατασκευή του δέντρου είναι να γίνει η κατασκευή απευθείας στην HBase αλλά αυτό αποδείχθηκε προβληματική για τους υπολογιστικούς κόμβους που υπάρχαν διαθέσιμοι. Τα δεδομένα που χρησιμοποιήθηκαν είναι από το σετ δεδομένων Map and GIS Data By US State [38]. Τα δεδομένα αποτελούνται από τοποθεσίες διαφόρων σημείων ενδιαφέροντος των ΗΠΑ. Στην συνέχεια τα δεδομένα μεταφέρθηκαν στην επιθυμητή μορφή και εκτελείται η 60

75 Load Balancing και Ευρετήρια παράλληλη δημιουργία του δέντρου και μεταφορά του στην HBase. Στην διαδικασία κατασκευής του δέντρου γίνεται η διάσπαση στα Μ τμήματα, όπου Μ το μέγεθος κάθε κόμβου του M-tree και στην συνέχεια περνούν στην διαδικασία Reduce όπου και προκύπτουν τα Μ δέντρα που αποθηκεύονται στην HBase και αποτελούν το ευρετήριο. Τέλος επιλέγεται ένα τυχαίο στοιχείο από κάθε κόμβο-ρίζα των M δέντρων (συνολικά Μ στοιχεία) και γίνεται εισαγωγή στην HBase μίας γραμμής με κλειδί root και στήλη τις τιμές αυτές. Ως αποτέλεσμα έχει δημιουργηθεί στην HBase το ευρετήριο των δεδομένων, τα στοιχεία του οποίου είναι αποθηκευμένα στα διάφορα υπολογιστικά συστήματα του cluster σύμφωνα με την αρχική διάσπασή τους σε M τμήματα Εξισορρόπηση φόρτου δεδομένων και ερωτήματα εύρους Τα ερωτήματα αναζήτησης με βάση το εύρος (range queries) είναι της μορφής range(q, r(q)) και χρησιμοποιούν όλα τα προϋπολογισμένα μεγέθη που περιεγράφηκαν πιο πάνω και υπάρχουν ήδη στην HBase. Το Q είναι ένα αντικείμενο που είναι ήδη αποθηκευμένο στο δέντρο και r(q) το ζητούμενο εύρος αναζήτησης γύρω από το Q. Το ερώτημα θα πρέπει να επιστρέψει όλα τα αντικείμενα που είναι αποθηκευμένα στο δέντρο και τα οποία εμπίπτουν στην ακτίνα του. Ο αλγόριθμος ξεκινά την αναζήτηση από τη ρίζα του δέντρου και κατευθύνεται προς τα φύλλα διασχίζοντας όλα τα δυνατά μονοπάτια. Ο αλγόριθμος φαίνεται αναλυτικά στο [39]. Αυτό που αναμένεται είναι η ταχύτερη εκτέλεσης της διαδικασίας αναζήτησης εύρους με τη χρήση του ευρετηρίου, καθώς θα απαιτείται πρόσβαση για ανάκτηση δεδομένων μόνο στα υπολογιστικά συστήματα που περιέχουν στοιχεία που βρίσκονται εντός του εύρους αναζήτησης και αυτό γίνεται αρκετά αποδοτικά λόγω της σχεδίασης και του τρόπου κατανομής του φόρου (δεδομένων) στους υπολογιστικούς κόμβους Οι μετρήσεις έγιναν πάνω σε κεντρικοποιημένη αλλά και κατανεμημένη υλοποίηση του ευρετηρίου. Τα πειράματα εκτελέστηκαν σε 3 υπολογιστικούς κόμβους. Όσον αφορά την παραμετροποίηση των πειραμάτων η δημιουργία του ευρετηρίου, κατά την διαδικασία Split, χρησιμοποιείται η πολιτική Random για ισορροπημένο partition. Η παράμετρος M κυμαίνεται μεταξύ 10 και 50. Παρακάτω φαίνονται οι χρόνοι εκτέλεσης ερωτημάτων με την χρήση του ευρετηρίου και την κατανομή των δεδομένων που προκύπτει λόγο της κατανεμημένης υλοποίησης. Συγκριτικά φαίνονται οι χρόνοι στο κεντρικοποιημένο σύστημα. Σε πρώτο στάδιο η είσοδος ήταν ένα τυχαίο κλειδί με κάποιο τυχαίο εύρος αναζήτησης. Η επιλογή του κλειδιού αρχικά ήταν να βρίσκεται εντός των ορίων των συντεταμένων των δεδομένων. Το εύρος αναζήτησης επιλέχθηκε ώστε να φέρνει ένα ποσοστό αποτελεσμάτων της του 10%-15% για να αποφεύγεται η αναζήτηση σε όλο το δέντρο. 61

76 secs (log) secs (log) Load Balancing και Ευρετήρια 10 Search 1 object different range 1 0, M Centralized M-Tree NSM-Tree Σχήμα 4.7 Αναζήτηση ενός αντικειμένου με διαφορετικές ακτίνες Για το τύπο ερωτήματος που φαίνεται στο Σχήμα 4.7 παρατηρείται ότι για χαμηλές τιμές του Μ μέχρι 30 απαιτούν ίδιο χρόνο εκτέλεσης αλλά καθώς αυξάνεται φαίνεται η ξεκάθαρη υπεροχή του ευρετηρίου καθώς το NSM-Tree απαιτεί τάξη μεγέθους μικρότερο χρόνο για να απατήσει στα ερωτήματα. Επίσης εκτελέστηκαν πειράματα για μέτρηση χρόνου αναζήτησης 1000 τυχαία κλειδιά, εντός και εκτός των ορίων συντεταγμένων, με το ίδιο εύρος αναζήτησης για όλα Search 1000 objects same range M Centralized M-Tree NSM-Tree Σχήμα 4.8 Αναζήτηση 1000 αντικειμένων με ίδια ακτίνα Στο Σχήμα 4.8 όπου αναζητούνται χίλια αντικείμενα παρατηρούμε την σταθερή υπεροχή της κατανεμημένης υλοποίησης του ευρετηρίου από την αρχή. Στην αρχή βλέπουμε ότι υπάρχει μια 62

77 secs (log) Load Balancing και Ευρετήρια σταθερή απόδοση για μικρά Μ όμως καθώς αυξάνεται το Μ αρχίζει να αυξάνεται η διαφορά απόδοσης και να φαίνεται πιο ξεκάθαρα η υπεροχή του NSM-tree. Το τελευταίο πείραμα έλεγχε χρόνους εκτέλεσης για ένα τυχαίο κλειδί εντός των συντεταγμένων με 1000 διαφορετικές τυχαίες τιμές εύρους (ακτίνες) Search 1 object 1000 different ranges M Centralized M-Tree NSM-Tree Σχήμα 4.9 Αναζήτηση ενός αντικειμένου με 1000 διαφορετικές ακτίνες Στο Σχήμα 4.9 φαίνονται τα αποτελέσματα του τελευταίου τύπου ερωτήματος. Όπως και στην προηγούμενη περίπτωση φαίνεται με παρόμοιο τρόπο συμπεριφοράς η υπεροχή του κατανεμημένου ευρετηρίου με ελαφρά αυξημένους χρόνους και στις δύο υλοποιήσεις λόγο της φύσης των ερωτημάτων. Η ελαφριά αύξηση του χρόνου για Μ=30 θεωρείται αμελητέα λόγο της φύσης των δεδομένων και αφού η αύξηση είναι στην ίδια τάξη μεγέθους. Συνοψίζοντας ως γενική παρατήρηση για τις δύο δομές μπορεί να ειπωθεί ότι ο χρόνος απόκρισης στα ερωτήματα είναι αντιστρόφως ανάλογος προς την αύξηση του μεγέθους Μ του κόμβου. Αυτό συμβαίνει επειδή οι μεγαλύτερες τιμές της Μ έχουν ως αποτέλεσμα μικρότερα βάθη σε δέντρα. Κατά συνέπεια, ο αλγόριθμος αναζήτησης θα διασχίσει ένα μικρότερο μονοπάτι από τη ρίζα προς τα φύλλα για να λάβει την απάντηση του ερωτήματος. Επιπλέον, το NSM-Tree υπερισχύει του M-Tree, ειδικά καθώς μεγαλώνει Μ. Αξίζει να σημειωθεί ότι η διαδικασία για τα ερώτημα ενός αντικειμένου με 1000 διαφορετικά ranges είναι πιο χρονοβόρα σε σύγκριση με την αναζήτηση 1000 αντικειμένων με σταθερό range. Αυτή η συμπεριφορά εξηγείται από τις παραμέτρους που επιλέγηκαν. Κατά την αναζήτηση για 1000 αντικειμένων, αναμένεται η θέση αυτών των αντικειμένων να είναι κοντά στη γεωγραφική περιοχή κάλυψης του συνόλου δεδομένων. Εάν ένα αντικείμενο βρίσκεται έξω από την περιοχή κάλυψης, η διαδικασία αναζήτησης σταματά σχεδόν αμέσως (κοιτάζει μόνο στον κόμβο ρίζα), εάν το εύρος αναζήτησης δεν είναι αρκετά μεγάλα για να περιληφθούν οποιαδήποτε από τα στοιχεία δέντρου. Από την άλλη, όταν γίνεται αναζήτηση για ένα αντικείμενο με 1000 διαφορετικά ranges 63

78 Load Balancing και Ευρετήρια το στοιχείο αναζήτησης επιλέγεται να είναι κοντά στην γεωγραφική περιοχή κάλυψης του συνόλου δεδομένων, προκειμένου να μην επιστραφεί κενό σύνολο αποτελεσμάτων. Γενικά, οι χρόνοι δημιουργίας και εκτέλεσης των ερωτημάτων αναζήτησης στην κατανεμημένη υλοποίηση είναι της μορφής 1/log(aM), όπου α ένας ακέραιος και M το μέγεθος των κόμβων του δέντρου. Ένα από τα βασικά πλεονεκτήματα της χρήσης του ευρετηρίου M-Tree στην αναζήτηση χωρικών σημείων είναι ότι ο τρόπος δημιουργίας του δέντρου προσφέρει την απαραίτητη πληροφορία αποστάσεων και έτσι μειώνεται ο χρόνος υπολογισμών που απαιτούνται κατά την αναζήτηση έως και 40%. Με βάση τα ποιο πάνω αποτελέσματα και την βελτιστοποίηση της κατανομής των δεδομένων που επιτυγχάνεται και την παράλληλη εκτέλεση των υπολογισμών σε πολλούς υπολογιστικούς κόμβους το ποσοστό αυτό μπορεί να αυξηθεί κατά πολύ. 64

79 Πειραματική Σύγκριση HBase και Neo4j Κεφα λαιο 5 5 Πειραματική Σύγκριση HBase και Neo4j Στο κεφάλαιο αυτό περιγράφεται το κομμάτι της εργασίας που έχει να κάνει με την σύγκριση μεταξύ των δύο πολύ γνωστών κατανεμημένων βάσεων δεδομένων και πως η χρήση των ευρετηρίων θα προσέδιδε αύξηση στην απόδοση. Το πρώτο σύστημα είναι η Column-Oriented HBase και το δεύτερο είναι η κατανεμημένη βάση δεδομένων για γραφήματα Neo4j. Η εργασία αυτή έχει δημοσιευτεί στο [36]. Προκειμένου να δημιουργηθούν σύγχρονες εφαρμογές που να ικανοποιούν τους χρήστες πρέπει να δοκιμαστούν αυτά τα συστήματα. Οι Lizhi Cai et al. στο [1] παρουσιάζουν ένα μοντέλο για δοκιμές επιδόσεων για πολύπλοκα συστήματα και δείχνουν ότι οι δοκιμές των επιδόσεων θα πρέπει να εκτελούνται από δύο πτυχές: την αρχιτεκτονική και σε επιχειρησιακό επίπεδο. Ακολουθούμε την λογική του πρώτου/δεύτερου επίπεδου και έτσι προκύπτει η αξιολόγηση σχετικά με τα παραπάνω συστήματα. 5.1 Προετοιμασία Πειραμάτων Για τα πειράματα είχαμε στην διάθεση μας 3 υπολογιστικούς κόμβους που έτρεχαν το Hadoop και HBase με χαρακτηριστικά: CPU: 4 cores, memory: 8GB, disk: 40GB, os: 64bit Debian. Το ίδιο cluster χρησιμοποιήθηκε για το Neo4j σε High Availability mode (HA) με την έκδοση neo4j Συλλογή δεδομένων Για την εκτέλεση των πειραμάτων, κατασκευάστηκε ένα σύνολο δεδομένων. Τα δεδομένα αυτά, συλλέγηκαν με διάφορα ελεύθερα web API s, είναι μία τυχαία συλλογή στοιχείων από ταινίες και πρόσωπα που συμμετέχουν σε αυτές με διάφορες ιδιότητες. Οι ταινίες και τα πρόσωπα, εκτός των υπόλοιπων ιδιοτήτων, έχουν ένα μοναδικό αναγνωριστικό, για τις ταινίες είναι τύπου ttxxxxxxx και για τα πρόσωπα nmxxxxxxx. Ο τύπος και το πλήθος των στοιχείων για κάθε ταινίας δεν είναι αναγκαία παρόμοια για όλες τις ταινίες, και αυτό εξυπηρετεί κατά κάποιο βαθμό στην λογική των μεγάλων πινάκων της HBase. Τα στοιχεία συλλέγηκαν σε τέσσερα αρχεία. Ένα αρχείο περιέχει σε κάθε γραμμή τα στοιχεία για κάθε μια από τις ταινίες, σε ένα άλλο υπάρχουν τα στοιχεία για τα διάφορα πρόσωπα που λαμβάνουν μέρος με κάποιο τρόπο στις ταινίες, ένα αρχείο με τις αντιστοιχίσεις ταινιών προσώπων και ακόμα ένα αρχείο το οποίο περιείχε την αντιστοιχία μεταξύ ταινιών και των ειδών που την περιγράφουν. 65

80 Πειραματική Σύγκριση HBase και Neo4j Προεπεξεργασία δεδομένων Αρχικά, αξίζει να αναφερθεί ότι ο κώδικας, σε όλα τα προγράμματα είναι γραμμένος σε Java και χρησιμοποιεί βιβλιοθήκες τόσο του JRE του Hadoop, της HBase και του Neo4j αντίστοιχα με την εφαρμογή. Μπορεί να μεταγλωττιστεί σε εκτελέσιμη μορφή αρχείου.jar είτε με χρήση τους προγραμματιστικού περιβάλλοντος του Eclipse. Στην συνέχεια το jar αρχείο τοποθετείται, στην περίπτωση που εκτελεί λειτουργίες του Hadoop ή του HBase στον κατάλογο ~/, ενώ αν εκτελεί λειτουργίες του Neo4j στο κατάλογο /opt/neo4j_home/lib. Τα αρχεία με τα στοιχεία πρέπει να ανέβουν στο κατανεμημένο σύστημα αρχείων ώστε να περάσουν από μια σειρά διαδικασιών MapReduce για να καθαριστούν και να μετατραπούν στις επιθυμητές μορφές. Αρχικά τα αρχεία μεταφέρονται στον master υπολογιστή του cluster με ένα πρόγραμμα scp και στην συνέχεια ανεβαίνουν στο HDFS. Τα αρχεία αυτά περιείχαν διάφορες γραμμές «σκουπίδια» καθώς και κάποιες γραμμές που επαναλαμβάνονταν λόγω του τρόπου λειτουργίας των API s. Για αυτό τον λόγο μπορούμε με μεγάλη ευκολία να χρησιμοποιήσουμε το MapReduce framework για να καθαρίσουμε αυτά τα αρχεία και να τα μετατρέψουμε σε μια επιθυμητή μορφή, τύπου κλειδί-τιμές, ώστε να μπορούμε στην συνέχεια να δημιουργήσουμε τις βάσεις μας στα δύο συστήματα που χρησιμοποιήθηκαν για την σύγκριση. Στις παρακάτω εντολές το πρώτο όρισμα μετά την κλάση που εκτελείτε είναι το αρχείο εισόδου από το HDFS και τα επόμενα τα αρχεία που παράγονται ώστε να χρησιμοποιηθούν στην συνέχεια. Σε αυτό το σημείο έχουμε τα τελικά αρχεία στο HDFS τα οποία πλέον περιέχουν όλες τις πληροφορίες που έχουμε σε μορφή ώστε να μπορούν να αναπαρασταθούν σε πίνακες στην HBase ή στην δημιουργία του γράφου στο Neo4j Κατασκευή πινάκων στην HBase Στην συνέχεια κατασκευάζουμε τους αντίστοιχους πίνακες στην HBase και τοποθετούμε τα δεδομένα που έχουμε συλλέξει με την διαδικασία Bulk Load που περιεγράφηκε στο κεφάλαιο 4 παρουσίασης της HBase. Στην συνέχεια θα παρουσιαστεί το τελικό schema που χρησιμοποιήθηκε στην HBase. Λόγω του τρόπου που γίνονται οι αναζητήσεις σε πίνακες της HBase εύκολα καταλήγουμε στον σημαντικό ρόλο που παίζουν κάποια ανεστραμμένα ευρετήρια τα οποία δημιουργούνται παρακάτω. Ο χρήστης εκτελεί ερωτήματα με διάφορες λέξεις. Ο πίνακας έχει ως κλειδί κάτι το οποίο είναι μοναδικό για κάθε γραμμή του πίνακα. Αυτό δεν περιορίζει τα δεδομένα μέσα σε δύο γραμμές να είναι διαφορετικά. Για παράδειγμα, κάποιες ταινίες πολύ συχνά έχουν τον ίδιο τίτλο. Το μόνο που μπορεί να τις ξεχωρίσει σε μία βάση είναι το διαφορετικό αναγνωριστικό. Αυτό μπορεί να εμφανιστεί και σε πολλές εφαρμογές που αποθηκεύουν αντίστοιχου είδους δεδομένα. Επίσης, είναι εμφανές ότι αν δεν κατασκευάζαμε ευρετήρια θα οδηγούμασταν σε εξαντλητικές αναζητήσεις που ο χρόνος τους θα ήταν απαγορευτικός και πιθανό να μην έδιναν ποτέ αποτελέσματα. Έτσι προχωρήσαμε στην επιλογή να κατασκευαστούν δύο ανάστροφα 66

81 Πειραματική Σύγκριση HBase και Neo4j ευρετήρια, ένα σε σχέση με τις λέξεις που εμφανίζονται στους τίτλους των ταινιών και ένα σε σχέση με τα ονόματα των ατόμων που συμμετέχουν, και οι δύο με αντιστοίχιση στα κλειδιά των ταινιών και των ατόμων αντίστοιχα HBase Schema Το τελικό σχήμα, που χρησιμοποιήθηκε για την εκτέλεση των ερωτημάτων στην βάση, περιέχει έξι πίνακες στην HBase ώστε να μπορέσουμε να δούμε πως επηρεάζουν τα joins, τα οποία κατασκευάστηκαν προγραμματιστικά, την απόδοση του συστήματος. Ο παρακάτω πίνακας περιγράφει το σχήμα με κάποια βασικά χαρακτηριστικά για τον κάθε πίνακα. ΗTable index key=words m2p key=id_movie movies key=id_movie p2m key=id_person person_index key=word persons key=id_person Περιγραφή {NAME => 'index', FAMILIES => [{NAME => 'movies', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '1', VERSIONS => '3', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => ' ', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', ENCODE_ON_DISK => 'true', BLOCKCACHE => 'true'}]} {NAME => 'm2p', FAMILIES => [{NAME => 'persons', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '1', VERSIONS => '3', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => ' ', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', ENCODE_ON_DISK => 'true', BLOCKCACHE => 'true'}]} {NAME => 'movies', FAMILIES => [{NAME => 'details', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '1', COMPRESSION => 'NONE', VERSIONS => '3', TTL => ' ', MIN_VERSIONS => '0', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', ENCODE_ON_DISK => 'true', IN_MEMORY => 'false', BLOCKCACHE => 'true'}, {NAME => 'details2', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '0', VERSIONS => '3', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => ' ', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', ENCODE_ON_DISK => 'true', BLOCKCACHE => 'true'}]} {NAME => 'p2m', FAMILIES => [{NAME => 'movies', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '1', VERSIONS => '3', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => ' ', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', ENCODE_ON_DISK => 'true', BLOCKCACHE => 'true'}]} {NAME => 'person_index', FAMILIES => [{NAME => 'p_ids', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '1', VERSIONS => '3', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => ' ', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', ENCODE_ON_DISK => 'true', BLOCKCACHE => 'true'}]} {NAME => 'persons', FAMILIES => [{NAME => 'details', DATA_BLOCK_ENCODING => 'NONE', BLOOMFILTER => 'NONE', REPLICATION_SCOPE => '1', VERSIONS => '3', COMPRESSION => 'NONE', MIN_VERSIONS => '0', TTL => ' ', KEEP_DELETED_CELLS => 'false', BLOCKSIZE => '65536', IN_MEMORY => 'false', ENCODE_ON_DISK => 'true', BLOCKCACHE => 'true'}]} Αποθηκευτικός Χώρος Αφού έχουν φορτωθεί τα δεδομένα είδαμε τη διαφορά μεταξύ των δύο συστημάτων σε σχέση με την αποθήκευση για τα ίδια δεδομένα που περιγράφονται στο παρόν υπό-τμήμα και με βάση τις επιλογές σχεδιασμού που φαίνονται στα παραπάνω. Μπορούμε να δούμε ότι η επιλεγείσα HBase παίρνει περίπου 2 φορές λιγότερο χώρο από ό,τι η Neo4j Store. 67

82 Πειραματική Σύγκριση HBase και Neo4j Storage (MB) Neo4j Hbase Σχήμα 5.1 Αποθηκευτικός Χώρος Υλοποιήσεων Neo4j Schema Τα πράγματα στο Neo4j είναι αρκετά πιο απλά. Τα αρχεία με τα καθαρά δεδομένα τα κατεβάζουμε από το HDFS στο μηχάνημα το οποίο θα κατασκευάσουμε τον αρχικό γράφο, ο οποίος αυτόματα στην συνέχεια θα αντιγραφεί και στα υπόλοιπα μηχανήματα του cluster. Ο γράφος, όπως αναφέρεται στο αντίστοιχο κεφάλαιο περιγραφής του Neo4j, περιέχει κόμβους και σχέσεις που μπορούν να περιέχουν διάφορες ιδιότητες. Οι οντότητες του γράφου είναι οι ταινίες, τα πρόσωπα και οι τύποι των ταινιών. Τους διαφορετικούς τύπους των ταινιών τους βρίσκουμε εύκολα με μια MapReduce εργασία αναλύοντας τους από το αρχείο που περιέχει τους τύπους σε σχέση με τις ταινίες. Κάθε ταινία, πρόσωπο και τύπος είναι ένα ξεχωριστός κόμβος. Κάποιες από τις ιδιότητες των ταινιών είναι το μοναδικό αναγνωριστικό, ο τίτλος, η χρονιά κυκλοφορίας, κάποια links και η σύνοψη της ταινίας. Επίσης υπάρχουν χαρακτηριστικά για τα πρόσωπα καθώς και για τους τύπους ταινιών. Για τον λόγο ότι τα δεδομένα είναι σε ξεχωριστά αρχεία δεν κατασκευάζουμε τους κόμβους ταυτόχρονα με τις σχέσεις. Αυτό μπορεί να γίνει μόνο σε περιπτώσεις που υπάρχει αρχικά ένας γράφος και στην συνέχεια προστίθενται νέα στοιχεία σε αυτό. Άρα αρχικά κατασκευάζουμε τους κόμβους και στην συνέχεια τοποθετούμε τις σχέσεις μεταξύ τους. Μία καλή πρακτική ώστε να μην χρειάζεται να διατρέχουμε για τα ερωτήματα ολόκληρο τον γράφο είναι να χρησιμοποιήσουμε indexes. Για αυτό τον λόγο κατά την δημιουργία κάθε κόμβου τον προσθέτουμε, ανάλογα με τον τύπο της οντότητας, στο αντίστοιχο ευρετήριο της οντότητας. Για τους σκοπούς των πειραμάτων που εκτελέστηκαν, για τους κόμβους των ταινιών, η δεικτοδότηση με τύπο κειμένου γίνεται με βάση το αναγνωριστικό και τον τίτλο και η δεικτοδότηση με τύπο αριθμητικό γίνεται με βάση την χρονιά κυκλοφορίας. Για τους κόμβους που ανήκουν στην οντότητα των ατόμων πάλι γίνεται indexing στα ονόματα και τα αναγνωριστικά, καθώς και στου τύπους ταινιών στο όνομα του τύπου. Το indexing στα αναγνωριστικά χρειάζεται για την σύνδεση των κόμβων μεταξύ τους με την αντίστοιχη σχέση, εφόσον υπάρχουν τα αρχεία που δείχνουν με αναγνωριστικά την σύνδεση 68

83 Πειραματική Σύγκριση HBase και Neo4j μεταξύ προσώπων και ταινιών καθώς και την σύνδεση μεταξύ ταινιών και των τύπων τους. Αυτό μπορεί να γενικευτεί σε άλλες αντίστοιχες εφαρμογές που έχουν δεδομένα που συνδέονται μεταξύ τους. Διαβάζοντας αυτά τα αρχεία βρίσκουμε από το indexing τους αντίστοιχους κόμβους καθορίζουμε ποιος είναι έναρξη και ποιος παραλήπτης και τοποθετείται ανάμεσα η σχέση που τα περιγράφει. Αν είναι μεταξύ ταινίας και ανθρώπου τότε τοποθετείται σχέση τύπου PART_OF και αν είναι μεταξύ ταινίας και κάποιου τύπου τοποθετείται μια σχέση τύπου TYPE. Έτσι έχουμε κατασκευάσει τον γράφο και με το ξεκίνημα των Neo4j instances των υπόλοιπων μηχανημάτων που ανήκουν στο cluster αντιγράφεται σε αυτά. Ο τελικός γράφος περιέχει περίπου κόμβους, ιδιότητες και σχέσεις. Στο παρακάτω σχήμα 5.2 υπάρχει ένα πολύ μικρό κομμάτι του γράφου από το web UI. Σχήμα 5.2 Μέρος του Neo4j γράφου 5.2 Δημιουργία και εκτέλεση ερωτημάτων Για τους διάφορους τύπους ερωτημάτων που θα αναλυθούν παρακάτω κατασκευάστηκαν κάποια τυχαία ερωτήματα. Με τον όρο ερωτήματα εννοούμε τα ορίσματα που παίρνει η διαδικασία που περιγράφεται εντός μιας κλάσης για την εκτέλεση ενός ερωτήματος στην βάση. Στην περίπτωση του Neo4j υπάρχουν ερωτήματα που εκτελούνται με χρήση του API του Neo4j και κάποια που εκτελούνται με χρήση της γλώσσας Cypher. Όλα τα ερωτήματα εκτελούνται από κλάσεις που καλούνται εντός.jar αρχείων και με ορίσματα από την γραμμή εισόδου. Για αυτούς τους λόγους κατασκευάστηκε ένα script, το query_engine.sh, το οποίο παράγει αριθμό αντίστοιχων ερωτημάτων για τις δύο βάσεις που συγκρίνουμε. Στα πλαίσια των πειραμάτων που εκτελέστηκαν κατασκευάστηκαν 1000 ερωτήματα για το κάθε είδος ερωτήματος και εκτελέστηκαν ώστε να πάρουμε τους μέσους χρόνους εκτέλεσης τους και να καταλήξουμε σε κάποια πιο γενικά συμπεράσματα. 69

84 Πειραματική Σύγκριση HBase και Neo4j 5.3 Ερωτήματα και Αποτελέσματα Πειραμάτων Για την πειραματική αξιολόγηση γράφτηκαν διαφορετικά σενάρια ερωτημάτων που θα μπορούσε να ζητηθεί σε μια βάση δεδομένων ταινιών. Στη διαδικασία αυτή, τα ερωτήματα γράφτηκαν έτσι ώστε σε περίπτωση που τα δεδομένα αντιπροσωπεύουν κάτι διαφορετικό, για να υπάρχει γενίκευση των αποτελεσμάτων. Έχει γραφεί κώδικας για μια ποικιλία τύπων ερωτημάτων από απλά σε πιο σύνθετες και εκτελείται ένας πολύ μεγάλο αριθμός από κάθε κατηγορία. Παρακάτω, περιγράφουμε τη λογική ερωτήματα και παρέχουν παραδείγματα ερωτημάτων. Η HBase δεν υποστηρίζει οποιαδήποτε γλώσσα για τα ερωτήματα γι 'αυτό έχουν προγραμματιστεί χρησιμοποιώντας το Java API. Το Neo4j υποστηρίζει Cypher γλώσσα και έχει τη δυνατότητα να είναι σε θέση να δώσει αυτόματα τα διάφορα ερωτημάτων με πιο απλές εντολές. Σε μερικές περιπτώσεις, χρησιμοποιούμε Java API που παρέχεται από Neo4j για την εκτέλεση των απλών ερωτημάτων Ανάλυση Ερωτημάτων Απλά Aggregate ερωτήματα Q1: Αυτά τα ερωτήματα υπολογίζουν και να επιστρέφουν το πληθάριθμο των αντικειμένων σε ένα συγκεκριμένο χαρακτηριστικό με διαφορετικό αριθμό τιμών χαρακτηριστικών, χρησιμοποιώντας τους τελεστές AND και OR. COUNT the movies WHERE contain the word word1 in title or synopsis COUNT the movies WHERE contain the words word1 AND word2 in title COUNT the movies WHERE contain the words word1 OR word2 OR word3 in synopsis Q2: Αυτό το ερώτημα χρησιμοποιεί την ίδια λογική όπως και παραπάνω, αλλά αυτή τη φορά επιστρέφει επίσης τα αρχεία υπακούοντας η λογική έκφραση AND μεταξύ χαρακτηριστικό των τιμών. Σε αυτή την περίπτωση χρησιμοποιείται ένα ανεστραμμένο ευρετήριο για να βρείτε τις τα κλειδιά των ταινιών και στη συνέχεια θα γίνει το join με τον HBase πίνακα που περιέχει τις πληροφορίες για την εν λόγω ταινίες. Τα joins δεν υποστηρίζονται οπότε έπρεπε να προγραμματιστούν με το χέρι. Ειδικότερα, γίνονται ενώσεις μεταξύ των πινάκων γιατί γνωρίζουμε ποιες γραμμές θα ανακτώνται από τα κλειδιά ου αποτελέσματος στο πρώτο βήμα του ερωτήματος. FIND the movies WHERE contain the words word1 AND word2 AND AND wordn in title or synopsis and RETURN the information stored Q3: Αυτό το ερώτημα είναι κατά βάση ίδιο με το ερώτημα Q2 αλλά αυτή την φορά είμαστε σίγουροι ότι το ερώτημα θα ανακτήσει δεδομένα με τη λογική έκφραση AND. Αυτό το ερώτημα είναι σημαντικό για εφαρμογές που θα μπορούσαν να χρησιμοποιήσουν τα δεδομένα με αυτόματη συμπλήρωση και δεν επιτρέπουν προσαρμοσμένο κείμενο από το χρήστη. 70

85 Πειραματική Σύγκριση HBase και Neo4j FIND the movies WHERE contain the words < word1, word2 > in title and RETURN the information stored Ερωτήματα εύρους (Range Queries) Q4-Q5: Και τα δύο αυτά ερωτήματα που εκτελούνται σε ένα χαρακτηριστικό. Το πρώτο ερώτημα (Q4) επιστρέφει εγγραφές λεξικογραφικά κοντά στις τιμές των χαρακτηριστικών του ερωτήματος. Αυτό το είδος της ερώτησης είναι δημοφιλές μεταξύ των εφαρμογών που ο χρήστης μπορεί να γράψει ελεύθερο κείμενο οπότε ίσως έχει ανορθόγραφη λέξη ή δεν πληκτρολογήστε το όλη τη λέξη. Το δεύτερο ερώτημα (Q5) επιστρέφει μόνο τις εγγραφές που ταιριάζουν ακριβώς. Τα δύο ερωτήματα κάνουν ένωση σε 3 πίνακες HBase για να παράγουν τα αποτελέσματα. Η ένωση έχει προγραμματιστεί με βέλτιστο τρόπο έτσι ώστε κάθε προηγούμενο βήμα join παράγει μικρότερο πλήθος αποτελεσμάτων από το επόμενο. (Q4) FIND the people WHERE their name looks like the text name and RETURN the information stored for them and their movies (Q5) FIND t h e people WHERE their name contains t h e text name and RETURN the information stored for them and their movies Τα ακόλουθα 2 ερωτήματα είναι πιο περίπλοκα. Q6: Αυτό το ερώτημα παίρνει ως είσοδο δύο χαρακτηριστικά των δεδομένων και περιλαμβάνει 2 πίνακες HBase, οπότε 1 join. Το Neo4j ερώτημα πρέπει να βρει τους κόμβους από το ευρετήριο για το πρώτο χαρακτηριστικό και ταυτόχρονα να κοιτάξει στο εσωτερικό αυτών των κόμβων για το δεύτερο χαρακτηριστικό. FIND the movies WHERE contain the words word1 AND word2 and their year production is in the range [year1,year2] and RETURN the information stored Q7: Αυτό το ερώτημα παίρνει ως είσοδο τρία χαρακτηριστικά των δεδομένων και περιλαμβάνει 2 πίνακες HBase, οπότε 1 join. Όπως και πριν, το Neo4j χρησιμοποιεί το ευρετήριο και στη συνέχεια πρέπει να κοιτάξουμε μέσα στον κόμβο για τις υπόλοιπες πληροφορίες. FIND the movies WHERE contain the words word1 AND word2, their year production is in the range [year1, year2] and the movies genres must be [genre1, genre2,...] and RETURN the information stored Ερωτήματα Ομαδοποίησης (Group-By Queries) Αυτά τα ερωτήματα είναι βασικά τα ίδια ερωτήματα που εκτελέστηκαν στα διαφορετικά χαρακτηριστικά για να δούμε πώς ο σχεδιασμός των πινάκων δεικτοδότησης στην HBase και των fat κόμβων στο Neo4j μπορεί να επηρεάσει αυτό το είδος των ερωτημάτων. Q8: Αυτό το ερώτημα ομαδοποιεί τα αποτελέσματα σε ένα χαρακτηριστικό για ένα εύρος τιμών. Αυτό το χαρακτηριστικό δεν υπάρχει σε κάποιο ευρετήριο τόσο στην HBase όσο και στο Neo4j. 71

86 Πειραματική Σύγκριση HBase και Neo4j FIND the movies WHERE contain the words word1 AND word2, the year production is in the range [year1,year2] and the movies genres must be [genre1, genre2,...] and GROUP BY year Q9: Αυτή η περίπτωση ομαδοποιεί τα αποτελέσματα σε ένα χαρακτηριστικό, και αν υπάρχουν περισσότερα από ένα, συνδέονται με τον τελεστή AND. Αυτή τη φορά, χρησιμοποιήσαμε τον πίνακα δεικτοδότησης της HBase και τους fat κόμβους για κάθε αντικείμενο αυτού του χαρακτηριστικού. FIND the movies WHERE contain the words word1 AND word2, the year production is in the range [year1,year2] and the movies genres must be [genre1, genre2,...] and GROUP BY genre Q10: Αυτό το ερώτημα είναι ακόμη πιο περίπλοκο, γιατί είναι ένας συνδυασμός και των δύο προηγούμενων ερωτημάτων (Q8 και Ε9). FIND the movies WHERE contain the words word1 AND word2, the year production is in the range [year1,year2] and the movies genres must be oneof [genre1, genre2,...] and GROUP BY year and genre Ερωτήματα Top-K Q11: Το τελευταίο ερώτημα που εξετάστηκε ήταν top-k. Χρησιμοποιήσαμε το πιο πολύπλοκο ερώτημα, αλλά αυτή τη φορά δεν επιστρέφαμε όλα τα αποτελέσματα. Γι 'αυτό και έπρεπε να ταξινομήσετε τα υποψήφια αποτελέσματα σε ένα συγκεκριμένο χαρακτηριστικό για να δούμε πώς αυτό επηρεάζει και τα δύο συστήματα. Έτρεξαν πειράματα σε τυχαίες τιμές του k. FIND the movies WHERE contain the words word1 AND word2, the year production is in the range [year1,year2] and the movies genres must be one of [genre1, genre2,...] and RETURN the TOP-K GROUP BY year and genre Ανάλυση Αποτελεσμάτων Δημιουργήσαμε πειραματικά σενάρια για κάθε ερώτημα που περιεγράφηκε πιο πάνω. Κάθε σενάριο περιέχει ένα πολύ μεγάλο αριθμό ερωτημάτων που εκτελούνται και στα δύο συστήματα. Αυτή η μέθοδος είναι παρόμοια με μέθοδο bulk loading, αλλά αντί αυτού των δεδομένων φόρτωσης εκτελούμε προκαθορισμένα ερωτήματα. Έτσι τα αποτελέσματα που περιγράφονται παρακάτω δείχνουν το latency, που είναι ο μέσος χρόνος που απαιτείται για να ολοκληρωθεί η εκτέλεση ενός ερωτήματος. Επιπλέον, η ανάλυση που ανταποκρίνεται στην επιμερισμένη ανάλυση. Η Επιμερισμένη πολυπλοκότητα (Amortized complexity) λέει ότι εξετάζει μια σειρά ενεργειών του ίδιου τύπου του προγράμματος, επιτρέπει την θέσπιση ενός ορίου χειρότερης περίπτωσης για την εκτέλεση ενός προγράμματος. Στην περίπτωσή μας, ένα πρόγραμμα αντιστοιχεί σε ένα ερώτημα. Η ανάλυση αυτή ισχύει και όταν ο χρόνος εκτέλεσης είναι διαφορετικός και δεν υπάρχει κάποια ένδειξη για την πραγματική πολυπλοκότητα ενός αλγορίθμου. Η επιμερισμένη πολυπλοκότητα μπορεί να υπολογιστεί χρησιμοποιώντας A t = 72

87 Πειραματική Σύγκριση HBase και Neo4j n i=1 T(q i ) n, όπου το T(q i ) είναι ο χρόνος εκτέλεσης ενός query και n είναι ο συνολικός αριθμός ερωτημάτων που εκτελούνται. Σχήμα 5.3 Αποτελέσματα Πειραμάτων Σύγκρισης Ερωτημάτων Το Σχήμα 5.3 δείχνει, σε λογαριθμική κλίμακα χιλιάδων miliseconds, ο μέσος χρόνος εκτέλεσης για κάθε ερώτημα και στα δύο συστήματα. Είναι προφανές ότι για την πρώτη κατηγορία ερωτημάτων η HBase έχει καλύτερη απόδοση από το Neo4j, αλλά καθώς τα ερωτήματα γίνονται πιο σύνθετα παρατηρούμε ότι υπάρχει μια εναλλαγή στην απόδοση μεταξύ των δύο συστημάτων. Και τα δύο συστήματα, όπως παρατηρούμε, στο Σχήμα 5.3 (a) υπάρχει πτώση στο χρόνο εκτέλεσης τους, όταν η αναζήτηση είναι πιο συγκεκριμένη (AND τελεστής). Όταν η HBase ερωτάται για συγκεκριμένα κλειδιά και ως εκ νέου το αποτέλεσμα προκύπτει από τις στήλες χωρίς περισσότερες πληροφορίες η HBase ξεπερνά σε απόδοση το Neo4j κατά πολύ. Μπορούμε επίσης να δούμε από Q2 ότι η μερική "ένωση" (partial join) σε πίνακες της HBase δεν επηρεάζει το χρόνο εκτέλεσης σε μεγάλο βαθμό. Η απόδοση Q3 είναι ελαφρώς καλύτερη σε Neo4j σε σύγκριση με τα προηγούμενα ερωτήματα στο ίδιο σύστημα και αυτό γιατί το Neo4j μπορεί να 73