Κάποια στιγμή στο μακρινό μέλλον, η αυτόματη αφαίρεση περιττών δεδομένων θα είναι ένα από τα σημαντικά καθήκοντα του DBMS [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 αρχίζει να λειτουργεί λίγο πιο αργά.
Τότε καταλαβαίνουμε ότι πλέον έχουμε μια εταιρεία μάρκετινγκ και η επισκεψιμότητα θα είναι αρκετές φορές μεγαλύτερη, οπότε αποφασίζουμε να σταματήσουμε προσωρινά τα περιττά πράγματα. Και ξεχάστε να επιστρέψετε.
Λίγους μήνες αργότερα θυμήθηκαν. Και αυτός ο προγραμματιστής εγκατέλειψε ή είναι απασχολημένος με κάτι άλλο, έδωσε εντολή σε άλλον να το επιστρέψει.
Έλεγξε στον προγραμματισμό, στη σκηνή - όλα είναι εντάξει. Φυσικά, πρέπει ακόμα να καθαρίσετε ό,τι έχει συσσωρευτεί. Έλεγξε ότι όλα λειτουργούν.
Τι συμβαίνει μετά? Τότε όλα καταρρέουν για εμάς. Πέφτει έτσι που κάποια στιγμή πέσουν όλα κάτω. Όλοι είναι σοκαρισμένοι, κανείς δεν καταλαβαίνει τι συμβαίνει. Και μετά αποδεικνύεται ότι το θέμα ήταν σε αυτό το DELETE.
Κάτι πήγε στραβά? Εδώ είναι μια λίστα με το τι θα μπορούσε να έχει πάει στραβά. Ποιο από αυτά είναι το πιο σημαντικό;
-
Για παράδειγμα, δεν έγινε κριτική, δηλαδή ο ειδικός του DBA δεν το κοίταξε. Θα έβρισκε αμέσως το πρόβλημα με ένα έμπειρο μάτι, και εκτός αυτού, έχει πρόσβαση σε prod, όπου έχουν συσσωρευτεί αρκετά εκατομμύρια γραμμές.
-
Ίσως έλεγξαν κάτι λάθος.
-
Ίσως το υλικό είναι ξεπερασμένο και πρέπει να αναβαθμίσετε αυτήν τη βάση.
-
Ή κάτι δεν πάει καλά με την ίδια τη βάση δεδομένων και πρέπει να περάσουμε από το Postgres στη MySQL.
-
Ή ίσως κάτι δεν πάει καλά με την επέμβαση.
-
Ίσως υπάρχουν κάποια λάθη στην οργάνωση της εργασίας και πρέπει να απολύσετε κάποιον και να προσλάβετε τους καλύτερους ανθρώπους;
Δεν έγινε έλεγχος DBA. Αν υπήρχε DBA, θα έβλεπε αυτά τα πολλά εκατομμύρια γραμμές και ακόμη και χωρίς πειράματα θα έλεγε: «Δεν το κάνουν αυτό». Ας υποθέσουμε ότι αν αυτός ο κώδικας βρισκόταν στο GitLab, στο GitHub και θα υπήρχε μια διαδικασία αναθεώρησης κώδικα και δεν υπήρχε τέτοιο πράγμα που χωρίς την έγκριση του DBA αυτή η λειτουργία θα γινόταν στο prod, τότε προφανώς το DBA θα έλεγε: «Αυτό δεν μπορεί να γίνει .»
Και θα έλεγε ότι θα έχετε προβλήματα με το IO του δίσκου και όλες οι διαδικασίες θα τρελαθούν, μπορεί να υπάρχουν κλειδώματα, και επίσης θα μπλοκάρετε την αυτόματη ηλεκτρική σκούπα για ένα σωρό λεπτά, οπότε αυτό δεν είναι καλό.
Το δεύτερο λάθος - έκαναν έλεγχο σε λάθος μέρος. Είδαμε μετά το γεγονός ότι πολλά ανεπιθύμητα δεδομένα συσσωρεύτηκαν στο prod, αλλά ο προγραμματιστής δεν είχε συσσωρευμένα δεδομένα σε αυτήν τη βάση δεδομένων και κανείς δεν δημιούργησε αυτά τα ανεπιθύμητα δεδομένα κατά τη διάρκεια της σταδιοποίησης. Αντίστοιχα, υπήρχαν 1 γραμμές που λειτούργησαν γρήγορα.
Καταλαβαίνουμε ότι τα τεστ μας είναι αδύναμα, δηλαδή η διαδικασία που χτίζεται δεν πιάνει προβλήματα. Δεν πραγματοποιήθηκε επαρκές πείραμα DB.
Ένα ιδανικό πείραμα διεξάγεται κατά προτίμηση στον ίδιο εξοπλισμό. Δεν είναι πάντα δυνατό να γίνει αυτό στον ίδιο εξοπλισμό, αλλά είναι πολύ σημαντικό να είναι ένα αντίγραφο πλήρους μεγέθους της βάσης δεδομένων. Αυτό κηρύττω εδώ και αρκετά χρόνια. Και πριν από ένα χρόνο μίλησα για αυτό, μπορείτε να τα παρακολουθήσετε όλα στο YouTube.
Ίσως ο εξοπλισμός μας είναι κακός; Αν κοιτάξετε, τότε η καθυστέρηση εκτινάχθηκε. Είδαμε ότι η αξιοποίηση είναι 100%. Φυσικά, αν αυτοί ήταν σύγχρονοι δίσκοι NVMe, τότε μάλλον θα ήταν πολύ πιο εύκολο για εμάς. Και ίσως δεν θα το παρατούσαμε.
Εάν έχετε σύννεφα, τότε η αναβάθμιση γίνεται εύκολα εκεί. Έγινε νέα αντίγραφα στο νέο υλικό. μετάβαση. Και όλα καλά. Πολύ εύκολο.
Είναι δυνατόν να αγγίξετε με κάποιο τρόπο τους μικρότερους δίσκους; Και εδώ, μόνο με τη βοήθεια του DBA, βυθιζόμαστε σε ένα συγκεκριμένο θέμα που ονομάζεται συντονισμός σημείων ελέγχου. Αποδεικνύεται ότι δεν είχαμε συντονισμό σημείων ελέγχου.
Τι είναι το σημείο ελέγχου; Είναι σε οποιοδήποτε DBMS. Όταν έχετε δεδομένα στη μνήμη που αλλάζουν, δεν εγγράφονται αμέσως στο δίσκο. Οι πληροφορίες ότι τα δεδομένα έχουν αλλάξει γράφονται πρώτα στο αρχείο καταγραφής προκαταβολής εγγραφής. Και κάποια στιγμή, το DBMS αποφασίζει ότι ήρθε η ώρα να απορρίψουμε πραγματικές σελίδες στο δίσκο, ώστε αν έχουμε αποτυχία, να μπορούμε να κάνουμε λιγότερα REDO. Είναι σαν παιχνίδι. Αν σκοτωθούμε, θα ξεκινήσουμε το παιχνίδι από το τελευταίο σημείο ελέγχου. Και όλα τα DBMS το εφαρμόζουν.
Οι ρυθμίσεις στο Postgres υστερούν. Είναι σχεδιασμένα για όγκους δεδομένων και συναλλαγών ηλικίας 10-15 ετών. Και το σημείο ελέγχου δεν αποτελεί εξαίρεση.
Ακολουθούν οι πληροφορίες από την αναφορά ελέγχου Postgres, δηλαδή τον αυτόματο έλεγχο υγείας. Και εδώ είναι μια βάση δεδομένων πολλών terabyte. Και φαίνεται καλά ότι τα αναγκαστικά σημεία ελέγχου σχεδόν στο 90% των περιπτώσεων.
Τι σημαίνει? Υπάρχουν δύο ρυθμίσεις εκεί. Το σημείο ελέγχου μπορεί να έρθει μετά από timeout, για παράδειγμα, στα 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 σε περίπτωση κακής μαζικής ΔΙΑΓΡΑΦΗΣ, πώς θα κάνει checkpoint.
Το σημείο ελέγχου στα ρωσικά είναι σημεία ελέγχου.
Παράδειγμα: ΔΙΑΓΡΑΦΗ πολλών εκατομμυρίων σειρών ανά ευρετήριο, οι σειρές είναι "σκόρπιες" στις σελίδες.
Εδώ είναι ένα παράδειγμα. Αυτή είναι κάποια βάση. Και με την προεπιλεγμένη ρύθμιση του 1 gigabyte για max_wal_size, είναι πολύ ξεκάθαρο ότι οι δίσκοι μας πηγαίνουν στο ράφι για εγγραφή. Αυτή η εικόνα είναι τυπικό σύμπτωμα ενός πολύ άρρωστου ασθενούς, δηλαδή ένιωθε πραγματικά άσχημα. Και υπήρξε μια μεμονωμένη λειτουργία, υπήρχε μόνο μια ΔΙΑΓΡΑΦΗ πολλών εκατομμυρίων γραμμών.
Εάν επιτρέπεται μια τέτοια επέμβαση στο prod, τότε απλώς θα ξαπλώσουμε, γιατί είναι ξεκάθαρο ότι ένα DELETE μας σκοτώνει στο ράφι.
Περαιτέρω, όπου τα 16 gigabyte, είναι σαφές ότι τα δόντια έχουν ήδη φύγει. Τα δόντια είναι ήδη καλύτερα, δηλαδή χτυπάμε ταβάνι, αλλά όχι και τόσο άσχημα. Υπήρχε κάποια ελευθερία εκεί. Δεξιά είναι ο δίσκος. Και ο αριθμός των πράξεων - το δεύτερο γράφημα. Και είναι σαφές ότι ήδη αναπνέουμε λίγο πιο εύκολα όταν 16 gigabyte.
Και εκεί που 64 gigabyte φαίνεται ότι έχει γίνει τελείως καλύτερο. Ήδη τα δόντια είναι έντονα, υπάρχουν περισσότερες ευκαιρίες να επιβιώσετε από άλλες επεμβάσεις και να κάνετε κάτι με το δίσκο.
Γιατί έτσι;
Θα βουτήξω λίγο στις λεπτομέρειες, αλλά αυτό το θέμα, ο τρόπος διεξαγωγής του συντονισμού σημείων ελέγχου, μπορεί να οδηγήσει σε μια ολόκληρη αναφορά, επομένως δεν θα φορτώσω πολλά, αλλά θα περιγράψω λίγο τις δυσκολίες που υπάρχουν.
Εάν το σημείο ελέγχου συμβαίνει πολύ συχνά και ενημερώνουμε τις γραμμές μας όχι διαδοχικά, αλλά βρίσκουμε κατά ευρετήριο, κάτι που είναι καλό, επειδή δεν διαγράφουμε ολόκληρο τον πίνακα, τότε μπορεί να συμβεί ότι στην αρχή αγγίξαμε την πρώτη σελίδα και μετά τη χιλιοστή, και μετά επέστρεψε στο πρώτο . Και αν ανάμεσα σε αυτές τις επισκέψεις στην πρώτη σελίδα, το checkpoint το έχει ήδη αποθηκεύσει στο δίσκο, τότε θα το αποθηκεύσει ξανά, γιατί το λερώσαμε για δεύτερη φορά.
Και θα αναγκάσουμε το σημείο ελέγχου να το σώσει πολλές φορές. Πώς θα υπήρχαν περιττές επεμβάσεις για αυτόν.
Αλλά δεν είναι μόνο αυτό. Οι σελίδες είναι 8 kilobyte στο Postgres και 4 kilobyte στο Linux. Και υπάρχει μια ρύθμιση full_page_wrates. Είναι ενεργοποιημένο από προεπιλογή. Και αυτό είναι σωστό, γιατί αν το απενεργοποιήσουμε, τότε υπάρχει ο κίνδυνος να αποθηκευτεί μόνο η μισή σελίδα αν κολλήσει.
Η συμπεριφορά της εγγραφής στο WAL του καταγραφής προώθησης είναι τέτοια που όταν έχουμε ένα σημείο ελέγχου και αλλάζουμε σελίδα για πρώτη φορά, ολόκληρη η σελίδα, δηλαδή και τα 8 kilobyte, μπαίνει στο αρχείο καταγραφής προώθησης, αν και αλλάξαμε μόνο το γραμμή, που ζυγίζει 100 byte . Και πρέπει να γράψουμε ολόκληρη τη σελίδα.
Σε επόμενες αλλαγές θα υπάρχει μόνο μια συγκεκριμένη πλειάδα, αλλά για πρώτη φορά καταγράφουμε τα πάντα.
Και, κατά συνέπεια, εάν το σημείο ελέγχου συνέβη ξανά, τότε πρέπει να ξεκινήσουμε ξανά τα πάντα από την αρχή και να σπρώξουμε ολόκληρη τη σελίδα. Με συχνά σημεία ελέγχου, όταν περπατάμε στις ίδιες σελίδες, το full_page_writes = on θα είναι περισσότερο από ό,τι θα μπορούσε να είναι, δηλαδή δημιουργούμε περισσότερα WAL. Περισσότερα αποστέλλονται σε αντίγραφα, στο αρχείο, στο δίσκο.
Και, κατά συνέπεια, έχουμε δύο απολύσεις.
Αν αυξήσουμε το max_wal_size, αποδεικνύεται ότι διευκολύνουμε τόσο το checkpoint όσο και το wal writer. Και αυτό είναι υπέροχο.
Ας βάλουμε ένα terabyte και ας ζήσουμε με αυτό. Τι κακό έχει; Αυτό είναι κακό, γιατί σε περίπτωση αποτυχίας, θα ανεβαίνουμε για ώρες, γιατί το σημείο ελέγχου ήταν πολύ καιρό πριν και πολλά έχουν ήδη αλλάξει. Και πρέπει να κάνουμε όλο αυτό REDO. Και έτσι κάνουμε τη δεύτερη σειρά πειραμάτων.
Κάνουμε μια επιχείρηση και βλέπουμε όταν το σημείο ελέγχου είναι έτοιμο να ολοκληρωθεί, σκοτώνουμε -9 Postgres επίτηδες.
Και μετά το ξεκινάμε ξανά και βλέπουμε πόσο καιρό θα ανέβει σε αυτόν τον εξοπλισμό, δηλαδή πόσο θα ΕΠΑΝΑΓΝΩΡΙΖΕΙ σε αυτήν την κακή κατάσταση.
Δύο φορές θα σημειώσω ότι η κατάσταση είναι άσχημη. Πρώτον, τρακάραμε ακριβώς πριν τελειώσει το σημείο ελέγχου, οπότε έχουμε πολλά να χάσουμε. Και δεύτερον, είχαμε μια μαζική επέμβαση. Και αν τα σημεία ελέγχου βρίσκονταν σε timeout, τότε, πιθανότατα, θα δημιουργούσε λιγότερο WAL από το τελευταίο σημείο ελέγχου. Δηλαδή είναι διπλός χαμένος.
Μετράμε μια τέτοια κατάσταση για διαφορετικά μεγέθη max_wal_size και καταλαβαίνουμε ότι αν το max_wal_size είναι 64 gigabyte, τότε στη διπλή χειρότερη περίπτωση θα ανέβουμε για 10 λεπτά. Και σκεφτόμαστε αν μας ταιριάζει ή όχι. Αυτή είναι μια επιχειρηματική ερώτηση. Πρέπει να δείξουμε αυτή την εικόνα στους υπεύθυνους για τις επιχειρηματικές αποφάσεις και να ρωτήσουμε: «Πόση ώρα μπορούμε το πολύ να ξαπλώνουμε σε περίπτωση προβλήματος; Μπορούμε να ξαπλώσουμε στη χειρότερη κατάσταση για 3-5 λεπτά; Και παίρνεις απόφαση.
Και εδώ είναι ένα ενδιαφέρον σημείο. Έχουμε μερικές αναφορές για τον Πατρώνη στο συνέδριο. Και ίσως το χρησιμοποιείτε. Αυτό είναι ένα autofailover για την Postgres. Το GitLab και το Data Egret μίλησαν για αυτό.
Και αν έχετε ένα autofailover που έρχεται σε 30 δευτερόλεπτα, τότε ίσως μπορούμε να ξαπλώσουμε για 10 λεπτά; Γιατί μέχρι αυτό το σημείο θα μεταβούμε στο αντίγραφο και όλα θα πάνε καλά. Αυτό είναι ένα επίμαχο σημείο. Δεν ξέρω ξεκάθαρη απάντηση. Απλώς πιστεύω ότι αυτό το θέμα δεν αφορά μόνο την ανάκτηση crash.
Εάν έχουμε μια μακρά ανάκαμψη μετά από μια αποτυχία, τότε θα νιώθουμε άβολα σε πολλές άλλες καταστάσεις. Για παράδειγμα, στα ίδια πειράματα, όταν κάνουμε κάτι και μερικές φορές πρέπει να περιμένουμε για 10 λεπτά.
Εξακολουθώ να μην το πήγαινα πολύ μακριά, ακόμα κι αν έχουμε autofailover. Κατά κανόνα, τιμές όπως 64, 100 gigabyte είναι καλές τιμές. Μερικές φορές αξίζει ακόμη και να επιλέξετε λιγότερα. Γενικά, αυτή είναι μια λεπτή επιστήμη.
Για να κάνετε επαναλήψεις, για παράδειγμα, max_wal_size =1, 8, πρέπει να επαναλάβετε τη λειτουργία μάζας πολλές φορές. Τα κατάφερες. Και στην ίδια βάση θέλεις να το ξανακάνεις, αλλά τα έχεις ήδη διαγράψει όλα. Τι να κάνω?
Θα μιλήσω αργότερα για τη λύση μας, τι κάνουμε για να επαναλάβουμε σε τέτοιες καταστάσεις. Και αυτή είναι η πιο σωστή προσέγγιση.
Αλλά σε αυτή την περίπτωση ήμασταν τυχεροί. Εάν, όπως λέει εδώ "START, DELETE, ROLLBACK", τότε μπορούμε να επαναλάβουμε το DELETE. Δηλαδή, αν το ακυρώσαμε μόνοι μας, τότε μπορούμε να το επαναλάβουμε. Και φυσικά σε εσάς τα δεδομένα θα βρίσκονται στο ίδιο μέρος. Δεν παθαίνεις καν φούσκωμα. Μπορείτε να επαναλάβετε αυτά τα DELETE.
Αυτό το DELETE with ROLLBACK είναι ιδανικό για συντονισμό σημείων ελέγχου, ακόμα κι αν δεν έχετε σωστά αναπτυγμένα εργαστήρια βάσης δεδομένων.
Φτιάξαμε ένα πιάτο με μία στήλη «ι». Το Postgres έχει βοηθητικές στήλες. Είναι αόρατα εκτός και αν τους ζητηθεί συγκεκριμένα. Αυτά είναι: ctid, xmid, xmax.
Το Ctid είναι μια φυσική διεύθυνση. Μηδενική σελίδα, η πρώτη πλειάδα στη σελίδα.
Φαίνεται ότι μετά το ROOLBACK η πλειάδα παρέμεινε στην ίδια θέση. Δηλαδή, μπορούμε να προσπαθήσουμε ξανά, θα συμπεριφερθεί με τον ίδιο τρόπο. Αυτό είναι το κύριο πράγμα.
Xmax είναι η ώρα του θανάτου της πλειάδας. Έγινε σφραγίδα, αλλά η Postgres γνωρίζει ότι η συναλλαγή επαναφέρθηκε, επομένως δεν έχει σημασία αν είναι 0 ή πρόκειται για επαναφορά συναλλαγής. Αυτό υποδηλώνει ότι είναι δυνατή η επανάληψη στο DELETE και ο έλεγχος των μαζικών λειτουργιών της συμπεριφοράς του συστήματος. Μπορείτε να δημιουργήσετε εργαστήρια βάσεων δεδομένων για τους φτωχούς.
Πρόκειται για προγραμματιστές. Σχετικά με το DBA, επίσης, πάντα επιπλήττουν τους προγραμματιστές για αυτό: "Γιατί κάνετε τόσο μεγάλες και δύσκολες λειτουργίες;". Αυτό είναι ένα τελείως διαφορετικό κάθετο θέμα. Κάποτε υπήρχε διοίκηση, τώρα θα υπάρχει ανάπτυξη.
Προφανώς δεν έχουμε σπάσει σε κομμάτια. Είναι σαφές. Είναι αδύνατο να μην σπάσει ένα τέτοιο DELETE για ένα σωρό εκατομμύρια γραμμές σε μέρη. Θα γίνει για 20 λεπτά, και όλα θα ξαπλώσουν. Αλλά, δυστυχώς, ακόμη και έμπειροι προγραμματιστές κάνουν λάθη, ακόμη και σε πολύ μεγάλες εταιρείες.
Γιατί είναι σημαντικό να σπάσει;
-
Αν δούμε ότι ο δίσκος είναι σκληρός, τότε ας τον επιβραδύνουμε. Και αν είμαστε σπασμένοι, τότε μπορούμε να προσθέσουμε παύσεις, μπορούμε να επιβραδύνουμε το γκάζι.
-
Και δεν θα μπλοκάρουμε άλλους για πολύ καιρό. Σε ορισμένες περιπτώσεις, δεν έχει σημασία, αν διαγράφετε πραγματικά σκουπίδια που κανείς δεν εργάζεται, τότε πιθανότατα δεν θα αποκλείσετε κανέναν εκτός από την εργασία αυτόματης ηλεκτρικής σκούπας, επειδή θα περιμένει να ολοκληρωθεί η συναλλαγή. Αλλά αν αφαιρέσετε κάτι που μπορεί να ζητήσει κάποιος άλλος, τότε θα αποκλειστεί, θα υπάρξει κάποιου είδους αλυσιδωτή αντίδραση. Οι πολύωρες συναλλαγές θα πρέπει να αποφεύγονται σε ιστότοπους και εφαρμογές για κινητά.
Αυτό είναι ενδιαφέρον. Βλέπω συχνά ότι οι προγραμματιστές ρωτούν: "Τι μέγεθος συσκευασίας να επιλέξω;".
Είναι σαφές ότι όσο μεγαλύτερο είναι το μέγεθος του πακέτου, τόσο μικρότερο είναι το γενικό κόστος συναλλαγής, δηλαδή το πρόσθετο γενικό κόστος από τις συναλλαγές. Ταυτόχρονα όμως αυξάνεται και ο χρόνος για αυτή τη συναλλαγή.
Έχω έναν πολύ απλό κανόνα: πάρτε όσο περισσότερο μπορείτε, αλλά μην ξεπεράσετε τα εκτελέσιμα αρχεία ανά δευτερόλεπτο.
Γιατί ένα δευτερόλεπτο; Η εξήγηση είναι πολύ απλή και κατανοητή σε όλους, ακόμα και σε μη τεχνικούς ανθρώπους. Βλέπουμε μια αντίδραση. Ας πάρουμε 50 χιλιοστά του δευτερολέπτου. Αν κάτι έχει αλλάξει, τότε το μάτι μας θα αντιδράσει. Αν λιγότερο, τότε πιο δύσκολο. Εάν κάτι ανταποκριθεί μετά από 100 χιλιοστά του δευτερολέπτου, για παράδειγμα, κάνατε κλικ με το ποντίκι και σας απάντησε μετά από 100 χιλιοστά του δευτερολέπτου, αισθάνεστε ήδη αυτή τη μικρή καθυστέρηση. Ένα δεύτερο εκλαμβάνεται ήδη ως φρένο.
Αντίστοιχα, αν σπάσουμε τις μαζικές επιχειρήσεις μας σε εκρήξεις 10 δευτερολέπτων, τότε έχουμε τον κίνδυνο να μπλοκάρουμε κάποιον. Και θα λειτουργήσει για λίγα δευτερόλεπτα, και οι άνθρωποι θα το παρατηρήσουν ήδη. Επομένως, προτιμώ να μην κάνω περισσότερο από ένα δευτερόλεπτο. Αλλά ταυτόχρονα, μην το διαλύσετε πολύ λεπτά, γιατί τα γενικά έξοδα συναλλαγής θα είναι αισθητά. Η βάση θα είναι πιο σκληρή και μπορεί να προκύψουν άλλα διαφορετικά προβλήματα.
Επιλέγουμε το μέγεθος της συσκευασίας. Σε κάθε περίπτωση, μπορούμε να το κάνουμε διαφορετικά. Μπορεί να αυτοματοποιηθεί. Και είμαστε πεπεισμένοι για την αποτελεσματικότητα της επεξεργασίας ενός πακέτου. Δηλαδή κάνουμε ΔΙΑΓΡΑΦΗ ενός πακέτου ή ΕΝΗΜΕΡΩΣΗ.
Παρεμπιπτόντως, όλα αυτά για τα οποία μιλάω δεν αφορούν μόνο τη ΔΙΑΓΡΑΦΗ. Όπως μαντέψατε, αυτές είναι οποιεσδήποτε μαζικές λειτουργίες σε δεδομένα.
Και βλέπουμε ότι το σχέδιο είναι εξαιρετικό. Μπορείτε να δείτε τη σάρωση ευρετηρίου, η σάρωση μόνο ευρετηρίου είναι ακόμα καλύτερη. Και έχουμε έναν μικρό όγκο δεδομένων. Και λιγότερο από ένα δευτερόλεπτο εκπληρώνει. Σούπερ.
Και πρέπει ακόμα να βεβαιωθούμε ότι δεν υπάρχει υποβάθμιση. Συμβαίνει ότι τα πρώτα πακέτα λειτουργούν γρήγορα και μετά γίνεται χειρότερο, χειρότερο και χειρότερο. Η διαδικασία είναι τέτοια που χρειάζεται να δοκιμάσεις πολύ. Αυτό ακριβώς εξυπηρετεί τα εργαστήρια βάσης δεδομένων.
Και πρέπει ακόμα να ετοιμάσουμε κάτι ώστε να μας επιτρέψει να το ακολουθήσουμε σωστά στην παραγωγή. Για παράδειγμα, μπορούμε να γράψουμε την ώρα στο αρχείο καταγραφής, μπορούμε να γράψουμε πού βρισκόμαστε τώρα και ποιους έχουμε τώρα διαγράψει. Και αυτό θα μας επιτρέψει να καταλάβουμε τι συμβαίνει αργότερα. Και σε περίπτωση που κάτι πάει στραβά, βρείτε γρήγορα το πρόβλημα.
Εάν πρέπει να ελέγξουμε την αποτελεσματικότητα των αιτημάτων και πρέπει να επαναλάβουμε πολλές φορές, τότε υπάρχει ένα τέτοιο πράγμα όπως ένα συνάδελφο bot. Είναι ήδη έτοιμος. Χρησιμοποιείται από δεκάδες προγραμματιστές καθημερινά. Και ξέρει πώς να δώσει μια τεράστια βάση δεδομένων terabyte κατόπιν αιτήματος σε 30 δευτερόλεπτα, το δικό σας αντίγραφο. Και μπορείτε να διαγράψετε κάτι εκεί και να πείτε RESET, και να το διαγράψετε ξανά. Μπορείτε να πειραματιστείτε με αυτό τον τρόπο. Βλέπω μέλλον για αυτό το πράγμα. Και το κάνουμε ήδη.
Τι είναι οι στρατηγικές κατάτμησης; Βλέπω 3 διαφορετικές στρατηγικές κατάτμησης που χρησιμοποιούν οι προγραμματιστές στο πακέτο.
Το πρώτο είναι πολύ απλό. Έχουμε ένα αριθμητικό αναγνωριστικό. Και ας το αναλύσουμε σε διαφορετικά διαστήματα και ας δουλέψουμε με αυτό. Το μειονέκτημα είναι ξεκάθαρο. Στο πρώτο τμήμα, μπορεί να έχουμε 100 γραμμές αληθινών σκουπιδιών, στο δεύτερο 5 γραμμές ή καθόλου, ή και οι 1 γραμμές θα αποδειχθούν σκουπίδια. Πολύ άνιση δουλειά, αλλά είναι εύκολο να σπάσει. Πήραν τη μέγιστη ταυτότητα και την έσπασαν. Αυτή είναι μια αφελής προσέγγιση.
Η δεύτερη στρατηγική είναι μια ισορροπημένη προσέγγιση. Χρησιμοποιείται στο Gitlab. Πήραν και σκάρωσαν το τραπέζι. Βρήκαμε τα όρια των πακέτων ταυτότητας έτσι ώστε κάθε πακέτο είχε ακριβώς 10 εγγραφές. Και βάλτε τα σε ουρά. Και μετά επεξεργαζόμαστε. Μπορείτε να το κάνετε αυτό σε πολλά νήματα.
Στην πρώτη στρατηγική, επίσης, παρεμπιπτόντως, μπορείτε να το κάνετε αυτό σε πολλά νήματα. Δεν είναι δύσκολο.
Αλλά υπάρχει μια πιο δροσερή και καλύτερη προσέγγιση. Αυτή είναι η τρίτη στρατηγική. Και όταν είναι δυνατόν, είναι καλύτερο να το επιλέξετε. Αυτό το κάνουμε με βάση ένα ειδικό ευρετήριο. Σε αυτή την περίπτωση, πιθανότατα θα είναι ένας δείκτης σύμφωνα με την κατάσταση των σκουπιδιών και την ταυτότητά μας. Θα συμπεριλάβουμε το αναγνωριστικό ώστε να είναι σάρωση μόνο ευρετηρίου για να μην πάμε στο σωρό.
Γενικά, η σάρωση μόνο ευρετηρίου είναι ταχύτερη από τη σάρωση ευρετηρίου.
Και βρίσκουμε γρήγορα τα αναγνωριστικά μας που θέλουμε να αφαιρέσουμε. BATCH_SIZE επιλέγουμε εκ των προτέρων. Και όχι μόνο τα παίρνουμε, τα παίρνουμε με έναν ιδιαίτερο τρόπο και τα χακάρουμε αμέσως. Κλειδώνουμε όμως ώστε αν είναι ήδη κλειδωμένα, να μην τα κλειδώσουμε, αλλά να προχωρήσουμε και να πάρουμε τα επόμενα. Αυτό είναι για την ενημέρωση κλειδωμένη παράβλεψη. Αυτή η σούπερ δυνατότητα της Postgres μας επιτρέπει να δουλεύουμε σε πολλά νήματα αν θέλουμε. Είναι δυνατό σε ένα ρεύμα. Και εδώ υπάρχει ένα CTE - αυτό είναι ένα αίτημα. Και έχουμε μια πραγματική διαγραφή σε εξέλιξη στον δεύτερο όροφο αυτού του CTE - returning *. Μπορείτε να επιστρέψετε το αναγνωριστικό, αλλά είναι καλύτερα *εάν δεν έχετε πολλά δεδομένα σε κάθε γραμμή.
Γιατί το χρειαζόμαστε; Αυτό πρέπει να αναφέρουμε. Έχουμε πλέον διαγράψει τόσες πολλές γραμμές στην πραγματικότητα. Και έχουμε σύνορα με αναγνωριστικό ή από create_at όπως αυτό. Μπορείτε να κάνετε min, max. Κάτι άλλο μπορεί να γίνει. Μπορείτε να κάνετε πολλά πράγματα εδώ. Και είναι πολύ βολικό για παρακολούθηση.
Υπάρχει μια ακόμη σημείωση για τον δείκτη. Εάν αποφασίσουμε ότι χρειαζόμαστε ένα ειδικό ευρετήριο για αυτήν την εργασία, τότε πρέπει να βεβαιωθούμε ότι δεν χαλάει τις ενημερώσεις πλειάδων μόνο. Δηλαδή η Postgres έχει τέτοια στατιστικά. Αυτό μπορεί να φανεί στους pg_stat_user_tables για τον πίνακά σας. Μπορείτε να δείτε εάν χρησιμοποιούνται hot ενημερώσεις ή όχι.
Υπάρχουν περιπτώσεις που ο νέος σας δείκτης μπορεί απλά να τους κόψει. Και έχετε όλες τις άλλες ενημερώσεις που ήδη λειτουργούν, επιβραδύνετε. Όχι μόνο επειδή εμφανίστηκε το ευρετήριο (κάθε ευρετήριο επιβραδύνει τις ενημερώσεις λίγο, αλλά λίγο), αλλά εδώ εξακολουθεί να το καταστρέφει. Και είναι αδύνατο να γίνει ειδική βελτιστοποίηση για αυτόν τον πίνακα. Αυτό συμβαίνει μερικές φορές. Αυτή είναι μια τέτοια λεπτότητα που λίγοι άνθρωποι θυμούνται. Και αυτή η τσουγκράνα είναι εύκολο να πατηθεί. Μερικές φορές συμβαίνει ότι πρέπει να βρείτε μια προσέγγιση από την άλλη πλευρά και να συνεχίσετε να κάνετε χωρίς αυτό το νέο ευρετήριο, ή να δημιουργήσετε άλλο ευρετήριο, ή με κάποιον άλλο τρόπο, για παράδειγμα, μπορείτε να χρησιμοποιήσετε τη δεύτερη μέθοδο.
Αλλά αυτή είναι η πιο βέλτιστη στρατηγική, πώς να χωρίσετε σε παρτίδες και να πυροβολήσετε σε παρτίδες με ένα αίτημα, να διαγράψετε λίγο κ.λπ.
Μακροχρόνιες συναλλαγές
Μπλοκαρισμένη αυτόματη ηλεκτρική σκούπα -
ζήτημα αποκλεισμού -
Το λάθος #5 είναι μεγάλο. Ο Νικολάι από το Okmeter μίλησε για την παρακολούθηση Postgres. Ιδανική παρακολούθηση Postgres, δυστυχώς, δεν υπάρχει. Άλλα είναι πιο κοντά, άλλα είναι πιο μακριά. Το Okmeter είναι αρκετά κοντά στο να είναι τέλειο, αλλά λείπουν πολλά και πρέπει να προστεθούν. Πρέπει να είστε έτοιμοι για αυτό.
Για παράδειγμα, οι νεκρές πλειάδες παρακολουθούνται καλύτερα. Εάν έχετε πολλά νεκρά πράγματα στον πίνακα, τότε κάτι δεν πάει καλά. Είναι καλύτερα να αντιδράσουμε τώρα, αλλιώς μπορεί να υπάρξει υποβάθμιση, και να ξαπλώσουμε. Συμβαίνει.
Εάν υπάρχει μεγάλο IO, τότε είναι σαφές ότι αυτό δεν είναι καλό.
Πολύωρες συναλλαγές επίσης. Δεν θα πρέπει να επιτρέπονται μεγάλες συναλλαγές στο OLTP. Και εδώ είναι ένας σύνδεσμος προς ένα απόσπασμα που σας επιτρέπει να πάρετε αυτό το απόσπασμα και να κάνετε ήδη κάποια παρακολούθηση μεγάλων συναλλαγών.
Γιατί οι μακροχρόνιες συναλλαγές είναι κακές; Γιατί όλες οι κλειδαριές θα απελευθερωθούν μόνο στο τέλος. Και τους βιδώνουμε όλους. Επιπλέον, αποκλείουμε την αυτόματη ηλεκτρική σκούπα για όλα τα τραπέζια. Δεν είναι καθόλου καλό. Ακόμα κι αν έχετε ενεργοποιημένη τη λειτουργία αναμονής στη ρεπλίκα, εξακολουθεί να είναι κακό. Γενικά, πουθενά δεν είναι καλύτερο να αποφύγεις τις μακροχρόνιες συναλλαγές.
Εάν έχουμε πολλά τραπέζια που δεν είναι σκουπισμένα με ηλεκτρική σκούπα, τότε πρέπει να έχουμε μια ειδοποίηση. Εδώ μια τέτοια κατάσταση είναι δυνατή. Μπορούμε να επηρεάσουμε έμμεσα τη λειτουργία του αυτόματου κενού. Αυτό είναι ένα απόσπασμα από το Avito, το οποίο βελτίωσα ελαφρώς. Και αποδείχθηκε ότι ήταν ένα ενδιαφέρον εργαλείο για να δούμε τι έχουμε με την αυτόματη ηλεκτρική σκούπα. Για παράδειγμα, κάποια τραπέζια περιμένουν εκεί και δεν θα περιμένουν τη σειρά τους. Πρέπει επίσης να το βάλετε σε παρακολούθηση και να έχετε ειδοποίηση.
Και εκδίδει μπλοκ. Δάσος από δέντρα. Μου αρέσει να παίρνω κάτι από κάποιον και να το βελτιώνω. Εδώ πήρα ένα δροσερό αναδρομικό CTE από το Data Egret που δείχνει ένα δάσος από δέντρα κλειδαριάς. Αυτό είναι ένα καλό διαγνωστικό εργαλείο. Και στη βάση του, μπορείτε επίσης να δημιουργήσετε παρακολούθηση. Αλλά αυτό πρέπει να γίνει προσεκτικά. Πρέπει να κάνετε ένα μικρό statement_timeout για τον εαυτό σας. Και το lock_timeout είναι επιθυμητό.
Μερικές φορές όλα αυτά τα σφάλματα συμβαίνουν αθροιστικά.
Κατά τη γνώμη μου, το κύριο λάθος εδώ είναι οργανωτικό. Είναι οργανωτικό, γιατί η τεχνική δεν τραβάει. Αυτός είναι ο αριθμός 2 - έκαναν έλεγχο σε λάθος μέρος.
Κάναμε έλεγχο σε λάθος μέρος, επειδή δεν είχαμε έναν κλώνο παραγωγής, ο οποίος είναι εύκολο να ελεγχθεί. Ένας προγραμματιστής μπορεί να μην έχει καθόλου πρόσβαση στην παραγωγή.
Και δεν ελέγξαμε εκεί. Αν είχαμε ελέγξει εκεί, θα το είχαμε δει μόνοι μας. Ο προγραμματιστής τα είδε όλα ακόμη και χωρίς DBA, αν το έλεγξε σε καλό περιβάλλον, όπου υπάρχουν τα ίδια δεδομένα και η ίδια τοποθεσία. Θα είχε δει όλη αυτή την υποβάθμιση και θα ντρεπόταν.
Περισσότερα για την αυτόματη σκούπα. Αφού έχουμε κάνει ένα τεράστιο σκούπισμα πολλών εκατομμυρίων γραμμών, πρέπει ακόμα να κάνουμε REPACK. Αυτό είναι ιδιαίτερα σημαντικό για τα ευρετήρια. Θα αισθανθούν άσχημα αφού καθαρίσαμε τα πάντα εκεί.
Και αν θέλετε να επαναφέρετε τις καθημερινές εργασίες καθαρισμού, τότε θα σας πρότεινα να το κάνετε πιο συχνά, αλλά μικρότερα. Μπορεί να είναι μία φορά το λεπτό ή ακόμα πιο συχνά λίγο. Και πρέπει να παρακολουθείτε δύο πράγματα: ότι αυτό το πράγμα δεν έχει σφάλματα και ότι δεν υστερεί. Το κόλπο που έδειξα θα το λύσει.
Αυτό που κάνουμε είναι ανοιχτού κώδικα. Έχει αναρτηθεί στο GitLab. Και το κάνουμε έτσι ώστε οι άνθρωποι να μπορούν να ελέγχουν ακόμη και χωρίς DBA. Κάνουμε ένα εργαστήριο βάσης δεδομένων, δηλαδή καλούμε το βασικό στοιχείο στο οποίο εργάζεται αυτή τη στιγμή ο Τζο. Και μπορείτε να πάρετε ένα αντίγραφο της παραγωγής. Τώρα υπάρχει μια υλοποίηση του Joe για χαλαρό, μπορείτε να πείτε εκεί: "εξηγήστε το τάδε αίτημα" και λάβετε αμέσως το αποτέλεσμα για το αντίγραφο της βάσης δεδομένων σας. Μπορείτε ακόμη και να ΔΙΑΓΡΑΨΕΤΕ εκεί και κανείς δεν θα το προσέξει.
Ας υποθέσουμε ότι έχετε 10 terabyte, κάνουμε το εργαστήριο βάσης δεδομένων επίσης 10 terabyte. Και με ταυτόχρονες βάσεις δεδομένων 10 terabyte, 10 προγραμματιστές μπορούν να εργαστούν ταυτόχρονα. Ο καθένας μπορεί να κάνει ότι θέλει. Μπορεί να διαγράψει, να απορρίψει κ.λπ. Αυτή είναι μια φαντασίωση. Θα μιλήσουμε για αυτό αύριο.
Αυτό ονομάζεται λεπτή παροχή. Αυτό είναι λεπτή παροχή. Αυτό είναι ένα είδος φαντασίας που αφαιρεί σε μεγάλο βαθμό τις καθυστερήσεις στην ανάπτυξη, στις δοκιμές και κάνει τον κόσμο καλύτερο από αυτή την άποψη. Δηλαδή, απλώς σας επιτρέπει να αποφύγετε προβλήματα με τις μαζικές λειτουργίες.
Παράδειγμα: Βάση δεδομένων 5 terabyte, λήψη αντιγράφου σε λιγότερο από 30 δευτερόλεπτα. Και δεν εξαρτάται καν από το μέγεθος, δηλαδή δεν έχει σημασία πόσα terabyte.
Σήμερα μπορείτε να πάτε στο και σκάβουμε στα εργαλεία μας. Μπορείτε να εγγραφείτε για να δείτε τι υπάρχει. Μπορείτε να εγκαταστήσετε αυτό το bot. Είναι δωρεάν. Γράφω.
ερωτήσεις
Πολύ συχνά σε πραγματικές καταστάσεις αποδεικνύεται ότι τα δεδομένα που πρέπει να παραμείνουν στον πίνακα είναι πολύ λιγότερα από αυτά που πρέπει να διαγραφούν. Δηλαδή, σε μια τέτοια κατάσταση, είναι συχνά πιο εύκολο να εφαρμοστεί μια τέτοια προσέγγιση, όταν είναι ευκολότερο να δημιουργήσετε ένα νέο αντικείμενο, να αντιγράψετε μόνο τα απαραίτητα δεδομένα εκεί και να συνδέσετε τον παλιό πίνακα. Είναι σαφές ότι χρειάζεται μια προγραμματική προσέγγιση για αυτήν τη στιγμή, ενώ θα αλλάζετε. Πώς είναι αυτή η προσέγγιση;
Αυτή είναι μια πολύ καλή προσέγγιση και ένα πολύ καλό έργο. Είναι πολύ παρόμοιο με αυτό που κάνει το pg_repack, είναι πολύ παρόμοιο με αυτό που πρέπει να κάνετε όταν κάνετε αναγνωριστικά 4 byte. Πολλά πλαίσια το έκαναν αυτό πριν από μερικά χρόνια, και απλώς οι πλάκες έχουν μεγαλώσει και πρέπει να μετατραπούν σε 8 byte.
Αυτό το έργο είναι αρκετά δύσκολο. Τα καταφέραμε. Και πρέπει να είσαι πολύ προσεκτικός. Υπάρχουν κλειδαριές κλπ. Γίνεται όμως. Δηλαδή, η τυπική προσέγγιση είναι να πάμε με το pg_repack. Δηλώνεις τέτοια ταμπέλα. Και προτού ξεκινήσετε να ανεβάζετε δεδομένα στιγμιότυπου σε αυτό, δηλώνετε επίσης μια πινακίδα που παρακολουθεί όλες τις αλλαγές. Υπάρχει ένα κόλπο που μπορεί να μην παρακολουθείτε καν κάποιες αλλαγές. Υπάρχουν λεπτότητες. Και μετά αλλάζετε με κυλιόμενες αλλαγές. Θα υπάρξει μια μικρή παύση όταν θα κλείσουμε τους πάντες, αλλά γενικά αυτό γίνεται.
Αν κοιτάξετε το pg_repack στο GitHub, τότε εκεί, όταν υπήρχε μια εργασία για τη μετατροπή ενός αναγνωριστικού από int 4 σε int 8, τότε υπήρχε μια ιδέα να χρησιμοποιήσετε το ίδιο το pg_repack. Αυτό είναι επίσης δυνατό, αλλά είναι λίγο χακάρισμα, αλλά θα λειτουργήσει και για αυτό. Μπορείτε να επέμβετε στο έναυσμα που χρησιμοποιεί το pg_repack και να πείτε εκεί: "Δεν χρειαζόμαστε αυτά τα δεδομένα", δηλαδή μεταφέρουμε μόνο ό,τι χρειαζόμαστε. Και μετά απλώς αλλάζει και τέλος.
Με αυτήν την προσέγγιση, εξακολουθούμε να λαμβάνουμε ένα δεύτερο αντίγραφο του πίνακα, στον οποίο τα δεδομένα είναι ήδη ευρετηριασμένα και στοιβάζονται πολύ ομοιόμορφα με όμορφα ευρετήρια.
Το Bloat δεν υπάρχει, είναι μια καλή προσέγγιση. Ξέρω όμως ότι γίνονται προσπάθειες να αναπτυχθεί ένας αυτοματισμός για αυτό, δηλαδή να γίνει μια καθολική λύση. Μπορώ να σας φέρω σε επαφή με αυτόν τον αυτοματισμό. Είναι γραμμένο σε Python, κάτι που είναι καλό.
Είμαι λίγο από τον κόσμο της MySQL, οπότε ήρθα να ακούσω. Και χρησιμοποιούμε αυτήν την προσέγγιση.
Αλλά είναι μόνο αν έχουμε το 90%. Αν έχουμε 5%, τότε δεν είναι πολύ καλό να το χρησιμοποιήσουμε.
Ευχαριστώ για την αναφορά! Εάν δεν υπάρχουν πόροι για να δημιουργήσετε ένα πλήρες αντίγραφο του prod, υπάρχει κάποιος αλγόριθμος ή τύπος για τον υπολογισμό του φορτίου ή του μεγέθους;
Καλή ερώτηση. Μέχρι στιγμής, είμαστε σε θέση να βρούμε βάσεις δεδομένων πολλών terabyte. Ακόμα κι αν το υλικό εκεί δεν είναι το ίδιο, για παράδειγμα, λιγότερη μνήμη, λιγότερος επεξεργαστής και δίσκοι δεν είναι ακριβώς το ίδιο, αλλά και πάλι το κάνουμε. Εάν δεν υπάρχει πουθενά, τότε πρέπει να σκεφτείτε. Άσε με να σκεφτώ μέχρι αύριο, ήρθες, θα μιλήσουμε, αυτή είναι μια καλή ερώτηση.
Ευχαριστώ για την αναφορά! Αρχικά ξεκινήσατε για το γεγονός ότι υπάρχει ένα κουλ Postgres, το οποίο έχει τέτοιους περιορισμούς, αλλά αναπτύσσεται. Και όλα αυτά είναι ένα δεκανίκι γενικά. Δεν έρχεται σε σύγκρουση όλο αυτό με την ανάπτυξη της ίδιας της Postgres, στην οποία θα εμφανιστεί κάποιο DELETE deferent ή κάτι άλλο που θα έπρεπε να κρατήσει σε χαμηλό επίπεδο αυτό που προσπαθούμε να λερώνουμε με κάποια περίεργα μέσα μας εδώ;
Αν είπαμε στην SQL να διαγράψουμε ή να ενημερώσουμε πολλές εγγραφές σε μία συναλλαγή, τότε πώς μπορεί η Postgres να τη διανείμει εκεί; Είμαστε σωματικά περιορισμένοι σε λειτουργίες. Θα το κάνουμε ακόμα για πολύ καιρό. Και θα κλειδώσουμε αυτή την ώρα κ.λπ.
Έγινε με ευρετήρια.
Μπορώ να υποθέσω ότι ο ίδιος συντονισμός σημείων ελέγχου θα μπορούσε να αυτοματοποιηθεί. Κάποτε μπορεί να είναι. Αλλά τότε δεν καταλαβαίνω πραγματικά την ερώτηση.
Το ερώτημα είναι, υπάρχει τέτοιος φορέας ανάπτυξης που πηγαίνει εδώ κι εκεί, και εδώ ο δικός σας είναι παράλληλος; Εκείνοι. Δεν το έχουν σκεφτεί ακόμα;
Μίλησα για τις αρχές που μπορούν να χρησιμοποιηθούν τώρα. Υπάρχει ένα άλλο bot , με αυτό μπορείτε να κάνετε αυτοματοποιημένο συντονισμό σημείων ελέγχου. Θα είναι κάποια μέρα στο Postgres; Δεν ξέρω, δεν έχει καν συζητηθεί ακόμα. Είμαστε ακόμα μακριά από αυτό. Υπάρχουν όμως επιστήμονες που κατασκευάζουν νέα συστήματα. Και μας χώνουν σε αυτόματα ευρετήρια. Υπάρχουν εξελίξεις. Για παράδειγμα, μπορείτε να δείτε τον αυτόματο συντονισμό. Επιλέγει τις παραμέτρους αυτόματα. Αλλά δεν θα κάνει ακόμα συντονισμό στο σημείο ελέγχου για εσάς. Δηλαδή, θα πάρει για απόδοση, buffer κελύφους κ.λπ.
Και για τον συντονισμό σημείων ελέγχου, μπορείτε να το κάνετε αυτό: εάν έχετε χίλια συμπλέγματα και διαφορετικό υλικό, διαφορετικές εικονικές μηχανές στο cloud, μπορείτε να χρησιμοποιήσετε το bot μας κάνουν αυτοματισμούς. Και το max_wal_size θα επιλεγεί αυτόματα σύμφωνα με τις ρυθμίσεις-στόχους σας. Αλλά μέχρι στιγμής αυτό δεν είναι καν κοντά στον πυρήνα, δυστυχώς.
Καλό απόγευμα Μιλήσατε για τους κινδύνους των μακροχρόνιων συναλλαγών. Είπατε ότι το autovacuum μπλοκάρεται σε περίπτωση διαγραφών. Πώς αλλιώς μας βλάπτει; Γιατί μιλάμε περισσότερο για την απελευθέρωση χώρου και τη δυνατότητα χρήσης του. Τι άλλο μας λείπει;
Η αυτόματη σκούπα δεν είναι ίσως το μεγαλύτερο πρόβλημα εδώ. Και το γεγονός ότι μια μεγάλη συναλλαγή μπορεί να κλειδώσει άλλες συναλλαγές, αυτή η πιθανότητα είναι πιο επικίνδυνη. Μπορεί να συναντηθεί μπορεί και όχι. Αν γνωρίστηκε, τότε μπορεί να είναι πολύ κακό. Και με την αυτόματη ηλεκτρική σκούπα - αυτό είναι επίσης ένα πρόβλημα. Υπάρχουν δύο προβλήματα με τις μεγάλες συναλλαγές στο OLTP: κλειδαριές και αυτόματη ηλεκτρική σκούπα. Και αν έχετε ενεργοποιημένη την ανάδραση ζεστής αναμονής στο αντίγραφο, τότε το κλείδωμα αυτόματης αναρρόφησης θα φτάσει επίσης στο κύριο, θα φτάσει από το αντίγραφο. Αλλά τουλάχιστον δεν θα υπάρχουν κλειδαριές. Και θα υπάρχουν λοξοί. Μιλάμε για αλλαγές δεδομένων, επομένως οι κλειδαριές είναι ένα σημαντικό σημείο εδώ. Και αν όλα αυτά είναι για πολύ, πολύ καιρό, τότε όλο και περισσότερες συναλλαγές κλειδώνονται. Μπορούν να κλέψουν άλλους. Και εμφανίζονται δέντρα Lok. Έδωσα έναν σύνδεσμο για το απόσπασμα. Και αυτό το πρόβλημα γίνεται πιο ορατό πιο γρήγορα από το πρόβλημα με την αυτόματη σκούπα, το οποίο μπορεί μόνο να συσσωρευτεί.
Ευχαριστώ για την αναφορά! Ξεκινήσατε την αναφορά σας λέγοντας ότι κάνατε λανθασμένο έλεγχο. Συνεχίσαμε την ιδέα μας ότι πρέπει να πάρουμε τον ίδιο εξοπλισμό, με τη βάση με τον ίδιο τρόπο. Ας πούμε ότι δώσαμε στον προγραμματιστή μια βάση. Και συμμορφώθηκε με το αίτημα. Και φαίνεται να είναι καλά. Δεν κάνει όμως έλεγχο για live, αλλά για live πχ έχουμε φορτίο 60-70%. Και ακόμα κι αν χρησιμοποιήσουμε αυτόν τον συντονισμό, δεν λειτουργεί πολύ καλά.
Είναι σημαντικό να έχετε έναν εμπειρογνώμονα στην ομάδα και να χρησιμοποιείτε ειδικούς του DBA που μπορούν να προβλέψουν τι θα συμβεί με ένα πραγματικό φορτίο φόντου. Όταν μόλις οδηγήσαμε τις καθαρές αλλαγές μας, βλέπουμε την εικόνα. Αλλά μια πιο προηγμένη προσέγγιση, όταν κάναμε ξανά το ίδιο, αλλά με ένα φορτίο προσομοιωμένο με την παραγωγή. Είναι πολύ ωραίο. Μέχρι τότε πρέπει να μεγαλώσεις. Είναι σαν ενήλικας. Απλώς εξετάσαμε τι έχουμε και επίσης εξετάσαμε αν έχουμε αρκετούς πόρους. Αυτή είναι μια καλή ερώτηση.
Όταν κάνουμε ήδη μια επιλογή σκουπιδιών και έχουμε, για παράδειγμα, μια διαγραμμένη σημαία
Αυτό κάνει αυτόματα το autovacuum στο Postgres.
Α, το κάνει;
Το Autovacuum είναι ο συλλέκτης σκουπιδιών.
Σας ευχαριστούμε!
Ευχαριστώ για την αναφορά! Υπάρχει επιλογή να σχεδιάσετε αμέσως μια βάση δεδομένων με διαχωρισμό με τέτοιο τρόπο ώστε όλα τα σκουπίδια να λερώνονται από το κεντρικό τραπέζι κάπου στο πλάι;
Φυσικά υπάρχει.
Είναι δυνατόν τότε να προστατευτούμε αν έχουμε κλειδώσει ένα τραπέζι που δεν πρέπει να χρησιμοποιείται;
Φυσικά και έχουν. Αλλά είναι σαν μια ερώτηση κοτόπουλου και αυγού. Αν όλοι ξέρουμε τι θα συμβεί στο μέλλον, τότε, φυσικά, θα τα κάνουμε όλα καλά. Αλλά η επιχείρηση αλλάζει, υπάρχουν νέες στήλες, νέα αιτήματα. Και μετά – ωχ, θέλουμε να το αφαιρέσουμε. Αλλά αυτή η ιδανική κατάσταση, στη ζωή συμβαίνει, αλλά όχι πάντα. Αλλά γενικά είναι μια καλή ιδέα. Απλά περικόψτε και τέλος.
Πηγή: www.habr.com