 Ένας αλγόριθμος ομοφωνίας consensus ◦ Από τους πιο αποτελεσματικούς και κομψούς αλγόριθμους ομοφωνίας ◦ Στα κατανεμημένα συστήματα χρησιμοποιείται κατά κόρον

 Developed by Leslie Lamport (from the Lamport clock)  “A fault-tolerant file system called Echo was built at SRC in the late 80s. The builders claimed that it would maintain consistency despite any number of non-Byzantine faults, and would make progress if any majority of the processors were working.”  “I decided that what they were trying to do was impossible, and set out to prove it. Instead, I discovered the Paxos algorithm.”  “I decided to cast the algorithm in terms of a parliament on an ancient Greek island (Paxos).”

 The paper abstract: ◦ “Recent archaeological discoveries on the island of Paxos reveal that the parliament functioned despite the peripatetic propensity of its part-time legislators. The legislators maintained consistent copies of the parliamentary record, despite their frequent forays from the chamber and the forgetfulness of their messengers. The Paxon parliament’s protocol provides a new way of implementing the state-machine approach to the design of distributed systems.”

 Ο κόσμος πίστευε ότι το Paxos ήταν αστείο.  Ο Lamport τελικά δημοσίευσε το άρθρο 8 χρόνια αργότερα το 1998 αφού γράφτηκε ◦ Τίτλος: “The Part-Time Parliament”  Το αρχικό paper ήταν δυσνόητο.  Ο Lamport έγραψε μια πιο κατανοητή έκδοση. ◦ Τίτλος: “Paxos Made Simple” ◦ Περίληψη: “The Paxos algorithm, when presented in plain English, is very simple.”

 Γενικά πως συμφωνεί ο κόσμος σε κάτι? ◦ Ερώτηση: Πρέπει ο καθηγητής να βάλει 10 σε όλους όσους παρακολουθούν το μάθημα Προχωρημένα Θέματα Βάσεων? ◦ Είσοδος: Όλοι λένε Ναι/Όχι. ◦ Έξοδος: μια συμφωνία σε Ναι ή Όχι.  Πολλά προβλήματα κατανεμημένων συστημάτων μπορούν να αναχθούν σε ένα πρόβλημα ομοφωνίας ◦ Mutual exclusion, leader election, total ordering, etc.  Paxos ◦ Πως γίνεται πολλαπλές διεργασίες να συμφωνήσουν σε μια τιμή? ◦ Κάτω από αστοχίες υλικού, κατατμήσεις δικτύου, καθυστερήσεις μηνυμάτων, κλπ?

 Πολύ σημαντικό πρόβλημα!  Αρκετά πραγματικά συστήματα υλοποιούν το Paxos ◦ Google Chubby, Apache Zookeeper ◦ MS Bing cluster management ◦ Etc.  Amazon CTO Werner Vogels (ο eventually consistent κύριος στο blog του “Job Openings in My Group”) ◦ “What kind of things am I looking for in you?” ◦ “You know your distributed systems theory: You know about logical time, snapshots, stability, message ordering, but also acid and multi-level transactions. You have heard about the FLP impossibility argument. You know why failure detectors can solve it (but you do not have to remember which one diamond-w was). You have at least once tried to understand Paxos by reading the original paper.”

 FruitCo has ◦ Its main Sales office in Oregon ◦ Farms and Warehouse are in Washington ◦ Finance is in Utah ◦ All three sites have local data centers with their own systems  When an order is placed, the Sales system must send the billing information to Utah and shipping information to Washington. ◦ When an order is placed, all three databases must be updated, or none should be. 8

9  The Basic Idea Transaction Manager (TM)Resource Manager (RM) 1.Trans. arrives. Message to ask for vote is sent to other site(s) Message is recorded. Site votes Y or N (abort) Vote is sent to site 1 2.The vote is received. If vote = Y on both sites, then Commit else Abort Either Commit or Abort based on the decision of site 1

 Phase 1 : The TM gets the RMs ready to write the results into the database  Phase 2 : Everybody writes the results into the database ◦ TM :The process at the site where the transaction originates and which controls the execution ◦ RM :The process at the other sites that participate in executing the transaction  Global Commit Rule: ◦ The TM aborts a transaction if and only if at least one RM votes to abort it. ◦ The TM commits a transaction if and only if all of the RMs vote to commit it. 10

11 ready?yes/nocommit/abort?commited/aborted Phase 1Phase 2 CCC P P P P P P P P

