ACID, CAP, BASE και Eventual Consistency

1. ACID, CAP, BASE και Eventual Consistency Ιωάννης Κωνσταντίνου

2. Περιεχόμενα • Ιστορία • ACID • CAP Theorem • Eventual consistency και BASE • Enter NoSQL • Χαρακτηριστικά NoSQLβάσεων • NoSQL taxonomy

3. Μοντέλα βάσεων δεδομένων RDBMS Flat Model Network Model Dimensional Model Hierarchical Model Object Model Relational Model

4. RDBMS ιδιότητες • Συναλλαγές (Transactions) • ACID • Ατομικότητα (Atomicity – όλη η συναλλαγή ή καθόλου) • Συνέπεια (Consistency – από μία consistent κατάσταση σε μία άλλη) • Απομόνωση (Isolation - απαγόρευση πρόσβασης σε δεδομένα συναλλαγής που δεν έχει ολοκληρωθεί) • Durability (Διάρκεια – μπορεί να ανακτήσει την προηγούμενη κατάσταση μετά από όλες τις committed συναλλαγές)

5. Παράδειγμα 1/3 • Έστω 2 συναλλαγές (Xacts) • T1: BEGIN A=A+100, B=B-100 END • T2: BEGIN A=1.06*A, B=1.06*B END • H T1 μεταφέρει 100 ευρώ από τον λογαριασμό Β στον Α • Η Τ2 δίνει 6% τόκο και στους δυο λογαριασμούς • Δεν υπάρχει εγγύηση ότι η Τ1 θα τρέξει πριν από την Τ2 εάν γίνουν ταυτόχρονα • Το αποτέλεσμα πρέπει να είναι το ίδιο όταν αυτές τρέξουν ταυτόχρονα

6. Παράδειγμα 2/3 • Έστω το παρακάτω interleaving schedule: • Και έστω και αυτό: • Η βάση στο Τ2 βλέπει: T1: A=A+100,B=B-100 T2: A=1.06*A, B=1.06*B T1: A=A+100,B=B-100 T2:A=1.06*A, B=1.06*B T1: R(A), W(A),R(B), W(B) T2:R(A), W(A), R(B), W(B)

7. Παράδειγμα 3/3 • Το δεύτερο είναι λάθος!!!! • Γράφος dependencies • Ένας κόμβος ανά συναλλαγή. Βέλος από το Ti στο Tjεάν το Tjδιαβάζει ή γράφει ένα αντικείμενο που γράφτηκε από το Ti. • Ο κύκλος είναι το πρόβλημα: Το αποτέλεσμα του Τ1 εξαρτάται από το Τ2 και αντίθετα T1: R(A), W(A),R(B), W(B) T2:R(A), W(A), R(B), W(B) A T1 T2 B

8. Δημιουργώντας transaction schedules • Equivalent schedules: Για κάθε κατάσταση της βάσης, το αποτέλεσμαστα αντικείμενα της εκτέλεσης του πρώτου σχεδίου είναι το ίδιο με την εκτέλεση του δεύτερου • Serializable schedule: Ένα schedule είναι equivalent με κάποια σειριακή εκτέλεση συναλλαγών. • Εάν το dependency graph ενός schedule είναι acyclic, το schedule λέγεται conflict serializableκαι είναι equivalent με ένα σειριακό schedule. • Τυπική (αλλά όχι απαραίτητη) συνθήκη που επιβάλλεται σε μια βάση για serializability.

9. Επιβάλλοντας serializability • Two-phase Locking (2PL) πρωτόκολλο: • ΚάθεXactπρέπει να πάρειέναS (shared) lockστο αντικείμενο πριν από read,και έναX (exclusive) lock πριν από write. • Όταν έναXactελευθερώσει ένα lock, δεν επιτρέπεται να πάρει άλλα locks. • Όταν έναXactέχει ένα X lock σε ένα αντικείμενο, κανένα άλλοXactδεν μπορεί να πάρει lock (S or X) σε αυτό το αντικείμενο. • 2PL επιτρέπει μόνο conflict-serializable schedules. • deadlock: Σκοτώνουμε τυχαία ένα transaction και ελευθερώνουμε τα locks του.

10. Ατομικότητα συναλλαγών • Μια συναλλαγή μπορεί να κάνει commitόταν έχει ολοκληρώσει τις ενέργειές της ή να κάνει abort όταν έχει ολοκληρώσει μερικές από τις ενέργειές της. • Οι ΒΔ εξασφαλίζουν ότι όλες οι συναλλαγές είναι atomic: Ο χρήστης τις βλέπει σαν να εκτελούνται σε ένα βήμα, ή σαν να μην εκτελούνται καθόλου. • Οι βάσεις κρατάνε σε log τις ενέργειες έτσι ώστε να μπορούν να κάνουν undo σε περίπτωση abort. • Αυτό εξασφαλίζει ότι εάν έναXactείναι συνεπές (consistency), τότεκάθε serializable schedule είναι consistent.

