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

Transcript

1 ΟΙΚΟΝΟΜΙΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΜΕΤΑΠΤΥΧΙΑΚΟ ΔΙΠΛΩΜΑ ΕΙΔΙΚΕΥΣΗΣ (MSc) στα ΠΛΗΡΟΦΟΡΙΑΚΑ ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙKH ΕΡΓΑΣΙΑ «Μελέτη χρήσης Αρχιτεκτονικών Υπολογιστικού Νέφους επί αποθετηρίου ψηφιακών βιβλιοθηκών» Ονοματεπώνυμο: Σερενίδης Δημήτριος Αριθμός Μητρώου: ΜΜ ΑΘΗΝΑ, ΦΕΒΡΟΥΑΡΙΟΣ 2015

2

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

4 Ευχαριστίες Η εκπόνηση αυτής της διπλωματικής εργασίας δεν θα ήταν εφικτή χωρίς τη πολύτιμη βοήθεια ορισμένων ανθρώπων που θα ήθελα να ευχαριστήσω σε αυτό το σημείο. Καταρχάς θέλω να ευχαριστήσω θερμά τον καθηγητή κο Κωτίδη Ιωάννη, για την ανάθεση ενός τόσο ενδιαφέροντος θέματος και για την καθοδήγησή του. Αισθάνομαι πολύ τυχερός που μου έκανε την τιμή να τον έχω ως επιβλέποντα καθηγητή στη διπλωματική μου εργασία. Επίσης, ευχαριστώ τον καθηγητή κο Κωνσταντόπουλο Παναγιώτη για τις κατευθύνσεις του στην ανάλυση των βασικών ζητημάτων της εργασίας. Ακόμη, το διδακτορικό σπουδαστή Σπυρόπουλο Βασίλειο για την καθοριστική βοήθεια που μου προσέφερε στην εγκατάσταση του συστήματος HBase. Όπως επίσης τη Μονάδα Ψηφιακής Επιμέλειας (ΜΟΨΕ) του Ερευνητικού Κέντρου Αθηνά, και ιδίως το Γαβριλή Δημήτριο, για την παροχή των υλικοτεχνικών υποδομών, επί των οποίων διεξάχθηκαν οι μετρήσεις του ερευνητικού σκέλους της εργασίας, και για τη γενικότερη συνεργασία τους. Θέλω να ευχαριστήσω επίσης θερμά το Κοινωφελές Ίδρυμα Αλέξανδρος Σ. Ωνάσης, για την ευκαιρία που μου παρείχε, μέσω της υποτροφίας, να φοιτήσω στο Πρόγραμμα Μεταπτυχιακών Σπουδών στα Πληροφοριακά Συστήματα. Όπως και τις εργαζόμενες σε αυτό κα Ρουσάκη Κατερίνα και κα Παπαθάνου Φανή, για τη συνδρομή τους σε όλα τα διαδικαστικής φύσεως ζητήματα. Τέλος θα ήθελα να ευχαριστήσω την οικογένειά μου, και ιδίως τη σύζυγό μου για την κατανόηση και υπομονή που έδειξε, κυρίως κατά το δεύτερο έτος σπουδών και τη συγγραφή της διπλωματικής εργασίας. Γνωρίζω πως ήταν δύσκολο με την εγκυμοσύνη και την ανατροφή της νεογέννητης κόρης μας.

5 Περίληψη Αντικείμενο της παρούσας εργασίας αποτελεί η διερεύνηση της εφαρμογής Αρχιτεκτονικών Υπολογιστικού Νέφους (Cloud) επί αποθετηρίου ψηφιακών βιβλιοθηκών. Οι τεχνολογίες που αξιολογούνται είναι οι Apache Cassandra, CouchDB, HBase και MongoDB. Και οι τέσσερις έχουν ρυθμιστεί να χρησιμοποιούν ένα παρόμοιο μοντέλο περιεχομένου που χειρίζεται XML κωδικοποιημένα ψηφιακά αντικείμενα με υποστήριξη εκδόσεων. Η αξιολόγηση τους επιτελείται με βάση κριτήρια απόδοσης επί καταχώρησης περίπου 1 εκατομμυρίου αρχείων μεγάλου όγκου, σε παραλλαγές κόμβων, πελατών και υποστήριξης. Συνεκτιμώνται επίσης ζητήματα αξιοπιστίας και πολυπλοκότητας λειτουργίας. Το ψηφιακό αποθετήριο επί του οποίου πραγματοποιήθηκε η έρευνα αποκαλείται ΜΟΨΕΑΣ. Βασίζεται στο Fedora-commons το οποίο αποτελεί μια ιδιαίτερα ευέλικτη και στιβαρή υποδομή κατασκευής συστημάτων ψηφιακών αποθετηρίων. Ο ΜΟΨΕΑΣ σχεδιάστηκε με τέτοιο τρόπο ώστε να δίνει ιδιαίτερη έμφαση στην ευελιξία προσαρμογής σε διαφορετικές συνθήκες, στη διαλειτουργικότητα και στη ψηφιακή διατήρηση. Η στρατηγική ψηφιακής διατήρησης του ΜΟΨΕΑ ακολουθεί ένα σύνολο από κανόνες που στοχεύουν στη μακροπρόθεσμη αποθήκευση και πρόσβαση στα ψηφιακά αντικείμενα. Βασικές λειτουργίες που υποστηρίζει είναι η λήψη δεδομένων, η πρόσβαση, η αποθήκευση και η διαχείριση δεδομένων, η αναζήτηση και η τροποποίηση καθώς επίσης και η εκκαθάριση δεδομένων. Ο όρος NoSQL (Not Only SQL) χρησιμοποιείται για να χαρακτηρίσει μία ομάδα συστημάτων βάσεων δεδομένων που διαφέρουν σε συγκεκριμένα σημεία από τις παραδοσιακά συστήματα σχεσιακών βάσεων δεδομένων (RDBMS). Μερικές από τις πιο αξιοσημείωτες διαφορές των NoSQL βάσεων συγκριτικά με τις σχεσιακές αποτελούν: Η απουσία σχήματος, ή έστω η ύπαρξη αυτού με χαλαρή δομή Η αποφυγή ενώσεων (joins) Η ικανότητα οριζόντιας επέκτασης (horizontal scaling)

6 6 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Η εγγενής υποστήριξη αυτόματης αναπαραγωγής Το πρώτο σημείο επιτρέπει ευκολία σχεδιασμού, το δεύτερο στοχεύει σε αύξηση της απόδοσης, ενώ το τρίτο στην παροχή διαθεσιμότητας και μείωση του κόστους. Η αυτόματη αναπαραγωγή βελτιώνει τη διαθεσιμότητα, ενώ σε ορισμένες περιπτώσεις μπορεί να χρησιμοποιηθεί και για αύξηση της ικανότητας ανάγνωσης. Τα περισσότερα NoSQL συστήματα θυσιάζουν τη συνοχή υπέρ της διαθεσιμότητας και της ανοχής σε διαμερισμό. Με άλλα λόγια, τα NoSQL συστήματα κατά κανόνα συμμορφώνονται με τις ιδιότητες BASE (Basically Available, Soft state, Eventual consistency), σε αντιπαραβολή προς τις ιδιότητες ACID. Έχουν γίνει διάφορες απόπειρες κατηγοριοποίησης των NoSQL συστημάτων, με κρατούσα το διαχωρισμό σε: α) Κλειδιού-Τιμής (Key-Value), β) Ευρείας Στήλης (Wide- Column), γ) Εγγράφου (Document) και δ) Γράφου (Graph). Περισσότερο πρόσφορα για τα πειράματά μας κρίθηκαν τα συστήματα των κατηγοριών Κλειδιού-Τιμής και Εγγράφου, για κάθε μία εκ των οποίων επιλέχθηκαν δύο εκπρόσωποι. Από την πρώτη κατηγορία οι Cassandra και HBase, ενώ από τη δεύτερη οι CouchDB και MongoDB. Το πλαίσιο της αξιολόγησης των NoSQL συστημάτων περιλαμβάνει τη δημιουργία των σεναρίων που εφαρμόστηκαν για τη δοκιμή των διαφορετικών τεχνολογιών, τη ρύθμιση του cloud περιβάλλοντος και των πελατών. Η εγκατάσταση αποτελείται από ένα σύμπλεγμα κόμβων αποθήκευσης και ένα σύνολο πελατών, που έχουν επιφορτιστεί με το βάρος να εισάγουν δεδομένα σε κάθε κόμβο. Τα πειράματα πραγματοποιήθηκαν για 1, 3, 6 και 9 κόμβους. Στόχος ήταν η εισαγωγή περίπου ενός εκατομμυρίου εγγραφών, με συνολικό όγκο 4GB. Η ιδιαιτερότητα των μετρήσεων δεν έγκειται τόσο στον αριθμό των σειρών, όσο στο σχετικά μεγάλο μέγεθος των ροών δεδομένων. Για κάθε αριθμό κόμβων, καταγράφηκαν 4 παραλλαγές μετρήσεων: 1. Εισαγωγή από έναν πελάτη, χωρίς να επιτελείται έλεγχος του αριθμού έκδοσης του καταχωρούμενου στοιχείου. 2. Εισαγωγή από έναν πελάτη, με υποστήριξη εκδόσεων. Αυτό το σενάριο επιτάσσει ενημέρωση του αριθμού έκδοσης του βιβλίου στον πίνακα πληροφοριών, εάν 6

7 Περίληψη 7 διαπιστωθεί ότι υπάρχει ήδη καταχωρημένο στη βάση δεδομένων. Αντίθετα, η ροή δεδομένων εισάγεται αυτούσια κάθε φορά. 3. Εισαγωγή από τρεις πελάτες, χωρίς έλεγχο του αριθμού έκδοσης. Οι πελάτες εκτελούν τις διεργασίες τους σε διαφορετικά εικονικά μηχανήματα (Virtual Machines), μοιράζονται σε ίσα μέρη το συνολικό αριθμό εγγραφών, ενώ εκτελούν παράλληλα τις καταχωρήσεις. 4. Εισαγωγή από τρεις πελάτες, με υποστήριξη εκδόσεων. Οι πελάτες εκτελούν τις διεργασίες τους σε διαφορετικά VMs, μοιράζονται σε ίσα μέρη το συνολικό αριθμό εγγραφών, ενώ εκτελούν παράλληλα τις καταχωρήσεις. Σε κάθε σύστημα, ακολουθήθηκε η προσέγγιση της δημιουργίας ενός σχήματος με δύο πίνακες, κατά την ορολογία των σχεσιακών βάσεων δεδομένων. Ο πρώτος πίνακας, καλούμενος στο εξής πίνακας μεταδεδομένων, περιέχει τα μεταδεδομένα κάθε ροής δεδομένων, όπως αποτυπώνονται στο εκάστοτε info.xml αρχείο, στα οποία προστίθενται κάποια μεταδεδομένα για τις ανάγκες του πειράματος, όπως ημερομηνία και χρήστης εισαγωγής. Στο δεύτερο πίνακα, καλούμενο στο εξής πίνακα ροής δεδομένων, καταχωρούνται οι ροές δεδομένων (datastreams). Και στους δύο πίνακες έχει προβλεφθεί η ύπαρξη επιπλέον στήλης που περιλαμβάνει το χρόνο καταχώρησης της κάθε εγγραφής, εφόσον ήταν απαραίτητο. Τα αποτελέσματα των μετρήσεων καταδεικνύουν ότι οι τεχνολογίες MongoDB και Cassandra, με asynchronous API σύνδεση, επικρατούν των CouchDB, HBase και Cassandra, με synchronous API σύνδεση. Ιδίως η CouchDB αποδείχθηκε ότι υστερεί σημαντικά σε απόδοση στο πλαίσιο των δεδομένων του πειράματος. Ένα δεύτερο σημαντικό εύρημα έγκειται στο ότι η οργάνωση του ψηφιακού αποθετηρίου με εγγενή υποστήριξη εκδόσεων, ώστε να διατηρεί ολόκληρο τον κύκλο ζωής ενός αντικειμένου (για σκοπούς μακροπρόθεσμης ψηφιακής διαφύλαξης), απαιτεί πρόσθετο χρόνο ολοκλήρωσης που κυμαίνεται μεταξύ 46-79% σε σχέση με την παραμετροποίηση χωρίς υποστήριξη εκδόσεων. 7

8 8 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Abstract In this paper, an evaluation of cloud technologies that can be used for building curation aware repositories is presented. The technologies that are evaluated include: Apache Cassandra, CouchDB, MongoDB and HBase. All three were configured to use a similar content model that handles XML encoded digital objects with versioning support. Both single node and multi node configurations are introduced with multiple clients that are ingesting / curating approximately 1 million records. Digital curation is undoubtedly part of most digital library systems. The curation of information in a rapidly changing world is essential in order to ensure interoperability and timeliness. Curation services can be and are used to transform large amounts of information that reside in various repositories. In the case where a repository is called upon to store and process large amounts of information, monolithic, single node technologies fail to address the numerous issues that arise. Instead, scalable distributed cloud technologies hold the key to ensure both efficiency and flexibility. A distributed scalable storage can ensure high availability, protect the data it stores and allows for distributed processing using a multinode environment. Various attempts have been made to categorize NoSQL systems. The prevailing classification is: a) Key-Value, b) Wide Column, c) Document and d) Graph. More appropriate for our experiments were deemed systems of the categories Key-Value and Document stores, for each of which we selected two representatives. From the first category, Cassandra and HBase, and the second CouchDB and MongoDB. The evaluation framework involves setting up the scenarios that will be used to test the different cloud technologies, the setup of the cloud environment and the clients. The setup comprised of a cluster of storage nodes and a set of clients that were ingesting information to each node. The experiments took place for 1, 3, 6 and 9 nodes. The goal was to insert 1 million rows, which occupied 4GB of space. The particularity of the benchmark lies not in the 8

9 Abstract 9 number of inserted rows but in the relatively large size of the datastreams. For each number of nodes, 4 variations were measured: 1. Ingest by a single client without checking the version number 2. Ingest by a single client with versioning. This scenario demands that if the book already exists in the database, its version number is updated in the info table. The datastream in inserted every time. 3. Ingest by three clients, who split the insert and work in parallel, without checking the version number. The clients are located in different VMs. 4. Ingest by three clients, who split the insert and work in parallel, with versioning. The clients are located in different VMs. The experiment was setup using Debian Linux on VMs with the same characteristics across all three configurations. Each digital object is represented as a container comprised of datastreams. Each datastream can hold any kind of information (e.g. binary, xml, etc) and can be versionable. This content model was configured in all four technologies. Extra information such as a provider identification, metadata schema identification were also part of the metadata of each object and datastream respectively. In order to access effectively the cloud infrastructure, a proper client had to be setup. The client ensures that it will take advantage of the specific features of each technology. In the current evaluation setup, three clients were developed with the following characteristics: Cassandra: Both the synchronous and asynchronous API was used. The latter proved, as expected, much faster. This result is due to the fact that the synchronous API blocks other client operations until at least some result has been received from the database. In contrast, the asynchronous API does not block. It returns as soon as the query has been passed to the underlying network stack. CouchDB: The ability to perform write operations by the clients in bulk was utilized. So in each insert operation, two bulk lists were populated, one for each document type. 9

