Το επόμενο συνέδριο HighLoad++ θα πραγματοποιηθεί στις 6 και 7 Απριλίου 2020 στην Αγία Πετρούπολη.
Λεπτομέρειες και εισιτήρια . HighLoad++ Siberia 2019. Αίθουσα "Krasnoyarsk". 25 Ιουνίου, 12:00. Διατριβές και .
Συμβαίνει ότι οι πρακτικές απαιτήσεις συγκρούονται με τη θεωρία, όπου δεν λαμβάνονται υπόψη πτυχές που είναι σημαντικές για ένα εμπορικό προϊόν. Αυτή η ομιλία παρουσιάζει μια διαδικασία επιλογής και συνδυασμού διαφορετικών προσεγγίσεων για τη δημιουργία στοιχείων Αιτιολογικής συνέπειας με βάση την ακαδημαϊκή έρευνα που βασίζεται στις απαιτήσεις ενός εμπορικού προϊόντος. Οι ακροατές θα μάθουν για τις υπάρχουσες θεωρητικές προσεγγίσεις για τα λογικά ρολόγια, την παρακολούθηση εξαρτήσεων, την ασφάλεια του συστήματος, το συγχρονισμό ρολογιού και γιατί η MongoDB συμφώνησε σε ορισμένες λύσεις.
Mikhail Tyulenev (εφεξής MT): – Θα μιλήσω για την Αιτιακή συνέπεια - αυτό είναι ένα χαρακτηριστικό που δουλέψαμε στο MongoDB. Εργάζομαι σε μια ομάδα κατανεμημένων συστημάτων, το κάναμε πριν από περίπου δύο χρόνια.
Στην πορεία, έπρεπε να εξοικειωθώ με πολλή ακαδημαϊκή έρευνα, γιατί αυτό το χαρακτηριστικό έχει μελετηθεί αρκετά καλά. Αποδείχθηκε ότι ούτε ένα άρθρο δεν ταιριάζει σε αυτό που απαιτείται σε μια βάση δεδομένων παραγωγής λόγω πολύ συγκεκριμένων απαιτήσεων που πιθανώς υπάρχουν σε οποιαδήποτε εφαρμογή παραγωγής.
Θα μιλήσω για το πώς εμείς, ως καταναλωτές της ακαδημαϊκής έρευνας, προετοιμάζουμε κάτι από αυτό που μπορούμε στη συνέχεια να παρουσιάσουμε στους χρήστες μας ως ένα έτοιμο πιάτο που είναι βολικό και ασφαλές στη χρήση.
Αιτιώδης συνέπεια. Ας ορίσουμε τις έννοιες
Αρχικά, θέλω να πω γενικά τι είναι η Αιτιώδης συνέπεια. Υπάρχουν δύο χαρακτήρες - ο Leonard και η Penny (τηλεοπτική σειρά "The Big Bang Theory"):
Ας πούμε ότι η Πένυ είναι στην Ευρώπη και ο Λέοναρντ θέλει να της κάνει ένα πάρτι έκπληξη. Και δεν μπορεί να σκεφτεί τίποτα καλύτερο από το να την πετάξει από τη λίστα των φίλων του, στέλνοντας σε όλους τους φίλους του μια ενημέρωση στο feed: «Ας κάνουμε την Πέννυ χαρούμενη!» (είναι στην Ευρώπη, ενώ κοιμάται, δεν τα βλέπει όλα αυτά και δεν τα βλέπει, γιατί δεν είναι εκεί). Τελικά, διαγράφει αυτήν την ανάρτηση, τη σβήνει από τη ροή και επαναφέρει την πρόσβαση για να μην παρατηρήσει τίποτα και να μην υπάρξει σκάνδαλο.
Όλα αυτά είναι καλά, αλλά ας υποθέσουμε ότι το σύστημα είναι κατανεμημένο και τα πράγματα πήγαν λίγο στραβά. Μπορεί, για παράδειγμα, να συμβεί ο περιορισμός πρόσβασης της Penny μετά την εμφάνιση αυτής της ανάρτησης, εάν τα γεγονότα δεν σχετίζονται με αιτία και αποτέλεσμα. Στην πραγματικότητα, αυτό είναι ένα παράδειγμα για το πότε απαιτείται αιτιώδης συνέπεια για την εκτέλεση μιας επιχειρηματικής λειτουργίας (σε αυτήν την περίπτωση).
Στην πραγματικότητα, αυτές είναι αρκετά μη τετριμμένες ιδιότητες της βάσης δεδομένων - πολύ λίγοι άνθρωποι τις υποστηρίζουν. Ας περάσουμε στα μοντέλα.
Μοντέλα Συνέπειας
Τι ακριβώς είναι ένα μοντέλο συνέπειας στις βάσεις δεδομένων; Αυτές είναι μερικές από τις εγγυήσεις που δίνει ένα κατανεμημένο σύστημα σχετικά με τα δεδομένα που μπορεί να λάβει ο πελάτης και με ποια σειρά.
Κατ 'αρχήν, όλα τα μοντέλα συνέπειας καταλήγουν στο πόσο παρόμοιο είναι ένα κατανεμημένο σύστημα με ένα σύστημα που εκτελείται, για παράδειγμα, σε έναν κόμβο ενός φορητού υπολογιστή. Και αυτό είναι πόσο παρόμοιο είναι ένα σύστημα που τρέχει σε χιλιάδες γεωκατανεμημένους «Κόμβους» με έναν φορητό υπολογιστή, στον οποίο όλες αυτές οι ιδιότητες εκτελούνται αυτόματα κατ' αρχήν.
Επομένως, τα μοντέλα συνέπειας εφαρμόζονται μόνο σε κατανεμημένα συστήματα. Όλα τα συστήματα που υπήρχαν προηγουμένως και λειτουργούσαν στην ίδια κατακόρυφη κλίμακα δεν αντιμετώπισαν τέτοια προβλήματα. Υπήρχε μία προσωρινή μνήμη προσωρινής αποθήκευσης και τα πάντα διαβάζονταν πάντα από αυτήν.
Μοντέλο Strong
Στην πραγματικότητα, το πρώτο μοντέλο είναι το Strong (ή η γραμμή ικανότητας ανόδου, όπως συχνά αποκαλείται). Αυτό είναι ένα μοντέλο συνέπειας που διασφαλίζει ότι κάθε αλλαγή, αφού επιβεβαιωθεί ότι έχει συμβεί, είναι ορατή σε όλους τους χρήστες του συστήματος.
Αυτό δημιουργεί μια συνολική σειρά όλων των συμβάντων στη βάση δεδομένων. Αυτή είναι μια ιδιότητα πολύ ισχυρής συνέπειας και είναι γενικά πολύ ακριβό. Ωστόσο, υποστηρίζεται πολύ καλά. Απλώς είναι πολύ ακριβό και αργό - απλώς χρησιμοποιείται σπάνια. Αυτό ονομάζεται ικανότητα ανύψωσης.
Υπάρχει μια άλλη, ισχυρότερη ιδιότητα που υποστηρίζεται στο Spanner - που ονομάζεται External Consistency. Θα το συζητήσουμε λίγο αργότερα.
Αιτιώδης συνάφεια
Το επόμενο είναι το Causal, για αυτό ακριβώς μιλούσα. Υπάρχουν πολλά ακόμη υποεπίπεδα μεταξύ Ισχυρού και Αιτιακού, για τα οποία δεν θα μιλήσω, αλλά όλα συνοψίζονται σε Αιτιατική. Αυτό είναι ένα σημαντικό μοντέλο επειδή είναι το ισχυρότερο από όλα τα μοντέλα, η ισχυρότερη συνέπεια παρουσία δικτύου ή κατατμήσεων.
Οι αιτίες είναι στην πραγματικότητα μια κατάσταση στην οποία τα γεγονότα συνδέονται με μια σχέση αιτίου-αποτελέσματος. Πολύ συχνά εκλαμβάνονται ως Ανάγνωση των δικαιωμάτων σας από τη σκοπιά του πελάτη. Εάν ο πελάτης έχει παρατηρήσει κάποιες τιμές, δεν μπορεί να δει τιμές που υπήρχαν στο παρελθόν. Έχει ήδη αρχίσει να βλέπει αναγνώσεις προθέματος. Όλα καταλήγουν στο ίδιο πράγμα.
Οι αιτίες ως μοντέλο συνέπειας είναι μια μερική σειρά γεγονότων στον διακομιστή, στην οποία τα συμβάντα από όλους τους πελάτες παρατηρούνται με την ίδια σειρά. Στην προκειμένη περίπτωση, ο Λέοναρντ και η Πένυ.
Ενδεχόμενος
Το τρίτο μοντέλο είναι η ενδεχόμενη συνέπεια. Αυτό υποστηρίζουν απολύτως όλα τα κατανεμημένα συστήματα, το ελάχιστο μοντέλο που έχει νόημα. Σημαίνει το εξής: όταν έχουμε κάποιες αλλαγές στα δεδομένα, κάποια στιγμή γίνονται συνεπείς.
Σε μια τέτοια στιγμή δεν λέει τίποτα, αλλιώς θα μετατρεπόταν σε Εξωτερική Συνέπεια - θα ήταν μια εντελώς διαφορετική ιστορία. Παρ 'όλα αυτά, αυτό είναι ένα πολύ δημοφιλές μοντέλο, το πιο κοινό. Από προεπιλογή, όλοι οι χρήστες κατανεμημένων συστημάτων χρησιμοποιούν το Eventual Consistency.
Θέλω να δώσω μερικά συγκριτικά παραδείγματα:
Τι σημαίνουν αυτά τα βέλη;
- Αφάνεια. Καθώς η ισχύς της συνέπειας αυξάνεται, γίνεται μεγαλύτερη για προφανείς λόγους: πρέπει να κάνετε περισσότερες εγγραφές, να λάβετε επιβεβαίωση από όλους τους κεντρικούς υπολογιστές και τους κόμβους που συμμετέχουν στο σύμπλεγμα ότι τα δεδομένα είναι ήδη εκεί. Αντίστοιχα, το Eventual Consistency έχει την πιο γρήγορη απάντηση, γιατί εκεί, κατά κανόνα, μπορείτε να το δεσμεύσετε ακόμη και στη μνήμη και αυτό, καταρχήν, θα είναι αρκετό.
- Διαθεσιμότητα. Εάν το κατανοήσουμε ως την ικανότητα του συστήματος να ανταποκρίνεται παρουσία σπασίματος δικτύου, διαμερισμάτων ή κάποιου είδους αποτυχίας, η ανοχή σφαλμάτων αυξάνεται καθώς μειώνεται το μοντέλο συνέπειας, αφού μας αρκεί να ζει ένας κεντρικός υπολογιστής και ταυτόχρονα ο χρόνος παράγει κάποια δεδομένα. Το Eventual Consistency δεν εγγυάται τίποτα σχετικά με τα δεδομένα - μπορεί να είναι οτιδήποτε.
- Ανωμαλίες. Ταυτόχρονα βέβαια αυξάνεται και ο αριθμός των ανωμαλιών. Στο Strong Consistency σχεδόν δεν θα έπρεπε να υπάρχουν καθόλου, αλλά στο Eventual Consistency μπορούν να είναι οτιδήποτε. Γεννιέται το ερώτημα: γιατί οι άνθρωποι επιλέγουν το Eventual Consistency εάν περιέχει ανωμαλίες; Η απάντηση είναι ότι τα μοντέλα ενδεχόμενης συνέπειας είναι εφαρμόσιμα και υπάρχουν ανωμαλίες, για παράδειγμα, σε σύντομο χρονικό διάστημα. είναι δυνατή η χρήση του οδηγού για ανάγνωση και περισσότερο ή λιγότερο ανάγνωση συνεπών δεδομένων. Είναι συχνά δυνατό να χρησιμοποιηθούν μοντέλα ισχυρής συνέπειας. Στην πράξη αυτό λειτουργεί, και συχνά ο αριθμός των ανωμαλιών είναι περιορισμένος χρονικά.
Θεώρημα CAP
Όταν βλέπετε τις λέξεις συνέπεια, διαθεσιμότητα – τι σας έρχεται στο μυαλό; Αυτό είναι σωστό - θεώρημα CAP! Τώρα θέλω να διαλύσω τον μύθο... Δεν είμαι εγώ - είναι ο Μάρτιν Κλέπμαν, που έγραψε ένα υπέροχο άρθρο, ένα υπέροχο βιβλίο.
Το θεώρημα CAP είναι μια αρχή που διατυπώθηκε στη δεκαετία του 2000 ότι η Συνέπεια, η Διαθεσιμότητα, οι Κατατμήσεις: πάρτε οποιαδήποτε δύο και δεν μπορείτε να επιλέξετε τρία. Ήταν μια συγκεκριμένη αρχή. Αποδείχθηκε ως θεώρημα λίγα χρόνια αργότερα από τους Gilbert και Lynch. Στη συνέχεια, αυτό άρχισε να χρησιμοποιείται ως μάντρα - τα συστήματα άρχισαν να χωρίζονται σε CA, CP, AP και ούτω καθεξής.
Αυτό το θεώρημα αποδείχθηκε στην πραγματικότητα για τις ακόλουθες περιπτώσεις... Πρώτον, η Διαθεσιμότητα δεν θεωρήθηκε ως συνεχής τιμή από το μηδέν έως τις εκατοντάδες (0 - το σύστημα είναι "νεκρό", 100 - αποκρίνεται γρήγορα, έχουμε συνηθίσει να το θεωρούμε έτσι) , αλλά ως ιδιότητα του αλγορίθμου , που εγγυάται ότι για όλες τις εκτελέσεις του επιστρέφει δεδομένα.
Δεν υπάρχει λέξη για τον χρόνο απόκρισης! Υπάρχει ένας αλγόριθμος που επιστρέφει δεδομένα μετά από 100 χρόνια - ένας απολύτως υπέροχος διαθέσιμος αλγόριθμος, ο οποίος αποτελεί μέρος του θεωρήματος CAP.
Δεύτερον: το θεώρημα αποδείχθηκε για αλλαγές στις τιμές του ίδιου κλειδιού, παρά το γεγονός ότι αυτές οι αλλαγές μπορούν να αλλάξουν μέγεθος. Αυτό σημαίνει ότι στην πραγματικότητα πρακτικά δεν χρησιμοποιούνται, επειδή τα μοντέλα είναι διαφορετικά Eventual Consistency, Strong Consistency (ίσως).
Προς τι όλα αυτά; Επιπλέον, το θεώρημα CAP με τη μορφή ακριβώς με την οποία αποδείχθηκε δεν είναι πρακτικά εφαρμόσιμο και χρησιμοποιείται σπάνια. Σε θεωρητική μορφή, κατά κάποιο τρόπο περιορίζει τα πάντα. Αποδεικνύεται μια ορισμένη αρχή που είναι διαισθητικά σωστή, αλλά γενικά δεν έχει αποδειχθεί.
Η αιτιώδης συνέπεια είναι το ισχυρότερο μοντέλο
Αυτό που συμβαίνει τώρα είναι ότι μπορείτε να αποκτήσετε και τα τρία πράγματα: Συνέπεια, Διαθεσιμότητα χρησιμοποιώντας Partitions. Ειδικότερα, η αιτιώδης συνέπεια είναι το ισχυρότερο μοντέλο συνέπειας, το οποίο εξακολουθεί να λειτουργεί με την παρουσία Διαμερισμάτων (σπασίματα στο δίκτυο). Γι' αυτό έχει τόσο μεγάλο ενδιαφέρον και γι' αυτό το ξεκινήσαμε.
Πρώτον, απλοποιεί το έργο των προγραμματιστών εφαρμογών. Συγκεκριμένα, η παρουσία μεγάλης υποστήριξης από τον διακομιστή: όταν όλες οι εγγραφές που εμφανίζονται μέσα σε έναν πελάτη είναι εγγυημένο ότι φτάνουν με την ίδια σειρά σε έναν άλλο πελάτη. Δεύτερον, αντέχει τα χωρίσματα.
Εσωτερική κουζίνα MongoDB
Ενθυμούμενοι ότι είναι μεσημεριανό, πηγαίνουμε στην κουζίνα. Θα σας πω για το μοντέλο συστήματος, δηλαδή, τι είναι το MongoDB για όσους ακούν για μια τέτοια βάση δεδομένων για πρώτη φορά.
Το MongoDB (εφεξής «MongoDB») είναι ένα κατανεμημένο σύστημα που υποστηρίζει οριζόντια κλιμάκωση, δηλαδή διαμοιρασμό. και μέσα σε κάθε θραύσμα υποστηρίζει επίσης πλεονασμό δεδομένων, δηλαδή αναπαραγωγή.
Το Sharding στο MongoDB (όχι μια σχεσιακή βάση δεδομένων) εκτελεί αυτόματη εξισορρόπηση, δηλαδή, κάθε συλλογή εγγράφων (ή «πίνακας» όσον αφορά τα σχεσιακά δεδομένα) χωρίζεται σε κομμάτια και ο διακομιστής τα μετακινεί αυτόματα μεταξύ θραυσμάτων.
Το Query Router, το οποίο διανέμει αιτήματα, για έναν πελάτη είναι κάποιος πελάτης μέσω του οποίου λειτουργεί. Γνωρίζει ήδη πού και ποια δεδομένα βρίσκονται και κατευθύνει όλα τα αιτήματα στο σωστό θραύσμα.
Ένα άλλο σημαντικό σημείο: Το MongoDB είναι ένα ενιαίο κύριο. Υπάρχει ένα Κύριο - μπορεί να λάβει εγγραφές που υποστηρίζουν τα κλειδιά που περιέχει. Δεν μπορείτε να κάνετε Multi-master εγγραφή.
Κάναμε την κυκλοφορία 4.2 - νέα ενδιαφέροντα πράγματα εμφανίστηκαν εκεί. Συγκεκριμένα, εισήγαγαν το Lucene - αναζήτηση - δηλαδή εκτελέσιμη java απευθείας στο Mongo, και εκεί έγινε δυνατή η εκτέλεση αναζητήσεων μέσω του Lucene, όπως και στο Elastica.
Και έφτιαξαν ένα νέο προϊόν - Charts, είναι επίσης διαθέσιμο στο Atlas (το δικό του Cloud του Mongo). Έχουν ένα Free Tier - μπορείτε να παίξετε με αυτό. Μου άρεσαν πολύ τα γραφήματα - οπτικοποίηση δεδομένων, πολύ διαισθητική.
Συστατικά Αιτιώδης συνέπεια
Μέτρησα περίπου 230 άρθρα που έχουν δημοσιευτεί για αυτό το θέμα - από τη Leslie Lampert. Τώρα από τη μνήμη μου θα σας μεταφέρω μερικά μέρη από αυτά τα υλικά.
Όλα ξεκίνησαν με ένα άρθρο της Leslie Lampert, το οποίο γράφτηκε τη δεκαετία του 1970. Όπως μπορείτε να δείτε, κάποια έρευνα για αυτό το θέμα είναι ακόμη σε εξέλιξη. Τώρα η αιτιώδης συνέπεια παρουσιάζει ενδιαφέρον σε σχέση με την ανάπτυξη κατανεμημένων συστημάτων.
Περιορισμοί
Τι περιορισμοί υπάρχουν; Αυτό είναι στην πραγματικότητα ένα από τα κύρια σημεία, γιατί οι περιορισμοί που επιβάλλει ένα σύστημα παραγωγής είναι πολύ διαφορετικοί από τους περιορισμούς που υπάρχουν στα ακαδημαϊκά άρθρα. Συχνά είναι αρκετά τεχνητά.
- Πρώτον, το "MongoDB" είναι ένα ενιαίο κύριο, όπως είπα ήδη (αυτό απλοποιεί πολύ).
- Πιστεύουμε ότι το σύστημα θα πρέπει να υποστηρίζει περίπου 10 χιλιάδες θραύσματα. Δεν μπορούμε να πάρουμε αρχιτεκτονικές αποφάσεις που θα περιορίζουν ρητά αυτήν την τιμή.
- Έχουμε ένα σύννεφο, αλλά υποθέτουμε ότι ένα άτομο πρέπει να έχει ακόμα την ευκαιρία όταν κατεβάζει δυαδικό, το τρέχει στον φορητό υπολογιστή του και όλα λειτουργούν τέλεια.
- Υποθέτουμε κάτι που η Έρευνα σπάνια υποθέτει: οι εξωτερικοί πελάτες μπορούν να κάνουν ό,τι θέλουν. Το MongoDB είναι ανοιχτού κώδικα. Κατά συνέπεια, οι πελάτες μπορεί να είναι τόσο έξυπνοι και θυμωμένοι - μπορεί να θέλουν να σπάσουν τα πάντα. Εικάζουμε ότι μπορεί να προέρχονται οι Βυζαντινοί Feilors.
- Για εξωτερικούς πελάτες που βρίσκονται εκτός της περιμέτρου, υπάρχει ένας σημαντικός περιορισμός: εάν αυτή η δυνατότητα είναι απενεργοποιημένη, τότε δεν θα πρέπει να παρατηρηθεί υποβάθμιση της απόδοσης.
- Ένα άλλο σημείο είναι γενικά αντι-ακαδημαϊκό: η συμβατότητα προηγούμενων εκδόσεων και μελλοντικών. Τα παλιά προγράμματα οδήγησης πρέπει να υποστηρίζουν νέες ενημερώσεις και η βάση δεδομένων πρέπει να υποστηρίζει παλιά προγράμματα οδήγησης.
Γενικά όλα αυτά επιβάλλουν περιορισμούς.
Στοιχεία αιτιώδους συνέπειας
Θα μιλήσω τώρα για μερικά από τα συστατικά. Αν λάβουμε υπόψη την Αιτιώδη συνέπεια γενικά, μπορούμε να επιλέξουμε μπλοκ. Επιλέξαμε από έργα που ανήκουν σε ένα συγκεκριμένο μπλοκ: Παρακολούθηση εξάρτησης, επιλογή ρολογιών, πώς αυτά τα ρολόγια μπορούν να συγχρονιστούν μεταξύ τους και πώς διασφαλίζουμε την ασφάλεια - αυτό είναι μια πρόχειρη περιγραφή του τι θα μιλήσω:
Παρακολούθηση πλήρους εξάρτησης
Γιατί χρειάζεται; Έτσι, όταν τα δεδομένα αναπαράγονται, κάθε εγγραφή, κάθε αλλαγή δεδομένων περιέχει πληροφορίες σχετικά με τις αλλαγές από τις οποίες εξαρτάται. Η πρώτη και αφελής αλλαγή είναι όταν κάθε μήνυμα που περιέχει μια εγγραφή περιέχει πληροφορίες για προηγούμενα μηνύματα:
Σε αυτό το παράδειγμα, ο αριθμός σε σγουρές αγκύλες είναι οι αριθμοί εγγραφής. Μερικές φορές αυτές οι εγγραφές με τιμές μεταφέρονται ακόμη και στο σύνολό τους, μερικές φορές μεταφέρονται ορισμένες εκδόσεις. Η ουσία είναι ότι κάθε αλλαγή περιέχει πληροφορίες για την προηγούμενη (προφανώς τα κουβαλάει όλα αυτά μέσα της).
Γιατί αποφασίσαμε να μην χρησιμοποιήσουμε αυτήν την προσέγγιση (πλήρης παρακολούθηση); Προφανώς, επειδή αυτή η προσέγγιση δεν είναι πρακτική: οποιαδήποτε αλλαγή σε ένα κοινωνικό δίκτυο εξαρτάται από όλες τις προηγούμενες αλλαγές σε αυτό το κοινωνικό δίκτυο, μεταφέροντας, ας πούμε, το Facebook ή το VKontakte σε κάθε ενημέρωση. Ωστόσο, υπάρχει πολλή έρευνα σχετικά με την παρακολούθηση πλήρους εξάρτησης - αυτά είναι δίκτυα προ-κοινωνίας· για ορισμένες περιπτώσεις λειτουργεί πραγματικά.
Ρητή παρακολούθηση εξάρτησης
Το επόμενο είναι πιο περιορισμένο. Η μεταφορά πληροφοριών εξετάζεται επίσης εδώ, αλλά μόνο αυτή που εξαρτάται σαφώς. Τι εξαρτάται από το τι, κατά κανόνα, καθορίζεται από την Εφαρμογή. Όταν τα δεδομένα αναπαράγονται, το ερώτημα επιστρέφει απαντήσεις μόνο όταν οι προηγούμενες εξαρτήσεις έχουν ικανοποιηθεί, δηλαδή εμφανιστούν. Αυτή είναι η ουσία του πώς λειτουργεί η αιτιώδης συνέπεια.
Βλέπει ότι η εγγραφή 5 εξαρτάται από τις εγγραφές 1, 2, 3, 4 - κατά συνέπεια, περιμένει πριν ο πελάτης έχει πρόσβαση στις αλλαγές που έγιναν με την απόφαση πρόσβασης της Penny, όταν όλες οι προηγούμενες αλλαγές έχουν ήδη περάσει από τη βάση δεδομένων.
Ούτε αυτό μας ταιριάζει, γιατί υπάρχουν ακόμα πάρα πολλές πληροφορίες και θα επιβραδύνουν τα πράγματα. Υπάρχει μια άλλη προσέγγιση...
Ρολόι Lamport
Είναι πολύ παλιοί. Ρολόι Lamport σημαίνει ότι αυτές οι εξαρτήσεις διπλώνονται σε μια βαθμωτή συνάρτηση, η οποία ονομάζεται Ρολόι Lamport.
Μια βαθμωτή συνάρτηση είναι κάποιος αφηρημένος αριθμός. Συχνά ονομάζεται λογικός χρόνος. Με κάθε συμβάν, αυτός ο μετρητής αυξάνεται. Ο μετρητής, ο οποίος είναι επί του παρόντος γνωστός στη διαδικασία, στέλνει κάθε μήνυμα. Είναι σαφές ότι οι διαδικασίες μπορεί να είναι εκτός συγχρονισμού, μπορεί να έχουν τελείως διαφορετικούς χρόνους. Ωστόσο, το σύστημα εξισορροπεί κατά κάποιο τρόπο το ρολόι με τέτοια μηνύματα. Τι συμβαίνει σε αυτή την περίπτωση;
Χώρισα αυτό το μεγάλο κομμάτι στα δύο για να γίνει σαφές: Οι φίλοι μπορούν να ζουν σε έναν κόμβο, ο οποίος περιέχει ένα κομμάτι της συλλογής, και το Feed μπορεί να ζήσει σε έναν άλλο κόμβο, ο οποίος περιέχει ένα κομμάτι αυτής της συλλογής. Είναι ξεκάθαρο πώς μπορούν να βγουν από τη γραμμή; Η πρώτη ροή θα λέει: "Αντιγραφή" και μετά "Φίλοι". Εάν το σύστημα δεν παρέχει κάποιου είδους εγγύηση ότι η ροή δεν θα εμφανίζεται μέχρι να παραδοθούν και οι εξαρτήσεις φίλων στη συλλογή Φίλων, τότε θα έχουμε ακριβώς την κατάσταση που ανέφερα.
Βλέπετε πώς αυξάνεται λογικά ο χρόνος μέτρησης στη ροή:
Επομένως, η κύρια ιδιότητα αυτού του ρολογιού Lamport και της αιτιακής συνέπειας (που εξηγείται μέσω του ρολογιού Lamport) είναι η εξής: εάν έχουμε συμβάντα Α και Β και το συμβάν Β εξαρτάται από το συμβάν Α*, τότε προκύπτει ότι ο Λογικός Χρόνος του Συμβάντος Α είναι μικρότερος από LogicalTime από το συμβάν Β.
* Μερικές φορές λένε επίσης ότι το Α συνέβη πριν από το Β, δηλαδή το Α συνέβη πριν από το Β - αυτή είναι μια συγκεκριμένη σχέση που διατάσσει εν μέρει ολόκληρο το σύνολο των γεγονότων που συνέβησαν γενικά.
Το αντίθετο είναι λάθος. Αυτό είναι στην πραγματικότητα ένα από τα κύρια μειονεκτήματα του Lamport Clock - μερική παραγγελία. Υπάρχει μια έννοια για ταυτόχρονα γεγονότα, δηλαδή γεγονότα στα οποία ούτε (το Α συνέβη πριν από το Β) ούτε (το Α συνέβη πριν από το Β). Ένα παράδειγμα θα ήταν η παράλληλη προσθήκη κάποιου άλλου από τον Λέοναρντ ως φίλου (ούτε καν ο Λέοναρντ, αλλά ο Σέλντον, για παράδειγμα).
Αυτή είναι η ιδιότητα που χρησιμοποιείται συχνά κατά την εργασία με ρολόγια Lamport: εξετάζουν συγκεκριμένα τη λειτουργία και από αυτό συμπεραίνουν ότι ίσως αυτά τα συμβάντα εξαρτώνται. Επειδή ένας τρόπος είναι αληθής: εάν ο Λογικός Χρόνος Α είναι μικρότερος από τον ΛογικόΧρόνο Β, τότε το Β δεν μπορεί να συμβεί πριν από το Α. και αν περισσότερα, τότε ίσως.
Διάνυσμα ρολόι
Η λογική εξέλιξη του ρολογιού Lamport είναι το Vector Clock. Διαφέρουν στο ότι κάθε κόμβος που βρίσκεται εδώ περιέχει το δικό του ξεχωριστό ρολόι και μεταδίδονται ως διάνυσμα.
Σε αυτήν την περίπτωση, βλέπετε ότι ο μηδενικός δείκτης του διανύσματος είναι υπεύθυνος για το Feed και ο πρώτος δείκτης του διανύσματος είναι για τους φίλους (καθένας από αυτούς τους κόμβους). Και τώρα θα αυξηθούν: ο μηδενικός δείκτης "Ροή" αυξάνεται όταν γράφετε - 1, 2, 3:
Γιατί είναι καλύτερο το Vector Clock; Επειδή σας επιτρέπουν να καταλάβετε ποια συμβάντα είναι ταυτόχρονα και πότε συμβαίνουν σε διαφορετικούς κόμβους. Αυτό είναι πολύ σημαντικό για ένα σύστημα κοινής χρήσης όπως το MongoDB. Ωστόσο, δεν το επιλέξαμε αυτό, αν και είναι υπέροχο πράγμα, και λειτουργεί υπέροχα, και μάλλον θα μας ταίριαζε...
Αν έχουμε 10 χιλιάδες θραύσματα, δεν μπορούμε να μεταφέρουμε 10 χιλιάδες συστατικά, ακόμα κι αν τα συμπιέσουμε ή καταλήξουμε σε κάτι άλλο - το ωφέλιμο φορτίο θα εξακολουθεί να είναι αρκετές φορές μικρότερο από τον όγκο ολόκληρου αυτού του διανύσματος. Επομένως, σφίγγοντας την καρδιά και τα δόντια μας, εγκαταλείψαμε αυτή την προσέγγιση και προχωρήσαμε σε άλλη.
Κλειδί TrueTime. Ατομικό ρολόι
Είπα ότι θα υπάρξει μια ιστορία για τον Spanner. Αυτό είναι ένα ωραίο πράγμα, κατευθείαν από τον XNUMXο αιώνα: ατομικά ρολόγια, συγχρονισμός GPS.
Ποια είναι η ιδέα; Το "Spanner" είναι ένα σύστημα της Google που πρόσφατα έγινε ακόμη και διαθέσιμο σε άτομα (πρόσθεσαν SQL σε αυτό). Κάθε συναλλαγή εκεί έχει κάποια χρονική σήμανση. Εφόσον η ώρα είναι συγχρονισμένη*, σε κάθε συμβάν μπορεί να εκχωρηθεί μια συγκεκριμένη ώρα - τα ατομικά ρολόγια έχουν χρόνο αναμονής, μετά τον οποίο είναι εγγυημένο ότι θα «συμβεί» διαφορετική ώρα.
Έτσι, με απλή εγγραφή στη βάση δεδομένων και αναμονή για κάποιο χρονικό διάστημα, διασφαλίζεται αυτόματα η Σειροποίηση του συμβάντος. Έχουν το ισχυρότερο μοντέλο Συνέπειας που μπορεί να φανταστεί κανείς κατ' αρχήν - είναι η Εξωτερική Συνέπεια.
* Αυτό είναι το κύριο πρόβλημα με τα ρολόγια Lampart - δεν είναι ποτέ σύγχρονα σε κατανεμημένα συστήματα. Μπορούν να αποκλίνουν· ακόμη και με το NTP, εξακολουθούν να μην λειτουργούν πολύ καλά. Το "Spanner" έχει ατομικό ρολόι και ο συγχρονισμός, όπως φαίνεται, είναι μικροδευτερόλεπτα.
Γιατί δεν επιλέξαμε; Δεν υποθέτουμε ότι οι χρήστες μας έχουν ενσωματωμένο ατομικό ρολόι. Όταν εμφανιστούν, ενσωματωμένα σε κάθε φορητό υπολογιστή, θα υπάρχει κάποιου είδους σούπερ κουλ συγχρονισμός GPS - τότε ναι... Αλλά προς το παρόν το καλύτερο που είναι δυνατό είναι το Amazon, οι σταθμοί βάσης - για τους φανατικούς... Έτσι χρησιμοποιήσαμε άλλα ρολόγια .
Υβριδικό ρολόι
Αυτό είναι στην πραγματικότητα αυτό που σημειώνει στο MongoDB όταν διασφαλίζεται η αιτιώδης συνέπεια. Πώς είναι υβριδικά; Το Hybrid είναι μια κλιμακωτή τιμή, αλλά έχει δύο συστατικά:
- Η πρώτη είναι η εποχή του Unix (πόσα δευτερόλεπτα έχουν περάσει από την «αρχή του κόσμου των υπολογιστών»).
- Το δεύτερο είναι κάποια αύξηση, επίσης μια 32-bit unsigned int.
Αυτό είναι όλο, στην πραγματικότητα. Υπάρχει αυτή η προσέγγιση: το τμήμα που είναι υπεύθυνο για τον χρόνο συγχρονίζεται με το ρολόι όλη την ώρα. κάθε φορά που εμφανίζεται μια ενημέρωση, αυτό το τμήμα συγχρονίζεται με το ρολόι και αποδεικνύεται ότι η ώρα είναι πάντα λίγο πολύ σωστή και η αύξηση σάς επιτρέπει να διακρίνετε μεταξύ συμβάντων που συνέβησαν την ίδια χρονική στιγμή.
Γιατί είναι αυτό σημαντικό για το MongoDB; Επειδή σας επιτρέπει να δημιουργήσετε κάποιο είδος backup εστιατορίων σε μια συγκεκριμένη χρονική στιγμή, δηλαδή το συμβάν ευρετηριάζεται με βάση την ώρα. Αυτό είναι σημαντικό όταν απαιτούνται ορισμένα γεγονότα. Για μια βάση δεδομένων, τα συμβάντα είναι αλλαγές στη βάση δεδομένων που συνέβησαν σε συγκεκριμένα χρονικά διαστήματα.
Θα σας πω τον πιο σημαντικό λόγο μόνο για εσάς (παρακαλώ, μην το πείτε σε κανέναν)! Το κάναμε αυτό επειδή έτσι μοιάζουν τα οργανωμένα, ευρετηριασμένα δεδομένα στο MongoDB OpLog. Το OpLog είναι μια δομή δεδομένων που περιέχει απολύτως όλες τις αλλαγές στη βάση δεδομένων: πρώτα πηγαίνουν στο OpLog και, στη συνέχεια, εφαρμόζονται στο ίδιο το Storage στην περίπτωση που πρόκειται για αναγραφόμενη ημερομηνία ή θραύσμα.
Αυτός ήταν ο κύριος λόγος. Ωστόσο, υπάρχουν επίσης πρακτικές απαιτήσεις για την ανάπτυξη μιας βάσης δεδομένων, που σημαίνει ότι θα πρέπει να είναι απλή - λίγος κώδικας, όσο το δυνατόν λιγότερα σπασμένα πράγματα που πρέπει να ξαναγραφτούν και να δοκιμαστούν. Το γεγονός ότι τα oplogs μας είχαν ευρετηριαστεί από υβριδικά ρολόγια βοήθησε πολύ και μας επέτρεψε να κάνουμε τη σωστή επιλογή. Πραγματικά απέδωσε και κατά κάποιο τρόπο λειτούργησε μαγικά στο πρώτο πρωτότυπο. Ήταν πολύ δροσερό!
Συγχρονισμός ρολογιού
Υπάρχουν πολλές μέθοδοι συγχρονισμού που περιγράφονται στην επιστημονική βιβλιογραφία. Μιλάω για συγχρονισμό όταν έχουμε δύο διαφορετικά θραύσματα. Εάν υπάρχει ένα σετ ρεπλίκα, δεν χρειάζεται κανένας συγχρονισμός: αυτό είναι ένα "μονό κύριο". έχουμε ένα OpLog, στο οποίο εμπίπτουν όλες οι αλλαγές - σε αυτήν την περίπτωση, όλα έχουν ήδη ταξινομηθεί διαδοχικά στο ίδιο το "Oplog". Αλλά αν έχουμε δύο διαφορετικά θραύσματα, ο συγχρονισμός χρόνου είναι σημαντικός εδώ. Εδώ βοήθησε περισσότερο το διανυσματικό ρολόι! Αλλά δεν τα έχουμε.
Το δεύτερο είναι κατάλληλο - αυτό είναι το "Heartbeats". Είναι δυνατή η ανταλλαγή ορισμένων σημάτων που εμφανίζονται κάθε μονάδα χρόνου. Αλλά οι παλμοί της καρδιάς είναι πολύ αργοί, δεν μπορούμε να παρέχουμε καθυστέρηση στον πελάτη μας.
Ο αληθινός χρόνος είναι, φυσικά, υπέροχο πράγμα. Αλλά, και πάλι, αυτό είναι μάλλον το μέλλον... Αν και μπορεί ήδη να γίνει στον Atlas, υπάρχουν ήδη γρήγοροι συγχρονιστές χρόνου «Amazon». Αλλά δεν θα είναι διαθέσιμο σε όλους.
Το κουτσομπολιό είναι όταν όλα τα μηνύματα περιλαμβάνουν χρόνο. Αυτό είναι περίπου αυτό που χρησιμοποιούμε. Κάθε μήνυμα μεταξύ κόμβων, ένα πρόγραμμα οδήγησης, ένας δρομολογητής κόμβου δεδομένων, απολύτως τα πάντα για το MongoDB είναι κάποιο είδος στοιχείου, ένα στοιχείο βάσης δεδομένων που περιέχει ένα ρολόι που εκτελείται. Έχουν την έννοια του υβριδικού χρόνου παντού, μεταδίδεται. 64 bit? Αυτό επιτρέπει, αυτό είναι δυνατό.
Πώς λειτουργούν όλα μαζί;
Εδώ κοιτάζω ένα σετ ρεπλίκα για να το κάνω λίγο πιο εύκολο. Υπάρχουν Πρωτοβάθμια και Δευτεροβάθμια. Το δευτερεύον κάνει αναπαραγωγή και δεν συγχρονίζεται πάντα πλήρως με το Primary.
Γίνεται μια εισαγωγή στο "Primery" με μια συγκεκριμένη χρονική τιμή. Αυτό το ένθετο αυξάνει την εσωτερική καταμέτρηση κατά 11, εάν αυτό είναι το μέγιστο. Ή θα ελέγξει τις τιμές του ρολογιού και θα συγχρονιστεί με το ρολόι εάν οι τιμές του ρολογιού είναι μεγαλύτερες. Αυτό σας επιτρέπει να οργανώσετε με βάση την ώρα.
Αφού κάνει την ηχογράφηση, εμφανίζεται μια σημαντική στιγμή. Το ρολόι είναι στο "MongoDB" και αυξάνεται μόνο σε περίπτωση εγγραφής στο "Oplog". Αυτό είναι το γεγονός που αλλάζει την κατάσταση του συστήματος. Σε όλα τα κλασικά άρθρα, ένα συμβάν θεωρείται όταν ένα μήνυμα χτυπά έναν κόμβο: το μήνυμα έφτασε, που σημαίνει ότι το σύστημα άλλαξε την κατάστασή του.
Αυτό οφείλεται στο γεγονός ότι κατά τη διάρκεια της έρευνας δεν είναι απολύτως σαφές πώς θα ερμηνευτεί αυτό το μήνυμα. Γνωρίζουμε με βεβαιότητα ότι εάν δεν αντικατοπτρίζεται στο "Oplog", τότε δεν θα ερμηνευτεί με κανέναν τρόπο και μια αλλαγή στην κατάσταση του συστήματος είναι μόνο μια καταχώριση στο "Oplog". Αυτό απλοποιεί τα πάντα για εμάς: το μοντέλο το απλοποιεί και μας επιτρέπει να το οργανώσουμε μέσα σε ένα σετ αντιγράφων και πολλά άλλα χρήσιμα πράγματα.
Η τιμή που είναι ήδη γραμμένη στο "Oplog" επιστρέφεται - γνωρίζουμε ότι το "Oplog" περιέχει ήδη αυτήν την τιμή και ο χρόνος του είναι 12. Τώρα, ας πούμε, η ανάγνωση ξεκινά από έναν άλλο κόμβο (Δευτερεύων) και μεταδίδει το afterClusterTime στο το μήνυμα. Λέει: «Χρειάζομαι όλα όσα συνέβησαν τουλάχιστον μετά τις 12 ή κατά τη διάρκεια των δώδεκα» (βλ. εικόνα παραπάνω).
Αυτό είναι αυτό που ονομάζεται Causal a Consent (CAT). Υπάρχει μια τέτοια έννοια στη θεωρία ότι αυτό είναι ένα κομμάτι του χρόνου, το οποίο είναι συνεπές από μόνο του. Σε αυτή την περίπτωση, μπορούμε να πούμε ότι αυτή είναι η κατάσταση του συστήματος που παρατηρήθηκε τη στιγμή 12.
Τώρα δεν υπάρχει τίποτα εδώ ακόμα, γιατί αυτό το είδος προσομοιώνει την κατάσταση όταν χρειάζεστε το δευτερεύον για αναπαραγωγή δεδομένων από το Πρωτεύον. Περιμένει... Και τώρα έφτασαν τα δεδομένα - επιστρέφει αυτές τις τιμές πίσω.
Κάπως έτσι λειτουργούν όλα. Σχεδόν.
Τι σημαίνει «σχεδόν»; Ας υποθέσουμε ότι υπάρχει κάποιος που έχει διαβάσει και έχει καταλάβει πώς λειτουργεί όλο αυτό. Συνειδητοποίησα ότι κάθε φορά που εμφανίζεται το ClusterTime, ενημερώνει το εσωτερικό λογικό ρολόι και, στη συνέχεια, η επόμενη καταχώρηση αυξάνεται κατά μία. Αυτή η λειτουργία παίρνει 20 γραμμές. Ας υποθέσουμε ότι αυτό το άτομο εκπέμπει τον μεγαλύτερο αριθμό 64-bit, μείον ένα.
Γιατί «μείον ένα»; Επειδή το εσωτερικό ρολόι θα αντικατασταθεί σε αυτήν την τιμή (προφανώς, αυτή είναι η μεγαλύτερη δυνατή και μεγαλύτερη από την τρέχουσα ώρα), τότε θα εμφανιστεί μια καταχώρηση στο "Oplog" και το ρολόι θα αυξηθεί κατά μια άλλη μονάδα - και θα υπάρχει ήδη να είναι μια μέγιστη τιμή (απλώς υπάρχουν όλες οι μονάδες, δεν υπάρχει πουθενά αλλού να πάτε) , unsaint ints).
Είναι σαφές ότι μετά από αυτό το σύστημα γίνεται απολύτως απρόσιτο για οτιδήποτε. Μπορεί να ξεφορτωθεί και να καθαριστεί μόνο - πολλή χειρωνακτική εργασία. Πλήρης διαθεσιμότητα:
Επιπλέον, εάν αυτό αναπαραχθεί κάπου αλλού, τότε ολόκληρο το σύμπλεγμα απλώς πέφτει κάτω. Μια απολύτως απαράδεκτη κατάσταση που μπορεί να οργανώσει ο καθένας πολύ γρήγορα και εύκολα! Ως εκ τούτου, θεωρήσαμε αυτή τη στιγμή ως μια από τις πιο σημαντικές. Πώς να το αποτρέψετε;
Ο τρόπος μας είναι να υπογράψουμε το clusterTime
Έτσι μεταδίδεται στο μήνυμα (πριν από το μπλε κείμενο). Αλλά αρχίσαμε επίσης να δημιουργούμε μια υπογραφή (μπλε κείμενο):
Η υπογραφή δημιουργείται από ένα κλειδί που αποθηκεύεται μέσα στη βάση δεδομένων, μέσα σε μια ασφαλή περίμετρο. η ίδια δημιουργείται και ενημερώνεται (οι χρήστες δεν βλέπουν τίποτα σχετικά με αυτό). Δημιουργείται ένας κατακερματισμός και κάθε μήνυμα υπογράφεται όταν δημιουργείται και επικυρώνεται όταν λαμβάνεται.
Το ερώτημα πιθανώς τίθεται στο μυαλό των ανθρώπων: "Πόσο επιβραδύνει αυτό τα πράγματα;" Σας είπα ότι θα πρέπει να λειτουργεί γρήγορα, ειδικά αν δεν υπάρχει αυτή η δυνατότητα.
Τι σημαίνει η χρήση της Αιτιακής συνέπειας σε αυτή την περίπτωση; Αυτό γίνεται για να εμφανιστεί η παράμετρος afterClusterTime. Χωρίς αυτό, θα περάσει απλώς τιμές ούτως ή άλλως. Το κουτσομπολιό, ξεκινώντας από την έκδοση 3.6, λειτουργεί πάντα.
Εάν αφήσουμε τη συνεχή δημιουργία υπογραφών, θα επιβραδύνει το σύστημα ακόμη και αν δεν υπάρχει ένα χαρακτηριστικό, το οποίο δεν ανταποκρίνεται στις προσεγγίσεις και τις απαιτήσεις μας. Τι κάναμε λοιπόν;
Κάντε το γρήγορα!
Είναι ένα αρκετά απλό πράγμα, αλλά το κόλπο είναι ενδιαφέρον - θα το μοιραστώ, ίσως κάποιος ενδιαφέρεται.
Έχουμε έναν κατακερματισμό που αποθηκεύει τα υπογεγραμμένα δεδομένα. Όλα τα δεδομένα περνούν από την κρυφή μνήμη. Η κρυφή μνήμη δεν υπογράφει τη συγκεκριμένη ώρα, αλλά το εύρος. Όταν φτάσει κάποια τιμή, δημιουργούμε ένα εύρος, κρύβουμε τα τελευταία 16 bit και υπογράφουμε αυτήν την τιμή:
Λαμβάνοντας μια τέτοια υπογραφή, επιταχύνουμε το σύστημα (σχετικά) 65 χιλιάδες φορές. Λειτουργεί εξαιρετικά: όταν πραγματοποιούσαμε πειράματα, ο χρόνος μειώθηκε στην πραγματικότητα κατά 10 χιλιάδες φορές όταν είχαμε μια διαδοχική ενημέρωση. Είναι σαφές ότι όταν βρίσκονται σε αντίθεση, αυτό δεν λειτουργεί. Αλλά στις περισσότερες πρακτικές περιπτώσεις λειτουργεί. Ο συνδυασμός της υπογραφής Range μαζί με την υπογραφή έλυσαν το πρόβλημα ασφαλείας.
Τι μάθαμε;
Τα διδάγματα που πήραμε από αυτό:
- Πρέπει να διαβάζουμε υλικά, ιστορίες, άρθρα, γιατί έχουμε πολλά ενδιαφέροντα πράγματα. Όταν εργαζόμαστε σε κάποιο χαρακτηριστικό (ειδικά τώρα, όταν κάναμε συναλλαγές κ.λπ.), πρέπει να διαβάζουμε και να καταλαβαίνουμε. Χρειάζεται χρόνος, αλλά στην πραγματικότητα είναι πολύ χρήσιμο γιατί καθιστά σαφές πού βρισκόμαστε. Δεν φαινόταν να καταλήξουμε σε κάτι νέο - απλώς πήραμε τα συστατικά.
Γενικά, υπάρχει μια ορισμένη διαφορά στη σκέψη όταν υπάρχει ένα ακαδημαϊκό συνέδριο (Sigmon, για παράδειγμα) - όλοι επικεντρώνονται σε νέες ιδέες. Τι νέο υπάρχει στον αλγόριθμό μας; Δεν υπάρχει τίποτα ιδιαίτερα νέο εδώ. Η καινοτομία έγκειται μάλλον στον τρόπο που συνδυάσαμε τις υπάρχουσες προσεγγίσεις. Επομένως, το πρώτο πράγμα είναι να διαβάσετε τα κλασικά, ξεκινώντας από τον Lampart.
- Στην παραγωγή, οι απαιτήσεις είναι εντελώς διαφορετικές. Είμαι βέβαιος ότι πολλοί από εσάς δεν αντιμετωπίζετε «σφαιρικές» βάσεις δεδομένων σε ένα αφηρημένο κενό, αλλά με κανονικά, πραγματικά πράγματα που έχουν προβλήματα με τη διαθεσιμότητα, την καθυστέρηση και την ανοχή σφαλμάτων.
- Το τελευταίο πράγμα είναι ότι έπρεπε να εξετάσουμε διαφορετικές ιδέες και να συνδυάσουμε πολλά εντελώς διαφορετικά άρθρα σε μια προσέγγιση, μαζί. Η ιδέα για την υπογραφή, για παράδειγμα, γενικά προήλθε από ένα άρθρο που θεωρούσε το πρωτόκολλο των Παξών, το οποίο για τους μη Βυζαντινούς Failors είναι μέσα στο πρωτόκολλο εξουσιοδότησης, για τους Βυζαντινούς - εκτός του πρωτοκόλλου εξουσιοδότησης... Γενικά, αυτό ακριβώς κατέληξε να κάνει.
Δεν υπάρχει απολύτως τίποτα νέο εδώ! Αλλά μόλις τα ανακατέψαμε όλα μαζί... Είναι το ίδιο με το να λέμε ότι η συνταγή για σαλάτα Olivier είναι ανοησία, γιατί τα αυγά, η μαγιονέζα και τα αγγούρια έχουν ήδη εφευρεθεί... Είναι περίπου η ίδια ιστορία.
Θα τελειώσω με αυτό. Ευχαριστώ!
ερωτήσεις
Ερώτηση από το ακροατήριο (εφεξής καλούμενο Β): – Ευχαριστώ, Μιχαήλ, για την αναφορά! Το θέμα του χρόνου είναι ενδιαφέρον. Χρησιμοποιείτε το Gossiping. Είπαν ότι ο καθένας έχει τη δική του ώρα, ο καθένας ξέρει την τοπική του ώρα. Όπως καταλαβαίνω, έχουμε ένα πρόγραμμα οδήγησης - μπορεί να υπάρχουν πολλοί πελάτες με προγράμματα οδήγησης, προγραμματιστές ερωτήσεων επίσης, θραύσματα επίσης... Και σε τι καταλήγει το σύστημα εάν ξαφνικά έχουμε μια ασυμφωνία: κάποιος αποφασίσει ότι είναι για λεπτό μπροστά, κάποιος ένα λεπτό πίσω; Πού θα καταλήξουμε;
MT: – Πραγματικά μεγάλη ερώτηση! Ήθελα απλώς να μιλήσω για θραύσματα. Αν καταλαβαίνω σωστά την ερώτηση, έχουμε την εξής κατάσταση: υπάρχει το θραύσμα 1 και το θραύσμα 2, η ανάγνωση γίνεται από αυτά τα δύο θραύσματα - έχουν μια ασυμφωνία, δεν αλληλεπιδρούν μεταξύ τους, επειδή ο χρόνος που γνωρίζουν είναι διαφορετικός, ειδικά την εποχή που υπάρχουν στα οπλόγκα.
Ας πούμε ότι το θραύσμα 1 έκανε ένα εκατομμύριο εγγραφές, το θραύσμα 2 δεν έκανε απολύτως τίποτα και το αίτημα έφτασε σε δύο θραύσματα. Και το πρώτο έχει afterClusterTime πάνω από ένα εκατομμύριο. Σε μια τέτοια κατάσταση, όπως εξήγησα, το θραύσμα 2 δεν θα ανταποκριθεί ποτέ καθόλου.
ΣΤΟ: – Ήθελα να μάθω πώς συγχρονίζονται και επιλέγουν μία λογική ώρα;
MT: - Πολύ εύκολος στον συγχρονισμό. Ο Shard, όταν του έρθει το afterClusterTime και δεν βρίσκει χρόνο στο "Oplog", δεν ξεκινάει καμία έγκριση. Δηλαδή, ανεβάζει τον χρόνο του με τα χέρια του σε αυτή την τιμή. Αυτό σημαίνει ότι δεν υπάρχουν συμβάντα που να ταιριάζουν με αυτό το αίτημα. Δημιουργεί αυτό το συμβάν τεχνητά και έτσι γίνεται Αιτιακή Συνεπής.
ΣΤΟ: – Κι αν μετά από αυτό του έρθουν κάποια άλλα γεγονότα που χάθηκαν κάπου στο δίκτυο;
MT: – Το Shard έχει σχεδιαστεί με τέτοιο τρόπο που δεν θα ξαναέρθουν, αφού είναι ένα single master. Αν έχει ήδη δηλώσει συμμετοχή, τότε δεν θα έρθουν, αλλά θα έρθουν αργότερα. Δεν μπορεί να συμβεί κάτι να κολλήσει κάπου, μετά να μην γράψει και μετά να έρθουν αυτά τα γεγονότα - και να σπάσει η Αιτιατική συνέπεια. Όταν δεν γράφει, θα πρέπει να έρθουν όλοι στη συνέχεια (θα τους περιμένει).
ΣΤΟ: – Έχω πολλές ερωτήσεις σχετικά με τις ουρές. Η αιτιώδης συνέπεια προϋποθέτει ότι υπάρχει μια συγκεκριμένη ουρά ενεργειών που πρέπει να εκτελεστούν. Τι θα συμβεί αν ένα από τα πακέτα μας εξαφανιστεί; Έρχεται η 10η, η 11η... η 12η εξαφανίστηκε, και όλοι οι άλλοι περιμένουν να γίνει πραγματικότητα. Και ξαφνικά το αυτοκίνητό μας πέθανε, δεν μπορούμε να κάνουμε τίποτα. Υπάρχει μέγιστο μήκος της ουράς που συγκεντρώνεται πριν από την εκτέλεση; Ποια θανατηφόρα αποτυχία συμβαίνει όταν χάνεται κάποια κατάσταση; Επιπλέον, αν γράψουμε ότι υπάρχει κάποια προηγούμενη κατάσταση, τότε θα πρέπει με κάποιο τρόπο να ξεκινήσουμε από αυτήν; Αλλά δεν τον απώθησαν!
MT: – Επίσης μεγάλη ερώτηση! Τι κάνουμε? Το MongoDB έχει την έννοια της απαρτίας γράφει, απαρτία διαβάζει. Σε ποιες περιπτώσεις μπορεί να χαθεί ένα μήνυμα; Όταν μια εγγραφή δεν είναι απαρτία ή όταν μια ανάγνωση δεν είναι απαρτία (κάποιο είδος σκουπιδιών μπορεί επίσης να κολλήσει).
Σχετικά με την Αιτιατική Συνέπεια, διεξήχθη ένα μεγάλο πειραματικό τεστ, το αποτέλεσμα του οποίου ήταν ότι στην περίπτωση που οι εγγραφές και οι αναγνώσεις δεν βρίσκονται σε απαρτία, συμβαίνουν παραβιάσεις της Αιτιατικής συνέπειας. Ακριβώς αυτό που λες!
Η συμβουλή μας: χρησιμοποιήστε τουλάχιστον ανάγνωση απαρτίας όταν χρησιμοποιείτε Αιτιατική συνέπεια. Σε αυτήν την περίπτωση, τίποτα δεν θα χαθεί, ακόμα κι αν χαθεί η εγγραφή απαρτίας... Αυτή είναι μια ορθογώνια κατάσταση: εάν ο χρήστης δεν θέλει να χαθούν δεδομένα, πρέπει να χρησιμοποιήσει μια εγγραφή απαρτίας. Η αιτιολογική συνέπεια δεν εγγυάται την ανθεκτικότητα. Η ανθεκτικότητα είναι εγγυημένη από την αναπαραγωγή και τα μηχανήματα που σχετίζονται με την αναπαραγωγή.
ΣΤΟ: – Όταν δημιουργούμε ένα στιγμιότυπο που εκτελεί sharding για εμάς (όχι master, αλλά slave, αντίστοιχα), βασίζεται στον χρόνο Unix της δικής του μηχανής ή στον χρόνο του "master". Συγχρονίζεται για πρώτη φορά ή περιοδικά;
MT: – Θα διευκρινίσω τώρα. Shard (δηλαδή οριζόντιο διαμέρισμα) - υπάρχει πάντα ένα Primary εκεί. Και ένα θραύσμα μπορεί να έχει έναν «κύριο» και μπορεί να υπάρχουν αντίγραφα. Αλλά το θραύσμα υποστηρίζει πάντα εγγραφή, γιατί πρέπει να υποστηρίζει κάποιο τομέα (το θραύσμα έχει Κύριο).
ΣΤΟ: – Δηλαδή όλα εξαρτώνται καθαρά από τον «κύριο»; Χρησιμοποιείται πάντα ο κύριος χρόνος;
MT: - Ναί. Μπορείτε να πείτε μεταφορικά: το ρολόι χτυπά όταν εμφανίζεται μια είσοδος στο "master", στο "Oplog".
ΣΤΟ: – Έχουμε έναν πελάτη που συνδέεται και δεν χρειάζεται να ξέρει τίποτα για την ώρα;
MT: – Δεν χρειάζεται να ξέρεις τίποτα απολύτως! Αν μιλάμε για το πώς λειτουργεί στον πελάτη: όταν ο πελάτης θέλει να χρησιμοποιήσει την Αιτιακή συνέπεια, πρέπει να ανοίξει μια συνεδρία. Τώρα όλα είναι εκεί: συναλλαγές στη συνεδρία και ανάκτηση δικαιωμάτων... Μια συνεδρία είναι η σειρά των λογικών γεγονότων που συμβαίνουν με τον πελάτη.
Αν ανοίξει αυτή τη συνεδρία και πει εκεί ότι θέλει Αιτιακή συνέπεια (αν η περίοδος λειτουργίας υποστηρίζει την Αιτιατική συνέπεια από προεπιλογή), όλα λειτουργούν αυτόματα. Ο οδηγός θυμάται αυτή τη φορά και την αυξάνει όταν λαμβάνει νέο μήνυμα. Θυμάται ποια απόκριση επέστρεψε ο προηγούμενος από τον διακομιστή που επέστρεψε τα δεδομένα. Το επόμενο αίτημα θα περιέχει afterCluster("χρόνος μεγαλύτερος από αυτό").
Ο πελάτης δεν χρειάζεται να ξέρει απολύτως τίποτα! Αυτό του είναι εντελώς αδιαφανές. Αν οι άνθρωποι χρησιμοποιούν αυτές τις δυνατότητες, τι μπορούν να κάνουν; Πρώτον, μπορείτε να διαβάσετε με ασφάλεια δευτερεύοντα: μπορείτε να γράψετε στο Primary και να διαβάσετε από γεωγραφικά αναπαραγόμενα δευτερεύοντα και να είστε σίγουροι ότι λειτουργεί. Ταυτόχρονα, οι περίοδοι σύνδεσης που καταγράφηκαν στο Primary μπορούν ακόμη και να μεταφερθούν στο Secondary, δηλαδή μπορείτε να χρησιμοποιήσετε όχι μία περίοδο σύνδεσης, αλλά πολλές.
ΣΤΟ: – Ένα νέο επίπεδο υπολογιστικής επιστήμης – τύποι δεδομένων CRDT (Conflict-replicated Data Types) – σχετίζεται στενά με το θέμα της Ενδεχόμενης συνέπειας. Έχετε σκεφτεί να ενσωματώσετε αυτά τα είδη δεδομένων στη βάση δεδομένων και τι μπορείτε να πείτε για αυτό;
MT: - Καλή ερώτηση! Το CRDT έχει νόημα για διενέξεις εγγραφής: στο MongoDB, single master.
ΣΤΟ: – Έχω μια ερώτηση από τους devops. Στον πραγματικό κόσμο, υπάρχουν τέτοιες ιησουϊτικές καταστάσεις όταν συμβαίνει η Βυζαντινή Αποτυχία, και οι κακοί άνθρωποι μέσα στην προστατευμένη περίμετρο αρχίζουν να τρυπώνουν στο πρωτόκολλο, στέλνουν πακέτα χειροτεχνίας με ειδικό τρόπο;
MT: – Οι κακοί άνθρωποι μέσα στην περίμετρο είναι σαν δούρειος ίππος! Οι κακοί άνθρωποι μέσα στην περίμετρο μπορούν να κάνουν πολλά άσχημα πράγματα.
ΣΤΟ: – Είναι ξεκάθαρο ότι αφήνοντας, χοντρικά μιλώντας, μια τρύπα στον διακομιστή μέσα από την οποία μπορείτε να βάλετε έναν ζωολογικό κήπο με ελέφαντες και να καταρρεύσετε ολόκληρο το σύμπλεγμα για πάντα... Θα χρειαστεί χρόνος για χειροκίνητη ανάκτηση... Αυτό, για να το θέσω ήπια, είναι λανθασμένος. Από την άλλη πλευρά, αυτό είναι ενδιαφέρον: στην πραγματική ζωή, στην πράξη, υπάρχουν καταστάσεις όπου συμβαίνουν φυσικά παρόμοιες εσωτερικές επιθέσεις;
MT: – Δεδομένου ότι σπάνια συναντώ παραβιάσεις ασφάλειας στην πραγματική ζωή, δεν μπορώ να πω αν συμβαίνουν. Αλλά αν μιλάμε για τη φιλοσοφία ανάπτυξης, σκεφτόμαστε ως εξής: έχουμε μια περίμετρο που παρέχει στους τύπους που κάνουν ασφάλεια - αυτό είναι ένα κάστρο, ένας τοίχος. και μέσα στην περίμετρο μπορείς να κάνεις ότι θέλεις. Είναι σαφές ότι υπάρχουν χρήστες με δυνατότητα μόνο προβολής και υπάρχουν χρήστες με δυνατότητα διαγραφής του καταλόγου.
Ανάλογα με τα δικαιώματα, η ζημιά που μπορούν να κάνουν οι χρήστες μπορεί να είναι ένα ποντίκι ή μπορεί να είναι ένας ελέφαντας. Είναι σαφές ότι ένας χρήστης με πλήρη δικαιώματα μπορεί να κάνει τα πάντα. Ένας χρήστης με περιορισμένα δικαιώματα μπορεί να προκαλέσει σημαντικά μικρότερη βλάβη. Συγκεκριμένα, δεν μπορεί να σπάσει το σύστημα.
ΣΤΟ: – Στην προστατευμένη περίμετρο, κάποιος προσπάθησε να δημιουργήσει απροσδόκητα πρωτόκολλα για τον διακομιστή, προκειμένου να καταστρέψει εντελώς τον διακομιστή, και αν είστε τυχεροί, ολόκληρο το σύμπλεγμα... Βγαίνει ποτέ τόσο «καλό»;
MT: «Δεν έχω ακούσει ποτέ για τέτοια πράγματα». Το γεγονός ότι μπορείτε να καταρρίψετε έναν διακομιστή με αυτόν τον τρόπο δεν είναι μυστικό. Αποτυχία μέσα, όντας από το πρωτόκολλο, εξουσιοδοτημένος χρήστης που μπορεί να γράψει κάτι τέτοιο στο μήνυμα... Στην πραγματικότητα, είναι αδύνατο, γιατί θα εξακολουθήσει να επαληθεύεται. Είναι δυνατό να απενεργοποιήσετε αυτόν τον έλεγχο ταυτότητας για χρήστες που δεν το θέλουν - τότε αυτό είναι το πρόβλημά τους. αυτοί, χοντρικά, κατέστρεψαν μόνοι τους τους τοίχους και μπορείς να σπρώξεις έναν ελέφαντα μέσα, που θα πατήσει... Αλλά γενικά μπορείς να ντυθείς επισκευαστής, έλα να τον βγάλεις!
ΣΤΟ: – Ευχαριστώ για την αναφορά. Σεργκέι (Yandex). Υπάρχει μια σταθερά στο Mong που περιορίζει τον αριθμό των μελών με δικαίωμα ψήφου στο Σύνολο Replica, και αυτή η σταθερά είναι 7 (επτά). Γιατί αυτό είναι σταθερά; Γιατί αυτό δεν είναι κάποιο είδος παραμέτρου;
MT: – Έχουμε Replica Sets με 40 κόμβους. Υπάρχει πάντα η πλειοψηφία. Δεν ξέρω ποια έκδοση...
ΣΤΟ: – Στο Replica Set μπορείτε να εκτελέσετε μέλη χωρίς δικαίωμα ψήφου, αλλά υπάρχουν το πολύ 7 μέλη με δικαίωμα ψήφου. Πώς μπορούμε να επιβιώσουμε από τον τερματισμό λειτουργίας σε αυτήν την περίπτωση εάν το Replica Set μας είναι κατανεμημένο σε 3 κέντρα δεδομένων; Ένα κέντρο δεδομένων μπορεί εύκολα να απενεργοποιηθεί και ένα άλλο μηχάνημα μπορεί να πέσει έξω.
MT: – (EN) Αυτό είναι ήδη λίγο πέρα από το πεδίο εφαρμογής της έκθεσης. Αυτή είναι μια γενική ερώτηση. Ίσως μπορώ να σας πω για αυτό αργότερα.
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com