CAP, Eventual Consistency και Lamport Clocks
description
Transcript of CAP, Eventual Consistency και Lamport Clocks
CAP, Eventual Consistency και Lamport Clocks
Ιστορία ACID CAP Theorem Eventual consistency και BASE Enter NoSQL Χαρακτηριστικά NoSQL βάσεων NoSQL taxonomy Ρολόγια Lamport
Περιεχόμενα
2
Μοντέλα βάσεων δεδομένων
RDBMS
Flat Model
Hierarchical Model
Network Model
Relational Model
Dimensional Model
Object Model
3
Συναλλαγές (Transactions) ACID
◦ Ατομικότητα (Atomicity – όλη η συναλλαγή ή καθόλου)
◦ Συνέπεια (Consistency – από μία consistent κατάσταση σε μία άλλη)
◦ Απομόνωση (Isolation - απαγόρευση πρόσβασης σε δεδομένα συναλλαγής που δεν έχει ολοκληρωθεί)
◦ Durability (Διάρκεια – μπορεί να ανακτήσει την προηγούμενη κατάσταση μετά από όλες τις committed συναλλαγές)
RDBMS ιδιότητες
4
Διαφορετικές ανάγκες των Web συστημάτων από αυτές που καλύπτουν τα RDBMS◦ ACID απαιτήσεις (replication …)◦ Οριζόντιος καταμερισμός vs Normalization ◦ Καθυστέρηση: Χαμηλοί και Προβλέψιμοι Χρόνοι
Απόκρισης◦ Flexible Schemas/ Αδόμητα ή Ημιδομημένα
Δεδομένα◦ Πολλά Datacenters κατανεμημένα σε όλο τον
κόσμο. Κλιμακωσιμότητα
◦ Υψηλή Διαθεσιμότητα (availability)
Γιατί δεν μας κάνει το RDBMS?
5
Γιατί να μην τα έχουμε όλα?
Συνέπεια Consistency
Διαθεσιμότητα
Availability
ΔιαμοιρασμόςPartition Tolerance
6
Συνέπεια◦ Όλοι να βλέπουν τις ίδιες
εκδόσεις δεδομένων Διαθεσιμότητα
◦ Σύστημα πάντα διαθέσιμο ανεξάρτητα από αποτυχίες κόμβων, αλλαγές H/W-S/W, κλειδώματα.
◦ 99,9% (three nines)= το πολύ 8,76 ώρες τον χρόνο εκτός λειτουργίας
◦ Κάθε ενέργεια πρέπει να τερματίσει «σωστά»
Διαμοιρασμός◦ Οι ενέργειες πρέπει να
ολοκληρωθούν ακόμα και εάν ορισμένα server κομμάτια είναι down
Γιατί να μην τα έχουμε όλα?
Συνέπεια Consistency
Διαθεσιμότητα
Availability
ΔιαμοιρασμόςPartition Tolerance
7
Συνέπεια◦ Όλοι να βλέπουν τις ίδιες
εκδόσεις δεδομένων Διαθεσιμότητα
◦ Σύστημα πάντα διαθέσιμο ανεξάρτητα από αποτυχίες κόμβων, αλλαγές H/W-S/W, κλειδώματα.
◦ 99,9% (three nines)= το πολύ 8,76 ώρες τον χρόνο εκτός λειτουργίας
◦ Κάθε ενέργεια πρέπει να τερματίσει «σωστά»
Διαμοιρασμός◦ Οι ενέργειες πρέπει να
ολοκληρωθούν ακόμα και εάν ορισμένα server κομμάτια είναι down
CAP Theorem: Μπορούμε να έχουμε μόνο δύο από τα τρία.
CA◦ Μικρά τοπικά δίκτυα ή πολύ μικρά clusters, με μικρό
partitioning στα δεδομένα. Εγγύηση για μεγάλο availability και για consistency
◦ Δύσκολη κλιμάκωση CP
◦ Δεδομένα μη προσβάσιμα συνεχώς, αλλά έχουμε συνέπεια και αντοχή στην κλιμάκωση
AP◦ Δεδομένα συνεχώς διαθέσιμα με κίνδυνο να μην είναι
ενημερωμένα. ◦ Eventual Consistency
CAP Theorem, περιπτώσεις
8
CA◦ Μικρά τοπικά δίκτυα ή πολύ μικρά clusters, με μικρό
partitioning στα δεδομένα. Εγγύηση για μεγάλο availability και για consistency
◦ Δύσκολη κλιμάκωση (παραδοσιακά RDBMS) CP
◦ Δεδομένα μη προσβάσιμα συνεχώς, αλλά έχουμε συνέπεια και αντοχή στην κλιμάκωση
AP◦ Δεδομένα συνεχώς διαθέσιμα με κίνδυνο να μην
είναι ενημερωμένα. ◦ Eventual Consistency
CAP Theorem, περιπτώσεις
9
Η περίπτωση των περισσότερων NoSQL
συστημάτων
10
Three phase commit
11
Παράδειγμα 2PC, 3PCcoordinator Data server 1 Data server 2
Can commit?
Ναι/Όχι
Pre-commit
ACK
Commit
Όλο αυτό: Αργεί Μπορεί να μην
εκτελεστεί καθόλου αν οπουδήποτε υπάρξει σφάλμα
Το availability είναι το γινόμενο των availabilities των επιμέρους συστημάτων
Ο brewer έχει δίκιο: 99,9%*99,9=99,8%
Eventually Consistent: πελάτες
12
Strong Consistency
13
Μετά την ενημέρωση, όλες οι επόμενες προσβάσεις από τους πελάτες θα φέρουν την τελευταία τιμή
Weak Consistency
14
Το σύστημα δεν εγγυάται ότι σε οποιαδήποτε μεταγενέστερη χρονική στιγμή από την ενημέρωση η πρόσβαση θα επιστρέφει την νέα τιμή
Eventual Consistency
15
Εάν δεν γίνουν άλλες ενημερώσεις στο αντικείμενο, το σύστημα eventually (μετά από well defined χρόνο t) θα επιστρέφει την τελευταία τιμή
Causal (αιτιώδης) Consistency
16
Οι τιμές είναι consistent μεταξύ συνεργαζόμενων clients (Α και Β)
Επόμενη πρόσβαση του Β θα επιστρέψει την νέα τιμή, και μια εγγραφή εγγυάται ότι θα υπερισχύσει της νεότερης εγγραφής
Read your writes Consistency
17
Ο Α ενημερώνει το αντικείμενο και κατόπιν βλέπει άμεσα τις αλλαγές και δεν παίρνει ποτέ πίσω παλιές τιμές
Παράδειγμα: Facebook status update Sticky clients: «κολλάνε» όλες τους τις συναλλαγές
με έναν server του cluster
Session Consistency
18
Στο ίδιο session το σύστημα εξασφαλίζει read your writes consistency
Monotonic read consistency
19
Εάν ένας πελάτης έχει πάρει μια συγκεκριμένη τιμή ενός αντικειμένου, όλες οι επόμενες προσβάσεις δεν θα επιστρέψουν ποτέ παλαιότερες εκδόσεις.
Monotonic write consistency
20
Το σύστημα εξασφαλίζει την σειριοποίηση εγγραφών του ίδιου πελάτη/process.
Μηχανισμός eventual consistency
21
Το transaction τελειώνει όταν πάρει το αντικείμενο μόνο ο primary
Οι replica servers το παίρνουν αργότερα ασύγχρονα
Από την μεριά του server
22
NRW N: Αριθμός των κόμβων που περιέχουν replica W: Αριθμός των replica κόμβων που πρέπει να
επιβεβαιώσουν την λήψη της ενημέρωσης πριν την ολοκλήρωση της ενημέρωσης
R: Ο αριθμός των replicas που γίνονται contact όταν ένα αντικείμενο ανακτάται κατά ένα read operation
Strong consistency
23
Βελτιστοποίηση read: R=1, N=W Βελτιστοποίηση write: W=1, N=R
Βελτιώσεις
24
Υλοποίηση read-your-writes και monotonic reads με την προσθήκη εκδόσεων στα writes και αγνοώντας οτιδήποτε προηγείται της τελευταίας γνωστής έκδοσης
Σχεδιασμός clients
25
BASE = η άλλη άποψη του ACID◦ Basically Available
Διαθέσιμοι οι πόροι σχεδόν πάντα, αλλά όχι πάντα◦ Soft-State, Scalable
Όχι από κατάσταση σε κατάσταση με transactions◦ Eventually Consistent
Συνέπεια που θα επέλθει στο χρόνο αλλά με περιπτώσεις μη-συνέπειας συχνές.
Ενημέρωση αντιγράφων κλπ
BASE
26
Δυο γεγονότα δεν είναι πάντα χρονικά ταξινομημένα σε ένα κατανεμημένο σύστημα.
Μόνο η σειρά γεγονότων που έχουν σχέση αιτίας/αποτελέσματος έχει σημασία.
Εμπνευσμένο από την ειδική θεωρία της σχετικότητας του A. Einstein.
Υλοποίηση με λογικά ρολόγια (logical clocks)
Λογικά ρολόγια: Ιδέα
27
Λογικά ρολόγια (Logical clocks)Αντιστοίχηση ακολουθίας αριθμών σε μηνύματα
◦ Όλες οι συμμετέχοντες διεργασίες μπορούν να συμφωνήσουν σε μια σειρά με την οποία έγιναν τα γεγονότα
◦ Αντίθετα με τα φυσικά ρολόγια (physical clocks): συγκεκριμένη ώρα
Δεν θεωρούμε μια κεντρική αρχή που λέει την ώρα◦ Το κάθε σύστημα/διεργασία έχει το δικό του ρολόι. ◦ Όχι συνολική ταξινόμηση γεγονότων
Δεν υπάρχει η έννοια του “πότε έγινε” κάτι αλλά, “ποιο από τα δύο έγινε πρώτο”?
• Ένα λογικό ρολόι είναι ένας μηχανισμός για τη καταγραφή χρονολογικών σχέσεων και σχέσεων που έχουν σχέση αιτίας/αποτελέσματος
• Υλοποίηση ενός ρολογιού– Δομή δεδομένων– Πρωτόκολλο ενημέρωσης ρολογιού
• Σημαντικοί αλγόριθμοι λογικών ρολογιών είναι αυτοί που βασίζονται σε – Μονοδιάστατα ρολόγια– Διανυσματικά ρολόγια
Τι είναι τα λογικά ρολόγια? (logical clocks)
Συνεισφορά του Lamport (1/2)• Εισαγωγή της έννοιας του λογικού χρόνου αντί για
τον απόλυτο χρόνο• Μερική διάταξη των γεγονότων σε σχέση με την
σειρά εμφάνισης– Causally Related Events
• Εάν το γεγονός Α έγινε πριν από το γεγονός Β, τότε το Α επηρεάζει το Β.
– Ταυτόχρονα γεγονότα• Δυο διαφορετικά γεγονότα Α και Β είναι ταυτόχρονα (concurrent)
εάν το Α δεν έγινε πριν το Β και το Β δεν έγινε πριν το Α. Δηλαδή τα γεγονότα δεν συνδέονται με κάποια σχέση αιτίας/αποτελέσματος.
• Επέκταση της σχέσης “Happens Before” για μια συνεπή ολική διάταξη στον χρόνο σε ένα κατανεμημένο σύστημα.
Παράδειγμα: make utility – χρόνοι δημιουργίας του input.c and input.o
Συνεισφορά του Lamport (2/2) Ο Lamport παρουσίασε ένα σύστημα λογικών
ρολογιών με σκοπό τον σωστό ορισμό της σχέσης “happened before”
Η κάθε διεργασία P έχει το δικό της ρολόι C. Για κάθε γεγονός ‘a’ σε μια διεργασία, το C
μπορεί να θεωρηθεί μια συνάρτηση που θέτει έναν αριθμό C(a) ο οποίος είναι μια χρονοσφραγίδα (timestamp) του γεγονότος ‘a’ στην διεργασία P.
Οι αριθμοί αυτοί δεν έχουν καμία σχέση με τον φυσικό χρόνο – για αυτό λέγονται λογικά ρολόγια.
Η σχέση “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
Λογικά ρολόγια (1/2)
Λογικά ρολόγια (2/2) Πως πετυχαίνουμε ένα συνεπές σετ από λογικά ρολόγια, ένα για
κάθε διαδικασία?
Διεργασίες και μηνύματα 1/2
Τρεις διεργασίες, κάθε μια με το δικό της ρολόι. Το κάθε ρολόι τρέχει με διαφορετικό ρυθμό.
Ο αλγόριθμος του Lampert διορθώνει τα ρολόγια
Διεργασίες και μηνύματα 2/2
E1/E2 είναι sending/receipt του ίδιου μηνύματος, τότε“E1 -> E2”, πχ A2 -> B4.“E1 -> E2 and E2 -> E3” then “E1 -> E3”, πχ. A1 → B4.Ταυτόχρονα: A2 και B3, B4 και C2.
Παράδειγμα: Μέτρηση γεγονότων 3 συστήματα: P0, P1, P2
Γεγονότα a, b, c, … Τοπικός μετρητής γεγονότων σε κάθε
σύστημα Περιστασιακά τα συστήματα επικοινωνούν
Παράδειγμα: Μέτρηση γεγονότων
a b
h i
k
P1
P2
P3
1 2
1 3
21
d f
g3
c
2
4 6
e
5
j
Παράδειγμα: Μέτρηση γεγονότων
a b
i
kj
P1
P2
P3
1 2
1 3
21
d f
g3
c
2
4 6
Λάθος σειρά:
e h
f k
h
e
5
Παράδειγμα: Μέτρηση γεγονότων
a b
i
kj
P1
P2
P3
1 2
1 7
21
d f
g3
c
2
4 6
6
7
h
e
5
Περίληψη Ο αλγόριθμος χρειάζεται έναν μονότονα
αυξανόμενο counter Αύξηση του counter τουλάχιστον κάθε φορά
που χρειάζεται μια χρονοσφραγίδα Κάθε γεγονός έχει μια χρονοσφραγίδα
Lamport
Για 2 γεγονότα a b ισχύει:L(a) < L(b)
Πρόβλημα: Ίδιες χρονοσφραγίδες
ab, bc, …: Τα τοπικά γεγονότα μπαίνουν σε σειράic, fd , dg, … : Ο Lamport βάζει σε σειρά
sendreceive γεγονότα
Ταυτόχρονα γεγονότα (πχ, a & j) μπορεί να έχουν την ίδια χρονοσφραγίδα … ή όχι
a b
h i
kj
P1
P2
P3
1 2
1 7
71
d f
g3
c
6
4 6
e
5
Λύση: Ολική ταξινόμηση (total ordering)
Ολική ταξινόμηση: Μοναδικές χρονοσφραγίδες
Μπορούμε να θέσουμε κάθε χρονοσφραγίδα να είναι μοναδική◦ Έστω καθολική λογική χρονοσφραγίδα (Ti, i)
Το Ti είναι μια τοπική χρονοσφραγίδα Το i δείχνει το id της διεργασίας (καθολικά
μοναδικό) Πχ(διεύθυνση IP, ID διεργασίας)
◦ Σύγκριση χρονοσφραγίδων:(Ti, i) < (Tj, j)
Εάν και μόνο εάνTi < Tj ή Ti = Tj και i < j
Αυθαίρετη ταξινόμηση των διεργασιών.
Μοναδικές ολικά ταξινομημένες χρονοσφραγίδες
a b
i
kj
P1
P2
P3
1.1 2.1
1.2 7.2
7.31.3
d f
g3.1
c
6.2
4.1 6.1h
e
5.1
Totally-Ordered Multicasting Updating a replicated database and leaving it in an inconsistent
state.
Totally-Ordered Multicasting
Μονοδιάστατος λογικός χρόνος: Υπέρ και Κατά
Υπέρ Παίρνουμε μια ολική ταξινόμηση των
γεγονότων στο σύστημα, χρησιμοποιώντας μόνο την σχέση αιτίας/αποτελέσματος.
Χρειάζεται μόνο ένας 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
52
NoSQL Πρακτικά θέλουμε να αλλάξουμε το μοντέλο των βάσεων
δεδομένων από τις σχεσιακές σε κάτι πιο ◦ Κλιμακώσιμο◦ Διαθέσιμο
No–SQL = όχι SQL, την πετάμε Ν–ο–SQL = όχι μόνο SQL, χρειαζόμαστε κι άλλα για
διαφορετικές εφαρμογές Για την ακρίβεια πιο σωστός όρος το NoRel = όχι στο
σχεσιακό μοντέλο Υπάρχει και ο όρος NoACID…
Δεν έχουμε σχέσεις -> key, value ζευγάρια Value μπορεί να είναι οτιδήποτε, από ένα value ή πολλά
columns, μέχρι αρχεία
Διαφορετικές όψεις στη Συνέπεια ανάλογα με προσέγγιση
Schema-less Βασισμένες σε Consistent Hashing και κάποια
DHT-like δομή. Πλήρως συνδεδεμένο δίκτυο. Ερωτήματα
◦ μεταφράζονται συνήθως σε MapReduce jobs◦ υποστήριση απλού get/select key◦ αποφεύγουν τα δύσκολα ερωτήματα, δύσκολα τα
υλοποιούν
53
Χαρακτηριστικά NoSQL βάσεων
54
Consistent Hashing000000
123fa2
42fb2a8976c1
a540ac
“The Dark Knight”md5(“The Dark Knight”)
= 36b123
36b123
Insert key
Κάθε κόμβος είναι υπεύθυνος για ένα μέρος του namespace. ◦ Πολλοί τρόποι να γίνει αυτό◦ Συνήθως κάθε κόμβος λαμβάνει ένα μέρος του
key space Πλήρως συνδεδεμένο δίκτυο
◦ Κάθε κόμβος γνωρίζει κάθε άλλον
55
Partitioning
Κλασσική τακτική στα κατανεμημένα συστήματα
Χρησιμοποιείται εκτενώς και στα Key Value Stores ◦ Κυρίως για ανίχνευση νέων κόμβων,
σφαλμάτων...◦ Μετάδοση της κατάστασης του δικτύου
Προσφέρει eventual consistency
56
Gossiping
57
Gossiping – διάδοση γεγονότος
Με Consistent Hashing ξέρουμε που θα αποθηκευτεί το κάθε αντικείμενο
Τα πράγματα δεν είναι τόσο απλά γιατί:◦ Κάθε κόμβος μπορεί να έχει πολλές θέσεις στο δακτύλιο◦ Θέμα: Που θα αποθηκευτούν τα αντίγραφα?◦ Είσοδος/Έξοδος κόμβων στο δίκτυο ◦ Θέμα: Πως θα έχω εξισορρόπηση φόρτου?
Κάθε προσέγγιση έχει ◦ Τους δικούς της στόχους ◦ Τα δικά της προβλήματα◦ Τις δικές της λύσεις
58
Θέματα/Προβλήματα
Στο http://nosql-database.org/◦ Πάνω από 100 συστήματα NoSQL βάσεων
δεδομένων Οι μεγάλες κατηγορίες
◦ Key-Value Stores◦ Column Stores◦ Document Stores◦ Graph Databases
59
NoSQL Taxonomy
Key-Value Stores◦ Τα structured P2P συστήματα – DHTs◦ Προσφέρουν απλά key lookups◦ Κυριότερα:
Dynamo Voldemort, KAI, Dynomite (open source Dynamo) Azure Riak Redis Tokyo Cabinet
60
NoSQL Taxonomy : Key Value Stores
Row Stores ◦ Αποθήκευση με βάση το Row key ◦ Εύκολη αποθήκευση◦ Τοπικότητα
Column Stores◦ Αποθήκευση με βάση το Column◦ Λίστες με τις τιμές των columns◦ Συμφέρει όταν θέλω να προσπελάσω ένα column αντί για όλο το row
Τα Column Stores που συζητάμε εδώ κάνουν κάτι το ενδιάμεσο
61
Column και Row Stores
Γιώργος Γιάννης Δημήτρης5 6Α Β 9 Α
Γιώργος Γιάννης Δημήτρης 5 6 Α Β9 Α
62
Column ή Row Stores? Οι περισσότεροι τα λένε column stores Στην πραγματικότητα είναι υβριδικό.
Key που καθορίζει το row, και το που θα γίνει η αποθήκευση
Value που αποτελείται από πολλά columns ή column families και πολλές τιμές για το καθένα
Κυριότερα◦ BigTable ◦ Hbase, Hypertable◦ Cassandra◦ SimpleDB
63
NoSQL Taxonomy : Column Stores
Id Ηθοποιός Ημ.γέννησης
1234 Christian Bale 30-1-19745678 Natalie
Portman9-6-1981
9012 Melissa Leo 14-9-19603456 Colin Firth 10-9-1960
Id
Ταινία Έτος
1 The Dark Knight
2008
2 King’s Speech 20103 The Fighter 20104 Black Swan 20105 The Prestige 2006
Ηθοπ Ταινία1234 11234 31234 55678 49012 33456 2
Ηθοπ Ταινία1234 11234 31234 55678 49012 33456 2
Key valueThe Dark Knight Ηθοποιοί: Christian Bale Έτος: 2008King’s Speech Ηθοποιοί: Colin Firth Έτος: 2010The Fighter Ηθοποιοί: Melissa Leo,
Christian BaleΈτος: 2010
Black Swan Ηθοποιοί: Natalie Portman
Έτος: 2010
The Prestige Ηθοποιοί: Christian Bale Έτος: 2006
Christian Bale Ημ.Γέννησης: 30-1-1974
Key valueThe Dark Knight Ηθοποιοί: Christian Bale Έτος: 2008King’s Speech Ηθοποιοί: Colin Firth Έτος: 2010The Fighter Ηθοποιοί: Melissa Leo,
Christian BaleΈτος: 2010
Black Swan Ηθοποιοί: Natalie Portman
Έτος: 2010
The Prestige Ηθοποιοί: Christian Bale Έτος: 2006
Document Stores◦ CouchDB◦ MongoDB◦ TerraStore
Graph Databases◦ Neo4J◦ HyperGraphDB◦ Sones◦ InfoGrid
65
NoSQL Taxonomy
66
Πλεονεκτήματα◦ Κλιμακωσιμότητα◦ Υψηλή διαθεσιμότητα◦ Χαμηλό κόστος◦ Ευελιξία στο Σχήμα, Ημιδομημένα δεδομένα
Μειονεκτήματα◦ Δυνατότητες σε ερωτήματα ◦ Standardization◦ Συνέπεια και eventual Consistency
Σύνθετα ερωτήματα◦ Πολύ ερευνητική δουλειά για την υποστήριξή τους σε
NoSQL περιβάλλοντα◦ Περίπλοκα προγράμματα (σε σχέση με τα RDBMS)
Hive, Pig …
NoSQL: Υπέρ και κατά
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-theorem-on-distributed-systems/
To see 1/3
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=1466448
http://dbmsmusings.blogspot.com/2010/08/problems-with-acid-and-how-to-fix-them.html
http://blog.nahurst.com/visual-guide-to-nosql-systems
To see 2/3
69
http://en.wikipedia.org/wiki/Lamport_timestamps
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
To see 3/3
70
Ερωτήσεις?