10 10 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών HBase: We employed the method "put" of Class HTable, residing in the org.apache.hadoop.hbase.client package of the native java client. This method accepts a list of data as argument, resulting in batch insertion to the database. MongoDB: The ability to perform write operations by the clients in bulk was utilized. So in each insert operation, two bulk lists were populated, one for each collection. This proved extremely efficient, considering the distribution of each collection s documents among the cluster s shards was implemented with hashed shard keys. The experimental results that were carried out involved the processing of 1 million records of digital objects (encoded in XML). The processing involved an ingest of records in a distributed storage environment of 1, 3, 6 and 9 nodes. Two major variations were tested: 1. A configuration with versionable datastreams: an ingest creates a new version of an existing datastream thus preserving the complete lifecycle of each object. 2. An ingest from single and multiple clients that were querying multiple peer nodes. In multi-client measurements, the client who finished last is used for the benchmarks which represents the overall completion time of the experiment. Consequently, the result is faster in all measurements. It has to be noted though that in most cases the overall completion amounts to more than one third of the time for the corresponding single-client measurement. This is due to the overhead for the handling of multiple clients. The evaluation results show that MongoDB and Apache Cassandra (Asynchronous client) dominated over HBase and Synchronous Apache Cassandra. Another important finding is that a setup with built-in versioning support that maintains the entire lifecycle of an object (for long-term digital preservation purposes) has an overhead that ranges from 46-79% over the non-versionable setup. 10

11 Περιεχόμενα Περίληψη... 5 Abstract Περιβάλλον Εφαρμογής ΜΟΨΕΑΣ NoSQL βάσεις δεδομένων Εισαγωγή Κλειδιού-Τιμής (Key-Value) Ευρείας Στήλης (Wide-Column) Εγγράφου (Document) Γράφου (Graph) Τεχνολογίες Υπολογιστικού Νέφους Πειράματος Cassandra Γενικά Ιστορία Βασικά Χαρακτηριστικά MongoDB Γενικά Ιστορία Βασικά Χαρακτηριστικά CouchDB Γενικά Ιστορία Βασικά Χαρακτηριστικά HBase Γενικά Ιστορία Βασικά Χαρακτηριστικά Πλαίσιο Αξιολόγησης Εισαγωγή Σενάρια Αξιολόγησης... 47

12 12 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών 4.3 Ρυθμίσεις Περιβάλλοντος Αξιολόγησης Μοντέλο περιεχομένων Ανάγνωση αρχείων ψηφιακού αποθετηρίου Ρύθμιση Βάσεων Δεδομένων Γενικά Cassandra CouchDB MongoDB HBase Ρύθμιση Πελατών Γενικά Cassandra CouchDB HBase MongoDB Αποτελέσματα Πειράματος Γενικά Cassandra CouchDB HBase MongoDB Σύγκριση Μετρήσεων Συμπεράσματα Βιβλιογραφία - Αρθρογραφία

13 1. Περιβάλλον Εφαρμογής Περιβάλλον Εφαρμογής 1.1 ΜΟΨΕΑΣ Ο ΜΟΨΕΑΣ είναι ένα σύστημα αποθετηρίου το οποίο βασίζεται στο Fedoracommons το οποίο αποτελεί μια ιδιαίτερα ευέλικτη και στιβαρή υποδομή κατασκευής συστημάτων ψηφιακών αποθετηρίων 1. Ο ΜΟΨΕΑΣ σχεδιάστηκε με τέτοιο τρόπο ώστε να δίνει ιδιαίτερη έμφαση στην ευελιξία προσαρμογής σε διαφορετικές συνθήκες, στη διαλειτουργικότητα και στη ψηφιακή διατήρηση. Είναι πλήρως προσβάσιμο μέσω του ιστού (web-based) ενώ οι βασικές τεχνολογίες που χρησιμοποιεί είναι: PHP, Java/JSP, MySQL 2. Η στρατηγική ψηφιακής διατήρησης του ΜΟΨΕΑ ακολουθεί ένα σύνολο από κανόνες που στοχεύουν στη μακροπρόθεσμη αποθήκευση και πρόσβαση στα ψηφιακά αντικείμενα. Βασικές λειτουργίες που υποστηρίζει είναι η λήψη δεδομένων, η πρόσβαση, η αποθήκευση και η διαχείριση δεδομένων, η αναζήτηση και η τροποποίηση καθώς επίσης και η εκκαθάριση δεδομένων. Το μοντέλο περιεχομένου που περιλαμβάνει ο ΜΟΨΕΑΣ είναι ιδιαίτερα ευέλικτο επιτρέποντας τη δόμηση των τεκμηρίων με οποιοδήποτε τρόπο. Έτσι, το μοντέλο της πληροφορίας που ακολουθείται είναι όσο το δυνατό πιο ανεξάρτητο από το πεδίο εφαρμογής του. Το μοντέλο αυτό έχει ως εξής: Όλες οι οντότητες του ΜΟΨΕΑ αποτελούν ψηφιακά αντικείμενα. Για την οργάνωση της πληροφορίας (των ψηφιακών τεκμηρίων) γίνεται χρήση ειδικής κατηγορίας ψηφιακών τεκμηρίων: τα containers, τα οποία μπορούν να διασυνδεθούν μεταξύ τους με χρήση σημασιολογικών συνδέσεων έτσι ώστε να μπορούν να σχηματίσουν από απλές ιεραρχίες έως σύνθετους γράφους. 1 Βλ. αναλυτικά MOPSEUS A Digital Repository System With Semantically Enhanced Preservation Services, Dimitris Gavrilis - Stavros Angelis - Christos Papatheodorou, ipres 2010 Session 4b: Preservation Services, σελ , διαθέσιμο σε 2 Βλ. αναλυτικά 13

14 14 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Κάθε ψηφιακό αντικείμενο μπορεί να περιλαμβάνει απεριόριστο αριθμό μεταδεδομένων ή/και ψηφιακών αρχείων δεδομένων. Το σύστημα ΜΟΨΕΑΣ υποστηρίζει τη χρήση πολλαπλών σχημάτων μεταδεδομένων ανά ψηφιακό αντικείμενο. Τα μεταδεδομένα μπορούν να παρασταθούν είτε ως XML ή με RDF τριπλέτες. Επιπλέον, επιτρέπονται σημασιολογικές συσχετίσεις μεταξύ αντικειμένων οι οποίες εισάγονται μέσω γραφικών διεπαφών ενώ ο ορισμός τους γίνεται απλά και εύκολα μέσω της γραφικής διεπαφής. Από την πλευρά τόσο των χρηστών όσο και των τεκμηριωτών, όλες οι ενέργειες οργανώνονται σε ροές εργασίας οι οποίες ορίζονται επίσης μέσω γραφικής διεπαφής εύκολα και απλά. Εικόνα 1: Αρχιτεκτονική του ΜΟΨΕΑ 3 3 Πηγή: (Ινστιτούτο Πληροφοριακών Συστημάτων και Προσομοίωσης / Ε.Κ. Αθηνά») 14

15 1. Περιβάλλον Εφαρμογής 15 Βασικό στοιχείο της αρχιτεκτονικής του ΜΟΨΕΑ αποτελεί η επικοινωνία των συμμετέχοντων κόμβων μέσω πρωτοκόλλων SOAP and REST. Κάθε αντικείμενο περιλαμβάνει πολλαπλές ψηφιακές παραστάσεις δεδομένων και μεταδεδομένων. To αποθετήριο υποστηρίζει τις λειτουργίες εισαγωγής και διαχείρισης και συσχέτισης αντικειμένων (object ingest, modify, purge, object relations). Ο ΜΟΨΕΑΣ ή ο βασικός κορμός του έχει εγκατασταθεί με επιτυχία στα παρακάτω έργα: 1. Ευρωπαϊκό έργο CARARE (Connecting Archaeology & Architecture in Europeana) 4 2. Ευρωπαϊκό έργο 3D-ICONS (3D Digitization of Icons of European Architectural and Archaeological Heritage) 3. Βιβλιοθήκη Παντείου Πανεπιστημίου 4. Τμήμα Ιστορίας και Αρχαιολογίας, ΕΚΠΑ

16 16 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών 2. NoSQL βάσεις δεδομένων 2.1 Εισαγωγή Ο όρος NoSQL (Not Only SQL) χρησιμοποιείται για να χαρακτηρίσει μία ομάδα συστημάτων βάσεων δεδομένων που διαφέρουν σε συγκεκριμένα σημεία από τις παραδοσιακά συστήματα σχεσιακών βάσεων δεδομένων (RDBMS) 5. Ο όρος χρησιμοποιήθηκε πρώτη φορά, με τη σημερινή του έννοια 6, από τον Eric Evans το 2009, στο πλαίσιο μίας εκδήλωσης σχετικά με ανοικτού πηγαίου κώδικα κατανεμημένες βάσεις δεδομένων 7. Με τη συγκεκριμένη ονομασία προσπάθησε να χαρακτηρίσει έναν αυξανόμενο αριθμό μη-σχεσιακών και κατανεμημένων συστημάτων βάσεων δεδομένων 8 που είχαν παρουσιαστεί εκείνη την εποχή. Μερικές από τις πιο αξιοσημείωτες διαφορές των NoSQL βάσεων συγκριτικά με τις σχεσιακές αποτελούν: Η απουσία σχήματος, ή έστω η ύπαρξη αυτού με χαλαρή δομή Η αποφυγή ενώσεων (joins) Η ικανότητα οριζόντιας επέκτασης (horizontal scaling) 9 Η εγγενής υποστήριξη αυτόματης αναπαραγωγής Το πρώτο σημείο επιτρέπει ευκολία σχεδιασμού, το δεύτερο στοχεύει σε αύξηση της απόδοσης, ενώ το τρίτο στην παροχή διαθεσιμότητας και μείωση του κόστους. Η αυτόματη αναπαραγωγή βελτιώνει τη διαθεσιμότητα, ενώ σε ορισμένες περιπτώσεις μπορεί να χρησιμοποιηθεί και για αύξηση της ικανότητας ανάγνωσης. Η ανάπτυξη των NoSQL συστημάτων προήλθε αρχικά για την κάλυψη των αναγκών Web 2.0 εφαρμογών, 5 Με κύριους εκπροσώπους τα συστήματα Oracle Databases, MySQL και Microsoft SQL Server 6 Ο όρος NoSQL είχε χρησιμοποιηθεί και στο παρελθόν, και συγκεκριμένα το 1998 από τον Carlo Strozzi, για την ονομασία μίας βάσης δεδομένων που είχε αναπτύξει. Επρόκειτο όμως για σχεσιακό σύστημα, το οποίο διαφοροποιείτο από τα παραδοσιακά μόνο ως προς την απουσία υποστήριξης του προτύπου SQL. Αντ αυτού είχε υλοποιηθεί εναλλακτικός τρόπος διασύνδεσης με τη βάση. 7 Βλ. ανάρτηση σε σχετικό blog, διαθέσιμη σε 8 Τα περισσότερα από τα εν λόγω συστήματα στερούνται κάποιες από τις προηγμένες λειτουργικότητες των RDBMS, όπως τύπους στηλών, δευτερεύοντα ευρετήρια, triggers, και σύνθετες γλώσσες επερωτήσεων. Για το λόγο αυτό συναντώνται συχνά στη βιβλιογραφία ως data stores αντί για data bases. 9 Συναντάται στη βιβλιογραφία και με τον όρο sharding 16

17 2. NoSQL βάσεις δεδομένων 17 όπως το Facebook. Σε αυτά τα περιβάλλοντα, η διαχείριση της συλλογής τεράστιου όγκου μη δομημένης πληροφορίας, με υψηλά ποσοστά εγγραφής και πλειονότητα περιεχομένου, όπως κείμενο, εικόνες και βίντεο, αποδείχθηκε ιδιαίτερα δυσχερής με τα υπάρχοντα συστήματα σχεσιακών βάσεων δεδομένων. Κατά τα λοιπά, οι μεταξύ τους ομοιότητες είναι ευκολότερο να διερευνηθούν είτε βάσει των ιδιοτήτων ACID είτε στο πλαίσιο του θεωρήματος CAP. Οι ιδιότητες ACID αναλύονται ως εξής 10 : 1. Ατομικότητα (Atomicity): σε κάθε συναλλαγή, η αποτυχία ενός μέρους αυτής συνεπάγεται την αποτυχία της συναλλαγής στο σύνολό της, ενώ η κατάσταση της βάσης δεδομένων απαιτείται να παραμένει αμετάβλητη 2. Συνέπεια (Consistency): κάθε συναλλαγή οδηγεί τη βάση δεδομένων από μια συνεπή κατάσταση σε άλλη 3. Απομόνωση (Isolation): η ταυτόχρονη εκτέλεση συναλλαγών έχει ως αποτέλεσμα το σύστημα να βρεθεί στην ίδια κατάσταση που θα βρισκόταν και σε περίπτωση που οι συναλλαγές εκτελούνταν σειριακά 4. Μονιμότητα (Durability): μόλις μια συναλλαγή δεσμευτεί, το αποτέλεσμα παραμένει, ακόμη και σε περίπτωση διακοπής ρεύματος ή σφάλματος Στην πλειονότητά τους, τα NoSQL συστήματα χαρακτηρίζονται από χαλαρή συνέπεια 11 και οι συναλλαγές σε αυτά περιορίζονται μόνο σε στοιχεία δεδομένων, σε αντίθεση με την κρατούσα πρακτική στις σχεσιακές βάσεις δεδομένων. Σύμφωνα με το θεώρημα CAP 12, είναι αδύνατο για ένα κατανεμημένο υπολογιστικό σύστημα να εξασφαλίσει ταυτόχρονα και τα τρία ακόλουθα χαρακτηριστικά: 10 Βλ. αναλυτικά Distributed Transaction Processing: Concepts and Techniques, Gray - Reuter, 1993, ISBN Συνήθως συνέπεια σε δεύτερο χρόνο, δηλαδή με την ολοκλήρωση όλων των αναπαραγωγών μεταξύ των κόμβων. 12 Γνωστό και ως θεώρημα του Brewer. Βλ. αναλυτικά μελέτη Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services, Gilbert - Lynch, ACM SIGACT News, Τεύχος 33 2, 2002, σελ. 51 επ., διαθέσιμη σε passim. 17

18 18 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών 1. Συνέπεια (Consistency): όλοι οι κόμβοι βλέπουν τα ίδια δεδομένα σε μία δεδομένη χρονική στιγμή 2. Διαθεσιμότητα (Availability): κάθε αίτημα λαμβάνει απάντηση αν ήταν επιτυχές ή όχι 3. Ανοχή σε διαμερισμό (Partition tolerance): το σύστημα συνεχίζει να λειτουργεί παρά την απώλεια μηνυμάτων ή την αποτυχία τμήματος αυτού Τα περισσότερα NoSQL συστήματα θυσιάζουν τη συνοχή υπέρ της διαθεσιμότητας και της ανοχής σε διαμερισμό 13. Με άλλα λόγια, τα NoSQL συστήματα κατά κανόνα συμμορφώνονται με τις ιδιότητες BASE (Basically Available, Soft state, Eventual consistency), σε αντιπαραβολή προς τις ιδιότητες ACID. Ένα σύστημα BASE πληροί τα ακόλουθα χαρακτηριστικά: 1. Γενικά διαθέσιμο (Basically available): το σύστημα εγγυάται διαθεσιμότητα, με την έννοια ότι θα υπάρχει πάντοτε απάντηση στα αιτήματα, χωρίς να αποκλείεται ωστόσο αυτή να είναι λάθος ή ελλιπής 2. Χαλαρή κατάσταση (Soft state): η κατάσταση του συστήματος ενδέχεται να αλλάξει με την πάροδο του χρόνου, ακόμη και χωρίς είσοδο νέων δεδομένων 3. Σταδιακή συνέπεια (Eventual consistency): το σύστημα τελικά θα περιέλθει κάποια στιγμή σε κατάσταση συνέπεια όταν σταματήσει να λαμβάνει νέα δεδομένα. Σε κάθε περίπτωση, θα συνεχίσει να λαμβάνει νέα δεδομένα χωρίς να προβαίνει σε έλεγχο συνέπειας στο πλαίσιο κάθε συναλλαγής Πρβλ. κριτική αυτής της προσέγγισης σε άρθρο Errors in Database Systems, Eventual Consistency, and the CAP Theorem, Michael Stonebraker, 05/04/2010, διαθέσιμο σε όπου παρατίθενται κατηγορίες σφαλμάτων επί των οποίων το θεώρημα CAP δεν εφαρμόζεται, ενώ υποστηρίζεται ότι στις λοιπές περιπτώσεις η σπανιότητα εμφάνισης αυτών καθιστά υπέρμετρη τη θυσία της συνέπειας υπέρ της διαθεσιμότητας και της ανοχής σε διαμερισμό. 14 Βλ. αναλυτικά άρθρο Eventually Consistent Revisited, Werner Vogels, 22/12/2008, διαθέσιμο σε 18

