Μεταγραφή της ομιλίας του Bruce Momjian το 2020 "Ξεκλείδωμα του Postgres Lock Manager".
(Σημείωση: Μπορείτε να λάβετε όλα τα ερωτήματα SQL από τις διαφάνειες σε αυτόν τον σύνδεσμο: )
Γειά σου! Είναι υπέροχο να βρίσκομαι ξανά εδώ στη Ρωσία. Λυπάμαι που δεν μπόρεσα να έρθω πέρυσι, αλλά φέτος ο Ιβάν και εγώ έχουμε μεγάλα σχέδια. Ελπίζω να είμαι εδώ πολύ πιο συχνά. Μου αρέσει να έρχομαι στη Ρωσία. Θα επισκεφθώ το Tyumen, Tver. Είμαι πολύ χαρούμενος που θα μπορέσω να επισκεφτώ αυτές τις πόλεις.
Το όνομά μου είναι Bruce Momjian. Εργάζομαι στην EnterpriseDB και συνεργάζομαι με την Postgres για πάνω από 23 χρόνια. Ζω στη Φιλαδέλφεια των Η.Π.Α. Ταξιδεύω περίπου 90 μέρες το χρόνο. Και παρακολουθώ περίπου 40 συνέδρια. Μου , το οποίο περιέχει τις διαφάνειες που θα σας δείξω τώρα. Επομένως, μετά το συνέδριο, μπορείτε να τα κατεβάσετε από τον προσωπικό μου ιστότοπο. Περιέχει επίσης περίπου 30 παρουσιάσεις. Και υπάρχουν επίσης βίντεο και ένας μεγάλος αριθμός καταχωρίσεων ιστολογίου, περισσότερες από 500. Αυτή είναι μια αρκετά ενημερωτική πηγή. Και αν σας ενδιαφέρει αυτό το υλικό, τότε σας προσκαλώ να το χρησιμοποιήσετε.
Ήμουν δάσκαλος, καθηγητής πριν ξεκινήσω να δουλεύω με την Postgres. Και χαίρομαι πολύ που μπορώ τώρα να σου πω αυτό που θα σου πω. Αυτή είναι μια από τις πιο ενδιαφέρουσες παρουσιάσεις μου. Και αυτή η παρουσίαση περιέχει 110 διαφάνειες. Θα αρχίσουμε να μιλάμε με απλά πράγματα, και μέχρι το τέλος της έκθεσης θα γίνεται όλο και πιο περίπλοκο, και θα γίνεται αρκετά περίπλοκο.
Αυτή είναι μια μάλλον δυσάρεστη συζήτηση. Ο αποκλεισμός δεν είναι το πιο δημοφιλές θέμα. Θέλουμε κάπου να εξαφανιστεί. Είναι σαν να πηγαίνεις στον οδοντίατρο.
- Το κλείδωμα είναι ένα πρόβλημα για πολλούς ανθρώπους που εργάζονται σε βάσεις δεδομένων και έχουν πολλές διεργασίες που εκτελούνται ταυτόχρονα. Χρειάζονται μπλοκάρισμα. Δηλαδή σήμερα θα σου δώσω βασικές γνώσεις μπλοκαρίσματος.
- Αναγνωριστικά συναλλαγών. Αυτό είναι ένα μάλλον βαρετό μέρος της παρουσίασης, αλλά πρέπει να γίνει κατανοητό.
- Στη συνέχεια, θα μιλήσουμε για τους τύπους αποκλεισμού. Είναι αρκετά μηχανικό μέρος.
- Και στη συνέχεια θα δώσουμε μερικά παραδείγματα αποκλεισμού. Και θα είναι αρκετά δύσκολο να το καταλάβεις.
Ας μιλήσουμε για μπλοκάρισμα.
Η ορολογία μας είναι αρκετά περίπλοκη. Πόσοι από εσάς γνωρίζετε από πού προέρχεται αυτό το απόσπασμα; Δύο άνθρωποι. Είναι από ένα παιχνίδι που ονομάζεται Colossal Cave Adventure. Ήταν ένα παιχνίδι υπολογιστή βασισμένο σε κείμενο τη δεκαετία του '80, νομίζω. Εκεί χρειάστηκε να μπω στη σπηλιά, στον λαβύρινθο και το κείμενο άλλαζε, αλλά το περιεχόμενο ήταν περίπου το ίδιο κάθε φορά. Έτσι θυμάμαι αυτό το παιχνίδι.
Και εδώ βλέπουμε το όνομα των κλειδαριών που μας ήρθαν από την Oracle. Τα χρησιμοποιούμε.
Εδώ βλέπουμε όρους που με μπερδεύουν. Για παράδειγμα, SHARE UPDATE EXXLUSIVE. Επόμενο ΚΟΙΝΟΠΟΙΗΣΤΕ ΑΠΟΚΛΕΙΣΤΙΚΟ ΑΚΑΤΕΡΓΑΣΤΟ. Ειλικρινά, αυτά τα ονόματα δεν είναι πολύ ξεκάθαρα. Θα προσπαθήσουμε να τα εξετάσουμε με περισσότερες λεπτομέρειες. Κάποια περιέχουν τη λέξη «μοιράζομαι», που σημαίνει χωρίζω. Ορισμένα περιέχουν τη λέξη "αποκλειστικό" - αποκλειστικό. Ορισμένες περιέχουν και τις δύο αυτές λέξεις. Θα ήθελα να ξεκινήσω με το πώς λειτουργούν αυτές οι κλειδαριές.
Και η λέξη «πρόσβαση» είναι επίσης πολύ σημαντική. Και οι λέξεις "σειρά" - μια γραμμή. Δηλαδή διανομή πρόσβασης, διανομή σειρών.
Ένα άλλο πρόβλημα που πρέπει να γίνει κατανοητό στο Postgres, το οποίο δυστυχώς δεν θα μπορέσω να καλύψω στην ομιλία μου, είναι το MVCC. Έχω μια ξεχωριστή παρουσίαση για αυτό το θέμα στον ιστότοπό μου. Και αν πιστεύετε ότι αυτή η παρουσίαση είναι δύσκολη, τότε το MVCC είναι ίσως το πιο δύσκολο μου. Και αν σας ενδιαφέρει μπορείτε να το δείτε στο site. Μπορείτε να παρακολουθήσετε το βίντεο.
Ένα άλλο πράγμα που πρέπει να καταλάβουμε είναι τα αναγνωριστικά συναλλαγών. Πολλές συναλλαγές δεν μπορούν να λειτουργήσουν χωρίς μοναδικά αναγνωριστικά. Και εδώ έχουμε μια εξήγηση για το τι είναι μια συναλλαγή. Η Postgres διαθέτει δύο συστήματα αρίθμησης συναλλαγών. Ξέρω ότι δεν είναι μια πολύ όμορφη λύση.
Λάβετε επίσης υπόψη ότι οι διαφάνειες θα είναι αρκετά δύσκολο να διαβαστούν, επομένως αυτό που επισημαίνεται με κόκκινο είναι αυτό που πρέπει να προσέξετε.
Εμείς κοιτάμε. Ο αριθμός συναλλαγής επισημαίνεται με κόκκινο χρώμα. Εδώ εμφανίζεται η συνάρτηση SELECT pg_back. Επιστρέφει τη συναλλαγή μου και το αναγνωριστικό αυτής της συναλλαγής.
Κάτι ακόμα, αν σας αρέσει αυτή η παρουσίαση και θέλετε να την εκτελέσετε στη βάση δεδομένων σας, τότε μπορείτε να ακολουθήσετε αυτόν τον σύνδεσμο που τονίζεται με ροζ και να κάνετε λήψη του SQL για αυτήν την παρουσίαση. Και μπορείτε απλώς να το εκτελέσετε στο PSQL σας και ολόκληρη η παρουσίαση θα είναι στην οθόνη σας σε ελάχιστο χρόνο. Δεν θα περιέχει λουλούδια, αλλά τουλάχιστον μπορούμε να το δούμε.
Σε αυτήν την περίπτωση, βλέπουμε το αναγνωριστικό συναλλαγής. Αυτός είναι ο αριθμός που της δώσαμε. Και υπάρχει ένας άλλος τύπος αναγνωριστικού συναλλαγής στο Postgres που ονομάζεται εικονικό αναγνωριστικό συναλλαγής
Και αυτό πρέπει να το καταλάβουμε. Αυτό είναι πολύ σημαντικό, διαφορετικά δεν θα μπορούμε να καταλάβουμε το κλείδωμα στην Postgres.
Ένα εικονικό αναγνωριστικό συναλλαγής είναι ένα αναγνωριστικό συναλλαγής που δεν περιέχει σταθερές τιμές. Για παράδειγμα, αν εκτελέσω μια εντολή SELECT, τότε πιθανότατα δεν θα αλλάξω τη βάση δεδομένων, δεν θα κλειδώσω τίποτα. Έτσι, όταν εκτελούμε ένα απλό SELECT, δεν δίνουμε σε αυτήν τη συναλλαγή μόνιμο αναγνωριστικό. Εκεί της δίνουμε μόνο μια εικονική ταυτότητα.
Και αυτό βελτιώνει την απόδοση του Postgres, βελτιώνει την ικανότητα καθαρισμού, επομένως το εικονικό αναγνωριστικό συναλλαγής αποτελείται από δύο αριθμούς. Ο πρώτος αριθμός πριν από την κάθετο είναι το αναγνωριστικό υποστήριξης. Και στα δεξιά βλέπουμε μόνο έναν πάγκο.
Επομένως, εάν εκτελέσω ένα αίτημα, λέει ότι το αναγνωριστικό υποστήριξης είναι 2.
Και αν εκτελέσω μια σειρά από τέτοιες συναλλαγές, τότε βλέπουμε ότι ο μετρητής αυξάνεται κάθε φορά που εκτελώ το ερώτημα. Για παράδειγμα, όταν εκτελώ το ερώτημα 2/10, 2/11, 2/12 κ.λπ.
Λάβετε υπόψη ότι υπάρχουν δύο στήλες εδώ. Στα αριστερά, βλέπουμε το εικονικό αναγνωριστικό συναλλαγής - 2/12. Και στα δεξιά έχουμε ένα μόνιμο αναγνωριστικό συναλλαγής. Και αυτό το πεδίο είναι κενό. Και αυτή η συναλλαγή δεν τροποποιεί τη βάση δεδομένων. Επομένως, δεν του εκχωρώ μόνιμο αναγνωριστικό συναλλαγής.
Μόλις εκτελέσω την εντολή ανάλυσης ((ΑΝΑΛΥΣΗ)), το ίδιο ερώτημα μου δίνει ένα μόνιμο αναγνωριστικό συναλλαγής. Δείτε πώς έχουμε αλλάξει. Παλαιότερα δεν είχα αυτή την ταυτότητα, τώρα την έχω.
Να λοιπόν άλλο αίτημα, άλλη συναλλαγή. Ο αριθμός εικονικής συναλλαγής είναι 2/13. Και αν ζητήσω ένα μόνιμο αναγνωριστικό συναλλαγής, τότε όταν εκτελέσω το αίτημα, θα το πάρω.
Για άλλη μια φορά λοιπόν. Έχουμε ένα εικονικό αναγνωριστικό συναλλαγής και ένα μόνιμο αναγνωριστικό συναλλαγής. Απλώς πάρτε αυτό το σημείο για να κατανοήσετε τη συμπεριφορά της Postgres.
Προχωράμε στην τρίτη ενότητα. Εδώ θα περιηγηθούμε στους διαφορετικούς τύπους κλειδαριών στο Postgres. Δεν είναι πολύ ενδιαφέρον. Η τελευταία ενότητα θα είναι πολύ πιο ενδιαφέρουσα. Πρέπει όμως να αναλογιστούμε τα βασικά, γιατί αλλιώς δεν θα καταλάβουμε τι θα γίνει μετά.
Θα περάσουμε από αυτήν την ενότητα, θα εξετάσουμε κάθε τύπο αποκλεισμού. Και θα σας δείξω παραδείγματα για το πώς εγκαθίστανται, πώς λειτουργούν, θα σας δείξω ορισμένα ερωτήματα που μπορείτε να χρησιμοποιήσετε για να δείτε πώς λειτουργεί ο αποκλεισμός στο Postgres.
Για να δημιουργήσουμε ένα ερώτημα και να δούμε τι συμβαίνει στο Postgres, πρέπει να υποβάλουμε το ερώτημα στην προβολή συστήματος. Σε αυτήν την περίπτωση, το pg_lock επισημαίνεται με κόκκινο χρώμα. Το pg_lock είναι ένας πίνακας συστήματος που μας λέει ποιες κλειδαριές χρησιμοποιούνται αυτήν τη στιγμή στο Postgres.
Ωστόσο, μου είναι πολύ δύσκολο να σας δείξω το pg_lock από μόνο του, γιατί είναι αρκετά περίπλοκο. Έτσι δημιούργησα μια προβολή που δείχνει το pg_locks. Και κάνει επίσης κάποια δουλειά για μένα που μου επιτρέπει να καταλαβαίνω καλύτερα. Δηλαδή, αποκλείει τα lock μου, τη δική μου συνεδρία κλπ. Είναι απλά τυπική SQL και σου επιτρέπει να δείχνεις καλύτερα τι συμβαίνει.
Ένα άλλο πρόβλημα είναι ότι αυτή η προβολή είναι πολύ ευρεία, επομένως πρέπει να δημιουργήσω μια δεύτερη - lockview2.
Και μου δείχνει περισσότερες στήλες από τον πίνακα. Και άλλο ένα που μου δείχνει τις υπόλοιπες στήλες. Αυτό είναι αρκετά περίπλοκο, γι' αυτό προσπάθησα να το παρουσιάσω όσο πιο απλά μπορούσα.
Έτσι, δημιουργήσαμε έναν πίνακα που ονομάζεται Lockdemo. Και δημιουργήσαμε μια γραμμή εκεί. Αυτός είναι ο πίνακας δειγμάτων μας. Και θα δημιουργήσουμε ενότητες μόνο για να σας δείξουμε παραδείγματα αποκλεισμού.
Άρα, μία γραμμή, μία στήλη. Ο πρώτος τύπος κλειδαριάς ονομάζεται ACCESS SHARE. Αυτός είναι ο λιγότερο περιοριστικός αποκλεισμός. Αυτό σημαίνει ότι πρακτικά δεν έρχεται σε αντίθεση με άλλες κλειδαριές.
Και αν θέλουμε να ορίσουμε ρητά μια κλειδαριά, εκτελούμε την εντολή "lock table". Και θα μπλοκάρει ρητά, δηλαδή στη λειτουργία ACCESS SHARE, τρέχουμε τον πίνακα κλειδώματος. Και αν ξεκινήσω το PSQL στο παρασκήνιο, τότε ξεκινώ τη δεύτερη συνεδρία από την πρώτη μου συνεδρία με αυτόν τον τρόπο. Δηλαδή τι θα κάνω εδώ; Πηγαίνω σε μια άλλη συνεδρία και του λέω "δείξε μου το lockview για αυτό το αίτημα". Και εδώ έχω ένα AccessShareLock σε αυτόν τον πίνακα. Αυτό ακριβώς ζήτησα. Και λέει ότι η κλειδαριά έχει ανατεθεί. Πολύ απλό.
Επιπλέον, αν κοιτάξουμε τη δεύτερη στήλη, τότε δεν υπάρχει τίποτα εκεί. Είναι άδεια.
Και αν εκτελέσω την εντολή "SELECT", τότε αυτός είναι ο σιωπηρός (ρητός) τρόπος για να ζητήσω το AccessShareLock. Έτσι, απελευθερώνω τον πίνακα μου και εκτελώ ένα ερώτημα και το ερώτημα επιστρέφει πολλές σειρές. Και σε μια από τις γραμμές βλέπουμε το AccessShareLock. Έτσι, το SELECT καλεί το AccessShareLock στο τραπέζι. Και δεν έρχεται σε αντίθεση με σχεδόν τίποτα, γιατί είναι κλειδαριά χαμηλού επιπέδου.
Τι γίνεται αν εκτελέσω ένα SELECT και έχω τρεις διαφορετικούς πίνακες; Προηγουμένως έτρεχα μόνο ένα τραπέζι, τώρα τρέχω τρία: pg_class, pg_namespace και pg_attribute.
Και τώρα, όταν κοιτάζω το ερώτημα, βλέπω 9 AccessShareLocks σε XNUMX πίνακες. Γιατί; Τρεις πίνακες επισημαίνονται με μπλε χρώμα: pg_attribute, pg_class, pg_namespace. Αλλά μπορείτε επίσης να δείτε ότι όλα τα ευρετήρια που ορίζονται μέσω αυτών των πινάκων έχουν επίσης AccessShareLock.
Και αυτό είναι ένα μπλοκάρισμα που πρακτικά δεν έρχεται σε αντίθεση με άλλους. Και το μόνο που κάνει είναι απλώς να μας εμποδίζει να ρίξουμε τον πίνακα ενώ τον επιλέγουμε. Είναι λογικό. Δηλαδή, αν επιλέξουμε έναν πίνακα, εξαφανίζεται εκείνη τη στιγμή, τότε αυτό είναι λάθος, επομένως Το AccessShare είναι ένα κλείδωμα χαμηλού επιπέδου που μας λέει "μην διαγράψετε αυτόν τον πίνακα ενώ εργάζομαι". Βασικά, αυτό είναι το μόνο που κάνει.
ΜΟΙΡΑΣΙΑ ΣΕΙΡΩΝ - Αυτή η κλειδαριά είναι λίγο διαφορετική.
Ας πάρουμε ένα παράδειγμα. SELECT ROW SHARE τρόπο για να κλειδώσετε κάθε σειρά ξεχωριστά. Με αυτόν τον τρόπο κανείς δεν μπορεί να τα διαγράψει ή να τα αλλάξει όσο τα παρακολουθούμε.
Λοιπόν, τι κάνει το SHARE LOCK; Βλέπουμε ότι το αναγνωριστικό συναλλαγής είναι 681 για το SELECT. Και είναι ενδιαφέρον. Τι συνέβη εδώ? Για πρώτη φορά βλέπουμε τον αριθμό στο πεδίο "Κλείδωμα". Παίρνουμε το αναγνωριστικό συναλλαγής και λέει ότι το μπλοκάρει σε αποκλειστική λειτουργία. Το μόνο που κάνει είναι να λέει ότι έχω μια σειρά που είναι τεχνικά κλειδωμένη κάπου στον πίνακα. Δεν λέει όμως πού ακριβώς. Θα το δούμε αναλυτικότερα λίγο αργότερα.
Εδώ λέμε ότι η κλειδαριά χρησιμοποιείται από εμάς.
Άρα, μια αποκλειστική κλειδαριά λέει ρητά (ρητά) ότι είναι αποκλειστική. Και επίσης εάν διαγράψετε μια σειρά σε αυτόν τον πίνακα, αυτό συμβαίνει, όπως μπορείτε να δείτε.
Το SHARE EXCLUSIVE είναι μια μακρύτερη κλειδαριά.
Αυτή είναι (ANALYZE) η εντολή αναλυτή που θα χρησιμοποιηθεί.
ΚΛΕΙΔΩΜΑ ΚΟΙΝΟΠΟΙΗΣΗΣ - Μπορείτε να κλειδώσετε ρητά στη λειτουργία κοινής χρήσης.
Μπορείτε επίσης να δημιουργήσετε ένα μοναδικό ευρετήριο. Και εκεί μπορείτε να δείτε το SHARE LOCK, το οποίο είναι μέρος τους. Και κλειδώνει το τραπέζι και θέτει μια κλειδαριά SHARE LOCK σε αυτό.
Το προεπιλεγμένο ΚΛΕΙΔΩΜΑ SHARE σε έναν πίνακα σημαίνει ότι άλλα άτομα μπορούν να διαβάσουν τον πίνακα, αλλά κανείς δεν μπορεί να τον τροποποιήσει. Και αυτό ακριβώς συμβαίνει όταν δημιουργείτε ένα μοναδικό ευρετήριο.
Εάν δημιουργήσω ένα μοναδικό ταυτόχρονο ευρετήριο, τότε θα έχω διαφορετικό τύπο κλειδαριάς, γιατί, θυμηθείτε, η χρήση ταυτόχρονων ευρετηρίων μειώνει την απαίτηση κλειδώματος. Και αν χρησιμοποιήσω ένα κανονικό κλείδωμα, ένα κανονικό ευρετήριο, τότε εμποδίζω έτσι την εγγραφή στο ευρετήριο του πίνακα κατά τη δημιουργία του. Εάν χρησιμοποιώ ταυτόχρονα ευρετήριο, τότε πρέπει να χρησιμοποιήσω διαφορετικό τύπο κλειδαριάς.
ΑΠΟΚΛΕΙΣΤΙΚΟ ΚΟΙΝΟΠΟΙΗΣΗ ΣΕΙΡΑΣ - και πάλι, μπορεί να οριστεί ρητά (ρητά).
Ή μπορούμε να δημιουργήσουμε έναν κανόνα, δηλαδή να πάρουμε κάποια συγκεκριμένη περίπτωση στην οποία θα χρησιμοποιηθεί.
ΑΠΟΚΛΕΙΣΤΙΚΟ κλείδωμα σημαίνει ότι κανείς άλλος δεν μπορεί να αλλάξει το τραπέζι.
Εδώ βλέπουμε διαφορετικούς τύπους κλειδαριών.
Το ACCESS EXCLUSIVE, για παράδειγμα, είναι μια εντολή κλειδώματος. Για παράδειγμα, αν το κάνετε CLUSTER table, τότε θα σημαίνει ότι κανείς δεν θα μπορεί να γράψει εκεί. Και κλειδώνει όχι μόνο τον ίδιο τον πίνακα, αλλά και τα ευρετήρια.
Αυτή είναι η δεύτερη σελίδα της κλειδαριάς ACCESS EXCLUSIVE όπου βλέπουμε συγκεκριμένα τι κλειδώνει στον πίνακα. Κλειδώνει μεμονωμένες σειρές τραπεζιών, κάτι που είναι αρκετά ενδιαφέρον.
Αυτές είναι όλες οι βασικές πληροφορίες που ήθελα να δώσω. Μιλήσαμε για κλειδώματα, για αναγνωριστικά συναλλαγών, μιλήσαμε για εικονικά αναγνωριστικά συναλλαγών, για μόνιμα αναγνωριστικά συναλλαγών.
Και τώρα θα περάσουμε από τα παραδείγματα αποκλεισμού. Αυτό είναι το πιο ενδιαφέρον κομμάτι. Θα δούμε πολύ ενδιαφέρουσες περιπτώσεις. Και ο στόχος μου σε αυτήν την παρουσίαση είναι να σας δώσω μια καλύτερη ιδέα για το τι κάνει στην πραγματικότητα η Postgres όταν προσπαθεί να μπλοκάρει τα πράγματα. Μου φαίνεται ότι είναι πολύ καλός στο να μπλοκάρει μεμονωμένα μέρη.
Ας δούμε μερικά συγκεκριμένα παραδείγματα.
Θα ξεκινήσουμε με πίνακες και μία σειρά ανά πίνακα. Όταν εισάγω κάτι, έχω ExclusiveLock, Transaction ID και ExclusiveLock στο τραπέζι.
Τι θα συμβεί αν εισαγάγω δύο ακόμη σειρές; Και τώρα το τραπέζι μας έχει τρεις σειρές. Και έβαλα μια σειρά και το πήρα ως έξοδο. Και αν βάλω άλλες δύο σειρές, τι περίεργο είναι εδώ; Υπάρχει ένα περίεργο εδώ γιατί έχω προσθέσει τρεις σειρές σε αυτόν τον πίνακα, αλλά εξακολουθώ να έχω δύο σειρές στον πίνακα κλειδώματος. Και αυτή είναι στην πραγματικότητα η θεμελιώδης συμπεριφορά της Postgres.
Πολλοί άνθρωποι πιστεύουν ότι εάν σε μια βάση δεδομένων κλειδώσετε 100 σειρές, τότε θα χρειαστεί να δημιουργήσετε 100 καταχωρήσεις κλειδώματος. Εάν αποκλείσω 1 σειρές ταυτόχρονα, τότε θα χρειαστώ 000 τέτοια αιτήματα. Και αν χρειάζομαι ένα εκατομμύριο ή ένα δισεκατομμύριο για να μπλοκάρω. Αλλά αν το κάνουμε αυτό, δεν θα λειτουργήσει πολύ καλά. Εάν έχετε χρησιμοποιήσει ένα σύστημα που δημιουργεί καταχωρήσεις αποκλεισμού για κάθε μεμονωμένη σειρά, τότε μπορείτε να δείτε ότι αυτό είναι περίπλοκο. Επειδή πρέπει να ορίσετε αμέσως τον πίνακα κλειδαριάς, ο οποίος μπορεί να ξεχειλίσει, αλλά η Postgres δεν το κάνει αυτό.
Και είναι πολύ σημαντικό σε αυτή τη διαφάνεια να δείχνει ξεκάθαρα ότι υπάρχει ένα άλλο σύστημα που λειτουργεί μέσα στο MVCC που μπλοκάρει μεμονωμένες γραμμές. Έτσι, όταν κλειδώνετε δισεκατομμύρια σειρές, η Postgres δεν δημιουργεί ένα δισεκατομμύριο ξεχωριστές οδηγίες κλειδώματος. Και αυτό είναι πολύ καλό για απόδοση.
Τι γίνεται με μια ενημέρωση; Ενημερώνω τη σειρά τώρα και μπορείτε να δείτε ότι έχει κάνει δύο διαφορετικές λειτουργίες ταυτόχρονα. Κλείδωσε το τραπέζι ταυτόχρονα, αλλά κλείδωσε και τον δείκτη. Και έπρεπε να κλειδώσει το ευρετήριο επειδή υπάρχουν μοναδικοί περιορισμοί σε αυτόν τον πίνακα. Και θέλουμε να βεβαιωθούμε ότι κανείς δεν το αλλάξει, γι' αυτό το μπλοκάρουμε.
Τι συμβαίνει εάν θέλω να ενημερώσω δύο σειρές; Και βλέπουμε ότι συμπεριφέρεται με τον ίδιο τρόπο. Κάνουμε διπλάσιες ενημερώσεις, αλλά ακριβώς τον ίδιο αριθμό γραμμών αποκλεισμού.
Αν αναρωτιέστε πώς το κάνει αυτό η Postgres, θα πρέπει να ακούσετε τις ομιλίες μου στο MVCC για να μάθετε πώς η Postgres επισημαίνει εσωτερικά αυτές τις γραμμές που αλλάζει. Και η Postgres έχει τον τρόπο να το κάνει, αλλά δεν το κάνει σε επίπεδο κλειδώματος τραπεζιού, το κάνει σε χαμηλότερο και πιο αποτελεσματικό επίπεδο.
Τι γίνεται αν θέλω να διαγράψω κάτι; Αν διαγράψω, για παράδειγμα, μια σειρά και εξακολουθώ να έχω τις δύο εισόδους μου στο κλείδωμα, και ακόμα κι αν θέλω να τις διαγράψω όλες, εξακολουθούν να υπάρχουν.
Και, για παράδειγμα, θέλω να εισαγάγω 1 γραμμές και, στη συνέχεια, είτε να διαγράψω είτε να προσθέσω 000 γραμμές, μετά οι μεμονωμένες γραμμές που προσθέτω ή αλλάζω, δεν καταγράφονται εδώ. Είναι γραμμένα σε χαμηλότερο επίπεδο μέσα στην ίδια τη σειρά. Και κατά τη διάρκεια της ομιλίας του MVCC, μίλησα για αυτό λεπτομερώς. Αλλά είναι πολύ σημαντικό όταν αναλύετε κλειδαριές να βεβαιωθείτε ότι έχετε κλειδαριά σε επίπεδο πίνακα και ότι δεν μπορείτε να δείτε πώς γράφονται εδώ μεμονωμένες σειρές.
Τι γίνεται με τον ρητό αποκλεισμό;
Αν κάνω κλικ στο "refresh" τότε έχω δύο σειρές κλειδωμένες. Και αν τα επιλέξω όλα και πατήσω "ενημέρωση παντού", τότε έχω ακόμα δύο κλειδωμένες εγγραφές.
Δεν δημιουργούμε ξεχωριστές εγγραφές για κάθε μεμονωμένη σειρά. Επειδή τότε η απόδοση πέφτει, μπορεί να είναι πάρα πολύ. Και μπορεί να βρεθούμε σε μια δυσάρεστη κατάσταση.
Και το ίδιο πράγμα, αν κάνουμε κοινή χρήση, μπορούμε να κάνουμε τα πάντα 30 φορές.
Επαναφέρουμε τον πίνακα μας, διαγράφουμε τα πάντα και μετά εισάγουμε ξανά μία σειρά.
Ένα άλλο είδος συμπεριφοράς που βλέπετε στο Postgres που είναι πολύ γνωστό και επιθυμητό είναι ότι μπορείτε να κάνετε μια ενημέρωση ή μια επιλογή. Και μπορείς να το κάνεις ταυτόχρονα. Και η επιλογή δεν μπλοκάρει την ενημέρωση και το ίδιο πράγμα προς την αντίθετη κατεύθυνση. Λέμε στον αναγνώστη να μην μπλοκάρει τον συγγραφέα και ο συγγραφέας δεν έχει μπλοκάρει τον αναγνώστη.
Θα σας δείξω ένα παράδειγμα αυτού. Θα κάνω μια επιλογή τώρα. Στη συνέχεια θα κάνουμε INSERT. Και μετά μπορείτε να δείτε - 694. Μπορείτε να δείτε το αναγνωριστικό της συναλλαγής που έκανε αυτό το ένθετο. Και έτσι λειτουργεί.
Και αν κοιτάξω τώρα το αναγνωριστικό του backend μου, έχει γίνει - 695.
Και μπορώ να δω ότι το 695 εμφανίζεται στον πίνακα μου.
Και αν κάνω ενημέρωση εδώ έτσι, τότε έχω διαφορετική περίπτωση. Σε αυτήν την περίπτωση, το 695 είναι ένα αποκλειστικό κλείδωμα και η ενημέρωση έχει την ίδια συμπεριφορά, αλλά δεν υπάρχει καμία σύγκρουση μεταξύ τους, κάτι που είναι αρκετά ασυνήθιστο.
Και μπορείτε να παρατηρήσετε ότι στην κορυφή είναι το ShareLock και στο κάτω είναι το ExclusiveLock. Και οι δύο συναλλαγές πέτυχαν.
Και πρέπει να ακούσετε την ομιλία μου στο MVCC για να καταλάβετε πώς συμβαίνει αυτό. Αλλά αυτό είναι μια απεικόνιση του γεγονότος ότι μπορείτε να το κάνετε ταυτόχρονα, δηλαδή να κάνετε SELECT και UPDATE ταυτόχρονα.
Ας κάνουμε επαναφορά και ας κάνουμε ξανά μια λειτουργία.
Εάν προσπαθήσετε να εκτελέσετε δύο ενημερώσεις ταυτόχρονα στην ίδια σειρά, θα αποκλειστεί. Και θυμηθείτε, είπα ότι ο αναγνώστης δεν μπλοκάρει τον συγγραφέα, αλλά τον συγγραφέα του αναγνώστη, αλλά ένας συγγραφέας μπλοκάρει έναν άλλο συγγραφέα. Δηλαδή, δεν μπορούμε να έχουμε δύο άτομα να ενημερώνουν την ίδια σειρά ταυτόχρονα. Πρέπει να περιμένετε μέχρι να τελειώσει ένα από αυτά.
Και για να το δείξω αυτό, θα κοιτάξω τον πίνακα Lockdemo. Και θα δούμε μια σειρά. Για τη συναλλαγή 698.
Το αναβαθμίσαμε σε 2. Το 699 είναι η πρώτη ενημέρωση. Και ήταν επιτυχής ή βρίσκεται σε εκκρεμή συναλλαγή που περιμένει να δεσμευτούμε ή να ακυρώσουμε.
Αλλά δείτε κάτι άλλο - το 2/51 είναι η πρώτη μας συναλλαγή, η πρώτη μας συνεδρία. Το 3/112 είναι το δεύτερο αίτημα που ήρθε από την κορυφή και άλλαξε αυτήν την τιμή σε 3. Και αν παρατηρήσετε, το επάνω έχει κλειδώσει μόνο του, το οποίο είναι 699. Αλλά το 3/112 δεν έδωσε κλείδωμα. Η στήλη Lock_mode λέει ότι βρίσκεται σε αναμονή. Περιμένει 699. Και αν κοιτάξετε πού είναι το 699, είναι υψηλότερο. Και τι έκανε η πρώτη συνεδρία; Δημιούργησε ένα αποκλειστικό κλείδωμα στο δικό της αναγνωριστικό συναλλαγής. Έτσι το κάνει η Postgres. Αποκλείει το δικό του αναγνωριστικό συναλλαγής. Και αν θέλετε να περιμένετε να δεσμευτεί ή να ακυρωθεί κάποιος, τότε πρέπει να περιμένετε όσο υπάρχει μια εκκρεμή συναλλαγή. Και έτσι μπορούμε να δούμε μια παράξενη γραμμή.
Ας ξανακοιτάξουμε. Στα αριστερά βλέπουμε το αναγνωριστικό επεξεργασίας μας. Στη δεύτερη στήλη βλέπουμε το εικονικό αναγνωριστικό συναλλαγής μας και στην τρίτη βλέπουμε το lock_type. Τι σημαίνει αυτό? Μάλιστα λέει ότι μπλοκάρει το αναγνωριστικό συναλλαγής. Προσέξτε όμως ότι σε όλες τις σειρές στο κάτω μέρος είναι γραμμένη η σχέση. Και έτσι έχετε δύο είδη κλειδαριών στο τραπέζι. Υπάρχει μια κλειδαριά σχέσης. Και επίσης υπάρχει ένα κλείδωμα συναλλαγής όπου κλειδώνουμε μόνοι μας, αυτό ακριβώς συμβαίνει στην πρώτη σειρά ή στο κάτω μέρος όπου η συναλλαγή είναι εκεί που περιμένουμε το 699 να ολοκληρώσει τη λειτουργία του.
Βλέπω τι συμβαίνει εδώ. Και εδώ δύο πράγματα συμβαίνουν ταυτόχρονα. Βλέπετε το κλείδωμα αναγνωριστικού συναλλαγής στην πρώτη σειρά, το οποίο κλειδώνει μόνο του. Και μπλοκάρει τον εαυτό της για να περιμένει τον κόσμο.
Αν κοιτάξετε την 6η γραμμή, είναι η ίδια καταχώρηση με την πρώτη. Και έτσι η συναλλαγή 699 μπλοκάρεται. Το 700 είναι και αυτοκλειδώνοντας. Και μετά στην κάτω σειρά θα δείτε ότι περιμένουμε το 699 να ολοκληρώσει τη λειτουργία του.
Και στο lock_type, πλειάδα βλέπετε αριθμούς.
Μπορείτε να δείτε ότι είναι 0/10. Και αυτός είναι ο αριθμός σελίδας, καθώς και η μετατόπιση αυτής της συγκεκριμένης σειράς.
Και βλέπετε τι γίνεται 0/11 όταν ενημερώνουμε.
Στην πραγματικότητα όμως είναι 0/10, γιατί υπάρχει προσδοκία για αυτή την επέμβαση. Έχουμε την ευκαιρία να δούμε ότι αυτή είναι η σειρά που περιμένω να επιβεβαιώσω.
Μόλις το επιβεβαιώσουμε και πατήσουμε το commit και όταν ολοκληρωθεί η ενημέρωση, αυτό παίρνουμε ξανά. Η συναλλαγή 700 είναι η μόνη κλειδαριά, δεν περιμένει κανέναν άλλον, γιατί δεσμεύτηκε. Απλώς περιμένει να ολοκληρωθεί η συναλλαγή. Μόλις τελειώσει το 699, δεν περιμένουμε τίποτα άλλο. Και τώρα η συναλλαγή 700 λέει ότι όλα είναι καλά, ότι έχει όλες τις κλειδαριές που χρειάζεται σε όλους τους επιτρεπόμενους πίνακες.
Και για να περιπλέκουμε ακόμη περισσότερο το όλο θέμα, δημιουργούμε μια άλλη άποψη, που αυτή τη φορά θα μας παρέχει μια ιεραρχία. Δεν περιμένω να καταλάβετε αυτό το αίτημα. Αλλά θα μας δώσει μια πιο ξεκάθαρη εικόνα του τι συμβαίνει.
Αυτή είναι μια αναδρομική προβολή που έχει επίσης μια ακόμη ενότητα. Και μετά φέρνει τα πάντα ξανά μαζί. Ας το χρησιμοποιήσουμε αυτό.
Τι γίνεται αν κάνουμε τρεις ταυτόχρονες ενημερώσεις και πούμε ότι η σειρά είναι τώρα τρεις. Και θα αλλάξουμε 3 σε 4.
Και εδώ βλέπουμε το 4. Και το αναγνωριστικό συναλλαγής 702.
Και μετά θα ανταλλάξω 4 με 5. Και 5 με 6, και 6 με 7. Και παραθέτω έναν αριθμό ατόμων να περιμένουν να ολοκληρωθεί αυτή η μία συναλλαγή.
Και όλα γίνονται ξεκάθαρα. Ποια είναι η πρώτη σειρά; Αυτό είναι 702. Αυτό είναι το αναγνωριστικό συναλλαγής που όρισε αρχικά αυτήν την τιμή. Τι έχω στη στήλη Χορηγείται; Έχω σημάδια f. Αυτές είναι οι ενημερώσεις μου που (5, 6, 7) δεν μπορούν να εγκριθούν επειδή περιμένουμε να λήξει το αναγνωριστικό συναλλαγής 702. Εκεί έχουμε κλείδωμα αναγνωριστικού συναλλαγής. Και αποδεικνύεται 5 κλειδαριές συναλλαγών ID.
Και αν δεις το 704, στο 705, δεν γράφει τίποτα ακόμα, γιατί δεν ξέρουν τι συμβαίνει ακόμα. Απλώς γράφουν ότι δεν έχουν ιδέα τι συμβαίνει. Και απλώς θα κοιμηθούν, γιατί περιμένουν κάποιον να τελειώσει και θα ξυπνήσουν όταν είναι δυνατόν να αλλάξουν σειρά.
Έτσι φαίνεται. Είναι ξεκάθαρο ότι όλοι περιμένουν τη 12η γραμμή.
Αυτό είδαμε εδώ. Εδώ είναι 0/12.
Έτσι, μόλις εγκριθεί η πρώτη συναλλαγή, μπορείτε να δείτε πώς λειτουργεί η ιεραρχία εδώ. Και τώρα είναι όλα ξεκάθαρα. Γίνονται όλοι καθαροί. Και στην πραγματικότητα περιμένουν ακόμα.
Να τι συμβαίνει. 702 δεσμεύεται. Και τώρα το 703 παίρνει αυτό το κλείδωμα της σειράς, και μετά το 704 αρχίζει να περιμένει το 703 να δεσμευτεί. Και το 705 περιμένει και αυτό. Και όταν ολοκληρωθούν όλα αυτά, αυτοκαθαρίζονται. Και θα ήθελα να επισημάνω ότι όλοι κάνουν ουρά. Και μοιάζει πολύ με την κατάσταση κυκλοφοριακής συμφόρησης όπου όλοι περιμένουν το πρώτο αυτοκίνητο. Το πρώτο αυτοκίνητο έχει σταματήσει και όλοι παρατάσσονται σε μια μεγάλη ουρά. Μετά κινείται, μετά το επόμενο αυτοκίνητο μπορεί να βγει μπροστά και να πάρει το μπλοκ του και ούτω καθεξής.
Και αν σας φάνηκε ότι δεν είναι αρκετά δύσκολο, τότε θα μιλήσουμε τώρα μαζί σας για αδιέξοδα. Δεν ξέρω ποιος από εσάς τα έχετε ζήσει. Αυτό είναι ένα αρκετά κοινό πρόβλημα στα συστήματα βάσεων δεδομένων. Αλλά αδιέξοδα είναι όταν μια συνεδρία περιμένει μια άλλη συνεδρία για να κάνει κάτι. Και εκείνη τη στιγμή μια άλλη συνεδρία περιμένει την πρώτη συνεδρία για να κάνει κάτι.
Και, για παράδειγμα, αν ο Ιβάν πει: «Δώσε μου κάτι», και εγώ του πω: «Όχι, θα σου το δώσω μόνο αν μου δώσεις κάτι άλλο». Και λέει: «Όχι, δεν θα σου το δώσω αν δεν μου το δώσεις». Και καταλήγουμε σε αδιέξοδο. Είμαι σίγουρος ότι ο Ιβάν δεν θα το κάνει αυτό, αλλά καταλαβαίνετε ότι έχουμε δύο άτομα που θέλουν κάτι και δεν είναι έτοιμοι να το δώσουν μέχρι να τους δώσει ο άλλος αυτό που θέλουν. Και δεν υπάρχει λύση.
Και, στην πραγματικότητα, η βάση δεδομένων σας πρέπει να το εντοπίσει. Και μετά πρέπει να διαγράψετε ή να κλείσετε μία από τις συνεδρίες, γιατί διαφορετικά θα παραμείνουν εκεί για πάντα. Και το βλέπουμε σε βάσεις δεδομένων, το βλέπουμε στα λειτουργικά συστήματα. Και σε όλα τα μέρη όπου έχουμε παράλληλες διαδικασίες, αυτό μπορεί να συμβεί.
Και θα βάλουμε δύο αδιέξοδα τώρα. Θα βάλουμε 50 και 80. Στην πρώτη σειρά θα ενημερώσω από το 50 στο 50. Θα πάρω τον αριθμό συναλλαγής 710.
Και μετά θα αλλάξω 80 σε 81 και 50 σε 51.
Και να πώς θα μοιάζει. Και έτσι το 710 έχει ένα κλείδωμα σειράς και το 711 περιμένει επιβεβαίωση. Το είδαμε όταν ενημερώσαμε. 710 - είναι ο ιδιοκτήτης της σειράς μας. Και το 711 περιμένει το 710 για να ολοκληρώσει τη συναλλαγή.
Και μάλιστα λέει σε ποια σειρά έχουμε αδιέξοδα. Και εδώ είναι που αρχίζει να γίνεται περίεργο.
Τώρα ενημερώνουμε το 80 στο 80.
Και εκεί αρχίζουν τα αδιέξοδα. Το 710 περιμένει απάντηση από το 711 και το 711 περιμένει το 710. Και αυτό δεν θα τελειώσει καλά. Και δεν υπάρχει διέξοδος από αυτό. Και θα περιμένουν απάντηση ο ένας από τον άλλον.
Και αρχίζει να καθυστερεί τα πάντα. Και δεν το θέλουμε αυτό.
Και η Postgres έχει τρόπους να παρατηρεί πότε συμβαίνει αυτό. Και όταν συμβεί αυτό, λαμβάνετε αυτό το σφάλμα. Και από αυτό είναι ξεκάθαρο ότι η συγκεκριμένη διαδικασία περιμένει ένα ΚΛΕΙΔΩΜΑ ΚΟΙΝΟΠΟΙΗΣΗΣ από μια άλλη διαδικασία, δηλαδή, η οποία μπλοκάρεται από τη διαδικασία 711. Και αυτή η διαδικασία περίμενε να δοθεί ένα ΚΛΕΙΔΩΜΑ ΚΟΙΝΗΣΗΣ σε ένα τέτοιο αναγνωριστικό συναλλαγής και να αποκλειστεί από μια τέτοια διαδικασία. Επομένως, υπάρχει μια κατάσταση νεκρού αποκλεισμού.
Υπάρχουν τριμερή αδιέξοδα; Είναι δυνατόν? Ναί.
Οδηγούμε αυτούς τους αριθμούς στον πίνακα. Αλλάζουμε 40 σε 40, κάνουμε κλειδαριά.
Αλλαγή 60 σε 61, 80 σε 81.
Και μετά αλλάζουμε 80 και μετά μπουμ!
Και το 714 περιμένει τώρα το 715. Το 716 περιμένει το 715. Και δεν υπάρχει τίποτα να γίνει γι 'αυτό.
Δεν υπάρχουν πια δύο άτομα, υπάρχουν ήδη τρία άτομα. Θέλω κάτι από σένα, αυτό θέλει κάτι από το τρίτο πρόσωπο, και το τρίτο άτομο θέλει κάτι από μένα. Και καταλήγουμε σε μια τριπλή αναμονή γιατί όλοι περιμένουμε να ολοκληρώσει ο άλλος αυτό που πρέπει να κάνει.
Και η Postgres ξέρει σε ποια σειρά συμβαίνει. Και έτσι θα σας δώσει το ακόλουθο μήνυμα που δείχνει ότι έχετε πρόβλημα όπου οι τρεις είσοδοι μπλοκάρουν η μία την άλλη. Και δεν υπάρχουν περιορισμοί. Αυτό μπορεί να συμβαίνει όταν 20 καταχωρήσεις μπλοκάρουν η μία την άλλη.
Το επόμενο τεύχος είναι σειριοποιήσιμο.
Εάν μια ειδική σειριοποιήσιμη κλειδαριά.
Και επιστρέφουμε στο 719. Έχει ένα εντελώς φυσιολογικό θέμα.
Και μπορείτε να πιέσετε για να κάνετε συναλλαγή από σειριοποιήσιμη.
Και καταλαβαίνετε ότι τώρα έχετε ένα διαφορετικό είδος αποκλεισμού SA - αυτό σημαίνει σειριοποιήσιμο.
Και έτσι έχουμε ένα νέο είδος κλειδαριάς που ονομάζεται SARieadLock, το οποίο είναι σειριακό κλείδωμα και σας επιτρέπει να εισάγετε σειριακούς αριθμούς.
Επίσης, μπορείτε να εισαγάγετε μοναδικά ευρετήρια.
Σε αυτόν τον πίνακα έχουμε μοναδικά ευρετήρια.
Οπότε αν βάλω τον αριθμό 2 εδώ, γι' αυτό έχω ένα 2. Αλλά στην κορυφή, έβαλα άλλο 2. Και μπορείτε να δείτε ότι το 721 έχει αποκλειστική κλειδαριά. Τώρα όμως το 722 περιμένει το 721 για να ολοκληρώσει τη λειτουργία του γιατί δεν μπορεί να εισαγάγει το 2 μέχρι να μάθει τι θα γίνει με το 721.
Και αν κάνουμε υποσυναλλαγή.
Εδώ έχουμε 723.
Και αν αποθηκεύσουμε το σημείο και μετά το ενημερώσουμε, τότε λαμβάνουμε νέο αναγνωριστικό συναλλαγής. Αυτή είναι μια άλλη συμπεριφορά που πρέπει να προσέξετε. Εάν το επιστρέψουμε, τότε το αναγνωριστικό συναλλαγής έχει φύγει. Το 724 φεύγει. Αλλά τώρα έχουμε 725.
Και τι προσπαθώ να κάνω εδώ; Προσπαθώ να σας δείξω παραδείγματα ασυνήθιστων κλειδαριών που μπορείτε να βρείτε: είτε πρόκειται για σειριοποιήσιμες κλειδαριές είτε για κλειδαριές SAVEPOINT, αυτά είναι διαφορετικά είδη κλειδαριών που θα εμφανίζονται στον πίνακα κλειδαριών.
Πρόκειται για τη δημιουργία ρητών (ρητά) κλειδαριών, τα οποία έχουν pg_advisory_lock.
Και μπορείτε να δείτε ότι ο τύπος κλειδαριάς αναφέρεται εδώ ως συμβουλευτικός. Και εδώ γράφει "συμβουλευτικό" με κόκκινο. Και μπορείτε να αποκλείσετε ταυτόχρονα με το pg_advisory_unlock.
Και εν κατακλείδι, θα ήθελα να σας δείξω ένα ακόμη συγκλονιστικό πράγμα. Θα δημιουργήσω μια άλλη άποψη. Αλλά θα ενώσω τον πίνακα pg_locks με τον πίνακα pg_stat_activity. Και γιατί θέλω να το κάνω αυτό; Επειδή θα μου επιτρέψει να κοιτάξω και να δω όλες τις τρέχουσες συνεδρίες και να δω τι είδους κλειδαριές περιμένουν. Και είναι αρκετά ενδιαφέρον όταν συνθέτουμε έναν πίνακα κλειδαριάς και έναν πίνακα ερωτήσεων.
Και εδώ δημιουργούμε το pg_stat_view.
Και ενημερώνουμε τη σειρά προς μία. Και εδώ βλέπουμε το 724. Και μετά ενημερώνουμε τη σειρά μας σε τρεις. Και τι βλέπετε εδώ τώρα; Αυτά είναι αιτήματα, δηλαδή βλέπετε ολόκληρη τη λίστα των αιτημάτων που παρατίθενται στην αριστερή στήλη. Στη συνέχεια, στη δεξιά πλευρά μπορείτε να δείτε κλειδαριές και τι δημιουργούν. Και μπορεί να είναι πιο κατανοητό για εσάς, ώστε να μην χρειάζεται να επιστρέφετε σε κάθε συνεδρία κάθε φορά και να βλέπετε αν χρειάζεται να συμμετάσχετε ή όχι. Το κάνουν για εμάς.
Ένα άλλο χαρακτηριστικό που είναι πολύ χρήσιμο είναι pg_blocking_pids. Μάλλον δεν έχετε ακούσει ποτέ για αυτήν. Τι κάνει? Μας επιτρέπει να πούμε ότι για αυτήν την περίοδο λειτουργίας 11740 ποια αναγνωριστικά διεργασίας περιμένει. Και μπορείτε να δείτε ότι το 11740 περιμένει 724. Και το 724 είναι στην κορυφή. Και το 11306 είναι το αναγνωριστικό διεργασίας σας. Ουσιαστικά, αυτή η λειτουργία περνά πάνω από το τραπέζι κλειδαριάς σας. Και ξέρω ότι είναι λίγο περίπλοκο, αλλά καταλαβαίνεις την ιδέα. Ουσιαστικά, αυτή η συνάρτηση περνά από αυτόν τον πίνακα κλειδώματος και προσπαθεί να βρει πού βρίσκεται αυτό το αναγνωριστικό διαδικασίας, δεδομένων των κλειδαριών που περιμένει. Και προσπαθεί επίσης να καταλάβει ποιο αναγνωριστικό διεργασίας έχει η διαδικασία που περιμένει το κλείδωμα. Έτσι μπορείτε να εκτελέσετε αυτήν τη λειτουργία pg_blocking_pids.
Και αυτό είναι πολύ χρήσιμο. Το έχουμε προσθέσει μόνο από την έκδοση 9.6, επομένως αυτή η δυνατότητα είναι μόλις 5 ετών, αλλά είναι πολύ, πολύ χρήσιμη. Και το ίδιο ισχύει και για το δεύτερο αίτημα. Δείχνει ακριβώς αυτό που πρέπει να δούμε.
Για αυτό ήθελα να σας μιλήσω. Και όπως περίμενα, εξαντλήσαμε όλο τον χρόνο μας γιατί υπήρχαν τόσες πολλές διαφάνειες. Και οι διαφάνειες είναι διαθέσιμες για λήψη. Θα ήθελα να σας ευχαριστήσω που είστε εδώ. Είμαι σίγουρος ότι θα απολαύσετε το υπόλοιπο του συνεδρίου, σας ευχαριστώ πολύ!
Ερωτήσεις:
Για παράδειγμα, εάν προσπαθήσω να ενημερώσω τις σειρές και η δεύτερη περίοδος σύνδεσης προσπαθήσει να διαγράψει ολόκληρο τον πίνακα. Απ' όσο καταλαβαίνω θα έπρεπε να υπάρχει κάτι σαν intent lock. Υπάρχει κάτι τέτοιο στο Postgres;
Επιστρέφουμε στην αρχή. Ίσως θυμάστε ότι όταν κάνετε οτιδήποτε, όπως όταν κάνετε μια επιλογή SELECT, εκδίδουμε ένα AccessShareLock. Και αποτρέπει την πτώση του τραπεζιού. Έτσι, εάν, για παράδειγμα, θέλετε να ενημερώσετε μια σειρά σε έναν πίνακα ή να διαγράψετε μια σειρά, τότε κάποιος δεν μπορεί να διαγράψει ολόκληρο τον πίνακα ταυτόχρονα, επειδή κρατάτε αυτό το AccessShareLock σε ολόκληρο τον πίνακα και πάνω από τη σειρά. Και μόλις τελειώσετε, μπορούν να το αφαιρέσουν. Αλλά όσο εσείς αλλάζετε απευθείας κάτι εκεί, δεν θα μπορούν να το κάνουν.
Ας το ξανακάνουμε. Ας προχωρήσουμε στο παράδειγμα διαγραφής. Και βλέπετε πώς η σειρά έχει αποκλειστική κλειδαριά σε ολόκληρο το τραπέζι.
Θα μοιάζει με αποκλειστική κλειδαριά, σωστά;
Ναι, μοιάζει. Καταλαβαίνω για τι πράγμα μιλάς. Λέτε ότι αν κάνω ένα SELECT, τότε έχω ένα ShareExclusive και μετά το βάλω σε κατάσταση Row Exclusive, γίνεται αυτό πρόβλημα; Αλλά παραδόξως αυτό δεν δημιουργεί πρόβλημα. Είναι σαν να αυξάνω τον βαθμό της κλειδαριάς, αλλά ουσιαστικά έχω μια κλειδαριά που εμποδίζει τη διαγραφή της. Και τώρα, όταν κάνω αυτήν την κλειδαριά πιο ισχυρή, εξακολουθεί να αποτρέπει τη διαγραφή. Άρα δεν είναι ότι ανεβαίνω. Δηλ. το εμπόδιζε όταν ήταν και σε χαμηλότερο επίπεδο, οπότε όταν το ανεβάζω, εξακολουθεί να εμποδίζει την πτώση του τραπεζιού.
Καταλαβαίνω για τι πράγμα μιλάς. Δεν υπάρχει περίπτωση να αυξήσετε τον βαθμό αποκλεισμού, όπου προσπαθείτε να εγκαταλείψετε ένα μπλοκ για να εισαγάγετε ένα πιο ισχυρό. Εδώ απλώς αυξάνει αυτή την αποφυγή παντού, οπότε δεν προκαλεί καμία σύγκρουση. Αλλά είναι μια καλή ερώτηση. Ευχαριστώ πολύ που ρωτήσατε!
Τι πρέπει να κάνουμε για να αποφύγουμε μια κατάσταση αδιεξόδου όταν έχουμε πολλές συνεδρίες, μεγάλο αριθμό χρηστών;
Η Postgres παρατηρεί αυτόματα αδιέξοδες καταστάσεις. Και θα διαγράψει αυτόματα μία από τις συνεδρίες. Ο μόνος τρόπος για να αποφύγετε μια κατάσταση αδιεξόδου είναι να μπλοκάρετε τους ανθρώπους με την ίδια σειρά. Όταν λοιπόν κοιτάς την αίτησή σου, είναι συχνά η αιτία αδιεξόδων... Ας πούμε ότι θέλω να μπλοκάρω δύο διαφορετικά πράγματα. Μια εφαρμογή κλειδώνει τον πίνακα 1 και μια άλλη εφαρμογή κλειδώνει τον πίνακα 2 και μετά τον πίνακα 1. Και ο ευκολότερος τρόπος για να αποφύγετε αδιέξοδα είναι να κοιτάξετε την εφαρμογή σας και να προσπαθήσετε να βεβαιωθείτε ότι το κλείδωμα εμφανίζεται με την ίδια σειρά σε όλες τις εφαρμογές. Και αυτό συνήθως αφαιρεί το 80% των προβλημάτων, γιατί κάθε είδους άνθρωποι γράφουν αυτές τις εφαρμογές. Και αν τα μπλοκάρετε με την ίδια σειρά, τότε δεν αντιμετωπίζετε αδιέξοδο.
Σας ευχαριστούμε πολύ για την απόδοσή σας! Μιλήσατε για το vacuum full και, αν καταλαβαίνω καλά, το vacuum full παραμορφώνει τη σειρά των εγγραφών σε ξεχωριστό κατάστημα, άρα κρατά αμετάβλητες τις τρέχουσες εγγραφές. Γιατί το vacuum full έχει αποκλειστική πρόσβαση κλειδώματος και γιατί έρχεται σε αντίθεση με τις λειτουργίες εγγραφής;
Αυτή είναι μια καλή ερώτηση. Ο λόγος είναι ότι το vacuum full παίρνει ένα τραπέζι. Και ουσιαστικά δημιουργούμε μια νέα έκδοση του πίνακα. Και το τραπέζι θα είναι νέο. Αποδεικνύεται ότι θα είναι μια εντελώς νέα έκδοση του πίνακα. Και το πρόβλημα είναι ότι όταν το κάνουμε αυτό, δεν θέλουμε οι άνθρωποι να το διαβάσουν επειδή θέλουμε να δουν τον νέο πίνακα. Και έτσι αυτό συνδέεται με την προηγούμενη ερώτηση. Αν μπορούσαμε να διαβάζουμε ταυτόχρονα, τότε δεν θα μπορούσαμε να το μετακινήσουμε και να κατευθύνουμε τους ανθρώπους σε ένα νέο τραπέζι. Θα πρέπει να περιμένουμε όλοι να ολοκληρώσουν την ανάγνωση αυτού του πίνακα, και έτσι, στην ουσία, πρόκειται για μια αποκλειστική κατάσταση κλειδαριάς.
Απλώς λέμε ότι κλειδώνουμε από την αρχή γιατί ξέρουμε ότι θα χρειαστούμε μια αποκλειστική κλειδαριά στο τέλος, προκειμένου να μεταφερθούν όλοι στο νέο αντίγραφο. Οπότε δυνητικά μπορούμε να το λύσουμε. Και έτσι το κάνουμε με την ταυτόχρονη ευρετηρίαση. Αλλά αυτό είναι πολύ πιο δύσκολο να γίνει. Και αυτό ισχύει πολύ έντονα για την προηγούμενη ερώτησή σας σχετικά με το lock exclusive.
Είναι δυνατή η προσθήκη χρονικού ορίου κλειδώματος στο Postgres; Στην Oracle, μπορώ, για παράδειγμα, να γράψω "επιλογή για ενημέρωση" και να περιμένω 50 δευτερόλεπτα πριν την ενημέρωση. Ήταν καλό για την εφαρμογή. Αλλά στο Postgres, είτε πρέπει να το κάνω αμέσως και να μην περιμένω καθόλου, είτε να περιμένω κάποια στιγμή.
Ναι, μπορείτε να επιλέξετε το χρονικό όριο των κλειδαριών σας, των κλειδαριών σας. Μπορείτε επίσης να εκδώσετε την εντολή no way, η οποία θα είναι ... εάν δεν μπορείτε να πάρετε την κλειδαριά αμέσως. Επομένως, είτε κλείδωμα χρονικού ορίου, είτε κάτι άλλο που θα σας επιτρέψει να το κάνετε αυτό. Αυτό δεν γίνεται σε συντακτικό επίπεδο. Αυτό γίνεται ως μεταβλητή στον διακομιστή. Μερικές φορές δεν μπορεί να χρησιμοποιηθεί.
Μπορείτε να ανοίξετε τη διαφάνεια 75;
Ναι.
Και η ερώτησή μου είναι η επόμενη. Γιατί και οι δύο διαδικασίες ενημέρωσης περιμένουν το 703;
Και αυτό είναι μια μεγάλη ερώτηση. Παρεμπιπτόντως, δεν καταλαβαίνω γιατί το κάνει αυτό η Postgres. Αλλά όταν δημιουργήθηκε το 703, περίμενε το 702. Και όταν εμφανιστούν τα 704 και 705, δεν φαίνεται να ξέρουν τι περιμένουν, γιατί δεν υπάρχει τίποτα ακόμα εκεί. Και η Postgres το κάνει κάπως έτσι: όταν δεν μπορείς να πάρεις κλειδαριά, σου λέει «Τι νόημα έχει να σε επεξεργαστούμε;», γιατί ήδη περιμένεις κάποιον. Απλά αφήστε το λοιπόν να κρέμεται στον αέρα, δεν το ενημερώνει καθόλου. Τι έγινε όμως εδώ; Μόλις το 702 ολοκλήρωσε τη διαδικασία και το 703 έλαβε την κλειδαριά του, το σύστημα επέστρεψε. Και είπε ότι τώρα έχουμε δύο άτομα που περιμένουν. Και μετά ας τα ενημερώσουμε μαζί. Και αναφέρετε ότι αναμένονται και τα δύο.
Δεν ξέρω γιατί το κάνει αυτό η Postgres. Αλλά υπάρχει ένα πρόβλημα που ονομάζεται f…. Μου φαίνεται ότι αυτός δεν είναι όρος στα ρωσικά. Αυτό συμβαίνει όταν όλοι περιμένουν ένα κάστρο, ακόμα κι αν υπάρχουν 20 περιπτώσεις που περιμένουν το κάστρο. Και ξαφνικά ξυπνούν όλοι την ίδια ώρα. Και όλοι αρχίζουν να προσπαθούν να αντιδράσουν. Αλλά το σύστημα το κάνει έτσι ώστε όλοι να περιμένουν το 703. Γιατί όλοι περιμένουν, και θα τους βάλουμε αμέσως στη σειρά. Και αν εμφανιστεί οποιοδήποτε άλλο νέο αίτημα που σχηματίστηκε μετά από αυτό, για παράδειγμα, 707, τότε θα υπάρξει και πάλι κενό.
Και μου φαίνεται ότι αυτό γίνεται για να μπορώ να πω ότι σε αυτό το στάδιο το 702 περιμένει το 703 και όσοι έρθουν μετά δεν θα έχουν καμία είσοδο σε αυτό το πεδίο. Μόλις όμως φύγει ο πρώτος σερβιτόρος και όλοι όσοι περίμεναν εκείνη τη στιγμή πριν από την ενημέρωση, λαμβάνουν το ίδιο διακριτικό. Και έτσι μου φαίνεται ότι αυτό γίνεται για να μπορέσουμε να επεξεργαστούμε με τη σειρά, ώστε να παραγγελθούν σωστά.
Πάντα το έβλεπα ως ένα μάλλον περίεργο φαινόμενο. Γιατί εδώ, για παράδειγμα, δεν αναγράφονται καθόλου. Αλλά, μου φαίνεται, κάθε φορά που δίνουμε μια νέα κλειδαριά, κοιτάμε όλους εκείνους που βρίσκονται σε διαδικασία αναμονής. Έπειτα τα στοιχίζουμε όλα. Και στη συνέχεια, όποιο νέο μπαίνει μπαίνει στην ουρά μόνο όταν το επόμενο άτομο έχει ολοκληρώσει την επεξεργασία. Πολύ καλή ερώτηση. Σας ευχαριστώ πολύ για την ερώτησή σας!
Μου φαίνεται πολύ πιο λογικό όταν το 705 περιμένει 704.
Το πρόβλημα όμως εδώ είναι το εξής. Τεχνικά, μπορείτε να ξυπνήσετε είτε ένα είτε εκείνο. Και έτσι ξυπνάμε το ένα ή το άλλο. Τι συμβαίνει όμως στη λειτουργία του συστήματος; Μπορείτε να δείτε πώς το 703 στην κορυφή έχει μπλοκάρει το δικό του αναγνωριστικό συναλλαγής. Έτσι λειτουργεί η Postgres. Και το 703 μπλοκάρεται από το δικό του αναγνωριστικό συναλλαγής, οπότε αν κάποιος θέλει να περιμένει, τότε θα περιμένει το 703. Και, στην πραγματικότητα, το 703 ολοκληρώνεται. Και μόνο μετά την ολοκλήρωσή του, μια από τις διαδικασίες ξυπνά. Και δεν ξέρουμε τι είδους διαδικασία θα είναι. Στη συνέχεια επεξεργαζόμαστε σταδιακά τα πάντα. Αλλά δεν είναι σαφές ποια διαδικασία ξυπνά πρώτη, γιατί θα μπορούσε να είναι οποιαδήποτε από αυτές τις διαδικασίες. Στην ουσία, είχαμε έναν χρονοπρογραμματιστή που έλεγε ότι μπορούμε πλέον να ξυπνήσουμε οποιαδήποτε από αυτές τις διαδικασίες. Απλώς επιλέγουμε ένα τυχαία. Επομένως, πρέπει να σημειωθούν και τα δύο, γιατί μπορούμε να ξυπνήσουμε οποιονδήποτε από αυτούς.
Και το πρόβλημα είναι ότι έχουμε CP-άπειρο. Και επομένως, είναι πολύ πιθανό να μπορέσουμε να ξυπνήσουμε τον αργότερα. Και αν, για παράδειγμα, ξυπνήσουμε αργότερα, τότε θα περιμένουμε αυτόν που μόλις έλαβε την κλειδαριά, οπότε δεν καθορίζουμε ποιος ακριβώς θα ξυπνήσει πρώτος. Δημιουργούμε ακριβώς μια τέτοια κατάσταση και το σύστημα θα τους ξυπνήσει τυχαία.
Υπάρχει . Κοίτα, είναι επίσης ενδιαφέροντα και χρήσιμα. Το θέμα είναι, φυσικά, τρομερά σύνθετο. Ευχαριστώ πολύ Bruce!
Πηγή: www.habr.com