Προγραμματισμός

Πότε να χρησιμοποιήσετε μια βάση δεδομένων που βασίζεται σε CRDT

Ο Roshan Kumar είναι ανώτερος διευθυντής προϊόντων στο Redis Labs.

Η κάμψη της συνοχής και της διαθεσιμότητας, όπως περιγράφεται από το θεώρημα της ΚΓΠ, ήταν μια μεγάλη πρόκληση για τους αρχιτέκτονες των γεωδιανεμημένων εφαρμογών. Το διαμέρισμα δικτύου είναι αναπόφευκτο. Η υψηλή καθυστέρηση μεταξύ των κέντρων δεδομένων οδηγεί πάντα σε κάποια αποσύνδεση μεταξύ των κέντρων δεδομένων για μικρό χρονικό διάστημα. Έτσι, οι παραδοσιακές αρχιτεκτονικές για γεω-κατανεμημένες εφαρμογές έχουν σχεδιαστεί είτε για να εγκαταλείψουν τη συνοχή των δεδομένων είτε να επηρεάσουν τη διαθεσιμότητα.

Δυστυχώς, δεν μπορείτε να θυσιάσετε τη διαθεσιμότητα για διαδραστικές εφαρμογές χρηστών. Τους τελευταίους χρόνους, οι αρχιτέκτονες έκαναν μια συνοχή και αγκάλιασαν το τελικό μοντέλο συνέπειας. Σε αυτό το μοντέλο, οι εφαρμογές εξαρτώνται από το σύστημα διαχείρισης βάσεων δεδομένων για να συγχωνεύσουν όλα τα τοπικά αντίγραφα των δεδομένων για να τα καταστήσουν τελικά συνεπή.

Όλα φαίνονται καλά με το τελικό μοντέλο συνέπειας έως ότου υπάρξουν διενέξεις δεδομένων. Μερικά μοντέλα ενδεχόμενης συνέπειας υπόσχονται την καλύτερη προσπάθεια για την επίλυση των συγκρούσεων, αλλά δεν εγγυώνται ισχυρή συνέπεια. Τα καλά νέα είναι ότι, τα μοντέλα που βασίζονται σε τύπους δεδομένων χωρίς αντιπαραθέσεις (CRDTs) προσφέρουν ισχυρή ενδεχόμενη συνοχή.

Τα CRDT επιτυγχάνουν ισχυρή τελική συνέπεια μέσω ενός προκαθορισμένου συνόλου κανόνων και σημασιολογίας επίλυσης συγκρούσεων. Οι εφαρμογές που βασίζονται σε βάσεις δεδομένων που βασίζονται σε CRDT πρέπει να είναι σχεδιασμένες για να εξυπηρετούν τη σημασιολογία επίλυσης συγκρούσεων. Σε αυτό το άρθρο θα διερευνήσουμε πώς να σχεδιάζουμε, να αναπτύσσουμε και να δοκιμάζουμε γεω-κατανεμημένες εφαρμογές χρησιμοποιώντας μια βάση δεδομένων που βασίζεται σε CRDT. Θα εξετάσουμε επίσης τέσσερις περιπτώσεις δειγματοληψίας: μετρητές, κατανεμημένη προσωρινή μνήμη, κοινόχρηστες περιόδους σύνδεσης και απορρόφηση δεδομένων σε πολλές περιοχές.

Ο εργοδότης μου, η Redis Labs, ανακοίνωσε πρόσφατα την υποστήριξη CRDT στο Redis Enterprise, με τύπους δεδομένων χωρίς αντιπαραθέσεις που εντάσσονται στο πλούσιο χαρτοφυλάκιο δομών δεδομένων - String, Hashes, Lists, Sets, Sorted Sets, Bitfields, Geo, Hyperloglog και Streams - στο το προϊόν της βάσης δεδομένων μας. Ωστόσο, η ακόλουθη συζήτηση ισχύει όχι μόνο για το Redis Enterprise, αλλά και για όλες τις βάσεις δεδομένων που βασίζονται σε CRDT.