19 2. NoSQL βάσεις δεδομένων 19 Γράφημα 1: Προσέγγιση των διάφορων συστημάτων βάσεων δεδομένων σε σχέση με το θεώρημα CAP 15 Με βάση τα ανωτέρω, στόχος των NoSQL συστημάτων δεν είναι αντικαταστήσουν πλήρως τις σχεσιακές βάσεις δεδομένων. Ωστόσο, ενδέχεται να προκριθούν σε κάποιες περιπτώσεις όταν αποβαίνουν κρίσιμοι ένας οι περισσότεροι από τις ακόλουθους παραμέτρους: Όγκος δεδομένων: Αν απαιτείται η διαχείριση πολύ μεγάλων συνόλων δεδομένων, τα NoSQL συστήματα πλεονεκτούν ως προς την ευκολία και την εγγενή υποστήριξη επεκτασιμότητας 15 Πηγή: Cassandra: The Definitive Guide, Eben Hewitt, 2010, ISBN

20 20 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Ταχύτητα: Οι NoSQL βάσεις δεδομένων είναι συνήθως αρκετά έως πολύ πιο γρήγορες στις λειτουργίες εγγραφής. Αντίθετα, η ταχύτητα στις λειτουργίες ανάγνωσης ποικίλλει μεταξύ των NoSQL συστημάτων, ενώ εξαρτάται σε μεγάλο βαθμό και από τον τύπο των επερωτήσεων Δημιουργία σχήματος χωρίς σχεδιασμό: Στο σημείο αυτό τα NoSQL συστήματα προσφέρουν ένα μεγάλο βαθμό ευελιξίας σε σύγκριση με τα σχεσιακά ΣΔΒΔ, που απαιτούν να προδιαγραφεί με απόλυτη αυστηρότητα το σχήμα της βάσης εξαρχής Αυτοματοποιημένη (ή εύκολη) αναπαραγωγή / επεκτασιμότητα: Η λειτουργία σε πολλούς κόμβους και η αυτόματη αναπαραγωγή δεδομένων μεταξύ αυτών συνιστά ένα από τα βασικά σχεδιαστικά χαρακτηριστικά των NoSQL βάσεων δεδομένων. Κατά συνέπεια, αποβαίνει ιδιαίτερα εύκολη η οριζόντια κλιμάκωση, ενώ αυξάνεται και η διαθεσιμότητα 20

21 2. NoSQL βάσεις δεδομένων 21 21

22 22 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Πίνακας 1: Σύγκριση NoSQL συστημάτων βάσεων δεδομένων με κριτήρια τα σχεδιασμό, ακεραιότητα, ευρετηρίαση και κατανομή 16 Αξίζει να σημειωθεί ωστόσο ότι το NoSQL είναι στην πραγματικότητα ένας όρος ομπρέλα, που καλείται να περιγράψει λογισμικά ετερόκλιτα, με στόχο συχνά την κάλυψη διαφορετικών αναγκών και συνακόλουθα παρατηρείται μεγάλη ανομοιογένεια μεταξύ τους 17. Έχουν γίνει διάφορες απόπειρες κατηγοριοποίησης 18, με κρατούσα το διαχωρισμό σε 19 : 2.2 Κλειδιού-Τιμής (Key-Value) Στην πλειονότητά τους, αυτά τα συστήματα βάσεων δεδομένων αποθηκεύουν κάθε αντικείμενο ως συνδυασμό αλφαριθμητικού αναγνωριστικού (κλειδί) και τιμής 20 σε αυτόνομους hash πίνακες 21. Οι τιμές μπορεί να είναι απλά αλφαριθμητικά ή ακόμη και σύνθετες λίστες και σύνολα, ανεξαρτήτως format 22. Σημαντικός παράγοντας στη βελτίωση της απόδοσης αποτελεί ο μηχανισμός κρυφής μνήμης που συνοδεύει τις αντιστοιχίσεις. Οι αναζητήσεις δεδομένων μπορούν συνήθως να πραγματοποιηθούν μόνο με βάση τα κλειδιά, και όχι τις τιμές, ενώ περιορίζονται σε ακριβή αντιστοιχία. Παραδείγματα της κατηγορίας αυτής είναι τα συστήματα Dynamo, FoundationDB, MemcacheDB, Redis και Riak. Συνηθισμένες περιπτώσεις χρήσης αυτού του τύπου συστημάτων βάσεων δεδομένων αποτελούν: 16 Πηγή: άρθρο NoSQL Database: New Era of Databases for Big data Analytics - Classification, Characteristics and Comparison, Moniruzzaman Hossain, International Journal of Database Theory and Application, Vol. 6, No , διαθέσιμο σε 17 Βλ. αναλυτική παράθεση τρέχοντων διαθέσιμων NoSQL λογισμικών σε 18 Πρβλ. άρθρο Will NoSQL Databases Live Up to Their Promise?, Neal Leavitt, Technology News, 2010, διαθέσιμο σε όπου προκρίνεται ο διαχωρισμός σε τρεις κατηγορίες: Key-value stores, column-oriented databases και document-based stores. 19 Βλ. αναλυτικά άρθρο NoSQL Database: New Era of Databases for Big data Analytics - Classification, Characteristics and Comparison, ο.π., σελ. 4 επ. 20 Η ορολογία key-value συναντάται στη βιβλιογραφία και ως associative array, map, symbol table, ή dictionary. 21 Όπου στην ουσία υπάρχει ένα μοναδικό κλειδί και ένας δείκτης προς ένα συγκεκριμένο αποθηκευμένο αντικείμενο 22 Π.χ. String, JSON, BLOB 22

23 2. NoSQL βάσεις δεδομένων 23 Προσωρινή αποθήκευση: Τα key/value συστήματα είναι ιδιαίτερα αποδοτικά σε περιπτώσεις γρήγορης αποθήκευση δεδομένων με ενδεχόμενη μελλοντική αξία Διαχείριση συλλογών: Ένα μέρος συστημάτων αυτής της κατηγορίας (π.χ. το Redis) παρέχουν υποστήριξη για λίστες, σύνολα, ουρές και λοιπούς τύπους συλλογών 2.3 Ευρείας Στήλης (Wide-Column) Τα Wide-Column 23 συστήματα βάσεων δεδομένων ακολουθούν την προσέγγιση της αποθήκευσης δεδομένων ως τμήματα στηλών (columns) δεδομένων, αντί για σειρές (rows). Οι στήλες ομαδοποιούνται σε οικογένειες στηλών (Column Families). Οι οικογένειες στηλών ενδέχεται να περιέχουν ένα σχεδόν απεριόριστο αριθμό στηλών που μπορούν να δημιουργηθούν είτε κατά το χρόνο εκτέλεσης είτε κατά τον ορισμό του σχήματος. Οι ενέργειες ανάγνωσης και εγγραφής επιτελούνται με τη χρήση στηλών αντί σειρών. Στην πράξη, οι βάσεις δεδομένων της συγκεκριμένης κατηγορίας λειτουργούν με τη δημιουργία συλλογών ενός ή περισσότερων ζευγαριών κλειδιού / τιμής που αντιστοιχούν σε μία εγγραφή. Χρησιμοποιούνται συνήθως όταν η αποθήκευση απλών ζευγαριών κλειδιού / τιμής δεν αρκεί, και απαιτείται η αποθήκευση ενός μεγάλου αριθμού εγγραφών με όγκο πληροφορίας, καθώς προσφέρουν πολύ υψηλή απόδοση και εξαιρετικά επεκτάσιμη αρχιτεκτονική. Παραδείγματα της κατηγορίας αυτής είναι τα συστήματα Accumulo, Cassandra, Druid και HBase. Συνηθισμένες περιπτώσεις χρήσης αυτού του τύπου συστημάτων βάσεων δεδομένων αποτελούν: Αποθήκευση μη δομημένης πληροφορίας: Αν είναι αναγκαία η μόνιμη αποθήκευση μίας μεγάλη συλλογής ιδιοτήτων και τιμών, οι column βάσεις δεδομένων αποδεικνύονται ιδιαίτερα αποδοτικές 23 Στη βιβλιογραφία συναντώνται και ως Column 23

24 24 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Επεκτασιμότητα: Τα εν λόγω συστήματα καθίστανται εξαιρετικά χρήσιμα στη διαχείριση μεγάλου όγκου δεδομένων, κυρίως λόγω των δυνατοτήτων τους όσον αφορά στην οριζόντια επεκτασιμότητα 2.4 Εγγράφου (Document) Πρόκειται για συστήματα που είναι σχεδιασμένα για τη διαχείριση και αποθήκευση εγγράφων. Τα έγγραφα αποθηκεύονται κωδικοποιημένα σε μια τυποποιημένη μορφή ανταλλαγής δεδομένων, όπως XML (EXtensible Markup Language), JSON (JavaScript Object Notation) ή BSON (Binary JSON). Σε αντίθεση με τα key-value συστήματα, η στήλη της τιμής κάθε πλειάδας περιέχει δεδομένα με κάποια δομή, ήτοι συγκεκριμένα ζεύγη ονόματος / τιμής. Κάθε στήλη ενδέχεται να περιέχει εκατοντάδες τέτοιες ιδιότητες, ενώ ο αριθμός και το είδος των καταχωρούμενων χαρακτηριστικών καταγράφονται συχνά ποικίλλει από πλειάδα σε πλειάδα. Στις document βάσεις δεδομένων επιτρέπεται η διενέργεια αναζήτησης βάσει τόσο των κλειδιών όσο και των τιμών των εγγραφών, σε αντίθεση με τις Key-Value βάσεις δεδομένων. Βασικό μειονέκτημα αυτής της κατηγορίας είναι ότι κάθε έγγραφο αποτελεί μία ενιαία οντότητα, δηλαδή η ανάκτηση μιας τιμής μίας εγγραφής επιστρέφει πάντα όλες τις ιδιότητες αυτού, ενώ το ίδιο ισχύει και για τις ενημερώσεις, γεγονός που επηρεάζει την απόδοση. Τούτο είναι ιδιαίτερα έκδηλο στις περιπτώσεις όπου τα ερωτήματα αποσκοπούν στην ανάκτηση συγκεκριμένων ιδιοτήτων μίας εγγραφής ή οι ενημερώσεις αφορούν ομοίως σε μικρό τμήμα του εγγράφου. Παραδείγματα της συγκεκριμένης κατηγορίας είναι τα συστήματα Clusterpoint, CouchDB, MarkLogic και MongoDB. Συνηθισμένες περιπτώσεις χρήσης αυτού του τύπου συστημάτων βάσεων δεδομένων αποτελούν: Διαχείριση ένθετης πληροφορίας: Οι document βάσεις δεδομένων καθιστούν ευχερή την εισαγωγή και επεξεργασία ένθετων, με αρκετά επίπεδα βάθος, και σύνθετων δομών δεδομένων Διασύνδεση με JavaScript περιβάλλοντα: Μία από τις πιο σημαντικές λειτουργίες των συστημάτων αυτών αποτελεί η αμεσότητα επικοινωνίας με 24

25 2. NoSQL βάσεις δεδομένων 25 δικτυακές εφαρμογές, στις οποίες οι τεχνολογίες JavaScript και JSON κατέχουν κεντρικό ρόλο Δεδομένα σε json format αποτυπώνονται με την ακόλουθη μορφή 24 : { "glossary": { "title": "example glossary", "GlossDiv": { "title": "S", "GlossList": { "GlossEntry": { "ID": "SGML", "SortAs": "SGML", "GlossTerm": "Standard Generalized Markup Language", "Acronym": "SGML", "Abbrev": "ISO 8879:1986", "GlossDef": { DocBook.", "para": "A meta-markup language, used to create markup languages such as "GlossSeeAlso": ["GML", "XML"] }, "GlossSee": "markup" } } } } } 24 Πηγή: 25

26 26 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Τα ίδια δεδομένα, εκφραζόμενα σε XML, θα είχαν την ακόλουθη μορφή: <!DOCTYPE glossary PUBLIC "-//OASIS//DTD DocBook V3.1//EN"> <glossary><title>example glossary</title> <GlossDiv><title>S</title> <GlossList> <GlossEntry ID="SGML" SortAs="SGML"> <GlossTerm>Standard Generalized Markup Language</GlossTerm> <Acronym>SGML</Acronym> <Abbrev>ISO 8879:1986</Abbrev> <GlossDef> <para>a meta-markup language, used to create markup languages such as DocBook.</para> <GlossSeeAlso OtherTerm="GML"> <GlossSeeAlso OtherTerm="XML"> </GlossDef> <GlossSee OtherTerm="markup"> </GlossEntry> </GlossList> </GlossDiv> </glossary> 2.5 Γράφου (Graph) Τα Graph συστήματα βάσεων δεδομένων αντικαθιστούν τους σχεσιακούς πίνακες των RDBMS με δομημένους σχεσιακούς γράφους, διασυνδεδεμένους με ζεύγη κλειδιώντιμών. Οι βασικές οντότητες της προσέγγισης αυτής είναι κόμβοι, άκρα και ιδιότητες. Προσομοιάζουν τις αντικειμενοστραφείς βάσεις δεδομένων στο ότι οι γράφοι απεικονίζονται ως ένα αντικειμενοστραφές δίκτυο κόμβων, στις σχέσεις των κόμβων και στην έκφραση των ιδιοτήτων ως ζεύγη κλειδιών-τιμών. Ορισμένες πράξεις, όπως 26

27 2. NoSQL βάσεις δεδομένων 27 ανεύρεση συναφών κόμβων ή αναζήτηση βημάτων μία διαδικασίας 25, είναι πολύ ευκολότερο να εκτελεσθούν στο πλαίσιο αυτού του είδους μοντελοποίησης, χάρη στην εγγενή υποστήριξη σύνδεσης και την ομαδοποίηση συσχετισμένων τμημάτων πληροφορίας. Παραδείγματα της συγκεκριμένης κατηγορίας είναι τα συστήματα Allegro, Neo4J, InfiniteGraph, OrientDB και Virtuoso. Συνηθισμένες περιπτώσεις χρήσης αυτού του τύπου συστημάτων βάσεων δεδομένων αποτελούν: Χειρισμός πολύπλοκων συσχετισμένων πληροφοριών: Οι graph βάσεις δεδομένων καθιστούν εξαιρετικά αποτελεσματική και εύκολη στη χρήση την ενασχόληση με πολύπλοκες αλλά συσχετισμένες πληροφορίες, όπως είναι οι συνδέσεις μεταξύ δύο βασικών οντοτήτων και διαφορών βαθμών άλλων φορέων έμμεσα σχετιζόμενων με αυτές Μοντελοποίηση και διαχείριση ταξινομήσεων: Το εν λόγω είδος συστημάτων πλεονεκτεί σε κάθε περίπτωση κατά την οποία εμπλέκονται σχέσεις μεταξύ οντοτήτων. Η μοντελοποίηση των δεδομένων επιτυγχάνεται αποτυπώνοντας οντότητες και τις μεταξύ τους συσχετίσεις 26, προσέγγιση που αποδεικνύεται πολύ πιο φυσική σε σύγκριση με τις σχεσιακές βάσεις δεδομένων, όπου η κανονικοποίηση ορισμένες φορές αποβαίνει δυσνόητη. 25 Βλ. αναλυτικά άρθρο How Graph Databases Relate To Other NoSQL Data Models, διαθέσιμο σε 26 Πρβλ. γράφημα 2 27

28 28 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Γράφημα 2: Σχέσεις σε Graph Database Πηγή: 28