11. Aborting a transaction 1/2 • Εάν έχουμε ένα abort της Ti πρέπει όλα τα actions να ακυρωθούν, και εάν η Tjέχει διαβάσει ένα αντικείμενο που έχει αλλαχθεί από την Tjπρέπει να ακυρωθεί και αυτή!! (cascading abort) • Τα συστήματα το αποφεύγουν ελευθερώνοντας τα locks μόνο κατά το commit • Εάν η Τiγράψει ένα αντικείμενο, η Tjμπορεί να το διαβάσει μόνο όταν η Ti κάνει commit

12. Aborting a transaction 2/2 • Για να κάνει μια βάση undo, διατηρεί ένα log που καταγράφει όλα τα writes. Σε περίπτωση crash χρησιμοποιείται αυτό το log για να επαναφέρει την βάση σε consistent state: όλα τα active Xactsκατά την στιγμή του crash γίνονται abort

13. WAL (write ahead log) • Οι παρακάτω ενέργειες καταγράφονται στο log • H Ti κάνει write ένα αντικείμενο: την παλιά και την καινούρια τιμή. • Η εγγραφή πάει στον δίσκο πριν την αλλαγή!! • H Ti κάνει commit/abort: μια εγγραφή στο log που δείχνει την ενέργεια αυτή. • Συνήθως οι xactsγκρουπάρονται ανά xact id για να γίνεται εύκολα το abort. • Διατήρηση αντιγράφων του log στον δίσκο. • Γίνεται διαφανώς από την βάση.

14. Γιατί δεν μας κάνει το RDBMS? • Διαφορετικές ανάγκες των Web συστημάτων από αυτές που καλύπτουν τα RDBMS • ACID απαιτήσεις(replication …) • Οριζόντιος καταμερισμόςvs Normalization • Καθυστέρηση: Χαμηλοί και Προβλέψιμοι Χρόνοι Απόκρισης • Flexible Schemas/ Αδόμητα ή Ημιδομημένα Δεδομένα • Πολλά Datacenters κατανεμημένα σε όλο τον κόσμο. • Κλιμακωσιμότητα • Υψηλή Διαθεσιμότητα (availability)

15. Γιατί να μην τα έχουμε όλα? Συνέπεια Consistency Διαθεσιμότητα Availability • Συνέπεια • Όλοι να βλέπουν τις ίδιες εκδόσεις δεδομένων • Διαθεσιμότητα • Σύστημα πάντα διαθέσιμο ανεξάρτητα από αποτυχίες κόμβων, αλλαγές H/W-S/W, κλειδώματα. • 99,9% (three nines)= το πολύ 8,76 ώρες τον χρόνο εκτός λειτουργίας • Κάθε ενέργεια πρέπει να τερματίσει «σωστά» • Διαμοιρασμός • Οι ενέργειες πρέπει να ολοκληρωθούν ακόμα και εάν ορισμένα server κομμάτια είναι down Διαμοιρασμός Partition Tolerance

16. Γιατί να μην τα έχουμε όλα? Συνέπεια Consistency Διαθεσιμότητα Availability • Συνέπεια • Όλοι να βλέπουν τις ίδιες εκδόσεις δεδομένων • Διαθεσιμότητα • Σύστημα πάντα διαθέσιμο ανεξάρτητα από αποτυχίες κόμβων, αλλαγές H/W-S/W, κλειδώματα. • 99,9% (three nines)= το πολύ 8,76 ώρες τον χρόνο εκτός λειτουργίας • Κάθε ενέργεια πρέπει να τερματίσει «σωστά» • Διαμοιρασμός • Οι ενέργειες πρέπει να ολοκληρωθούν ακόμα και εάν ορισμένα server κομμάτια είναι down CAP Theorem: Μπορούμε να έχουμε μόνο δύο από τα τρία. Διαμοιρασμός Partition Tolerance

17. CAP Theorem, περιπτώσεις • CA • Μικρά τοπικά δίκτυα ή πολύ μικρά clusters, με μικρό partitioning στα δεδομένα. Εγγύηση για μεγάλο availability και για consistency • Δύσκολη κλιμάκωση • CP • Δεδομένα μη προσβάσιμα συνεχώς, αλλά έχουμε συνέπεια και αντοχή στην κλιμάκωση • AP • Δεδομένα συνεχώς διαθέσιμα με κίνδυνο να μην είναι ενημερωμένα. • Eventual Consistency