INITIAL WAIT Commit command Prepare Vote-commit (all) Global-commit INITIAL READY Prepare Vote-commit Global-commit Ack Prepare Vote-abort Global-abort Ack TM RMs Vote-abort Global-abort ABORTCOMMIT ABORT

 Timeout in INITIAL ◦ Who cares  Timeout in WAIT ◦ Cannot unilaterally commit ◦ Can unilaterally abort  Timeout in ABORT or COMMIT ◦ Stay blocked and wait for the acks TM INITIAL WAIT Commit command Prepare Vote-commit Global-commit ABORTCOMMIT Vote-abort Global-abort

 Timeout in INITIAL ◦ TM must have failed in INITIAL state ◦ Unilaterally abort  Timeout in READY ◦ Stay blocked INITIAL READY Prepare Vote-commit Global-commit Ack Prepare Vote-abort Global-abort Ack ABORTCOMMIT RMs

 Failure in INITIAL ◦ Start the commit process upon recovery  Failure in WAIT ◦ Restart the commit process upon recovery  Failure in ABORT or COMMIT ◦ Nothing special if all the acks have been received ◦ Otherwise the termination protocol is involved TM INITIAL WAIT Commit command Prepare Vote-commit Global-commit ABORTCOMMIT Vote-abort Global-abort

 Failure in INITIAL ◦ Unilaterally abort upon recovery  Failure in READY ◦ The TM has been informed about the local decision ◦ Treat as timeout in READY state and invoke the termination protocol  Failure in ABORT or COMMIT ◦ Nothing special needs to be done INITIAL READY Prepare Vote-commit Global-commit Ack Prepare Vote-abort Global-abort Ack ABORT COMMIT RMs