Βάσεις δεδομένων για γεω-κατανεμημένες εφαρμογές

Για γεω-κατανεμημένες εφαρμογές, είναι σύνηθες να εκτελείτε υπηρεσίες τοπικά στους πελάτες. Αυτό μειώνει την κίνηση του δικτύου και τον λανθάνοντα χρόνο που προκαλείται από την επιστροφή. Σε πολλές περιπτώσεις, οι αρχιτέκτονες σχεδιάζουν τις υπηρεσίες για σύνδεση σε τοπική βάση δεδομένων. Έπειτα έρχεται το ερώτημα για το πώς διατηρείτε σταθερά δεδομένα σε όλες τις βάσεις δεδομένων. Μια επιλογή είναι να το χειριστείτε σε επίπεδο εφαρμογής - μπορείτε να γράψετε μια περιοδική διαδικασία εργασίας που θα συγχρονίζει όλες τις βάσεις δεδομένων. Ή μπορείτε να βασιστείτε σε μια βάση δεδομένων που θα συγχρονίζει τα δεδομένα μεταξύ των βάσεων δεδομένων.

Για το υπόλοιπο άρθρο, υποθέτουμε ότι θα ακολουθήσετε τη δεύτερη επιλογή — αφήστε τη βάση δεδομένων να κάνει τη δουλειά. Όπως φαίνεται στο σχήμα 1 παρακάτω, η γεω-κατανεμημένη εφαρμογή σας εκτελεί υπηρεσίες σε πολλές περιοχές, με κάθε υπηρεσία να συνδέεται με μια τοπική βάση δεδομένων. Το υποκείμενο σύστημα διαχείρισης βάσεων δεδομένων συγχρονίζει τα δεδομένα μεταξύ των βάσεων δεδομένων που αναπτύσσονται σε όλες τις περιοχές.

Εργαστήρια Redis

Μοντέλα συνοχής δεδομένων

Ένα μοντέλο συνέπειας είναι ένα συμβόλαιο μεταξύ της κατανεμημένης βάσης δεδομένων και της εφαρμογής που καθορίζει το πόσο καθαρά είναι τα δεδομένα μεταξύ λειτουργιών εγγραφής και ανάγνωσης.

Για παράδειγμα, σε ένα μοντέλο ισχυρής συνοχής, η βάση δεδομένων εγγυάται ότι οι εφαρμογές θα διαβάζουν πάντα την τελευταία εγγραφή. Με διαδοχική συνέπεια, η βάση δεδομένων διασφαλίζει ότι η σειρά των δεδομένων που διαβάζετε είναι συνεπής με τη σειρά με την οποία γράφτηκαν στη βάση δεδομένων. Στο μοντέλο της τελικής συνέπειας, η κατανεμημένη βάση δεδομένων υπόσχεται να συγχρονίσει και να ενοποιήσει τα δεδομένα μεταξύ των αντιγράφων της βάσης δεδομένων πίσω από τα παρασκήνια. Επομένως, εάν γράψετε τα δεδομένα σας σε ένα αντίγραφο βάσης δεδομένων και τα διαβάσετε από άλλο, είναι πιθανό ότι δεν θα διαβάσετε το τελευταίο αντίγραφο των δεδομένων.

Ισχυρή συνέπεια

Η δέσμευση δύο φάσεων είναι μια κοινή τεχνική για την επίτευξη ισχυρής συνοχής. Εδώ, για κάθε λειτουργία εγγραφής (προσθήκη, ενημέρωση, διαγραφή) σε έναν τοπικό κόμβο βάσης δεδομένων, ο κόμβος βάσης δεδομένων μεταδίδει τις αλλαγές σε όλους τους κόμβους βάσης δεδομένων και περιμένει να αναγνωριστούν όλοι οι κόμβοι. Ο τοπικός κόμβος έπειτα στέλνει μια δέσμευση σε όλους τους κόμβους και περιμένει μια άλλη αναγνώριση. Η εφαρμογή θα μπορεί να διαβάσει τα δεδομένα μόνο μετά τη δεύτερη δέσμευση. Η κατανεμημένη βάση δεδομένων δεν θα είναι διαθέσιμη για εργασίες εγγραφής όταν το δίκτυο αποσυνδέεται μεταξύ των βάσεων δεδομένων.