18. CAP Theorem, περιπτώσεις • CA • Μικρά τοπικά δίκτυα ή πολύ μικρά clusters, με μικρό partitioning στα δεδομένα. Εγγύηση για μεγάλο availability και για consistency • Δύσκολη κλιμάκωση • CP • Δεδομένα μη προσβάσιμα συνεχώς, αλλά έχουμε συνέπεια και αντοχή στην κλιμάκωση • AP • Δεδομένα συνεχώς διαθέσιμα με κίνδυνο να μην είναι ενημερωμένα. • Eventual Consistency Η περίπτωση των περισσότερων NoSQL συστημάτων

19. Παράδειγμα 2PC, 3PC • Όλο αυτό: • Αργεί • Μπορεί να μην εκτελεστεί καθόλου αν οπουδήποτε υπάρξει σφάλμα • Το availability είναι το γινόμενο των availabilities των επιμέρους συστημάτων • Ο brewer έχει δίκιο: 99,9%*99,9=99,8% • Three phase commit coordinator Data server 1 Data server 2 Can commit? Ναι/Όχι Pre-commit ACK Commit

20. Eventually Consistent: πελάτες

21. Strong Consistency • Μετά την ενημέρωση, όλες οι επόμενες προσβάσεις από τους πελάτες θα φέρουν την τελευταία τιμή

22. Weak Consistency • Το σύστημα δεν εγγυάται ότι σε οποιαδήποτε μεταγενέστερη χρονική στιγμή από την ενημέρωση η πρόσβαση θα επιστρέφει την νέα τιμή

23. Eventual Consistency • Εάν δεν γίνουν άλλες ενημερώσεις στο αντικείμενο, το σύστημα eventually (μετά από well defined χρόνο t) θα επιστρέφει την τελευταία τιμή

24. Causal (αιτιώδης) Consistency • Οι τιμές είναι consistent μεταξύ συνεργαζόμενων clients (Α και Β) • Επόμενη πρόσβαση του Β θα επιστρέψει την νέα τιμή, και μια εγγραφή εγγυάται ότι θα υπερισχύσει της νεότερης εγγραφής

25. Read your writes Consistency • Ο Α ενημερώνει το αντικείμενο και κατόπιν βλέπει άμεσα τις αλλαγές και δεν παίρνει ποτέ πίσω παλιές τιμές • Παράδειγμα: Facebook status update • Sticky clients: «κολλάνε» όλες τους τις συναλλαγές με έναν server του cluster

26. Session Consistency • Στο ίδιο session το σύστημα εξασφαλίζει read your writes consistency

27. Monotonic read consistency • Εάν ένας πελάτης έχει πάρει μια συγκεκριμένη τιμή ενός αντικειμένου, όλες οι επόμενες προσβάσεις δεν θα επιστρέψουν ποτέ παλαιότερες εκδόσεις.

28. Monotonic write consistency • Το σύστημα εξασφαλίζει την σειριοποίηση εγγραφών του ίδιου πελάτη/process.

29. Μηχανισμός eventual consistency • Το transaction τελειώνει όταν πάρει το αντικείμενο μόνο ο primary • Οι replica servers το παίρνουν αργότερα ασύγχρονα

30. Από την μεριά του server • NRW • N:Αριθμός των κόμβων που περιέχουν replica • W:Αριθμός των replica κόμβων που πρέπει να επιβεβαιώσουν την λήψη της ενημέρωσης πριν την ολοκλήρωση της ενημέρωσης • R:Ο αριθμός των replicas που γίνονται contact όταν ένα αντικείμενο ανακτάται κατά ένα read operation

31. Strong consistency

32. Βελτιώσεις • Βελτιστοποίηση read: R=1, N=W • Βελτιστοποίηση write: W=1, N=R

33. Σχεδιασμός clients • Υλοποίηση read-your-writes και monotonic reads με την προσθήκη εκδόσεων στα writes και αγνοώντας οτιδήποτε προηγείται της τελευταίας γνωστής έκδοσης

34. BASE • BASE = η άλλη άποψητου ACID • Basically Available • Διαθέσιμοι οι πόροι σχεδόν πάντα, αλλά όχι πάντα • Soft-State, Scalable • Όχι από κατάσταση σε κατάσταση με transactions • Eventually Consistent • Συνέπεια που θα επέλθει στο χρόνο αλλά με περιπτώσεις μη-συνέπειας συχνές. • Ενημέρωση αντιγράφων κλπ

35. NoSQL • Πρακτικά θέλουμε να αλλάξουμε το μοντέλο των βάσεων δεδομένων από τις σχεσιακές σε κάτι πιο • Κλιμακώσιμο • Διαθέσιμο • No–SQL = όχι SQL, την πετάμε • Ν–ο–SQL = όχι μόνο SQL, χρειαζόμαστε κι άλλα για διαφορετικές εφαρμογές • Για την ακρίβεια πιο σωστός όρος το NoRel = όχι στο σχεσιακό μοντέλο • Υπάρχει και ο όρος NoACID… • Δεν έχουμε σχέσεις -> key,value ζευγάρια • Value μπορεί να είναι οτιδήποτε, από ένα value ή πολλά columns, μέχρι αρχεία