RM TM No Yes VOTE-COMMIT Yes GLOBAL-ABORT No write abort in log Abort Commit ACK INITIAL write abort in log write ready in log write commit in log Type of msg WAIT Ready to Commit? write commit in log Any No? write abort in log ABORTCOMMIT ABORT write begin_commit in log write end_of_transaction in log READY INITIAL PREPARE VOTE-ABORT VOTE-COMMIT

 Two-phase commit protocol limitation: it is a blocking protocol. ◦ The failure of the TM can cause the protocol to block until the TM is repaired.  If the TM fails right after every RM has sent a Prepared message, then the other RMs have no way of knowing whether the TM committed or aborted.  RMs will block resource processes while waiting for a message from the TM. ◦ A TM will also block resources while waiting for replies from RMs. A TM can also block indefinitely if no acknowledgement is received from the RM.

 Το δίκτυο είναι ασύγχρονο με δικτυακές καθυστερήσεις.  Το δίκτυο μπορεί χάσει ή να αντιγράψει μηνύματα (αλλά δεν τα αλλάζει επίτηδες)  Οι διεργασίες μπορούν να κρασάρουν και να ανανήψουν  Οι διεργασίες είναι non-Byzantine.  Οι διεργασίες έχουν μόνιμο αποθηκευτικό χώρο.  Οι διεργασίες μπορούν να προτείνουν τιμές.  Στόχος: κάθε διεργασία συμφωνεί σε μια από ένα σύνολο προτεινόμενων τιμών.

 Ασφάλεια ◦ Οι επιλεγμένη τιμή πρέπει να είναι από το σύνολο των προτεινόμενων. ◦ Μόνο μια τιμή μπορεί να επιλεχτεί. ◦ Μια διεργασία δεν μαθαίνει ποτέ ότι μια τιμή έχει επιλεχτεί μέχρις ότου επιλεχτεί.  Liveness (ζωντάνια) ◦ Τελικά κάποια τιμή πρέπει να επιλεχτεί ◦ Εάν μια τιμή επιλεχτεί, τότε σε βάθος χρόνου οι διεργασίες το μαθαίνουν.

 Τρεις ρόλοι  Proposers: προτείνουν τιμές  Acceptors: δέχονται τιμές ◦ Δεχτή από την πλειοψηφία  τελικά επιλέγεται  Learners: μαθαίνουν το αποτέλεσμα (πχ, η τιμή που επιλέχτηκε)  Στην πράξη μια διεργασία έχει και τους τρεις ρόλους.

 Ας έχουμε έναν acceptor ο οποίος δέχεται την πρώτη τιμή που του προτείνεται.  A0 Spof! P0 P1 P2 A0 V: 0 V: 10 V: 3

 Ας έχουμε πολλαπλούς acceptors; Ο κάθε ένας δέχεται την πρώτη πρόταση και όλοι διαλέγουν την πλειοψηφία. P0 P1 P2 A1 A0 A2 V: 0 V: 10 V: 3

 Εάν προταθούν τρεις τιμές? P0 P1 P2 A1 A0 A2 V: 0 V: 10 V: 3

 Ας αφήσουμε έναν acceptor να δεχτεί πολλαπλές προτάσεις. ◦ «Ελπίδα» ότι μια από τις πολλές προτάσεις που δέχτηκε θα έχει τον ψήφο της πλειοψηφίας  Paxos: Πως διαλέγουμε μια τιμή όταν υπάρχουν πολλοί acceptors που δέχονται πολλές προτάσεις ταυτόχρονα?

 Κάθε proposer εξασφαλίζει ότι: ◦ Εάν μια πρόταση με τιμή V επιλεχτεί, τότε όλες οι επόμενες προτάσεις θα έχουν την ίδια τιμή V. ◦ Άπαξ και μια τιμή επιλεχτεί, καμία επόμενη πρόταση δεν μπορεί να αλλάξει το αποτέλεσμα. ◦ Αυτό επιτρέπει πολλαπλές προτάσεις να επιλεχτούν, εξασφαλίζοντας ότι όλες οι προτάσεις που τελικά θα επιλεχτούν θα έχουν την ίδια τιμή.

 Μία πρόταση τώρα έχει δύο τιμές, και όχι μια, (proposal #, value) == (N, V)  Μια πρόταση αποτελείται από 2 πεδία (proposal #, value) == (N, V) ◦ (Σε γενικές γραμμές) ένα proposal id για κάθε τιμή που προτείνεται ◦ Το proposal # είναι αυστηρά αυξανόμενο και καθολικά μοναδικό σε όλους τους proposers. ◦ Παρόλα αυτά επιλέγει μια μόνο τιμή  Πρωτόκολλο σε 3 φάσεις

 Ένας proposer διαλέγει ένα proposal id N και στέλνει ένα prepare request στους acceptors.  Οι Acceptors χρειάζεται να απαντήσουν με: ◦ Μια υπόσχεση ότι δεν θα δεχτούν άλλη πρόταση που έχει αριθμό λιγότερο από N ποτέ (για να εξασφαλιστεί ότι το πρωτόκολλο δεν θα ασχοληθεί με παλαιότερες προτάσεις) ◦ Εάν υπάρχει, την τιμή της αποδεκτής πρότασης με το proposal id μικρότερο ή ίσο του Ν.

 Εάν ένας proposer λάβει μια απάντηση από την πλειοψηφία, στέλνει ένα accept request με την πρόταση (N, V) ◦ V: το V από την πρόταση Ν με τον μεγαλύτερο αριθμό από τις απαντήσεις (δηλαδή τις αποδεκτές προτάσεις που επιστρέψανε οι acceptors από την φάση 1) ◦ Ή, εάν καμία αποδεκτή πρόταση δεν επέστρεψε από την φάση 1, οποιαδήποτε νέα τιμή για το V.  Λαμβάνοντας ένα (N, V), οι acceptors είτε: ◦ Το δέχονται ◦ Το απορρίπτουν εάν υπήρξε ένα άλλο prepare request με αριθμό μεγαλύτερο από Ν, και το απάντησαν.

 Οι Learners πρέπει να μάθουν ποια τιμή τελικά επιλέχτηκε.  Πολλοί τρόποι να το πετύχουν:  Πχ: κάθε acceptor το στέλνει σε όλους τους learners ◦ Αποτελεσματικό αλλά ακριβό  Άλλος τρόπος: Εκλογή ενός “distinguished learner” ◦ Οι Acceptors στέλνουν τα accept τους σε αυτό το process ◦ Ο distinguished learner ενημερώνει τους υπόλοιπους. ◦ Μη ανεκτικό στα σφάλματα  Μίξη και των 2: ένα σετ από distinguished learners

31

32 Αcceptor failure Proposer failure

33 Dueling proposers

 Race condition for proposals.  P0 τελειώνει την φάση1 με proposal number N0  Πριν ο P0 ξεκινήσει την φάση 2, ο P1 ξεκινά και ολοκληρώνει την phase 1 με proposal number N1 > N0.  Ο P0 κάνει την phase 2, και οι acceptors reject.  Πριν ο P1 ξεκινήσει την phase 2, ο P0 ξαναξεκινάει και τερματίζει την φάση 1 με proposal number N2 > N1.  P1 κάνει την φάση 2, οι acceptors κάνουν reject.  …(Αυτό πάει για πάντα)

 Λύση: Εκλογή ενός distinguished proposer ◦ I.e., μόνο ένας proposer  Εάν ο distinguished proposer μπορεί να επικοινωνήσει με την πλειοψηφία, το πρωτόκολλο εγγυάται liveness. ◦ Πχ, εάν μια διεργασία παίζει τρεις ρόλους, το Paxos αντέχει αστοχίες των f < 1/2 * N servers.  Η εκλογή του leader δεν έχει λυθεί (άλλο πρόβλημα αυτό).

W Chosen client Propose X consensus box client Propose W W Chosen  collects proposed values  Picks one proposed value  remembers it forever

 Get consensus on TM’s decision.  TM just learns consensus value.  TM is “stateless” RM Propose Prepared Prepared Chosen consensus box Prepared Chosen Prepared RequestCommit Prepare Commit client TMRM TM Request Commit Prepare Commit Propose Prepared Prepared Chosen

 Get consensus on each RM’s choice.  TM just combines consensus values.  TM is “stateless” RM RM1 Prepared Chosen RM2 Prepared Chosen RequestCommit Prepare Commit client TM Request Commit Prepare Commit consensus box consensus box Propose RM2 Prepared Propose RM1 Prepared RM2 Prepared Chosen Propose RM2 Prepared

Prepared Chosen Prepared Prepare Commit Propose Prepared RM1 Prepared Chosen Prepare Commit Propose RM1 Prepared RM2 Prepared Chosen Propose RM2 Prepared The Obvious ApproachPaxos Commit One fewer message delay

RM TM acceptor Consensus box Propose RM Prepared  The normal (failure-free) case  Two message delays  Can optimize Propose RM Prepared Vote RM Prepared RM Prepare d Chosen

 N RMs  2F+1 acceptors (~2F+1 TMs)  If F+1 acceptors see all RMs prepared, then transaction committed.  2F(N+1) + 3N + 1 messages 5 message delays 2 stable write delays. Client TM RM1…N Acceptors 0…2F request commit prepare prepared all prepared commit

 Two-Phase Commit ◦ 3N+1 messages ◦ N+1 stable writes ◦ 4 message delays ◦ 2 stable-write delays  Availability is compromised  Paxos Commit ◦ 3N+ 2F(N+1) +1 messages ◦ N+2F+1 stable writes ◦ 5 message delays ◦ 2 stable-write delays  Tolerates F Faults  Paxos ≡ 2PC for F = 0 •Paxos Algorithm is the basis of Google’s Global Distributed Lock Manager ◦ Chubby has F=2 (5 Acceptors)

 Paxos ◦ A consensus algorithm ◦ Handles crash-stop failures (f < 1/2 * N)  Three phases ◦ Phase 1: prepare request/reply ◦ Phase 2: accept request/reply ◦ Phase 3: learning of the chosen value

44

 Φτιάχτηκε στο Facebook  Αποθήκευε το Inbox μέχρι το 2010 (μετά γυρίσανε σε Hbase)  Ο κώδικας ανοίχτηκε το 2008  Java  Top Level Apache Project  Συγγραφείς: Avinash Lakshman, Prashant Malik  Lakshman → Επιρροές από Dynamo

 Row store  Απόλυτα κατανεμημένο  Μοντέλο δεδομένων: παρόμοιο με ΒΔ  Όχι όμως πλήρες σχεσιακό μοντέλο  Υψηλή αντοχή σε αποτυχίες  Μεγάλη κλιμακωσιμότητα (δεδομένων, όχι κόμβων)

 Symmetric ◦ No single point of failure ◦ Linearly scalable ◦ Ease of administration  Flexible partitioning, replica placement  Automated provisioning  High availability (eventual consistency) 47

 BigTable ◦ Strong consistency ◦ Sparse map data model ◦ GFS, Chubby, et al  Dynamo ◦ O(1) distributed hash table (DHT) ◦ BASE (aka eventual consistency) ◦ Client tunable consistency/availability 48

 Consistent Hashing ◦ Routing, Load balancing, Replica placement  Vector Clocks ◦ Concurrent updates  Gossip Protocol  Hinted Handoffs ◦ Failure detection/recovery 49

Οργάνωση δεδομένων σε κελιά/στήλες και API για ανάγνωση/εγγραφή 50

 Όπως του BigTable  Μονάδα δεδομένων: στήλη (Column)  Περιέχονται σε Οικογένεις στηλών (Column Families) – αντίστοιχο των πινάκων των ΣΒΔ  Μπορούν να είναι και Υπερ-στήλες (περιέχουν άλλες στήλες μέσα) namevaluetimestamp

 Οικογένειες στηλών: • Περιέχουν στήλες • Δυναμικές – δεν έχουν προκαθορισμένες στήλες • Αραιές – αποθηκεύονται μόνο όσες στήλες υπάρχουν σε κάθε σειρά • Ταξινόμηση στηλών: ως αριθμοί, ως αλφαριθμητικά κ.ο.κ. • «Περιέχονται» μέσα στο πεδίο κλειδιών (keyspace)

 Πεδίο κλειδιών – αντίστοιχο της ΒΔ, περιέχει ΟΣ (πίνακες), που περιέχουν Στήλες (τιμές)  Κάθε κλειδί → μια σειρά από Στήλες σε διάφορες ΟΣ key CF1 column CF2

tom People CF “name”:“Tom”“job”:“serf”“height”:“average” “name”:“Dick”“breed”:“poodle” Dogs CFkey dick“name”:“Dick”“job”:“IT”“weight”:“heavy” harry“name”:“Harry”“job”:“OBG”“pay”:“2000” rex “name”:“Rex” “breed”:“German shepherd”

 Απλό API, που θυμίζει DHT:  insert (keyspace, key, rowMutation) εισαγωγή τιμής  get (keyspace, key, columnName) ανάκτηση τιμής  delete (keyspace, key, columnName) διαγραφή τιμής  Αιτήσεις γίνονται σε οποιοδήποτε κόμβο (που ονομάζεται συντονιστής)  Μαζεύει τα αποτελέσματα και τα στέλνει στον πελάτη

• Η υλοποίηση της Cassandra έχει προσθέσει λειτουργίες • Range queries – και σε επίπεδο κλειδιών και σε επίπεδο στηλών •list get_range_slices(column_parent, predicate, range, consistency_level) • Multiget – λήψη δεδομένων από πολλές σειρές, όχι συνεχόμενες • Ευρετήρια και select •list get_indexed_slices(column_parent, index_clause, predicate, consistency_level) • Προσθήκη/αφαίρεση ΟΣ

 get(): retrieve by column name  multiget(): by column name for a set of keys  get slice(): by column name, or a range of names ◦ returning columns ◦ returning super columns  multiget slice(): a subset of columns for a set of keys  get count: number of columns or sub-columns  get range slice(): subset of columns for a range of keys 57

Consistent hashing, distributed hash table – like routing and replication and load balancing 58

59

 Χωρισμός του πεδίου κλειδιών σε κόμβους  Κάθε κόμβος: αναγνωριστικό  Υπεύθυνος: ο διάδοχος ενός κλειδιού  Δύο επιλογές:  RandomPartitioner  OrderPreservingPartitioner

 RandomPartitioner  Αναγνωριστικό από Consistent Hash Function  Ισοκατανομή φόρτου  OrderPreservingPartitioner  Αναγνωριστικό: string  Εξυπηρέτηση ερωτημάτων διαστήματος  Ωστόσο, κακή κατανομή φόρτου  Λύνεται με διάφορους τρόπους:  Επιλογή σημείου εισαγωγής  Χειροκίνητα  Διαχωρισμό δεδομένων που χρειάζονται OP

62

63

64

65

 Distributed Hash Table (Peer to Peer)  Routing tables  Getting B with 3 hops

67

68

 insert(): add/update column (by key)  batch insert(): add/update multiple columns (by key)  remove(): remove a column  batch mutate(): like batch insert() but can also delete  (new for 0.6, deprecates batch insert())  Remove key range RSN 69

tomΣτήλες… dick Στήλες … harry Στήλες … rex Στήλες … ID κόμβου: “door” ID κόμβου: “wide” People CFkeyDogs CF Κάθε κόμβος αποθηκεύει όλες τις Στήλες που σχετίζονται με μια σειρά από κλειδιά sid Στήλες … Μια νέα σειρά θα αποθηκευθεί στον κατάλληλο κόμβο

 Όλα γράφονται αρχικά στη μνήμη, ως ένα κατώφλι  Όταν ξεπεραστεί, dump στο δίσκο σε μορφή SSTable  Για κάθε Οικογένεια στηλών:  Bloom Filter  Index  Data  Ταξινομημένα κατά κλειδί  Όταν τα SSTables ξεπεράσουν ένα πλήθος, συγχωνεύονται  Όλα γράφονται πρώτα σε ένα commit log

 Διατηρούνται Ν αντίγραφα  Διάφορες στρατηγικές τοποθέτησης:  SimpleSnitch  Default  N-1 successive nodes  RackInferringSnitch  Infers DC/rack from IP  PropertyFileSnitch  Configured w/ a properties file  Την αντιγραφή αναλαμβάνει ο συντονιστής  Κάθε κόμβος ξέρει την τοποθεσία των αντιγράφων οποιωνδήποτε δεδομένων

 Rack unaware: απλή επιλογή των N-1 διαδόχων  Rack/DC aware:  Τοποθέτηση του πρώτου αντιγράφου σε άλλο Rack/DataCenter  Άλλο ένα στο δικό μας DataCenter σε άλλο Rack  Είναι επεκτάσιμη – οποιαδήποτε υλοποίηση (υπάρχει και μία με ορισμό τοπολογίας σε αρχείο)

ρυθμιζόμενο επίπεδο συνέπειας 74

 Εγγραφή:  Αίτηση σε οποιοδήποτε κόμβο (coordinator)  Γράφει το νέο δεδομένο στο commit log  Ο Διαμοιραστής (Partitioner) καθορίζει σε ποιον κόμβο θα πάει το αντικείμενο και τα αντίγραφά του  Οι κόμβοι το λαμβάνουν, το γράφουν σε MemTable (πίνακας στη μνήμη)  Εάν χρειαστεί, κάνουν εξαγωγή σε SSTable (πίνακας στο δίσκο)  Εάν κόμβος πεσμένος, Hinted Handoff

 Ανάγνωση:  Αίτηση σε οποιονδήποτε κόμβο (coordinator)  Ο Διαμοιραστής επιστρέφει τους κόμβους όπου υπάρχει το αντικείμενο ή αντίγραφό του  Αιτήσεις για αριθμό αντιγράφων ανάλογα με το Consistency level (βλ. παρακάτω)  Read repair: εάν λήφθηκαν «μπαγιάτικες» (stale) απαντήσεις, ο κόμβος τους στέλνει την τελευταία έκδοση του δεδομένου

LevelBehavior ANYWritten to at least 1 node(including HH) ONE1 replica’s commit log and memory table QUORUMN/2+1 replicas LOCAL_QUORUMN/2+1 replicas within local D.C.(only with cross D.C. strategy) EACH_QUORUMN/2+1 replicas each D.C.(only with cross D.C. strategy) ALLWritten to all replicas

LevelBehavior ANYNot supported ONEReturns record returned by first replica to respond QUORUMReturns record with most recent timestamp once at least N/2+1 replicas reported. LOCAL_QUORUMReturns record with most recent timestamp once at least N/2+1 replicas reported within local D.C. EACH_QUORUMReturns record with most recent timestamp once at least N/2+1 replicas reported within each D.C. ALLReturns record with most recent timestamp once all replicas have responded.

 uter_science%29 uter_science%29  Lamport, Leslie (2001). Paxos Made Simple ACM SIGACT News (Distributed Computing Column) 32, 4 (Whole Number 121, December 2001)  us/um/people/lamport/pubs/paxos-simple.pdf us/um/people/lamport/pubs/paxos-simple.pdf

 dra dra  Lakshman, A. and Malik, P. Cassandra - A Decentralized Structured Storage System. in ACM SIGOPS Operating Systems Review 2010  rs/lakshman-ladis2009.pdf rs/lakshman-ladis2009.pdf

 tem) tem)  Giuseppe de Candia et al. Dynamo: amazon’s highly available key-value store. In SIGOPS, pp 205–220. ACM,  dynamo-sosp2007.pdf dynamo-sosp2007.pdf  Distributed Hash Tables και Consistent hashing  Balakrishnan, H. and Kaashoek, M.F. and Karger, D. and Morris, R. and Stoica, I. Looking up data in P2P systems in Communications of the ACM, 2003  balakrishnan.pdf balakrishnan.pdf 