29 3. Τεχνολογίες Υπολογιστικού Νέφους Πειράματος Τεχνολογίες Υπολογιστικού Νέφους Πειράματος Μεταξύ των κατηγοριών NoSQL συστημάτων, που αναλύθηκαν ανωτέρω, περισσότερα πρόσφορα για τη μελέτη μας κρίθηκαν τα συστήματα των κατηγοριών Κλειδιού-Τιμής και Εγγράφου, με βασικό κριτήριο το ζητούμενο της απόδοσης με βάση τα δεδομένα του πειράματος. Για κάθε μία εκ των οποίων επιλέχθηκαν δύο εκπρόσωποι. Από την πρώτη κατηγορία οι Cassandra και HBase, ενώ από τη δεύτερη οι CouchDB και MongoDB. Ακολουθεί αναλυτική παρουσίαση των τεσσάρων αυτών συστημάτων, με ιδιαίτερη έμφαση στα πλεονεκτήματα του καθενός. 3.1 Cassandra Γενικά Η Cassandra είναι ένα κατανεμημένο σύστημα διαχείρισης βάσεων δεδομένων, σχεδιασμένο για το χειρισμό μεγάλου όγκου δεδομένων μεταξύ πολλαπλών εξυπηρετητών 28. Έχει συγγραφεί σε γλώσσα προγραμματισμού Java. Βασικοί στόχοι του συστήματος είναι η παροχή υψηλής διαθεσιμότητας και απόδοσης 29. Η Cassandra υποστηρίζει την ασύγχρονη και ομότιμη (masterless) αναπαραγωγή δεδομένων μεταξύ συστάδων (clusters) που εκτείνονται σε πολλαπλά κέντρα. Κατ αποτέλεσμα, αποτρέπει την ύπαρξη ενιαίου σημείου αποτυχίας και επιτυγχάνει χαμηλή καθυστέρηση (latency) για όλους τους πελάτες. Παρέχονται επίσης δυνατότητες παραμετροποίησης της ακρίβειας (consistency) της βάσης. Το μοντέλο δεδομένων της Cassandra βασίζεται στην αποθήκευση πλειάδων σε διαμερίσματα (partitioning). Οι πλειάδες είναι οργανωμένες σε πίνακες. Η πρώτη συνιστώσα του πρωτεύοντος κλειδιού ενός πίνακα είναι το κλειδί κατανομής. Μέσα σε κάθε διαμέρισμα, οι πλειάδες ομαδοποιούνται βάσει των υπόλοιπων στηλών του κλειδιού. 28 Το λογισμικό διατίθεται προς μεταφόρτωση σε 29 Το 2012, ερευνητές του Πανεπιστημίου του Τορόντο, μελετώντας συστήματα NoSQL, κατέληξαν στο συμπέρασμα ότι "Όσον αφορά στην επεκτασιμότητα, υπάρχει σαφής νικητής σε όλα τα πειράματά μας. Η Cassandra επιτυγχάνει την υψηλότερη απόδοση για το μέγιστο αριθμό των κόμβων σε όλα τα πειράματα τούτο έρχεται με κόστος υψηλές καθυστερήσεις σε εγγραφή και ανάγνωση". Βλ. αναλυτικά μελέτη Solving Big Data Challenges for Enterprise Application Performance Management, Rabl - Sadoghi - Jacobsen - Gomez-Villamor - Muntes-Mulero - Mankovskii, Αύγουστος 2012, διαθέσιμο σε 29

30 30 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Επιτρέπεται ο ευρετηρίαση των υπόλοιπων στηλών χωριστά από το πρωτεύον κλειδί. Οι πίνακες είναι δυνατό να δημιουργούνται, διαγράφονται, και να τροποποιούνται κατά το χρόνο εκτέλεσης, χωρίς να εμποδίζονται ενημερώσεις και επερωτήσεις προς τη βάση. Συνήθως ταξινομείται μεταξύ των wide-column συστημάτων. Στην ουσία πρόκειται όμως για ένα υβρίδιο μεταξύ συστήματος key-value και wide-column. Μια οικογένεια στήλης (Column Family) 30 μοιάζει με έναν πίνακα ενός RDBMS. Περιέχει γραμμές και στήλες, ενώ κάθε γραμμή ταυτοποιείται μοναδικά με βάση κάποιο κλειδί. Κάθε γραμμή έχει πολλαπλές στήλες, καθεμία από τις οποίες έχει όνομα, τιμή, και χρονική σήμανση (timestamp). Σε αντίθεση όμως με έναν πίνακα σε ένα RDBMS, διαφορετικές σειρές στην ίδια οικογένεια στήλης δεν χρειάζεται να έχουν τις ίδιες στήλες, ενώ μία στήλη μπορεί να προστεθεί σε μία ή περισσότερες γραμμές οποιαδήποτε στιγμή. Επιπλέον, οι εφαρμογές μπορούν να καθορίσουν τη σειρά ταξινόμησης των στηλών σε μία υπερ-στήλη (Super Column) ή σε μία οικογένεια απλών στηλών (Simple Column Family). Η Cassandra δεν υποστηρίζει ενώσεις (joins) ή υποερωτήματα. Αντίθετα, ο τρόπος λειτουργίας αυτής ενθαρρύνει την αποκανονικοποίηση. Η πολλαπλή αποθήκευση της ίδιας πληροφορίας ανάλογα με την προβλεπόμενη χρήση αυτής είναι αναμενόμενη στην Cassandra και υποστηρίζεται από διάφορα στοιχεία αυτής, όπως οι συλλογές Ιστορία Η Cassandra αναπτύχθηκε στο Facebook, για να χρησιμοποιηθεί στην αναζήτηση εισερχόμενης αλληλογραφίας, από τους Avinash Lakshman και Prashant Malik 31. Δόθηκε ως λογισμικό ανοικτού πηγαίου κώδικα στην Google Code τον Ιούλιο του 2008, ενώ το Μάρτιο του 2009 εντάχθηκε στα έργα του Apache Software Foundation 32, οπότε και 30 Που ονομάζεται πίνακας (table) από την έκδοση 3 της CQL (Cassandra Query Language) 31 Βλ. παρουσίαση των βασικών σημείων του συστήματος από έναν εκ των δημιουργών της σε άρθρο Cassandra A structured storage system on a P2P Network, Avinash Lakshman, 25/08/2008, διαθέσιμο σε και αναλυτική παρουσίαση σε μελέτη Cassandra - A Decentralized Structured Storage System, Avinash Lakshman - Prashant Malik, passim, διαθέσιμη σε

31 3. Τεχνολογίες Υπολογιστικού Νέφους Πειράματος 31 μετονομάστηκε σε Apache Cassandra. Έκτοτε, η Cassandra έχει χρησιμοποιηθεί ευρέως από διάφορους μεγάλους οργανισμούς, συμπεριλαμβανομένων των Netflix, ebay, Twitter και Reddit 33. Εμπορική υποστήριξη του λογισμικού παρέχεται από την εταιρεία Datastax 34. Στα πειράματά μας χρησιμοποιήθηκε η έκδοση του συστήματος, η σταθερή έκδοση της οποίας δημοσιεύθηκε την 30 Ιουνίου Βασικά Χαρακτηριστικά Αποκεντρωμένη Κάθε κόμβος μίας ομάδας έχει τον ίδιο ρόλο και ως εκ τούτου δεν υφίσταται ενιαίο σημείο αποτυχίας. Τα δεδομένα είναι κατανεμημένα στη συστάδα, κατά τρόπο ώστε κάθε κόμβος να περιέχει διαφορετικά δεδομένα, χωρίς ωστόσο να υφίσταται προϊστάμενος, καθώς οποιοσδήποτε κόμβος μπορεί να εξυπηρετήσει κάποιο αίτημα. Υποστηρίζει την αναπαραγωγή, ακόμη και μεταξύ πολλαπλών κέντρων Παρέχεται δυνατότητα παραμετροποίησης των στρατηγικών αναπαραγωγής. Η Cassandra έχει σχεδιαστεί ως ένα κατανεμημένο σύστημα, με μεγάλο αριθμό κόμβων, διάσπαρτων σε πολλαπλά κέντρα δεδομένων. Τα βασικά χαρακτηριστικά της κατανεμημένης αρχιτεκτονικής του συστήματος είναι ειδικά προσαρμοσμένα για λειτουργία σε πολλαπλά κέντρα δεδομένων, πλεονασμό και αποκατάσταση μετά από καταστροφή (disaster recovery). Επεκτασιμότητα Το διαθέσιμο εύρος τόσο ανάγνωσης όσο και εγγραφής αυξάνονται γραμμικά όσο προστίθενται νέα μηχανήματα, χωρίς διακοπές ή καθυστερήσεις στις εφαρμογές. Η Cassandra χαρακτηρίζεται από ελαστική οριζόντια επεκτασιμότητα, καθώς μπορούν να προσθαφαιρούνται εξυπηρετητές, χωρίς την ανάγκη επανεκκίνησης της υπηρεσίας ή τροποποίησης των ρυθμίσεων στους συνδεδεμένους clients. 33 Βλ. αναλυτικά Practical Cassandra: A Developer's Approach, Russell Bradberry - Eric Lubow, 2013, ISBN , σελ

32 32 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Υψηλή διαθεσιμότητα και Ανοχή σε σφάλματα Τα δεδομένα αναπαράγονται αυτόματα σε πολλαπλούς κόμβους για την επίτευξη ανοχής σε βλάβες. Οι προβληματικοί κόμβοι μπορούν να αντικατασταθούν χωρίς διακοπή της λειτουργίας του συστήματος. Παραμετροποιήσιμη συνέπεια Οι ενέργειες εγγραφής και ανάγνωσης παρέχονται με ρυθμιζόμενο το επίπεδο της συνέπειας, με τιμές που εκτείνονται από "οι εγγραφές δεν αποτυγχάνουν ποτέ" έως "κλείδωμα ώστε όλα τα αντίγραφα να είναι αναγνώσιμα» 35. Υποστήριξη Map/Reduce Η Cassandra υποστηρίζει διασύνδεση με το Hadoop, με υποστήριξη MapReduce. Το μοντέλο Map / Reduce εισήχθη από την Google, και η λειτουργία του βασίζεται σε δύο βήματα. Στο πρώτο (Map), η είσοδος της συνάρτησης λαμβάνεται από τον κύριο κόμβο και διασπάται σε μικρότερα τμήματα. Τα τελευταία στη συνέχεια διανέμονται σε κόμβους, που επιλύουν το πρόβλημα και επιστρέφουν τα αποτελέσματα στον κύριο κόμβο. Στο δεύτερο βήμα (Reduce), ο κύριος κόμβος παίρνει τα μερικά αποτελέσματα και τα συνδυάζει για να καταλήξει στο τελικό 36. Υπάρχει επίσης υποστήριξη για τα Apache Pig και Apache Hive. Γλώσσα επερωτήσεων Η Cassandra εισήγαγε τη CQL (Cassandra Query Language), η οποία βρίσκεται πολύ κοντά στο πρότυπο SQL, ως μία εναλλακτική λύση στην παραδοσιακή διασύνδεση RPC. 35 Βλ. αναλυτικά Cassandra: The Definitive Guide, ο.π., σελ. 17 επ. 36 Βλ. αναλυτικά MapReduce: Simplified Data Processing on Large Clusters, Jeffrey Dean - Sanjay Ghemawat, OSDI'04: Sixth Symposium on Operating System Design and Implementation, Δεκέμβριος 2004, διαθέσιμο σε passim 32

33 3. Τεχνολογίες Υπολογιστικού Νέφους Πειράματος MongoDB Γενικά Η MongoDB 37 είναι μία document βάση δεδομένων, η οποία βασίζει την αποθήκευση των τιμών σε format BSON (Binary JSON) 38. Έχει συγγραφεί σε γλώσσα προγραμματισμού C++. Το ευέλικτο μοντέλο δεδομένων του εν λόγω συστήματος καθιστά εύκολο τον αρχικό σχεδιασμό και επεξεργασία του σχήματος 39, χωρίς να θυσιάζονται λειτουργικότητες πλούσιων επερωτήσεων και ευρετηρίασης. Η MongoDB έχει εγγενή υποστήριξη analytics και αναζήτησης κειμένου, διαχείρισης μνήμης και αυτόματης αναπαραγωγής, στοιχεία που επιτρέπουν την ανάπτυξη μιας ευρείας γκάμας εφαρμογών πραγματικού χρόνου πάνω στην ίδια τεχνολογία Ιστορία Αναπτύχθηκε από την εταιρεία λογισμικού 10gen 40 τον Οκτώβριο του 2007, ως τμήμα μιας επί πληρωμής πλατφόρμας νέφους (cloud). Κατανοώντας στην πορεία την προοπτική του συστήματος βάσης δεδομένων που είχε αναπτύξει, η εταιρία εγκατέλειψε την πλατφόρμα cloud και επικεντρώθηκε στην εξέλιξη της βάσης, την οποία διέθεσε στο κοινό το 2009 ως λογισμικό ανοικτού πηγαίου κώδικα, προσφέροντας παράλληλα εμπορική υποστήριξη και λοιπές υπηρεσίες. Έκτοτε, η MongoDB έχει υιοθετηθεί από μια σειρά μεγάλων δικτυακών τόπων, συμπεριλαμβανομένων των ebay, Foursquare, SourceForge και Viacom 41. Διατίθεται με άδεια που συνιστά συνδυασμό των GNU Affero General Public License και Apache. Στα πειράματά μας χρησιμοποιήθηκε η έκδοση του συστήματος, η σταθερή έκδοση της οποίας δημοσιεύθηκε την 11 Αυγούστου Η ονομασία της προέρχεται από τη λέξη humongous, που σημαίνει γιγαντιαία 38 Το λογισμικό διατίθεται προς μεταφόρτωση σε 39 Μάλιστα παρέχεται δυνατότητα δυναμικής επεξεργασίας του σχήματος χωρίς να συνεπάγεται διακοπή της λειτουργίας του συστήματος 40 Η οποία πλέον έχει μετατραπεί στην MongoDB Inc. 41 Η MongoDB είναι το πιο δημοφιλές NoSQL σύστημα βάσης δεδομένων για τον Οκτώβριο του 2014, σύμφωνα με σημειώνοντας μάλιστα συνεχή ανοδική τάση την τελευταία διετία (βλ. αναλυτικά 33

34 34 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Βασικά Χαρακτηριστικά Πλήρης υποστήριξη ευρετηρίασης (Indexing) Προβλέπονται οι ακόλουθοι τύποι index: α) με βάση το βασικό κλειδί (Default _id), β) σε συγκεκριμένο πεδίο (Single Field), γ) σε περισσότερα πεδία (Compound), δ) σε περισσότερες εσωτερικής ιδιότητες της τιμής κάθε εγγραφής (Multikey), ε) γεωχωρικοί (Geospatial), στ) κειμένου (Text) και ζ) κατακερματισμού (Hashed) 42. Αναπαραγωγή και υψηλή διαθεσιμότητα Μία ομάδα από instances 43 που φιλοξενεί το ίδιο σύνολο δεδομένων αποκαλείται replica set στη MongoDB. Ανεξάρτητα από την τοπολογία που θα προκριθεί, μόνο το πρωτεύον instance επιτρέπεται να λαμβάνει λειτουργίες εγγραφής. Τα υπόλοιπα είναι αποδέκτες των αναπαραγωγών. Χάρη στον εν λόγω περιορισμό, επιτυγχάνεται απόλυτη συνέπεια για κάθε ανάγνωση από το πρωτεύον instance. Προβλέπεται η προσθήκη επιπλέον instance στο replica set με το ρόλο του διαιτητή (arbiter). Ο τελευταίος δεν τηρεί κάποιο σύνολο δεδομένων καθώς η συνεισφορά του εξαντλείται στη συμμετοχή στη ψηφοφορία ανάδειξης νέου πρωτεύοντος instance, στις περιπτώσεις που για κάποιο λόγο παρουσιάζεται απώλεια του αρχικού. Εικόνα 2: Διάγραμμα μίας ομάδας αναπαραγωγής στη MongoDB που αποτελείται από έναν πρωτεύοντα και δύο δευτερεύοντες κόμβους Βλ. αναλυτικά 43 Σημειώνεται ότι σε έναν κόμβο ενδέχεται να εκτελούνται περισσότερα mongod instances 44 Πηγή: 34