36. Χαρακτηριστικά NoSQLβάσεων • Διαφορετικές όψεις στη Συνέπεια ανάλογα με προσέγγιση • Schema-less • Βασισμένες σε Consistent Hashing και κάποια DHT-like δομή. • Πλήρως συνδεδεμένο δίκτυο. • Ερωτήματα • μεταφράζονταισυνήθως σε MapReduce jobs • υποστήριση απλού get/select key • αποφεύγουν τα δύσκολα ερωτήματα, δύσκολα τα υλοποιούν

37. Consistent Hashing 000000 Insert key “The Dark Knight” md5(“The Dark Knight”) = 36b123 123fa2 a540ac 36b123 42fb2a 8976c1

38. Partitioning • Κάθε κόμβος είναι υπεύθυνος για ένα μέρος του namespace. • Πολλοί τρόποι να γίνει αυτό • Συνήθως κάθε κόμβος λαμβάνει ένα μέρος του key space • Πλήρως συνδεδεμένο δίκτυο • Κάθε κόμβος γνωρίζει κάθε άλλον

39. Gossiping • Κλασσική τακτική στα κατανεμημένα συστήματα • Χρησιμοποιείται εκτενώς και στα Key Value Stores • Κυρίως για ανίχνευση νέων κόμβων, σφαλμάτων... • Μετάδοση της κατάστασης του δικτύου • Προσφέρει eventual consistency

40. Gossiping – διάδοση γεγονότος

41. Θέματα/Προβλήματα • Με Consistent Hashing ξέρουμε που θα αποθηκευτεί το κάθε αντικείμενο • Τα πράγματα δεν είναι τόσο απλά γιατί: • Κάθε κόμβος μπορεί να έχει πολλές θέσεις στο δακτύλιο • Θέμα: Που θα αποθηκευτούν τα αντίγραφα? • Είσοδος/Έξοδος κόμβων στο δίκτυο • Θέμα: Πως θα έχω εξισορρόπηση φόρτου? • Κάθε προσέγγιση έχει • Τους δικούς της στόχους • Τα δικά της προβλήματα • Τις δικές της λύσεις

42. NoSQLTaxonomy • Στο http://nosql-database.org/ • Πάνω από 100 συστήματα NoSQL βάσεων δεδομένων • Οι μεγάλες κατηγορίες • Key-Value Stores • Column Stores • Document Stores • Graph Databases

43. NoSQL Taxonomy : Key Value Stores • Key-Value Stores • Τα structured P2P συστήματα – DHTs • Προσφέρουν απλά key lookups • Κυριότερα: • Dynamo • Voldemort, KAI, Dynomite (open source Dynamo) • Azure • Riak • Redis • Tokyo Cabinet

44. Column και Row Stores • Row Stores • Αποθήκευση με βάση το Row key • Εύκολη αποθήκευση • Τοπικότητα • Column Stores • Αποθήκευση με βάση το Column • Λίστες με τις τιμές των columns • Συμφέρει όταν θέλω να προσπελάσω ένα column αντί για όλο το row • Τα Column Stores που συζητάμε εδώκάνουν κάτι το ενδιάμεσο Γιώργος 5 Α Γιάννης 6 Β Δημήτρης 9 Α Γιώργος Γιάννης Δημήτρης 5 6 9 Α Β Α

45. Column ή Row Stores? • Οι περισσότεροι τα λένε column stores • Στην πραγματικότητα είναι υβριδικό.

46. NoSQL Taxonomy : Column Stores • Key που καθορίζει το row, και το που θα γίνει η αποθήκευση • Value που αποτελείται από πολλά columns ή column families και πολλές τιμές για το καθένα • Κυριότερα • BigTable • Hbase, Hypertable • Cassandra • SimpleDB

48. NoSQL Taxonomy • Document Stores • CouchDB • MongoDB • TerraStore • Graph Databases • Neo4J • HyperGraphDB • Sones • InfoGrid

50. NoSQL: Υπέρ και κατά • Πλεονεκτήματα • Κλιμακωσιμότητα • Υψηλή διαθεσιμότητα • Χαμηλό κόστος • Ευελιξία στο Σχήμα, Ημιδομημένα δεδομένα • Μειονεκτήματα • Δυνατότητες σε ερωτήματα • Standardization • Συνέπεια και eventual Consistency • Σύνθετα ερωτήματα • Πολύ ερευνητική δουλειά για την υποστήριξή τους σε NoSQLπεριβάλλοντα • Περίπλοκα προγράμματα (σε σχέση με τα RDBMS) • Hive, Pig …