ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ. ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ

Transcript

1 ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ Μελέτη ανάπτυξης συστημάτων διαχείρισης RDF δεδομένων, NoSQL εργαλείων και πειραματική αξιολόγηση των ΜΜ Αθήνα, Οκτώβριος 2015

2 - 2 -

3 Περίληψη Στις μέρες μας έχει σημειωθεί μεγάλη αύξηση της δημοτικότητας των Linked Data, τα οποία μετατρέπουν τον παγκόσμιο ιστό σε μία παγκόσμια βάση δεδομένων. Πρόκειται πλέον όχι μόνο για απλή παρουσίαση των δεδομένων στο διαδίκτυο αλλά για την πραγματοποίηση συνδέσεων, έτσι ώστε ένα άτομο ή μηχανή να μπορεί να εξερευνήσει το διαδίκτυο των δεδομένων και να βρει άλλα, σχετικά δεδομένα. Ο όρος Linked Open Data αναφέρεται στα διασυνδεδεμένα δεδομένα τα οποία είναι ανοιχτού περιεχομένου (open content) και επομένως είναι δημοσιευμένα με ελεύθερη άδεια χρήσης και είναι εφικτό να επαναχρησιμοποιηθούν. Για να γίνει πραγματικότητα ο Παγκόσμιος Ιστός των Δεδομένων (Web of Data), είναι σημαντικό ο τεράστιος όγκος των δεδομένων να είναι διαθέσιμος σε μία τυποποιημένη μορφή. Το RDF framework αποτελεί ένα από τα κύρια συστατικά των Linked Data και παρέχει ένα γενικευμένο μοντέλο δεδομένων γράφου για την περιγραφή πραγμάτων, συμπεριλαμβανομένων των σχέσεων τους με άλλα πράγματα. Στο μοντέλο, η περιγραφή ενός πόρου αναπαρίσταται σαν ένα σύνολο από τριπλέτες (triples), η οποία αποτελείται από 3 μέρη: <υποκείμενο (subject), κατηγόρημα (predicate) και αντικείμενο (object)>. Οι RDF τριπλέτες αποθηκεύονται σε έναν τύπο βάσης δεδομένων που αποκαλείται triplestore. Παρόμοια με μία σχεσιακή βάση δεδομένων, τα triplestores είναι βελτιστοποιημένα για να αποθηκεύουν τριπλέτες και γίνεται ανάκτηση των δεδομένων μέσω μίας γλώσσας επερωτήσεων. Η κυρίαρχη γλώσσα επερωτήσεων για γράφους RDF είναι η SPARQL. Εκπρόσωπος των Linked Open Data είναι η DBpedia, η οποία αποτελεί μια συλλογική προσπάθεια για την εξαγωγή και επαναχρησιμοποίηση δομημένης πληροφορίας από την Wikipedia. Ένας από τους στόχους της DBpedia είναι να προσφέρει δυνατότητα αναζήτησης και εκτέλεσης πολύπλοκων επερωτήσεων μία ευρεία κοινότητα. Παράλληλα, γίνεται μελέτη των NoSQL συστημάτων, τα οποία παρέχουν ένα μηχανισμό για την αποθήκευση και την ανάκτηση των δεδομένων που μοντελοποιείται πέρα από σχέσεις πινάκων και έχουν κατασκευαστεί για να επιτρέπουν την εισαγωγή των - 3 -

4 δεδομένων χωρίς ένα προκαθορισμένο σχήμα. Τα NoSQL συστήματα πλεονεκτούν έναντι των RDBMS, όταν έχουν να αντιμετωπίσουν μεγάλο πλήθος δεδομένων και παράλληλη επεξεργασία και ειδικά όταν τα δεδομένα δεν απαιτούν σχεσιακή μοντελοποίηση. Κατηγοριοποιούνται σε Key value stores, Document databases, Column family stores, Graph databases. Η ανάδειξη των NoSQL βάσεων δεδομένων οφείλεται στο γεγονός ότι ο ψηφιακός κόσμος αυξάνεται γρήγορα και γίνεται ολοένα και πιο πολύπλοκος όσον αφορά στο μέγεθος (volume), στην ταχύτητα (velocity) και στην ποικιλομορφία (variety). Σκοπός της διπλωματικής εργασίας είναι να γίνει μία εισαγωγή στο θεωρητικό υπόβαθρο σχετικά με τις παραπάνω έννοιες. Στη συνέχεια, ακολουθεί καταγραφή και σύντομη παρουσίαση υπαρχόντων συστημάτων διαχείρισης RDF δεδομένων και συγκεκριμένα των Jena, Sesame, AllegroGraph και Virtuoso. Στη συνέχεια θα πραγματοποιηθεί καταγραφή κατηγοριών NoSQL συστημάτων. Θα ακολουθήσει η λεπτομερής ανάλυση συγκεκριμένων εκπροσώπων των κατηγοριών αυτών. Συγκεκριμένα των HBase, MongoDB και Neo4j. Επόμενο βήμα είναι η προσπάθεια αξιολόγησής τους χρησιμοποιώντας RDF δεδομένα. Έχει αποφασιστεί πως τα RDF δεδομένα που θα χρησιμοποιηθούν είναι της DBPedia. Για την εύκολη εξαγωγή των δεδομένων θα υλοποιηθεί λογισμικό το οποίο μπορεί και τρέχει, χρησιμοποιώντας εύκολο περιβάλλον διεπαφής, SPARQL ερωτήματα σε οποιοδήποτε Virtuoso Endpoint. Μέρος των δεδομένων της DBpedia, αφού εξαχθούν με το λογισμικό, στη συνέχεια, θα εισαχθούν στα τρία παραπάνω NoSQL συστήματα κατόπιν κατάλληλης επεξεργασίας και θα γίνει καταγραφή των συμπερασμάτων. Λέξεις Κλειδιά: Σημασιολογικός Ιστός, Διασυνδεδεμένα δεδομένα, Ανοιχτά Διασυνδεδεμένα δεδομένα, RDF μοντέλο, RDF αποθήκες, NoSQL βάσεις δεδομένων, Key-Value, Column-family, Document βάσεις δεδομένων, Graph βάσεις δεδομένων, DBpedia, Hbase, MongoDB, Neo4J - 4 -

5 Abstract Over the last few years we have seen the rise of Linked Data, which makes the World Wide Web into a global database that we call the Web of Data. The Semantic Web isn't just about putting data on the web. It is about making links, so that a person or machine can explore the web of data. With linked data, when you have some of it, you can find other, related, data. The term Linked Open Data refers to Linked Data that is open content, reusable and published under an open license. However, to make the Web of Data a reality, it is important to have the huge amount of data on the Web available in a standard format, reachable and manageable by Semantic Web tools. RDF, the Resource Description Framework, is one of the key ingredients of Linked Data, and provides a generic graph-based data model for describing things, including their relationships with other things. RDF provides a common data model for Linked Data and is particularly suited for representing data on the Web. Linked Data uses RDF as its data model and represents it in one of several syntaxes. In RDF model, a description of a resource is represented as a number of triples. The three parts of each triple are called its subject, predicate, and object. A triplestore or RDF store is a purposebuilt database for the storage and retrieval of triples. Much like a relational database, a triplestore is optimized for the storage and retrieval of triples via a query language. The standard query language is called SPARQL. Large linked open data sets include DBpedia. DBpedia is a community effort to extract structured information from Wikipedia and make this information available on the Web. One of the goals of the DBpedia project is to provide querying and search capabilities to a wide community by extracting structured data from Wikipedia which can then be used for answering expressive queries. In addition, we examine the NoSQL data stores, which are widely used to store and retrieve possibly large amounts of data and are built to allow the insertion of data without a predefined schema. The NoSQL systems are challenging the dominance of relational databases, when you have to deal with a large number of data and parallel processing, - 5 -

6 especially when the data do not require relational modeling. NoSQL databases can broadly be categorized in four types: Key Value Stores, Document Databases, Column family, Graph databases. The emergence of NoSQL databases happens because, the digital world is growing very fast and become more complex in the volume, variety, velocity in nature. In this work, we make an introduction in the theoretical background concerning the concepts that listed above. Then, follows a brief presentation of RDF existing data management systems and in particular of Jena, Sesame, AllegroGraph and Virtuoso. Next, we study all the categories of NoSQL systems and we analyze in detail four specific representatives of these categories. Namely HBase, MongoDB and Neo4j. Eventually, we evaluate these NoSQL Systems using RDF data. The RDF data used for this evaluation effort is DBpedia. For easy data export we develop software which execute SPARQL queries to any Virtuoso Endpoint, using easy interface. After data extraction and processing is done, using the software, we import the data into these 3 NoSQL systems listed above and we the conclusions about query execution. Key Words: Semantic Web, Linked Data, Open Linked Data, RDF model, RDF stores, NoSQL databases, Key-Value stores, Column-family stores, Document databases, Graph databases, DBpedia, Hbase, MongoDB, Neo4J - 6 -

7 Ευχαριστίες Με την παρούσα διπλωματική εργασία ολοκληρώνεται ένας κύκλος σπουδών στο Μεταπτυχιακό Πρόγραμμα Ειδίκευσης στα Πληροφοριακά Συστήματα του Οικονομικού Πανεπιστημίου Αθηνών. Αρχικά θα ήθελα να ευχαριστήσω τον κύριο Ιωάννη Κωτίδη που μου έδωσε την ευκαιρία να εργαστώ πάνω σε ένα σύγχρονο και πολύ ενδιαφέρον αντικείμενο όπως τα RDF και οι NoSQL πλατφόρμες. Τέλος, θα ήθελα να εκφράσω την ευγνωμοσύνη μου στην οικογένειά μου, καθώς η συμβολή και η συμπαράστασή της ήταν πολύτιμη για την περάτωση αυτής της εργασίας και των σπουδών μου

8 Περιεχόμενα Κατάλογος Πινάκων... 9 Κατάλογος Εικόνων Εισαγωγή Θεωρητικό Υπόβαθρo Διασυνδεδεμένα Δεδομένα (Linked Data) RDF μοντέλο RDF Stores Ανοιχτά Διασυνδεδεμένα Δεδομένα DBPedia NoSQL Βάσεις Δεδομένων Εισαγωγή Κατηγορίες Μελέτη NoSQL αποθηκών Υλοποίηση Σχήμα Δεδομένων Virtuoso Query Data Tool Περιγραφή Benchmarking Περιβάλλοντος Αξιολόγηση Εισαγωγή δεδομένων Ανάκτηση δεδομένων Ανάκτηση δεδομένων ύστερα από ομαδοποίηση Ανάκτηση δεδομένων υπο συνθήκη

9 4 Συμπεράσματα και Μελλοντική έρευνα Σχετικές εργασίες Βιβλιογραφικές Αναφορές Παράρτημα Α Kλάσεις αντικείμενων για τα αποτελέσματα Header Detail Row Row Detail Κλάσεις αντικειμένων για τα ερωτήματα Result Query Builder Client Βασική λειτουργικότητα Κατάλογος Πινάκων Πίνακας 2-1: 5-Star Scheme for Open Linked Data Πίνακας 2-2: DBpedia - κλάση Album [33] Πίνακας 2-3: DBpedia - ιδιότητες της κλάσης Album [33] Πίνακας 2-4: Πλεονεκτήματα και Μειονεκτήματα της HBase Πίνακας 2-5: Εφαρμογές αλληλεπίδρασης με το Hadoop Πίνακας 2-6: SQL vs MongoDB statement

10 Πίνακας 2-7: SQL vs Cypher statement Πίνακας 3-1: Χαρακτηριστικά Host μηχανήματος Πίνακας 3-2: HBase Virtual Machine Πίνακας 3-3: MongoDB Virtual Machine Πίνακας 3-4: Neo4J Virtual Machine Πίνακας 4-1 Πίνακας συμπερασμάτων Κατάλογος Εικόνων Εικόνα 2-1: Linked datasets, Αύγουστος 2014 Πηγή: 21 Εικόνα 2-2: Αρχιτεκτονική Επισκόπηση του Jena [15] Εικόνα 2-3: Αρχιτεκτονική Επισκόπηση του Sesame [15] Εικόνα 2-4: Αρχιτεκτονική του AllegroGraph client server [15] Εικόνα 2-5 Technical Αρχιτεκτονική του Virtuso [43] Εικόνα 2-6 Conseptual Αρχιτεκτονική του Virtuoso [43] Εικόνα 2-7: Απεικόνιση mapping του Ελληνικού και Αγγλικού template για το Βιβλίο στην ίδια κλάση της οντολογίας της Dbpedia [35] Εικόνα 2-8: Datasets linked from Dbpedia [35] Εικόνα 2-9: Example of a Typical Key/Value Domain [24] Εικόνα 2-10: Document data model Πηγή: 44 Εικόνα 2-11: Column Family Store - data model [26] Εικόνα 2-12: Απεικόνιση πίνακα Customer Address και η σχέση τους σε RDBMS.. 46 Εικόνα 2-13: Απεικόνιση δεδομένων και σχέσης Customer - Address σε Column - family ΒΔ

11 Εικόνα 2-14: Graph NoSQLDatabase Πηγή: 48 Εικόνα 2-15: Πίνακας στην Hbase [37] Εικόνα 2-16: Αναπαράσταση γραμμής στην HBase ως πολυδιάστατος χάρτης [37] Εικόνα 2-17: Απεικόνιση πίνακα στην HBase ως key-value store [37] Εικόνα 2-18: Η δομή μίας εγγραφής στη MongoDB Πηγή: 57 Εικόνα 2-19: Παράδειγμα εγγράφου στη MongoDB Πηγή: 58 Εικόνα 2-20: Συσχέτιση μέσω References στη MongoDB Πηγή: 59 Εικόνα 2-21: Συσχέτιση μέσω Embedded εγγράφου στη MongoDB Πηγή: 59 Εικόνα 2-22: Τα building blocks του Property Graph [41] Εικόνα 2-23: Παράδειγμα μοντέλου δεδομένων Labeled Property Graph [41] Εικόνα 2-24: Μοντελοποίηση σε RDBMS Πηγή: 69 Εικόνα 2-25: Μοντελοποίηση σε γράφο Πηγή: 69 Εικόνα 3-1: Virtuoso Query Data Tool - DBPedia example Εικόνα 3-2: Virtuoso Query Data Tool - IMDB example Εικόνα 3-3: Virtuoso Query Data Tool - GeoData example Εικόνα 3-4: Αποτελέσματα εισαγωγής δεδομένων Εικόνα 3-6 Αποτελέσματα ανάκτησης δεδομένων

12 Εικόνα 3-7 Αποτελέσματα ανάκτησης δεδομένων Εικόνα 3-8 Αποτελέσματα ανάκτησης δεδομένων Εικόνα 4-1: Γραφική Απεικόνιση SPARQL ερωτήματος

13 1 Εισαγωγή Τα τελευταία χρόνια γίνονται μεγάλες προσπάθειες για την υλοποίηση του Semantic Web. Διεθνείς οργανισμοί έχουν ορίσει πρότυπα για όλες τις λειτουργίες που θα πρέπει να εκτελούνται. Βασικό πρότυπο για την αποθήκευση και μεταφορά των δεδομένων είναι το RDF. Σύμφωνα με το RDF τα δεδομένα αποθηκεύονται στην μορφή των triples. Η SPARQL είναι η βασική γλώσσα με την οποία μπορούμε να κάνουμε ερωτήσεις και να επεξεργαζόμαστε RDF δεδομένα. Το διαδίκτυο αναπτύσσεται συνεχώς και τα δεδομένα που περιέχονται σε αυτό αυξάνονται κάθε μέρα και περισσότερο. Αν θέλουμε να υλοποιήσουμε, λοιπόν, το στόχο του Semantic Web, πρέπει να δημιουργήσουμε συστήματα, τα οποία θα είναι σε θέση να χειριστούν το μεγάλο όγκο δεδομένων του διαδικτύου και συγκεκριμένα των RDF. Η απάντηση έρχεται με την άνοδο ενός νέου τύπου βάσεων δεδομένων, γνωστό ως NoSQL βάσεις, οι οποίες αμφισβητούν την κυριαρχία των σχεσιακών βάσεων. NoSQL σημαίνει Not Only SQL, υπονοώντας ότι κατά τη σχεδίαση λογισμικού για μία λύση ή προϊόν, υπάρχουν περισσότεροι από ένας μηχανισμός αποθήκευσης, ο οποίος χρησιμοποιείται ανάλογα με τις ανάγκες. Τα NoSQL συστήματα παρέχουν ένα μηχανισμό για την αποθήκευση και την ανάκτηση των δεδομένων που μοντελοποιείται πέρα από σχέσεις πινάκων και έχουν κατασκευαστεί για να επιτρέπουν την εισαγωγή των δεδομένων χωρίς ένα προκαθορισμένο σχήμα, σε αντίθεση με τις σχεσιακές βάσεις που απαιτούν προκαθορισμένο σχήμα, προτού γίνει εισαγωγή δεδομένων. Αυτό το καθιστά εύκολο να γίνουν σημαντικές αλλαγές στο επίπεδο της εφαρμογής σε πραγματικό χρόνο, χωρίς όμως να ανησυχούμε για διακοπές της υπηρεσίας - που σημαίνει ότι η ανάπτυξη είναι ταχύτερη, η ενσωμάτωση κώδικα είναι πιο αξιόπιστη, και απαιτείται λιγότερος διαχειριστικός χρόνος για τη βάση δεδομένων. Οι προγραμματιστές θέλουν μια πολύ ευέλικτη βάση δεδομένων που μπορεί να φιλοξενήσει εύκολα και αποτελεσματικά τους νέους τύπους δεδομένων και αδόμητα ή ημι-δομημένα δεδομένα. Η schema-based προσέγγιση των σχεσιακών βάσεων καθιστά

14 αδύνατη τη γρήγορη ενσωμάτωση νέων τύπων και δεν παρέχει αποτελεσματική λύση στην αποθήκευση αδόμητων δεδομένων και έτσι οι NoSQL βάσεις έρχονται για να δώσουν λύση, παρέχοντας ένα μοντέλο δεδομένων που καλύπτει καλύτερα τις ανάγκες αυτές. Ταυτόχρονα, τα NoSQL συστήματα επεκτείνονται οριζόντια, γεγονός που σημαίνει ότι για να προστεθεί χωρητικότητα, ο διαχειριστής απλά θα προσθέσει ένα διακομιστή ή ένα cloud instance και αυτόματα η NoSQL βάση θα διαδώσει τα δεδομένα στους διακομιστές όπως απαιτείται. Θα πρέπει να αναφερθεί ότι υπάρχουν ορισμένες κατηγορίες NoSQL συστημάτων: Key-values Stores Column Family Stores Document Databases Graph Databases Η πρώτη κατηγορία, οι key-value stores, δημιουργήθηκαν με κυρίως ιδέα την ύπαρξη ενός hash table όπου υπάρχει ένα μοναδικό κλειδί και ένας δείκτης στοχεύοντας σε ένα συγκεκριμένο στοιχείο. Αυτό το είδος mapping συνήθως συνοδεύεται από μηχανισμούς cache, για την καλύτερη απόδοση του συστήματος. Συνήθως είναι χρήσιμες για την αποθήκευση πληροφοριών των sessions, προφίλ χρηστών, προτιμήσεις, καλάθι αγορών. Καλό είναι να αποφεύγονται όταν χρειάζεται να γίνει επερώτηση στα δεδομένα ή υπάρχουν σχέσεις μεταξύ των δεδομένων ή χρειάζεται να χειρισμός σε πολλαπλά κλειδιά ταυτόχρονα. Οι Column family stores βάσεις σχεδιάστηκαν έτσι ώστε να διαχειρίζονται πολύ μεγάλα ποσά δεδομένων που είναι κατανεμημένα σε διάφορους servers. Όπως και στην προηγούμενη κατηγορία, έτσι κι εδώ υπάρχουν συγκεκριμένα κλειδιά που στοχεύουν όμως σε περισσότερα από ένα στοιχεία. Οι rows εδώ αναγνωρίζονται από ένα μοναδικό row key ενώ οι στήλες είναι οργανωμένες σε column families. Οι Column family βάσεις είναι γενικά χρήσιμες για συστήματα διαχείρισης περιεχομένου, πλατφόρμες blogging, διατήρηση μετρητών, λήξη χρήσης, μεγάλου όγκου εγγραφής, όπως log aggregation. Καλό είναι να αποφεύγονται για συστήματα που είναι