35 3. Τεχνολογίες Υπολογιστικού Νέφους Πειράματος 35 Αυτόματη οριζόντια επέκταση Τα δεδομένα χωρίζονται και διανέμονται σε πολλαπλούς servers, αποκαλούμενοι ως shards από τη MongoDB. Κάθε shard συνιστά μια ανεξάρτητη βάση δεδομένων, και συλλογικά, τα shards συνθέτουν μια ενιαία λογική βάση δεδομένων. Η MongoDB υποστηρίζει τις σχετικές διεργασίες μέσω της διαμόρφωσης ομάδων shards (sharded clusters), που αποτελούνται από shards, για την αποθήκευση των δεδομένων, δρομολογητές επερωτήσεων (Query Routers), με αντικείμενο την κατάλληλη διακίνηση των αιτημάτων, και εξυπηρετητές ρυθμίσεων (Config servers), όπου τηρούνται τα απαραίτητα μεταδεδομένα. Επερωτήσεις με πληθώρα δυνατοτήτων Υποστηρίζονται λογικοί τελεστές (AND, OR), έλεγχος ισότητας σε ιδιότητες ενσωματωμένων εγγράφων, αντιστοίχηση πίνακα και έλεγχος αν περιέχεται συγκεκριμένο στοιχείο πίνακα με δυνατότητα συνδυασμού κριτηρίων. 35

36 36 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Πίνακας 2: Συγκριτικός πίνακας ως προς τις δυνατότητες των επερωτήσεων προς τη MongoDB 45 Ταχείες Ενημερώσεις Σε αντίθεση με άλλες document βάσεις δεδομένων, η MongoDB επιτρέπει την απομόνωση και ενημέρωση συγκεκριμένης ιδιότητας ενός αποθηκευμένου εγγράφου, στοιχείο που προσφέρει μία σημαντική ώθηση σε απόδοση. Map/Reduce 45 Πηγή: 36

37 3. Τεχνολογίες Υπολογιστικού Νέφους Πειράματος 37 Οι διεργασίες Map/Reduce αποσκοπούν στην επεξεργασία δεδομένων κατά τρόπο ώστε συμπυκνώνεται μεγάλος όγκος δεδομένων σε χρήσιμα συγκεντρωτικά αποτελέσματα. Όλες οι συναρτήσεις map-reduce στη MongoDB καλούνται μέσω JavaScript. Υποστήριξη GridFS Το GridFS είναι μια προδιαγραφή για την αποθήκευση και ανάκτηση αρχείων που υπερβαίνουν το όριο μεγέθους BSON εγγράφων που έχει οριστεί σε 16MB. Αντί να αποθηκευθεί ένα αρχείο σε ένα ενιαίο έγγραφο, το GridFS το χωρίζει σε τμήματα, και αποθηκεύει καθένα από αυτά ως ξεχωριστό έγγραφο. Χρησιμοποιεί δύο συλλογές για την αποθήκευση αρχείων, η πρώτη για τα κομμάτια του αρχείου, και η δεύτερη για τα μεταδεδομένα. Το GridFS είναι χρήσιμο όχι μόνο για την αποθήκευση αρχείων που υπερβαίνουν τα 16MB, αλλά και για την αποθήκευση των αρχείων, για την πρόσβαση προς τα οποία δεν είναι αναγκαία η φόρτωση ολόκληρου του αρχείου στη μνήμη. JavaScript διεπαφή Η διεπαφή προς τη MongoDB βασίζεται κατά κύριο λόγο σε JavaScript (JS). Λόγω της ραγδαίας ανάπτυξης του Παγκόσμιου Ιστού, η JavaScript έχει καταστεί τα τελευταία χρόνια μία από τις πιο δημοφιλείς γλώσσες προγραμματισμού 46. Το γεγονός ότι οι serverside εντολές διεπαφής προς τη MongoDB συντάσσονται αποκλειστικά σε JavaScript ενώ τα αποθηκευμένα δεδομένα είναι σε JSON, αποτελεί ένα σημαντικό πλεονέκτημα για τους μηχανικούς λογισμικού δικτυακών εφαρμογών. 46 Βλ. μεταξύ άλλων άρθρο The RedMonk Programming Language Rankings: January 2014, Stephen O'Grady, 22/01/2014, διαθέσιμο σε όπου η JavaScript κατατάσσεται ως η πιο δημοφιλής γλώσσα προγραμματισμού για τον Ιανουάριο του

38 38 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών 3.3 CouchDB Γενικά Η CouchDB είναι μία document βάση δεδομένων, η οποία βασίζει την αποθήκευση των τιμών σε format JSON 47. Έχει συγγραφεί σε γλώσσα προγραμματισμού Erlang, μια συναρτησιακή γλώσσα προγραμματισμού, που χαρακτηρίζεται από την ιδιαίτερη έμφαση στην παραγωγή αξιόπιστων, ανεκτικών σε σφάλματα και με έντονο παραλληλισμό εφαρμογών. Η ονομασία της συνιστά ακρωνύμιο της φράσης Cluster Of Unreliable Commodity Hardware 48, η οποία αντανακλά τους κυρίαρχους στόχους της CouchDB να είναι εξαιρετικά επεκτάσιμη και να προσφέρει υψηλή διαθεσιμότητα και αξιοπιστία, ακόμη και όταν λειτουργεί σε hardware επιρρεπές σε σφάλματα. Η επικοινωνία με τη βάση δεδομένων επιτελείται μέσω ενός HTTP -based REST API, γεγονός που υποδεικνύει τη ροπή του συστήματος προς δικτυακές εφαρμογές. Η CouchDB βασίζεται σε μια μηχανή αποθήκευσης Β-δέντρου (B-tree), η οποία είναι επιφορτισμένη με την ταξινόμηση των αποθηκευμένων δεδομένων, ενώ παρέχει και ένα μηχανισμό για την αναζήτηση, εισαγωγή και διαγραφή σε λογαριθμικά μειούμενο χρόνο. Κάθε αποθηκευμένο έγγραφο περιέχει μεταδεδομένα, όπως μοναδικό κλειδί και την αριθμό αναθεώρησης. Προκειμένου να αντιμετωπίσει το πρόβλημα απουσίας σταθερής δομής των δεδομένων, το συγκεκριμένο σύστημα εισήγαγε ένα μοντέλο προβολής (view), όπου χρησιμοποιείται JavaScript για την περιγραφή. Τα views χτίζονται δυναμικά και δεν επηρεάζουν τα υποκείμενα έγγραφα, ενώ επιτρέπονται περισσότερα για τα ίδια στοιχεία. 47 Το λογισμικό διατίθεται προς μεταφόρτωση σε 48 Δηλαδή Ομάδα Αναξιόπιστου Συμβατικού Υλικού 38

39 3. Τεχνολογίες Υπολογιστικού Νέφους Πειράματος 39 Εικόνα 3: Συμμόρφωση της CouchDB σε θεώρημα CAP Ιστορία Η CouchDB δημιουργήθηκε τον Απρίλιο του 2005 από τον Damien Katz, πρώην προγραμματιστή του Lotus Notes στην IBM. Στόχος του ήταν να αποτελέσει τη βάση δεδομένων του διαδικτύου, καθώς ο σχεδιασμός του είχε ως βασικό αντικείμενο να εξυπηρετήσει τις δικτυακές εφαρμογές. Αρχικά είχε συγγραφεί σε C ++, αλλά στην πορεία μεταφέρθηκε στην πλατφόρμα Erlang OTP, λόγω των πλεονεκτημάτων της τελευταίας στη διαχείριση σφαλμάτων. Το 2008 δόθηκε ως λογισμικό ανοικτού πηγαίου κώδικα με άδεια του Apache Software Foundation 50, με την πρώτη stable έκδοση να διατίθεται τον Ιούλιο του Έκτοτε έχει χρησιμοποιηθεί σε πληθώρα λογισμικών και υπηρεσιών, δραστηριοποιούμενων κατά κύριο λόγο στο διαδίκτυο Πηγή: CouchDB The Definitive Guide, J. Chris Anderson - Jan Lehnardt - Noah Slater, 2009, διαθέσιμο σε Βλ. άρθρο CouchDB NoSQL Database Ready for Production Use, Joab Jackson, IDG News Service, 14/08/2010, διαθέσιμο σε 52 Βλ. αναλυτικά άρθρο CouchDB In The Wild, διαθέσιμο σε 39

40 40 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Στα πειράματά μας χρησιμοποιήθηκε η έκδοση του συστήματος, η σταθερή έκδοση της οποίας δημοσιεύθηκε την 10 Ιουνίου Βασικά Χαρακτηριστικά Υποστήριξη ιδιοτήτων ACID Η CouchDB συμμορφώνεται και με τις 4 ιδιότητες ACID (Atomic Consistent Isolated Durable). Δεν αντικαθίστανται σε καμία περίπτωση δεδομένα που έχουν γίνει commit, εξασφαλίζοντας ότι η βάσης δεδομένων τελεί πάντοτε σε σταθερή κατάσταση. Αυτό επιτυγχάνεται με την εφαρμογή ενός μοντέλου ελέγχου παράλληλων εργασιών (Multi-Version Concurrency Control - MVCC) στις ενέργειες ανάγνωσης, δυνάμει του οποίου κάθε πελάτης βλέπει ένα συνεπές στιγμιότυπο της βάσης δεδομένων από την αρχή μέχρι το τέλος της λειτουργίας ανάγνωσης. Σημειώνεται ότι η ιδιότητα της συνέπειας πραγματώνεται με την ευρεία έννοια του όρου, ήτοι ως σταδιακή συνέπεια (eventual consistency) 53. Αυτόματη Συμπίεση Βάσει προγραμματισμένων περιοδικών εργασιών, όταν το αρχείο της βάσης δεδομένων υπερβαίνει έναν ορισμένο όγκο, εφαρμόζεται διαδικασία συμπίεσης και ενσωμάτωσης σε ένα νέο αρχείο. Η βάση δεδομένων παραμένει πλήρως διαθέσιμη κατά το μεσοδιάστημα, για λειτουργίες τόσο ανάγνωσης όσο και εγγραφής. Προβολές (Views) Σε αντίθεση με τις SQL βάσεις δεδομένων, όπου τα δεδομένα κατανέμονται σε πίνακες με αυστηρή δομή, τα δεδομένα στη CouchDB αποθηκεύονται ως ημι-δομημένα έγγραφα, σε JSON format. Κατά συνέπεια, επιτρέπεται το καθένα να έχει τη δική του δομή, στοιχείο που παρέχει μεγάλη ευελιξία. Από την άλλη πλευρά όμως, δεν υπάρχουν σταθερά σημεία αναφοράς ως προς το περιεχόμενο των εγγράφων. Η ανάγκη αυτή καλύπτεται με την πρόβλεψη των views. Τα τελευταία παρέχουν έναν πλήρως παραμετροποιήσιμο τρόπο 53 Βλ. αναλυτικά ανωτέρω 40

41 3. Τεχνολογίες Υπολογιστικού Νέφους Πειράματος 41 για το φιλτράρισμα, την οργάνωση και την έκθεση των δεδομένων. Οι προβολές ορίζονται με Javascript συναρτήσεις, που αποτελούν το βήμα Map σε μία map-reduce διεργασία. Για λόγους απόδοσης, η CouchDB επιτρέπει τη σύσταση ευρετηρίων (indexes) πάνω σε views. Ασφάλεια και Αυθεντικοποίηση Υλοποιούνται μέτρα ασφάλειας σε επίπεδο βάσης δεδομένων. Προβλέπονται ρόλοι διαχειριστή και απλού χρήστη. Μόνο ο πρώτος να δημιουργήσει άλλους λογαριασμούς διαχειριστή και να ενημερώσει έγγραφα σχεδιασμού (design) 54. Υποστηρίζει ακόμη αυθεντικοποίηση μέσω HTTP και διαχείριση συνόδων (sessions) με cookies φυλλομετρητή. Παρέχεται τέλος δυνατότητα επαλήθευσης της ορθότητας των εισαγόμενων εγγραφών με Javascript συναρτήσεις. Κατανεμημένη αρχιτεκτονική με αναπαραγωγή Η CouchDB σχεδιάστηκε με δυνατότητα αμφίδρομης αναπαραγωγής και με offline υποστήριξη. Οι κόμβοι τηρούν ο καθένας το δικό του αντίγραφο των ίδιων δεδομένων, ενώ ο συγχρονισμός των αλλαγών μπορεί να λάβει χώρα σε μεταγενέστερο χρόνο. REST API Όλα τα στοιχεία έχουν ένα μοναδικό URI (Uniform resource identifier) που εκτίθεται μέσω HTTP. Ακολουθείται RESTful υλοποίηση δικτυακών υπηρεσιών, όπου χρησιμοποιούνται οι HTTP μεθόδους POST, GET, PUT και DELETE για τις τέσσερις βασικές λειτουργίες CRUD (Create, Read, Update, Delete) σε όλους τους πόρους. Δικτυακό διαχειριστικό περιβάλλον Η CouchDB περιλαμβάνει μία δικτυακή διεπαφή διαχείρισης, προσβάσιμη μέσω φυλλομετρητή, που ονομάζεται Futon. 54 Τα έγγραφα σχεδιασμού αποτελούν ειδικά έγγραφα που περιέχουν τους ορισμούς προβολών και άλλων ειδικών τύπων, καθώς και βασικά πεδία και blobs. 41

42 42 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Εικόνα 4: Futon, το δικτυακό διαχειριστικό περιβάλλον της CouchDB 3.4 HBase Γενικά Η HBase είναι ένα wide-column, κατανεμημένο, επεκτάσιμο και με υποστήριξη εκδόσεων NoSQL σύστημα αποθήκευσης 55, το οποίο αποτελεί τη βάση δεδομένων του Hadoop 56. Έχει συγγραφεί σε γλώσσα προγραμματισμού Java. Η χρήση της HBase συνίσταται σε περιπτώσεις όπου απαιτείται τυχαία και σε πραγματικό χρόνο πρόσβαση για ανάγνωση ή εγγραφή σε μεγάλο όγκο δεδομένων. Στόχος της είναι να αποθηκεύει πολύ μεγάλους πίνακες, της τάξης των δισεκατομμυρίων σειρών με εκατομμύρια στήλες, επί συστάδων συμβατικού hardware. Αναπτύχθηκε έχοντας ως πρότυπο το σύστημα Bigtable της Google 57. Ακριβώς όπως το Bigtable αξιοποιεί την κατανεμημένη αποθήκευση 55 Το λογισμικό διατίθεται προς μεταφόρτωση σε 56 Το Hadoop αποτελεί μία βιβλιοθήκη λογισμικού που επιτρέπει την κατανεμημένη επεξεργασία μεγάλων συνόλων δεδομένων σε συστάδες υπολογιστών με τη χρήση απλών προγραμματιστικών μοντέλων. ΒΛ. αναλυτικά 57 Βλ. αναλυτικά Bigtable: A Distributed Storage System for Structured Data, Chang Dean Ghemawat Hsieh Wallach Burrows Chandra Fikes Gruber, OSDI'06: Seventh Symposium on Operating System 42