Τελική συνέπεια

Το κύριο πλεονέκτημα του μοντέλου ενδεχόμενης συνέπειας είναι ότι η βάση δεδομένων θα είναι στη διάθεσή σας για να εκτελείτε εργασίες εγγραφής, ακόμη και όταν η διασύνδεση δικτύου μεταξύ των κατανεμημένων αντιγράφων βάσης δεδομένων διακόπτεται. Σε γενικές γραμμές, αυτό το μοντέλο αποφεύγει το χρόνο μετ 'επιστροφής που προκύπτει από τη δέσμευση δύο φάσεων, και ως εκ τούτου υποστηρίζει πολύ περισσότερες λειτουργίες εγγραφής ανά δευτερόλεπτο από τα άλλα μοντέλα. Ένα πρόβλημα που ενδεχομένως πρέπει να αντιμετωπίσει η συνέπεια είναι οι συγκρούσεις - ταυτόχρονη εγγραφή στο ίδιο αντικείμενο σε δύο διαφορετικές τοποθεσίες. Με βάση τον τρόπο αποφυγής ή επίλυσης διενέξεων, οι τελικά συνεπείς βάσεις δεδομένων ταξινομούνται περαιτέρω στις ακόλουθες κατηγορίες:

  1. Ο τελευταίος συγγραφέας κερδίζει (LWW). Σε αυτήν τη στρατηγική, οι κατανεμημένες βάσεις δεδομένων βασίζονται στον συγχρονισμό χρονικής σήμανσης μεταξύ των διακομιστών. Οι βάσεις δεδομένων ανταλλάσσουν τη χρονική σήμανση κάθε λειτουργίας εγγραφής μαζί με τα ίδια τα δεδομένα. Σε περίπτωση διένεξης, κερδίζει η λειτουργία εγγραφής με την πιο πρόσφατη χρονική σήμανση.

    Το μειονέκτημα αυτής της τεχνικής είναι ότι προϋποθέτει ότι όλα τα ρολόγια του συστήματος είναι συγχρονισμένα. Στην πράξη, είναι δύσκολο και ακριβό να συγχρονίσετε όλα τα ρολόγια του συστήματος.

  2. Τελική συνοχή βάσει απαρτίας: Αυτή η τεχνική είναι παρόμοια με τη διφασική δέσμευση. Ωστόσο, η τοπική βάση δεδομένων δεν περιμένει την επιβεβαίωση από όλες τις βάσεις δεδομένων. περιμένει απλώς την αναγνώριση από την πλειονότητα των βάσεων δεδομένων. Η αναγνώριση από την πλειοψηφία δημιουργεί απαρτία. Σε περίπτωση σύγκρουσης, κερδίζει η λειτουργία εγγραφής που έχει καθορίσει την απαρτία.

    Από την άλλη πλευρά, αυτή η τεχνική προσθέτει καθυστέρηση δικτύου στις λειτουργίες εγγραφής, γεγονός που καθιστά την εφαρμογή λιγότερο επεκτάσιμη. Επίσης, η τοπική βάση δεδομένων δεν θα είναι διαθέσιμη για εγγραφές εάν απομονωθεί από τα άλλα αντίγραφα βάσης δεδομένων στην τοπολογία.

  3. Συγχώνευση αναπαραγωγής: Σε αυτήν την παραδοσιακή προσέγγιση, η οποία είναι κοινή μεταξύ των σχεσιακών βάσεων δεδομένων, ένας κεντρικός πράκτορας συγχώνευσης συγχωνεύει όλα τα δεδομένα. Αυτή η μέθοδος προσφέρει επίσης κάποια ευελιξία στην εφαρμογή των δικών σας κανόνων για την επίλυση συγκρούσεων.

    Η αναπαραγωγή συγχώνευσης είναι πολύ αργή για την υποστήριξη εφαρμογών σε πραγματικό χρόνο. Έχει επίσης ένα μόνο σημείο αποτυχίας. Καθώς αυτή η μέθοδος δεν υποστηρίζει προκαθορισμένους κανόνες για την επίλυση συγκρούσεων, οδηγεί συχνά σε εφαρμογές με λάθη για επίλυση συγκρούσεων.

  4. Αναπαραγόμενος τύπος δεδομένων χωρίς σύγκρουση (CRDT): Θα μάθετε λεπτομερώς για τα CRDTs στις επόμενες ενότητες. Με λίγα λόγια, οι βάσεις δεδομένων που βασίζονται σε CRDT υποστηρίζουν τύπους δεδομένων και λειτουργίες που παρέχουν τελική συνέπεια χωρίς σύγκρουση. Οι βάσεις δεδομένων που βασίζονται σε CRDT είναι διαθέσιμες ακόμη και όταν τα αντίγραφα κατανεμημένης βάσης δεδομένων δεν μπορούν να ανταλλάξουν τα δεδομένα. Παρέχουν πάντα τοπική καθυστέρηση στις διαδικασίες ανάγνωσης και εγγραφής.

    Περιορισμοί; Δεν επωφελούνται όλες οι περιπτώσεις χρήσης βάσης δεδομένων από CRDTs. Επίσης, η σημασιολογία επίλυσης συγκρούσεων για βάσεις δεδομένων που βασίζονται σε CRDT είναι προκαθορισμένη και δεν μπορεί να παρακαμφθεί.

