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

Ερωτήσεις?