43 3. Τεχνολογίες Υπολογιστικού Νέφους Πειράματος 43 δεδομένων μέσω του συστήματος αρχείων της Google (Google File System- GFS), η HBase παρέχει παρόμοιες λειτουργικότητες σε επίπεδο ανώτερο των Hadoop και HDFS (Hadoop Distributed File System) 58. Εικόνα 5: Μία τυπική τοπολογία συστάδας στην HBase Ιστορία Η HBase αναπτύχθηκε το 2007 από την εταιρεία Powerset για την κάλυψη της ανάγκης επεξεργασίας τεράστιου όγκου δεδομένων στο πλαίσιο ενός λογισμικού αναζήτησης στο διαδίκτυο με φυσική γλώσσα. Το 2008 δόθηκε ως λογισμικό ανοικτού πηγαίου κώδικα και εντάχθηκε ως υπό-έργο του Hadoop, ενώ το 2010 αξιολογήθηκε ως υψηλού επιπέδου έργο του Apache Software Foundation. Εμπορική υποστήριξη του λογισμικού παρέχεται από την εταιρεία Cloudera 60. Το σύστημα ξεκίνησε να γίνεται δημοφιλές και στο ευρύ κοινό ύστερα από την επιλογή του από το Facebook το Νοέμβριο Design and Implementation, Νοέμβριος 2006, διαθέσιμο σε passim 58 Το HDFS είναι ένα κατανεμημένο σύστημα αρχείων, κατάλληλη για την αποθήκευση μεγάλων αρχείων 59 Πηγή: άρθρο Apache Hbase - The NoSQL Database for Hadoop and Big Data, Alex Baranau - Otis Gospodnetic, 2012, διαθέσιμο σε

44 44 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών του 2010 ως το σύστημα βάσης δεδομένων της νέας του πλατφόρμας ανταλλαγής μηνυμάτων (Facebook Messenger) 61, 62. Στα πειράματά μας χρησιμοποιήθηκε η έκδοση του συστήματος, η σταθερή έκδοση της οποίας δημοσιεύθηκε την 4 Σεπτεμβρίου Βασικά Χαρακτηριστικά Αυστηρή συνέπεια Σε αντίθεση με τα περισσότερα NoSQL συστήματα, που ακολουθούν την προσέγγιση της σταδιακής συνέπειας, η HBase συνιστά CP τύπο λογισμικό, υπό το πρίσμα του θεωρήματος CAP, δηλαδή θυσιάζει τη διαθεσιμότητα και όχι τη συνέπεια 63. Αυτόματη οριζόντια επέκταση Οι πίνακες της HBase διανέμονται στη συστάδα, κατατασσόμενες σε περιφέρειες (regions), και οι περιφέρειες χωρίζονται αυτόματα και αναδιανέμονται καθώς αυξάνονται τα δεδομένα. Παρέχεται ωστόσο και δυνατότητα παραμετροποίησης του ακριβούς τρόπου αναδιανομής Βλ. αναλυτικά άρθρο The Underlying Technology of Messages, Kannan Muthukkaruppan, 15/11/2010, διαθέσιμο σε όπου αναφέρεται ότι δοκιμάστηκαν μεταξύ άλλων τα συστήματα MySQL, Cassandra και HBase. Επιλέχθηκε τελικά η Hbase, επειδή η MySQL αποδείχθηκε μη αποδοτική στη διαχείριση του μεγάλου όγκου δεδομένων, ενώ το μοντέλο σταδιακής συνέπειας της Cassandra ήταν δύσκολο να συμβιβαστεί με την υποδομή της νέας πλατφόρμας ανταλλαγής μηνυμάτων. 62 Πρβλ. λίστα των οργανισμών που χρησιμοποιούν το σύστημα Hbase σε wiki.apache.org/hadoop/hbase/poweredby 63 Βλ. αναλυτικά άρθρο CAP Confusion: Problems with partition tolerance, Henry Robinson, 26/04/2010, διαθέσιμο σε 64 Βλ. αναλυτικά HBase: The Definitive Guide, Lars George, 2011, ISBN , σελ. 21 επ. 44

45 3. Τεχνολογίες Υπολογιστικού Νέφους Πειράματος 45 Εικόνα 6: Αποθήκευση σειρών στην HBase, κατανεμημένων σε περιφέρειες, σε περισσότερους εξυπηρετητές 65 Διαλειτουργικότητα με Hadoop/HDFS Υπάρχει εγγενής υποστήριξη της HDFS, ως το κατανεμημένο σύστημα αρχείων για τις εργασίες της HBase. Map/Reduce Παρέχεται δυνατότητα μαζικής παράλληλης επεξεργασίας με Map/Reduce. Διεπαφές Προσφέρονται application programming interfaces (API) για απομακρυσμένη πρόσβαση μέσω Java, καθώς και μέσω Thrift και REST. Η πύλη Thrift και η REST δικτυακή υπηρεσία Web υποστηρίζουν XML, Protobuf και binary επιλογές κωδικοποίησης δεδομένων. Block Cache και Bloom Filters 65 Πηγή: HBase: The Definitive Guide, ο.π. 45

46 46 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Η HBase περιλαμβάνει υλοποίηση Block Cache και Bloom Filters με στόχο τη βελτιστοποίηση υψηλού όγκου επερωτήσεων. Η Block Cache διατηρεί τα δεδομένα στη μνήμη μετά την ανάγνωσή τους, ούτως ώστε να είναι σε θέση να εξυπηρετήσει επόμενα αιτήματα ανάγνωσης με ελάχιστη καθυστέρηση της τάξης χιλιοστών του δευτερολέπτου. Το Bloom Filter 66 από την άλλη πλευρά, είναι μία δομή δεδομένων που έχει σχεδιαστεί για να προβλέψει εάν ένα στοιχείο εισόδου αποτελεί μέλος ενός συνόλου δεδομένων. Ένα θετικό αποτέλεσμα δεν είναι πάντα ακριβές, αλλά τα αρνητικά αποτελέσματα έχουν εγγυημένη ορθότητα. Στο πλαίσιο της HBase, τα φίλτρα Bloom παρέχει μια ελαφριά δομή στη μνήμη προκειμένου να μειωθεί ο αριθμός των φορών ανάγνωσης από δίσκο. Το δυνητικό κέρδος σε απόδοση αυξάνει με τον αριθμό των παράλληλων αναγνώσεων. Διαχειριστικό Περιβάλλον μετρικές JMX. Υπάρχει ενσωματωμένη δικτυακή διεπαφή για ανάλυση των διεργασιών και 66 Ονομάστηκαν έτσι από το δημιουργό τους, Burton Howard Bloom. 46

47 4. Πλαίσιο Αξιολόγησης Πλαίσιο Αξιολόγησης 4.1 Εισαγωγή Το πλαίσιο της αξιολόγησης των NoSQL συστημάτων περιλαμβάνει τη δημιουργία των σεναρίων που εφαρμόστηκαν για τη δοκιμή των διαφορετικών τεχνολογιών, τη ρύθμιση του cloud περιβάλλοντος και των πελατών. Η εγκατάσταση, όπως απεικονίζεται στην εικόνα 9, αποτελείται από ένα σύμπλεγμα κόμβων αποθήκευσης και ένα σύνολο πελατών, που έχουν επιφορτιστεί με το βάρος να εισάγουν δεδομένα σε κάθε κόμβο. Εικόνα 7: Σχέση πελατών και κόμβων συστήματος 4.2 Σενάρια Αξιολόγησης Τα πειράματα πραγματοποιήθηκαν για 1, 3, 6 και 9 κόμβους. Στόχος ήταν η εισαγωγή περίπου ενός εκατομμυρίου εγγραφών, με συνολικό όγκο 4GB. Η ιδιαιτερότητα των μετρήσεων δεν έγκειται τόσο στον αριθμό των σειρών, όσο στο σχετικά μεγάλο μέγεθος των ροών δεδομένων. Για κάθε αριθμό κόμβων, καταγράφηκαν 4 παραλλαγές μετρήσεων: 47

48 48 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών 1. Εισαγωγή από έναν πελάτη, χωρίς να επιτελείται έλεγχος του αριθμού έκδοσης του καταχωρούμενου στοιχείου. 2. Εισαγωγή από έναν πελάτη, με υποστήριξη εκδόσεων. Αυτό το σενάριο επιτάσσει ενημέρωση του αριθμού έκδοσης του βιβλίου στον πίνακα πληροφοριών, εάν διαπιστωθεί ότι υπάρχει ήδη καταχωρημένο στη βάση δεδομένων. Αντίθετα, η ροή δεδομένων εισάγεται αυτούσια κάθε φορά. 3. Εισαγωγή από τρεις πελάτες, χωρίς έλεγχο του αριθμού έκδοσης. Οι πελάτες εκτελούν τις διεργασίες τους σε διαφορετικά εικονικά μηχανήματα (Virtual Machines), μοιράζονται σε ίσα μέρη το συνολικό αριθμό εγγραφών, ενώ εκτελούν παράλληλα τις καταχωρήσεις. 4. Εισαγωγή από τρεις πελάτες, με υποστήριξη εκδόσεων. Οι πελάτες εκτελούν τις διεργασίες τους σε διαφορετικά VMs, μοιράζονται σε ίσα μέρη το συνολικό αριθμό εγγραφών, ενώ εκτελούν παράλληλα τις καταχωρήσεις. 4.3 Ρυθμίσεις Περιβάλλοντος Αξιολόγησης Τα πειράματα έλαβαν χώρα σε εικονικά μηχανήματα, με λειτουργικό Debian Linux και ίδιων χαρακτηριστικών σε όλες τις διαμορφώσεις. Χρησιμοποιήθηκαν οι ακόλουθες εκδόσεις λογισμικού αποθήκευσης σε υπολογιστικό νέφος για την εκτέλεση των σεναρίων αξιολόγησης: Cassandra: (δημοσιεύθηκε την 30 Ιουνίου 2014) CouchDB: (δημοσιεύθηκε την 10 Ιουνίου 2014) HBase: (δημοσιεύθηκε την 4 Σεπτεμβρίου 2014), συνδεόμενη σε Hadoop έκδοσης 2.2.0, και Zookeeper έκδοσης MongoDB: (δημοσιεύθηκε την 11 Αυγούστου 2014) Oι εφαρμογές των πελατών έχουν αναπτυχθεί στο σύνολό τους χρησιμοποιώντας την τελευταία έκδοση του αντίστοιχου προγράμματος οδήγησης Java και εκτελέσθηκαν σε Java 1.7.0_67 περιβάλλον: Cassandra: DataStax Java Driver 2.1 για Apache Cassandra CouchDB: LightCouch Java driver HBase: native Java driver

49 4. Πλαίσιο Αξιολόγησης 49 MongoDB: MongoDB Java Driver Μοντέλο περιεχομένων Το ψηφιακό αποθετήριο λαμβάνει την πληροφορία σε συμπιεσμένα αρχεία tar, που περιέχουν φακέλους και αρχεία με καθορισμένη δομή. Το μοντέλο περιεχομένου βασίζεται σε XML κωδικοποιημένα ψηφιακά αντικείμενα, όπως αποτυπώνονται στις ακόλουθες εικόνες. Κάθε ψηφιακό αντικείμενο αναπαρίσταται ως ένα σύμπλεγμα, αποτελούμενο από ροές δεδομένων (datastreams). Κάθε ροή δεδομένων ενδέχεται να τηρεί κάθε είδους πληροφορία (π.χ. δυαδικές, XML, κλπ) και παρέχει υποστήριξη εκδόσεων. Πρόσθετη πληροφορία, όπως στοιχεία ιδιοκτήτη και ορισμός XML σχήματος, αποτελεί μέρος των μεταδεδομένων του εκάστοτε αντικειμένου. Εικόνα 8: Αναπαράσταση ψηφιακού αντικειμένου Η πληροφορία διασπάται σε πληθώρα εξωτερικών φακέλων για λόγους περιορισμών στα διάφορα λειτουργικά συστήματα. Εικόνα 9: Στοιχεία εξωτερικού φακέλου 49

50 50 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Κάθε εξωτερικός φάκελος περιέχει εντός του φακέλου items ένα σύνολο υποφακέλων, ο καθένας εκ των οποίων αντιστοιχεί σε ένα αντικείμενο του αποθετηρίου. Εικόνα 10: Ενδεικτικά περιεχόμενα φακέλου items Στα πειράματα χρησιμοποιήθηκαν αρχεία με προέλευση το έργο CARARE (Connecting Archaeology & Architecture in Europeana) 67. Για τη συγκεκριμένη προέλευση, αναγνώσθηκε σε κάθε υποφάκελο το αρχείο με ονομασία carare.xml. Αντιστοιχεί στην ουσία στο προς καταχώρηση datastream. Το αρχείο native.xml περιέχει στην ουσία τα ίδια δεδομένα, αλλά σε συμμόρφωση με διαφορετικό XML σχήμα. 67 Βλ. συνοπτικά 50

51 4. Πλαίσιο Αξιολόγησης 51 Εικόνα 11: Στοιχεία αντικειμένου αποθετηρίου Το δεύτερο αρχείο που μας ενδιαφέρει είναι αυτό με ονομασία info.xml. Αυτό περιέχει τα μεταδεδομένα της εκάστοτε καταχώρησης. Η ταυτοποίηση κάθε στοιχείου προκύπτει από το συνδυασμό των id των στοιχείων provider & item. Εικόνα 12: Ενδεικτικά περιεχόμενα αρχείου info.xml 4.5 Ανάγνωση αρχείων ψηφιακού αποθετηρίου Προκειμένου τα δεδομένα του ψηφιακού αποθετηρίου να μπορούν να εισαχθούν με ομοιόμορφο τρόπο στα διάφορα συστήματα, αναπτύχθηκε ειδική εφαρμογή σε περιβάλλον Java EE 7. Σκοπός αυτής αποτελεί η ανάλυση (parsing) των ανωτέρω αρχείων από το file system και η μετατροπή τους σε αντικείμενο με τα πεδία που θα εισαχθούν στην κάθε βάση δεδομένων. 51

52 52 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Εικόνα 13: Πεδία και μέθοδοι της κλάσης CarareItem Η κλάση Java υπεύθυνη για τη συγκεκριμένη διεργασία αποκαλείται CarareParser και δημιουργεί αντικείμενα της entity κλάσης CarareItem. Λειτουργεί με αυτόνομο τρόπο σε σχέση με τη διαδικασία εισαγωγής δεδομένων στα NoSQL συστήματα, ενώ τηρείται ξεχωριστά ο χρόνος ολοκλήρωσης και ο αριθμός επεξεργαζόμενων αρχείων για λόγους ελέγχου. Το instance της κλάσης CarareParser διασχίζει τους φακέλους με τα items, αναλύοντας τα περιεχόμενα αρχεία info.xml, ώστε να αντλήσει τα σχετικά μεταδεδομένα ονομασίας και μοναδικής ταυτοποίησης. Στη συνέχεια διαβάζει το αντίστοιχο αρχείο carare.xml και μετατρέπει το περιεχόμενό του σε αλφαριθμητικό (String). Με την ολοκλήρωση της ανάγνωσης και μετατροπής των αρχείων, μεταφέρεται ο έλεγχος στην κλάση για εισαγωγή δεδομένων στις nosql βάσεις δεδομένων. 52

53 4. Πλαίσιο Αξιολόγησης 53 Εικόνα 14: Πεδία και μέθοδοι της κλάσης CarareParser 4.6 Ρύθμιση Βάσεων Δεδομένων Γενικά Σε κάθε σύστημα, ακολουθήθηκε η προσέγγιση της δημιουργίας ενός σχήματος με δύο πίνακες, κατά την ορολογία των σχεσιακών βάσεων δεδομένων. Ο πρώτος πίνακας, καλούμενος στο εξής πίνακας μεταδεδομένων, περιέχει τα μεταδεδομένα κάθε ροής δεδομένων, όπως αποτυπώνονται στο εκάστοτε info.xml αρχείο, στα οποία προστίθενται κάποια μεταδεδομένα για τις ανάγκες του πειράματος, όπως ημερομηνία και χρήστης εισαγωγής. Στο δεύτερο πίνακα, καλούμενο στο εξής πίνακα ροής δεδομένων, καταχωρούνται οι ροές δεδομένων (datastreams). Και στους δύο πίνακες έχει προβλεφθεί η ύπαρξη επιπλέον στήλης που περιλαμβάνει το χρόνο καταχώρησης της κάθε εγγραφής, εφόσον ήταν απαραίτητο - π.χ. στην περίπτωση της MongoDB δεν προστέθηκε τέτοιο πεδίο διότι η συναφής πληροφορία συνιστά μέρος του auto generated _id και ως εκ τούτου δύναται να εξαχθεί από το τελευταίο. 53

