Download original PPTX presentation with speaker notes in greek from: http://www.mediafire.com/?me3h3zfqkny NoSQL Grunge Logo designed by me and released to the public domain. Download as PSD or PNG from: http://www.mediafire.com/?sharekey=2644cf1d57cb17d6ab1eab3e9fa335cace0f768f8ef0a62b --------- Παρουσίαση που πραγματοποιήθηκε στις 26/5/2010 στο τμήμα Πληροφορικής και Τηλεπικοινωνιών ΕΚΠΑ, στα πλαίσια του μεταπτυχιακού μαθήματος "Θέματα Εφαρμογών Βάσεων Δεδομένων"

1. Στέλιος Καραμπασάκης » grad0946@di.uoa.gr
τμήμα Πληροφορικής και Τηλεπικοινωνιών ΕΚΠΑ
ΠΜΣ 510 – Θέματα Εφαρμογών Βάσεων Δεδομένων

2.  2/47

3. Κλιμάκωση • σε μεγάλους όγκους δεδομένων
» δυνατότητα προσθήκης νέων servers
• σε υψηλούς ρυθμούς διεκπεραίωσης επερωτήσεων
» τόσο σε reads όσο και σε updates
Διαθεσιμότητα • η εφαρμογή είναι πάντα διαθέσιμη
» ακόμα και σε απρόβλεπτες συνθήκες φόρτου
• όλα τα δεδομένα είναι πάντα διαθέσιμα
» ακόμα και αν μερικοί database servers τεθούν εκτός λειτουργίας
Απόδοση • χαμηλές καθυστερήσεις
» ακόμα και σε συμβατικό hardware
 3/47

4. 25 εκ. χρήστες 100 εκ. χρήστες
1 εκ. επισκέπτες/ημέρα 55M tweets/ημέρα
600 εκ. searches/ημέρα
500 εκ. χρήστες 200 data clusters
120 εκ. queries/sec Query throughput: 40GB/sec/cluster
>10PB δεδομένων
 4/47

5. Ask Ron, our Systems Engineering Lead,
the exact number of servers we have in
production and he'll probably respond
with “I don't honestly know”.
– digg.com
 5/47

6.  6/47

7.  Normalization  Transactions
• Joins  ACID properties
 Foreign keys • Atomicity
 Indexes • Consistency
 SQL parsing • Isolation
• Durability
 Query optimization
 Security/Authentication
 Persistent storage
 7/47

8.  Normalization  Transactions
• Joins  ACID properties
 Foreign keys • Atomicity
 Indexes • Consistency
 SQL parsing • Isolation
• Durability
 Query optimization
 Security/Authentication
 Persistent storage
 8/47

9. Scaling Up Προσθέστε CPU και RAM στον server
Denormalization Εισάγετε πλεονασμό για να αποφύγετε τα joins
Distributed Caching Χρησιμοποιήστε το memcached
Replication Μοιράστε το φόρτο σε πολλαπλά αντίγραφα
Master-Slave Ένας master για τα writes & πολλαπλοί slaves για τα reads
Multi-master Πολλαπλοί masters για τα writes & πολλαπλοί slaves για τα reads
Partitioning Τεμαχίστε τη βάση σε μικρότερα κομμάτια
Vertical Partitioning Βάλτε διαφορετικά tables σε διαφορετικούς servers
Horizontal Partitioning Σπάστε ένα μεγάλο πίνακα σε μικρότερους
Sharding Απλώστε ένα μεγάλο πίνακα κατά μήκος πολλών servers
 9/47

10. Our growth has forced us into
horizontal and vertical partitioning
strategies that have eliminated most of
the value of a relational database,
while still incurring all the overhead.
– Digg.com
 10/47

11.  11/47

12. χαλασμένος
δίσκος
κόπηκε το
ρεύμα!!
έπεσε το εργασίες
δίκτυο αναβάθμισης
 12/47

13. Dealing with failures in an infrastructure
comprised of millions of components is
our standard mode of operation.
– Amazon.com
 13/47

14. Οι μεγαλύτεροι δικτυακοί τόποι…
…δεν χρησιμοποιούν πια σχεσιακές βάσεις!
 14/47

15. 2004 To Google αρχίζει να αναπτύσσει για εσωτερική χρήση το δικό
του σύστημα διαχείρισης δεδομένων, το BigTable.
2005 Αρχίζει η ανάπτυξη του CouchDB
2006 Δημοσιεύεται τo paper του BigTable.
2007 Το Amazon δημοσιεύει το paper του Dynamo και ξεκινάει την
υπηρεσία Amazon S3 που βασίζεται στο Dynamo.
2008 Το Google δίνει πρόσβαση στο BigTable στο κοινό, μέσω του
Google App Engine
2008 To Facebook ανοίγει τον κώδικα του Cassandra, ενός
συστήματος εμπνευσμένου από το BigTable και το Dynamo.
2008 To LinkedIn ξεκινάει το Project Voldemort.
 15/<##>