Τι είναι τα CRDT;

Τα CRDT είναι ειδικοί τύποι δεδομένων που συγκλίνουν δεδομένα από όλα τα αντίγραφα βάσης δεδομένων. Τα δημοφιλή CRDT είναι μετρητές G (μετρητές μόνο για ανάπτυξη), μετρητές PN (μετρητές θετικών-αρνητικών), καταχωρητές, σετ G (σετ μόνο για ανάπτυξη), σετ 2P (σετ δύο φάσεων), σετ OR ( παρατηρούμε-αφαιρέστε σύνολα) κ.λπ. Πίσω από τα παρασκήνια, βασίζονται στις ακόλουθες μαθηματικές ιδιότητες για τη σύγκλιση των δεδομένων:

  1. Υπολογιστική ιδιότητα: a ☆ b = b ☆ α
  2. Συνεργατική ιδιοκτησία: a ☆ (b ☆ c) = (a ☆ b) ☆ c
  3. Ικανότητα: a ☆ a = α

Ένας μετρητής G είναι ένα τέλειο παράδειγμα ενός λειτουργικού CRDT που συγχωνεύει τις λειτουργίες. Εδώ, a + b = b + a και a + (b + c) = (a + b) + c. Τα αντίγραφα ανταλλάσσουν μόνο τις ενημερώσεις (προσθήκες) μεταξύ τους. Το CRDT θα συγχωνεύσει τις ενημερώσεις προσθέτοντάς τις. Ένα σύνολο G, για παράδειγμα, εφαρμόζει idempotence ({a, b, c} U {c} = {a, b, c}) για τη συγχώνευση όλων των στοιχείων. Το Idempotence αποφεύγει την επανάληψη στοιχείων που προστίθενται σε μια δομή δεδομένων καθώς ταξιδεύουν και συγκλίνουν μέσω διαφορετικών διαδρομών.

Τύποι δεδομένων CRDT και η σημασιολογία επίλυσης συγκρούσεων

Δομές δεδομένων χωρίς συγκρούσεις: μετρητές G, μετρητές PN, σύνολα G

Όλες αυτές οι δομές δεδομένων είναι σχεδιασμένες χωρίς συγκρούσεις. Οι παρακάτω πίνακες δείχνουν πώς συγχρονίζονται τα δεδομένα μεταξύ των αντιγράφων της βάσης δεδομένων.

Εργαστήρια Redis Εργαστήρια Redis