54 54 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Ο ορισμός δύο πινάκων ήταν επιβεβλημένος προκειμένου να καταστεί δυνατή η υποστήριξη εκδόσεων (versioning) για τα εισαγόμενα στοιχεία. Η εν λόγω υποστήριξη επιτελείται με τον ακόλουθο τρόπο: πριν από κάθε νέα καταχώρηση γίνεται έλεγχος, βάσει των σχετικών εντολών του εκάστοτε συστήματος, αν υπάρχει προηγούμενη έγγραφη για το ίδιο αντικείμενο. Σε θετική περίπτωση, αυξάνεται κατά μία μονάδα ο αριθμός έκδοσης στην αντίστοιχη εγγραφή του πίνακα μεταδεδομένων Cassandra Δημιουργήθηκε ένα keyspace με πρόβλεψη αναπαραγωγής (replication), ειδικότερα με κλάση απλής στρατηγικής (Simple Strategy) και με ανατειθέμενη τιμή 1 ως παράγοντας αντιγραφής. Εντός του keyspace, ορίστηκαν δύο πίνακες, για τα μεταδεδομένα και τις ροές δεδομένων αντίστοιχα. Στον πίνακα μεταδεδομένων ορίστηκε ο συνδυασμός του παρόχου και κωδικού αντικειμένου ως πρωτεύον κλειδί, ενώ στον πίνακα ροής δεδομένων προβλέφθηκε τεχνητό κλειδί, με βάση τον timeuuid τύπο δεδομένων. Εικόνα 15: Εντολές δημιουργίας σχήματος σε Cassandra 54

55 4. Πλαίσιο Αξιολόγησης CouchDB Η CouchDB βασίζεται σε ένα ελεύθερο σχήμα δεδομένων, που δε συμβαδίζει με την κλασική έννοια των πεδίων πίνακα μίας σχεσιακής βάσης δεδομένων. Αρκεί κάθε εγγραφή να συμμορφώνεται με το JSON format. Δημιουργήθηκε μία βάση δεδομένων (database), στην οποία αποθηκεύουμε έγγραφα τόσο με μεταδεδομένα όσο και με ροές δεδομένων. Διαχωρίζονται μεταξύ τους μέσω της πρόβλεψης ενός πεδίου με τίτλο "type" και το οποίο λαμβάνει τιμές "info" και "datastreams", αντίστοιχα. Στις εγγραφές με μεταδεδομένα το πρωτεύον κλειδί προκύπτει από το συνδυασμό του παρόχου και κωδικού αντικειμένου, ενώ στις εγγραφές με ροές δεδομένων προβλέφθηκε τεχνητό κλειδί, με βάση τη static μέθοδο UUID.randomUUID() της Java MongoDB Δημιουργήθηκε μία βάση δεδομένων, στην οποίο προβλέφθηκαν δύο συλλογές (collections), με τα μεταδεδομένα και τις ροές δεδομένων αντίστοιχα. Η αποθήκευση των δεδομένων μεταξύ των διαφόρων κόμβων διεξήχθη μέσω διαμελισμού (sharding). Το σύμπλεγμα διαμελισμού (sharded cluster) αποτελείται από τα ακόλουθα στοιχεία: shards, δρομολογητές επερωτήσεων (query routers) και εξυπηρετητή ρυθμίσεων (config server). Το κλειδί διαμελισμού βασίστηκε σε κατακερματισμό (hash based partitioning). Για λόγους απόδοσης, δημιουργήθηκε ευρετήριο (index) με βάση το συνδυασμό παρόχου και κωδικού αντικειμένου, το οποίο χρησιμοποιήθηκε στα σενάρια υποστήριξης εκδόσεων. Εικόνα 16: Εντολές δημιουργίας σχήματος σε MongoDB 55

56 56 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών HBase Δημιουργήθηκε namespace, το οποίο περιέχει δύο πίνακες, για τα μεταδεδομένα και τις ροές δεδομένων αντίστοιχα. Ορίστηκαν οικογένειες στηλών (Column Families) σε κάθε πίνακα, οι οποίες χωρίστηκαν με βάση τις πληροφορίες αντικειμένου και εισαγωγής. Εικόνα 17: Εντολές δημιουργίας σχήματος σε HBase 4.7 Ρύθμιση Πελατών Γενικά Προκειμένου να αποκτηθεί αποτελεσματική πρόσβαση στην υποδομή υπολογιστικού νέφους, ήταν απαραίτητη η ανάπτυξη και πρόσφορη παραμετροποίηση πελάτη. Για λόγους αξιοπιστίας και ευχερέστερης συντήρησης, προκρίθηκε σε όλες τις περιπτώσεις η χρήση της τεχνολογίας Java. Δόθηκε ωστόσο έμφαση ώστε ο κάθε πελάτης να εξασφαλίσει ότι οι μετρήσεις θα επωφεληθούν από τα ιδιαίτερα χαρακτηριστικά της διασυνδεόμενης βάσης δεδομένων. Επίσης, για λόγους ακεραιότητας των μετρήσεων, η τήρηση του χρόνου εισαγωγής 56

57 4. Πλαίσιο Αξιολόγησης 57 επιτελείται αποκλειστικά στην πλευρά της Java εφαρμογής. Η μέτρηση της διάρκειας των συναλλαγών επιτελείται με χρήση της συνάρτησης System.nanoTime() 68. Εικόνα 18: Μέθοδος κλήσης NoSQL Java clients Για λόγους επαναχρησιμοποίησης κώδικα και περιορισμού των σφαλμάτων, οι java clients, που επικοινωνούν με τον client driver κάθε NoSQL συστήματος, αναπτύχθηκαν με σχέση κληρονομικότητας προς μία αφηρημένη (abstract) γονική κλάση εισαγωγής. Με αυτόν τον τρόπο αφενός υπάρχει κοινή αναφορά στα δεδομένα εισαγωγής και αφετέρου εγκαθιδρύεται ενιαία μέτρηση για τα transactions. 68 Ως πιο αξιόπιστη για μετρήσεις διάρκειας. Βλ. αναλυτικά - υπάρχει από την έκδοση 5 της Java EE 57

58 58 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Εικόνα 19: Πεδία και μέθοδοι της κλάσης NoSQLClientTest Cassandra Χρησιμοποιήθηκε τόσο το σύγχρονο όσο και το ασύγχρονο API (Application Programming Interface) του DataStax Java Driver. Το τελευταίο αποδείχθηκε, όπως αναμενόταν, πολύ πιο γρήγορο. Αυτό το αποτέλεσμα οφείλεται στο γεγονός ότι το σύγχρονο API μπλοκάρει άλλες λειτουργίες πελάτη έως ότου ληφθεί κάποιο αποτέλεσμα από τη βάση δεδομένων. 58

59 4. Πλαίσιο Αξιολόγησης 59 Εικόνα 20: Εισαγωγή δεδομένων με το asynchronous Java client API για Cassandra Από την άλλη πλευρά, το ασύγχρονο ΑΡΙ δε συνεπάγεται την παύση διασύνδεσης λοιπών πελατών. Ολοκληρώνει το έργο του μόλις η επερώτηση περαστεί στη στοίβα δικτύου με προορισμό τη βάση δεδομένων 69. Ο έλεγχος επιτυχούς εισαγωγής των εγγραφών μετατίθεται κατά συνέπεια σε δεύτερο χρόνο, μέσω της πρόσβασης στο αντικείμενο ResultSetFuture. Σε αμφότερες τις κλήσεις API, χρησιμοποιήθηκε α) μια πραγμάτωση της κλάσης com.datastax.driver.core.cluster για κάθε φυσική συστάδα κόμβων (cluster) σε όλη τη διάρκεια ζωής της εφαρμογής, β) αποκλειστικά μία συνεδρία 70 για το σύνολο των επερωτήσεων και γ) ένα PreparedStatement 71 για κάθε CQL 69 Βλ. αναλυτικά σχετικό Javadoc, διαθέσιμο σε tastax.driver.core.statement%29 70 Πραγμάτωση της κλάσης com.datastax.driver.core.session 71 Πραγμάτωση της κλάσης com.datastax.driver.core.preparedstatement 59

60 60 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών επερώτηση 72. Στην περίπτωση των κλήσεων με το σύγχρονο API, περιορίστηκε στο ελάχιστο ο αριθμός network roundtrips, χάρη στη χρήση Batches 73. Εικόνα 21: Εισαγωγή δεδομένων με το synchronous Java client API για Cassandra Βάσει του σχήματος που ορίστηκε στη συγκεκριμένη βάση δεδομένων, αποδείχθηκε αναγκαία η χρησιμοποίηση της εντολής "ALLOW FILTERING" στις επερωτήσεις για την ανεύρεση υπάρχοντος αντικειμένου στα σενάρια υποστήριξης εκδόσεων. 72 Πρβλ. συναφείς κατευθύνσεις σε άρθρο 4 simple rules when using the DataStax drivers for Cassandra, Alex Popescu, 05/06/2014, διαθέσιμο σε 73 Πραγμάτωση της κλάσης com.datastax.driver.core.batchstatement. Βλ. αναλυτικά 60

61 4. Πλαίσιο Αξιολόγησης 61 Εικόνα 22: Μέθοδος ανεύρεσης υπάρχουσας εγγραφής σε Cassandra CouchDB Στην CouchDB χρησιμοποιήθηκε, για λόγους απόδοσης, το Bulk documents API του LightCouch Java driver 74, το οποίο επιτρέπει τη μαζική εισαγωγή δεδομένων. 74 Βλ. documentation σε 61

62 62 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Εικόνα 23: Εισαγωγή δεδομένων στην CouchDB με Java client Εικόνα 24: Μέθοδος ανεύρεσης υπάρχουσας εγγραφής σε CouchDB HBase Για την αποδοτικότερη διασύνδεση με την HBase, επιστρατεύθηκε η μέθοδος Put της κλάσης HTable, η οποία ανευρίσκεται στο πακέτο org.apache.hadoop.hbase.client του Native Client java. Αυτή η μέθοδος δέχεται μια λίστα στοιχείων (List 62

63 4. Πλαίσιο Αξιολόγησης 63 <org.apache.hadoop.hbase.client.put>) ως παράμετρο εισόδου 75, χαρακτηριστικό που συνεπάγεται τη μαζική εισαγωγή εγγραφών στη βάση δεδομένων. Λόγω περιορισμών σε επίπεδο μνήμης RAM, οι εγγραφές προς εισαγωγή διαιρούνται σε χιλιάδες. Εικόνα 25: Εισαγωγή δεδομένων στην HBase με Java client 75 Βλ. αναλυτικά σχετικό Javadoc σε

64 64 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Εικόνα 26: Μέθοδος ανεύρεσης υπάρχουσας εγγραφής σε HBase MongoDB Στην περίπτωση της MongoDB, αξιοποιήθηκε η δυνατότητα, που παρέχεται από το MongoDB Java Driver, για εκτέλεση της λειτουργίας εγγραφής από τους πελάτες μαζικά 76. Ειδικότερα, σε κάθε λειτουργία εισαγωγής, συμπληρώνονται δύο λίστες, μία για κάθε συλλογή της βάσης δεδομένων. Η εν λόγω προσέγγιση αποδείχθηκε εξαιρετικά αποτελεσματική, ιδίως λόγω του συνδυασμού της με τη διανομή των εγγράφων κάθε συλλογής μεταξύ των shards του συμπλέγματος βάσει κλειδιών κατακερματισμού. Κατ αποτέλεσμα, αποφεύχθηκε η υπεισέλευση μονότονου στραγγαλισμού (monotonic throttling 77 ), φαινόμενο που παρουσιάζεται όταν η πλειονότητα των προς εγγραφή δεδομένων έχουν το ίδιο κόμβο ως αποδέκτη. 76 Βλ. αναλυτικά σχετικό documentation σε 77 Βλ. αναλυτικά MongoDB CRUD Operations, MongoDB Documentation Project, 23/01/2015, διαθέσιμο σε σελ

65 4. Πλαίσιο Αξιολόγησης 65 Εικόνα 27: Εισαγωγή δεδομένων στη MongoDB με Java client Εικόνα 28: Μέθοδος ανεύρεσης υπάρχουσας εγγραφής σε MongoDB 65

66 66 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών 4.8 Αποτελέσματα Πειράματος Γενικά Τα αποτελέσματα των μετρήσεων αναφέρονται στην εισαγωγή 1 εκατομμυρίου ψηφιακών αντικειμένων, κωδικοποιημένων σε XML, συνολικού όγκου 4GB. Η οριζόντια γραμμή (άξονας x) απεικονίζει τον αριθμό των κόμβων, ενώ η κάθετη γραμμή (άξονας y) απεικονίζει το χρόνο σε δευτερόλεπτα που απαιτήθηκε για την ολοκλήρωση της λειτουργίας. Επομένως χαμηλότερες τιμές υποδεικνύουν καλύτερη επίδοση. Σημειώνεται ότι για τον υπολογισμό του χρόνου προσμετρήθηκαν αποκλειστικά τα διαστήματα επικοινωνίας με τη βάση δεδομένων, τόσο για την εγκαθίδρυση σύνδεσης όσο και για την εισαγωγή των στοιχείων, και όχι ο χρόνος ανάγνωσης και μετατροπής των XML αρχείων. Στις μετρήσεις με πολλαπλούς πελάτες, για τον υπολογισμό του χρονικού διαστήματος καταγράφεται ο χρόνος εισαγωγής του πελάτη ο οποίος τερμάτισε τελευταίος, ο οποίος αντιπροσωπεύει και το συνολικό χρόνο ολοκλήρωσης του πειράματος. Κατά συνέπεια, το αποτέλεσμα είναι ταχύτερο σε όλες τις σχετικές μετρήσεις. Επισημαίνεται ωστόσο ότι, στις περισσότερες περιπτώσεις, η συνολική ολοκλήρωση ανέρχεται σε περισσότερο από το ένα τρίτο του χρόνου για την αντίστοιχη μέτρηση εκ μέρους ενός πελάτη. Το γεγονός αυτό οφείλεται κατά κύριο λόγο στην αφιέρωση πόρων για το χειρισμό πολλαπλών πελατών. Όλα τα αποτελέσματα και γραφικές παραστάσεις είναι διαθέσιμα στη διεύθυνση Για την παρουσίαση αυτών αναπτύχθηκε μία δικτυακή εφαρμογή, σε περιβάλλον PHP - MySQL. Η απεικόνιση των γραφικών παραστάσεων επιτελείται με τη συνδρομή της Javascript βιβλιoθήκης Highcharts 78. Παρέχεται επίσης δυνατότητα απευθείας πρόσβασης στα δεδομένα, σε JSON format, με την χρήση REST-based AJAX κλήσεων 79. Οι μετρήσεις επιτελέσθηκαν σε παραλλαγές 1, 3, 6 και 9 κόμβων. Τα σενάρια εκτέλεσης σε ένα κόμβο επιτελέσθηκαν ώστε να υπάρχει ένα σημείο αναφοράς για τη 78 Διαθέσιμη σε 79 Π.χ. %5B%5D=1&bench_db%5B%5D=2 66