15 σε αρχικό στάδιο ανάπτυξης με μεταβαλλόμενα query patterns. Βασικός εκπρόσωπος της οικογένειας αυτής είναι η HBase. H επόμενη κατηγορία, των Document databases, είναι όμοιες με τις key-value stores. Τα δεδομένα σε αυτή την περίπτωση είναι οργανωμένα από συλλογές key-valued συλλογών δεδομένων. Οι Document βάσεις δεδομένων είναι γενικά χρήσιμες για συστήματα διαχείρισης περιεχομένου, πλατφόρμες blogging, web analytics, real-time analytics, ecommerce εφαρμογές. Καλό είναι να αποφεύγονται για συστήματα που απαιτούν πολύπλοκες συναλλαγές που επεκτείνονται σε πολλαπλές λειτουργίες ή επερωτήσεις σε ποικίλες aggregate δομές. Από τη συγκεκριμένη κατηγορία, εκείνη που θα εξεταστεί σε αυτή την διπλωματική είναι η MongoDB. Τέλος οι Graph databases, είναι βασισμένες σε κόμβους, τις σχέσεις μεταξύ αυτών των κόμβων και τις ιδιότητές τους. Αντί για πίνακες με στήλες και σειρές, εδώ υπάρχει ένα ευέλικτο graph που μπορεί να χρησιμοποιηθεί και να αναπτυχθεί παράλληλα σε πολλά μηχανήματα. Οι Graph βάσεις προσαρμόζονται πολύ καλά σε προβλήματα χώρου όπου υπάρχουν διασυνδεδεμένα δεδομένα, όπως κοινωνικά δίκτυα, δίκτυα χωρικών δεδομένων, πληροφορίες δρομολόγησης αγαθών και χρημάτων, μηχανές προτάσεων (recommendation engines). Στα πλαίσια της διπλωματικής θα επικεντρωθούμε στην Neo4j η οποία είναι από τις πλέον χρησιμοποιούμενες της συγκεκριμένης οικογένειας

16 2 Θεωρητικό Υπόβαθρo 2.1 Διασυνδεδεμένα Δεδομένα (Linked Data) Ο όρος διασυνδεδεμένα δεδομένα (Linked data) χρησιμοποιείται για να περιγράψει μια προτεινόμενη βέλτιστη πρακτική για την έκθεση, την κοινή χρήση και τη σύνδεση δεδομένων, πληροφοριών και γνώσης στο Σημασιολογικό Ιστό (Semantic Web). Ο Σημασιολογικός Ιστός δεν είναι μόνο για την παρουσίαση των δεδομένων στο διαδίκτυο. Πρόκειται για την πραγματοποίηση συνδέσεων, έτσι ώστε ένα άτομο ή μηχανή να μπορεί να εξερευνήσει το διαδίκτυο των δεδομένων και να βρει άλλα, σχετικά δεδομένα. Τα Linked Data αφορούν τεχνολογίες για τη δημοσίευση δομημένων δεδομένων στον παγκόσμιο ιστό, χρησιμοποιώντας τυποποιημένα formats και διεπαφές και αναφέρονται σε δεδομένα που συμμορφώνονται με τις τεχνικές αυτές. Η συλλογή των τεχνολογιών του Σημασιολογικού Ιστού (RDF, OWL, SKOS, SPARQL, κλπ. ), παρέχουν ένα περιβάλλον, όπου μία εφαρμογή μπορεί να θέσει επερωτήσεις στα Linked data, να εξάγει συμπεράσματα χρησιμοποιώντας λεξιλόγια, κλπ. Τα Linked Data έχουν μία σημαντική ιδιότητα: μπορούν εύκολα να συνδυαστούν με άλλα διασυνδεδεμένα δεδομένα για να σχηματίσουν νέα γνώση. Τα Linked Data μετατρέπουν τον παγκόσμιο ιστό σε μία παγκόσμια βάση δεδομένων ή αλλιώς Web of Data. Οι προγραμματιστές μπορούν να θέσουν επερωτήσεις από πολλαπλές πηγές ταυτόχρονα και να τις συνδυάσουν δυναμικά, κάτι που είναι δύσκολο ή αδύνατο να γίνει με τις παραδοσιακές τεχνολογίες διαχείρισης δεδομένων. Στην ουσία, σε ένα μόνο βήμα μπορούν να συγκεντρώσουν όλα τα δεδομένα που χρειάζονται. Τεχνικά, τα Linked data αναφέρονται σε στοιχεία που δημοσιεύονται στο διαδίκτυο με τέτοιο τρόπο, ώστε να είναι αναγνώσιμα από ένα μηχάνημα και ορίζονται σαφώς από το ίδιο το όνομά τους: συνδέονται με άλλα εξωτερικά σύνολα δεδομένων και στη συνέχεια εξωτερικά σύνολα δεδομένων μπορούν να συνδεθούν με αυτά. Ο όρος Linked Data είναι μία έννοια γενικού σκοπού. Κυριολεκτικά, οτιδήποτε μπορεί να περιγραφεί από Linked Data και ο σκοπός είναι να μπορεί κανείς να μοιραστεί τις

17 γνώσεις του με τους άλλους. Ο σκοπός τους επιτυγχάνεται με τη δημοσίευση Linked Data στον παγκόσμιο ιστό, έτσι ώστε να μπορούν να βρεθούν, να διαμοιραστούν και να συνδυαστούν με τα δεδομένα άλλων ανθρώπων. Τα linked data απελευθερώνουν τα δομημένα δεδομένα από τα προσωπικά «αρχεία» του καθενός, ώστε οποιοσδήποτε να μπορεί να τα χρησιμοποιήσει. Τα Linked Data βασίζονται σε 2 τεχνολογίες που έχουν θεμελιώδη σημασία για το Web: URIs (Uniform Resource Identifiers) και το πρωτόκολλο HTTP (HyperText Transfer Protocol). Ενώ τα URLs (Uniform Resource Locators) έχουν γίνει γνωστά ως διευθύνσεις για έγγραφα και άλλες οντότητες που βρίσκονται στο διαδίκτυο, τα URIs παρέχουν ένα πιο γενικευμένο μέσο για τον προσδιορισμό κάθε οντότητας που υπάρχει στον κόσμο. Ο παγκόσμιος ιστός στηρίζεται σε HTML (HyperText Markup Language) έγγραφα που συνδέονται μέσω hyperlinks, τα Linked Data στηρίζονται σε έγγραφα που περιέχουν δεδομένα σε RDF (Resource Description Framework) format. Τα Linked Data δεν αρκούνται στο να συνδέσουν απλά τα έγγραφα αυτά, αλλά, χρησιμοποιώντας RDF, δημιουργούν δηλώσεις που συσχετίζουν αυθαίρετα πράγματα στον κόσμο. Ο Berners-Lee (2006) παρουσίασε ένα σύνολο κανόνων για τη δημοσίευση δεδομένων στο διαδίκτυο με τρόπο ώστε τα δημοσιευμένα δεδομένα να γίνουν μέρος του ενιαίου παγκόσμιου χώρου δεδομένων. Αυτοί οι κανόνες είναι γνωστοί ως «Αρχές των Linked Data» και είναι: 1. Χρήση URIs ως ονόματα για πράγματα 2. Χρήση URIs, HTTP, έτσι ώστε κάποιος να μπορεί να αναζητήσει αυτά τα ονόματα 3. Όταν κάποιος αναζητά ένα URI, να παρέχονται χρήσιμες πληροφορίες, χρησιμοποιώντας τα πρότυπα (RDF, SPARQL) 4. Συμπερίληψη συνδέσμων προς άλλα URIs, ώστε να μπορεί κανείς να ανακαλύψει περισσότερα πράγματα

18 2.1.1 RDF μοντέλο Για να γίνει πραγματικότητα ο Παγκόσμιος Ιστός των Δεδομένων (Web of Data), είναι σημαντικό ο τεράστιος όγκος των δεδομένων να είναι διαθέσιμος σε μία τυποποιημένη μορφή, όπως και προσβάσιμος και διαχειρίσιμος από τα εργαλεία του Σημασιολογικού Ιστού (Semantic Web). Ο Σημασιολογικός Ιστός δεν χρειάζεται απλά πρόσβαση στα δεδομένα, αλλά και στις σχέσεις μεταξύ των δεδομένων. Εξάλλου, όπως έχει ήδη περιγραφεί, αυτή η συλλογή των αλληλένδετων συνόλων δεδομένων στο διαδίκτυο ορίζει τον όρο Linked Data. Το RDF framework αποτελεί ένα από τα κύρια συστατικά των Linked Data και παρέχει ένα γενικευμένο μοντέλο δεδομένων γράφου για την περιγραφή πραγμάτων, συμπεριλαμβανομένων των σχέσεων τους με άλλα πράγματα. Το RDF παρέχει ένα μοντέλο δεδομένων που είναι εξαιρετικά απλό από τη μία πλευρά, αλλά αυστηρά προσαρμοσμένο στη Web αρχιτεκτονική από την άλλη πλευρά. Στο μοντέλο, η περιγραφή ενός πόρου αναπαρίσταται σαν ένα σύνολο από τριπλέτες (triples). Η δομική μονάδα του RDF είναι η τριπλέτα, η οποία αποτελείται από 3 μέρη: <υποκείμενο (subject), κατηγόρημα (predicate) και αντικείμενο (object)>. Μία τριπλέτα αντικατοπτρίζει τη βασική δομή μίας απλής πρότασης, όπως η παρακάτω: George has the address george@gmail.com (subject) (predicate) (object) Κάθε όρος έχει διαφορετική σημασία και αναλύεται παρακάτω: Subject: το subject είναι το URI που προσδιορίζει τον πόρο που περιγράφεται. Object: το object μπορεί είτε να είναι μια απλή τιμή (όπως ένα αλφαριθμητικό, αριθμός ή ημερομηνία) ή μπορεί να είναι ένα URI ενός διαφορετικού πόρου, με τον οποίο συσχετίζεται με κάποιο τρόπο το subject. Predicate: το predicate υποδεικνύει το είδος της σχέσης μεταξύ του subject και του object. Για παράδειγμα, το predicate θα μπορούσε να είναι το όνομα ή η ημερομηνία γέννησης ή ο εργοδότης ή κάποιος τον οποίο γνωρίζει το άτομο (στην περίπτωση ενός άλλου πόρου). Το predicate είναι επίσης ένα URI. Αυτά τα

19 predicate URIs προέρχονται από λεξιλόγια ή συλλογές URI που μπορούν να χρησιμοποιηθούν για να αναπαριστούν πληροφορίες για ένα συγκεκριμένο τομέα. Γνωστά λεξιλόγια που έχουν αναπτυχθεί στο Σημασιολογικό ιστό είναι τα εξής: Friend-of-a-Friend (FOAF): λεξιλόγιο για την περιγραφή ανθρώπων Dublin Core (DC): Καθορίζει τις γενικές ιδιότητες μεταδεδομένων. Semantically-Interlinked Online Communities (SIOC): λεξιλόγιο για την αναπαράσταση online κοινοτήτων vocabulary for representing online communities. Description of a Project (DOAP): λεξιλόγιο για την περιγραφή έργων Simple Knowledge Organization System (SKOS) : λεξιλόγιο για την αναπαράσταση ταξονομιών και χαλαρά δομημένης γνώσης Music Ontology: παρέχει όρους για την περιγραφή καλλιτεχνών, άλμπουμ και τραγουδιών. Review Vocabulary : λεξιλόγιο για την αναπαράσταση εκθέσεων Creative Commons (CC): λεξιλόγιο για την περιγραφή όρων άδειας (license terms) Μερικοί άνθρωποι φαντάζονται ένα σύνολο από RDF τριπλέτες ως ένα γράφημα RDF. Τα URIs που εμφανίζονται ως subject και object είναι οι κόμβοι στο γράφημα και μία ακμή (βέλος), που είναι το predicate συνδέει το subject με το object. Δεδομένου ότι το υποκείμενο μιας δήλωσης μπορεί να αποτελεί αντικείμενο κάποιας άλλης, πολλές τέτοιες RDF τριπλέτες συνθέτουν έναν κατευθυνόμενο γράφο με κόμβους subject και object και ακμές (predicates) που αντιστοιχούν στις σχέσεις μεταξύ τους. Υπάρχουν 2 κύριοι τύποι RDF τριπλετών: 1. Literal Triples

20 Οι Literal Triples έχουν μία απλή τιμή (όπως ένα αλφαριθμητικό, αριθμός ή ημερομηνία) σαν object. Χρησιμοποιούνται για να περιγράψουν ιδιότητες των πόρων. Για παράδειγμα, το όνομα ή την ημερομηνία γέννησης ενός ατόμου. 2. RDF Links Τα RDF Links αντιπροσωπεύουν τη συσχέτιση μεταξύ δύο πόρων και αποτελούνται από τρεις URI αναφορές. Τα URI στη θέση του subject και του object προσδιορίζουν τους αλληλοσυνδεόμενους πόρους. Το URI στη θέση του predicate δηλώνει τον τύπο της σύνδεσης. Για παράδειγμα, ένας σύνδεσμος RDF μπορεί να δηλώσει ότι ένα πρόσωπο απασχολείται από έναν οργανισμό. Ένας άλλος σύνδεσμος RDF μπορεί να δηλώσει ότι τα πρόσωπα γνωρίζουν ορισμένα άλλα άτομα. Τα RDF Links επιτρέπουν στους Linked Data browsers και crawlers να περιηγούνται ανάμεσα στις πηγές δεδομένων και να ανακαλύπτουν επιπρόσθετα στοιχεία. Το πεδίο εφαρμογής θα καθορίσει ποιες ιδιότητες RDF χρησιμοποιούνται ως κατηγορήματα (predicates). Για παράδειγμα, συχνά χρησιμοποιούμενες ιδιότητες στην περιγραφή ανθρώπων είναι οι foaf:knows, foaf:based_near και foaf:topic_interest από το λεξιλόγιο FOAF (Friend-of-a-Friend). Τα RDF Links μπορούν να ρυθμιστούν χειροκίνητα, όπως γίνεται συνήθως στην περίπτωση των προφίλ FOAF, ή μπορούν να παραχθούν με αυτοματοποιημένους αλγόριθμους διασύνδεσης, προσέγγιση η οποία ακολουθείται συνήθως στη διασύνδεση μεγάλων συνόλων δεδομένων. Σε πολλούς τομείς υπάρχουν γενικά αποδεκτά σχήματα ονοματοδοσίας. Για παράδειγμα, στον τομέα των εκδόσεων υπάρχον οι αριθμοί ISBN στον χρηματοοικονομικό τομέα υπάρχουν τα αναγνωριστικά ISIN. Αν αυτά τα αναγνωριστικά χρησιμοποιούνται ως μέρος του HTTP URI για τον εντοπισμό συγκεκριμένων πόρων, τότε είναι δυνατή η χρήση απλών αλγορίθμων βασισμένων σε πρότυπα (Pattern-based Algorithms), προκειμένου να παραχθούν τα RDF links μεταξύ των πόρων. Καθοριστικό ρόλο στην προσπάθεια διασύνδεσης δεδομένων κατέχει το Linked Data Project (LDP). Στο LDP, εκατοντάδες σύνολα δεδομένων (datasets) από διάφορους

21 οργανισμούς δημοσιεύονται και συνδέονται μεταξύ τους ακολουθώντας το μοντέλο RDF. Ενδεικτικό της απήχησης του LDP είναι το γεγονός ότι ο όγκος των δεδομένων που ήδη φιλοξενεί αγγίζει τα 25 εκατ. RDF τριπλετών, με σύνολα δεδομένων που φέρουν πάνω από 400 εκατ. διασυνδέσεις. Προφανώς, όσο ο όγκος των δεδομένων αυτών μεγαλώνει, τόσο οι τεχνικές προκλήσεις που αφορούν στην αποδοτική διαχείρισή τους αυξάνονται. Εικόνα 2-1: Linked datasets, Αύγουστος 2014 Πηγή: Τα οφέλη από τη χρήση του RDF μοντέλο δεδομένων στο πλαίσιο των Linked Data είναι τα εξής: Οι clients μπορούν να αναζητήσουν κάθε URI σε έναν RDF γράφο στο διαδίκτυο για την ανάκτηση επιπρόσθετων πληροφοριών Οι πληροφορίες από διαφορετικές πηγές συγχωνεύονται με φυσικό τρόπο Το μοντέλο επιτρέπει να ορίσετε RDF links μεταξύ των δεδομένων από διαφορετικές πηγές

22 Το μοντέλο επιτρέπει να αναπαραστήσετε σε ένα ενιαίο μοντέλο πληροφορίες βασισμένες σε διαφορετικά σχήματα. Σε συνδυασμό με γλώσσες όπως οι RDF-S ή OWL, το μοντέλο επιτρέπει την αναπαράσταση τόσο δομημένων δεδομένων όσο και ημι-δομημένων. Τα RDF δεδομένα μπορούν να αποτυπωθούν με πολλούς διαφορετικούς τρόπους, γνωστοί ως serialisations. Παραδείγματα των RDF serialisations αποτελούν: Turtle: ένα format συμπαγές και φιλικό προς τον άνθρωπο. N-Triples: ένα απλό, εύκολο στη μεταγλώττιση, line-based μορφή που δεν είναι τόσο συμπαγής όσο το format Turtle N-Quads: ένα υπερσύνολο του N-Triples format, για πολλαπλά RDF γραφήματα JSON-LD: ένα format που στηρίζεται σε JSON N3 or Notation3: μία μη στάνταρ μορφή serialization, παρόμοια με το format Turtle, αλλά με επιπλέον χαρακτηριστικά, όπως η δυνατότητα να καθοριστούν συμπερασματικοί κανόνες RDF/XML: σύνταξη βασισμένη στην XML, αποτελείτο 1 ο στάνταρ format για RDF serializations. Η επιλογή του βέλτιστου RDF serialization για τη δημοσίευση RDF δεδομένων εξαρτάται από το πλαίσιο και τα σενάρια χρήσης. Για παράδειγμα, αν οι άνθρωποι χρειάζεται να διαβάσουν και να γράψουν τα στοιχεία, τότε το format turtle είναι πιθανώς το πιο εύκολο serialization να χρησιμοποιηθεί. Στη συνέχεια, για τη δημοσίευση των δεδομένων, το format RDF/XML είναι μια καλή επιλογή, καθώς έχει ευρεία υποστήριξη σε εργαλεία που αφορούν τα Linked Data. Εάν η υποδομή της δημοσίευσης περιορίζεται στη χρήση HTML εγγράφων, τότε το RDFa είναι το προτιμώμενο serialization. Αντίθετα, εάν τα δεδομένα χρειάζεται να εναλλάσσονται μεταξύ συστημάτων σε μεγάλες ποσότητες, όπως για παράδειγμα η παραγωγή δεδομένων για τη φόρτωση σε ένα triple store, τότε το N-Triples serialization είναι η καλύτερη επιλογή. Η επεξεργασία τους γίνεται σε μία ροή, μία γραμμή τη φορά και χωρίς να φορτώνεται ολόκληρο το αρχείο στη μνήμη