Οι μετρητές G και οι μετρητές PN είναι δημοφιλείς για περιπτώσεις χρήσης, όπως παγκόσμια ψηφοφορία, μετρήσεις ροής, παρακολούθηση δραστηριότητας και ούτω καθεξής. Τα σετ G χρησιμοποιούνται σε μεγάλο βαθμό για την εφαρμογή τεχνολογίας blockchain. Τα bitcoin, για παράδειγμα, χρησιμοποιούν καταχωρίσεις αποκλεισμού μόνο για προσάρτημα.

Μητρώα: Χορδές, Hashes

Τα μητρώα δεν είναι από τη φύση τους χωρίς σύγκρουση. Ακολουθούν συνήθως τις πολιτικές του LWW ή την επίλυση συγκρούσεων βάσει απαρτίας. Το σχήμα 4 δείχνει ένα παράδειγμα του πώς ένα μητρώο επιλύει τη διένεξη ακολουθώντας την πολιτική LWW.

Εργαστήρια Redis

Τα μητρώα χρησιμοποιούνται κυρίως για την αποθήκευση δεδομένων προσωρινής αποθήκευσης και περιόδου λειτουργίας, πληροφοριών προφίλ χρήστη, καταλόγου προϊόντων κ.λπ.

2P-σετ

Τα σετ δύο φάσεων διατηρούν δύο σύνολα G-set - ένα για πρόσθετα στοιχεία και το άλλο για αντικείμενα που έχουν αφαιρεθεί. Τα αντίγραφα ανταλλάσσουν τις προσθήκες G-set όταν συγχρονίζονται. Η σύγκρουση προκύπτει όταν το ίδιο στοιχείο βρίσκεται και στα δύο σύνολα. Σε ορισμένες βάσεις δεδομένων που βασίζονται σε CRDT, όπως το Redis Enterprise, αυτό διαχειρίζεται η πολιτική, "Προσθήκη νικών κατά τη διαγραφή".

Εργαστήρια Redis

Το σετ 2P είναι μια καλή δομή δεδομένων για την αποθήκευση κοινόχρηστων δεδομένων συνεδρίας, όπως καλάθι αγορών, κοινόχρηστο έγγραφο ή υπολογιστικό φύλλο.

Πώς να δημιουργήσετε μια εφαρμογή για να χρησιμοποιήσετε μια βάση δεδομένων που βασίζεται σε CRDT

