nosql: Μη-σχεσιακές βάσεις δεδομένων για υψηλή κλιμάκωση...
DESCRIPTION
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 στο τμήμα Πληροφορικής και Τηλεπικοινωνιών ΕΚΠΑ, στα πλαίσια του μεταπτυχιακού μαθήματος "Θέματα Εφαρμογών Βάσεων Δεδομένων"TRANSCRIPT
Στέλιος Καραμπασάκης » [email protected]
τμήμα Πληροφορικής και Τηλεπικοινωνιών ΕΚΠΑ
ΠΜΣ 510 – Θέματα Εφαρμογών Βάσεων Δεδομένων
2/47
3/47
Κλιμάκωση • σε μεγάλους όγκους δεδομένων
» δυνατότητα προσθήκης νέων servers
• σε υψηλούς ρυθμούς διεκπεραίωσης επερωτήσεων
» τόσο σε reads όσο και σε updates
• η εφαρμογή είναι πάντα διαθέσιμη
» ακόμα και σε απρόβλεπτες συνθήκες φόρτου
• όλα τα δεδομένα είναι πάντα διαθέσιμα
» ακόμα και αν μερικοί database servers τεθούν εκτός λειτουργίας
• χαμηλές καθυστερήσεις
» ακόμα και σε συμβατικό hardware
Διαθεσιμότητα
Απόδοση
25 εκ. χρήστες
1 εκ. επισκέπτες/ημέρα
100 εκ. χρήστες
55M tweets/ημέρα
600 εκ. searches/ημέρα
4/47
500 εκ. χρήστες
120 εκ. queries/sec
200 data clusters
Query throughput: 40GB/sec/cluster
>10PB δεδομένων
5/47
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
6/47
Normalization
• Joins
Foreign keys
Indexes
SQL parsing
Query optimization
Persistent storage
Transactions
ACID properties
• Atomicity
• Consistency
• Isolation
• Durability
Security/Authentication
7/47
Normalization
• Joins
Foreign keys
Indexes
SQL parsing
Query optimization
Persistent storage
Transactions
ACID properties
• Atomicity
• Consistency
• Isolation
• Durability
Security/Authentication
8/47
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/47
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
11/47
12/47
χαλασμένος δίσκος
έπεσε το δίκτυο
εργασίες αναβάθμισης
κόπηκε το ρεύμα!!
13/47
Dealing with failures in an infrastructure comprised of millions of components is our standard mode of operation.
– Amazon.com
Οι μεγαλύτεροι δικτυακοί τόποι…
…δεν χρησιμοποιούν πια σχεσιακές βάσεις!
14/47
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/47
17/47
18/47
Availability
Partitiontolerance
Consistency
19/47
διαλέξτε δύο από τα τρία
Availability
Partitiontolerance
Consistency
20/47
διαλέξτε δύο από τα τρία
Κλιμάκωση = Κατανεμημένα
+ Οριζόντιο partitioning
+ Όχι JOINs
+ Ελαφριές δοσοληψίες
21/47
Διαθεσιμότητα = Replication
+ ασθενής συνέπεια
Απόδοση = Ελεγχόμενο latency
+ Απουσία access control
ΟΧΙ σχεσιακό μοντέλο
ΟΧΙ SQL
ΟΧΙ ισχυρή συνέπεια
OXI κεντρικοποιημένα
ΑΛΛΑ μη σχεσιακά data models
ΑΛΛΑ απλουστευμένα query API’s
ΑΛΛΑ eventual consistency
ΑΛΛΑ δυναμικό partitioning
αυτόματο replication
load balancing
22/47
Μη σχεσιακά, schema-less, σχεδιασμένα για εύκολο partitioning
23/47
Σχεδιασμένα για εύκολο partitioning• Ουσιαστικά, πρόκειται για διευρυμένα DHT’s
Single object operations• Κάθε read επιστρέφει μία μόνο εγγραφή. • Κάθε update επιδρά σε μία μόνο εγγραφή.• Ατομικότητα υποστηρίζεται μόνο σε επίπεδο μεμονωμένης εγγραφής• Δεν υπάρχουν JOINs
Object versioning• Το σύστημα μπορεί να αποθηκεύει προηγούμενες εκδόσεις ενός αντικειμένου
Καλύπτουν ορισμένα use cases καλύτερα από το σχεσιακό μοντέλο• Αραιά δεδομένα• Συνεργατική επεξεργασία (π.χ. Wikipedia, Google Docs)• Κοινωνικός γράφος• Αρχεία καταγραφής
24/47
Key-value
25/47
Column
Document
<person><firstname>John</firstname><lastname>Smith</lastname> <phone type="home">212 555-1234</phone><phone type="fax">646 555-4567</phone>
</person>
26/47
κλειδί
(ένα hash)
τιμή
(ένα blob)
Μοντέλο δεδομένων: πίνακας κατακερματισμού
f1:col f2:col f3:col1 f3:col2 f3:col3 f999:col
...
27/47
κλειδιά
(ταξινομημένα)
οικογέμεια στηλώμ(προσπελαύνονται μαζί)
Μοντέλο δεδομένων: αραιό πολυδιάστατο ταξινομημένο ευρετήριο
στήλες
get (key)
put (key, context, object)
get (table, key, columnName)
insert (table, key, rowMutation)
delete (table, key, columnName)
28/47
Key-value
Column
29/47
<nosql,1>
συλλογή εγγράφωνnosql
nosql
rdbms
rdbms nosqlnosql
rdbmsrdbmsrdbms
<nosql,1><rdbms,1> <rdbms,2> <nosql,2><rdbms,1> <rdbms,1>
nosql rdbms
4 5
μετρήστε τις εμφανίσεις των λέξεων nosql και rdbms σε μια συλλογή εγγράφων
reducers
mappers
ενδιάμεσα ζεύγη k-v
αποτελέσματα
Οι αστοχίες είναι αναπόφευκτες. Για να πετύχουμε υψηλή διαθεσιμότητα, θυσιάζουμε τη συνέπεια.
30/47
Η ισχυρή συνέπεια είναι σύγχρονη.
• Η δοσοληψία δεν θεωρείται ολοκληρωμένη παρά μόνο αν ενημερωθούν όλα τα αντίγραφα
Η eventual consistency είναι ασύγχρονη.
• Τα αντίγραφα ενημερώνονται στο παρασκήνιο, χωρίς να μπλοκάρουν την ολοκλήρωση της δοσοληψίας
Μετά από κάποια αστοχία, μπορεί να υπάρχουν στο σύστημα πολλαπλές εκδόσεις ενός αντικειμένου, ασυνεπείς μεταξύ τους.
• Στα κατανεμημένα συστήματα δεν υπάρχει «καθολικό ρολόι». Άρα, πως μπορούμε να ξέρουμε ποια έκδοση είναι η «τελική»;
• Λύση: vector clocks
31/47
32/47
Αλγόριθμος: Consistent Hashing
33/47
63 0
8
16
24
32
40
48
56
34/47
Το πεδίο των κλειδιών σχηματίζει ένα δακτύλιο
δακτύλιος 64 κλειδιώμ
35/47
Σε κάθε κόμβο ανατίθεται μία τυχαία θέση στο δακτύλιο.
κόμβος
36/47
Κάθε κόμβος είναι υπεύθυνοςγια την περιοχή κλειδιών μεταξύ της θέσης του και της θέσης του κόμβου που προηγείται.
Όταν καλούμε μια λειτουργία που αναφέρεται στο κλειδί k,το αίτημά μας προωθείται στον κόμβο που είναι υπεύθυνος για το κλειδί k
κόμβος
περιοχή κλειδιώμ
37/47
Ένας νέος κόμβος που εισέρχεται στο cluster αναλαμβάνει τμήμα της περιοχής κλειδιών του επόμενου κόμβου
μέος κόμβος
38/47
Ένας νέος κόμβος που εισέρχεται στο cluster αναλαμβάνει τμήμα της περιοχής κλειδιών του επόμενου κόμβου
Ένας κόμβος που αφαιρείται από το clusterδίνει την περιοχή κλειδιών του στον επόμενο κόμβο
κόμβος που αφαιρείται
/
39/47
Ένας νέος κόμβος που εισέρχεται στο cluster αναλαμβάνει τμήμα της περιοχής κλειδιών του επόμενου κόμβου
Ένας κόμβος που αφαιρείται από το clusterδίνει την περιοχή κλειδιών του στον επόμενο κόμβο
κόμβος που αφαιρείται
/Η εισαγωγή και η αφαίρεση κόμβων σε ένα cluster επηρεάζει μόνο τους γειτονικούς κόμβους
40/47
Η τυχαία τοποθέτηση των κόμβων επάνω στο δακτύλιοπου κάνει ο αλγόριθμος consistent hashingδεν εξασφαλίζει καλή κατανομή του φόρτουμεταξύ των κόμβων.
Παραλλαγές του consistent hashing για καλύτερο καταμερισμό φόρτου
41/47
42/47
Έστω ότι στο cluster συμμετέχουν P κόμβοι.
Κάθε κόμβος εισάγεται τυχαία σε V θέσεις στο δακτύλιο, οπότε αναλαμβάνει την ευθύνη V περιοχών.
Ένας νέος κόμβος που εισάγεται στο cluster παίρνει κλειδιά από V γείτονες
Ένας κόμβος που αφαιρείται από το cluster μοιράζει τα κλειδιά του σε V γείτονες.
παράδειγμαP=4 κόμβοι
V=3 περιοχές/κόμβο
43/47
Οι κόμβοι ανταλλάσσουν μεταξύ τους πληροφορίες σχετικά με την κατάσταση του φόρτου τους.
Κόμβοι με χαμηλό φόρτο μετακινούνται επάνω στο δακτύλιο, αναλαμβάνοντας τμήμα της περιοχής κλειδιών από κόμβους με υψηλό φόρτο.
Απαραίτητο για υψηλή διαθεσιμότητα
44/47
45/47
Τα δεδομένα κάθε κόμβου αναπαράγονται και στους επόμενους N-1 κόμβους
Οι Ν κόμβοι που περιέχουν ένα αντίγραφο του αντικειμένου με κλειδί k ορίζουν μια λίστα προτίμησης για το κλειδί k
Τα Ν αντίγραφα του αντικειμένου k μπορεί να είναι μη συνεπή μεταξύ τους.
παράδειγμαΝ=4 κόμβοι
46/47
Ένα αίτημα get επιτυγχάνει όταν R από τους Ν κόμβους επιστρέψουν την ίδια τιμή
Ένα αίτημα put επιτυγχάνει όταν W από τους Ν κόμβους επιστρέψουν μήνυμα ότι η εγγραφή πέτυχε.
• Οι τιμές των παραμέτρων R,W,N επιλέγονται από το διαχειριστή ή τον προγραμματιστή
• Trade-off ανάμεσα σε consistencyκαι latency
Google BigTable
Cassandra
Hbase
Hyperbase
47/47
Key-value
Column
Document
Amazon Dynamo
Voldemort
Scalaris
CouchDB
MongoDB
Riak
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