Σημείωση. μετάφρ.: Η Jaana Dogan είναι μια έμπειρη μηχανικός στην Google που αυτή τη στιγμή εργάζεται για την παρατηρησιμότητα των υπηρεσιών παραγωγής της εταιρείας γραμμένες στο Go. Σε αυτό το άρθρο, το οποίο απέκτησε μεγάλη δημοτικότητα στο αγγλόφωνο κοινό, συγκέντρωσε σε 17 σημεία σημαντικές τεχνικές λεπτομέρειες σχετικά με τα DBMS (και μερικές φορές τα κατανεμημένα συστήματα γενικά) που είναι χρήσιμα να ληφθούν υπόψη για προγραμματιστές μεγάλων/ απαιτητικών εφαρμογών.
Η συντριπτική πλειοψηφία των συστημάτων υπολογιστών παρακολουθεί την κατάστασή τους και, κατά συνέπεια, απαιτεί κάποιο είδος συστήματος αποθήκευσης δεδομένων. Συσσώρευσα γνώσεις σχετικά με τις βάσεις δεδομένων για μεγάλο χρονικό διάστημα, κάνοντας λάθη σχεδιασμού που οδήγησαν σε απώλεια δεδομένων και διακοπές λειτουργίας. Σε συστήματα που επεξεργάζονται μεγάλους όγκους πληροφοριών, οι βάσεις δεδομένων βρίσκονται στο επίκεντρο της αρχιτεκτονικής του συστήματος και λειτουργούν ως βασικό στοιχείο για την επιλογή της βέλτιστης λύσης. Παρά το γεγονός ότι δίνεται μεγάλη προσοχή στη δουλειά της βάσης δεδομένων, τα προβλήματα που προσπαθούν να προβλέψουν οι προγραμματιστές εφαρμογών είναι συχνά μόνο η κορυφή του παγόβουνου. Σε αυτήν τη σειρά άρθρων, μοιράζομαι μερικές ιδέες που θα είναι χρήσιμες για προγραμματιστές που δεν είναι εξειδικευμένοι σε αυτόν τον τομέα.
- Είστε τυχεροί αν το 99,999% των περιπτώσεων δεν προκαλεί προβλήματα στο δίκτυο.
- ΟΞΥ σημαίνει πολλά διαφορετικά πράγματα.
- Κάθε βάση δεδομένων έχει τους δικούς της μηχανισμούς για τη διασφάλιση της συνέπειας και της απομόνωσης.
- Το αισιόδοξο μπλοκάρισμα έρχεται να σώσει όταν είναι δύσκολο να διατηρήσεις το συνηθισμένο.
- Υπάρχουν και άλλες ανωμαλίες εκτός από βρώμικες αναγνώσεις και απώλεια δεδομένων.
- Η βάση δεδομένων και ο χρήστης δεν συμφωνούν πάντα για την πορεία δράσης.
- Η κοινή χρήση σε επίπεδο εφαρμογής μπορεί να μετακινηθεί εκτός της εφαρμογής.
- Η αυτόματη αύξηση μπορεί να είναι επικίνδυνη.
- Τα παλιά δεδομένα μπορεί να είναι χρήσιμα και δεν χρειάζεται να κλειδωθούν.
- Οι παραμορφώσεις είναι χαρακτηριστικές για οποιεσδήποτε χρονικές πηγές.
- Η καθυστέρηση έχει πολλές έννοιες.
- Οι απαιτήσεις απόδοσης θα πρέπει να αξιολογούνται για μια συγκεκριμένη συναλλαγή.
- Οι ένθετες συναλλαγές μπορεί να είναι επικίνδυνες.
- Οι συναλλαγές δεν πρέπει να συνδέονται με την κατάσταση εφαρμογής.
- Οι σχεδιαστές ερωτημάτων μπορούν να σας πουν πολλά για τις βάσεις δεδομένων.
- Η διαδικτυακή μετανάστευση είναι δύσκολη, αλλά δυνατή.
- Μια σημαντική αύξηση στη βάση δεδομένων συνεπάγεται αύξηση της μη προβλεψιμότητας.
Θα ήθελα να ευχαριστήσω τον Emmanuel Odeke, τον Rein Henrichs και άλλους για τα σχόλιά τους σχετικά με μια προηγούμενη έκδοση αυτού του άρθρου.
Είστε τυχεροί αν το 99,999% των περιπτώσεων δεν προκαλεί προβλήματα στο δίκτυο.
Το ερώτημα παραμένει σχετικά με το πόσο αξιόπιστες είναι οι σύγχρονες τεχνολογίες δικτύου και πόσο συχνά τα συστήματα απενεργοποιούνται λόγω αστοχιών δικτύου. Οι πληροφορίες για αυτό το θέμα είναι σπάνιες και η έρευνα συχνά κυριαρχείται από μεγάλους οργανισμούς με εξειδικευμένα δίκτυα, εξοπλισμό και προσωπικό.
Με ποσοστό διαθεσιμότητας 99,999% για το Spanner (την παγκόσμια κατανεμημένη βάση δεδομένων της Google), η Google ισχυρίζεται ότι μόνο προβλήματα σχετίζονται με το δίκτυο. Ταυτόχρονα, η εταιρεία αποκαλεί το εξειδικευμένο της δίκτυο «κύριο πυλώνα» της υψηλής διαθεσιμότητας. Μελέτη , που πραγματοποιήθηκε το 2014, αμφισβητεί ένα από τα «», την οποία διατύπωσε ο Peter Deutsch το 1994. Είναι πραγματικά αξιόπιστο το δίκτυο;
Ολοκληρωμένη έρευνα εκτός εταιρειών κολοσσών, που γίνεται για το ευρύτερο Διαδίκτυο, απλά δεν υπάρχει. Δεν υπάρχουν επίσης αρκετά στοιχεία από τους μεγάλους παίκτες σχετικά με το ποσοστό των προβλημάτων των πελατών τους που σχετίζονται με το δίκτυο. Γνωρίζουμε καλά τις διακοπές στη στοίβα δικτύου μεγάλων παρόχων cloud που μπορούν να καταργήσουν ένα ολόκληρο κομμάτι του Διαδικτύου για αρκετές ώρες απλώς και μόνο επειδή είναι γεγονότα υψηλού προφίλ που επηρεάζουν μεγάλο αριθμό ατόμων και εταιρειών. Οι διακοπές δικτύου μπορεί να προκαλέσουν προβλήματα σε πολλές περισσότερες περιπτώσεις, ακόμα κι αν δεν βρίσκονται όλες αυτές οι περιπτώσεις στο επίκεντρο. Οι πελάτες υπηρεσιών cloud δεν γνωρίζουν επίσης τίποτα για τις αιτίες των προβλημάτων. Εάν υπάρχει αποτυχία, είναι σχεδόν αδύνατο να αποδοθεί σε σφάλμα δικτύου από την πλευρά του παρόχου υπηρεσιών. Για αυτούς, οι υπηρεσίες τρίτων είναι μαύρα κουτιά. Είναι αδύνατο να εκτιμηθεί ο αντίκτυπος χωρίς να είσαι μεγάλος πάροχος υπηρεσιών.
Δεδομένων των όσων αναφέρουν οι μεγάλοι παίκτες για τα συστήματά τους, είναι ασφαλές να πούμε ότι είστε τυχεροί εάν οι δυσκολίες δικτύου αντιπροσωπεύουν μόνο ένα μικρό ποσοστό των πιθανών προβλημάτων χρόνου διακοπής λειτουργίας. Οι επικοινωνίες δικτύου εξακολουθούν να υποφέρουν από τέτοια εγκόσμια πράγματα όπως αστοχίες υλικού, αλλαγές τοπολογίας, αλλαγές στις ρυθμίσεις παραμέτρων διαχείρισης και διακοπές ρεύματος. Πρόσφατα, με έκπληξη έμαθα ότι προστέθηκε η λίστα με τα πιθανά προβλήματα (ναι καλά ακούσατε).
ΟΞΥ σημαίνει πολλά διαφορετικά πράγματα
Το ακρωνύμιο ACID σημαίνει Atomicity, Consistency, Isolation, Reliability. Αυτές οι ιδιότητες των συναλλαγών αποσκοπούν στη διασφάλιση της εγκυρότητάς τους σε περίπτωση αστοχιών, σφαλμάτων, αστοχιών υλικού κ.λπ. Χωρίς ACID ή παρόμοια σχήματα, θα ήταν δύσκολο για τους προγραμματιστές εφαρμογών να κάνουν διαφοροποίηση μεταξύ του τι είναι υπεύθυνοι και για το τι είναι υπεύθυνη η βάση δεδομένων. Οι περισσότερες βάσεις δεδομένων σχεσιακών συναλλαγών προσπαθούν να είναι συμβατές με ACID, αλλά νέες προσεγγίσεις όπως η NoSQL έχουν οδηγήσει σε πολλές βάσεις δεδομένων χωρίς συναλλαγές ACID, επειδή είναι ακριβές στην εφαρμογή τους.
Όταν μπήκα για πρώτη φορά στον κλάδο, ο τεχνικός μας επικεφαλής μίλησε για το πόσο σχετική ήταν η ιδέα του ACID. Για να είμαστε δίκαιοι, το ACID θεωρείται μια πρόχειρη περιγραφή παρά ένα αυστηρό πρότυπο εφαρμογής. Σήμερα το βρίσκω κυρίως χρήσιμο γιατί εγείρει μια συγκεκριμένη κατηγορία ζητημάτων (και προτείνει μια σειρά από πιθανές λύσεις).
Δεν είναι όλα τα DBMS συμβατά με ACID. Ταυτόχρονα, οι υλοποιήσεις βάσεων δεδομένων που υποστηρίζουν το ACID κατανοούν διαφορετικά το σύνολο των απαιτήσεων. Ένας από τους λόγους για τους οποίους οι υλοποιήσεις ACID είναι αποσπασματικές οφείλεται στις πολλές αντισταθμίσεις που πρέπει να γίνουν για την εφαρμογή των απαιτήσεων ACID. Οι δημιουργοί μπορεί να παρουσιάζουν τις βάσεις δεδομένων τους ως συμβατές με ACID, αλλά η ερμηνεία των περιπτώσεων ακμών μπορεί να ποικίλλει δραματικά, όπως και ο μηχανισμός χειρισμού «απίθανων» συμβάντων. Τουλάχιστον, οι προγραμματιστές μπορούν να αποκτήσουν μια υψηλού επιπέδου κατανόηση των περιπλοκών των βασικών εφαρμογών για να κατανοήσουν σωστά την ειδική συμπεριφορά τους και τους συμβιβασμούς σχεδιασμού.
Η συζήτηση σχετικά με το εάν το MongoDB συμμορφώνεται με τις απαιτήσεις ACID συνεχίζεται ακόμη και μετά την κυκλοφορία της έκδοσης 4. Το MongoDB δεν υποστηρίζεται εδώ και πολύ καιρό , αν και από προεπιλογή τα δεδομένα δεσμεύονταν στο δίσκο όχι περισσότερο από μία φορά κάθε 60 δευτερόλεπτα. Φανταστείτε το ακόλουθο σενάριο: μια εφαρμογή δημοσιεύει δύο εγγραφές (w1 και w2). Το MongoDB αποθηκεύει με επιτυχία το w1, αλλά το w2 χάνεται λόγω βλάβης υλικού.
Διάγραμμα που απεικονίζει το σενάριο. Το MongoDB διακόπτεται πριν μπορέσει να γράψει δεδομένα στο δίσκο
Η δέσμευση στο δίσκο είναι μια δαπανηρή διαδικασία. Αποφεύγοντας τις συχνές δεσμεύσεις, οι προγραμματιστές βελτιώνουν την απόδοση εγγραφής σε βάρος της αξιοπιστίας. Το MongoDB υποστηρίζει επί του παρόντος την καταγραφή, αλλά οι βρώμικες εγγραφές μπορούν ακόμα να επηρεάσουν την ακεραιότητα των δεδομένων, καθώς τα αρχεία καταγραφής καταγράφονται κάθε 100 ms από προεπιλογή. Δηλαδή, ένα παρόμοιο σενάριο είναι ακόμα δυνατό για τα αρχεία καταγραφής και τις αλλαγές που παρουσιάζονται σε αυτά, αν και ο κίνδυνος είναι πολύ μικρότερος.
Κάθε βάση δεδομένων έχει τους δικούς της μηχανισμούς συνέπειας και απομόνωσης
Από τις απαιτήσεις ACID, η συνέπεια και η απομόνωση διαθέτουν τον μεγαλύτερο αριθμό διαφορετικών εφαρμογών, επειδή το εύρος των αντισταθμίσεων είναι ευρύτερο. Πρέπει να πούμε ότι η συνέπεια και η απομόνωση είναι αρκετά ακριβές λειτουργίες. Απαιτούν συντονισμό και αυξάνουν τον ανταγωνισμό για τη συνέπεια των δεδομένων. Η πολυπλοκότητα του προβλήματος αυξάνεται σημαντικά όταν είναι απαραίτητο να κλιμακωθεί οριζόντια η βάση δεδομένων σε πολλά κέντρα δεδομένων (ειδικά αν βρίσκονται σε διαφορετικές γεωγραφικές περιοχές). Η επίτευξη υψηλού επιπέδου συνέπειας είναι πολύ δύσκολη, καθώς μειώνει επίσης τη διαθεσιμότητα και αυξάνει την τμηματοποίηση του δικτύου. Για μια γενικότερη εξήγηση αυτού του φαινομένου, σας συμβουλεύω να ανατρέξετε . Αξίζει επίσης να σημειωθεί ότι οι εφαρμογές μπορούν να χειριστούν μικρές ποσότητες ασυνέπειας και οι προγραμματιστές μπορούν να κατανοήσουν τις αποχρώσεις του προβλήματος αρκετά καλά ώστε να εφαρμόσουν πρόσθετη λογική στην εφαρμογή για να χειριστεί την ασυνέπεια χωρίς να βασίζονται σε μεγάλο βαθμό στη βάση δεδομένων για να το χειριστούν.
Τα DBMS παρέχουν συχνά διαφορετικά επίπεδα απομόνωσης. Οι προγραμματιστές εφαρμογών μπορούν να επιλέξουν την πιο αποτελεσματική με βάση τις προτιμήσεις τους. Η χαμηλή απομόνωση επιτρέπει αυξημένη ταχύτητα, αλλά και αυξάνει τον κίνδυνο αγώνα δεδομένων. Η υψηλή μόνωση μειώνει αυτή την πιθανότητα, αλλά επιβραδύνει την εργασία και μπορεί να οδηγήσει σε ανταγωνισμό, που θα οδηγήσει σε τέτοια φρένα στη βάση που αρχίζουν οι αστοχίες.
Ανασκόπηση των υφιστάμενων μοντέλων συγχρονισμού και των σχέσεων μεταξύ τους
Το πρότυπο SQL ορίζει μόνο τέσσερα επίπεδα απομόνωσης, αν και θεωρητικά και πρακτικά υπάρχουν πολλά περισσότερα. προσφέρει μια εξαιρετική επισκόπηση των υφιστάμενων μοντέλων συγχρονισμού. Για παράδειγμα, το Google Spanner εγγυάται τη δυνατότητα εξωτερικής σειριοποίησης με συγχρονισμό ρολογιού και, παρόλο που πρόκειται για ένα πιο αυστηρό επίπεδο απομόνωσης, δεν ορίζεται σε τυπικά επίπεδα απομόνωσης.
Το πρότυπο SQL αναφέρει τα ακόλουθα επίπεδα απομόνωσης:
- Serializable (πιο αυστηρή και δαπανηρή): Η σειροποιήσιμη εκτέλεση έχει το ίδιο αποτέλεσμα με κάποια διαδοχική εκτέλεση συναλλαγών. Διαδοχική εκτέλεση σημαίνει ότι κάθε επόμενη συναλλαγή ξεκινά μόνο αφού ολοκληρωθεί η προηγούμενη. Πρέπει να σημειωθεί ότι το επίπεδο Serializable συχνά υλοποιείται ως η λεγόμενη απομόνωση στιγμιότυπου (για παράδειγμα, στο Oracle) λόγω διαφορών στην ερμηνεία, αν και η ίδια η απομόνωση στιγμιότυπου δεν αναπαρίσταται στο πρότυπο SQL.
- Επαναλαμβανόμενες αναγνώσεις: Οι μη δεσμευμένες εγγραφές στην τρέχουσα συναλλαγή είναι διαθέσιμες στην τρέχουσα συναλλαγή, αλλά οι αλλαγές γίνονται από άλλες συναλλαγές (όπως νέες σειρές) .
- Διαβάστε δεσμευμένοι: Τα μη δεσμευμένα δεδομένα δεν είναι διαθέσιμα για συναλλαγές. Σε αυτήν την περίπτωση, οι συναλλαγές μπορούν να δουν μόνο δεσμευμένα δεδομένα και ενδέχεται να προκύψουν φανταστικές αναγνώσεις. Εάν μια συναλλαγή εισάγει και δεσμεύει νέες σειρές, η τρέχουσα συναλλαγή θα μπορεί να τις δει όταν ζητηθεί.
- Διαβάστε αδέσμευτη (λιγότερο αυστηρό και ακριβό επίπεδο): Επιτρέπονται οι βρώμικες αναγνώσεις, οι συναλλαγές μπορούν να δουν μη δεσμευμένες αλλαγές που έγιναν από άλλες συναλλαγές. Στην πράξη, αυτό το επίπεδο μπορεί να είναι χρήσιμο για πρόχειρες εκτιμήσεις, όπως ερωτήματα
COUNT(*)πάνω στο τραπέζι.
Επίπεδο Serializable ελαχιστοποιεί τον κίνδυνο αγώνων δεδομένων, ενώ είναι το πιο ακριβό στην εφαρμογή και έχει ως αποτέλεσμα το υψηλότερο ανταγωνιστικό φορτίο στο σύστημα. Άλλα επίπεδα απομόνωσης είναι πιο εύκολο να εφαρμοστούν, αλλά αυξάνουν την πιθανότητα αγώνων δεδομένων. Ορισμένα DBMS σάς επιτρέπουν να ορίσετε ένα προσαρμοσμένο επίπεδο απομόνωσης, άλλα έχουν ισχυρές προτιμήσεις και δεν υποστηρίζονται όλα τα επίπεδα.
Η υποστήριξη για επίπεδα απομόνωσης συχνά διαφημίζεται σε ένα δεδομένο DBMS, αλλά μόνο μια προσεκτική μελέτη της συμπεριφοράς του μπορεί να αποκαλύψει τι συμβαίνει στην πραγματικότητα.
Ανασκόπηση ανωμαλιών συγχρονισμού σε διαφορετικά επίπεδα απομόνωσης για διαφορετικά DBMS
Ο Martin Kleppmann στο έργο του Συγκρίνει διαφορετικά επίπεδα απομόνωσης, μιλά για ανωμαλίες συγχρονισμού και εάν η βάση δεδομένων είναι σε θέση να τηρήσει ένα συγκεκριμένο επίπεδο απομόνωσης. Η έρευνα του Kleppmann δείχνει πόσο διαφορετικά σκέφτονται οι προγραμματιστές βάσεων δεδομένων για τα επίπεδα απομόνωσης.
Το αισιόδοξο μπλοκάρισμα έρχεται να σώσει όταν είναι δύσκολο να διατηρήσεις το συνηθισμένο.
Ο αποκλεισμός μπορεί να είναι πολύ ακριβός, όχι μόνο επειδή αυξάνει τον ανταγωνισμό στη βάση δεδομένων, αλλά και επειδή απαιτεί από τους διακομιστές εφαρμογών να συνδέονται συνεχώς με τη βάση δεδομένων. Η τμηματοποίηση δικτύου μπορεί να επιδεινώσει τις καταστάσεις αποκλειστικού κλειδώματος και να οδηγήσει σε αδιέξοδα που είναι δύσκολο να εντοπιστούν και να επιλυθούν. Σε περιπτώσεις που το αποκλειστικό κλείδωμα δεν είναι κατάλληλο, το αισιόδοξο κλείδωμα βοηθά.
είναι μια μέθοδος κατά την οποία κατά την ανάγνωση μιας συμβολοσειράς, λαμβάνει υπόψη την έκδοση, το άθροισμα ελέγχου ή τον χρόνο τελευταίας τροποποίησης. Αυτό σας επιτρέπει να διασφαλίσετε ότι δεν υπάρχει αλλαγή ατομικής έκδοσης πριν αλλάξετε μια καταχώριση:
UPDATE products
SET name = 'Telegraph receiver', version = 2
WHERE id = 1 AND version = 1
Σε αυτήν την περίπτωση, ενημέρωση του πίνακα products δεν θα εκτελεστεί εάν κάποια άλλη λειτουργία έκανε προηγουμένως αλλαγές σε αυτήν τη σειρά. Εάν δεν πραγματοποιήθηκαν άλλες λειτουργίες σε αυτήν τη σειρά, θα συμβεί η αλλαγή για μία σειρά και μπορούμε να πούμε ότι η ενημέρωση ήταν επιτυχής.
Υπάρχουν και άλλες ανωμαλίες εκτός από βρώμικες αναγνώσεις και απώλεια δεδομένων
Όσον αφορά τη συνοχή των δεδομένων, η εστίαση είναι στις πιθανές συνθήκες αγώνα που μπορεί να οδηγήσουν σε βρώμικες αναγνώσεις και απώλεια δεδομένων. Ωστόσο, οι ανωμαλίες δεδομένων δεν σταματούν εκεί.
Ένα παράδειγμα τέτοιων ανωμαλιών είναι η καταγραφή παραμόρφωσης (γράψτε λοξές). Οι παραμορφώσεις είναι δύσκολο να εντοπιστούν επειδή συνήθως δεν αναζητούνται ενεργά. Δεν οφείλονται σε βρώμικες αναγνώσεις ή απώλεια δεδομένων, αλλά σε παραβιάσεις των λογικών περιορισμών που τίθενται στα δεδομένα.
Για παράδειγμα, ας εξετάσουμε μια εφαρμογή παρακολούθησης που απαιτεί από έναν χειριστή να είναι σε ετοιμότητα ανά πάσα στιγμή:
BEGIN tx1; BEGIN tx2;
SELECT COUNT(*)
FROM operators
WHERE oncall = true;
0 SELECT COUNT(*)
FROM operators
WHERE oncall = TRUE;
0
UPDATE operators UPDATE operators
SET oncall = TRUE SET oncall = TRUE
WHERE userId = 4; WHERE userId = 2;
COMMIT tx1; COMMIT tx2;Στην παραπάνω περίπτωση, θα προκύψει καταστροφή ρεκόρ εάν και οι δύο συναλλαγές πραγματοποιηθούν με επιτυχία. Αν και δεν υπήρχαν βρώμικες αναγνώσεις ή απώλεια δεδομένων, η ακεραιότητα των δεδομένων διακυβεύτηκε: τώρα δύο άτομα θεωρούνται σε εφημερία ταυτόχρονα.
Η σειριοποιήσιμη απομόνωση, ο σχεδιασμός σχήματος ή οι περιορισμοί βάσης δεδομένων μπορούν να βοηθήσουν στην εξάλειψη της καταστροφής της εγγραφής. Οι προγραμματιστές πρέπει να είναι σε θέση να εντοπίζουν τέτοιες ανωμαλίες κατά την ανάπτυξη, προκειμένου να τις αποφύγουν στην παραγωγή. Ταυτόχρονα, οι παραμορφώσεις εγγραφής είναι εξαιρετικά δύσκολο να αναζητηθούν στη βάση κώδικα. Ειδικά σε μεγάλα συστήματα, όταν διαφορετικές ομάδες ανάπτυξης είναι υπεύθυνες για την υλοποίηση λειτουργιών που βασίζονται στους ίδιους πίνακες και δεν συμφωνούν στις ιδιαιτερότητες της πρόσβασης στα δεδομένα.
Η βάση δεδομένων και ο χρήστης δεν συμφωνούν πάντα για το τι πρέπει να κάνουν
Ένα από τα βασικά χαρακτηριστικά των βάσεων δεδομένων είναι η εγγύηση της εντολής εκτέλεσης, αλλά αυτή η ίδια η εντολή μπορεί να μην είναι διαφανής για τον προγραμματιστή λογισμικού. Οι βάσεις δεδομένων εκτελούν τις συναλλαγές με τη σειρά που λαμβάνονται και όχι με τη σειρά που σκοπεύουν οι προγραμματιστές. Η σειρά των συναλλαγών είναι δύσκολο να προβλεφθεί, ειδικά σε παράλληλα συστήματα με υψηλό φορτίο.
Κατά την ανάπτυξη, ειδικά όταν εργάζεστε με μη αποκλειστικές βιβλιοθήκες, το κακό στυλ και η χαμηλή αναγνωσιμότητα μπορεί να κάνουν τους χρήστες να πιστεύουν ότι οι συναλλαγές εκτελούνται διαδοχικά, ενώ στην πραγματικότητα θα μπορούσαν να φτάσουν στη βάση δεδομένων με οποιαδήποτε σειρά.
Με την πρώτη ματιά, στο παρακάτω πρόγραμμα, τα T1 και T2 καλούνται διαδοχικά, αλλά εάν αυτές οι συναρτήσεις είναι μη μπλοκαρισμένες και επιστρέφουν αμέσως το αποτέλεσμα στη μορφή , τότε η σειρά των κλήσεων θα καθοριστεί από τις στιγμές που εισήλθαν στη βάση δεδομένων:
result1 = T1() // τα πραγματικά αποτελέσματα είναι υποσχέσεις
αποτέλεσμα2 = T2()
Εάν απαιτείται ατομικότητα (δηλαδή, είτε πρέπει να ολοκληρωθούν είτε να ματαιωθούν όλες οι λειτουργίες) και έχει σημασία η αλληλουχία, τότε οι λειτουργίες Τ1 και Τ2 πρέπει να εκτελούνται σε μία μόνο συναλλαγή.
Η κοινή χρήση σε επίπεδο εφαρμογής μπορεί να μετακινηθεί εκτός της εφαρμογής
Το Sharding είναι μια μέθοδος οριζόντιας κατάτμησης μιας βάσης δεδομένων. Ορισμένες βάσεις δεδομένων μπορούν να διαχωρίσουν αυτόματα τα δεδομένα οριζόντια, ενώ άλλες δεν μπορούν ή δεν είναι πολύ καλές σε αυτό. Όταν οι αρχιτέκτονες/προγραμματιστές δεδομένων είναι σε θέση να προβλέψουν ακριβώς πώς θα προσπελαστούν τα δεδομένα, μπορούν να δημιουργήσουν οριζόντια διαμερίσματα στο χώρο του χρήστη αντί να αναθέσουν αυτήν την εργασία στη βάση δεδομένων. Αυτή η διαδικασία ονομάζεται "διαμοιρασμός σε επίπεδο εφαρμογής" (διαμοιρασμός σε επίπεδο εφαρμογής).
Δυστυχώς, αυτό το όνομα δημιουργεί συχνά την εσφαλμένη αντίληψη ότι η κοινή χρήση ζει στις υπηρεσίες εφαρμογών. Στην πραγματικότητα, μπορεί να υλοποιηθεί ως ξεχωριστό επίπεδο μπροστά από τη βάση δεδομένων. Ανάλογα με την ανάπτυξη δεδομένων και τις επαναλήψεις σχημάτων, οι απαιτήσεις διαμοιρασμού μπορεί να γίνουν αρκετά περίπλοκες. Ορισμένες στρατηγικές ενδέχεται να ωφεληθούν από τη δυνατότητα επανάληψης χωρίς να χρειάζεται να ανακατανείμετε τους διακομιστές εφαρμογών.
Ένα παράδειγμα αρχιτεκτονικής στην οποία οι διακομιστές εφαρμογών διαχωρίζονται από την υπηρεσία διαμοιρασμού
Η μετακίνηση του διαμοιρασμού σε ξεχωριστή υπηρεσία επεκτείνει τη δυνατότητα χρήσης διαφορετικών στρατηγικών διαμοιρασμού χωρίς την ανάγκη αναδιάταξης εφαρμογών. είναι ένα παράδειγμα τέτοιου συστήματος διαμοιρασμού σε επίπεδο εφαρμογής. Το Vitess παρέχει οριζόντια κοινή χρήση για MySQL και επιτρέπει στους πελάτες να συνδεθούν σε αυτό μέσω του πρωτοκόλλου MySQL. Το σύστημα τμηματοποιεί τα δεδομένα σε διαφορετικούς κόμβους MySQL που δεν γνωρίζουν τίποτα ο ένας για τον άλλο.
Η αυτόματη αύξηση μπορεί να είναι επικίνδυνη
Το AUTOINCREMENT είναι ένας κοινός τρόπος δημιουργίας πρωτευόντων κλειδιών. Υπάρχουν συχνά περιπτώσεις όπου οι βάσεις δεδομένων χρησιμοποιούνται ως γεννήτριες αναγνωριστικών και η βάση δεδομένων περιέχει πίνακες που έχουν σχεδιαστεί για τη δημιουργία αναγνωριστικών. Υπάρχουν διάφοροι λόγοι για τους οποίους η δημιουργία πρωτευόντων κλειδιών με χρήση αυτόματης αύξησης απέχει πολύ από το να είναι ιδανική:
- Σε μια κατανεμημένη βάση δεδομένων, η αυτόματη αύξηση είναι ένα σοβαρό πρόβλημα. Για τη δημιουργία του αναγνωριστικού, απαιτείται καθολική κλειδαριά. Αντίθετα, μπορείτε να δημιουργήσετε ένα UUID: αυτό δεν απαιτεί αλληλεπίδραση μεταξύ διαφορετικών κόμβων βάσης δεδομένων. Η αυτόματη αύξηση με κλειδαριές μπορεί να οδηγήσει σε διαμάχη και να μειώσει σημαντικά την απόδοση στα ένθετα σε κατανεμημένες καταστάσεις. Ορισμένα DBMS (για παράδειγμα, MySQL) ενδέχεται να απαιτούν ειδική διαμόρφωση και πιο προσεκτική προσοχή για τη σωστή οργάνωση της αναπαραγωγής master-master. Και είναι εύκολο να κάνετε λάθη κατά τη διαμόρφωση, τα οποία θα οδηγήσουν σε αποτυχίες εγγραφής.
- Ορισμένες βάσεις δεδομένων έχουν αλγόριθμους κατάτμησης που βασίζονται σε πρωτεύοντα κλειδιά. Τα διαδοχικά αναγνωριστικά μπορεί να οδηγήσουν σε απρόβλεπτα hot spots και αυξημένο φορτίο σε ορισμένα διαμερίσματα, ενώ άλλα παραμένουν σε αδράνεια.
- Το πρωτεύον κλειδί είναι ο ταχύτερος τρόπος πρόσβασης σε μια σειρά σε μια βάση δεδομένων. Με καλύτερους τρόπους αναγνώρισης εγγραφών, τα διαδοχικά αναγνωριστικά μπορούν να μετατρέψουν την πιο σημαντική στήλη στους πίνακες σε μια άχρηστη στήλη γεμάτη με τιμές χωρίς νόημα. Επομένως, όποτε είναι δυνατόν, επιλέξτε ένα παγκοσμίως μοναδικό και φυσικό πρωτεύον κλειδί (π.χ. όνομα χρήστη).
Πριν αποφασίσετε για μια προσέγγιση, εξετάστε τον αντίκτυπο της αυτόματης αύξησης των αναγνωριστικών και των UUID στην ευρετηρίαση, τη διαμέριση και τον διαμοιρασμό.
Τα παλιά δεδομένα μπορεί να είναι χρήσιμα και να μην απαιτούν κλείδωμα
Multiversion Concurrency Control (MVCC) εφαρμόζει πολλές από τις απαιτήσεις συνέπειας που συζητήθηκαν εν συντομία παραπάνω. Ορισμένες βάσεις δεδομένων (για παράδειγμα, Postgres, Spanner) χρησιμοποιούν το MVCC για να "τροφοδοτούν" τις συναλλαγές με στιγμιότυπα — παλαιότερες εκδόσεις της βάσης δεδομένων. Οι συναλλαγές Snapshot μπορούν επίσης να σειριοποιηθούν για να διασφαλιστεί η συνέπεια. Κατά την ανάγνωση από ένα παλιό στιγμιότυπο, διαβάζονται παλιά δεδομένα.
Η ανάγνωση ελαφρώς παλιών δεδομένων μπορεί να είναι χρήσιμη, για παράδειγμα, κατά τη δημιουργία αναλυτικών στοιχείων από τα δεδομένα ή τον υπολογισμό κατά προσέγγιση συγκεντρωτικών τιμών.
Το πρώτο πλεονέκτημα της εργασίας με δεδομένα παλαιού τύπου είναι η χαμηλή καθυστέρηση (ειδικά εάν η βάση δεδομένων διανέμεται σε διαφορετικές γεωγραφικές περιοχές). Το δεύτερο είναι ότι οι συναλλαγές μόνο για ανάγνωση είναι χωρίς κλείδωμα. Αυτό είναι ένα σημαντικό πλεονέκτημα για εφαρμογές που διαβάζουν πολύ, αρκεί να μπορούν να χειριστούν μπαγιάτικα δεδομένα.
Ο διακομιστής εφαρμογών διαβάζει δεδομένα από το τοπικό αντίγραφο που δεν είναι ενημερωμένα κατά 5 δευτερόλεπτα, ακόμα κι αν η πιο πρόσφατη έκδοση είναι διαθέσιμη στην άλλη πλευρά του Ειρηνικού Ωκεανού
Τα DBMS εκκαθαρίζουν αυτόματα παλαιότερες εκδόσεις και, σε ορισμένες περιπτώσεις, σας επιτρέπουν να το κάνετε αυτό κατόπιν αιτήματος. Για παράδειγμα, η Postgres επιτρέπει στους χρήστες να κάνουν VACUUM κατόπιν αιτήματος, και επίσης περιοδικά εκτελεί αυτόματα αυτήν τη λειτουργία. Το Spanner λειτουργεί με έναν συλλέκτη σκουπιδιών για να απαλλαγεί από στιγμιότυπα παλαιότερα της μίας ώρας.
Οποιεσδήποτε πηγές χρόνου υπόκεινται σε παραμόρφωση
Το καλύτερα κρυμμένο μυστικό στην επιστήμη των υπολογιστών είναι ότι όλα τα API χρονισμού ψεύδονται. Στην πραγματικότητα, τα μηχανήματα μας δεν γνωρίζουν την ακριβή τρέχουσα ώρα. Οι υπολογιστές περιέχουν κρυστάλλους χαλαζία που παράγουν δονήσεις που χρησιμοποιούνται για τη διατήρηση του χρόνου. Ωστόσο, δεν είναι αρκετά ακριβείς και μπορεί να είναι μπροστά/υστερούν στον ακριβή χρόνο. Η βάρδια μπορεί να φτάσει τα 20 δευτερόλεπτα την ημέρα. Επομένως, η ώρα στους υπολογιστές μας πρέπει να συγχρονίζεται περιοδικά με την ώρα δικτύου.
Οι διακομιστές NTP χρησιμοποιούνται για συγχρονισμό, αλλά η ίδια η διαδικασία συγχρονισμού υπόκειται σε καθυστερήσεις δικτύου. Ακόμη και ο συγχρονισμός με έναν διακομιστή NTP στο ίδιο κέντρο δεδομένων απαιτεί κάποιο χρόνο. Είναι σαφές ότι η εργασία με έναν δημόσιο διακομιστή NTP μπορεί να οδηγήσει σε ακόμη μεγαλύτερη παραμόρφωση.
Τα ατομικά ρολόγια και τα αντίστοιχα GPS είναι καλύτερα για τον προσδιορισμό της τρέχουσας ώρας, αλλά είναι ακριβά και απαιτούν περίπλοκη ρύθμιση, επομένως δεν μπορούν να εγκατασταθούν σε κάθε αυτοκίνητο. Εξαιτίας αυτού, τα κέντρα δεδομένων χρησιμοποιούν μια κλιμακωτή προσέγγιση. Τα ατομικά ρολόγια ή/και GPS δείχνουν την ακριβή ώρα, μετά την οποία μεταδίδεται σε άλλα μηχανήματα μέσω δευτερευόντων διακομιστών. Αυτό σημαίνει ότι κάθε μηχάνημα θα έχει μια συγκεκριμένη μετατόπιση από τον ακριβή χρόνο.
Η κατάσταση επιδεινώνεται από το γεγονός ότι οι εφαρμογές και οι βάσεις δεδομένων βρίσκονται συχνά σε διαφορετικά μηχανήματα (αν όχι σε διαφορετικά κέντρα δεδομένων). Έτσι, ο χρόνος θα διαφέρει όχι μόνο στους κόμβους DB που διανέμονται σε διαφορετικά μηχανήματα. Θα είναι επίσης διαφορετικό στον διακομιστή εφαρμογών.
Το Google TrueTime ακολουθεί μια εντελώς διαφορετική προσέγγιση. Οι περισσότεροι άνθρωποι πιστεύουν ότι η πρόοδος της Google προς αυτή την κατεύθυνση εξηγείται από την απλή μετάβαση στα ατομικά ρολόγια και τα ρολόγια GPS, αλλά αυτό είναι μόνο ένα μέρος της μεγάλης εικόνας. Δείτε πώς λειτουργεί το TrueTime:
- Το TrueTime χρησιμοποιεί δύο διαφορετικές πηγές: GPS και ατομικά ρολόγια. Αυτά τα ρολόγια έχουν μη συσχετισμένες λειτουργίες αστοχίας. [δείτε σελίδα 5 για λεπτομέρειες - περίπου μετάφρ.), επομένως η κοινή χρήση τους αυξάνει την αξιοπιστία.
- Το TrueTime έχει ένα ασυνήθιστο API. Επιστρέφει το χρόνο ως ένα διάστημα με ενσωματωμένο σφάλμα μέτρησης και αβεβαιότητα. Η πραγματική χρονική στιγμή βρίσκεται κάπου μεταξύ των άνω και κάτω ορίων του διαστήματος. Το Spanner, η κατανεμημένη βάση δεδομένων της Google, απλώς περιμένει μέχρι να είναι ασφαλές να πούμε ότι η τρέχουσα ώρα είναι εκτός εύρους. Αυτή η μέθοδος εισάγει κάποιο λανθάνοντα χρόνο στο σύστημα, ειδικά εάν η αβεβαιότητα για τους κύριους είναι υψηλή, αλλά εξασφαλίζει την ορθότητα ακόμη και σε μια παγκόσμια κατανεμημένη κατάσταση.
Τα στοιχεία του κλειδιού χρησιμοποιούν το TrueTime, όπου η TT.now() επιστρέφει ένα διάστημα, επομένως το κλειδί απλώς αδράνει μέχρι το σημείο όπου μπορεί να είναι βέβαιο ότι η τρέχουσα ώρα έχει περάσει ένα συγκεκριμένο σημείο
Μειωμένη ακρίβεια στον προσδιορισμό της τρέχουσας ώρας σημαίνει αύξηση της διάρκειας των λειτουργιών του κλειδιού και μείωση της απόδοσης. Αυτός είναι ο λόγος για τον οποίο είναι σημαντικό να διατηρείται η υψηλότερη δυνατή ακρίβεια, παρόλο που είναι αδύνατο να αποκτήσετε ένα απόλυτα ακριβές ρολόι.
Η καθυστέρηση έχει πολλές έννοιες
Αν ρωτήσετε μια ντουζίνα ειδικούς για το τι είναι η καθυστέρηση, πιθανότατα θα λάβετε διαφορετικές απαντήσεις. Στο DBMS, ο λανθάνων χρόνος ονομάζεται συχνά "λανθάνουσα κατάσταση βάσης δεδομένων" και είναι διαφορετικός από αυτό που αντιλαμβάνεται ο πελάτης. Το γεγονός είναι ότι ο πελάτης παρατηρεί το άθροισμα της καθυστέρησης δικτύου και της καθυστέρησης της βάσης δεδομένων. Η δυνατότητα απομόνωσης του τύπου λανθάνοντος χρόνου είναι κρίσιμη κατά την αποσφαλμάτωση αυξανόμενων προβλημάτων. Κατά τη συλλογή και την εμφάνιση μετρήσεων, προσπαθείτε πάντα να προσέχετε και τους δύο τύπους.
Οι απαιτήσεις απόδοσης θα πρέπει να αξιολογούνται για μια συγκεκριμένη συναλλαγή
Μερικές φορές τα χαρακτηριστικά απόδοσης ενός ΣΔΒΔ και οι περιορισμοί του καθορίζονται ως προς την απόδοση εγγραφής/ανάγνωσης και την καθυστέρηση. Αυτό παρέχει μια γενική επισκόπηση των βασικών παραμέτρων του συστήματος, αλλά κατά την αξιολόγηση της απόδοσης ενός νέου DBMS, μια πολύ πιο ολοκληρωμένη προσέγγιση είναι η ξεχωριστή αξιολόγηση κρίσιμων λειτουργιών (για κάθε ερώτημα ή/και συναλλαγή). Παραδείγματα:
- Γράψτε την απόδοση και την καθυστέρηση κατά την εισαγωγή μιας νέας σειράς στον πίνακα X (με 50 εκατομμύρια σειρές) με καθορισμένους περιορισμούς και συμπλήρωση σειρών σε σχετικούς πίνακες.
- Καθυστέρηση στην εμφάνιση φίλων φίλων ενός συγκεκριμένου χρήστη όταν ο μέσος αριθμός φίλων είναι 500.
- Καθυστέρηση στην ανάκτηση των 100 κορυφαίων καταχωρήσεων από το ιστορικό ενός χρήστη, όταν ο χρήστης ακολουθεί 500 άλλους χρήστες με X καταχωρήσεις ανά ώρα.
Η αξιολόγηση και ο πειραματισμός μπορεί να περιλαμβάνουν τέτοιες κρίσιμες περιπτώσεις μέχρι να βεβαιωθείτε ότι η βάση δεδομένων πληροί τις απαιτήσεις απόδοσης. Ένας παρόμοιος εμπειρικός κανόνας λαμβάνει επίσης υπόψη αυτήν την ανάλυση κατά τη συλλογή μετρήσεων λανθάνοντος χρόνου και τον προσδιορισμό των SLO.
Λάβετε υπόψη σας την υψηλή συσχέτιση κατά τη συλλογή μετρήσεων για κάθε λειτουργία. Χρησιμοποιήστε αρχεία καταγραφής, συλλογή συμβάντων ή κατανεμημένη ανίχνευση για να λάβετε δεδομένα εντοπισμού σφαλμάτων υψηλής ισχύος. Στο άρθρο "» μπορείτε να εξοικειωθείτε με τις μεθοδολογίες καθυστερήσεων εντοπισμού σφαλμάτων.
Οι ένθετες συναλλαγές μπορεί να είναι επικίνδυνες
Δεν υποστηρίζει κάθε DBMS ένθετες συναλλαγές, αλλά όταν το κάνουν, τέτοιες συναλλαγές μπορεί να οδηγήσουν σε απροσδόκητα σφάλματα που δεν είναι πάντα εύκολο να εντοπιστούν (δηλαδή, θα πρέπει να είναι προφανές ότι υπάρχει κάποιο είδος ανωμαλίας).
Μπορείτε να αποφύγετε τη χρήση ένθετων συναλλαγών χρησιμοποιώντας βιβλιοθήκες πελατών που μπορούν να τις εντοπίσουν και να τις παρακάμψουν. Εάν οι ένθετες συναλλαγές δεν μπορούν να εγκαταλειφθούν, προσέξτε ιδιαίτερα κατά την υλοποίησή τους για να αποφύγετε απροσδόκητες καταστάσεις όπου οι ολοκληρωμένες συναλλαγές ακυρώνονται κατά λάθος λόγω ένθετων.
Η ενθυλάκωση συναλλαγών σε διαφορετικά επίπεδα μπορεί να οδηγήσει σε απροσδόκητες ένθετες συναλλαγές και από την άποψη της αναγνωσιμότητας του κώδικα, μπορεί να δυσχεράνει την κατανόηση των προθέσεων του συγγραφέα. Ρίξτε μια ματιά στο παρακάτω πρόγραμμα:
with newTransaction():
Accounts.create("609-543-222")
with newTransaction():
Accounts.create("775-988-322")
throw Rollback();Ποια θα είναι η έξοδος του παραπάνω κώδικα; Θα επαναφέρει και τις δύο συναλλαγές ή μόνο την εσωτερική; Τι συμβαίνει εάν βασιζόμαστε σε πολλαπλά επίπεδα βιβλιοθηκών που ενσωματώνουν τη δημιουργία συναλλαγών για εμάς; Θα μπορέσουμε να εντοπίσουμε και να βελτιώσουμε τέτοιες περιπτώσεις;
Φανταστείτε ένα επίπεδο δεδομένων με πολλαπλές λειτουργίες (π.χ. newAccount) εφαρμόζεται ήδη στις δικές της συναλλαγές. Τι θα συμβεί εάν τα εκτελείτε ως μέρος της επιχειρηματικής λογικής υψηλότερου επιπέδου που εκτελείται εντός της δικής του συναλλαγής; Ποια θα ήταν η απομόνωση και η συνέπεια σε αυτή την περίπτωση;
function newAccount(id string) {
with newTransaction():
Accounts.create(id)
}Αντί να αναζητάτε απαντήσεις σε τέτοιες ατελείωτες ερωτήσεις, είναι προτιμότερο να αποφεύγετε τις ένθετες συναλλαγές. Εξάλλου, το επίπεδο δεδομένων σας μπορεί εύκολα να εκτελεί λειτουργίες υψηλού επιπέδου χωρίς να δημιουργεί τις δικές του συναλλαγές. Επιπλέον, η ίδια η επιχειρηματική λογική είναι ικανή να ξεκινήσει μια συναλλαγή, να εκτελέσει λειτουργίες σε αυτήν, να δεσμεύσει ή να ματαιώσει μια συναλλαγή.
function newAccount(id string) {
Accounts.create(id)
}
// In main application:
with newTransaction():
// Read some data from database for configuration.
// Generate an ID from the ID service.
Accounts.create(id)
Uploads.create(id) // create upload queue for the user.Οι συναλλαγές δεν πρέπει να συνδέονται με την κατάσταση εφαρμογής
Μερικές φορές είναι δελεαστικό να χρησιμοποιείτε την κατάσταση εφαρμογής στις συναλλαγές για να αλλάξετε ορισμένες τιμές ή να τροποποιήσετε τις παραμέτρους του ερωτήματος. Η κρίσιμη απόχρωση που πρέπει να ληφθεί υπόψη είναι το σωστό πεδίο εφαρμογής. Οι πελάτες συχνά επανεκκινούν τις συναλλαγές όταν υπάρχουν προβλήματα δικτύου. Εάν η συναλλαγή στη συνέχεια εξαρτάται από μια κατάσταση που αλλάζει από κάποια άλλη διαδικασία, μπορεί να επιλέξει λάθος τιμή ανάλογα με την πιθανότητα μιας κούρσας δεδομένων. Οι συναλλαγές πρέπει να λαμβάνουν υπόψη τον κίνδυνο συνθηκών αγώνων δεδομένων στην εφαρμογή.
var seq int64
with newTransaction():
newSeq := atomic.Increment(&seq)
Entries.query(newSeq)
// Other operations...Η παραπάνω συναλλαγή θα αυξάνει τον αριθμό σειράς κάθε φορά που εκτελείται, ανεξάρτητα από το τελικό αποτέλεσμα. Εάν η δέσμευση αποτύχει λόγω προβλημάτων δικτύου, το αίτημα θα εκτελεστεί με διαφορετικό αριθμό σειράς όταν προσπαθήσετε ξανά.
Οι σχεδιαστές ερωτημάτων μπορούν να σας πουν πολλά για μια βάση δεδομένων
Οι σχεδιαστές ερωτημάτων καθορίζουν πώς θα εκτελεστεί ένα ερώτημα σε μια βάση δεδομένων. Αναλύουν επίσης αιτήματα και τα βελτιστοποιούν πριν τα στείλουν. Οι σχεδιαστές μπορούν να παρέχουν μόνο ορισμένες πιθανές εκτιμήσεις με βάση τα σήματα που έχουν στη διάθεσή τους. Για παράδειγμα, ποια είναι η καλύτερη μέθοδος αναζήτησης για το ακόλουθο ερώτημα;
SELECT * FROM articles where author = "rakyll" order by title;Τα αποτελέσματα μπορούν να ανακτηθούν με δύο τρόπους:
- Πλήρης σάρωση τραπεζιού: Μπορείτε να δείτε κάθε καταχώριση στον πίνακα και να επιστρέψετε άρθρα με αντίστοιχο όνομα συγγραφέα και, στη συνέχεια, να τα παραγγείλετε.
- Σάρωση ευρετηρίου: Μπορείτε να χρησιμοποιήσετε ένα ευρετήριο για να βρείτε αντίστοιχα αναγνωριστικά, να λάβετε αυτές τις σειρές και, στη συνέχεια, να τις παραγγείλετε.
Η δουλειά του σχεδιαστή ερωτημάτων είναι να καθορίσει ποια στρατηγική είναι η καλύτερη. Αξίζει να ληφθεί υπόψη ότι οι σχεδιαστές ερωτημάτων έχουν περιορισμένες μόνο δυνατότητες πρόβλεψης. Αυτό μπορεί να οδηγήσει σε κακές αποφάσεις. Τα DBA ή οι προγραμματιστές μπορούν να τα χρησιμοποιήσουν για τη διάγνωση και τη βελτίωση των ερωτημάτων με χαμηλή απόδοση. Οι νέες εκδόσεις του DBMS μπορούν να διαμορφώσουν προγράμματα σχεδιασμού ερωτημάτων και η αυτοδιάγνωση μπορεί να βοηθήσει κατά την ενημέρωση της βάσης δεδομένων, εάν η νέα έκδοση οδηγεί σε προβλήματα απόδοσης. Τα αργά αρχεία καταγραφής ερωτημάτων, οι αναφορές ζητημάτων καθυστέρησης ή τα στατιστικά του χρόνου εκτέλεσης μπορούν να βοηθήσουν στον εντοπισμό ερωτημάτων που χρειάζονται βελτιστοποίηση.
Ορισμένες μετρήσεις που παρουσιάζονται από τον προγραμματιστή ερωτημάτων ενδέχεται να υπόκεινται σε θόρυβο (ειδικά κατά την εκτίμηση του λανθάνοντος χρόνου ή του χρόνου CPU). Μια καλή προσθήκη στους προγραμματιστές είναι τα εργαλεία για τον εντοπισμό και την παρακολούθηση της διαδρομής εκτέλεσης. Σας επιτρέπουν να διαγνώσετε τέτοια προβλήματα (αλίμονο, δεν παρέχουν όλα τα DBMS τέτοια εργαλεία).
Η διαδικτυακή μετανάστευση είναι δύσκολη αλλά δυνατή
Η διαδικτυακή μετεγκατάσταση, η ζωντανή μετεγκατάσταση ή η μετεγκατάσταση σε πραγματικό χρόνο σημαίνει μετακίνηση από τη μια βάση δεδομένων στην άλλη χωρίς διακοπή λειτουργίας ή καταστροφή δεδομένων. Η ζωντανή μετεγκατάσταση είναι ευκολότερο να πραγματοποιηθεί εάν η μετάβαση πραγματοποιείται εντός του ίδιου DBMS/μηχανής. Η κατάσταση γίνεται πιο περίπλοκη όταν είναι απαραίτητο να μετακινηθείτε σε ένα νέο ΣΔΒΔ με διαφορετικές απαιτήσεις απόδοσης και σχήματος.
Υπάρχουν διαφορετικά μοντέλα διαδικτυακής μετεγκατάστασης. Εδώ είναι ένα από αυτά:
- Ενεργοποίηση διπλής καταχώρησης και στις δύο βάσεις δεδομένων. Η νέα βάση δεδομένων σε αυτό το στάδιο δεν έχει όλα τα δεδομένα, αλλά δέχεται μόνο τα πιο πρόσφατα δεδομένα. Αφού βεβαιωθείτε για αυτό, μπορείτε να προχωρήσετε στο επόμενο βήμα.
- Ενεργοποιήστε την ανάγνωση και από τις δύο βάσεις δεδομένων.
- Διαμορφώστε το σύστημα έτσι ώστε η ανάγνωση και η εγγραφή να εκτελούνται κυρίως στη νέα βάση δεδομένων.
- Σταματήστε να γράφετε στην παλιά βάση δεδομένων, ενώ συνεχίζετε να διαβάζετε δεδομένα από αυτήν. Σε αυτό το στάδιο, η νέα βάση δεδομένων εξακολουθεί να στερείται ορισμένων δεδομένων. Θα πρέπει να αντιγραφούν από την παλιά βάση δεδομένων.
- Η παλιά βάση δεδομένων είναι μόνο για ανάγνωση. Αντιγράψτε τα δεδομένα που λείπουν από την παλιά βάση δεδομένων στη νέα. Αφού ολοκληρωθεί η μετεγκατάσταση, αλλάξτε τις διαδρομές στη νέα βάση δεδομένων, σταματήστε την παλιά και διαγράψτε την από το σύστημα.
Για περισσότερες πληροφορίες, προτείνω να επικοινωνήσετε , το οποίο περιγράφει λεπτομερώς τη στρατηγική μετανάστευσης του Stripe που βασίζεται σε αυτό το μοντέλο.
Μια σημαντική αύξηση στη βάση δεδομένων συνεπάγεται αύξηση της μη προβλεψιμότητας
Η ανάπτυξη της βάσης δεδομένων οδηγεί σε απρόβλεπτα προβλήματα που σχετίζονται με την κλίμακα της. Όσο περισσότερα γνωρίζουμε για την εσωτερική δομή μιας βάσης δεδομένων, τόσο καλύτερα μπορούμε να προβλέψουμε πώς θα κλιμακωθεί. Ωστόσο, κάποιες στιγμές είναι ακόμα αδύνατο να προβλεφθούν.
Καθώς η βάση μεγαλώνει, οι προηγούμενες υποθέσεις και προσδοκίες σχετικά με τον όγκο δεδομένων και τις απαιτήσεις εύρους ζώνης δικτύου μπορεί να είναι ξεπερασμένες. Αυτό συμβαίνει όταν ανακύπτει το ερώτημα για σημαντικές αναθεωρήσεις σχεδιασμού, λειτουργικές βελτιώσεις μεγάλης κλίμακας, επανεξέταση των αναπτύξεων ή μετάβαση σε άλλα DBMS για την αποφυγή πιθανών προβλημάτων.
Μην νομίζετε όμως ότι η άριστη γνώση της εσωτερικής δομής της υπάρχουσας βάσης δεδομένων είναι το μόνο απαραίτητο. Οι νέες ζυγαριές θα φέρουν μαζί τους νέα άγνωστα. Τα απρόβλεπτα σημεία πόνου, η άνιση κατανομή δεδομένων, τα απροσδόκητα ζητήματα εύρους ζώνης και υλικού, η συνεχώς αυξανόμενη επισκεψιμότητα και τα νέα τμήματα δικτύου θα σας αναγκάσουν να αναθεωρήσετε την προσέγγιση της βάσης δεδομένων, το μοντέλο δεδομένων, το μοντέλο ανάπτυξης και το μέγεθος της βάσης δεδομένων.
...
Την εποχή που άρχισα να σκέφτομαι να δημοσιεύσω αυτό το άρθρο, υπήρχαν ήδη πέντε ακόμη στοιχεία στην αρχική μου λίστα. Μετά ήρθε ένας τεράστιος αριθμός για το τι άλλο μπορεί να καλυφθεί. Επομένως, το άρθρο αγγίζει τα λιγότερο προφανή προβλήματα που απαιτούν τη μέγιστη προσοχή. Ωστόσο, αυτό δεν σημαίνει ότι το θέμα έχει εξαντληθεί και δεν θα επανέλθω πλέον σε αυτό στα μελλοντικά μου υλικά και δεν θα κάνω αλλαγές στο τρέχον.
PS
Διαβάστε επίσης στο blog μας:
- «"?
- «"?
- «».
Πηγή: www.habr.com