NoSQL: Μη-σχεσιακές βάσεις δεδομένων για υψηλή κλιμάκωση...

Στέλιος Καραμπασάκης » [email protected]

τμήμα Πληροφορικής και Τηλεπικοινωνιών ΕΚΠΑ

ΠΜΣ 510 – Θέματα Εφαρμογών Βάσεων Δεδομένων

3/47

Κλιμάκωση • σε μεγάλους όγκους δεδομένων

» δυνατότητα προσθήκης νέων servers

• σε υψηλούς ρυθμούς διεκπεραίωσης επερωτήσεων

» τόσο σε reads όσο και σε updates

• η εφαρμογή είναι πάντα διαθέσιμη

» ακόμα και σε απρόβλεπτες συνθήκες φόρτου

• όλα τα δεδομένα είναι πάντα διαθέσιμα

» ακόμα και αν μερικοί database servers τεθούν εκτός λειτουργίας

• χαμηλές καθυστερήσεις

» ακόμα και σε συμβατικό hardware

Διαθεσιμότητα

Απόδοση

25 εκ. χρήστες

1 εκ. επισκέπτες/ημέρα


55M tweets/ημέρα

600 εκ. searches/ημέρα

4/47


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

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

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/<##>

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

Αλγόριθμος: 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δίνει την περιοχή κλειδιών του στον επόμενο κόμβο

κόμβος που αφαιρείται

/

39/47


Ένας κόμβος που αφαιρείται από το 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

NoSQL: Μη-σχεσιακές βάσεις δεδομένων για υψηλή κλιμάκωση...

Technology

Transcript of NoSQL: Μη-σχεσιακές βάσεις δεδομένων για υψηλή κλιμάκωση...