1 / 71

CAP, Eventual Consistency και Lamport Clocks

CAP, Eventual Consistency και Lamport Clocks. Περιεχόμενα. Ιστορία ACID CAP Theorem Eventual consistency και BASE Enter NoSQL Χαρακτηριστικά NoSQL βάσεων NoSQL taxonomy Ρολόγια Lamport. Μοντέλα βάσεων δεδομένων. RDBMS. Flat Model . Network Model. Dimensional Model.

takoda
Download Presentation

CAP, Eventual Consistency και Lamport Clocks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CAP, Eventual Consistency και Lamport Clocks

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

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

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

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

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

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

  10. Παράδειγμα 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

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

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

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

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

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

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

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

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

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

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

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

  22. Strong consistency

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

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

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

  26. Λογικά ρολόγια:Ιδέα • Δυο γεγονότα δεν είναι πάντα χρονικά ταξινομημένα σε ένα κατανεμημένο σύστημα. • Μόνο η σειρά γεγονότων που έχουν σχέση αιτίας/αποτελέσματος έχει σημασία. • Εμπνευσμένο από την ειδική θεωρία της σχετικότητας του A. Einstein. • Υλοποίηση με λογικά ρολόγια (logical clocks)

  27. Λογικά ρολόγια(Logical clocks) Αντιστοίχηση ακολουθίας αριθμών σε μηνύματα • Όλες οι συμμετέχοντες διεργασίες μπορούν να συμφωνήσουν σε μια σειρά με την οποία έγιναν τα γεγονότα • Αντίθετα με τα φυσικά ρολόγια(physical clocks): συγκεκριμένη ώρα Δεν θεωρούμε μια κεντρική αρχή που λέει την ώρα • Το κάθε σύστημα/διεργασία έχει το δικό του ρολόι. • Όχι συνολική ταξινόμηση γεγονότων • Δεν υπάρχει η έννοια του “πότε έγινε” κάτιαλλά, “ποιο από τα δύο έγινε πρώτο”?

  28. Τι είναι τα λογικά ρολόγια? (logical clocks) • Ένα λογικό ρολόι είναι ένας μηχανισμός για τη καταγραφή χρονολογικών σχέσεων και σχέσεων που έχουν σχέση αιτίας/αποτελέσματος • Υλοποίηση ενός ρολογιού • Δομή δεδομένων • Πρωτόκολλο ενημέρωσης ρολογιού • Σημαντικοί αλγόριθμοι λογικών ρολογιών είναι αυτοί που βασίζονται σε • Μονοδιάστατα ρολόγια • Διανυσματικά ρολόγια

  29. Συνεισφορά του Lamport (1/2) • Εισαγωγή της έννοιας του λογικού χρόνου αντί για τον απόλυτο χρόνο • Μερική διάταξη των γεγονότων σε σχέση με την σειρά εμφάνισης • Causally Related Events • Εάν το γεγονός Α έγινε πριν από το γεγονός Β, τότε το Α επηρεάζει το Β. • Ταυτόχρονα γεγονότα • Δυο διαφορετικά γεγονότα Α και Β είναι ταυτόχρονα (concurrent) εάν το Α δεν έγινε πριν το Β και το Β δεν έγινε πριν το Α. Δηλαδή τα γεγονότα δεν συνδέονται με κάποια σχέση αιτίας/αποτελέσματος. • Επέκταση της σχέσης “Happens Before” για μια συνεπή ολική διάταξη στον χρόνο σε ένα κατανεμημένο σύστημα. Παράδειγμα: make utility – χρόνοι δημιουργίαςτουinput.c and input.o

  30. Συνεισφορά του Lamport (2/2) • Ο Lamportπαρουσίασε ένα σύστημα λογικών ρολογιών με σκοπό τον σωστό ορισμό της σχέσης “happened before” • Η κάθε διεργασία P έχει το δικό της ρολόι C. • Για κάθε γεγονός ‘a’ σε μια διεργασία, το C μπορεί να θεωρηθεί μια συνάρτηση που θέτει έναν αριθμό C(a) ο οποίος είναι μια χρονοσφραγίδα (timestamp) του γεγονότος ‘a’ στην διεργασία P. Οι αριθμοί αυτοί δεν έχουν καμία σχέση με τον φυσικό χρόνο – για αυτό λέγονται λογικά ρολόγια.

  31. Η σχέση “Happens Before” “->” • Εάν το ‘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

  32. Λογικά ρολόγια (1/2)

  33. Λογικά ρολόγια (2/2) • Πως πετυχαίνουμε ένα συνεπές σετ από λογικά ρολόγια, ένα για κάθε διαδικασία?

  34. Διεργασίες και μηνύματα 1/2

  35. Τρεις διεργασίες, κάθε μια με το δικό της ρολόι. Το κάθε ρολόι τρέχει με διαφορετικό ρυθμό.

  36. Ο αλγόριθμος του Lampertδιορθώνει τα ρολόγια

  37. Διεργασίες και μηνύματα 2/2 E1/E2 είναι sending/receipt του ίδιου μηνύματος, τότε“E1 -> E2”, πχ A2 -> B4. “E1 -> E2 and E2 -> E3” then “E1 -> E3”, πχ. A1 → B4. Ταυτόχρονα: A2 και B3, B4 και C2.

  38. Παράδειγμα: Μέτρηση γεγονότων • 3 συστήματα: P0, P1, P2 • Γεγονόταa, b, c, … • Τοπικός μετρητής γεγονότων σε κάθε σύστημα • Περιστασιακά τα συστήματα επικοινωνούν

  39. Παράδειγμα: Μέτρηση γεγονότων e a b c d f P1 3 4 5 1 2 6 g h i P2 2 1 3 j k P3 1 2

  40. Παράδειγμα: Μέτρηση γεγονότων e a b c d f P1 3 4 5 1 2 6 g h i P2 2 1 3 j k P3 1 2 Λάθος σειρά: e  h f  k

  41. Παράδειγμα: Μέτρηση γεγονότων e a b c d f P1 3 4 5 1 2 6 g h i P2 2 1 7 6 j k P3 1 2 7

  42. Περίληψη • Ο αλγόριθμος χρειάζεται έναν μονότονα αυξανόμενο counter • Αύξηση του counter τουλάχιστον κάθε φορά που χρειάζεται μια χρονοσφραγίδα • Κάθε γεγονός έχει μια χρονοσφραγίδαLamport • Για 2 γεγονότα a  b ισχύει: L(a) < L(b)

  43. Πρόβλημα: Ίδιες χρονοσφραγίδες e a b c d f P1 3 4 5 1 2 6 g h i P2 6 1 7 j k P3 1 7 ab, bc, …: Τα τοπικά γεγονότα μπαίνουν σε σειρά ic, fd , dg, … : Ο Lamportβάζεισε σειράsendreceiveγεγονότα Ταυτόχρονα γεγονότα (πχ, a & j) μπορείνα έχουν την ίδια χρονοσφραγίδα… ή όχι

  44. Λύση: Ολική ταξινόμηση (totalordering)

  45. Ολική ταξινόμηση: Μοναδικές χρονοσφραγίδες Μπορούμε να θέσουμε κάθε χρονοσφραγίδα να είναι μοναδική • Έστωκαθολική λογική χρονοσφραγίδα(Ti, i) • Το Tiείναι μια τοπική χρονοσφραγίδα • Το iδείχνει το id της διεργασίας (καθολικά μοναδικό) • Πχ(διεύθυνση IP, ID διεργασίας) • Σύγκριση χρονοσφραγίδων: (Ti, i) < (Tj, j) Εάν και μόνο εάν Ti < Tjή Ti = Tjκαιi < j Αυθαίρετη ταξινόμηση των διεργασιών.

  46. Μοναδικές ολικά ταξινομημένες χρονοσφραγίδες e a b c d f P1 3.1 4.1 5.1 1.1 2.1 6.1 g h i P2 6.2 1.2 7.2 j k P3 1.3 7.3

  47. Totally-Ordered Multicasting • Updating a replicated database and leaving it in an inconsistent state.

  48. Totally-Ordered Multicasting

  49. Μονοδιάστατος λογικός χρόνος: Υπέρ και Κατά • Υπέρ • Παίρνουμε μια ολική ταξινόμηση των γεγονότων στο σύστημα, χρησιμοποιώντας μόνο την σχέση αιτίας/αποτελέσματος. • Χρειάζεται μόνο ένας 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.

More Related