Κάποια στιγμή στο μακρινό μέλλον, η αυτόματη διαγραφή περιττών δεδομένων θα είναι ένα από τα σημαντικά καθήκοντα ενός ΣΔΒΔ [1]. Στο μεταξύ, εμείς οι ίδιοι πρέπει να φροντίσουμε να διαγράψουμε ή να μετακινήσουμε περιττά δεδομένα σε λιγότερο ακριβά συστήματα αποθήκευσης. Ας υποθέσουμε ότι αποφασίσατε να διαγράψετε πολλά εκατομμύρια σειρές. Αρκετά απλή εργασία, ειδικά αν η κατάσταση είναι γνωστή και υπάρχει κατάλληλος δείκτης. "ΔΙΑΓΡΑΦΗ ΑΠΟ τον πίνακα1 ΟΠΟΥ col1 = :value" - τι θα μπορούσε να είναι πιο απλό, σωστά;
Βίντεο:
Είμαι στην επιτροπή προγράμματος Highload από τον πρώτο χρόνο, δηλαδή από το 2007.
Και είμαι με την Postgres από το 2005. Το χρησιμοποίησα σε πολλά έργα.
Η ομάδα με τη RuPostges υπάρχει επίσης από το 2007.
Έχουμε αυξηθεί σε 2100+ συμμετέχοντες στο Meetup. Είναι δεύτερη στον κόσμο μετά τη Νέα Υόρκη, έχοντας ξεπεράσει το Σαν Φρανσίσκο εδώ και πολύ καιρό.
Ζω στην Καλιφόρνια εδώ και αρκετά χρόνια. Συνεργάζομαι περισσότερο με αμερικανικές εταιρείες, συμπεριλαμβανομένων μεγάλων. Είναι ενεργοί χρήστες του Postgres. Και όλα τα ενδιαφέροντα πράγματα συμβαίνουν εκεί.
- Αυτή είναι η εταιρεία μου. Ασχολούμαστε με την αυτοματοποίηση εργασιών που εξαλείφουν την επιβράδυνση της ανάπτυξης.
Αν κάνετε κάτι, μερικές φορές συναντάτε κάποια συμφόρηση γύρω από την Postgres. Ας υποθέσουμε ότι πρέπει να περιμένετε έως ότου ο διαχειριστής δημιουργήσει μια δοκιμαστική βάση για εσάς ή πρέπει να περιμένετε έως ότου σας απαντήσει το DBA. Και βρίσκουμε τέτοια σημεία συμφόρησης στη διαδικασία ανάπτυξης, δοκιμών και διαχείρισης και προσπαθούμε να τα εξαλείψουμε με τη βοήθεια αυτοματισμών και νέων προσεγγίσεων.
Ήμουν πρόσφατα στο VLDB στο Λος Άντζελες. Αυτό είναι το μεγαλύτερο συνέδριο βάσης δεδομένων. Και υπήρχε μια αναφορά ότι στο μέλλον, τα DBMS όχι μόνο θα αποθηκεύουν, αλλά και θα διαγράφουν αυτόματα δεδομένα. Αυτό είναι ένα νέο θέμα.
Υπάρχουν όλο και περισσότερα δεδομένα στον κόσμο - τα zettabyte είναι 1 petabyte. Και τώρα υπολογίζεται ότι έχουμε περισσότερα από 000 zettabytes δεδομένων αποθηκευμένα στον κόσμο. Και είναι όλο και περισσότεροι από αυτούς.
Και τι να κάνετε για αυτό; Είναι σαφές ότι πρέπει να διαγραφεί. Εδώ είναι ένας σύνδεσμος προς αυτήν την ενδιαφέρουσα έκθεση. Αλλά αυτό δεν έχει ακόμη εφαρμοστεί στο DBMS.
Αυτοί που ξέρουν να μετράνε χρήματα θέλουν δύο πράγματα. Θέλουν να διαγράψουμε, οπότε τεχνικά θα πρέπει να μπορούμε να το κάνουμε.
Αυτό που θα σας πω στη συνέχεια είναι μια αφηρημένη κατάσταση που περιλαμβάνει ένα σωρό πραγματικές καταστάσεις, δηλαδή μια συλλογή του τι πραγματικά συνέβη σε εμένα και στις γύρω βάσεις δεδομένων πολλές φορές, πολλά χρόνια. Η τσουγκράνα είναι παντού και όλοι την πατούν συνέχεια.
Ας πούμε ότι έχουμε μια βάση ή πολλές βάσεις που αυξάνονται. Και μερικές από τις αναρτήσεις είναι απλά σκουπίδια. Για παράδειγμα, ένας χρήστης άρχισε να κάνει κάτι εκεί και δεν το ολοκλήρωσε. Και μετά από κάποιο χρονικό διάστημα γνωρίζουμε ότι αυτό το ημιτελές έργο δεν μπορεί πλέον να αποθηκευτεί. Δηλαδή, θα θέλαμε να καθαρίσουμε ορισμένα σκουπίδια για να εξοικονομήσουμε χώρο, να βελτιώσουμε την απόδοση κ.λπ.
Γενικά, το καθήκον είναι να αυτοματοποιηθεί η διαγραφή συγκεκριμένων πραγμάτων, συγκεκριμένων γραμμών σε κάποιον πίνακα.
Και έχουμε ένα τέτοιο αίτημα, για το οποίο θα μιλήσουμε σήμερα, δηλαδή για την απομάκρυνση των σκουπιδιών.
Ζητήσαμε από έναν έμπειρο προγραμματιστή να το κάνει αυτό. Πήρε αυτό το αίτημα, το έλεγξε μόνος του - όλα λειτουργούν. Δοκιμασμένο στη σκηνή - όλα είναι εντάξει. Το βγάλαμε και όλα λειτουργούν. Το λανσάρουμε μία φορά την ημέρα - όλα είναι καλά.
Η βάση δεδομένων μεγαλώνει και μεγαλώνει. Το Daily DELETE αρχίζει να λειτουργεί λίγο πιο αργά.
Τότε συνειδητοποιούμε ότι τώρα εκτελούμε μια καμπάνια μάρκετινγκ και η επισκεψιμότητα θα είναι αρκετές φορές μεγαλύτερη, οπότε αποφασίζουμε να βάλουμε προσωρινά τα επιπλέον πράγματα σε αναμονή. Και ξεχνάμε να το επιστρέψουμε.
Λίγους μήνες αργότερα θυμήθηκαν. Και αυτός ο προγραμματιστής εγκατέλειψε ή ήταν απασχολημένος με κάτι άλλο, και ανέθεσαν σε άλλον να το επιστρέψει.
Έλεγξε στον προγραμματισμό, στη σκηνή - όλα είναι εντάξει. Φυσικά, πρέπει ακόμα να καθαρίσετε ό,τι έχει συσσωρευτεί. Έλεγξε, όλα λειτουργούν.
Τι γίνεται μετά; Τότε όλα καταρρέουν για εμάς. Πέφτει ώστε κάποια στιγμή να μας γκρεμίσουν όλα. Όλοι είναι σοκαρισμένοι, κανείς δεν καταλαβαίνει τι συμβαίνει. Και μετά αποδεικνύεται ότι το πρόβλημα ήταν αυτή η ΔΙΑΓΡΑΦΗ.
Τι πήγε στραβά; Εδώ είναι μια λίστα με πράγματα που μπορεί να πάνε στραβά. Ποιο είναι το πιο σημαντικό από αυτό;
Για παράδειγμα, δεν έγινε κριτική, δηλαδή ο ειδικός του DBA δεν κοίταξε. Θα έβρισκε αμέσως το πρόβλημα με το έμπειρο μάτι του και, επιπλέον, έχει πρόσβαση στο prod, όπου έχουν συσσωρευτεί αρκετά εκατομμύρια γραμμές.
Ίσως το έλεγξαν λανθασμένα με κάποιο τρόπο.
Ίσως το υλικό είναι ξεπερασμένο και χρειάζεται αναβάθμιση για αυτήν τη βάση δεδομένων.
Ή κάτι δεν πάει καλά με την ίδια τη βάση δεδομένων και πρέπει να περάσουμε από το Postgres στη MySQL.
Ή ίσως κάτι δεν πάει καλά με την επέμβαση.
Μήπως υπάρχουν κάποια λάθη στην οργάνωση της εργασίας και χρειάζεται να απολυθεί κάποιος και να προσληφθούν καλύτερα άτομα;
Δεν έγινε έλεγχος DBA. Αν υπήρχε DBA, θα έβλεπε αυτά τα πολλά εκατομμύρια γραμμές και, ακόμη και χωρίς πειράματα, θα έλεγε: «Δεν γίνεται έτσι». Ας πούμε ότι εάν αυτός ο κώδικας ήταν στο GitLab, στο GitHub και υπήρχε μια διαδικασία αναθεώρησης κώδικα και δεν ήταν ότι αυτή η λειτουργία θα πήγαινε στην παραγωγή χωρίς έγκριση DBA, τότε προφανώς το DBA θα έλεγε: "Δεν μπορείτε να το κάνετε αυτό."
Και θα έλεγε ότι θα έχετε προβλήματα με την IO του δίσκου και όλες οι διαδικασίες θα τρελαθούν, μπορεί να υπάρχουν κλειδαριές, και επίσης θα μπλοκάρετε το autovacuum για πολλά λεπτά, οπότε αυτό δεν είναι καλό.
Το δεύτερο λάθος είναι ότι έκαναν έλεγχο σε λάθος μέρος. Είδαμε μετά το γεγονός ότι πολλά δεδομένα σκουπιδιών είχαν συσσωρευτεί κατά την παραγωγή, αλλά ο προγραμματιστής δεν είχε συσσωρευμένα δεδομένα σε αυτήν τη βάση δεδομένων και κανείς δεν δημιούργησε πραγματικά αυτά τα σκουπίδια στη σκηνή. Αντίστοιχα, υπήρχαν 1 γραμμές που επιλύθηκαν γρήγορα.
Καταλαβαίνουμε ότι τα τεστ μας είναι αδύναμα, δηλαδή η διαδικασία που χτίζεται δεν πιάνει προβλήματα. Δεν διεξήγαγαν ένα κατάλληλο πείραμα BD.
Το ιδανικό πείραμα κατά προτίμηση θα διεξαγόταν στον ίδιο εξοπλισμό. Δεν είναι πάντα δυνατό να γίνει αυτό στον ίδιο εξοπλισμό, αλλά είναι πολύ σημαντικό να είναι ένα αντίγραφο πλήρους μεγέθους της βάσης δεδομένων. Αυτό κηρύττω εδώ και αρκετά χρόνια. Και πριν από ένα χρόνο μίλησα για αυτό, μπορείτε να τα παρακολουθήσετε όλα στο YouTube.
Ίσως ο εξοπλισμός μας είναι κακός; Αν κοιτάξετε, η καθυστέρηση έχει αυξηθεί. Είδαμε ότι το ποσοστό ανακύκλωσης ήταν 100%. Φυσικά, αν αυτοί ήταν σύγχρονοι δίσκοι NVMe, τότε μάλλον θα ήταν πολύ πιο εύκολο για εμάς. Και ίσως να μην είχαμε πάει για ύπνο εξαιτίας αυτού.
Αν έχετε cloud, τότε η αναβάθμιση είναι εύκολη. Δημιουργήθηκαν νέα αντίγραφα σε νέο υλικό. Μετάβαση. Και όλα είναι καλά. Αρκετά εύκολο.
Υπάρχει τρόπος να αγγίξω λιγότερο τους δίσκους; Και εδώ, με τη βοήθεια του DBA, βυθιζόμαστε σε ένα θέμα που ονομάζεται συντονισμός σημείων ελέγχου. Αποδεικνύεται ότι δεν πραγματοποιήσαμε συντονισμό σημείων ελέγχου.
Τι είναι ένα σημείο ελέγχου; Αυτό είναι σε οποιοδήποτε DBMS. Όταν έχετε δεδομένα στη μνήμη που αλλάζουν, δεν εγγράφονται αμέσως στο δίσκο. Οι πληροφορίες ότι τα δεδομένα έχουν αλλάξει γράφονται πρώτα στο αρχείο καταγραφής προκαταβολής εγγραφής. Και κάποια στιγμή το DBMS αποφασίζει ότι είναι ώρα να ξεπλύνει τις πραγματικές σελίδες στο δίσκο, έτσι ώστε, αν έχουμε αποτυχία, να πρέπει να κάνουμε λιγότερες REDO. Είναι σαν παιχνίδι. Αν σκοτωθούμε, θα ξεκινήσουμε το παιχνίδι από το τελευταίο σημείο ελέγχου. Και όλα τα DBMS το εφαρμόζουν αυτό.
Οι ρυθμίσεις Postgres καθυστερούν. Έχουν σχεδιαστεί για όγκους δεδομένων και λειτουργιών ηλικίας 10-15 ετών. Και το σημείο ελέγχου δεν αποτελεί εξαίρεση.
Ακολουθούν οι πληροφορίες από την αναφορά ελέγχου Postgres, δηλαδή τον αυτόματο έλεγχο υγείας. Και εδώ είναι μια βάση δεδομένων πολλών terabyte. Και είναι ξεκάθαρα ορατό ότι τα αναγκαστικά σημεία ελέγχου συμβαίνουν σχεδόν στο 90% των περιπτώσεων.
Τι σημαίνει αυτό; Υπάρχουν δύο ρυθμίσεις εκεί. Το σημείο ελέγχου μπορεί να συμβεί μετά από ένα χρονικό όριο, για παράδειγμα, σε 10 λεπτά. Ή μπορεί να συμβεί όταν έχουν συμπληρωθεί αρκετά δεδομένα.
Και από προεπιλογή, το max_wal_saze έχει οριστεί σε 1 gigabyte. Στην πραγματικότητα, αυτό συμβαίνει στην Postgres μετά από 300-400 megabyte. Αλλάξατε τόσα πολλά δεδομένα και έχετε ένα σημείο ελέγχου.
Και αν κανείς δεν το συντόνισε και η υπηρεσία μεγάλωσε και η εταιρεία βγάζει πολλά χρήματα, έχει πολλές συναλλαγές, τότε το σημείο ελέγχου εμφανίζεται μία φορά το λεπτό, μερικές φορές μία φορά κάθε 30 δευτερόλεπτα και μερικές φορές ακόμη και επικαλύπτονται. Αυτό είναι πραγματικά κακό.
Και πρέπει να το κάνουμε να συμβαίνει λιγότερο συχνά. Δηλαδή, μπορούμε να αυξήσουμε το max_wal_size. Και θα εμφανίζεται λιγότερο συχνά.
Αλλά έχουμε αναπτύξει μια ολόκληρη μεθοδολογία για το πώς να το κάνουμε αυτό πιο σωστά, δηλαδή πώς να λαμβάνουμε αποφάσεις σχετικά με την επιλογή ρυθμίσεων, βασιζόμενοι σαφώς σε συγκεκριμένα δεδομένα.
Αντίστοιχα, διεξάγουμε δύο σειρές πειραμάτων σε βάσεις δεδομένων.
Πρώτη σειρά – αλλάζουμε max_wal_size. Και κάνουμε μαζική επιχείρηση. Πρώτα, το κάνουμε στην προεπιλεγμένη ρύθμιση του 1 gigabyte. Και κάνουμε μια μαζική ΔΙΑΓΡΑΦΗ πολλών εκατομμυρίων γραμμών.
Μπορείτε να δείτε πόσο δύσκολο είναι για εμάς. Βλέπουμε ότι η IO του δίσκου είναι πολύ κακή. Ας δούμε πόσα WAL δημιουργήσαμε, γιατί αυτό είναι πολύ σημαντικό. Ας δούμε πόσες φορές εμφανίστηκε το σημείο ελέγχου. Και βλέπουμε ότι δεν είναι καλό.
Στη συνέχεια αυξάνουμε το max_wal_size. Ας επαναλάβουμε. Αυξάνουμε, επαναλαμβάνουμε. Και τόσες φορές. Κατ 'αρχήν, 10 σημεία είναι καλά, όπου 1, 2, 4, 8 gigabyte. Και εξετάζουμε τη συμπεριφορά ενός συγκεκριμένου συστήματος. Είναι σαφές ότι ο εξοπλισμός εδώ θα πρέπει να είναι ο ίδιος όπως στο prod. Θα πρέπει να έχετε τους ίδιους δίσκους, την ίδια ποσότητα μνήμης και τις ίδιες ρυθμίσεις Postgres.
Και έτσι θα ανταλλάξουμε το σύστημά μας, και ξέρουμε πώς θα συμπεριφερθεί το DBMS με ένα κακό μαζικό DELETE, πώς θα είναι το σημείο ελέγχου.
Σημείο ελέγχου στα ρωσικά σημαίνει σημεία ελέγχου.
Παράδειγμα: ΔΙΑΓΡΑΦΗ πολλών εκατομμυρίων σειρών ανά ευρετήριο, οι σειρές είναι "σκόρπιες" στις σελίδες.
Εδώ είναι ένα παράδειγμα. Αυτό είναι κάποια βάση. Και με την προεπιλεγμένη ρύθμιση του 1 gigabyte για max_wal_size, είναι πολύ ξεκάθαρο ότι οι δίσκοι μας για εγγραφή πηγαίνουν στο ράφι. Αυτή είναι μια εικόνα - αυτό είναι ένα τυπικό σύμπτωμα ενός πολύ άρρωστου ασθενούς, δηλαδή ένιωθε πραγματικά άσχημα. Και εδώ υπήρχε μια μεμονωμένη λειτουργία, εδώ υπήρχε μόνο μια ΔΙΑΓΡΑΦΗ πολλών εκατομμυρίων γραμμών.
Αν κάνουμε μια τέτοια επιχείρηση στο prod, τότε θα είμαστε αυτοί που θα κατέβουμε, γιατί είναι ξεκάθαρο ότι μια ΔΙΑΓΡΑΦΗ μας σκοτώνει στο σύνταγμα.
Περαιτέρω, όπου υπάρχουν 16 gigabyte, μπορείτε να δείτε ότι τα δόντια έχουν ήδη αρχίσει να εμφανίζονται. Τα δόντια είναι ήδη καλύτερα, δηλαδή χτυπάμε ταβάνι, αλλά όχι τόσο άσχημα. Λίγη ελευθερία εμφανίστηκε εκεί. Δεξιά είναι η ηχογράφηση. Και ο αριθμός των πράξεων είναι το δεύτερο γράφημα. Και είναι σαφές ότι μπορούμε να αναπνεύσουμε λίγο πιο εύκολα τώρα που υπάρχουν 16 gigabyte.
Και όπου υπάρχουν 64 gigabyte, μπορείτε να δείτε ότι έχει γίνει πολύ καλύτερο. Τα δόντια είναι ήδη καθαρά ορατά, υπάρχουν περισσότερες ευκαιρίες να επιβιώσετε από άλλες επεμβάσεις και να κάνετε κάτι με το δίσκο.
Γιατί έτσι;
Θα βουτήξω σε μια μικρή λεπτομέρεια, αλλά αυτό το θέμα του πώς να διεξάγετε τον συντονισμό σημείων ελέγχου θα μπορούσε να μετατραπεί σε μια ολόκληρη αναφορά, επομένως δεν θα σας επιβαρύνω πολύ, αλλά θα περιγράψω εν συντομία ποιες δυσκολίες υπάρχουν.
Εάν το σημείο ελέγχου συμβαίνει πολύ συχνά και ενημερώνουμε τις γραμμές μας όχι διαδοχικά, αλλά τις βρίσκουμε με ευρετήριο, κάτι που είναι καλό γιατί δεν διαγράφουμε ολόκληρο τον πίνακα, τότε μπορεί να συμβεί να αγγίξουμε πρώτα την πρώτη σελίδα, μετά τη χιλιοστή και μετά να επιστρέψουμε στην πρώτη. Και αν ανάμεσα σε αυτές τις επισκέψεις στην πρώτη σελίδα, το checkpoint το έχει ήδη αποθηκεύσει στο δίσκο, τότε θα το αποθηκεύσει ξανά, γιατί το έχουμε λερώσει για δεύτερη φορά.
Και θα αναγκάσουμε το σημείο ελέγχου να το σώσει πολλές φορές. Φαίνεται ότι υπάρχουν περιττές επεμβάσεις για αυτόν.
Αλλά αυτό δεν είναι όλο. Στο Postgres, οι σελίδες ζυγίζουν 8 kilobyte, και στο Linux 4 κιλομπάιτ. Και υπάρχει η ρύθμιση full_page_writes. Είναι ενεργοποιημένη από προεπιλογή. Και αυτό είναι καλό, γιατί αν την απενεργοποιήσουμε, υπάρχει κίνδυνος σε περίπτωση σφάλματος, να αποθηκευτεί μόνο η μισή σελίδα.
Η συμπεριφορά της εγγραφής στο WAL του καταγραφής μπροστά είναι τέτοια που όταν έχουμε ένα σημείο ελέγχου και αλλάζουμε μια σελίδα για πρώτη φορά, ολόκληρη η σελίδα, δηλαδή και τα 8 kilobyte, μπαίνει στο αρχείο καταγραφής μπροστά, αν και αλλάξαμε μόνο μια γραμμή που ζυγίζει 100 byte. Και αναγκαζόμαστε να γράψουμε ολόκληρη τη σελίδα.
Σε επόμενες αλλαγές θα υπάρχει μόνο μια συγκεκριμένη πλειάδα, αλλά για πρώτη φορά θα γράψουμε τα πάντα.
Και, κατά συνέπεια, εάν το σημείο ελέγχου συμβεί ξανά, τότε πρέπει να ξεκινήσουμε τα πάντα από την αρχή και να γεμίσουμε ολόκληρη τη σελίδα. Με συχνά σημεία ελέγχου, όταν περπατάμε στις ίδιες σελίδες, το full_page_writes = on θα είναι μεγαλύτερο από ό,τι θα μπορούσε να είναι, δηλαδή δημιουργούμε περισσότερα WAL. Περισσότερα αποστέλλονται σε αντίγραφα, στο αρχείο, στο δίσκο.
Και, κατά συνέπεια, έχουμε δύο απολύσεις.
Αν αυξήσουμε το max_wal_size, αποδεικνύεται ότι διευκολύνουμε τη δουλειά τόσο του checkpoint όσο και του wal writer. Και αυτό είναι ωραίο.
Ας βάλουμε ένα terabyte και ας ζήσουμε με αυτό. Τι συμβαίνει με αυτό; Αυτό είναι κακό γιατί αν υπάρξει αστοχία θα σκαρφαλώνουμε για ώρες, γιατί το σημείο ελέγχου ήταν πολύ καιρό πριν και πολλά έχουν ήδη αλλάξει. Και πρέπει να κάνουμε REDO για όλα αυτά. Και έτσι κάνουμε μια δεύτερη σειρά πειραμάτων.
Κάνουμε την επέμβαση και βλέπουμε όταν το σημείο ελέγχου είναι κοντά στην ολοκλήρωση, σκοτώνουμε -9 Postgres συγκεκριμένα.
Και μετά το ξεκινάμε ξανά και βλέπουμε πόσο καιρό θα χρειαστεί να ανέβει σε αυτόν τον εξοπλισμό, δηλαδή πόσο REDO θα κάνει σε αυτήν την κακή κατάσταση.
Θα ελέγξω ξανά ότι η κατάσταση είναι κακή. Πρώτον, πέσαμε λίγο πριν το τέλος του σημείου ελέγχου, οπότε έχουμε πολλά να χάσουμε. Και δεύτερον, είχαμε μια μαζική επέμβαση. Και αν τα σημεία ελέγχου είχαν λήξει, τότε πιθανότατα θα είχαν δημιουργηθεί λιγότερα WAL από το τελευταίο σημείο ελέγχου. Δηλαδή είναι διπλός χαμένος.
Μετράμε αυτήν την κατάσταση για διαφορετικά μεγέθη max_wal_size και καταλαβαίνουμε ότι αν το max_wal_size είναι 64 gigabyte, τότε σε δύο φορές χειρότερη κατάσταση θα σηκωθούμε για 10 λεπτά. Και σκεφτόμαστε αν είμαστε ευχαριστημένοι με αυτό ή όχι. Αυτή είναι μια επιχειρηματική ερώτηση. Πρέπει να δείξουμε αυτή την εικόνα σε εκείνους που είναι υπεύθυνοι για τις επιχειρηματικές αποφάσεις και να ρωτήσουμε: «Πόσο καιρό μπορούμε να περιμένουμε το μέγιστο εάν υπάρχει πρόβλημα; Μπορούμε να ξαπλώσουμε στη χειρότερη κατάσταση για 3-5 λεπτά; Και εσείς αποφασίζετε.
Και εδώ είναι ένα ενδιαφέρον σημείο. Έχουμε μερικές παρουσιάσεις για τον Πατρώνη στο συνέδριό μας. Και ίσως το χρησιμοποιήσετε. Αυτό είναι το autofailover για την Postgres. Το GitLab και το Data Egret μίλησαν για αυτό.
Και αν έχετε ένα autofailover που θα συμβεί σε 30 δευτερόλεπτα, τότε ίσως μπορούμε να ξαπλώσουμε εκεί για 10 λεπτά; Γιατί μέχρι εκείνο το σημείο θα είμαστε έτοιμοι και όλα θα πάνε καλά. Αυτό είναι ένα αμφιλεγόμενο ζήτημα. Δεν ξέρω τη σαφή απάντηση. Απλώς αισθάνομαι ότι αυτό δεν είναι μόνο ένα θέμα γύρω από την αποκατάσταση από καταστροφές.
Εάν έχουμε μεγάλο χρόνο αποκατάστασης μετά από μια αποτυχία, τότε θα ταλαιπωρηθούμε σε πολλές άλλες καταστάσεις. Για παράδειγμα, στα ίδια πειράματα, όταν κάνουμε κάτι και μερικές φορές αναγκαζόμαστε να περιμένουμε για 10 λεπτά.
Ακόμα δεν θα πήγαινα πολύ μακριά, ακόμα κι αν έχουμε autofailover. Γενικά, τιμές όπως τα 64, 100 gigabyte είναι καλές τιμές. Μερικές φορές αξίζει ακόμη και να επιλέξετε λιγότερα. Γενικά, είναι μια λεπτή επιστήμη.
Για να κάνετε επαναλήψεις, για παράδειγμα, max_wal_size = 1, 8, πρέπει να επαναλάβετε τη μαζική λειτουργία πολλές φορές. Το έκανες. Και θέλετε να το κάνετε ξανά στην ίδια βάση, αλλά έχετε ήδη διαγράψει τα πάντα. Τι να κάνουμε;
Θα μιλήσω για τη λύση μας αργότερα, τι κάνουμε για να επαναλάβουμε σε τέτοιες καταστάσεις. Και αυτή είναι η πιο σωστή προσέγγιση.
Αλλά σε αυτή την περίπτωση ήμασταν τυχεροί. Εάν, όπως γράφεται εδώ, "START, DELETE, ROLLBACK", τότε μπορούμε να επαναλάβουμε το DELETE. Δηλαδή, αν το ακυρώσαμε μόνοι μας, τότε μπορούμε να το επαναλάβουμε. Και φυσικά τα δεδομένα σας θα βρίσκονται εκεί. Δεν παθαίνεις καν φούσκωμα. Μπορείτε να επαναλάβετε σε τέτοια DELETE.
Αυτό το DELETE with ROLLBACK είναι ιδανικό για συντονισμό σημείων ελέγχου, ακόμα κι αν δεν έχετε σωστά αναπτυγμένα εργαστήρια βάσης δεδομένων.
Φτιάξαμε μια ταμπέλα με μια στήλη "i". Η Postgres έχει στήλες υπηρεσιών. Είναι αόρατα εκτός και αν τους ζητηθεί συγκεκριμένα. Αυτά είναι: ctid, xmid, xmax.
Το Ctid είναι μια φυσική διεύθυνση. Σελίδα μηδέν, η πρώτη πλειάδα στη σελίδα.
Είναι σαφές ότι μετά το ROOLBACK η πλειάδα παρέμεινε στην ίδια θέση. Δηλαδή, μπορούμε να προσπαθήσουμε ξανά, θα συμπεριφερθεί με τον ίδιο τρόπο. Αυτό είναι το κύριο πράγμα.
Το Xmax είναι ο χρόνος θανάτου της πλειάδας. Ορίστηκε, αλλά η Postgres γνωρίζει ότι αυτή η συναλλαγή επαναφέρθηκε, επομένως δεν έχει σημασία αν είναι 0 ή επαναφορά συναλλαγής. Αυτό υποδηλώνει ότι το DELETE μπορεί να χρησιμοποιηθεί για την επανάληψη και τον έλεγχο της μαζικής συμπεριφοράς του συστήματος. Είναι δυνατό να δημιουργηθούν εργαστήρια βάσεων δεδομένων για τους φτωχούς.
Αυτό είναι ήδη για προγραμματιστές. Σχετικά με το DBA, επίσης, επιπλήττουν πάντα τους προγραμματιστές για αυτό: "Γιατί κάνετε τόσο μεγάλες και δύσκολες λειτουργίες;" Αυτό είναι ένα τελείως διαφορετικό κάθετο θέμα. Παλαιότερα υπήρχε διοίκηση, αλλά τώρα θα υπάρξει ανάπτυξη.
Προφανώς δεν το σπάσαμε σε κομμάτια. Αυτό είναι κατανοητό. Είναι αδύνατο να ΔΙΑΓΡΑΨΕΙΣ κάτι τέτοιο για ένα σωρό εκατομμύρια γραμμές χωρίς να το σπάσεις σε μέρη. Θα χρειαστούν 20 λεπτά για να γίνει και όλα θα ρυθμιστούν. Αλλά, δυστυχώς, ακόμη και έμπειροι προγραμματιστές κάνουν λάθη, ακόμη και σε πολύ μεγάλες εταιρείες.
Γιατί είναι σημαντικό να σπάσει;
Αν δούμε ότι ο δίσκος δυσκολεύεται, τότε ας τον επιβραδύνουμε. Και αν έχουμε βλάβη, τότε μπορούμε να προσθέσουμε παύσεις, μπορούμε να επιβραδύνουμε το γκάζι.
Και δεν θα μπλοκάρουμε άλλους για πολύ. Σε ορισμένες περιπτώσεις, δεν έχει σημασία, εάν διαγράφετε πραγματικά σκουπίδια που κανείς δεν εργάζεται, τότε πιθανότατα δεν πρόκειται να αποκλείσετε κανέναν εκτός από το autovacuum επειδή θα περιμένει να ολοκληρωθεί η συναλλαγή. Αλλά αν διαγράψετε κάτι που μπορεί να ζητήσει κάποιος άλλος, θα αποκλειστεί και θα ξεκινήσει κάποιο είδος αλυσιδωτής αντίδρασης. Οι πολύωρες συναλλαγές θα πρέπει να αποφεύγονται σε ιστότοπους και εφαρμογές για κινητά.
Αυτό είναι ενδιαφέρον. Βλέπω συχνά προγραμματιστές να ρωτούν: "Τι μέγεθος συσκευασίας να επιλέξω;"
Είναι σαφές ότι όσο μεγαλύτερο είναι το μέγεθος της παρτίδας, τόσο μικρότερο είναι το γενικό κόστος συναλλαγής, δηλαδή πρόσθετα γενικά έξοδα από τις συναλλαγές. Ταυτόχρονα όμως αυξάνεται και ο χρόνος για αυτή τη συναλλαγή.
Έχω έναν πολύ απλό κανόνα: πάρτε όσες περισσότερες μπορείτε, αλλά μην υπερβαίνετε την εκτέλεση ανά δευτερόλεπτο.
Γιατί ένα δευτερόλεπτο; Η εξήγηση είναι πολύ απλή και κατανοητή σε όλους, ακόμα και σε μη τεχνικούς ανθρώπους. Βλέπουμε την αντίδραση. Ας πάρουμε 50 χιλιοστά του δευτερολέπτου. Αν κάτι έχει αλλάξει, τα μάτια μας θα αντιδράσουν. Αν είναι λιγότερο, είναι πιο δύσκολο. Αν κάτι ανταποκριθεί μετά από 100 χιλιοστά του δευτερολέπτου, για παράδειγμα, κάνατε κλικ με το ποντίκι και σας απάντησε μετά από 100 χιλιοστά του δευτερολέπτου, αισθάνεστε ήδη αυτή τη μικρή καθυστέρηση. Ένα δεύτερο εκλαμβάνεται ήδη ως φρένο.
Αντίστοιχα, αν σπάσουμε τις μαζικές μας επιχειρήσεις σε εκρήξεις 10 δευτερολέπτων, τότε διατρέχουμε τον κίνδυνο να μπλοκάρουμε κάποιον. Και θα λειτουργήσει για λίγα δευτερόλεπτα και οι άνθρωποι θα το παρατηρήσουν. Γι' αυτό προτιμώ να μην κάνω περισσότερο από ένα δευτερόλεπτο. Ταυτόχρονα, όμως, μην το αναλύσετε πολύ λεπτά, γιατί τα γενικά έξοδα συναλλαγής θα είναι αισθητά. Η βάση θα δυσκολευτεί περισσότερο και μπορεί να προκύψουν άλλα διαφορετικά προβλήματα.
Επιλέγουμε το μέγεθος της συσκευασίας. Σε κάθε περίπτωση μπορούμε να το κάνουμε διαφορετικά. Μπορεί να αυτοματοποιηθεί. Και είμαστε πεπεισμένοι για την αποτελεσματικότητα της επεξεργασίας ενός πακέτου. Δηλαδή, κάνουμε ΔΙΑΓΡΑΦΗ μιας παρτίδας ή ΕΝΗΜΕΡΩΣΗ.
Παρεμπιπτόντως, όλα αυτά για τα οποία μιλάω δεν αφορούν μόνο τη ΔΙΑΓΡΑΦΗ. Όπως ίσως μαντέψατε, αυτές είναι οποιεσδήποτε μαζικές λειτουργίες σε δεδομένα.
Και βλέπουμε ότι το σχέδιο είναι εξαιρετικό. Μπορείτε να δείτε σάρωση ευρετηρίου, ακόμα καλύτερα σάρωση μόνο ευρετηρίου. Και έχουμε έναν μικρό όγκο δεδομένων. Και όλα λειτουργούν σε λιγότερο από ένα δευτερόλεπτο. Σούπερ.
Και πρέπει ακόμα να βεβαιωθούμε ότι δεν υπάρχει υποβάθμιση. Συμβαίνει ότι οι πρώτες συσκευασίες σβήνονται γρήγορα και μετά γίνεται όλο και χειρότερο και χειρότερο. Η διαδικασία είναι τέτοια που απαιτούνται πολλές δοκιμές. Αυτό ακριβώς εξυπηρετούν τα εργαστήρια βάσεων δεδομένων.
Και πρέπει ακόμα να προετοιμάσουμε κάτι ώστε να μας επιτρέψει να το παρακολουθούμε σωστά στην παραγωγή. Για παράδειγμα, μπορούμε να γράψουμε την ώρα στο αρχείο καταγραφής, μπορούμε να γράψουμε πού βρισκόμαστε τώρα και ποιους μόλις διαγράψαμε. Και αυτό θα μας επιτρέψει να καταλάβουμε αργότερα τι συμβαίνει. Και αν κάτι πάει στραβά, βρείτε γρήγορα το πρόβλημα.
Εάν πρέπει να ελέγξουμε την αποτελεσματικότητα των ερωτημάτων και πρέπει να επαναλάβουμε πολλές φορές, τότε υπάρχει ένα τέτοιο πράγμα όπως το comrade bot. Είναι ήδη έτοιμο. Χρησιμοποιείται από δεκάδες προγραμματιστές καθημερινά. Και μπορεί να παρέχει μια τεράστια βάση δεδομένων terabyte κατόπιν αιτήματος σε 30 δευτερόλεπτα, το δικό σας αντίγραφο. Και μπορείτε να διαγράψετε κάτι εκεί και να πείτε RESET, και να το διαγράψετε ξανά. Μπορείτε να πειραματιστείτε με αυτόν τον τρόπο. Βλέπω μέλλον σε αυτό το πράγμα. Και το κάνουμε ήδη αυτό.
Ποιες είναι οι στρατηγικές κατάτμησης; Βλέπω 3 διαφορετικές στρατηγικές κατάτμησης που χρησιμοποιούνται από προγραμματιστές στο πακέτο.
Το πρώτο είναι πολύ απλό. Έχουμε ένα αριθμητικό αναγνωριστικό. Και ας το αναλύσουμε σε διαφορετικά διαστήματα και ας δουλέψουμε με αυτό. Το μειονέκτημα είναι ξεκάθαρο. Στο πρώτο τμήμα, μπορεί να έχουμε 100 γραμμές πραγματικών σκουπιδιών, στο δεύτερο, 5 γραμμές ή καθόλου, ή και οι 1 γραμμές θα αποδειχθούν σκουπίδια. Πολύ άνιση δουλειά, αλλά εύκολο να χωριστεί. Πήραμε τη μέγιστη ταυτότητα και τη χωρίσαμε. Αυτή είναι μια αφελής προσέγγιση.
Η δεύτερη στρατηγική είναι μια ισορροπημένη προσέγγιση. Χρησιμοποιείται στο Gitlab. Πήραμε και σαρώσαμε το τραπέζι. Βρήκαμε τα όρια των πακέτων ID έτσι ώστε κάθε πακέτο να περιέχει ακριβώς 10 εγγραφές. Και με έσπρωξαν σε κάποια ουρά. Και συνεχίζουμε την επεξεργασία. Αυτό μπορεί να γίνει σε πολλά νήματα.
Στην πρώτη στρατηγική, παρεμπιπτόντως, μπορείτε επίσης να το κάνετε αυτό σε πολλά νήματα. Δεν είναι δύσκολο.
Αλλά υπάρχει μια πιο δροσερή και βέλτιστη προσέγγιση. Αυτή είναι η τρίτη στρατηγική. Και όταν είναι δυνατόν, είναι καλύτερα να το επιλέξετε. Αυτό το κάνουμε με βάση ένα ειδικό ευρετήριο. Σε αυτή την περίπτωση, πιθανότατα θα είναι ένας δείκτης σύμφωνα με την κατάσταση των σκουπιδιών και την ταυτότητά μας. Θα συμπεριλάβουμε το αναγνωριστικό έτσι ώστε να είναι μόνο σάρωση ευρετηρίου, ώστε να μην πάμε στο σωρό.
Γενικά, η σάρωση μόνο ευρετηρίου είναι ταχύτερη από τη σάρωση ευρετηρίου.
Και βρίσκουμε γρήγορα τα αναγνωριστικά μας που θέλουμε να διαγράψουμε. Επιλέγουμε BATCH_SIZE εκ των προτέρων. Και όχι μόνο τα παραλαμβάνουμε, τα παραλαμβάνουμε με ιδιαίτερο τρόπο και τα κλειδώνουμε αμέσως. Αλλά κλειδώνουμε με τέτοιο τρόπο ώστε αν είναι ήδη κλειδωμένα, να μην τα κλειδώνουμε, αλλά να προχωρήσουμε και να πάρουμε τα επόμενα. Αυτό είναι για την παράλειψη ενημέρωσης κλειδωμένη. Αυτή η σούπερ δυνατότητα της Postgres μας επιτρέπει να δουλεύουμε σε πολλά νήματα αν θέλουμε. Είναι δυνατό σε ένα ρεύμα. Και εδώ υπάρχει CTE - αυτό είναι ένα ερώτημα. Και έχουμε πραγματική αφαίρεση στον δεύτερο όροφο αυτού του CTE – returning *. Η επιστροφή του αναγνωριστικού είναι δυνατή, αλλά είναι καλύτερη *, εάν έχετε λίγα δεδομένα σε κάθε γραμμή.
Γιατί το χρειαζόμαστε αυτό; Χρειαζόμαστε αυτό για να αναφέρουμε. Έχουμε πλέον διαγράψει τόσες πολλές γραμμές στην πραγματικότητα. Και έχουμε όρια με αναγνωριστικό ή από create_at όπως αυτό. Μπορείτε να κάνετε min, max. Υπάρχει και κάτι άλλο που μπορεί να γίνει. Μπορείτε να χωρέσετε πολλά πράγματα εδώ μέσα. Και αυτό είναι πολύ βολικό για παρακολούθηση.
Υπάρχει μια ακόμη παρατήρηση σχετικά με τον δείκτη. Εάν αποφασίσουμε ότι χρειαζόμαστε ένα ειδικό ευρετήριο για τη συγκεκριμένη εργασία, πρέπει να βεβαιωθούμε ότι δεν χαλάει τις ενημερώσεις πλειάδων μόνο. Δηλαδή η Postgres έχει τέτοια στατιστικά. Μπορείτε να το δείτε στο pg_stat_user_tables για τον πίνακά σας. Μπορείτε να δείτε εάν χρησιμοποιούνται hot ενημερώσεις ή όχι.
Υπάρχουν περιπτώσεις όπου ο νέος σας δείκτης μπορεί απλά να τους κόψει. Και όλες οι άλλες ενημερώσεις που εκτελούνται ήδη θα επιβραδυνθούν. Όχι μόνο επειδή εμφανίστηκε το ευρετήριο (κάθε ευρετήριο επιβραδύνει τις ενημερώσεις λίγο, αλλά λίγο), αλλά εδώ θα το χαλάσει επίσης. Και είναι αδύνατο να γίνει ειδική βελτιστοποίηση για αυτόν τον πίνακα. Αυτό συμβαίνει μερικές φορές. Αυτή είναι μια τέτοια λεπτότητα που λίγοι άνθρωποι θυμούνται. Και είναι εύκολο να πατήσεις αυτή τη γκανιότα. Μερικές φορές συμβαίνει ότι πρέπει να βρείτε μια προσέγγιση από διαφορετική οπτική γωνία και να συνεχίσετε να κάνετε χωρίς αυτό το νέο ευρετήριο, ή να δημιουργήσετε άλλο ευρετήριο ή με κάποιο άλλο τρόπο, για παράδειγμα, μπορείτε να χρησιμοποιήσετε τη δεύτερη μέθοδο.
Αλλά αυτή είναι η πιο βέλτιστη στρατηγική, πώς να χωριστείτε σε παρτίδες και να πυροβολήσετε τα πακέτα με ένα αίτημα, να διαγράψετε σιγά σιγά κ.λπ.
Μακροχρόνιες συναλλαγές -
Μπλοκαρισμένη αυτόματη ηλεκτρική σκούπα —
Πρόβλημα αποκλεισμού —
Το λάθος #5 είναι μεγάλο. Ο Nikolay από το Okmeter μίλησε για την παρακολούθηση Postgres. Δυστυχώς, δεν υπάρχει ιδανική παρακολούθηση Postgres. Άλλα είναι πιο κοντά, άλλα είναι πιο μακριά. Το Okmeter είναι πολύ κοντά στο να είναι τέλειο, αλλά λείπουν πολλά πράγματα που πρέπει να προστεθούν. Πρέπει να είστε προετοιμασμένοι για αυτό.
Για παράδειγμα, είναι καλύτερο να παρακολουθείτε τις νεκρές πλειάδες. Εάν έχετε πολλά νεκρά πράγματα στο τραπέζι σας, τότε κάτι δεν πάει καλά. Καλύτερα να αντιδράσουμε τώρα, αλλιώς μπορεί να υπάρξει υποβάθμιση και να κατέβουμε. Αυτό συμβαίνει.
Εάν υπάρχει μεγάλο IO, τότε είναι σαφές ότι αυτό δεν είναι καλό.
Πολύωρες συναλλαγές επίσης. Δεν θα πρέπει να επιτρέπονται μεγάλες συναλλαγές στο OLTP. Και εδώ είναι ένας σύνδεσμος προς ένα απόσπασμα που σας επιτρέπει να λάβετε αυτό το απόσπασμα και να παρακολουθήσετε μακροχρόνιες συναλλαγές.
Γιατί οι μακροχρόνιες συναλλαγές είναι κακές; Γιατί όλες οι κλειδαριές θα απελευθερωθούν μόνο στο τέλος. Και κλειδώνουμε τους πάντες. Επιπλέον, εμποδίζουμε την αυτόματη σκούπα να λειτουργεί για όλα τα τραπέζια. Αυτό δεν είναι καθόλου καλό. Ακόμα κι αν έχετε ενεργοποιημένη τη λειτουργία αναμονής στη ρεπλίκα, εξακολουθεί να είναι κακό. Γενικά, είναι προτιμότερο να μην επιτρέπονται πουθενά μεγάλες συναλλαγές.
Εάν έχουμε πολλά τραπέζια που δεν είναι σκουπισμένα με ηλεκτρική σκούπα, τότε πρέπει να έχουμε μια ειδοποίηση. Αυτή είναι ακριβώς η κατάσταση που είναι δυνατή εδώ. Μπορούμε να επηρεάσουμε έμμεσα τη λειτουργία του αυτόματου κενού. Αυτό είναι ένα απόσπασμα από το Avito, το οποίο βελτίωσα λίγο. Και αποδείχθηκε ότι ήταν ένα ενδιαφέρον εργαλείο για να δούμε τι έχουμε με την αυτόματη ηλεκτρική σκούπα. Για παράδειγμα, περιμένουν κάποια τραπέζια και δεν μπορούν να περιμένουν τη σειρά τους. Πρέπει επίσης να τεθεί σε παρακολούθηση και να υπάρχει ειδοποίηση.
Και εκδίδει μπλοκ. Δάσος από δέντρα του αποκλεισμού. Μου αρέσει να παίρνω κάτι από κάποιον και να το βελτιώνω. Εδώ από το Data Egret πήρα ένα δροσερό αναδρομικό CTE που δείχνει ένα δάσος από δέντρα κλειδαριάς. Αυτό είναι καλό για τα διαγνωστικά. Και η παρακολούθηση μπορεί επίσης να οικοδομηθεί στη βάση της. Αλλά αυτό πρέπει να γίνει προσεκτικά. Πρέπει να κάνετε το statement_timeout σας μικρό. Και το lock_timeout είναι επιθυμητό.
Μερικές φορές όλα αυτά τα σφάλματα συμβαίνουν μαζί.
Κατά τη γνώμη μου, το μεγαλύτερο λάθος εδώ είναι οργανωτικό. Είναι οργανωτικό, επειδή η τεχνολογία δεν ανταποκρίνεται στο καθήκον. Αυτός είναι ο αριθμός 2 - έκαναν έλεγχο σε λάθος μέρος.
Δεν κάναμε έλεγχο εκεί γιατί δεν είχαμε έναν κλώνο παραγωγής για να τον ελέγξουμε εύκολα. Ο προγραμματιστής μπορεί να μην έχει καθόλου πρόσβαση στην παραγωγή.
Και κάναμε έλεγχο σε λάθος μέρος. Αν είχαν ελέγξει εκεί, θα το βλέπαμε μόνοι μας. Ο προγραμματιστής θα μπορούσε να τα δει όλα αυτά ακόμη και χωρίς DBA, αν τα έλεγχε σε ένα καλό περιβάλλον, όπου υπάρχει ο ίδιος όγκος δεδομένων και η ίδια τοποθεσία. Θα έβλεπε όλη αυτή την υποβάθμιση και θα ντρεπόταν.
Περισσότερα για την αυτόματη σκούπα. Αφού κάναμε έναν τεράστιο καθαρισμό πολλών εκατομμυρίων γραμμών, πρέπει ακόμα να κάνουμε μια ΕΠΑΝΑΣΥΣΚΕΥΑΣΙΑ. Αυτό είναι ιδιαίτερα σημαντικό για τους δείκτες. Θα έχουν πρόβλημα αφού καθαρίσουμε τα πάντα εκεί.
Και αν θέλετε να επαναφέρετε τις καθημερινές εργασίες καθαρισμού, τότε θα πρότεινα να το κάνετε πιο συχνά, αλλά σε μικρότερα κομμάτια. Μπορείτε να το κάνετε μία φορά το λεπτό ή ακόμα πιο συχνά, λίγο τη φορά. Και πρέπει να ρυθμίσουμε την παρακολούθηση δύο πραγμάτων: ότι αυτό το πράγμα δεν έχει σφάλματα και ότι δεν υστερεί. Το κόλπο που σου έδειξα θα το λύσει.
Αυτό που κάνουμε είναι ανοιχτού κώδικα. Αυτό δημοσιεύεται στο GitLab. Και το κάνουμε έτσι ώστε οι άνθρωποι να μπορούν να ελέγχουν ακόμη και χωρίς DBA. Φτιάχνουμε ένα εργαστήριο βάσης δεδομένων, δηλαδή αυτό που λέμε το βασικό συστατικό στο οποίο εργάζεται αυτή τη στιγμή ο Τζο. Και μπορείτε να πάρετε ένα αντίγραφο παραγωγής. Υπάρχει τώρα μια υλοποίηση του Joe for slack, όπου μπορείτε να πείτε: "εξηγήστε το τάδε ερώτημα" και να λάβετε αμέσως το αποτέλεσμα για το αντίγραφο της βάσης δεδομένων σας. Μπορείτε ακόμη και να κάνετε DELETE εκεί και κανείς δεν θα το προσέξει.
Ας υποθέσουμε ότι έχετε 10 terabyte, κάνουμε ένα εργαστήριο βάσης δεδομένων επίσης 10 terabyte. Και 10 προγραμματιστές μπορούν να εργαστούν ταυτόχρονα με βάσεις δεδομένων 10 terabyte. Ο καθένας μπορεί να κάνει ότι θέλει. Μπορεί να διαγράψει, να πέσει κλπ. Τόσο φανταστικό είναι. Θα μιλήσουμε για αυτό αύριο.
Αυτό ονομάζεται λεπτή παροχή. Αυτό είναι λεπτή παροχή. Αυτό είναι ένα είδος φαντασίας που μειώνει σημαντικά τις καθυστερήσεις στην ανάπτυξη, στις δοκιμές και κάνει τον κόσμο καλύτερο από αυτή την άποψη. Δηλαδή, σας επιτρέπει να αποφύγετε προβλήματα με μαζικές λειτουργίες.
Παράδειγμα: Βάση δεδομένων 5 terabyte, αντιγραφή σε λιγότερο από 30 δευτερόλεπτα. Και δεν εξαρτάται καν από το μέγεθος, δηλαδή δεν έχει σημασία πόσα terabyte.
Μπορείτε ήδη να επισκεφθείτε σήμερα και σκάβουμε στα εργαλεία μας. Μπορείτε να εγγραφείτε και να δείτε τι υπάρχει. Μπορείτε να εγκαταστήσετε αυτό το bot μόνοι σας. Είναι δωρεάν. Γράφω.
ερωτήσεις
Πολύ συχνά σε πραγματικές καταστάσεις αποδεικνύεται ότι τα δεδομένα που πρέπει να παραμείνουν στον πίνακα είναι πολύ λιγότερα από αυτά που πρέπει να διαγραφούν. Δηλαδή, σε μια τέτοια κατάσταση είναι συχνά πιο εύκολο να εφαρμοστεί μια τέτοια προσέγγιση, όταν είναι πιο απλό να δημιουργήσετε ένα νέο αντικείμενο, να αντιγράψετε μόνο τα απαραίτητα δεδομένα εκεί και να συνδέσετε τον παλιό πίνακα. Είναι σαφές ότι χρειάζεται μια προσέγγιση λογισμικού για αυτήν τη στιγμή ενώ αλλάζετε. Τι θα λέγατε για αυτή την προσέγγιση;
Αυτή είναι μια πολύ καλή προσέγγιση και ένα πολύ καλό έργο. Είναι πολύ παρόμοιο με αυτό που κάνει το pg_repack, είναι πολύ παρόμοιο με αυτό που πρέπει να κάνετε όταν κάνετε αναγνωριστικά 4 byte. Πολλά πλαίσια το έκαναν αυτό πριν από μερικά χρόνια, και καθώς οι πίνακες μεγάλωναν, έπρεπε να μετατραπούν σε 8 byte.
Αυτό το έργο είναι αρκετά δύσκολο. Το κάναμε. Και πρέπει να είστε πολύ προσεκτικοί. Υπάρχουν κλειδαριές και ούτω καθεξής. Γίνεται όμως. Δηλαδή, η τυπική προσέγγιση είναι παρόμοια με το pg_repack. Ανακοινώνεις ένα τέτοιο σημάδι. Και προτού ξεκινήσετε τη μεταφόρτωση δεδομένων σε αυτό χρησιμοποιώντας ένα στιγμιότυπο, δηλώνετε επίσης έναν πίνακα που παρακολουθεί όλες τις αλλαγές. Υπάρχει ένα κόλπο εκεί που μπορεί να μην παρακολουθείτε καν κάποιες αλλαγές. Υπάρχουν λεπτότητες. Και στη συνέχεια αλλάζετε, προωθώντας τις αλλαγές. Θα υπάρξει μια μικρή παύση, ενώ θα κλειδώσουμε όλους, αλλά γενικά έχει γίνει.
Αν κοιτάξετε το pg_repack στο GitHub, τότε όταν υπήρχε μια εργασία για τη μετατροπή του αναγνωριστικού από int 4 σε int 8, υπήρχε μια ιδέα να χρησιμοποιήσετε το ίδιο το pg_repack. Αυτό είναι επίσης δυνατό, αλλά είναι λίγο μια μέθοδος χάκερ, αλλά θα λειτουργήσει και για αυτό. Μπορείτε να επέμβετε στο έναυσμα που χρησιμοποιεί το pg_repack και να πείτε εκεί: "Δεν χρειαζόμαστε αυτά τα δεδομένα", δηλαδή μεταφέρουμε μόνο ό,τι χρειαζόμαστε. Και μετά θα αλλάξει και τέλος.
Με αυτήν την προσέγγιση, παίρνουμε επίσης ένα δεύτερο αντίγραφο του πίνακα, στον οποίο τα δεδομένα είναι ήδη ευρετηριασμένα και τοποθετημένα πολύ ομοιόμορφα με όμορφα ευρετήρια.
Οχι, αυτή είναι μια καλή προσέγγιση. Ξέρω όμως ότι γίνονται προσπάθειες να αναπτυχθεί αυτοματισμός για αυτό, δηλαδή να γίνει μια καθολική λύση. Μπορώ να σας φέρω σε επαφή με αυτόν τον αυτοματισμό. Είναι γραμμένο σε Python, καλά πράγματα.
Είμαι λίγο από τον κόσμο της MySQL, οπότε ήρθα να ακούσω. Και χρησιμοποιούμε αυτήν την προσέγγιση.
Αλλά λειτουργεί μόνο αν έχουμε 90%. Αν έχουμε 5%, τότε δεν είναι πολύ καλό να το χρησιμοποιήσουμε.
Ευχαριστώ για την αναφορά! Εάν δεν υπάρχουν πόροι για να δημιουργήσετε ένα πλήρες αντίγραφο του prod, υπάρχει κάποιος αλγόριθμος ή τύπος για τον υπολογισμό του φορτίου ή του μεγέθους;
Καλή ερώτηση. Μέχρι στιγμής μπορέσαμε να βρούμε βάσεις δεδομένων πολλών terabyte. Ακόμα κι αν το υλικό εκεί δεν είναι το ίδιο, για παράδειγμα, λιγότερη μνήμη, λιγότερος επεξεργαστής και οι δίσκοι δεν είναι εντελώς ίδιοι, αλλά και πάλι το κάνουμε. Εάν δεν υπάρχει πουθενά, τότε πρέπει να το σκεφτείτε. Άσε με να το σκεφτώ μέχρι αύριο, ήρθες, θα τα πούμε, είναι καλή ερώτηση.
Ευχαριστώ για την αναφορά! Στην αρχή άρχισες να μιλάς για το πώς υπάρχει ένα κουλ Postgres, που έχει τέτοιους περιορισμούς, αλλά εξελίσσεται. Αλλά όλα αυτά είναι ένα δεκανίκι, γενικά. Όλα αυτά δεν έρχονται σε αντίθεση με την εξέλιξη της ίδιας της Postgres, στην οποία θα εμφανιστεί κάποιο DELETE deferent ή κάτι άλλο που θα έπρεπε να υποστηρίζει σε χαμηλό επίπεδο αυτό που προσπαθούμε να καλύψουμε εδώ με κάποια περίεργα μέσα μας;
Εάν είπαμε στην SQL να διαγράψει ή να ενημερώσει πολλές εγγραφές σε μία συναλλαγή, πώς μπορεί η Postgres να τις διανείμει; Είμαστε σωματικά περιορισμένοι στις λειτουργίες. Θα συνεχίσουμε να το κάνουμε αυτό για πολύ καιρό. Και θα κλειδώσουμε αυτή την ώρα κ.λπ.
Το έκαναν με τους δείκτες.
Μπορώ να υποθέσω ότι ο ίδιος συντονισμός σημείων ελέγχου θα μπορούσε να αυτοματοποιηθεί. Κάποτε, ίσως, θα συμβεί. Αλλά τότε δεν καταλαβαίνω πραγματικά την ερώτηση.
Το ερώτημα είναι, δεν υπάρχει ένας φορέας ανάπτυξης που συμβαίνει εκεί, και εδώ ο δικός σας συνεχίζεται παράλληλα; Εκείνοι. Δεν το έχουν σκεφτεί ακόμα;
Μίλησα για τις αρχές που μπορούν να χρησιμοποιηθούν τώρα. Υπάρχει ένα άλλο bot , με αυτό μπορείτε να κάνετε αυτοματοποιημένο συντονισμό σημείων ελέγχου. Θα είναι ποτέ αυτό στο Postgres; Δεν ξέρω, δεν έχει συζητηθεί ακόμη. Είμαστε ακόμα μακριά από αυτό. Υπάρχουν όμως επιστήμονες που κατασκευάζουν νέα συστήματα. Και μας σπρώχνουν σε αυτόματα ευρετήρια. Υπάρχουν εξελίξεις. Για παράδειγμα, μπορείτε να δείτε τον αυτόματο συντονισμό. Επιλέγει τις παραμέτρους αυτόματα. Αλλά δεν θα σας κάνει ακόμα συντονισμό στο σημείο ελέγχου. Δηλαδή θα επιλέξει για απόδοση, buffer κελύφους κ.λπ.
Και για τον συντονισμό σημείων ελέγχου μπορείτε να το κάνετε αυτό: αν έχετε χίλια συμπλέγματα και διαφορετικό υλικό, διαφορετικές εικονικές μηχανές στο cloud, μπορείτε να χρησιμοποιήσετε το bot μας κάνουν αυτοματισμούς. Και το max_wal_size θα επιλεγεί αυτόματα σύμφωνα με τις ρυθμίσεις-στόχους σας. Αλλά δυστυχώς, αυτό δεν είναι ακόμη κοντά στο να είναι στον πυρήνα.
Καλησπέρα Μιλήσατε για το κακό των πολύωρων συναλλαγών. Είπατε ότι το autovacuum μπλοκάρεται σε περίπτωση διαγραφών. Πώς αλλιώς μας βλάπτει αυτό; Επειδή μιλάμε περισσότερο για την απελευθέρωση χώρου και τη δυνατότητα χρήσης του. Τι άλλο χάνουμε;
Αυτόματη σκούπα - αυτό μπορεί να μην είναι το μεγαλύτερο πρόβλημα εδώ. Και το γεγονός ότι μια μακροχρόνια συναλλαγή μπορεί να κλειδώσει άλλες συναλλαγές είναι μια πιο επικίνδυνη πιθανότητα. Μπορεί να συναντηθεί μπορεί και όχι. Αν συναντιόταν, τότε τα πράγματα θα μπορούσαν να είναι πολύ άσχημα. Και με την αυτόματη ηλεκτρική σκούπα - αυτό είναι επίσης ένα πρόβλημα. Υπάρχουν δύο προβλήματα με τις μεγάλες συναλλαγές στο OLTP: κλειδαριές και αυτόματη ηλεκτρική σκούπα. Και αν έχετε ενεργοποιημένη την ανάδραση ζεστής αναμονής στο αντίγραφο, τότε θα λάβετε επίσης μια κλειδαριά αυτόματης αναρρόφησης στο κύριο, θα προέρχεται από τη ρεπλίκα. Αλλά τουλάχιστον δεν θα υπάρχουν κλειδαριές εκεί. Και εδώ θα υπάρχουν κλειδαριές. Μιλάμε για αλλαγές δεδομένων, επομένως οι κλειδαριές είναι ένα σημαντικό σημείο εδώ. Και αν αυτό συνεχιστεί για μεγάλο χρονικό διάστημα, τότε όλο και περισσότερες συναλλαγές κλειδώνονται. Μπορούν να κλειδώσουν άλλους. Και εμφανίζονται τα δέντρα της κλειδαριάς. Έδωσα έναν σύνδεσμο για το απόσπασμα. Και αυτό το πρόβλημα γίνεται πιο ορατό πιο γρήγορα από το πρόβλημα με την αυτόματη σκούπα, το οποίο μπορεί μόνο να συσσωρευτεί.
Ευχαριστώ για την αναφορά! Ξεκινήσατε την αναφορά σας λέγοντας ότι κάνατε λανθασμένο έλεγχο. Συνεχίσαμε την ιδέα μας ότι πρέπει να πάρουμε τον ίδιο εξοπλισμό, με την ίδια βάση. Ας πούμε ότι δώσαμε στον προγραμματιστή μια βάση. Και εκπλήρωσε το αίτημα. Και όλα δείχνουν να είναι καλά μαζί του. Αλλά δεν τσεκάρει ζωντανά, και ζωντανά, για παράδειγμα, έχουμε ένα φορτίο 60-70%. Και ακόμα κι αν χρησιμοποιήσουμε αυτόν τον συντονισμό, δεν μας βγαίνει πολύ καλά
Είναι σημαντικό να έχετε έναν εμπειρογνώμονα στην ομάδα σας και να χρησιμοποιείτε ειδικούς του DBA που μπορούν να κάνουν μια πρόβλεψη για το τι θα συμβεί κάτω από πραγματικό φόρτο παρασκηνίου. Όταν απλώς εκτελούμε τις καθαρές αλλαγές, βλέπουμε μια εικόνα. Αλλά μια πιο προηγμένη προσέγγιση, όταν κάναμε ξανά το ίδιο, αλλά με ένα φορτίο προσομοιωμένο από την παραγωγή. Αυτό είναι απολύτως φοβερό. Πρέπει ακόμα να μεγαλώσεις σε αυτό. Αυτό είναι ενήλικος. Εξετάσαμε καθαρά τι ήταν διαθέσιμο και επίσης κοιτάξαμε να δούμε αν είχαμε αρκετούς πόρους. Αυτή είναι μια καλή ερώτηση.
Όταν κάνουμε ήδη garbage select και έχουμε, για παράδειγμα, μια διαγραμμένη σημαία
Αυτό κάνει αυτόματα το autovacuum στο Postgres.
Α, το κάνει;
Το Autovacuum είναι ένας συλλέκτης σκουπιδιών.
Σας ευχαριστούμε!
Ευχαριστώ για την αναφορά! Υπάρχει επιλογή να σχεδιάσουμε αμέσως μια βάση δεδομένων με διαχωρισμό έτσι ώστε όλα τα σκουπίδια να διαχωρίζονται από το κεντρικό τραπέζι κάπου στο πλάι;
Φυσικά υπάρχει.
Είναι δυνατόν να προστατευτούμε τότε αν έχουμε κλειδώσει ένα τραπέζι που δεν πρέπει να χρησιμοποιείται;
Φυσικά και υπάρχει. Αλλά αυτή είναι μια ερώτηση κότας και αυγού. Αν όλοι ξέρουμε τι θα συμβεί στο μέλλον, τότε, φυσικά, θα τα κάνουμε όλα υπέροχα. Αλλά η επιχείρηση αλλάζει, εμφανίζονται νέες στήλες και νέα αιτήματα. Και μετά - ωχ, θέλουμε να το διαγράψουμε. Αλλά αυτή είναι μια ιδανική κατάσταση, στη ζωή συμβαίνει, αλλά όχι πάντα. Αλλά γενικά είναι μια καλή ιδέα. Απλά περικόψτε και τέλος.
Πηγή: www.habr.com