23 2.1.2 RDF Stores Οι RDF τριπλέτες αποθηκεύονται σε έναν τύπο βάσης δεδομένων που αποκαλείται triplestore. Παρόμοια με μία σχεσιακή βάση δεδομένων, τα triplestores είναι βελτιστοποιημένα για να αποθηκεύουν τριπλέτες και γίνεται ανάκτηση των δεδομένων μέσω μίας γλώσσας επερωτήσεων. Εκτός από τα ερωτήματα, οι τριπλέτες συνήθως μπορούν να εισάγονται / εξάγονται χρησιμοποιώντας το Resource Description Framework και άλλες μορφές. Ορισμένα triplestores έχουν δημιουργηθεί ως μηχανές βάσεων δεδομένων από το μηδέν, ενώ άλλα έχουν κατασκευαστεί πάνω από υπάρχουσες εμπορικές μηχανές σχεσιακών βάσεων δεδομένων (SQL - based). Η κυρίαρχη γλώσσα επερωτήσεων για γράφους RDF είναι η SPARQL. Η SPARQL είναι σαν ένα SQL ερώτημα και αποτελεί τη σύστασης του W3C από τον Ιανουάριο Άλλοι μη τυποποιημένοι τρόποι επερωτήσεων σε RDF γράφους αποτελούν: RDQL (RDF Data Query Language): πρόδρομος της SPARQL, SQL-like Versa: συμπαγής σύνταξη (non SQL-like), υλοποιημένη αποκλειστικά σε 4Suite (Python) RQL (RDF Query Language): μία από τις πρώτες δηλωτικές γλώσσες για επερώτηση σχημάτων RDF και περιγραφές των πόρων SeRQL: μέρος του Sesame XUL Στα triplestores τα δεδομένω αποθηκεύονται με τρεις διαφορετικές προσεγγίσεις. Η αρχιτεκτονική των triplestores μπορεί να υλοποιεί και τους τρεις τρόπους οι οποίοι είναι: In-memory: τα in-memory triplestores αποθηκεύουν τον RDF γράφο στην κύρια μνήμη. Αυτή η προσέγγιση δεν μπορεί να χρησιμοποιηθεί για μεγάλο όγκο δεδομένων. Native: είναι ένας τρόπος για να αποθηκευτούν τα δεδομένα RDF μόνιμα στο σύστημα αρχείων (file system) - Virtuoso, Mulgara, AllegroGraph, Garlik JXT

24 Relational: τα triplestores που ανήκουν σε αυτή την κατηγορία έχουν δημιουργηθεί για να τρέχουν πάνω σε τρίτα συστήματα βάσεων δεδομένων. Για παράδειγμα, το Jena SDB μπορεί να συνδυαστεί με σχεδόν όλες τις βάσεις δεδομένων, όπως η MySQL, PostsgreSQL, Oracle. Ο αριθμός των triplestores που αναπτύσσονται ενεργά έχει αυξηθεί από το Jena και Sesame στις αρχές του 2000 στα Garlik JXT, YARS2, BigOWLIM, Jena TDB, Jena SDB, Virtuoso, AllegroGraph, BigData, Mulgara, Sesame, Kowari, 3Store και RDF Gateway. Ορισμένα από αυτά, όπως το Garlik και το YARS2 είναι ιδιόκτητα και δεν διανέμονται. Άλλα, όπως το BigOWLIM και AllegroGraph είναι εμπορικά διαθέσιμα. Τα υπόλοιπα είναι δωρεάν και open source. Στα μεγάλα triplestores, με δυνατότητα αποθήκευσης μεγάλου όγκου RDF τριπλετών περιλαμβάνονται: Oracle Spatial and Graph with Oracle Database 12c (1.08 Trillion triples) AllegroGraph (1+Trillion) Stardog (50 Billion) Garlik 4store (15 Billion) Bigdata(R) (12.7 Billion) YARS2 (7 Billion) Jena TDB (1.7 Billion) Jena SDB (650 Million) Mulgara (500 Million) RDF gateway (262 Million) Jena with PostgreSQL (200 Million) Kowari (160 Million) 3store with MySQL 3 (100 Million) Sesame (70 Million)

25 Στις επόμενες ενότητες παρουσιάζεται μια σύντομη επισκόπηση 4 triplestores που αξιολογούνται και συγκεκριμένα είναι τα Virtuoso, Jena, Sesame και AllegroGraph Jena Το Jena αποτελεί ένα java framework για τη δημιουργία εφαρμογών στο Σημασιολογικό Ιστό και υλοποιεί APIs που ασχολούνται με τα RDF και OWL. Το framework προσφέρει μεθόδους για φόρτωση RDF δεδομένων στη μνήμη, σε native βάση ή σε τρίτη λύση. Ως τρίτη λύση μπορούν να χρησιμοποιηθούν διάφορες σχεσιακές βάσεις δεδομένων, όπως για παράδειγμα MySQL, PostgreSQL ή Oracle. Τα δεδομένα σε όλες τις περιτπώσεις μπορούν να ανακτηθούν μέσω SPARQL επερωτήσεις (ARQ package του Jena). Το SDB ως component του Jena, παρέχει επεκτάσιμο χώρο αποθήκευσης και δυνατότητα εκτέλεσης επερωτήσεων στα RDF datasets χρησιμοποιώντας συμβατικές SQL βάσεις δεδομένων. Ο χώρος αποθήκευσης παρέχεται από μία SQL βάση δεδομένων και η διαχείριση γίνεται μέσω command line εντολών ή μέσω του Jena API. Το SDB μπορεί να συνδεθεί με το web server Fuski (παλιότερα ο Joseki server ήταν ο οποιο διαδεδομένος έως ότου ολοκληρώθηκε η υποστήριξή του) ο οποίος είναι ένας SPARQL query server. Αυτός δίνει τη δυνατότητα να εκτελεστούν επερωτήσεις στο SDB μέσω HTTP. Το Jena εισήγαγε επίσης και το TDB, το οποίο δίνει τη δυνατότηα στο Jena, να αποθηκεύει native τα δεδομένα. Εικόνα 2-2: Αρχιτεκτονική Επισκόπηση του Jena [15]

26 Το Ontology API παρέχει μεθόδους για οντολογίες σε διαφορετικά formats, όπως OWL ή RDFS. To core RDF Model API του Jena παρέχει μεθόδους για τη δημιουργία, επεξεργασία, πλοήγηση, διάβασμα, εγγραφή ή επερώτηση των RDF δεδομένων. Άλλα σημαντικά components του Jena είναι το Inference API, το οποίο επιτρέπει τη διασύνδεση συλλογιστικών μηχανισμών (inference engines / reasoners) με το σύστημα και το Reiffication API. Εκτός από τη SPARQL, υποστηρίζει επίσης τη RDQL σαν γλώσσα επερωτήσεων η οποία όμως έχει αποφασιστεί να καταργηθεί σε μελλοντικές εκδόσεις. Το Jena χρησιμοποιεί readers και writers για RDF/XML, N-Triples και N3 formats των RDF δεδομένων Sesame To σύστημα Sesame είναι ένα open source framework για αποθήκευση και εκτέλεση επερωτήσεων στα RDF δεδομένων καθώς και εξαγωγή συλλογιστικών. Το Sesame ταιριάζει με τα χαρακτηριστικά του Jena, στη διαθεσιμότητα σύνδεσης API, web server και SPARQL endpoint. Όπως και το Jena SDB, υποστηρίζει τη χρήση τρίτων συστημάτων RDBMS, όπως η MySQL και PostsgreSQL. Το Sesame προσφέρει το σύστημα Sesame Native που είναι το native triplestore και είναι λιγότερο επεκτάσιμο συγκριτικά με το native triplestore Jena TDB. Το Sesame έχει δοκιμαστεί σε πάνω από 70 εκατομμύρια τριπλέτες, ενώ το Jena TDB είναι γνωστό ότι δουλεύει με 1,7 δισεκατομμύρια τριπλέτες. Το Sesame package περιέχει δυο web εφαρμογές, τον Sesame server o οποίος αποθηκεύει τα RDF δεδομένα και το OpenRDF Workbench το οποίο είναι ένα γραφικό περιβάλλον του server, το οποίο διαχειρίζεται το χώρο αποθήκευσης, φορτώνει τα RDF δεδομένα και εκτελεί επερωτήσεις. Το Sesame υποστηρίζει και τους 3 εναλλακτικούς τρόπους αποθήκευσης των RDF δεδομένων (in-memory, native, relational)

27 Εικόνα 2-3: Αρχιτεκτονική Επισκόπηση του Sesame [15] Η αρχιτεκτονική του αποτελείται από το RDF Model που υλοποιεί τις βασικές έννοιες των RDF δεδομένων και το component RDF I/O (Rio) που αποτελείται από μεταγλωττιστές για τη διαχείριση των RDF δεδομένων. Το Storage And Inference Layer (Sail) API χρησιμοποιείται για αρχικοποίηση, εκτέλεση ερωτημάτων και επεξεργασία των RDF stores. Το Repository API παρέχει ένα μεγαλύτερο σύνολο μεθόδων για τη διαχείριση των RDF δεδομένων. Το Sesame υποστηρίζει τη SeRQL (Sesame RDF Query Language) και προσφέρει μεταγλωττιστές για τα πιο δημοφιλή RDF formats N3, N-Triples,RDF/XML, Turtle και τα δύο πιο νέα formats TriG43 and TriX AllegroGraph Το AllegroGraph είναι ένα triplestore κλειστού κώδικα, σχεδιασμένο για να αποθηκεύει RDF τριπλέτες. χαρακτηρίζεται από μέγιστη ταχύτητα φόρτωσης και εκτέλεσης ερωτημάτων και αποτελεσματική χρήση της μνήμης συνδυαστικά με την disk-based αποθήκευση, ώστε να επεκτείνεται σε δισεκατομμύρια triples/quards, διατηρώντας παράλληλα υψηλή απόδοση. Προσφέρει μία REST protocol αρχιτεκτονική, και ουσιαστικά ένα υπερσύνολο του Sesame HTTP client και παρέχει Java, Python, Ruby, Perl, C#, Clojure και Common Lisp APIs. Το λογισμικό είναι αυτόνομο και δεν απαιτεί άλλες βάσεις δεδομένων ή άλλο λογισμικό για να λειτουργήσει. Η αποθήκευση, η ευρετηρίαση και η επεξεργασία των ερωτημάτων

28 εκτελείται στο AllegroGraph. Μπορεί να διασυνδεθεί με το Sesame ή το Jena και είναι προσβάσιμο μέσω HTTP. Εικόνα 2-4: Αρχιτεκτονική του AllegroGraph client server [15] Η διαθέσιμη γλώσσα επερωτήσεων είναι η SPARQL, αλλά επιπλέον υποστηρίζει low level API κλήσεις για απευθείας πρόσβαση σε τριπλέτες με subject, predicate και object. Οι API κλήσεις παρέχουν λειτουργικότητα παρόμοια με τα SQL select statements. Υποστηρίζει επίσης RDFS++ Reasoning και Prolog για μηχανισμούς συλλογιστικής. Τα RDF formats που υποστηρίζει είναι τα RDF/XML και N-Triples Virtuoso Το σύστημα διαχείρισης RDF δεδομένων Virtuoso, είναι ένα native triplestore διαθέσιμο είτε ως open source είτε με εμπορικές άδειες. Προσφέρει μία αντικείμενο-σχεσιακή βάση δεδομένων (object-relational database) και αποτελεί ένα σύστημα με υβριδική αρχιτεκτονική που προσφέρει παραδοσιακές και ξεχωριστές λειτουργίες server σε μία ενιαία λύση, προσφέροντας όλη τη λειτουργικότητα μέσω Web Services. Επιπλέον, η δυνατή υποστήριξη σε XML (built-in XQuery, XPath, XSLT, XML Schema) το καθιστούν ελκυστικό στις νέες Web 2.0 εφαρμογές του σημασιολογικού ιστού. Για παράδειγμα, o Virtuoso server μπορεί να προσφέρει αποθήκευση, δυναμικές web σελίδες, ποικίλα XML formats για οποιαδήποτε εφαρμογή. Συγκεκριμένα, καλύπτει τις εξής περιοχές:

29 Relational Tables Data Management (Columnar ή Column-Store SQL RDBMS) Relational Property Graphs Data Management (SPARQL RDF based Quad Store) Content Management (HTML, TEXT, TURTLE, RDF/XML, JSON, JSON-LD, XML) Web και άλλα Document File Services (Web Document ή File Server) Five-Star Linked Open Data Deployment (RDF-based Linked Data Server) Web Application Server (SOAP ή RESTful interaction modes) Το Virtuoso υποστηρίζει μία σειρά από βάσεις δεδομένων διαφορετικών προμηθευτών και παρέχει διαφανή πρόσβαση στις πηγές δεδομένων. Οι client εφαρμογές μπορούν να συνδεθούν ταυτόχρονα μέσω των ODBC, JDBC, UDBC, OLE-DB, ADO.NET και services στα δεδομένα. Αυτές οι βάσεις δεδομένων περιλαμβάνουν την Oracle, Microsoft SQL Server, DB2, Informix, Progress, Ingres. Όλες οι βάσεις δεδομένων αντιμετωπίζονται ως μία ενιαία λογική μονάδα μέσω της Virtuoso Virtual Database engine και η εφαρμογή έχει άμεση και ταυτόχρονη πρόσβαση σε πραγματικό χρόνο στα δεδομένα που είναι αποθηκευμένα στις διαφορετικές βάσεις δεδομένων. Το Virtuoso υποστηρίζει όλους τους τύπους των RDF δεδομένων και μπορούν να φορτωθούν N3, Turtle και RDF/XML αρχεία σε γράφο με τη χρήση των Virtuoso SQL μεθόδων. Τα RDF σύνολα δεδομένων διαχειρίζονται από ένα επιπρόσθετο module εντός του Virtuoso ORDBMS core. Η λειτουργικότητα αυτή παρέχεται σε client εφαρμογές μέσω της υλοποίησης της SPARQL Query Language και Protocol, καθώς και μια συλλογή από Web Services και APIs για δημιουργία, ενημέρωση, διαγραφή RDF datasets. Οι δηλώσεις της SPARQL μπορούν να γραφτούν μέσα σε SQL δηλώσεις ή να απεικονιστούν σαν top-level SQL ερωτήματα. Αυτό σημαίνει ότι οποιαδήποτε ODBC, JDBC,.NET ή OLE/DB εφαρμογή μπορεί να κάνει απλά SQL αναζητήσεις σαν να ήταν SQL ερωτήματα. Επιπλέον, το SPARQL transport protocol επιτρέπει να εκτελούνται ερωτήματα μέσω HTTP και υποστηρίζει το SPARQL XML serialization format για τα αποτελέσματα

30 Εικόνα 2-5 Technical Αρχιτεκτονική του Virtuso [43] Εικόνα 2-6 Conseptual Αρχιτεκτονική του Virtuoso [43]

31 Το Virtuoso προσφέρει drivers για τα Jena, Sesame και Redland frameworks. Έχουν γίνει πολλές αξιολογήσεις στο Virtuoso και έχει αποδειχτεί ότι είναι επεκτάσιμο σε πάνω από 1 δισεκατομμύριο τριπλέτες. 2.2 Ανοιχτά Διασυνδεδεμένα Δεδομένα Ο όρος Linked Open Data αναφέρεται στα διασυνδεδεμένα δεδομένα τα οποία είναι ανοιχτού περιεχομένου (open content) και επομένως είναι δημοσιευμένα με ελεύθερη άδεια χρήσης και είναι εφικτό να επαναχρησιμοποιηθούν. Δεν είναι απαραίτητο ότι όλα τα Linked Data θα είναι ανοιχτά και επίσης όχι όλα τα Open Data θα είναι διασυνδεδεμένα. Το 2010 ο Tim Berners-Lee όρισε ένα σχήμα αξιολόγησης 5 αστέρων (5-star scheme) με σκοπό να ενθαρρύνει τους παρόχους δεδομένων να παρέχουν δεδομένα που συνδέονται με ανοικτή άδειες. Το σχήμα χρησιμοποιεί αστέρια για να αξιολογήσει τη διαθεσιμότητα των διασυνδεδεμένων δεδομένων ως ανοιχτών διασυνδεδεμένων δεδομένων και φαίνεται στον παρακάτω πίνακα: Data available on the web in any format, even using PDF or image scan, but with an Open licence Data delivered as machine-readable structured data, e.g. excel instead of image scan of a table Data available in a non-proprietary format, e.g. CSV instead of excel All the above plus, data using open standards from W3C, e.g. RDF and SPARQL, to identify things and properties, so that people can point at other data All the above, plus, to link data to other people s data to provide context Πίνακας 2-1: 5-Star Scheme for Open Linked Data Εάν όλα τα δεδομένα στο Διαδίκτυο ήταν ανοιχτά και διασυνδεδεμένα, θα ήταν ευκολότερο να δημιουργηθούν πληροφοριακά συστήματα που συνδυάζουν διαφορετικά κατανεμημένα αποθετήρια δεδομένων. Έτσι, ο Παγκόσμιος Ιστός των δεδομένων θα επέτρεπε την πρόσβαση και την ανταλλαγή δεδομένων και γνώσης, χωρίς εμπόδια

32 Μεγάλα ανοιχτά διασυνδεδεμένα δεδομένα είναι η DBpedia και η Freebase DBPedia H Wikipedia έχει εξελιχθεί σε μία κεντρική πηγή γνώσης για την ανθρωπότητα. Είναι το 7 ο website σε επισκεψιμότητα, η πιο ευρέως χρησιμοποιούμενη εγκυκλοπαίδεια και οι εκδόσεις της είναι διαθέσιμες σε 250 γλώσσες. Ωστόσο, όπως πολλές άλλες web εφαρμογές, η Wikipedia προσφέρει περιορισμένες δυνατότητες αναζήτησης και εκτέλεσης επερωτημάτων καθώς περιορίζεται σε full-text search, η οποία επιτρέπει πολύ περιορισμένη πρόσβαση στη γνωσιακή της βάση. Για παράδειγμα, είναι δύσκολο να βρει κανείς όλα τα ποτάμια που εκβάλλουν στον Ρήνο ή όλους τους Ιταλούς συνθέτες του 18ου αιώνα. H DBpedia αποτελεί μια συλλογική προσπάθεια για την εξαγωγή και επαναχρησιμοποίηση δομημένης πληροφορίας από την Wikipedia. Ένας από τους στόχους της DBpedia είναι να προσφέρει δυνατότητα αναζήτησης και εκτέλεσης πολύπλοκων επερωτήσεων, όπως οι παραπάνω, σε μία ευρεία κοινότητα. Τα άρθρα της Wikipedia αποτελούνται κυρίως από ελεύθερο κείμενο σε φυσική γλώσσα, αλλά επίσης περιέχουν και διαφορετικούς τύπους δομημένης πληροφορίας, όπως infobox 1 templates 2, πληροφορίες κατηγοριοποίησης, εικόνες, γεωγραφικές συντεταγμένες, συνδέσμους με εξωτερικές Web σελίδες, ανακατευθύνσεις μεταξύ των σελίδων, καθώς και συνδέσεις σε διαφορετικές εκδόσεις γλώσσας της Wikipedia. Το DBpedia extraction framework εξάγει αυτή τη δομημένη πληροφορία από τη Wikipedia και τη μετατρέπει σε μία πλούσια πολυγλωσσική γνωσιακή βάση. Μετατρέπει, δηλαδή, το περιεχόμενο της Wikipedia σε δομημένη γνώση και την καθιστά ευρέως διαθέσιμη 1 Infobox ονομάζεται ένας πίνακας σταθερού μεγέθους, ο οποίος εμφανίζεται στην επάνω δεξιά γωνία των άρθρων της Wikipedia και παρουσιάζει μία περίληψη του θέματος που παρουσιάζει το άρθρο προσφέροντας βελτιωμένη περιήγηση και σε άλλα σχετικά άρθρα. Πολλά infoboxes περιέχουν δομημένα metadata τα οποία χρησιμοποιούνται από την DBpedia. 2 Infobox templates περιέχουν σημαντικά μετρήσιμα και στατιστικά τα οποία είναι συνήθη σε σχετικά άρθρα και περιλαμβάνουν μία γρήγορη σύνοψη των σημαντικών σημείων σε μία εύκολη μορφή για ανάγνωση. Για παράδειγμα, όλα τα ζώα έχουν μία επιστημονική κατηγοριοποίηση. Έτσι, είναι πιο εύκολη και γρήγορη η αναζήτηση πληροφορίας και η σύγκριση με άλλα σχετικά άρθρα