16.  16/47

17.  17/47

18.  18/47

19. Availability
Consistency Partition
tolerance
διαλέξτε δύο από τα τρία
 19/47

20. Availability
Consistency Partition
tolerance
διαλέξτε δύο από τα τρία
 20/47

21. Κλιμάκωση = Κατανεμημένα
+ Οριζόντιο partitioning
+ Όχι JOINs
+ Ελαφριές δοσοληψίες
Διαθεσιμότητα = Replication
+ ασθενής συνέπεια
Απόδοση = Ελεγχόμενο latency
+ Απουσία access control
 21/47

22. ΟΧΙ σχεσιακό μοντέλο ΑΛΛΑ μη σχεσιακά data models
ΟΧΙ SQL ΑΛΛΑ απλουστευμένα query API’s
ΟΧΙ ισχυρή συνέπεια ΑΛΛΑ eventual consistency
OXI κεντρικοποιημένα ΑΛΛΑ δυναμικό partitioning
αυτόματο replication
load balancing
 22/47

23. Μη σχεσιακά, schema-less, σχεδιασμένα για εύκολο partitioning
 23/47

24.  Σχεδιασμένα για εύκολο partitioning
• Ουσιαστικά, πρόκειται για διευρυμένα DHT’s
 Single object operations
• Κάθε read επιστρέφει μία μόνο εγγραφή.
• Κάθε update επιδρά σε μία μόνο εγγραφή.
• Ατομικότητα υποστηρίζεται μόνο σε επίπεδο μεμονωμένης εγγραφής
• Δεν υπάρχουν JOINs
 Object versioning
• Το σύστημα μπορεί να αποθηκεύει προηγούμενες εκδόσεις ενός αντικειμένου
 Καλύπτουν ορισμένα use cases καλύτερα από το σχεσιακό μοντέλο
• Αραιά δεδομένα
• Συνεργατική επεξεργασία (π.χ. Wikipedia, Google Docs)
• Κοινωνικός γράφος
• Αρχεία καταγραφής
 24/47

25. Key-value
Column
<person>
<firstname>John</firstname>
Document <lastname>Smith</lastname>
<phone type="home">212 555-1234</phone>
<phone type="fax">646 555-4567</phone>
</person>
 25/47

26. Μοντέλο δεδομένων: πίνακας κατακερματισμού
κλειδί τιμή
(ένα hash) (ένα blob)
 26/47

27. Μοντέλο δεδομένων: αραιό πολυδιάστατο ταξινομημένο ευρετήριο
κλειδιά στήλες
(ταξινομημένα)
f1:col f2:col f3:col1 f3:col2 f3:col3 f999:col
...
οικογέμεια στηλώμ
(προσπελαύνονται μαζί)
 27/47

28. get (key)
Key-value
put (key, context, object)
get (table, key, columnName)
Column insert (table, key, rowMutation)
delete (table, key, columnName)
 28/47

29. μετρήστε τις εμφανίσεις των λέξεων nosql και rdbms σε μια συλλογή εγγράφων
nosql rdbms nosql
συλλογή εγγράφων nosql
nosql rdbms rdbms rdbms
rdbms
mappers
ενδιάμεσα ζεύγη k-v <nosql,1> <nosql,1><rdbms,1> <rdbms,2> <nosql,2><rdbms,1> <rdbms,1>
reducers nosql rdbms
αποτελέσματα 4 5
 29/47

30. Οι αστοχίες είναι αναπόφευκτες.
Για να πετύχουμε υψηλή διαθεσιμότητα, θυσιάζουμε τη συνέπεια.
 30/47

31.  Η ισχυρή συνέπεια είναι σύγχρονη.
• Η δοσοληψία δεν θεωρείται ολοκληρωμένη παρά μόνο αν ενημερωθούν
όλα τα αντίγραφα
 Η eventual consistency είναι ασύγχρονη.
• Τα αντίγραφα ενημερώνονται στο παρασκήνιο, χωρίς να μπλοκάρουν
την ολοκλήρωση της δοσοληψίας
 Μετά από κάποια αστοχία, μπορεί να υπάρχουν στο σύστημα
πολλαπλές εκδόσεις ενός αντικειμένου, ασυνεπείς μεταξύ τους.
• Στα κατανεμημένα συστήματα δεν υπάρχει «καθολικό ρολόι». Άρα, πως
μπορούμε να ξέρουμε ποια έκδοση είναι η «τελική»;
• Λύση: vector clocks
 31/47

32.  32/47

33. Αλγόριθμος: Consistent Hashing
 33/47

34. 63 0
56 8
 Το πεδίο των κλειδιών
σχηματίζει ένα δακτύλιο
48 16
40 24
32
δακτύλιος
64 κλειδιώμ
 34/47

35. κόμβος
 Σε κάθε κόμβο ανατίθεται μία
τυχαία θέση στο δακτύλιο.
 35/47

36. κόμβος
 Κάθε κόμβος είναι υπεύθυνος