67 4. Πλαίσιο Αξιολόγησης 67 βασική λειτουργία του κάθε NoSQL συστήματος. Αντικείμενο ωστόσο της εργασίας αποτελεί η διερεύνηση αρχιτεκτονικών υπολογιστικού νέφους και κατ αποτέλεσμα οι συγκεκριμένες παραμετροποιήσεις δεν είναι πρόσφορες για την ικανοποίηση αυτού του σκοπού, δεδομένου ότι δεν παρέχουν ούτε υψηλή διαθεσιμότητα ούτε δυνατότητα άμεσης επαναφοράς από καταστροφή. Εξάλλου, κάποια από τα συστήματα διατίθενται μόνο για λόγους δοκιμής σε λειτουργία ενός κόμβου (π.χ. HBase σε standalone mode), χωρίς να χρησιμοποιούν όλο το εύρος των τεχνολογιών που περιλαμβάνουν. Για το λόγο αυτό παρατίθενται αποκλειστικά για αντιπαραβολή και αγνοούνται κατά το στάδιο εξαγωγής συμπερασμάτων Cassandra Στις μετρήσεις της Cassandra με το synchronous API διαπιστώνουμε τα ακόλουθα: 1. Οι ταχύτερες μετρήσεις καταγράφηκαν σε περιβάλλον 3 κόμβων, και στις τέσσερις παραλλαγές 2. Στα σενάρια υποστήριξης εκδόσεων η προσθήκη κόμβων συνεπάγεται αισθητή αύξηση του χρόνου ολοκλήρωσης. Αντίθετα, στα σενάρια χωρίς versioning, η αύξηση από 9 σε 6 κόμβους παρουσίασε μικρή βελτίωση σε απόδοση Εικόνα 29: Μετρήσεις Cassandra με synchronous API Στις μετρήσεις της Cassandra με το asynchronous API διαπιστώνουμε τα ακόλουθα: 1. Οι ταχύτερες μετρήσεις καταγράφηκαν σε περιβάλλον 3 κόμβων, με εξαίρεση το σενάριο εισαγωγής χωρίς υποστήριξη έκδοσης από έναν πελάτη, όπου ταχύτερο αποδείχθηκε το περιβάλλον των 6 κόμβων 67

68 68 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών 2. Στα σενάρια υποστήριξης εκδόσεων η προσθήκη κόμβων συνεπάγεται αισθητή αύξηση του χρόνου ολοκλήρωσης. Αυξητική τάση παρατηρούμε και στα σενάρια χωρίς versioning, χωρίς όμως τόσο απότομες διαφορές. Εικόνα 30: Μετρήσεις Cassandra με asynchronous API Στη σύγκριση των μετρήσεων της Cassandra, μεταξύ synchronous και asynchronous API, διαπιστώνουμε τα ακόλουθα: 1. Η εισαγωγή με asynchronous API αποδείχθηκε πολύ πιο αποδοτική, της τάξης του 400% κατά μέσο όρο στα σενάρια χωρίς υποστήριξη εκδόσεων και 180% στα σενάρια με υποστήριξη εκδόσεων. Αυτό το αποτέλεσμα οφείλεται στο γεγονός ότι το σύγχρονο API μπλοκάρει άλλες λειτουργίες πελάτη έως ότου ληφθεί κάποιο αποτέλεσμα από τη βάση δεδομένων 2. Παρατηρείται ένα σενάριο όπου η εισαγωγή με synchronous API ήταν ταχύτερη. Πρόκειται για την εισαγωγή από έναν πελάτη με υποστήριξη εκδόσεων σε περιβάλλον 9 κόμβων. Τούτο καταδεικνύει την καθυστέρηση της Cassandra να αναζητήσει την ύπαρξη υπάρχουσας εγγραφής σε περιβάλλον πολλαπλών κόμβων, με αποτέλεσμα οι σχετικές μετρήσεις να καταστούν παραπλήσιες όπως συμβαίνει και στο σενάριο εισαγωγής από τρεις πελάτες με υποστήριξη εκδόσεων σε περιβάλλον 9 κόμβων 68

69 4. Πλαίσιο Αξιολόγησης 69 Εικόνα 31: Σύγκριση μετρήσεων Cassandra με synchronous και asynchronous API Το γεγονός ότι η προσθήκη κόμβων δεν οδήγησε σε γενικές γραμμές και σε αύξηση της απόδοσης αποδίδεται κατά κύριο λόγο στους σχετικά περιορισμένους πόρους κάθε εικονικού μηχανήματος σε RAM (συνολικά 4 GB) CouchDB Στις μετρήσεις της CouchDB διαπιστώνουμε τα ακόλουθα: 1. Αποδείχθηκε σε γενικές γραμμές απογοητευτικά αργή στα δεδομένα του πειράματος, σε σύγκριση με τις υπόλοιπες τεχνολογίες 2. Η προσθήκη κόμβων οδηγεί σε γραμμική άνοδο στους χρόνους ολοκλήρωσης σε όλα τα σενάρια. Αυτό οφείλεται στο γεγονός ότι ο μηχανισμός αναπαραγωγής της CouchDB έχει ως στόχο αποκλειστικά την παροχή υψηλής διαθεσιμότητας και όχι τη βελτίωση της απόδοσης. Τα δεδομένα δε διαμοιράζονται μεταξύ των κόμβων, όπως συμβαίνει σε άλλες τεχνολογίες υπολογιστικού νέφους. Αντίθετα, αναπαράγεται σε κάθε κόμβο στο σύνολό της η βάση δεδομένων 3. Σε αντίθεση με όλα τα υπόλοιπα συστήματα, οι χρόνοι ολοκλήρωσης στα σενάρια με υποστήριξη εκδόσεων είναι συντομότεροι. Αυτό παρατηρείται στις παραλλαγές τόσο με έναν όσο και με περισσότερους πελάτες, με μοναδική εξαίρεση την εισαγωγή από πολλούς πελάτες σε 9 κόμβους. Το αποτέλεσμα 80 Βλ. όπου τα 4GB ορίζονται ως ελάχιστη συνιστώμενη μνήμη RAM για τη λειτουργία της Cassandra σε περιβάλλον πολλαπλών κόμβων. Πρβλ. άρθρο Selecting hardware for enterprise implementations, διαθέσιμο σε rdware_c.html 69

70 70 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών αυτό εξηγείται από το γεγονός ότι χρησιμοποιήθηκε ο μηχανισμός εγγενούς υποστήριξης versioning της CouchDB, δυνάμει του οποίου ανευρίσκεται με ταχύτητα η ύπαρξη ίδιας εγγραφής. Στη συνέχεια η ενημέρωση της εγγραφής αποδεικνύεται ταχύτερη από την εισαγωγή νέας. Εικόνα 32: Μετρήσεις CouchDB HBase Στις μετρήσεις της HBase διαπιστώνουμε τα ακόλουθα: 1. Ταχύτερη συνολικά αποδείχθηκε η εισαγωγή σε περιβάλλον 9 κόμβων από πολλαπλούς πελάτες χωρίς υποστήριξη έκδοσης 2. Η προσθήκη κόμβων συνεπάγεται μικρή αύξηση στους χρόνους ολοκλήρωσης στα σενάρια εισαγωγής από έναν πελάτη. Το αποτέλεσμα αυτό προκύπτει από το πρόσθετο κόστος διαχείρισης των επιπλέον κόμβων 3. Η προσθήκη κόμβων συνεπάγεται μικρή μείωση στους χρόνους ολοκλήρωσης στα σενάρια εισαγωγής από πολλαπλούς πελάτες, στις παραλλαγές χωρίς υποστήριξη εκδόσεων. Αντίθετα, παρατηρείται μικρή άνοδος στις παραλλαγές με versioning. 70

71 4. Πλαίσιο Αξιολόγησης 71 Εικόνα 33: Μετρήσεις HBase Το γεγονός ότι η προσθήκη κόμβων δεν οδήγησε σε γενικές γραμμές και σε αύξηση της απόδοσης αποδίδεται κατά κύριο λόγο στους σχετικά περιορισμένους πόρους κάθε εικονικού μηχανήματος σε RAM (συνολικά 4 GB) 81. Υπενθυμίζεται ότι λειτουργία της HBase προϋποθέτει τη λειτουργία των λογισμικών Hadoop και Zookeeper, γεγονός που εξηγεί τις υψηλές απαιτήσεις σε πόρους MongoDB Στις μετρήσεις της MongoDB διαπιστώνουμε τα ακόλουθα: 1. Ταχύτερη συνολικά αποδείχθηκε η εισαγωγή σε περιβάλλον 9 κόμβων από πολλαπλούς πελάτες χωρίς υποστήριξη έκδοσης 2. Η προσθήκη κόμβων συνεπάγεται μικρή μείωση στους χρόνους ολοκλήρωσης στα σενάρια εισαγωγής από έναν πελάτη. Το αποτέλεσμα αυτό εξηγείται από το γεγονός ότι στο περιβάλλον πολλαπλών κόμβων ενυπάρχουν περισσότερα shards στο σύστημα, τα οποία διαμοιράζονται τις εγγραφές προς εισαγωγή 3. Η προσθήκη κόμβων έχει ως αποτέλεσμα αισθητή αύξηση στους χρόνους ολοκλήρωσης στα σενάρια με υποστήριξη έκδοσης, με εισαγωγή από έναν ή περισσότερους πελάτες. Τούτο οφείλεται στο γεγονός ότι ο μηχανισμός sharding της MongoDB διασπά τις εγγραφές και τις διαμοιράζει μεταξύ των κόμβων, με βάση το ορισθέν κλειδί κατακερματισμού. Κατά συνέπεια, όσο 81 Βλ. αναλυτικά άρθρο How-to: Select the Right Hardware for Your New Hadoop Cluster, Kevin O'Dell, 28/08/2013, διαθέσιμο σε όπου συνίσταται RAM άνω των 16GB. 71

72 72 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών περισσότερα τα shards, τόσα περισσότερα τα τμήματα στα οποία απαιτείται να λάβει χώρα η ανεύρεση της τυχόν υπάρχουσας καταχώρησης Εικόνα 34: Μετρήσεις MongoDB Σύγκριση Μετρήσεων Στη συγκεντρωτική παράθεση των μετρήσεων, στο σύνολο των παραλλαγών, διαπιστώνουμε ότι οι χρόνοι ολοκλήρωσης των εισαγωγών στην CouchDB υστερούν σε τέτοιο βαθμό ώστε να καθίστανται μη συγκρίσιμοι. Εικόνα 35: Συνολική παρουσίαση μετρήσεων Στη συγκεντρωτική παράθεση των μετρήσεων, στο σύνολο των παραλλαγών, αφαιρώντας την CouchDB και την Cassandra σε synchronous API, διαπιστώνουμε τα ακόλουθα: 1. Ταχύτερο συνολικά χρόνο εισαγωγής σε σενάρια χωρίς υποστήριξη έκδοσης κατέγραψε η MongoDB (274 δευτερόλεπτα). Επιτεύχθηκε σε περιβάλλον 9 κόμβων από πολλαπλούς πελάτες. Ακολούθησε η Cassandra, σε σύνδεση μέσω του asynchronous API, με 331 δευτερόλεπτα, σε περιβάλλον 6 κόμβων 72

73 4. Πλαίσιο Αξιολόγησης Ταχύτερο συνολικά χρόνο εισαγωγής σε σενάρια με υποστήριξη έκδοσης κατέγραψε η MongoDB (614 δευτερόλεπτα). Επιτεύχθηκε σε περιβάλλον 3 κόμβων από πολλαπλούς πελάτες. Ακολούθησε η Cassandra, σε σύνδεση μέσω του asynchronous API με 971 δευτερόλεπτα, σε περιβάλλον 3 κόμβων 3. Στα σενάρια με υποστήριξη έκδοσης αποδείχθηκε πιο σταθερή στην προσθήκη κόμβων η HBase. Κατέγραψε παραπλήσιους χρόνους ολοκλήρωσης, σε αντίθεση με τις MongoDB και Cassandra, οι οποίες παρουσίασαν σημαντική αύξηση. Μάλιστα σε περιβάλλον 9 κόμβων αποδείχθηκε πιο γρήγορη από την Cassandra. Εικόνα 36: Συγκεντρωτικές Μετρήσεις χωρίς CouchDB και Cassandra με synchronous API Στη συγκεντρωτική παράθεση των μετρήσεων εισαγωγής από έναν πελάτη χωρίς υποστήριξη εκδόσεων, αφαιρώντας την CouchDB, διαπιστώνουμε τα ακόλουθα: 1. Ταχύτερο συνολικά χρόνο εισαγωγής κατέγραψε η Cassandra, σε σύνδεση μέσω του asynchronous API (465 δευτερόλεπτα). Επιτεύχθηκε σε περιβάλλον 3 κόμβων. Ακολούθησε η MongoDB, με 500 δευτερόλεπτα, σε περιβάλλον 9 κόμβων 2. Η προσθήκη κόμβων είχε ως αποτέλεσμα την αύξηση του χρόνου ολοκλήρωσης σε Cassandra και HBase, σε αντίθεση με τη MongoDB 73

74 74 Μελέτη χρήσης Αρχιτεκτονικών Cloud επί αποθετηρίου ψηφιακών βιβλιοθηκών Εικόνα 37: Συγκεντρωτικές μετρήσεις multi-node, με single client & χωρίς versioning Στη συγκεντρωτική παράθεση των μετρήσεων εισαγωγής από έναν πελάτη με υποστήριξη εκδόσεων, αφαιρώντας την CouchDB, διαπιστώνουμε τα ακόλουθα: 1. Ταχύτερο συνολικά χρόνο εισαγωγής κατέγραψε η MongoDB (650 δευτερόλεπτα). Επιτεύχθηκε σε περιβάλλον 3 κόμβων. Ακολούθησε η Cassandra, σε σύνδεση μέσω του asynchronous API, με 1093 δευτερόλεπτα, πάλι σε περιβάλλον 3 κόμβων 2. Η προσθήκη κόμβων είχε ως αποτέλεσμα την αισθητή αύξηση του χρόνου ολοκλήρωσης σε Cassandra και MongoDB, σε αντίθεση με την HBase Εικόνα 38: Συγκεντρωτικές μετρήσεις multi-node, με single client & versioning Στη συγκεντρωτική παράθεση των μετρήσεων εισαγωγής από πολλαπλούς πελάτες χωρίς υποστήριξη εκδόσεων, αφαιρώντας την CouchDB, διαπιστώνουμε τα ακόλουθα: 1. Ταχύτερο συνολικά χρόνο εισαγωγής κατέγραψε η MongoDB (274 δευτερόλεπτα). Επιτεύχθηκε σε περιβάλλον 9 κόμβων. Ακολούθησε η Cassandra, σε σύνδεση μέσω του asynchronous API, με 332 δευτερόλεπτα, σε περιβάλλον 6 κόμβων 74

75 4. Πλαίσιο Αξιολόγησης Η προσθήκη κόμβων είχε ως αποτέλεσμα τη βελτίωση της επίδοσης στο σύνολο των συστημάτων, με εξαίρεση την Cassandra, σε σύνδεση μέσω του asynchronous API Εικόνα 39: Συγκεντρωτικές μετρήσεις multi-node, με multi-client & χωρίς versioning Στη συγκεντρωτική παράθεση των μετρήσεων εισαγωγής από πολλαπλούς πελάτες χωρίς υποστήριξη εκδόσεων, αφαιρώντας την CouchDB, διαπιστώνουμε τα ακόλουθα: 1. Ταχύτερο συνολικά χρόνο εισαγωγής κατέγραψε η MongoDB (614 δευτερόλεπτα). Επιτεύχθηκε σε περιβάλλον 3 κόμβων. Ακολούθησε η Cassandra, σε σύνδεση μέσω του asynchronous API με 971 δευτερόλεπτα, πάλι σε περιβάλλον 3 κόμβων 2. Η προσθήκη κόμβων είχε ως αποτέλεσμα την αισθητή αύξηση του χρόνου ολοκλήρωσης σε Cassandra και MongoDB, σε αντίθεση με την HBase Εικόνα 40: Συγκεντρωτικές μετρήσεις multi-node, με multi-client & versioning 75