33 μέσω των καθιερωμένων προτύπων του Σημασιολογικού Ιστού και τις best practices των Linked Data. Για κάθε σελίδα στη Wikipedia, δημιουργείται ένα URI για να προσδιορίσει μία οντότητα ή μία έννοια που περιγράφεται στην αντίστοιχη σελίδα. Κατά τη διαδικασία εξαγωγής, οι δομημένες πληροφορίες από το wiki, όπως infobox πεδία, κατηγορίες και page links εξάγονται ως RDF τριπλέτες και προστίθενται στη γνωσιακή βάση ως ιδιότητες του αντίστοιχου URI. Ένας από τους λόγους για τους οποίους η ποιότητα των δεδομένων της DBpedia έχει βελτιωθεί τα τελευταία χρόνια είναι γιατί η δομή της γνώσης στην DBpedia συντηρείται από την ίδια την κοινότητά της. Πολύ σημαντικό είναι το γεγονός ότι η κοινότητα δημιουργεί mappings (αντιστοιχίσεις) από πληροφορίες της Wikipedia στην οντολογία της DBpedia. Αυτή η οντολογία ενοποιεί διαφορετικά δομικά templates. Η συντήρηση των διαφορετικών εκδόσεων της DBpedia σε διαφορετική γλώσσα έχει εξαπλωθεί σε ένα πλήθος οργανισμών. Κάθε οργανισμός είναι υπεύθυνος για την υποστήριξη μιας συγκεκριμένης γλώσσας. Εικόνα 2-7: Απεικόνιση mapping του Ελληνικού και Αγγλικού template για το Βιβλίο στην ίδια κλάση της οντολογίας της Dbpedia [35]

34 Η ευθυγράμμιση μεταξύ στα Wikipedia infoboxes και στην οντολογία έχουν πραγματοποιηθεί μέσω των mappings που παρέχονται από την κοινότητα, τα οποία βοηθούν στην εξομάλυνση των παραλλαγών στα ονόματα των κλάσεων και ιδιοτήτων. Για παράδειγμα, τα «date of birth» και «birth date» έχουν αντιστοιχιθεί με την ίδια ιδιότητα birthdate. Τα infoboxes «Infobox Person» και «InfoboxFoundingPerson» έχουν αντιστοιχιθεί με την κλάση Person από την κοινότητα της DBpedia. Αυτή τη στιγμή έχουν πραγματοποιηθεί mappings για 23 γλώσσες, το οποίο σημαίνει ότι άλλες ιδιότητες των infoboxes, όπως «data de nascimento» ή «Geburtstag» - ημερομηνία γέννησης στα Πορτογαλικά και στα Γερμανικά αντίστοιχα έχουν συσχετιστεί με το global αναγνωριστικό birthdate. Επομένως, τα DBpedia wiki mappings (αντιστοιχίσεις) μπορεί να γραφτούν για μια ποικιλία γλωσσών, συνδέοντας πολυγλωσσικές πληροφορίες σε μια ενιαία, διαμοιρασμένη οντολογία της DBpedia, ανεξαρτήτου γλώσσας. Το DBpedia extraction framework χρησιμοποιεί τα mappings (αντιστοιχίσεις) για να ομογενοποιήσει τις πληροφορίες που προέρχονται από την Wikipedia προτού παραχθεί δομημένη πληροφορία σε RDF. Η οντολογία βασίζεται σε OWL και αποτελεί τη ραχοκοκαλιά της δομής της DBPedia. περιγράφει κλάσεις, όπως άτομο, πόλη, χώρα και ιδιότητες, όπως τόπος γέννησης, γεωγραφικό πλάτος. Συγκεκριμένα, οργανώνει τη γνώση της Wikipedia σε 685 κλάσεις, οι οποίες σχηματίζουν μία ιεραρχία και περιγράφονται από διαφορετικές ιδιότητες. Διαθέτει ετικέτες και περιλήψεις για πάνω από 3.64 εκατομμύρια πράγματα σε 128 γλώσσες, τα οποία κατηγοριοποιούνται σε μία συνεκτική οντολογία, περιλαμβάνοντας: άτομα μέρη εργασίες οργανισμούς είδη

35 Επιπρόσθετα, υπάρχουν πάνω από 6.3 εκατομμύρια σύνδεσμοι σε εξωτερικές web σελίδες, πάνω από εκατομμύρια σύνδεσμοι σε εικόνες και περισσότερες από γεωγραφικές συντεταγμένες για μέρη. Παράδειγμα Κλάσης Album: Label (gl): Label (el): Label (ga): Label (it): Label (en): Label (de): Label (es): Label (zh): Label (pt): Label (ja): Label (nl): Label (fr): Label (ko): Super classes: álbum album albam album album Album album 照片集 álbum アルバム album album 앨범 MusicalWork Πίνακας 2-2: DBpedia - κλάση Album [33] Ιδιότητες της κλάσης Album: Name Label Domain Range Comment albumruntime (edit) album duration Album Time artist (edit) performer MusicalWork Agent The performer or creator of the musical work. compiler (edit) compiler Album Person For compilation albums: the person or entity responsible for selecting the album's track listing. longtype (edit) longtype Album xsd:string can be used to include more informations e.g. the name of the artist that a tribute album is in honor of lyrics (edit) lyrics MusicalWork Person Creator of the text of a MusicalWork, eg Musical, Opera or Song musicformat (edit) musicformat Album xsd:string The format of the album: EP, Single etc

36 musictype (edit) musictype MusicalWork owl:thing Type is too general. We should be able to distinguish types of music from types of architecture musicalkey (edit) musical key MusicalWork xsd:string recorddate (edit) record date MusicalWork xsd:date recordedin (edit) recorded in MusicalWork PopulatedPlace review (edit) review Album xsd:anyuri totaldiscs (edit) total discs Album xsd:integer the total number of discs contained in the album totaltracks (edit) total tracks Album xsd:integer the total number of tracks contained in the album Πίνακας 2-3: DBpedia - ιδιότητες της κλάσης Album [33] Το project DBpedia ξεκίνησε το 2006 και στο μεταξύ προσέλκυσε μεγάλο ενδιαφέρον στην έρευνα και στην πρακτική. Ως κεντρικό τμήμα του νέφους LOD, λειτουργεί ως κομβικό σημείο σύνδεσης για άλλα σύνολο δεδομένων. H DBpedia διασυνδέεται με πολλά εξωτερικά datasets, ακολουθώντας τις αρχές των Linked Data. Στην επόμενη εικόνα, στην 1 η στήλη, φαίνονται τα εξωτερικά datasets στα οποία συνδέεται η DBpedia. Στη 2 η στήλη εμφανίζεται το κατηγόρημα που χρησιμοποιείται για τη σύνδεση και την 3 η στήλη απεικονίζεται ο συνολικός αριθμός των links ανάμεσα στη DBpedia και το εξωτερικό dataset. Τα datasets της DBpedia μπορούν είτε να εισαχθούν σε third-party εφαρμογές ή μπορούν να προσπελαστούν online με τη χρήση ποικιλίας διεπαφών της DBpedia

37 Εικόνα 2-8: Datasets linked from Dbpedia [35]

38 2.3 NoSQL Βάσεις Δεδομένων Εισαγωγή Ο ψηφιακός κόσμος αυξάνεται γρήγορα και γίνεται ολοένα και πιο πολύπλοκος όσον αφορά στο μέγεθος (volume), στην ταχύτητα (velocity) και στην ποικιλομορφία (variety). Το μέγεθος περιγράφει τον όγκο των δεδομένων (από terabyte σε petabyte) που παράγονται από χρήστες εφαρμογών, συστήματα ή αισθητήρες. H ταχύτητα αναφέρεται στo ρυθμό δημιουργίας των δεδομένων (streaming data) και η ποικιλομορφία αναφέρεται στη διαφορετικότητα των δεδομένων (δομημένα, αδόμητα ή υβριδικά), που παράγονται από τα κοινωνικά δίκτυα, έξυπνες συσκευές, ιστοσελίδες, δεδομένα τοποθεσίας (GPS) κ.ο.κ. Η σύνθεση των τριών αυτών χαρακτηριστικών μας δίνει το πλαίσιο για τον όρο Big Data, ο οποίος έχει γίνει παγκόσμιο φαινόμενο. Στην ουσία, ο όρος περιγράφει την εκθετική αύξηση και τη διαθεσιμότητα των δεδομένων, τα οποία είναι πρακτικά αδύνατο να τα διαχειριστεί κανείς μέσα από παραδοσιακά εργαλεία λογισμικού, όπως σχεσιακές βάσεις δεδομένων ή συμβατικές μηχανές αναζήτησης. Παράλληλα με την εμφάνιση των Big Data, έγινε γρήγορα δημοφιλής και η χρήση της αρχιτεκτονικής «Cloud Computing» ή απλά «Cloud», η οποία επικεντρώνεται στη μεγιστοποίηση της αποτελεσματικότητας των διαμοιρασμένων πόρων (shared resources) και κατηγοριοποιείται σε δημόσιο, ιδιωτικό ή υβριδικό μοντέλο. Οι πόροι στο Cloud διαμοιράζονται ανάμεσα σε πολλαπλούς χρήστες και ανακατανέμονται δυναμικά ανάλογα με τη ζήτηση και την εισερχόμενη κίνηση, απορροφώντας το φόρτο εργασίας με τον καλύτερο δυνατό τρόπο (scalability). Η αρχιτεκτονική αποτελείται από 3 επίπεδα (infrastructure layer platform layer application layer) και υλοποιείται μέσω απομακρυσμένων εξυπηρετητών και δίκτυα λογισμικού, τα οποία επιτρέπουν την κεντρικοποιημένη αποθήκευση δεδομένων και την online πρόσβαση σε υπηρεσίες ή πόρους. Ουσιαστικά, ονομάζεται Cloud computing, γιατί τα δεδομένα και οι εφαρμογές είναι αποθηκευμένα στο «σύννεφο» των web εξυπηρετητών, στα οποία οι χρήστες αποκτούν πρόσβαση από οποιαδήποτε συσκευή διασυνδεδεμένη στο διαδίκτυο, μέσω ενός browser

39 Από τη δεκαετία του 80 το σχεσιακό μοντέλο απεικόνισης και αποθήκευσης δεδομένων κυριαρχεί και είναι γνωστό με τον όρο Relational Database Management System (RDBMS), με εφαρμογές όπως οι Oracle βάσεις δεδομένων, MySQL, Microsoft SQL Servers. Ωστόσο, τον τελευταίο καιρό, σε ένα αυξανόμενο αριθμό περιπτώσεων, η χρήση σχεσιακών βάσεων δεδομένων οδηγεί σε προβλήματα μοντελοποίησης και θέτει περιορισμούς στην οριζόντια επεκτασιμότητα (scalability) σε πολλαπλούς εξυπηρετητές και στο πλήθος των δεδομένων. Οι απαιτήσεις των εφαρμογών σε υπολογιστική ισχύ και δυνατότητες αποθήκευσης (Big data ανάλυση, Business Intelligence, Social Networking σε σύνολα δεδομένων μεγέθους petabyte) ώθησαν τις SQL-like κεντρικοποιημένες βάσεις δεδομένων στα όριά τους και οδήγησαν στην ανάπτυξη κατανεμημένων, μη σχεσιακών χώρων αποθήκευσης δεδομένων (data stores), με δυνατότητα οριζόντιας επέκτασης, που είναι πλέον γνωστές ως NoSQL βάσεις δεδομένων. Κατά συνέπεια, οι οργανισμοί που συλλέγουν μεγάλο όγκο αδόμητων δεδομένων στρέφονται όλο και περισσότερο προς τις μη σχεσιακές βάσεις, καθώς οι NoSQL βάσεις επικεντρώνονται στην αναλυτική επεξεργασία μεγάλων συνόλων δεδομένων, μεγάλης έκτασης, προσφέροντας δυνατότητα επέκτασης στα μηχανήματα υπολογιστών. Στην ερώτηση για το τι ακριβώς είναι, λοιπόν, ένα NoSQL σύστημα διαχείρισης δεδομένων θα απαντούσε κανείς ότι είναι ένα σύστημα όπου οι βάσεις δεδομένων δεν δομούνται σε πίνακες και δεν χρησιμοποιούν SQL ερωτήματα για τη διαχείριση δεδομένων. Τα NoSQL συστήματα πλεονεκτούν έναντι των RDBMS, όταν έχουν να αντιμετωπίσουν μεγάλο πλήθος δεδομένων και παράλληλη επεξεργασία και ειδικά όταν τα δεδομένα δεν απαιτούν σχεσιακή μοντελοποίηση. Το αυστηρά σχεσιακό μοντέλο των RDBMS καθίσταται εμπόδιο σε web εφαρμογές (Web 2.0), όπως blogs, τα οποία αποτελούνται από πολλές διαφορετικές ιδιότητες (κείμενο, σχόλια, εικόνες, video, source code, και άλλες πληροφορίες πρέπει να αποθηκευτούν σε πολλαπλούς πίνακες). Δεδομένου ότι οι web εφαρμογές είναι ευέλικτες, έτσι και οι βάσεις δεδομένων που τις υποστηρίζουν πρέπει να είναι εξίσου ευέλικτες, τηρώντας πάντα ανέπαφη τη διαθεσιμότητα της εφαρμογής. Τα συστήματα NoSQL έχουν την ικανότητα να

40 αποθηκεύουν και να ευρετηριάζουν αυθαίρετα μεγάλα datasets, ενώ εξυπηρετούν μεγάλο πλήθος παράλληλων αιτημάτων χρηστών. Η δομή των δεδομένων σε ένα NoSQL σύστημα διαφέρει από τις δομές στα RDBMS, και γι' αυτό κάποιες λειτουργίες είναι πιο γρήγορες ενίοτε στη μία ή στην άλλη περίπτωση. Η καταλληλόλητα μιας NoSQL βάσης δεδομένων εξαρτάται από το πρόβλημα που καλείται να επιλύσει. Τα κλασικά σχεσιακά μοντέλα στηρίζονται σε συναλλαγές (transactions), ώστε να εγγυηθούν την ακεραιότητα και να εξασφαλίσουν συνοχή των δεδομένων. Τα χαρακτηριστικά αυτά των σχεσιακών βάσεων είναι γνωστά σαν ACID ιδιότητες (Atomicity, Consistency, Isolation, Durability). Ωστόσο, η επέκταση (scaling out) σε συστήματα, τα οποία συμμορφώνονται με τις ACID ιδιότητες, έχει φέρει στην επιφάνεια προβλήματα και διαμάχες μεταξύ των διαφορετικών πτυχών της υψηλής διαθεσιμότητας σε κατανεμημένα συστήματα. Το πρόβλημα αυτό δεν είναι πλήρως επιλύσιμο και είναι γνωστό σαν το θεώρημα CAP. Το θεώρημα αναφέρεται σε δυνατή συνοχή (strong Consistency), υψηλή διαθεσιμότητα (high Availability) και ανοχή κατανομής σε διαφορετικούς servers (Partition-tolerance) και υποστηρίζει ότι μόνο δύο εκ των τριών ιδιοτήτων (C - consistency, A - availability or P - partitioning) μπορούν να επιτευχθούν πλήρως την ίδια στιγμή. Όταν η συνοχή των δεδομένων είναι κρίσιμη, τότε θα πρέπει να χρησιμοποιηθεί ένα σχεσιακό μοντέλο βάσης δεδομένων. Όταν, όμως, η πληροφορία είναι κατανεμημένη σε πολλαπλούς servers, η συνοχή είναι δύσκολη να επιτευχθεί. Για το λόγο αυτό, πολλά NoSQL συστήματα μετριάζουν τη συνοχή, η οποία δεν είναι απαραίτητη σε συγκεκριμένες εφαρμογές και use cases, με σκοπό να επιτύχουν υψηλότερη διαθεσιμότητα και κατανομή (partitioning). Σε αντίθεση με τα RDBMS, οι NoSQL βάσεις δεδομένων έχουν σχεδιαστεί για να επεκτείνονται οριζόντια σε μεγάλο αριθμό εξυπηρετητών, ώστε να μην στηρίζονται σε υψηλής διαθεσιμότητας hardware. Υπολογιστικοί πόροι μπορούν να προστίθενται ή να αφαιρούνται, ακόμα και αυτόματα, χωρίς να προκαλούν δυσλειτουργίες, όπως γίνεται στα clustered RDBMS κατά το partitioning (sharding). Κατά συνέπεια, παρουσιάζουν μεγάλη «ελαστικότητα» στην βελτίωση της επίδοσης τους. Μάλιστα από την στιγμή που η υλοποίησή τους τις περισσότερες φορές γίνεται σε υποδομές cloud ή σε virtualized

41 environments, συμφέρουν πολύ από οικονομική άποψη, σε αντίθεση με τα κλασικά RDBMS συστήματα. Ειδικότερα, ενώ στα RDBMS συστήματα, όταν απαιτείται βελτίωση, γίνεται προσθήκη επιπρόσθετης μνήμης RΑΜ ή καλύτερων επεξεργαστών στις υποδομές του οργανισμού, αντίθετα στα NoSQL συστήματα απλά προστίθενται κόμβοι, ώστε να επεξεργάζονται ακόμη περισσότερα δεδομένα ταυτόχρονα. Τα NoSQL συστήματα έχουν σχεδιαστεί για αποθήκευση δομών, οι οποίες είναι είτε απλές είτε παρόμοιες με αυτές του αντικειμενοστραφούς προγραμματισμού σε σύγκριση με τις σχεσιακές δομές δεδομένων. Συγκεκριμένα, οι NoSQL βάσεις δεδομένων χρησιμοποιούνται κυρίως για: Επεξεργασία μεγάλης κλίμακας δεδομένων σε μικρότερο χρόνο - Large-scale data processing (parallel processing over distributed systems). Αναζήτηση και ανάκτηση δεδομένων - Embedded IR (basic machine-tomachine information look-up & retrieval). Ανάλυση σε ημιδομημένα/μη δομημένα δεδομένα - Exploratory analytics on semi-structured data. Αποθήκευση συνεχώς αυξανόμενου όγκου δεδομένων - Large volume data storage (unstructured, semi-structured, small-packet structured) Κατηγορίες Στο συγκεκριμένο κεφάλαιο, οι NoSQL βάσεις δεδομένων θα κατηγοριοποιηθούν σε 4 βασικά είδη: Key value stores Document databases Column family stores Graph databases Κάθε κατηγορία περιγράφεται στα επόμενα υποκεφάλαια