για την περιοχή κλειδιών
μεταξύ της θέσης του και της
περιοχή
θέσης του κόμβου που κλειδιώμ
προηγείται.
 Όταν καλούμε μια λειτουργία
που αναφέρεται στο κλειδί k,
το αίτημά μας προωθείται
στον κόμβο που είναι
υπεύθυνος για το κλειδί k
 36/47

37.  Ένας νέος κόμβος που
εισέρχεται στο cluster
αναλαμβάνει τμήμα της
περιοχής κλειδιών του
επόμενου κόμβου
μέος
κόμβος
 37/47

38.  Ένας νέος κόμβος που
εισέρχεται στο cluster
αναλαμβάνει τμήμα της
περιοχής κλειδιών του
επόμενου κόμβου
 Ένας κόμβος που
αφαιρείται από το cluster
δίνει την περιοχή κλειδιών
του στον επόμενο κόμβο
/
κόμβος που
αφαιρείται
 38/47

39.  Ένας νέος κόμβος που
εισέρχεται στο cluster
αναλαμβάνει τμήμα της
περιοχής κλειδιών του
επόμενου κόμβου
 Ένας κόμβος που
αφαιρείται από το cluster
δίνει την περιοχή κλειδιών
του στον επόμενο κόμβο
Η εισαγωγή και η αφαίρεση
κόμβων σε ένα cluster επηρεάζει /
μόνο τους γειτονικούς κόμβους κόμβος που
αφαιρείται
 39/47

40. Η τυχαία τοποθέτηση των
κόμβων επάνω στο δακτύλιο
που κάνει ο αλγόριθμος
consistent hashing
δεν εξασφαλίζει καλή
κατανομή του φόρτου
μεταξύ των κόμβων.
 40/47

41. Παραλλαγές του consistent hashing για καλύτερο καταμερισμό φόρτου
 41/47

42.  Έστω ότι στο cluster
συμμετέχουν P κόμβοι.
 Κάθε κόμβος εισάγεται τυχαία
σε V θέσεις στο δακτύλιο, παράδειγμα
οπότε αναλαμβάνει την P=4 κόμβοι
ευθύνη V περιοχών. V=3 περιοχές/κόμβο
 Ένας νέος κόμβος που
εισάγεται στο cluster παίρνει
κλειδιά από V γείτονες
 Ένας κόμβος που αφαιρείται
από το cluster μοιράζει τα
κλειδιά του σε V γείτονες.
 42/47

43.  Οι κόμβοι ανταλλάσσουν
μεταξύ τους πληροφορίες
σχετικά με την κατάσταση του
φόρτου τους.
 Κόμβοι με χαμηλό φόρτο
μετακινούνται επάνω στο
δακτύλιο, αναλαμβάνοντας
τμήμα της περιοχής κλειδιών
από κόμβους με υψηλό
φόρτο.
 43/47

44. Απαραίτητο για υψηλή διαθεσιμότητα
 44/47

45.  Τα δεδομένα κάθε κόμβου
αναπαράγονται και στους
επόμενους N-1 κόμβους
 Οι Ν κόμβοι που περιέχουν παράδειγμα
ένα αντίγραφο του Ν=4 κόμβοι
αντικειμένου με κλειδί k
ορίζουν μια λίστα
προτίμησης για το κλειδί k
 Τα Ν αντίγραφα του
αντικειμένου k μπορεί να
είναι μη συνεπή μεταξύ
τους.
 45/47

46.  Ένα αίτημα get επιτυγχάνει όταν
R από τους Ν κόμβους
επιστρέψουν την ίδια τιμή
 Ένα αίτημα put επιτυγχάνει όταν
W από τους Ν κόμβους
επιστρέψουν μήνυμα ότι η
εγγραφή πέτυχε.
• Οι τιμές των παραμέτρων R,W,N
επιλέγονται από το διαχειριστή ή
τον προγραμματιστή
• Trade-off ανάμεσα σε consistency
και latency
 46/47

47.  Amazon Dynamo  Scalaris
Key-value
 Voldemort
 Google BigTable  Hbase
Column
 Cassandra  Hyperbase
 CouchDB  Riak
Document
 MongoDB
 47/47

48.  F. Chang et al., Bigtable: A distributed storage system for structured data, in
Proceedings of the 7th USENIX Symposium on Operating Systems Design and
Implementation (OSDI’06), 2006, http://labs.google.com/papers/bigtable.html
 Giuseppe DeCandia et al., Dynamo: Amazon’s Highly Available Key-value Store, in
Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles
(Stevenson, Washington, USA: ACM, 2007), 205-220,
http://portal.acm.org/citation.cfm?id=1294261.1294281
 A. Lakshman and P. Malik, Cassandra-A Decentralized Structured Storage System (2007),
http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf
 S. Das et al., Clouded Data: Comprehending Scalable Data Management Systems,
Technical Report 2008-18, UCSB, 2008.
 48/47