Η σύνδεση της εφαρμογής σας με βάση δεδομένων CRDT δεν διαφέρει από τη σύνδεση της εφαρμογής σας με οποιαδήποτε άλλη βάση δεδομένων. Ωστόσο, λόγω των τελικών πολιτικών συνέπειας, η εφαρμογή σας πρέπει να ακολουθεί ένα συγκεκριμένο σύνολο κανόνων για να προσφέρει μια συνεπή εμπειρία χρήστη. Τρία κλειδιά: 

  1. Κάντε την αίτησή σας απάτριδα. Μια εφαρμογή χωρίς κατάσταση είναι συνήθως API. Κάθε κλήση σε ένα API έχει ως αποτέλεσμα την ανακατασκευή του πλήρους μηνύματος από το μηδέν. Αυτό διασφαλίζει ότι τραβάτε πάντα ένα καθαρό αντίγραφο δεδομένων ανά πάσα στιγμή. Ο χαμηλός τοπικός λανθάνων χρόνος που προσφέρεται από μια βάση δεδομένων που βασίζεται σε CRDT καθιστά την ανακατασκευή μηνυμάτων ταχύτερη και ευκολότερη. 

  2. Επιλέξτε το σωστό CRDT που ταιριάζει στη θήκη χρήσης σας. Ο μετρητής είναι ο απλούστερος των CRDTs. Μπορεί να εφαρμοστεί για περιπτώσεις χρήσης, όπως η παγκόσμια ψηφοφορία, η παρακολούθηση ενεργών συνεδριών, η μέτρηση κ.λπ. Ωστόσο, εάν θέλετε να συγχωνεύσετε την κατάσταση των κατανεμημένων αντικειμένων, τότε πρέπει επίσης να λάβετε υπόψη και άλλες δομές δεδομένων. Για παράδειγμα, για μια εφαρμογή που επιτρέπει στους χρήστες να επεξεργάζονται ένα κοινόχρηστο έγγραφο, ίσως θελήσετε να διατηρήσετε όχι μόνο τις τροποποιήσεις, αλλά και τη σειρά με την οποία πραγματοποιήθηκαν. Σε αυτήν την περίπτωση, η αποθήκευση των τροποποιήσεων σε μια λίστα που βασίζεται σε CRDT ή μια δομή δεδομένων ουράς θα ήταν μια καλύτερη λύση από την αποθήκευσή τους σε ένα μητρώο. Είναι επίσης σημαντικό να κατανοήσετε τη σημασιολογία επίλυσης συγκρούσεων που επιβάλλεται από τα CRDT και ότι η λύση σας συμμορφώνεται με τους κανόνες.
  3. Το CRDT δεν είναι μια λύση για όλα τα μεγέθη. Ενώ το CRDT είναι πράγματι ένα εξαιρετικό εργαλείο για πολλές περιπτώσεις χρήσης, μπορεί να μην είναι το καλύτερο για όλες τις περιπτώσεις χρήσης (για παράδειγμα, συναλλαγές με ACID). Οι βάσεις δεδομένων που βασίζονται σε CRDT ταιριάζουν γενικά με την αρχιτεκτονική των μικροϋπηρεσιών όπου διαθέτετε μια ειδική βάση δεδομένων για κάθε μικροϋπηρεσία.

Η κύρια αποστολή εδώ είναι ότι η εφαρμογή σας πρέπει να επικεντρωθεί στη λογική και να μεταβιβάσει την πολυπλοκότητα διαχείρισης δεδομένων και συγχρονισμού στην υποκείμενη βάση δεδομένων.

Δοκιμή εφαρμογών με μια κατανεμημένη βάση πολλαπλών κύριων δεδομένων

Για να επιτύχετε ταχύτερη μετάβαση στην αγορά, σας συνιστούμε να έχετε μια συνεπή ρύθμιση ανάπτυξης, δοκιμών, στάσης και παραγωγής. Μεταξύ άλλων, αυτό σημαίνει ότι η ανάπτυξη και η δοκιμή σας πρέπει να έχουν ένα μικροσκοπικό μοντέλο της κατανεμημένης βάσης δεδομένων σας. Ελέγξτε εάν η βάση δεδομένων σας με βάση το CRDT είναι διαθέσιμη ως κοντέινερ Docker ή εικονική συσκευή. Αναπτύξτε τα αντίγραφα της βάσης δεδομένων σας σε διαφορετικά υποδίκτυα, ώστε να μπορείτε να προσομοιώσετε τη σύνδεση συμπλεγμάτων συνδεδεμένων και αποσυνδεδεμένων.

Ο έλεγχος εφαρμογών με μια κατανεμημένη βάση πολλαπλών κύριων δεδομένων μπορεί να ακούγεται περίπλοκη. Αλλά τις περισσότερες φορές το μόνο που θα δοκιμάσετε είναι η συνοχή των δεδομένων και η διαθεσιμότητα των εφαρμογών σε δύο περιπτώσεις: Όταν οι κατανεμημένες βάσεις δεδομένων είναι συνδεδεμένες και όταν υπάρχει ένα διαμέρισμα δικτύου μεταξύ των βάσεων δεδομένων.

Με τη δημιουργία μιας κατανεμημένης βάσης δεδομένων τριών κόμβων στο περιβάλλον ανάπτυξης, μπορείτε να καλύψετε (και ακόμη και να αυτοματοποιήσετε) τα περισσότερα από τα σενάρια δοκιμών στη δοκιμή μονάδας. Ακολουθούν οι βασικές οδηγίες για τη δοκιμή των εφαρμογών σας:

$config[zx-auto] not found$config[zx-overlay] not found