42 Key Value Stores Τα NoSQL συστήματα, που ανήκουν σε αυτή την κατηγορία, δεν έχουν σχήμα και αποθηκεύουν δεδομένα ως ένα ζεύγος κλειδιού και τιμής. Η δομή αυτή είναι γνωστή επίσης με τον όρο «hash table», όπου η ανάκτηση και ευρετηριοποίηση των δεδομένων πραγματοποιείται με βάση το κλειδί για πρόσβαση στις τιμές κάθε ιδιότητας. Οι τιμές αυτές μπορεί να είναι απλό κείμενο ή πιο σύνθετες λίστες και σετ και κάθε γραμμή μπορεί να έχει τιμές σε περισσότερες ή λιγότερες ιδιότητες από μία άλλη γραμμή. Τα key-value stores παρέχουν συνεπές hashing, έτσι ώστε να μπορούν να επεκταθούν σταδιακά παράλληλα με τα δεδομένα. Ανταλλάσσουν δομές κόμβων διαμέσου πρωτοκόλλου, ώστε να παραμείνουν όλοι οι κόμβοι συγχρονισμένοι. Εικόνα 2-9: Example of a Typical Key/Value Domain [24] Η απλότητα των key-value βάσεων τις συνιστά ιδανικές σε περιπτώσεις απαίτησης γρήγορης ανάκτησης δεδομένων, όπως για παράδειγμα η γρήγορη ανάκτηση ονομάτων προϊόντων ή ανάκτηση προφίλ χρηστών. Επίσης, είναι η καλύτερη επιλογή σε περιπτώσεις πολύ μεγάλων datasets, χαμηλής πολυπλοκότητας, στα οποία οι ανάγκες επέκτασης ολοένα αυξάνονται. Παραδείγματα: Dynamo (Amazon), Redis, Voldemort (LinkedIn), Oracle BDB, BerkeleyDB, Riak. Δυνατά σημεία: Γρήγορη αναζήτηση Αδύνατα σημεία: Τα αποθηκευμένα δεδομένα δεν έχουν σχήμα

43 Document Databases Εμπνευσμένες από το σύστημα Lotus Notes, οι document βάσεις δεδομένων είναι σχεδιασμένες για διαχείριση και αποθήκευση εγγράφων. Τα έγγραφα είναι κωδικοποιημένα σε συγκεκριμένες μορφές, όπως XML, JSON (Javascript Option Notation) ή BSON (Binary JSON). Σε αντίθεση με τις key-value βάσεις, η εκτέλεση ερωτημάτων και η αναζήτηση μπορεί να πραγματοποιηθεί με το κλειδί αλλά και με τις τιμές, παρέχοντας έτσι μεγαλύτερη ευελιξία. Στην ουσία, μία document βάση δεδομένων είναι μία key-value βάση και βασίζεται σε συλλογές ζευγών κλειδιού-τιμής με μία σημαντική εξαίρεση: αντί να αποθηκεύει οποιοδήποτε blob αρχείο μέσα στη βάση, η document db αποθηκεύει όλα τα δεδομένα του εγγράφου σε ένα format, το οποίο να είναι αναγνωρίσιμο από τη βάση (πχ XML ή JSON) και με αυτό τον τρόπο επιτρέπει την εκτέλεση ερωτημάτων απευθείας στα δεδομένα του εγγράφου. Πιο συγκεκριμένα, στη document βάση, η στήλη «value» περιέχει ημιδομημένα δεδομένα, σε ζεύγος όνομα ιδιότητας τιμή ιδιότητας. Μία μοναδική στήλη μπορεί να έχει εκατοντάδες ιδιότητες. Ο αριθμός και ο τύπος των ιδιοτήτων αυτών μπορεί να διαφέρει από γραμμή σε γραμμή. Οι βάσεις εγγράφων είναι κατάλληλες για αποθήκευση και διαχείριση Big Data, μεγάλες συλλογές, δηλαδή, κυριολεκτικών εγγράφων, όπως μηνύματα ηλεκτρονικού ταχυδρομείου και XML έγγραφα, καθώς επίσης και για αποθήκευση εννοιολογικών εγγράφων, όπως η αναπαράσταση οντοτήτων, για παράδειγμα προϊόν ή πελάτης. Επιπρόσθετα, είναι κατάλληλες για αποθήκευσης ημιδομημένων δεδομένων, που είναι γενικά ελλιπή και θα απαιτούσε εκτεταμένη χρήση τιμών null (μηδενικές ή ανύπαρκτες τιμές) σε ένα RDBMS σύστημα

44 Εικόνα 2-10: Document data model Πηγή: Παραδείγματα: CouchDB, MongoDb Δυνατά σημεία: Ανοχή σε ελλιπή δεδομένα Αδύνατα σημεία: Απόδοση ερωτημάτων, Μη προτυποποιημένο συντακτικό ερωτημάτων Column Family stores Τα column family stores έχουν σχεδιαστεί για την αποθήκευση και την επεξεργασία τεράστιων ποσοτήτων δεδομένων (εκατοντάδες εκατομμύρια, ή δισεκατομμύρια γραμμών που περιέχουν εκατοντάδες στήλες). Ταυτόχρονα παρέχουν πολύ γρήγορη πρόσβαση στα δεδομένα αυτά σε συνδυασμό με ένα αποτελεσματικό, κατανεμημένο μηχανισμό αποθήκευσης. Τα column family stores βασίζονται στην υλοποίηση BigTable της Google και είναι πιθανό να μοιάζουν επιφανειακά με τις σχεσιακές βάσεις δεδομένων, ωστόσο, υπάρχουν πολλές διαφορές. Σε αυτό το μοντέλο όλα τα δεδομένα αποθηκεύονται ως ένα σύνολο από γραμμές και στήλες. Εξακολουθούν να υφίστανται κλειδιά, τα οποία όμως δείχνουν σε πολλαπλές στήλες και οι στήλες οργανώνονται σε οικογένειες. Οι βασικές έννοιες είναι οι στήλες, οι υπερ-στήλες και οι οικογένειες στηλών, οι οποίες ορίζονται ως εξής:

45 Οικογένειες στηλών (super column families): Αποτελούν το πλησιέστερο στοιχείο στον πίνακα ενός RDBMS, δεδομένου ότι θα πρέπει να καθοριστεί εκ των προτέρων. Ωστόσο, δεν υπάρχει σχήμα και το μοναδικό χαρακτηριστικό που ορίζεται για κάθε οικογένεια στηλών είναι το όνομα και οι βασικές επιλογές ταξινόμησης. Μία οικογένεια στηλών μπορεί να περιέχει υπερ στήλες ή στήλες και καθορίζει το πώς θα δομηθούν τα δεδομένα στον δίσκο. Όλα τα δεδομένα μίας οικογένειας θα αποτυπωθούν στο ίδιο αρχείο ή σύνολο αρχείων. Υπερ-στήλη (super column): είναι ένας κατάλογος ή συλλογή από άλλες στήλες. Δηλαδή, μία υπερ-στήλη μπορεί να περιέχει άλλες στήλες, αλλά όχι άλλες υπερ-στήλες. Στήλη (column): είναι από μόνη της ένα ζεύγος κλειδιού-τιμής που υπάρχει σε μια οικογένεια στηλών (περιέχει και timestamp). Εικόνα 2-11: Column Family Store - data model [26] Αντίθετα με τους πίνακες σε ένα RDBMS, οι στήλες σε μία οικογένεια δεν ακολουθούν συγκεκριμένο σχήμα για κάθε γραμμή. Αυτό σημαίνει ότι σε μια column-family βάση δεδομένων, κάθε γραμμή μπορεί να έχει διαφορετικές στήλες. Επομένως, μία οικογένεια στηλών μπορεί να χαρακτηριστεί σαν ένας χάρτης ζευγών από κλειδί-τιμή, όπου τα περιεχόμενα του χάρτη είναι πιθανό να διαφέρουν από γραμμή σε γραμμή. Αν μία γραμμή δεν έχει τιμή σε μία

46 στήλη, τότε η στήλη αυτή παραλείπεται από τη γραμμή. Η προσέγγιση αυτή δίνει τη δυνατότητα να αποθηκεύονται ελλιπή δεδομένα πιο αποτελεσματικά σε σχέση με πίνακες σε σχεσιακή βάση δεδομένων. Εικόνα 2-12: Απεικόνιση πίνακα Customer Address και η σχέση τους σε RDBMS Εικόνα 2-13: Απεικόνιση δεδομένων και σχέσης Customer - Address σε Column - family ΒΔ Μια καλά σχεδιασμένη column-family βάση δεδομένων είναι εγγενώς πιο γρήγορη και πιο επεκτάσιμη συγκριτικά με μια σχεσιακή βάση που περιέχει ένα ισοδύναμο όγκο των δεδομένων. Ωστόσο, μία τυπική βάση αυτής της κατηγορίας σχεδιάζεται για να υποστηρίξει συγκεκριμένο σύνολο ερωτημάτων και έτσι τείνει να γίνεται λιγότερο γενικευμένη σε σχέση με μία σχεσιακή βάση. Επομένως, για να γίνει η καλύτερη δυνατή χρήση μιας column-family βάσης, θα πρέπει να έχουν σχεδιαστεί οι οικογένειες στηλών με τέτοιο τρόπο, ο οποίος να βελτιστοποιεί τα συνήθη ερωτήματα που θα εκτελεί η εφαρμογή που τρέχει σε αυτή τη βάση. Συνίσταται οι στήλες με δεδομένα τα οποία ανακτώνται συχνά μαζί, να διατάσσονται σε μία ομάδα - οικογένεια

47 Παραδείγματα: Cassandra (Facebook, Twitter), HBase, Bigtable (Google), Hypertable, SimpleDB (Amazon), DynamoDB Δυνατά σημεία: Καλή επέκταση, Αποτελεσματικότητα σε πολύπλοκα σύνολα δεδομένων Αδύνατα σημεία: Όχι τόσο καλή επέκταση όσο τα key-value stores Graph databases Οι βάσεις δεδομένων γράφων αντικαθιστούν τους σχεσιακούς πίνακες με δομημένους σχεσιακούς γράφους διασυνδεδεμένων ζευγών κλειδιού-τιμής. Το μοντέλο είναι παρόμοιο με τις αντικειμενοστραφείς βάσεις δεδομένων, καθώς οι γράφοι απεικονίζονται σαν ένα αντικειμενοστραφές δίκτυο κόμβων (εννοιολογικά αντικείμενα) με σχέσεις μεταξύ των κόμβων (άκρα) και ιδιότητες (ιδιοτήτων των αντικειμένων που εκφράζονται ως ζεύγη κλειδιού-τιμής). Οι NoSQL βάσεις που ανήκουν στη συγκεκριμένη κατηγορία ασχολούνται με τις σχέσεις μεταξύ δεδομένων ή κόμβων και εστιάζουν στην οπτική αναπαράσταση των δεδομένων, γεγονός που τις καθιστά πιο φιλικές προς τον άνθρωπο σε σχέση με άλλα NoSQL συστήματα. Οι γράφοι είναι χρήσιμοι όταν η σχέση μεταξύ των δεδομένων είναι πιο σημαντική από τα ίδια τα δεδομένα, όπως για παράδειγμα, όταν απεικονίζεται και διασχίζεται ένα κοινωνικό δίκτυο, παράγοντας προτάσεις (upsell or cross-sell προτάσεις) ή όταν διεξάγεται μία εγκληματολογική έρευνα (pattern detection). Μια βάση δεδομένων γράφων είναι μια μεγάλη πυκνή δομή δικτύου. Γι αυτό το λόγο, είναι κατάλληλες όταν η αποθηκευμένη πληροφορία μπορεί να αναπαρασταθεί σε μορφή γράφου με διασυνδεδεμένους κόμβους, όπως για παράδειγμα ένα κοινωνικό δίκτυο, οδικοί χάρτες ή δρομολόγια μέσων μεταφοράς και όταν το ενδιαφέρον είναι στη διάσχιση των σχέσεων και όχι στην εκτέλεση ερωτημάτων. Το πιο κοινό παράδειγμα είναι η σχέση μεταξύ ανθρώπων σε ένα κοινωνικό δίκτυο, όπως το Facebook. Σε ένα RDBMS, η λεπτομερής εξέταση μιας τεράστιας συνδεδεμένης λίστας ανθρώπων θα απαιτούσε ώρες, ενώ αντίθετα, μια βάση δεδομένων γράφων χρησιμοποιεί πιο εξεζητημένους αλγόριθμους συντομότερων μονοπατιών και κάνει πιο

48 αποδοτικά τα ερωτήματα στα δεδομένα. Παρά το ότι είναι πιο αργές από άλλες NoSQL βάσεις, είναι πιθανό να έχουν την πιο πολύπλοκη δομή από όλες και να συνεχίζουν να διατρέχουν δισεκατομμύρια κόμβων και σχέσεων με τεράστια ταχύτητα. Εικόνα 2-14: Graph NoSQLDatabase Πηγή: Παραδείγματα: Neo4J, InfoGrid, Infinite Graph, AllegroGraph. Δυνατά σημεία: ισχυρό μοντέλο δεδομένων, γρήγοροι για συνδεδεμένα δεδομένα, εύκολος τρόπος επερωτήσεων, Αλγόριθμοι γραφημάτων π.χ. shortest path, n degree relationships, κτλ. Αδύνατα σημεία: Διάσχιση ολόκληρου γράφου για οριστική απάντηση, δύσκολο να δημιουργηθούν clusters Μελέτη NoSQL αποθηκών HBase Ο πιο εύκολος τρόπος να περιγράψει κανείς το μοντέλο δεδομένων της HBase είναι στη μορφή πινάκων, αποτελούμενων από γραμμές και στήλες. Η περιγραφή αυτή θυμίζει το σχεσιακό μοντέλο των RDBMS, στο οποίο υπάρχει μεγαλύτερη εξοικείωση, αλλά η

49 ομοιότητα της HBase με το μοντέλο δεδομένων των RDBMS σταματά σε αυτό το σημείο, καθώς στην HBase ακόμα και οι ίδιες οι έννοιες των γραμμών και στηλών διαφέρουν. Βασικοί όροι της HBase: Πίνακας (Table): Η Hbase οργανώνει τα δεδομένα σε πίνακες και κάθε πίνακας περιέχει πολλαπλές γραμμές. Τα ονόματα των πινάκων είναι αλφαριθμητικά και αποτελούνται από χαρακτήρες που είναι ασφαλείς για χρήση σε μια διαδρομή συστήματος αρχείων. Γραμμή (Row): Μία γραμμή στην HBase αποτελείται από ένα κλειδί γραμμής και μία ή περισσότερες στήλες με τιμές, συσχετισμένες μεταξύ τους. Οι γραμμές ταξινομούνται αλφαβητικά με βάση το κλειδί γραμμής, κατά την καταχώρηση και γι αυτό η σχεδίαση του κλειδιού είναι σημαντικό. Ο στόχος είναι να αποθηκεύονται τα δεδομένα με τέτοιο τρόπο, ώστε συσχετιζόμενες γραμμές να βρίσκονται κοντά. Το κλειδί γραμμής δεν έχει συγκεκριμένο τύπο δεδομένων και αντιμετωπίζεται ως ένα byte array (byte []). Στήλη (Column): Μία στήλη στην HBase αποτελείται από μία οικογένεια-στήλη και ένα αναγνωριστικό, χωρισμένα με το σύμβολο «:». Οικογένεια στηλών (Column Family): Μία οικογένεια-στήλη οργανώνει ένα σύνολο στηλών και τις τιμές τους, συχνά για λόγους απόδοσης. Οι οικογένειες-στηλών επηρεάζουν τη φυσική διάταξη των δεδομένων που αποθηκεύονται στην Hbase και έχουν ιδιότητες αποθήκευσης (cache values in memory, compression, key encoding). Γι αυτό το λόγο, είναι απαραίτητο να καθορίζονται εκ των προτέρων, καθώς δεν είναι εύκολα τροποποιήσιμες. Κάθε γραμμή σε έναν πίνακα έχει τις ίδιες οικογένειες στηλών παρόλο που είναι πιθανό μία γραμμή να μην αποθηκεύσει τίποτα σε κάποια από τις οικογένειες-στήλες. Μία οικογένεια στήλη είναι αλφαριθμητικό και αποτελείται από χαρακτήρες που είναι ασφαλείς για χρήση σε μια διαδρομή συστήματος αρχείων

50 Αναγνωριστικό Στήλης (Column Qualifier): Ένα αναγνωριστικό στήλης προστίθεται σε μία οικογένεια-στήλη για να παρέχει ένα δείκτη για συγκεκριμένα δεδομένα. Οι στήλες δεν είναι απαραίτητο να προσδιοριστούν από τη δημιουργία του πίνακα, τα αναγνωριστικά στηλών μπορεί να είναι ευμετάβλητα καθώς και να διαφέρουν σε μεγάλο βαθμό μεταξύ των γραμμών. Όπως και με το κλειδί της γραμμής, έτσι και η στήλη δεν έχει τύπο δεδομένων και αντιμετωπίζεται σαν ένα byte array (byte[]). Κελί (Cell): Ο συνδυασμός ενός κλειδιού γραμμής, οικογένειας-στήλης και αναγνωριστικού στήλης προσδιορίζει μοναδικά ένα κελί. Τα δεδομένα αποθηκεύονται σε ένα κελί, μαζί με χρονοσήμανση και αποτελούν μία έκδοση της τιμής του εν λόγω κελιού. Οι τιμές δεν έχουν έναν τύπο δεδομένων και αντιμετωπίζονται πάντα σαν ένα byte array (byte[]). Χρονοσήμανση (Timestamp): Για τις τιμές ενός κελιού διατηρούνται οι διαφορετικές εκδόσεις (versioning). Το χαρακτηριστικό αυτό ρυθμίζεται στην HBase ανά οικογένεια-στήλη και ο προεπιλεγμένος αριθμός εκδόσεων κελιού είναι τρεις. Μία έκδοση προσδιορίζεται από τον αριθμό έκδοσης, ο οποίος εξ ορισμού είναι η χρονική σήμανση όταν καταχωρήθηκε η τιμή στο κελί. Αν κατά την ανάγνωση δεν καθορίζεται η χρονική σήμανση, επιστρέφεται πάντα η πιο πρόσφατη τιμή. Το API της HBase για διαχείριση των δεδομένων παρέχει 4 μεθόδους: Get: επιστρέφει ιδιότητες μίας συγκεκριμένης γραμμής. Put: προσθέτει νέα γραμμή (αν το κλειδί είναι νέο) ή ενημερώνει υπάρχουσα γραμμή (αν το κλειδί υπάρχει). Scan: επιτρέπει την επανάληψη σε πολλαπλές γραμμές για συγκεκριμένα χαρακτηριστικά Delete: αφαιρεί μία γραμμή από ένα πίνακα. Η μέθοδος Get και Put αναφέρονται σε συγκεκριμένες γραμμές και απαιτούν να τους δοθεί το κλειδί της γραμμής. Η μέθοδος Scan εκτελείται σε ένα εύρος γραμμών, το οποίο

51 μπορεί να καθοριστεί από ένα κλειδί έναρξης και ένα κλειδί τέλους ή θα μπορούσε να είναι και ολόκληρος ο πίνακας, αν δεν δοθεί κλειδί έναρξης και τέλους. Για τη διαγραφή γραμμών δημιουργούνται δείκτες, που λέγονται tombstones. Η εκκαθάριση των «σκουπιδιών» γίνεται με τη διαδικασία της συμπίεσης (major compaction) για τις εγγραφές με δείκτη προς διαγραφή και επιπλέον για KeyValues που είτε έχουν λήξει λόγω της ρύθμισης του TTL (Time to live) της οικογένειας-στήλης είτε γιατί αποτελούν πλέον παλιότερη έκδοση (Version settings). Παρακάτω απεικονίζεται η μορφή ενός πίνακα στην HBase. Ο πίνακας αποτελείται από 2 οικογένειες στηλών, Personal και Office, και η κάθε μία έχει 2 στήλες (Name και Residence phone στην οικογένεια-στήλη Personal, Phone και Address στην οικογένειαστήλη Office). Εικόνα 2-15: Πίνακας στην Hbase [37] Το μοντέλο δεδομένων της HBase γίνεται μερικές φορές πιο εύκολα κατανοητό αν το σκεφτεί κανείς σαν ένα πολυδιάστατο χάρτη. Το κλειδί «δείχνει» σε μία λίστα από οικογένειες-στήλες, κάθε μία εκ των οποίων «δείχνει» σε μία λίστα στηλών. Κάθε στήλη «δείχνει» σε μία λίστα από χρονοσημάνσεις και κάθε χρονοσήμανση «δείχνει» σε μία τιμή, δηλαδή, σε ένα κελί. Επομένως, η ανάκτηση ενός item, στο οποίο «δείχνει» το κλειδί, θα επιστρέψει δεδομένα από όλες τις στήλες της γραμμής. Η ανάκτηση ενός item

