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

Παρουσίαση με θέμα: " Ιστορία  ACID  CAP Theorem  Eventual consistency και BASE  Enter NoSQL  Χαρακτηριστικά NoSQL βάσεων  NoSQL taxonomy  Ρολόγια Lamport 2."— Μεταγράφημα παρουσίασης:

1

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

3 RDBMS Flat Model Hierarchical Model Network Model Relational Model Dimensional Model Object Model 3

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

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

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

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

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

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

10 10

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

12 12

13 13  Μετά την ενημέρωση, όλες οι επόμενες προσβάσεις από τους πελάτες θα φέρουν την τελευταία τιμή

14 14  Το σύστημα δεν εγγυάται ότι σε οποιαδήποτε μεταγενέστερη χρονική στιγμή από την ενημέρωση η πρόσβαση θα επιστρέφει την νέα τιμή

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

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

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

18 18  Στο ίδιο session το σύστημα εξασφαλίζει read your writes consistency

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

20 20  Το σύστημα εξασφαλίζει την σειριοποίηση εγγραφών του ίδιου πελάτη/process.

21 21  Το transaction τελειώνει όταν πάρει το αντικείμενο μόνο ο primary  Οι replica servers το παίρνουν αργότερα ασύγχρονα

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

23 23

24  Βελτιστοποίηση read: R=1, N=W  Βελτιστοποίηση write: W=1, N=R 24

25  Υλοποίηση read-your-writes και monotonic reads με την προσθήκη εκδόσεων στα writes και αγνοώντας οτιδήποτε προηγείται της τελευταίας γνωστής έκδοσης 25

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

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

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

29 Ένα λογικό ρολόι είναι ένας μηχανισμός για τη καταγραφή χρονολογικών σχέσεων και σχέσεων που έχουν σχέση αιτίας/αποτελέσματος Υλοποίηση ενός ρολογιού – Δομή δεδομένων – Πρωτόκολλο ενημέρωσης ρολογιού Σημαντικοί αλγόριθμοι λογικών ρολογιών είναι αυτοί που βασίζονται σε – Μονοδιάστατα ρολόγια – Διανυσματικά ρολόγια

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

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

32 Εάν το ‘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

33

34  Πως πετυχαίνουμε ένα συνεπές σετ από λογικά ρολόγια, ένα για κάθε διαδικασία? 

35

36

37

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

39  3 συστήματα: P 0, P 1, P 2  Γεγονότα a, b, c, …  Τοπικός μετρητής γεγονότων σε κάθε σύστημα  Περιστασιακά τα συστήματα επικοινωνούν

40 ab hi k P1P1 P2P2 P3P3 12 13 21 df g 3 c 2 4 6 e 5 j

41 ab i k j P1P1 P2P2 P3P3 12 13 21 df g 3 c 2 4 6 Λάθος σειρά: e  h f  k h e 5

42 ab i k j P1P1 P2P2 P3P3 12 17 21 df g 3 c 2 4 6 6 7 h e 5

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

44 a  b, b  c, …:Τα τοπικά γεγονότα μπαίνουν σε σειρά i  c, f  d, d  g, … :Ο Lamport βάζει σε σειρά send  receive γεγονότα Ταυτόχρονα γεγονότα (πχ, a & j) μπορεί να έχουν την ίδια χρονοσφραγίδα … ή όχι ab hi k j P1P1 P2P2 P3P3 12 17 71 df g 3 c 6 4 6 e 5

45

46 Μπορούμε να θέσουμε κάθε χρονοσφραγίδα να είναι μοναδική ◦ Έστω καθολική λογική χρονοσφραγίδα (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 Αυθαίρετη ταξινόμηση των διεργασιών.

47 ab i k j P1P1 P2P2 P3P3 1.12.1 1.27.2 7.31.3 df g 3.1 c 6.2 4.1 6.1 h e 5.1

48  Updating a replicated database and leaving it in an inconsistent state.

49

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

51  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

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

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

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

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

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

57 57

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

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

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

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

62 62  Οι περισσότεροι τα λένε column stores  Στην πραγματικότητα είναι υβριδικό.

63  Key που καθορίζει το row, και το που θα γίνει η αποθήκευση  Value που αποτελείται από πολλά columns ή column families και πολλές τιμές για το καθένα  Κυριότερα ◦ BigTable ◦ Hbase, Hypertable ◦ Cassandra ◦ SimpleDB 63

64 IdΗθοποιόςΗμ.γέννησης 1234Christian Bale30-1-1974 5678Natalie Portman9-6-1981 9012Melissa Leo14-9-1960 3456Colin Firth10-9-1960 IdΤαινίαΈτος 1The Dark Knight2008 2King’s Speech2010 3The Fighter2010 4Black Swan2010 5The Prestige2006 ΗθοπΤαινία 12341 3 5 56784 90123 34562 ΗθοπΤαινία 12341 3 5 56784 90123 34562 Keyvalue The Dark KnightΗθοποιοί: Christian BaleΈτος: 2008 King’s SpeechΗθοποιοί: Colin FirthΈτος: 2010 The FighterΗθοποιοί: Melissa Leo, Christian Bale Έτος: 2010 Black SwanΗθοποιοί: Natalie PortmanΈτος: 2010 The PrestigeΗθοποιοί: Christian BaleΈτος: 2006 Christian BaleΗμ.Γέννησης: 30-1-1974 Keyvalue The Dark KnightΗθοποιοί: Christian BaleΈτος: 2008 King’s SpeechΗθοποιοί: Colin FirthΈτος: 2010 The FighterΗθοποιοί: Melissa Leo, Christian Bale Έτος: 2010 Black SwanΗθοποιοί: Natalie PortmanΈτος: 2010 The PrestigeΗθοποιοί: Christian BaleΈτος: 2006

65  Document Stores ◦ CouchDB ◦ MongoDB ◦ TerraStore  Graph Databases ◦ Neo4J ◦ HyperGraphDB ◦ Sones ◦ InfoGrid 65

66 66

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

68  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.julianbrowne.com/article/viewer/brewers -cap-theorem  http://www.royans.net/arch/brewers-cap-theorem- on-distributed-systems/ http://www.royans.net/arch/brewers-cap-theorem- on-distributed-systems/ 68

69  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://queue.acm.org/detail.cfm?id=146644 8  http://dbmsmusings.blogspot.com/2010/08 /problems-with-acid-and-how-to-fix- them.html http://dbmsmusings.blogspot.com/2010/08 /problems-with-acid-and-how-to-fix- them.html  http://blog.nahurst.com/visual-guide-to- nosql-systems http://blog.nahurst.com/visual-guide-to- nosql-systems 69

70  http://en.wikipedia.org/wiki/Lamport_timest amps 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 http://research.microsoft.com/users/lamport/pubs /time-clocks.pdf 70

71