Ιστορία ACID CAP Theorem Eventual consistency και BASE Enter NoSQL Χαρακτηριστικά NoSQL βάσεων NoSQL taxonomy Ρολόγια Lamport 2
Flat Model Network Model Dimensional Model Hierarchical Model Object Model Relational Model RDBMS 3
Συναλλαγές (Transactions) ACID Ατομικότητα (Atomicity όλη η συναλλαγή ή καθόλου) Συνέπεια (Consistency από μία consistent κατάσταση σε μία άλλη) Απομόνωση (Isolation - απαγόρευση πρόσβασης σε δεδομένα συναλλαγής που δεν έχει ολοκληρωθεί) Durability (Διάρκεια μπορεί να ανακτήσει την προηγούμενη κατάσταση μετά από όλες τις committed συναλλαγές) 4
Διαφορετικές ανάγκες των Web συστημάτων από αυτές που καλύπτουν τα RDBMS ACID απαιτήσεις (replication ) Οριζόντιος καταμερισμός vs Normalization Καθυστέρηση: Χαμηλοί και Προβλέψιμοι Χρόνοι Απόκρισης Flexible Schemas/ Αδόμητα ή Ημιδομημένα Δεδομένα Πολλά Datacenters κατανεμημένα σε όλο τον κόσμο. Κλιμακωσιμότητα Υψηλή Διαθεσιμότητα (availability) 5
Συνέπεια Όλοι να βλέπουν τις ίδιες εκδόσεις δεδομένων Διαθεσιμότητα Σύστημα πάντα διαθέσιμο ανεξάρτητα από αποτυχίες κόμβων, αλλαγές H/W-S/W, κλειδώματα. 99,9% (three nines)= το πολύ 8,76 ώρες τον χρόνο εκτός λειτουργίας Κάθε ενέργεια πρέπει να τερματίσει «σωστά» Διαμοιρασμός Οι ενέργειες πρέπει να ολοκληρωθούν ακόμα και εάν ορισμένα server κομμάτια είναι down 6
Συνέπεια Όλοι να βλέπουν τις ίδιες εκδόσεις δεδομένων Διαθεσιμότητα Σύστημα πάντα διαθέσιμο ανεξάρτητα από αποτυχίες κόμβων, αλλαγές H/W-S/W, κλειδώματα. 99,9% (three nines)= το πολύ 8,76 ώρες τον χρόνο εκτός λειτουργίας Κάθε ενέργεια πρέπει να τερματίσει «σωστά» Διαμοιρασμός Οι ενέργειες πρέπει να ολοκληρωθούν ακόμα και εάν ορισμένα server κομμάτια είναι down CAP Theorem: Μπορούμε να έχουμε μόνο δύο από τα τρία. 7
CA Μικρά τοπικά δίκτυα ή πολύ μικρά clusters, με μικρό partitioning στα δεδομένα. Εγγύηση για μεγάλο availability και για consistency Δύσκολη κλιμάκωση CP Δεδομένα μη προσβάσιμα συνεχώς, αλλά έχουμε συνέπεια και αντοχή στην κλιμάκωση AP Δεδομένα συνεχώς διαθέσιμα με κίνδυνο να μην είναι ενημερωμένα. Eventual Consistency 8
CA Μικρά τοπικά δίκτυα ή πολύ μικρά clusters, με μικρό partitioning στα δεδομένα. Εγγύηση για μεγάλο availability και για consistency Δύσκολη κλιμάκωση (παραδοσιακά RDBMS) CP Δεδομένα μη προσβάσιμα συνεχώς, αλλά έχουμε συνέπεια και αντοχή στην κλιμάκωση AP Δεδομένα συνεχώς διαθέσιμα με κίνδυνο να μην είναι ενημερωμένα. Eventual Consistency Η περίπτωση των περισσότερων NoSQL συστημάτων 9
10
Three phase commit coordinator Data server 1 Data server 2 Can commit? Ναι/Όχι Pre-commit ACK Commit Όλο αυτό: Αργεί Μπορεί να μην εκτελεστεί καθόλου αν οπουδήποτε υπάρξει σφάλμα Το availability είναι το γινόμενο των availabilities των επιμέρους συστημάτων Ο brewer έχει δίκιο: 99,9%*99,9=99,8% 11
12
Μετά την ενημέρωση, όλες οι επόμενες προσβάσεις από τους πελάτες θα φέρουν την τελευταία τιμή 13
Το σύστημα δεν εγγυάται ότι σε οποιαδήποτε μεταγενέστερη χρονική στιγμή από την ενημέρωση η πρόσβαση θα επιστρέφει την νέα τιμή 14
Εάν δεν γίνουν άλλες ενημερώσεις στο αντικείμενο, το σύστημα eventually (μετά από well defined χρόνο t) θα επιστρέφει την τελευταία τιμή 15
Οι τιμές είναι consistent μεταξύ συνεργαζόμενων clients (Α και Β) Επόμενη πρόσβαση του Β θα επιστρέψει την νέα τιμή, και μια εγγραφή εγγυάται ότι θα υπερισχύσει της νεότερης εγγραφής 16
Ο Α ενημερώνει το αντικείμενο και κατόπιν βλέπει άμεσα τις αλλαγές και δεν παίρνει ποτέ πίσω παλιές τιμές Παράδειγμα: Facebook status update Sticky clients: «κολλάνε» όλες τους τις συναλλαγές με έναν server του cluster 17
Στο ίδιο session το σύστημα εξασφαλίζει read your writes consistency 18
Εάν ένας πελάτης έχει πάρει μια συγκεκριμένη τιμή ενός αντικειμένου, όλες οι επόμενες προσβάσεις δεν θα επιστρέψουν ποτέ παλαιότερες εκδόσεις. 19
Το σύστημα εξασφαλίζει την σειριοποίηση εγγραφών του ίδιου πελάτη/process. 20
Το transaction τελειώνει όταν πάρει το αντικείμενο μόνο ο primary Οι replica servers το παίρνουν αργότερα ασύγχρονα 21
NRW N: Αριθμός των κόμβων που περιέχουν replica W: Αριθμός των replica κόμβων που πρέπει να επιβεβαιώσουν την λήψη της ενημέρωσης πριν την ολοκλήρωση της ενημέρωσης R: Ο αριθμός των replicas που γίνονται contact όταν ένα αντικείμενο ανακτάται κατά ένα read operation 22
23
Βελτιστοποίηση read: R=1, N=W Βελτιστοποίηση write: W=1, N=R 24
Υλοποίηση read-your-writes και monotonic reads με την προσθήκη εκδόσεων στα writes και αγνοώντας οτιδήποτε προηγείται της τελευταίας γνωστής έκδοσης 25
BASE = η άλλη άποψη του ACID Basically Available Διαθέσιμοι οι πόροι σχεδόν πάντα, αλλά όχι πάντα Soft-State, Scalable Όχι από κατάσταση σε κατάσταση με transactions Eventually Consistent Συνέπεια που θα επέλθει στο χρόνο αλλά με περιπτώσεις μη-συνέπειας συχνές. Ενημέρωση αντιγράφων κλπ 26
Δυο γεγονότα δεν είναι πάντα χρονικά ταξινομημένα σε ένα κατανεμημένο σύστημα. Μόνο η σειρά γεγονότων που έχουν σχέση αιτίας/αποτελέσματος έχει σημασία. Εμπνευσμένο από την ειδική θεωρία της σχετικότητας του A. Einstein. Υλοποίηση με λογικά ρολόγια (logical clocks) 27
Αντιστοίχηση ακολουθίας αριθμών σε μηνύματα Όλες οι συμμετέχοντες διεργασίες μπορούν να συμφωνήσουν σε μια σειρά με την οποία έγιναν τα γεγονότα Αντίθετα με τα φυσικά ρολόγια (physical clocks): συγκεκριμένη ώρα Δεν θεωρούμε μια κεντρική αρχή που λέει την ώρα Το κάθε σύστημα/διεργασία έχει το δικό του ρολόι. Όχι συνολική ταξινόμηση γεγονότων Δεν υπάρχει η έννοια του πότε έγινε κάτι αλλά, ποιο από τα δύο έγινε πρώτο?
Ένα λογικό ρολόι είναι ένας μηχανισμός για τη καταγραφή χρονολογικών σχέσεων και σχέσεων που έχουν σχέση αιτίας/αποτελέσματος Υλοποίηση ενός ρολογιού Δομή δεδομένων Πρωτόκολλο ενημέρωσης ρολογιού Σημαντικοί αλγόριθμοι λογικών ρολογιών είναι αυτοί που βασίζονται σε Μονοδιάστατα ρολόγια Διανυσματικά ρολόγια
Εισαγωγή της έννοιας του λογικού χρόνου αντί για τον απόλυτο χρόνο Μερική διάταξη των γεγονότων σε σχέση με την σειρά εμφάνισης Causally Related Events Εάν το γεγονός Α έγινε πριν από το γεγονός Β, τότε το Α επηρεάζει το Β. Ταυτόχρονα γεγονότα Δυο διαφορετικά γεγονότα Α και Β είναι ταυτόχρονα (concurrent) εάν το Α δεν έγινε πριν το Β και το Β δεν έγινε πριν το Α. Δηλαδή τα γεγονότα δεν συνδέονται με κάποια σχέση αιτίας/αποτελέσματος. Επέκταση της σχέσης Happens Before για μια συνεπή ολική διάταξη στον χρόνο σε ένα κατανεμημένο σύστημα. Παράδειγμα: make utility χρόνοι δημιουργίας του input.c and input.o
Ο Lamport παρουσίασε ένα σύστημα λογικών ρολογιών με σκοπό τον σωστό ορισμό της σχέσης happened before Η κάθε διεργασία P έχει το δικό της ρολόι C. Για κάθε γεγονός a σε μια διεργασία, το C μπορεί να θεωρηθεί μια συνάρτηση που θέτει έναν αριθμό C(a) ο οποίος είναι μια χρονοσφραγίδα (timestamp) του γεγονότος a στην διεργασία P. Οι αριθμοί αυτοί δεν έχουν καμία σχέση με τον φυσικό χρόνο για αυτό λέγονται λογικά ρολόγια.
Εάν το a και b είναι δυο γεγονότα της ίδιας διεργασίας, και το a έγινε πριν το b τότε ισχύει a -> b. Εάν το a είναι το αποτέλεσμα της αποστολής ενός μηνύματος από μια διεργασία και b είναι το αποτέλεσμα της λήψης του μηνύματος από μια άλλη διεργασία τότε a -> b. Εάν a -> b και b -> c, ισχύει a -> c. Εάν a (not) -> b και b (not) -> a, τότε τα a και b είναι concurrent (ταυτόχρονα). Eάν τα a και b συμβούν σε διαφορετικές διεργασίες που δεν ανταλλάσουν μηνύματα, τότε ούτε a -> b ούτε b -> a
Πως πετυχαίνουμε ένα συνεπές σετ από λογικά ρολόγια, ένα για κάθε διαδικασία?
E1/E2 είναι sending/receipt του ίδιου μηνύματος, τότε E1 -> E2, πχ A2 -> B4. E1 -> E2 and E2 -> E3 then E1 -> E3, πχ. A1 B4. Ταυτόχρονα: A2 και B3, B4 και C2.
3 συστήματα: P 0, P 1, P 2 Γεγονότα a, b, c, Τοπικός μετρητής γεγονότων σε κάθε σύστημα Περιστασιακά τα συστήματα επικοινωνούν
a b c d e f P 1 1 2 3 g 4 5 6 h i P 2 j 1 2 3 k P 3 1 2
a b c d e f P 1 1 2 3 g 4 5 6 h i P 2 j 1 2 3 k P 3 1 2 Λάθος σειρά: e h f k
a b c d e f P 1 1 2 3 g 4 5 6 h i P 2 j 1 2 7 6 k P 3 1 2 7
Ο αλγόριθμος χρειάζεται έναν μονότονα αυξανόμενο counter Αύξηση του counter τουλάχιστον κάθε φορά που χρειάζεται μια χρονοσφραγίδα Κάθε γεγονός έχει μια χρονοσφραγίδα Lamport Για 2 γεγονότα a b ισχύει: L(a) < L(b)
a b c d e f P 1 1 2 3 g 4 5 6 h i P 2 j 1 6 7 k P 3 1 7 a b, b c, : Τα τοπικά γεγονότα μπαίνουν σε σειρά i c, f d, d g, : Ο Lamport βάζει σε σειρά send receive γεγονότα Ταυτόχρονα γεγονότα (πχ, a & j) μπορεί να έχουν την ίδια χρονοσφραγίδα ή όχι
Μπορούμε να θέσουμε κάθε χρονοσφραγίδα να είναι μοναδική Έστω καθολική λογική χρονοσφραγίδα (T i, i) Το T i είναι μια τοπική χρονοσφραγίδα Το i δείχνει το id της διεργασίας (καθολικά μοναδικό) Πχ(διεύθυνση IP, ID διεργασίας) Σύγκριση χρονοσφραγίδων: (T i, i) < (T j, j) Εάν και μόνο εάν T i < T j ή T i = T j και i < j Αυθαίρετη ταξινόμηση των διεργασιών.
a b c d e f P 1 1.1 2.1 3.1 g 4.1 5.1 6.1 h i P 2 j 1.2 6.2 7.2 k P 3 1.3 7.3
Updating a replicated database and leaving it in an inconsistent state.
Υπέρ Παίρνουμε μια ολική ταξινόμηση των γεγονότων στο σύστημα, χρησιμοποιώντας μόνο την σχέση αιτίας/αποτελέσματος. Χρειάζεται μόνο ένας integer ανά διεργασία. Κατά Clocks are not strongly consistent: clocks lose track of the timestamp of the event on which they are dependent on. This is because we are using a single integer to store the local and logical time.
Causality If a->b then event a can affect event b Concurrency If neither a->b nor b->a then one event cannot affect the other Partial Ordering Causal events are sequenced Total Ordering All events are sequenced Υπέρ : Παίρνουμε μια ολική ταξινόμηση των γεγονότων στο σύστημα, χρησιμοποιώντας μόνο την σχέση αιτίας/αποτελέσματος. Μόνο ένας int ανά process
Πρακτικά θέλουμε να αλλάξουμε το μοντέλο των βάσεων δεδομένων από τις σχεσιακές σε κάτι πιο Κλιμακώσιμο Διαθέσιμο No SQL = όχι SQL, την πετάμε Ν ο SQL = όχι μόνο SQL, χρειαζόμαστε κι άλλα για διαφορετικές εφαρμογές Για την ακρίβεια πιο σωστός όρος το NoRel = όχι στο σχεσιακό μοντέλο Υπάρχει και ο όρος NoACID Δεν έχουμε σχέσεις -> key, value ζευγάρια Value μπορεί να είναι οτιδήποτε, από ένα value ή πολλά columns, μέχρι αρχεία 52
Διαφορετικές όψεις στη Συνέπεια ανάλογα με προσέγγιση Schema-less Βασισμένες σε Consistent Hashing και κάποια DHT-like δομή. Πλήρως συνδεδεμένο δίκτυο. Ερωτήματα μεταφράζονται συνήθως σε MapReduce jobs υποστήριση απλού get/select key αποφεύγουν τα δύσκολα ερωτήματα, δύσκολα τα υλοποιούν 53
000000 Insert key The Dark Knight md5( The Dark Knight ) = 36b123 123fa2 a540ac 36b123 8976c1 42fb2a 54
Κάθε κόμβος είναι υπεύθυνος για ένα μέρος του namespace. Πολλοί τρόποι να γίνει αυτό Συνήθως κάθε κόμβος λαμβάνει ένα μέρος του key space Πλήρως συνδεδεμένο δίκτυο Κάθε κόμβος γνωρίζει κάθε άλλον 55
Κλασσική τακτική στα κατανεμημένα συστήματα Χρησιμοποιείται εκτενώς και στα Key Value Stores Κυρίως για ανίχνευση νέων κόμβων, σφαλμάτων... Μετάδοση της κατάστασης του δικτύου Προσφέρει eventual consistency 56
57
Με Consistent Hashing ξέρουμε που θα αποθηκευτεί το κάθε αντικείμενο Τα πράγματα δεν είναι τόσο απλά γιατί: Κάθε κόμβος μπορεί να έχει πολλές θέσεις στο δακτύλιο Θέμα: Που θα αποθηκευτούν τα αντίγραφα? Είσοδος/Έξοδος κόμβων στο δίκτυο Θέμα: Πως θα έχω εξισορρόπηση φόρτου? Κάθε προσέγγιση έχει Τους δικούς της στόχους Τα δικά της προβλήματα Τις δικές της λύσεις 58
Στο http://nosql-database.org/ Πάνω από 100 συστήματα NoSQL βάσεων δεδομένων Οι μεγάλες κατηγορίες Key-Value Stores Column Stores Document Stores Graph Databases 59
Key-Value Stores Τα structured P2P συστήματα DHTs Προσφέρουν απλά key lookups Κυριότερα: Dynamo Voldemort, KAI, Dynomite (open source Dynamo) Azure Riak Redis Tokyo Cabinet 60
Row Stores Αποθήκευση με βάση το Row key Εύκολη αποθήκευση Τοπικότητα Column Stores Αποθήκευση με βάση το Column Λίστες με τις τιμές των columns Συμφέρει όταν θέλω να προσπελάσω ένα column αντί για όλο το row Τα Column Stores που συζητάμε εδώ κάνουν κάτι το ενδιάμεσο Γιώργος 5 Α Γιάννης 6 Β Δημήτρης 9 Α Γιώργος Γιάννης Δημήτρης 5 6 9 Α Β Α 61
Οι περισσότεροι τα λένε column stores Στην πραγματικότητα είναι υβριδικό. 62
Key που καθορίζει το row, και το που θα γίνει η αποθήκευση Value που αποτελείται από πολλά columns ή column families και πολλές τιμές για το καθένα Κυριότερα BigTable Hbase, Hypertable Cassandra SimpleDB 63
Id Ηθοποιός Ημ.γέννησης 1234 Christian Bale 30-1-1974 5678 Natalie Portman 9-6-1981 9012 Melissa Leo 14-9-1960 3456 Colin Firth 10-9-1960 Id Ταινία Έτος 1 The Dark Knight 2008 2 King s Speech 2010 3 The Fighter 2010 4 Black Swan 2010 5 The Prestige 2006 Ηθοπ Ταινία 1234 1 1234 3 1234 5 5678 4 9012 3 3456 2 Key value The Dark Knight Ηθοποιοί: Christian Bale Έτος: 2008 King s Speech Ηθοποιοί: Colin Firth Έτος: 2010 The Fighter Ηθοποιοί: Melissa Leo, Έτος: 2010 Christian Bale Black Swan Ηθοποιοί: Natalie Portman Έτος: 2010 The Prestige Ηθοποιοί: Christian Bale Έτος: 2006 Christian Bale Ημ.Γέννησης: 30-1-1974
Document Stores CouchDB MongoDB TerraStore Graph Databases Neo4J HyperGraphDB Sones InfoGrid 65
66
Πλεονεκτήματα Κλιμακωσιμότητα Υψηλή διαθεσιμότητα Χαμηλό κόστος Ευελιξία στο Σχήμα, Ημιδομημένα δεδομένα Μειονεκτήματα Δυνατότητες σε ερωτήματα Standardization Συνέπεια και eventual Consistency Σύνθετα ερωτήματα Πολύ ερευνητική δουλειά για την υποστήριξή τους σε NoSQL περιβάλλοντα Περίπλοκα προγράμματα (σε σχέση με τα RDBMS) Hive, Pig 67
A Comparison of Approches to Large-Scale Data Analysis. Andrew Pavlo, Erik Paulson, Alexander Rasin, Daniel J Abadi, David J. DeWitt, Samuel Madden and Michael Stonebraker. SIGMOD 2009 BASE: An Acid Alternative, ACM Queue, Volume 6 Issue 3, May/June 2008 Eric A. Brewer. Towards Robust Distributed Systems. (Invited Talk) Principles of Distributed Computing (PODC), Portland, Oregon, July 2000. http://www.julianbrowne.com/article/viewer/brewers -cap-theorem http://www.royans.net/arch/brewers-cap-theoremon-distributed-systems/ 68
W. Vogels, Amazon s vice president and CTO Eventually consistent, Communications of the ACM, vol. 52, no. 1, pp. 40 44, 2009. http://queue.acm.org/detail.cfm?id=146644 8 http://dbmsmusings.blogspot.com/2010/08 /problems-with-acid-and-how-to-fixthem.html http://blog.nahurst.com/visual-guide-tonosql-systems 69
http://en.wikipedia.org/wiki/lamport_timest amps Lamport, L. (1978). "Time, clocks, and the ordering of events in a distributed system". Communications of the ACM 21 (7): 558 565. http://research.microsoft.com/users/lamport/pubs /time-clocks.pdf 70