52 μίας συγκεκριμένης οικογένειας-στήλη θα επιστρέψει όλες τις στήλες της οικογένειας. Η ανάκτηση ενός item μίας συγκεκριμένης στήλης θα επιστρέψει όλες τις χρονοσημάνσεις και τις σχετικές τιμές. Εικόνα 2-16: Αναπαράσταση γραμμής στην HBase ως πολυδιάστατος χάρτης [37] Η HBase βελτιστοποιεί τα τυπικά πρότυπα και επιστρέφει μόνο την τελευταία έκδοση από προεπιλογή. Μέσω κατάλληλου επερωτήματος είναι εφικτό να επιστραφούν πολλαπλές εκδόσεις μιας τιμής. Το κλειδί γραμμής στην HBase είναι ισοδύναμο με τo πρωτεύον κλειδί σε ένα πίνακα ενός σχεσιακού μοντέλου, αλλά στην HBase μετά τη δημιουργία του πίνακα δεν είναι δυνατό να αλλάξει το ποια στήλη αντιπροσωπεύει το κλειδί. Έτσι, στο παραπάνω παράδειγμα, η στήλη Name στην οικογένεια-στήλη Personal δεν μπορεί να επιλεγεί σαν κλειδί, μετά την καταχώρηση δεδομένων στον πίνακα. Η HBase είναι δυνατό να περιγραφεί και σαν ένα key-value store, όπου το κλειδί είναι το κλειδί γραμμής και η τιμή είναι τα υπόλοιπα δεδομένα σε μία στήλη. Σε άλλη προσέγγιση είναι δυνατό να περιγραφεί η HBase σαν ένα key-value store, όπου το κλειδί προσδιορίζεται ως ο συνδυασμός από το κλειδί γραμμής/οικογένειαστήλη/στήλη/χρονοσήμανση και η τιμή είναι τα περιεχόμενα του κελιού, δηλαδή, τα

53 πραγματικά δεδομένα που βρίσκονται αποθηκευμένα στο κελί. Ο συνδυασμός εξαρτάται από τα κελιά που ενδιαφέρουν προς ανάκτηση. Αν ενδιαφέρουν όλα τα κελιά σε μία γραμμή, τότε το κλειδί θα είναι το κλειδί γραμμής. Αν ενδιαφέρουν μόνο ορισμένα κελιά, τότε η κατάλληλη οικογένεια-στήλη και οι στήλες θα πρέπει να είναι μέρος του κλειδιού. Η απεικόνιση φαίνεται στην επόμενη εικόνα. Εικόνα 2-17: Απεικόνιση πίνακα στην HBase ως key-value store [37] Ο σχεδιασμός πινάκων στην HBase θα μπορούσε να προσδιοριστεί από τις απαντήσεις στις εξής ερωτήσεις: Ποια θα είναι η δομή του κλειδιού γραμμής και τι πρέπει να περιλαμβάνει; Πόσες οικογένειες-στήλες πρέπει να έχει ένας πίνακας; Τι είδους δεδομένων θα αποθηκεύονται σε κάθε οικογένεια-στήλη; Πόσες στήλες θα υπάρχον σε κάθε οικογένεια-στήλη; Ποια θα είναι τα ονόματα των στηλών; (παρόλο που κατά τη δημιουργία του πίνακα δεν χρειάζεται να είναι γνωστά, είναι απαραίτητα όμως κατά την ανάγνωση ή εγγραφή δεδομένων). Τι πληροφορία θα καταχωρείται στα κελιά; Πόσες εκδόσεις θα διατηρούνται για κάθε κελί; Το πιο σημαντικό είναι ο καθορισμός της δομής του κλειδιού γραμμής και για να γίνει αυτό αποτελεσματικά, πρέπει να προσδιοριστούν εκ των προτέρων πρότυπα πρόσβασης

54 (ανάγνωσης και εγγραφής). Ο σωστός σχεδιασμός του σχήματος στην HBase προϋποθέτει να ληφθούν υπόψιν βασικά χαρακτηριστικά των πινάκων της HBase, τα οποία είναι: 1. Η ευρετηριοποίηση πραγματοποιείται μόνο με βάση το κλειδί. 2. Οι πίνακες είναι ταξινομημένοι με βάση το κλειδί και αποτελούνται από περιοχές. Κάθε περιοχή αντιπροσωπεύει ένα εύρος κλειδιών και προσδιορίζεται από ένα αρχικό και ένα τελικό κλειδί γραμμής. Η περιοχή περιλαμβάνει ένα ταξινομημένη εύρος γραμμών από το αρχικό έως το τελικό κλειδί, που αποθηκεύονται μαζί. 3. Τα πάντα στους πίνακες της HBase αποθηκεύονται σαν byte[]. Δεν υπάρχουν τύποι. 4. Η ατομικότητα είναι εγγυημένη στο επίπεδο της γραμμής, όχι όμως κατά μήκος των γραμμών, που σημαίνει ότι δεν υπάρχουν συναλλαγές (transactions) πολλαπλών γραμμών. 5. Οι οικογένειες-στήλες πρέπει να οριστούν εκ των προτέρων, κατά τη δημιουργία του πίνακα. 6. Τα αναγνωριστικά των στηλών μπορούν να είναι δυναμικά και να οριστούν την ώρα της καταχώρησης. Αποθηκεύονται ως byte[], που σημαίνει ότι είναι δυνατή ακόμα και η καταχώρηση δεδομένων σε αυτά. Παρακάτω παρουσιάζονται επιγραμματικά τα πλεονεκτήματα και μειονεκτήματα της HBase: ΠΛΕΟΝΕΚΤΗΜΑΤΑ Εξαιρετικό για αναλύσεις σε συνδυασμό με Hadoop MapReduce Διαχείριση μεγάλου όγκου δεδομένων Επεκτασιμότητα (scale out) σε συνεργασία με το σύστημα αρχείων του ΜΕΙΟΝΕΚΤΗΜΑΤΑ Δεν υποστηρίζονται transactions. Τα JOINs χειρίζονται στο MapReduce layer Ευρετηριοποίηση και ταξινόμηση μόνο με βάση το κλειδί γραμμής

55 Hadoop, ακόμα και σε hardware του εμπορίου Ανοχή σε σφάλματα Δεν υποστηρίζονται built-in έλεγχοι ταυτότητας ή δικαιώματα Μεγάλη Ευελιξία στο σχήμα/ δεν έχει προκαθορισμένο σχήμα Μοναδικό σημείο αποτυχίας (όταν χρησιμοποιείται μόνο ένας HMaster) Διασύνδεση με το Hive για επερωτήματα τύπου SQL, για DBAs εξοικειωμένους με της T-SQL Auto-sharding (καταμερίζει περιοχών σε πολλαπλές φυσικές κατατμήσεις καθώς τα δεδομένα αυξάνονται) Auto failover Απλή διεπαφή χρήστη Ατομικότητα σε επίπεδο γραμμής (η μέθοδος PUT είτε θα γράψει είτε θα αποτύχει) Πίνακας 2-4: Πλεονεκτήματα και Μειονεκτήματα της HBase Η HBase είναι μία column-oriented βάση δεδομένων που χρησιμοποιεί το κατανεμημένο σύστημα αρχείων του Hadoop, γνωστό ως HDFS (Hadoop Distributed File System) για την αποθήκευση δεδομένων. Υλοποιείται από έναν master server και πολλούς region servers. Η αποθήκευση υλοποιείται με τη μορφή περιοχών (πίνακες). Αυτές οι περιοχές χωρίζονται και αποθηκεύονται σε region servers. Ο master server διαχειρίζεται τους region servers και όλες τις λειτουργίες που πραγματοποιούνται στο HDFS. Σε αντίθεση με τις σχεσιακές βάσεις δεδομένων, η HBase δεν υποστηρίζει μία δομημένη γλώσσα επερωτήσεων, όπως η SQL. H HBase έχει δικές της εντολές για την ανάκτηση

56 δεδομένων (χρησιμοποιώντας το σκανάρισμα σαν δύναμη). H HBase Shell είναι μία script γλώσσα (Ruby) που βοηθά στην αλληλεπίδραση με το σύστημα HBase, χρησιμοποιώντας τη διεπαφή της γραμμής εντολών. Η συγκεκριμένη μέθοδος υποστηρίζει τη δημιουργία, διαγραφή και τροποποίηση πινάκων (CRUD), καθώς και την εκτέλεση άλλων λειτουργιών όπως η καταχώρηση, μέτρηση, διαγραφή των δεδομένων στην HBase. Εκτός από αυτόν τον τρόπο, υπάρχει και το Hue (Hadoop User Experience), το οποίο παρέχει ένα web interface για την εκτέλεση ερωτημάτων καθώς και τη δημιουργία, συντήρηση και εκτέλεση διαφόρων εργασιών στο Hadoop και κατ επέκταση στην HBase. Αποτελείται από διάφορες εφαρμογές που αλληλοεπιδρούν με τα συστατικά του Hadoop, οι οποίες είναι επιγραμματικά: Εφαρμογή FileBrowser Beeswax Impala App Oozie App Pig App HBase Browser Table Browser Search App Job Browser Job Designer Περιγραφή Γραφικό περιβάλλον για αναζήτης/περιήγηση αρχείων Δημιουργία και εκτέλεση Hive ερωτημάτων Δημιουργία και εκτέλεση Impala ερωτημάτων Δημιουργία, υποβολή και προγραμματισμός ροών εργασιών και πακέτων Δημιουργία και εκτέλεση Pig scripts Διερεύνηση και τροποποίηση HBase πινάκων και δεδομένων Πρόσβαση σε Hive metadata Επερωτήσεις σε Solr και Solr Cloud Προβολή και πρόσβαση στις εργασίες MapReduce Δημιουργία και εκτέλεση εργασιών MapReduce Πίνακας 2-5: Εφαρμογές αλληλεπίδρασης με το Hadoop

57 Mongo DB Η MongoDB ανήκει στην κατηγορία των document βάσεων δεδομένων. Τα δεδομένα αποθηκεύονται σε μορφή εγγράφου, το οποίο είναι μία δομή δεδομένων αποτελούμενη από ζεύγη πεδίων και έτσι μία εγγραφή στη MongoDB είναι ένα έγγραφο. Οι βασικές έννοιες στη MongoDB είναι: Έγγραφο (document) Τα έγγραφα της MongoDB είναι παρόμοια με JSON αντικείμενα και μοιάζουν με δομές του προγραμματισμού που συσχετίζουν κλειδιά με τιμές (πχ, λεξικά, χάρτες, σχετιζόμενους πίνακες). Τυπικά, ένα MongoDB έγγραφο είναι ένα BSON έγγραφο (Binary JSON), το οποίο είναι η δυαδική αναπαράσταση ενός JSON με επιπρόσθετες πληροφορίες για τον τύπο. Οι τιμές των πεδίων μπορεί να περιλαμβάνουν άλλα έγγραφα, πίνακες ή πίνακες εγγράφων. Ένα έγγραφο είναι ανάλογο με μία γραμμή σε ένα πίνακα ενός RDBMS και κάθε πεδίο του εγγράφου ανάλογο με μία στήλη του πίνακα. Η δομή ενός εγγράφου στη MongoDB φαίνεται στην επόμενη εικόνα: Εικόνα 2-18: Η δομή μίας εγγραφής στη MongoDB Πηγή: Το επόμενο παράδειγμα παρουσιάζει ένα έγγραφο, με ζεύγη πεδίου τιμής, όπου οι τιμές είναι διάφορων τύπων: Το πεδίο name περιέχει ένα ενσωματωμένο έγγραφο που περιέχει τα πεδία Όνομα και Επώνυμο

58 Τα πεδία birth και death περιέχουν τιμές του τύπου Ημερομηνία. Το πεδίο contribs περιέχει ένα πίνακα από αλφαριθμητικά. Το πεδίο views περιέχει τιμή τύπου Αριθμός Long Εικόνα 2-19: Παράδειγμα εγγράφου στη MongoDB Πηγή: Συλλογή εγγράφων (collections) Η MongoDB αποθηκεύει όλα τα έγγραφα σε συλλογές. Μία συλλογή είναι μία ομάδα ομοειδών εγγράφων που έχουν ένα σετ κοινών ευρετηρίων. Τυπικά, όλα τα έγγραφα σε μια συλλογή έχουν μια παρόμοια ή συναφή σκοπό, αλλά τα έγγραφα εντός συλλογής μπορεί να έχουν διαφορετικά πεδία. Οι συλλογές είναι ανάλογες των πινάκων σε μία σχεσιακή βάση δεδομένων, αλλά στη MongoDB δεν επιβάλλεται να έχουν κάποιο σχήμα. Σχήμα Η MongoDB χρησιμοποιεί δυναμικό και ευέλικτο σχήμα. Είναι δυνατό να δημιουργεί μία συλλογή χωρίς να προσδιοριστεί η δομή των εγγράφων εντός της συλλογής, δηλαδή, τα πεδία ή ο τύπος των τιμών τους, σε αντίθεση με τους πίνακες σε SQL βάσεις. Η δομή των εγγράφων μπορεί να αλλάξει απλά προσθέτοντας νέα πεδία ή διαγράφοντας ήδη υπάρχοντα. Η ευελιξία αυτή διευκολύνει τη συσχέτιση των εγγράφων με μία οντότητα ή ένα αντικείμενο. Κάθε έγγραφο μπορεί να ταιριάξει με τα πεδία δεδομένων της οντότητας που αναπαριστά, ακόμη και αν τα δεδομένα έχουν ποικίλουν. Η μοντελοποίηση δεδομένων εξαρτάται από τις ανάγκες της εφαρμογής, τα χαρακτηριστικά της απόδοσης της βάσης δεδομένων και τα πρότυπα ανάκτησης δεδομένων. Συσχετίσεις

59 Υπάρχουν 2 τρόποι αποθήκευσης που επιτρέπουν στις εφαρμογές να αναπαριστούν συσχετίσεις: Αναφορές (references) και Ενσωματωμένα έγγραφα (embedded documents). Οι Αναφορές αποθηκεύουν σχέσεις μεταξύ δεδομένων περιλαμβάνοντας συνδέσμους(links) ή αναφορές από το ένα έγγραφο στο άλλο. Οι εφαρμογές μπορούν να επιλύσουν αυτές τις αναφορές και να έχουν πρόσβαση στα σχετικά δεδομένα. Ο 2 ος τρόπος των embedded εγγράφων αποτυπώνει τις σχέσεις σε μία ενιαία δομή εγγράφου. Στο παρακάτω παράδειγμα, απεικονίζονται συσχετίσεις με τον τρόπο των αναφορών (references): Εικόνα 2-20: Συσχέτιση μέσω References στη MongoDB Πηγή: Στο παρακάτω παράδειγμα, απεικονίζονται συσχετίσεις με τον τρόπο των embedded εγγράφων σε μία ενιαία δομή εγγράφου: Εικόνα 2-21: Συσχέτιση μέσω Embedded εγγράφου στη MongoDB Πηγή:

60 Τα κύρια χαρακτηριστικά της MongoDB είναι: 1. Υψηλή απόδοση 2. Μεγάλη διαθεσιμότητα: Η MongoDB παρέχει υψηλή διαθεσιμότητα μέσω της λειτουργικότητας που ονομάζεται replica sets. Πρόκειται για μία συλλογή από MongoDB servers που διατηρούν τα ίδια δεδομένα και παρέχουν πλεονασμό με αποτέλεσμα να αυξάνουν τη διαθεσιμότητα. 3. Αυτόματη οριζόντια επεκτασιμότητα (sharding): Η MongoDB παρέχει οριζόντια επεκτασιμότητα χρησιμοποιώντας μια τεχνική που ονομάζεται sharding. Η διαδικασία του sharding διανέμει τα δεδομένα σε πολλαπλές φυσικές μηχανές που ονομάζονται shards. Το sharding επιτρέπει στα συστήματα MongoDB να αντιμετωπίσουν τους περιορισμούς υλικού ενός μοναδικού εξυπηρετητή, όπως τα bottlenecks στη RAM ή στο I/O των δίσκων, χωρίς να προστίθεται επιπλέον πολυπλοκότητα στην εφαρμογή. Το sharding είναι διαφανές στις εφαρμογές. Είτε υπάρχει ένα είτε εκατό shards, ο κώδικας της εφαρμογής για τα ερωτήματα στη MongoDB είναι ο ίδιος. Οι εφαρμογές στέλνουν ερωτήματα σε έναν δρομολογητή ερωτημάτων που στέλνει τα ερωτήματα στα κατάλληλα shards. Κάθε shard αποτελεί μία ανεξάρτητη βάση δεδομένων και συνολικά τα shards αποτελούν τη μοναδική λογική βάση δεδομένων. 4. Συναλλαγές και ACID ιδιότητες Η MongoDB δεν υποστηρίζει joins ή συναλλαγές (transactions) ανάμεσα σε πολλαπλά έγγραφα. Ωστόσο, διαθέτει δευτερεύοντα ευρετήρια, μια εκφραστική γλώσσα ερωτημάτων, ατομικότητα σε επίπεδο εγγράφου, και απολύτως συνεπή reads. Οι ACID εγγυήσεις που παρέχονται από τη MongoDB διασφαλίζουν πλήρη απομόνωση καθώς ένα έγγραφο ενημερώνεται. Οποιοδήποτε σφάλμα προκαλεί τη λειτουργία να αντιστραφεί και έτσι υπάρχει πάντα μια συνεπής όψη του εγγράφου. Τα πλεονεκτήματα χρήσης εγγράφων συνοπτικά είναι:

61 1. Τα έγγραφα (αντικείμενα) αντιστοιχούν σε native τύπους δεδομένων σε πολλές γλώσσες προγραμματισμού. 2. Τα ενσωματωμένα έγγραφα (embedded documents) και οι πίνακες μειώνουν την ανάγκη ακριβών join. 3. Το δυναμικό σχήμα υποστηρίζει καθολικά τον πολυμορφισμό. Η MongoDB υποστηρίζει μία πλούσια, ad-hoc δικής της γλώσσα επερωτήσεων. Μία επερώτηση στοχεύει σε μία συγκεκριμένη συλλογή εγγράφων. Οι επερωτήσεις προσδιορίζουν τα κριτήρια και τις συνθήκες που προσδιορίζουν τα έγγραφα που η MongoDB θα επιστρέψει στον client. Οι επερωτήσεις μπορεί επίσης να περιλαμβάνουν μία προβολή για το ποια συγκεκριμένα πεδία από τα έγγραφα που βρέθηκαν θα επιστραφούν, και επιπρόσθετα μπορεί να γίνει χρήση των εντολών ταξινόμησης (sort order), περιορισμού εγγραφών (limit) κ.ο.κ. Η MongoDB παρέχει τη μέθοδο db.collection.find(), η οποία δέχεται τα κριτήρια και τις προβολές και επιστρέφει έναν κέρσορα με τα έγγραφα που ταιριάζουν στα κριτήρια. Αντίστοιχα, υπάρχουν εντολές για τις υπόλοιπες CRUD λειτουργίες: db.collection.find() db.collection.insert() db.createcollection() db.collection.update() $set / $unset db.collection.createindex() db.collection.drop() db.collection.remove() db.collection.update() db.collection.distinct() db.collection.findone() $ne / $and / $or / $gt / $lt / $exists / $lte / $regex

62 limit() skip() explain() sort() count() Αν, για παράδειγμα, υπάρχει σε μία σχεσιακή βάση ο πίνακας users και στη MongoDB μία συλλογή με όνομα users, που περιέχει έγγραφα που ακολουθούν το εξής πρότυπο: { _id: ObjectId ("509a8fb2f3f4948bd2f983a0"), user_id: "abc123", age: 55, status: 'A' Παρακάτω παρουσιάζονται τα statements είτε στην SQL είτε στη MongoDB: Statement SQL MongoDB Create table Drop table Insert record CREATE TABLE users ( id MEDIUMINT NOT NULL AUTO_INCREMENT, user_id Varchar(30), age Number, status char(1), PRIMARY KEY (id) ) DROP TABLE users INSERT INTO users (user_id, age, status) VALUES ("bcd001", 45, "A") db.createcollection("users") db.users.drop() db.users.insert( { user_id: "bcd001", age: 45, status: "A" )

63 Select * SELECT * FROM users db.users.find() Select user_id, status Select top 1 Select Distinct Select count(*) Where Order By Update Delete SELECT user_id, status FROM users SELECT * FROM users LIMIT 1 SELECT DISTINCT(status) FROM users SELECT COUNT(*) FROM users SELECT * FROM users WHERE status = "A" AND age = 50 SELECT * FROM users WHERE status = "A" ORDER BY user_id ASC UPDATE users SET status = "C" WHERE age > 25 DELETE FROM users db.users.find( {, { user_id: 1, status: 1, _id: 0 ) db.users.findone() ή db.users.find().limit(1) db.users.distinct( "status" ) db.users.count() ή db.users.find().count() db.users.find( { status: "A", age: 50 ) db.users.find( { status: "A" ).sort( { user_id: 1 ) db.users.update( { age: { $gt: 25, { $set: { status: "C", { multi: true ) db.users.remove( { status: "D" ) WHERE status = "D" Πίνακας 2-6: SQL vs MongoDB statement

64 Neo4j Ένας γράφος καταχωρεί δεδομένα σε κόμβους και συσχετίσεις, στοιχεία τα οποία μπορεί να έχουν ιδιότητες και αυτό το μοντέλο είναι γνωστό ως Property Graph Model. Εικόνα 2-22: Τα building blocks του Property Graph [41] Η Neo4j βασίζεται στο μοντέλο δεδομένων του Property Graph και αποτελείται από κόμβους, συσχετίσεις και τις ιδιότητές τους. Βασικά στοιχεία της Neo4j: Κόμβος (Node) Οι κόμβοι συχνά αναπαριστούν οντότητες. Εκτός από συσχετίσεις, ένας κόμβος μπορεί να έχει καμία ή περισσότερες ιδιότητες ή/και ετικέτες. Ο απλούστερο δυνατός γράφος είναι ένας μοναδικός Κόμβος. Συσχέτιση (Relationship) Οι συσχετίσεις οργανώνουν τους κόμβους, ενώνοντάς τους. Οι συσχετίσεις συνδέουν σημασιολογικά 2 κόμβους-οντότητες και έχουν κατεύθυνση, τύπο, κόμβο αρχής και κόμβο τέλους καθώς και δικές τους ιδιότητες. Αποθηκεύονται αποτελεσματικά και έτσι οι κόμβοι διαμοιράζονται τις συσχετίσεις χωρίς να επιβαρύνεται η απόδοση. Παρόλο που οι συσχετίσεις έχουν κατεύθυνση, η περιήγηση γίνεται ανεξάρτητα από την κατεύθυνση αυτή. Ακολουθείται ο κανόνας: «No broken links». Δηλαδή, εφόσον μία συσχέτιση έχει

65 κόμβο έναρξης και κόμβο τέλους, δεν μπορεί να διαγραφεί ένας κόμβος χωρίς να διαγραφούν και οι συσχετιζόμενες σχέσεις. Έτσι, μπορεί να υποθέσει κανείς ότι μία υπάρχουσα σχέση δεν θα καταλήγει ποτέ σε ένα κόμβο που δεν υφίσταται. Ιδιότητα (Property) Οι ιδιότητες κόμβων και συσχετίσεων είναι τιμές με ένα όνομα. Οι τιμές μπορεί να είναι τύπου: Αριθμητική, Αλφαριθμητική, Boolean, Συλλογή από οποιοδήποτε άλλο τύπο τιμών. Ετικέτα (Label) Οι ετικέτες αναθέτουν ρόλους ή τύπος σε κόμβους και είναι προαιρετικές. Η ετικέτα είναι μία ονομαστική δομή του γράφου που χρησιμοποιείται για να ομαδοποιεί κόμβους σε συλλογές. Έτσι, όλοι οι κόμβοι με ίδια ετικέτα ανήκουν στην ίδια συλλογή. Με αυτόν τον τρόπο, διευκολύνονται τα ερωτήματα στο γράφο και η εκτέλεσή τους είναι πιο αποτελεσματική. Ένας κόμβος μπορεί να έχει από μηδέν έως περισσότερες ετικέτες. Οι ετικέτες προστίθενται και αφαιρούνται κατά την εκτέλεση (run-time) με αποτέλεσμα να μπορούν να χρησιμοποιηθούν για να δηλώσουν προσωρινές καταστάσεις για τους κόμβους. Διάσχιση (Traversal) Μία διάσχιση πλοηγείται μέσα στο γράφημα για να βρει μονοπάτια προκειμένου να δώσει απαντήσεις στα επερωτήματα που θέτει κάποιος στο γράφο. Διασχίζοντας ένα γράφο σημαίνει ότι επισκεπτόμαστε τους κόμβους του, ακολουθώντας συσχετίσεις σύμφωνα με κάποιους κανόνες. Μονοπάτι (Path) Ένα μονοπάτι αποτελείται από ένα ή περισσότερους κόμβους με συνδεδεμένες συσχετίσεις και ανακτάται σαν αποτέλεσμα μίας διάσχισης. Το μικρότερο πιθανό μονοπάτι έχει μήκος μηδέν και αποτελείται από ένα μόνο κόμβο, χωρίς συσχέτιση

66 Σχήμα (Schema) Στη Neo4j το σχήμα είναι προαιρετικό. Μπορεί να χρησιμοποιηθεί η Neo4j χωρίς καθόλου σχήμα μέχρι τη στιγμή που θα χρειαστεί να επωφεληθούμε τα πλεονεκτήματα της ύπαρξης σχήματος. Στη Neo4j είναι επίσης διαθέσιμα τα ευρετήρια (indexes), τα οποία βελτιώνουν την απόδοση και την ταχύτητα αναζήτησης ανάμεσα στους κόμβους του γράφου. Αφού επιλεγούν οι ιδιότητες που θα χρησιμοποιηθούν ως ευρετήρια, η Neo4j εγγυάται ότι θα παραμένουν ανανεωμένα για όσο ο γράφος εξελίσσεται. Επιπλέον, μπορούν να χρησιμοποιηθούν περιορισμοί (constraints) που επιτρέπουν να προσδιοριστούν κανόνας για το πώς πρέπει να είναι τα δεδομένα προκειμένου η βάση να διατηρείται καθαρή. Οποιαδήποτε αλλαγή παραβιάζει κάποιο περιορισμό, απορρίπτεται. Το μοντέλο Labeled Property Graph θα φανεί οικείο σε όποιον έχει εργαστεί πάνω σε διαγράμματα οντοτήτων-συσχετίσεων. Περιλαμβάνει συνδεδεμένες οντότητες (κόμβους), οι οποίες έχουν ιδιότητες και οι κόμβοι μπορεί να επισημανθούν με ετικέτες που αντιπροσωπεύουν τους διαφορετικούς ρόλους τους στον τομέα σας. Εικόνα 2-23: Παράδειγμα μοντέλου δεδομένων Labeled Property Graph [41] H Neo4j παρέχει μία αντικειμενοστραφή και ευέλικτη δομή δικτύου. Τα βασικά στοιχεία που τη χαρακτηρίζουν είναι:

67 ACID συναλλαγές Υψηλή διαθεσιμότητα Επέκταση σε δισεκατομμύρια κόμβους και συσχετίσεις Επερωτήματα με μεγάλη ταχύτητα μέσω διάσχισης Δηλωτική γλώσσα επερωτημάτων Είναι αξιόπιστη, συμβατή με τις ACID ιδιότητες, παρέχει υψηλή διαθεσιμότητα και είναι επεκτάσιμη. Η Neo4j επιβάλλει ότι όλες οι πράξεις που τροποποιούν τα δεδομένα συμβαίνουν μέσα σε μια συναλλαγή (transaction), εξασφαλίζοντας συνεπή δεδομένα. Ένας γράφος αποθήκευσης δεδομένων μπορεί εύκολα να προστεθεί σε οποιαδήποτε εφαρμογή και στη συνέχεια να επεκταθεί σε μέγεθος και πολυπλοκότητα καθώς η εφαρμογή εξελίσσεται, με πολύ μικρό αντίκτυπο στην απόδοση. Είτε ξεκινώντας νέα ανάπτυξη είτε εμπλουτίζοντας υπάρχουσα λειτουργικότητα, η Neo4j επηρεάζεται μόνο από περιορισμούς του hardware. Μπορεί να υλοποιηθεί είτε ως server, προσφέροντας ένα REST API για χρήση είτε σαν ένα single file με τη χρήση του κατάλληλου Java API (βιβλιοθήκες διαχείρισης του αρχείου CRUD). Η Neo4j δεν υποστηρίζει κατάτμηση (sharding) και δεν πρέπει να χρησιμοποιείται όταν δεν υπάρχουν συσχετίσεις μεταξύ των δεδομένων. Η Neo4j χρησιμοποιεί τη γλώσσα CYPHER για την εκτέλεση επερωτήσεων. Οι επερωτήσεις πραγματοποιούνται μέσω διάσχισης, εκτελώντας εκατομμύρια βήματα διάσχισης ανά δευτερόλεπτο. Ένα βήμα διάσχισης μοιάζει με ένα join σε ένα RDBMS. Η σύνταξη της CYPHER παρέχει έναν γνώριμο τρόπο να ταιριάζει τα πρότυπα των κόμβων και των σχέσεων σε ένα γράφο και επιτρέπει να τεθούν επερωτήματα και ενημερώσεις στις δομές του γράφου με συνοπτικές δηλώσεις. Η γλώσσα Cyphern είναι απλή αλλά δυνατή. Πολλές φορές, κατά τη συγγραφή SQL επερωτήματος με πολλαπλά Joins, πολύ γρήγορα ο χρήστης μπερδεύεται για το τι τελικά κάνει το query λόγω του τεχνικού «θορύβου». Στη Cypher, η σύνταξη παραμένει καθαρή και επικεντρωμένη στο concept του πεδίου. Δηλαδή, επικεντρώνεται στην έκφραση για το τι θα ανακτηθεί παρά για το πώς θα

68 ανακτηθεί. Οι περισσότερες λέξεις κλειδιά όπως WHERE και ORDER BY είναι εμπνευσμένα από την SQL. Το ταίριασμα προτύπων δανείζεται εκφράσεις από την SPARQL. Άλλα σχετικά με τη σημασιολογία της συλλογής έχουν δανειστεί από γλώσσες όπως Haskell και Python. Μερικές εντολές για ανάγνωση από το γράφο είναι: MATCH: το πρότυπο (pattern) με το οποίο θα κάνει το ταίριασμα. Αποτελεί το πιο κλασικό τρόπο για ανάκτηση δεδομένων. WHERE: προσθέτει περιορισμούς και φιλτράρει τα δεδομένα. RETURN: τι θα επιστραφεί σαν αποτέλεσμα. Εντολές για ενημέρωση του γράφου: CREATE (and DELETE): δημιουργία (και διαγραφή) κόμβων και συσχετίσεων. SET (and REMOVE): προσθήκη (και αφαίρεση) ετικέτας σε κόμβους ή ορισμός τιμών σε ιδιότητες. MERGE: ταιριάζει υπάρχοντες κόμβους ή δημιουργεί νέους κόμβους και πρότυπα. Στο επόμενο παράδειγμα φαίνεται η μοντελοποίηση ενός οργανισμού με τις οντότητες Person, Department και Project τόσο σε ένα RDBMS όσο και σε ένα γράφο

69 Εικόνα 2-24: Μοντελοποίηση σε RDBMS Πηγή: Εικόνα 2-25: Μοντελοποίηση σε γράφο Πηγή: Για να απαντηθεί το εξής ερώτημα «Εμφάνισε λίστα με τα ονόματα των υπαλλήλων του τμήματος IT Department», τα queries σε SQL και Cypher αντίστοιχα θα ήταν: SQL statement Cypher Statement

70 SELECT name FROM Person LEFT JOIN Person_Department ON Person.Id = Person_Department.PersonId LEFT JOIN Department MATCH (p:person)<-[:employee]- (d:department) WHERE d.name = "IT Department" RETURN p.name ON Department.Id = Person_Department.DepartmentId WHERE Department.name = "IT Department" Πίνακας 2-7: SQL vs Cypher statement

71 3 Υλοποίηση 3.1 Σχήμα Δεδομένων Στην ενότητα αυτή θα γίνει η περιγραφή του σχήματος που έχει επιλεγεί από την DBPedia. Οι οντότητες και οι ιδιότητες που επιλέχθηκαν είναι ενδεικτικές από τo σύνολο της οντολογίας - η οποία περιέχει περίπου αντικείμενα - αλλά ικανές για να αξιολογηθούν με επιτυχία οι τρεις NoSQL βάσεις και να βγάλουν τελικά ασφαλή συμπεράσματα. Οι βασικές οντότητες που εξετάζει η μελέτη είναι οι: 1. Movie με αντικείμενα ( 2. Film Director με αντικείμενα ( 3. Distributor με 5278 αντικείμενα ( Η οντότητα 1 έχει τις παρακάτω διασυνδέσεις με τις 2 και 3. Movie dbo:director Film Director Movie dbo:distributor Distributor Στις διασυνδέσεις αυτές φαίνεται και η υλοποίηση που έχει η DBpedia σχετικά με τα RDF triples. Για παράδειγμα, για την ταινία American Teacher έχουμε τις εξής τριπλέτες: American_Teacher dbo:director Vanessa_Roth American_Teacher dbo:director Brian_McGinn American_Teacher dbo:distributor Gravitas_Ventures Τα SPARQL ερωτήματα τα οποία εκτελέστηκαν στο Virtuoso Endpoint της DBPedia για την ανάκτηση των αντικειμένων είναι τα εξής: Ερώτημα α : Εμφάνισε τα αντικείμενα της οντότητας SELECT * WHERE {

72 ?a a < foaf:name?name. OPTIONAL {?a rdfs:comment?comment OPTIONAL {?a dbo:abstract?abstract OPTIONAL {?a dbo:budget?budget FILTER langmatches(lang(?comment),'en') FILTER langmatches(lang(?abstract),'en') Ερώτημα β : Εμφάνισε τα αντικείμενα της οντότητας director PREFIX dbpedia-owl: < SELECT * WHERE {?film dbpedia-owl:director?director. Ερώτημα γ : Εμφάνισε τα αντικείμενα της οντότητας distributor PREFIX dbpedia-owl: < SELECT * WHERE {?film dbpedia-owl:distributor?distributor. 3.2 Virtuoso Query Data Tool H DBPedia όπως και τα περισσότερα data sources τα οποία διαχειρίζονται RDF δεδομένα και χρησιμοποιούν Virtuoso, προσφέρουν τον υποστηριζόμενο από την εταιρία online SPARQL query editor. Το συγκεκριμένο εργαλείο καθώς και όμοια με αυτό εργαλεία τρίτων, έχουν περιορισμούς οι οποίοι τελικά οδήγησαν στην υλοποίηση του Virtuoso Query Data Tool. Ο πρώτος περιορισμός είναι ότι υπάρχει όριο στα αντικείμενα τα οποία επιστρέφει ένα ερώτημα σαν αποτελέσματα. Το άνω αυτό φράγμα συνήθως φτάνει στα αντικείμενα. Μια λύση σε αυτό το πρόβλημα είναι να γίνει χρήση του offset (1 η φορά να τρέξει για offset 0, 2 η για offset 10000, 3 η για 20000, κ.ο.κ. έως ότου να επιστρέψει τα

73 συνολικά αποτελέσματα). Ωστόσο, παρατηρήθηκε ότι υπάρχουν περιπτώσεις που το άνω αυτό φράγμα δημιουργεί timeout προβλήματα. Η λύση σε αυτό είναι να εμπλακεί στα ερωτήματα και το limit (1 η φορά να τρέξει για offset 0 και limit 2000, 2 η για offset 2000 και limit 2000, 3 η για offset 4000 και limit 2000, κ.ο.κ.). Τι γίνεται στην περίπτωση που το ερώτημα γυρίζει σαν αποτέλεσμα εγγραφές; Θα έπρεπε ο χρήστης να εκτελέσει 500 ερωτήματα αλλάζοντας κατάλληλα τα limit και offset. Ως προς τα προβλήματα που μόλις αναφέρθηκαν υπάρχουν 3 rd part εργαλεία που τα λύνουν σε ικανοποιητικό αριθμό. Το νέο πρόβλημα όμως που συναντάει κανείς σε αυτά είναι ότι είναι web υπηρεσίες οπότε τελικά υπάρχει ένας ενδιάμεσος σταθμός ανάμεσα στον χρήση και στο Virtuoso Endpoint. Αυτό σημαίνει πως υπάρχει μεγάλη επίπτωση στην ταχύτητα εφόσον τα data θα πρέπει να ταξιδέψουν πρώτα από την DBPedia στον server που τρέχει το 3rd part εργαλείο και σε δεύτερο στάδιο στον τελικό χρήστη. To Virtuoso Query Data Tool είναι μια desktop εφαρμογή η οποία λύνει τα προβλήματα που μόλις αναλύθηκαν. Αρχικά δεν υπάρχει περιορισμός στα αποτελέσματα τα οποία επιστρέφουν τα ερωτήματα που τρέχουν, δεύτερον τα ερωτήματα προστατεύονται, έτσι ώστε να μην εμφανίζονται timeout exceptions και τέλος υπάρχει άμεση αλληλεπίδραση με το Virtuoso Endpoint χωρίς να υπάρχει κάποιος ενδιάμεσος κόμβος. Η υλοποίηση έγινε χρησιμοποιώντας τεχνολογίες αιχμής. Συγκεκριμένα υλοποιήθηκε σε Microsoft.NET Framework ενώ το Visual Studio 2015 χρησιμοποιήθηκε ως editor. Επιπλέον οι διαδεδομένες βιβλιοθήκες RestSharp και NewtonSoft.JSON συνέβαλλαν έτσι ώστε να πραγματοποιηθούν χωρίς δυσκολίες οι HTTP κλίσεις στο Endpoint και το parsing των αποτελεσμάτων σε JSON. To Virtuoso Query Data Tool έχει υλοποιηθεί με τέτοιο τρόπο ώστε να είναι εύκολα επεκτάσιμο όσον αφορά στην λειτουργικότητά του καθώς και στο UI/UX που προσφέρει. Ως προς το UI πρέπει να αναφερθεί πως στον τελικό χρήστη προσφέρεται η δυνατότητα να επεξεργαστεί τα αποτελέσματα όπως επιθυμεί (filtering, ordering, grouping) και να τα εξάγει ως Excel, CSV, Json, Html και Txt αρχεία. Τέλος έχει αναπτυχθεί έτσι ώστε να μπορεί να χρησιμοποιηθεί σε οποιοδήποτε Virtuoso σύστημα χωρίς να εξαρτάται από τα RDF data ή τα triples που

74 είναι αποθηκευμένα στο καθένα από αυτά. Αντιλαμβάνεται κανείς πόσο δυναμικό είναι το εργαλείο που αναπτύχθηκε στα πλαίσια της διπλωματικής αυτής και τελικά τι δυνατότητες έχει. Η επόμενη εικόνα δείχνει ένα στιγμιότυπο στο οποίο έχει τρέξει η ερώτηση: PREFIX dbpedia-owl: < PREFIX dct: < SELECT?person?nationality {?person a dbpedia-owl:person.?person dbp:nationality?nationality στο endpoint της DBPedia και έχει φέρει σαν αποτέλεσμα, αντικείμενα τα οποία έχουν επεξεργαστεί από την διεπαφή του χρήστη, έτσι ώστε να είναι σε αλφαβητική σειρά και να έχουν χωριστεί σε ομάδες ανάλογα με την εθνικότητά τους. Εικόνα 3-1: Virtuoso Query Data Tool - DBPedia example

75 Στην επόμενη εικόνα φαίνεται το στιγμιότυπο που έχει εκτελεστεί στο endpoint της IMDB το ερώτημα : select?film?character?actor where {?performance a < < Εικόνα 3-2: Virtuoso Query Data Tool - IMDB example Στην επόμενη εικόνα φαίνεται το στιγμιότυπο που έχει εκτελεστεί στο endpoint της GeoData το ερώτημα : PREFIX prf1: < PREFIX rdfs: < PREFIX lgdo: <

76 SELECT?HighwayThing_label?HighwayThing_long?HighwayThing_lat WHERE {?HighwayThing a lgdo:highwaything.?highwaything rdfs:label?highwaything_label.?highwaything prf1:long?highwaything_long.?highwaything prf1:lat?highwaything_lat. Εικόνα 3-3: Virtuoso Query Data Tool - GeoData example Τα βασικά σημεία του πηγαίου κώδικα παρατίθενται στο Παράρτημα Α. 3.3 Περιγραφή Benchmarking Περιβάλλοντος Για την κατασκευή του κατάλληλου περιβάλλοντος το οποίο επιτρέπει την εκτέλεση ερωτημάτων στις τρεις NοSQL βάσεις καθώς και την εξαγωγή συμπερασμάτων,

77 χρησιμοποιήθηκε η τεχνολογία των virtual μηχανημάτων και συγκεκριμένα το περιβάλλον Oracle Virtual Box. Σαν host λειτούργησε ένας υπολογιστής με τα εξής χαρακτηριστικά: Host machine Λειτουργικό σύστημα Επεξεργαστής Μνήμη RAM Τύπος συστήματος Σκληρός Δίσκος Windows 10 Enterprise Intel Core 2.00GHz 2.60 GHz 8 GB 64-bit λειτουργικό με x64 επεξεργαστή 256GB PCIe SSD Πίνακας 3-1: Χαρακτηριστικά Host μηχανήματος Για κάθε NoSQL βάση δημιουργήθηκε διαφορετικό εικονικό μηχάνημα. Στους επόμενους πίνακες φαίνονται τα χαρακτηριστικά του κάθε vm καθώς και οι εκδόσεις που χρησιμοποιήθηκαν για κάθε βάση ή πλατφόρμας μέσω τις οποία εκτελέστηκαν τα ερωτήματα. HBASE VM Λειτουργικό σύστημα CentOS 6.4 Επεξεργαστής Virtual Intel Core 2.00GHz x 2 Μνήμη RAM Τύπος συστήματος Σκληρός Δίσκος 6 GB 64-bit λειτουργικό με x64 επεξεργαστή 70GB Hard Disk Cloudera Hue HBASE Hive Editor Πίνακας 3-2: HBase Virtual Machine MongoDB VM

78 Λειτουργικό σύστημα Ubuntu LST Επεξεργαστής Virtual Intel Core 2.00GHz x 2 Μνήμη RAM Τύπος συστήματος Σκληρός Δίσκος 6 GB 64-bit λειτουργικό με x64 επεξεργαστή 78GB Hard Disk MongoDB Robomongo Πίνακας 3-3: MongoDB Virtual Machine Neo4j VM Λειτουργικό σύστημα Επεξεργαστής Μνήμη RAM Τύπος συστήματος Σκληρός Δίσκος Ubuntu LST Virtual Intel Core 2.00GHz x 6 GB 64-bit λειτουργικό με x64 επεξεργαστή 48GB Hard Disk Neo4j Πίνακας 3-4: Neo4J Virtual Machine Για τις μετρήσεις τα βήματα που ακολουθήθηκαν είναι τα εξής : 1. Εκτέλεση των ερωτημάτων στο Virtuoso Query Data Tool a. Για τις οντότητες Director και Distributor τα ερωτήματα φαίνονται στο κεφάλαιο 3.1 b. Για την οντότητα Film το ερώτημα φαίνεται στο κεφάλαιο 3.1. Το ερώτημα αυτό εκτελέστηκε δύο φορές χρησιμοποιώντας το LIMIT ώστε να έρθουν περιορισμένες εγγραφές. Την πρώτη φορά ήρθαν 21,360 εγγραφές (πακέτο 1) ενώ τη δεύτερη 42,720 που είναι οι μισές (πακέτο 2). Τέλος εκτελέστηκε και τρίτη φορά χωρίς την χρήση του LIMIT και ήρθαν όλες οι 85,450 εγγραφές (πακέτο 3) 2. Export των αποτελεσμάτων (πακέτο 1,2 και 3) στην κατάλληλη μορφή

79 a. CSV για τις HBASE και Neo4j b. JSON για τη MongoDB 3. Εισαγωγή των δεδομένων που σχετίζονται με τις βοηθητικές οντότητες Director και Distributor 4. Εισαγωγή του πακέτου 1 και στις τρεις βάσεις με χρονομέτρηση. 5. Εκτέλεση του ερωτήματος «φέρε όλες τις ταινίες» στις τρεις βάσεις με χρονομέτρηση. 6. Εκτέλεση του ερωτήματος «φέρε όλες τις ταινίες οι οποίες έχουν πάνω από έναν σκηνοθέτη» 7. Εκτέλεση του ερωτήματος «φέρε όλες τις ταινίες οι οποίες έχουν για διανομέα τα Universal Studios» 8. Τα βήματα 4,5,6,7 επαναλήφθηκαν για το πακέτο 2 9. Τα βήματα 4,5,6,7 επαναλήφθηκαν για το πακέτο 3 Όπως φαίνεται οι μετρήσεις που έγιναν είχαν σαν σκοπό να βγουν συμπεράσματα για την απόδοση των τριών NoSQL βάσεων στις εξής 4 βασικότερες ενέργειες : Απλή εισαγωγή δεδομένων χωρίς κάποια επιπλέον επεξεργασία Απλή ανάκτηση δεδομένων χωρίς κάποια επιπλέον επεξεργασία ή εκτέλεση κάποια μεθόδου Ανάκτηση δεδομένων στα οποία πρέπει να εκτελεστεί aggregate μέθοδος για το grouping των δεδομένων και φιλτράρισμα τους Ανάκτηση δεδομένων υπό συνθήκη Τέλος η επιλογή στο να χρησιμοποιηθούν 3 πακέτα δεδομένων οφείλεται στο ότι με τον τρόπο αυτό οι μετρήσεις θα δείξουν την τάση που ακολουθεί ο χρόνος εκτέλεσης των ενεργειών σε σχέση με το πλήθος των εγγραφών. 3.4 Αξιολόγηση Παρόλο που τα ερωτήματα τα οποία εκτελέστηκαν δεν ήταν μεγάλης κλίμακας και δεν πίεσαν στα άκρα τις τρεις βάσεις, ήταν όμως ικανά ώστε να αναδείξουν τις διαφορές και τις ομοιότητές που έχουν μεταξύ τους. H μεγαλύτερη ομοιότητα τους είναι ότι και οι τρεις έχουν μη ώριμες γλώσσες ερωτημάτων (και όλες είναι διαφορετικές μεταξύ τους) που δεν ακολουθούν κάποιο

80 πρότυπο. Οι MongoDB και Neo4j προσπαθούν να ξεπεράσουν το πρόβλημα αυτό δίνοντας την δυνατότητα να μπορούν εκτελεστούν ερωτήματα με τη χρήση JavaScript και Cypher αντίστοιχα. H πολυπλοκότητα και η ανομοιογένεια αυτή, είχε σαν αποτέλεσμα η διαδικασία γραφής των ερωτημάτων να καταλήξει να γίνει εξαιρετικά επίπονη κάτι το οποίο μπορεί να οδηγήσει τον χρήστη στην αποτροπή από τη χρήση τους. Βέβαια, παρατηρήθηκε πως υπάρχει μεγάλη απήχηση και ευρεία χρήση των NoSQL βάσεων από την κοινότητα των προγραμματιστών. Κάτι το οποίο είναι λογικό μιας και στο σύνολό τους δίνουν κατάλληλους drivers σε πλήθος γλωσσών προγραμματισμού. Οι drivers αυτοί κρύβουν την πολυπλοκότητα των query γλωσσών. Για παράδειγμα η εκτέλεση ερωτημάτων, στις τρεις βάσεις που μελετάμε, με τη χρήση του.νετ Framework χρησιμοποιώντας τους κατάλληλους drivers, απαιτεί και για τις τρεις βασικές γνώσεις σε Linq. H Linq προσφέρει τη δυνατότητα εκτέλεσης ερωτημάτων σε C#, κάτι με το οποίο όλοι οι.net προγραμματιστές είναι εξοικειωμένοι. Οι drivers με τη σειρά τους, μεταφράζουν το Linq ερώτημα σε ερώτηση που NoSQL βάση κατανοεί. Στο κεφάλαιο 3.3 πραγματοποιήθηκε η περιγραφή των ενεργειών που εκτελέστηκαν και για τις οποίες καταγράφηκαν οι χρόνοι εκτέλεσής τους. Με τα γραφήματα που ακολουθούν γίνεται η γραφική απεικόνιση των αποτελεσμάτων αυτών και όπως θα δούμε βοήθησαν πολύ στην εξαγωγή των συμπερασμάτων Εισαγωγή δεδομένων Η πρώτη μέτρηση αφορά την απόδοση των βάσεων ως προς τη βασική λειτουργία της εισαγωγής δεδομένων χωρίς επιπλέον επεξεργασία τους κατά τη διάρκεια αυτής

81 records records records Hbase MongoDB Neo4j Εικόνα 3-4: Αποτελέσματα εισαγωγής δεδομένων Κυρίως η HBase αλλά και η MongoDB αποδίδουν χωρίς ιδιαίτερα προβλήματα στην συγκεκριμένη ενέργεια. Το αξιοσημείωτο για τις δύο αυτές βάσεις είναι πως με την αύξηση του πλήθους των εγγραφών, ο χρόνος που απαιτείται για την ολοκλήρωση της εισαγωγής δεδομένων, αυξάνεται γραμμικά. Το χαρακτηριστικό αυτό αποτελεί ανταγωνιστικό πλεονεκτήματα σε συστήματα με ανάγκη για τεράστιο αριθμό από inserts. Η Neo4j αντίθετα, φαίνεται πως ακολουθεί σε απόδοση τις άλλες δύο με μικρά προβλήματα να εμφανίζονται όσο αυξάνοντα τα data προς εισαγωγή. Πάντως μελλοντικές εκδόσεις της, φαίνεται να βελτιώνουν σε ικανοποιητικό βαθμό τις ταχύτητες αυτές Ανάκτηση δεδομένων Το επόμενο διάγραμμα αφορά τις μετρήσεις που σχετίζονται με την απόδοση των βάσεων ως προς τη βασική λειτουργία της ανάκτησης δεδομένων χωρίς επιπλέον διαχείριση (χωρίς χρήση φίλτρων, aggregate functions, ταξινόμηση κτλ.)

82 4,5 4 3,5 3 2,5 2 1,5 1 0, records records records Hbase MongoDB Neo4j Εικόνα 3-5 Αποτελέσματα ανάκτησης δεδομένων Σε αυτή την περίπτωση, η HBase φαίνεται πως υπερτερεί σε σύγκριση με τα άλλα δύο συστήματα. Παρατηρούμε επίσης με ενδιαφέρον ότι ο χρόνος εκτέλεσης δεν επηρεάζεται σημαντικά με την αύξηση των δεδομένων. Συνεχίζει να υφίσταται γραμμική εξάρτηση μεταξύ χρόνου εκτέλεσης και όγκου δεδομένων. Οι άλλες δύο NoSQL βάσεις ακολουθούν με μικρότερη ταχύτητα εκτέλεσης και μεταξύ των δύο, η MongoDB έχει μικρό πλεονέκτημα Ανάκτηση δεδομένων ύστερα από ομαδοποίηση Στο επόμενο διάγραμμα απεικονίζονται οι μετρήσεις που αφορούν την ανάκτηση δεδομένων με χρήση aggregation και συγκεκριμένα grouping και sum

83 records records records Hbase MongoDB Neo4j Εικόνα 3-6 Αποτελέσματα ανάκτησης δεδομένων Στη συγκεκριμένη περίπτωση αρχίζει να γίνεται εμφανής η αδυναμία της HBase, καθώς δεν έχει τη δυνατότητα εύκολης διαχείρισης των aggregations που εκτελούνται στα δεδομένα. Αντίθετα, η MongoDB υπερτερεί έναντι των υπολοίπων καθώς ο τρόπος αποθήκευσης των δεδομένων της επιτρέπει να εκτελέσει aggregations με μεγάλη ευκολία (σε κάθε έγγραφο Film έχει αποθηκευμένη την πληροφορία των directors εμφωλευμένη μέσα στο document) Ανάκτηση δεδομένων υπο συνθήκη Το τελευταίο διάγραμμα απεικονίζει τα αποτελέσματα των μετρήσεων για το ερώτημα «εμφάνιση όλων των ταινιών όπου διανομέας είναι τα Universal Studios»

84 records records records Hbase MongoDB Neo4j Εικόνα 3-7 Αποτελέσματα ανάκτησης δεδομένων Στη συγκεκριμένη περίπτωση υπερτερεί η Graph NoSQL βάση δεδομένων, Neo4J, η οποία διατρέχει γρήγορα όλους τους κόμβους με distributors (υπάρχουν και indexes πάνω σε αυτούς, οπότε εκτελείται indexed αναζήτηση), βρίσκει τον κόμβο Universal Studios και επιστρέφει όλους τους κόμβους Film που συνδέονται με αυτόν

85 4 Συμπεράσματα και Μελλοντική έρευνα Τα συμπεράσματα που προκύπτουν από την παρούσα διπλωματική εργασία συνοψίζονται στα παρακάτω σημεία. Θα πρέπει να γίνει διαμορφωθεί ένα ενιαίο πρότυπο γλώσσας επερωτημάτων στις NoSQL βάσεις διότι αυτή τη στιγμή η κάθε πλατφόρμα απαιτεί τη δική της γλώσσα. Το γεγονός αυτό δημιουργεί πολυπλοκότητα και αποτρέπει τη χρήση τους. Η HBase υπερτερεί σε διαδικασίες που απαιτούν γρήγορο και εύκολο reading/writing, χρησιμοποιώντας κυρίως τα κλειδιά. Βασική προϋπόθεση είναι να μην υπάρχουν εμφωλευμένες επερωτήσεις, aggregations, joins ή πολύπλοκες συνθήκες. Δυστυχώς σε περιπτώσεις όπου δεν έχουμε ένα ορισμένο και μοναδικό κλειδί για ένα συγκεκριμένο αποτέλεσμα, η ανάκτηση του είναι δυσκολότερη και χρονοβόρα. Η MongoDB είναι πολύ δυνατή σε aggregate ερωτήματα, αρκεί οι συσχετίσεις να είναι αποθηκευμένες εντός του εγγράφου. Σημαντικός παράγοντας επιτυχίας είναι η σωστή δομή του σχήματος δεδομένων, το οποίο θα πρέπει να βασίζεται στην πολυπλοκότητα των ερωτημάτων που θα εκτελεστούν σε αυτό. Το γεγονός αυτό δεν είναι περιοριστικό, καθώς ανά πάσα στιγμή που θα προκύψει ένα νέο ερώτημα το οποίο δεν καλύπτεται από την υπάρχουσα δομή του σχήματος, ο διαχειριστής έχει τη δυνατότητα να δημιουργήσει επιπλέον documents. Τα νέα documents θα καλύπτουν τις ανάγκες των ερωτημάτων σε απόδοση και ταχύτητα αλλά ίσως να περιέχουν duplicate πληροφορία. Ωστόσο, αυτό δεν αποτελεί πρόβλημα γιατί η MongoDB ως document-based βάση, αποθηκεύει τα δεδομένα σαν documents στο δίσκο και έτσι η δημιουργία επιπλέον εγγράφων δεν προσθέτει ιδιαίτερη επιβάρυνση σε κόστος, καθώς ο χώρος δεν είναι πλέον ακριβός. Η Neo4j ως graph βάση δεδομένων φάνηκε να πλεονεκτεί όταν υπάρχουν πολύπλοκα διασυνδεμένα δεδομένα και τα ερωτήματα που εκτελούνται βασίζονται σε σχέσεις αυτών (relationship-based queries). Με τις graph βάσεις δεδομένων η ανάκτηση των κόμβωνπαιδιών δεν απαιτεί κόπο ή χρόνο. Το κλασσικό παράδειγμα για να δοθεί έμφαση στην ευκολία των graph βάσεων στη διάσχιση του γράφου αποτελεί το ερώτημα : «φέρε μου τους φίλους των φίλων των φίλων μου»

86 Με βάση τα αποτελέσματα στα πλαίσια της έρευνας συνοψίζουμε την αξιολόγησή μας στον παρακάτω πίνακα. Ο πίνακας εμφανίζει ανά κατηγορία εφαρμογής την/τις προτεινόμενη/ες NoSQL πλατφόρμες με βάση τα κύρια χαρακτηριστικά τους. Εφαρμογές HBASE MongoDB Neo4j Δυναμικά ερωτήματα που αλλάζουν συχνά x Τεράστιος όγκος δεδομένων x Συστήματα logging x Συστήματα wiki x Analytics x Εύκολη επεκτασιμότητα x x x Πλατφόρμα μηνυμάτων x x Location based δεδομένα x Συστήματα διαχείρισης δικτύων x Συστήματα σχέσων και συστάσεων x Πίνακας 4-1 Πίνακας συμπερασμάτων Θα μπορούσαμε να θεωρήσουμε ότι το μέλλον ανήκει στις σχεσιακές βάσεις δεδομένων που θα καταφέρουν να ενσωματώσουν χαρακτηριστικά από τις NoSQL βάσεις δεδομένων. Με αυτό τον τρόπο θα συνδυαστεί η ωριμότητα των σχεσιακών με την δυνατότητα των NoSQL να διαχειρίζονται τεράστιο πλήθος μη αυστηρά δομημένων δεδομένων και την δυνατότητα για εύκολη επεκτασιμότητα. Σε μελλοντική έρευνα, η υλοποίηση του εργαλείου Virtuoso Query Data Tool που αναπτύχθηκε στα πλαίσια της διπλωματικής εργασίας θα μπορούσε να επεκταθεί σε έναν πληρέστερο editor και να συμπεριλαμβάνει επίσης: Έλεγχο συντακτικού Query Optimization Advisor Γραφική απεικόνιση επερώτησης

87 Εικόνα 4-1: Γραφική Απεικόνιση SPARQL ερωτήματος Επιπλέον, τα δοκιμαστικά τεστς με RDF δεδομένα θα μπορούσαν να αναλύσουν και να συγκρίνουν περαιτέρω τις NoSQL βάσεις δεδομένων με : Εισαγωγή σχήματος δεδομένων με μεγαλύτερη πολυπλοκότητα (Αύξηση του όγκου δεδομένων, των οντοτήτων της DBpedia και των συσχετίσεων) Εγκατάσταση συστημάτων σε πολλαπλούς servers Η αξιολόγηση αυτή θα μας επέτρεπε να κατανοήσουμε τη συμπεριφορά των NoSQL συστήματα σε κατανεμημένα και παράλληλα περιβάλλοντα. Τέλος, η διαμόρφωση και υιοθέτηση ενός ενιαίου προτύπου για την σύνταξη επερωτήσεων σε NoSQL πλατφόρμες θα αποτελούσε ένα σημαντικό βήμα