Η έκθεση παρουσιάζει ορισμένες προσεγγίσεις που επιτρέπουν παρακολουθεί την απόδοση των ερωτημάτων SQL όταν υπάρχουν εκατομμύρια από αυτά την ημέρα, και υπάρχουν εκατοντάδες διακομιστές PostgreSQL που παρακολουθούνται.
Ποιες τεχνικές λύσεις μας επιτρέπουν να επεξεργαζόμαστε αποτελεσματικά έναν τέτοιο όγκο πληροφοριών και πώς αυτό διευκολύνει τη ζωή ενός συνηθισμένου προγραμματιστή;
Ποιος ενδιαφέρεται; ανάλυση συγκεκριμένων προβλημάτων και διάφορες τεχνικές βελτιστοποίησης Ερωτήματα SQL και επίλυση τυπικών προβλημάτων DBA στο PostgreSQL - μπορείτε επίσης σχετικά με το θέμα αυτό.
Το όνομά μου είναι Kirill Borovikov, εκπροσωπώ . Συγκεκριμένα, ειδικεύομαι στην εργασία με βάσεις δεδομένων στην εταιρεία μας.
Σήμερα θα σας πω πώς βελτιστοποιούμε τα ερωτήματα, όταν δεν χρειάζεται να "διαχωρίσετε" την απόδοση ενός μεμονωμένου ερωτήματος, αλλά να λύσετε το πρόβλημα μαζικά. Όταν υπάρχουν εκατομμύρια αιτήματα και πρέπει να βρείτε μερικά προσεγγίσεις για τη λύση αυτό το μεγάλο πρόβλημα.
Σε γενικές γραμμές, το Tensor για ένα εκατομμύριο από τους πελάτες μας είναι : εταιρικό κοινωνικό δίκτυο, λύσεις για επικοινωνία βίντεο, για εσωτερική και εξωτερική ροή εγγράφων, λογιστικά συστήματα για λογιστικά και αποθήκες,... Δηλαδή, ένας τέτοιος «mega-combine» για ολοκληρωμένη διαχείριση επιχειρήσεων, στον οποίο υπάρχουν περισσότερα από 100 διαφορετικά εσωτερικά έργα.
Για να διασφαλίσουμε ότι όλα λειτουργούν και αναπτύσσονται κανονικά, έχουμε 10 αναπτυξιακά κέντρα σε όλη τη χώρα, με περισσότερα σε αυτά 1000 προγραμματιστές.
Δουλεύουμε με την PostgreSQL από το 2008 και έχουμε συγκεντρώσει μεγάλο αριθμό όσων επεξεργαζόμαστε - δεδομένα πελατών, στατιστικά, αναλυτικά, δεδομένα από εξωτερικά συστήματα πληροφοριών - περισσότερα από 400 TB. Υπάρχουν περίπου 250 διακομιστές μόνο στην παραγωγή, και συνολικά υπάρχουν περίπου 1000 διακομιστές βάσεων δεδομένων που παρακολουθούμε.
Η SQL είναι μια δηλωτική γλώσσα. Δεν περιγράφετε «πώς» κάτι πρέπει να λειτουργεί, αλλά «τι» θέλετε να πετύχετε. Το DBMS γνωρίζει καλύτερα πώς να κάνει ένα JOIN - πώς να συνδέσετε τα τραπέζια σας, ποιες προϋποθέσεις να επιβάλετε, τι θα περάσει από το ευρετήριο, τι δεν θα...
Ορισμένα DBMS δέχονται συμβουλές: "Όχι, συνδέστε αυτούς τους δύο πίνακες σε μια τέτοια ουρά", αλλά η PostgreSQL δεν μπορεί να το κάνει αυτό. Αυτή είναι η συνειδητή θέση των κορυφαίων προγραμματιστών: «Προτιμούμε να ολοκληρώσουμε το πρόγραμμα βελτιστοποίησης ερωτημάτων παρά να επιτρέψουμε στους προγραμματιστές να χρησιμοποιούν κάποιου είδους υποδείξεις».
Όμως, παρά το γεγονός ότι η PostgreSQL δεν επιτρέπει στο «έξω» να ελέγχει τον εαυτό του, το επιτρέπει απόλυτα δείτε τι συμβαίνει μέσα τουόταν εκτελείτε το ερώτημά σας και πού αντιμετωπίζει προβλήματα.
Γενικά, ποια κλασικά προβλήματα αντιμετωπίζει συνήθως ένας προγραμματιστής [σε ένα DBA]; «Εδώ εκπληρώσαμε το αίτημα και όλα είναι αργά μαζί μας, όλα κρέμονται, κάτι συμβαίνει... Κάποιος μπελάς!».
Οι λόγοι είναι σχεδόν πάντα οι ίδιοι:
- αναποτελεσματικός αλγόριθμος ερωτημάτων
Προγραμματιστής: «Τώρα του δίνω 10 πίνακες σε SQL μέσω JOIN...» - και αναμένει ότι οι συνθήκες του θα «λυθούν» αποτελεσματικά από θαύμα και θα τα πάρει όλα γρήγορα. Αλλά θαύματα δεν συμβαίνουν και οποιοδήποτε σύστημα με τέτοια μεταβλητότητα (10 πίνακες σε έναν FROM) δίνει πάντα κάποιου είδους σφάλμα. [] - άσχετα στατιστικά στοιχεία
Αυτό το σημείο είναι πολύ σχετικό ειδικά για την PostgreSQL, όταν "χύσατε" ένα μεγάλο σύνολο δεδομένων στον διακομιστή, υποβάλετε ένα αίτημα και αυτό "εξαρθρώνει" το tablet σας. Επειδή χθες υπήρχαν 10 εγγραφές σε αυτό, και σήμερα υπάρχουν 10 εκατομμύρια, αλλά η PostgreSQL δεν το γνωρίζει ακόμη και πρέπει να το πούμε. [] - «βύσμα» στους πόρους
Έχετε εγκαταστήσει μια μεγάλη και πολύ φορτωμένη βάση δεδομένων σε έναν αδύναμο διακομιστή που δεν έχει αρκετή απόδοση δίσκου, μνήμης ή επεξεργαστή. Και αυτό είναι όλο... Κάπου υπάρχει ένα ταβάνι απόδοσης πάνω από το οποίο δεν μπορείς πλέον να πηδήξεις. - μπλοκάρισμα
Αυτό είναι ένα δύσκολο σημείο, αλλά είναι πιο σχετικά με διάφορα ερωτήματα τροποποίησης (INSERT, UPDATE, DELETE) - αυτό είναι ένα ξεχωριστό μεγάλο θέμα.
Λήψη σχεδίου
...Και για όλα τα άλλα εμείς χρειάζεται ένα σχέδιο! Πρέπει να δούμε τι συμβαίνει μέσα στον διακομιστή.
Ένα σχέδιο εκτέλεσης ερωτήματος για την PostgreSQL είναι ένα δέντρο του αλγόριθμου εκτέλεσης ερωτήματος στην αναπαράσταση κειμένου. Είναι ακριβώς ο αλγόριθμος που, ως αποτέλεσμα της ανάλυσης του σχεδιαστή, βρέθηκε να είναι ο πιο αποτελεσματικός.
Κάθε κόμβος δέντρου είναι μια λειτουργία: ανάκτηση δεδομένων από πίνακα ή ευρετήριο, δημιουργία bitmap, ένωση δύο πινάκων, ένωση, διασταύρωση ή εξαίρεση επιλογών. Η εκτέλεση ενός ερωτήματος περιλαμβάνει το περπάτημα στους κόμβους αυτού του δέντρου.
Για να λάβετε το σχέδιο ερωτήματος, ο ευκολότερος τρόπος είναι να εκτελέσετε τη δήλωση EXPLAIN. Για να αποκτήσετε όλα τα πραγματικά χαρακτηριστικά, δηλαδή να εκτελέσετε πραγματικά ένα ερώτημα στη βάση - EXPLAIN (ANALYZE, BUFFERS) SELECT ....
Το κακό μέρος: όταν το εκτελείτε, συμβαίνει "εδώ και τώρα", επομένως είναι κατάλληλο μόνο για τοπικό εντοπισμό σφαλμάτων. Εάν πάρετε έναν διακομιστή με μεγάλη φόρτωση που βρίσκεται υπό έντονη ροή δεδομένων, αλλάζει και βλέπετε: "Ω! Εδώ έχουμε μια αργή εκτέλεσηsya αίτηση." Πριν από μισή ώρα, μία ώρα - ενώ εκτελούσατε και λαμβάνατε αυτό το αίτημα από τα αρχεία καταγραφής, το επαναφέρατε στον διακομιστή, άλλαξαν ολόκληρο το σύνολο δεδομένων και τα στατιστικά στοιχεία σας. Το τρέχετε για εντοπισμό σφαλμάτων - και εκτελείται γρήγορα! Και δεν μπορείς να καταλάβεις γιατί, γιατί ήταν αργά.
Για να καταλάβουμε τι ακριβώς συνέβη τη στιγμή που το αίτημα εκτελέστηκε στον διακομιστή, έγραψαν οι έξυπνοι άνθρωποι . Υπάρχει σχεδόν σε όλες τις πιο κοινές διανομές PostgreSQL και μπορεί απλά να ενεργοποιηθεί στο αρχείο διαμόρφωσης.
Εάν αντιληφθεί ότι κάποιο αίτημα εκτελείται περισσότερο από το όριο που του είπατε, το κάνει «στιγμιότυπο» του σχεδίου αυτού του αιτήματος και τα γράφει μαζί στο αρχείο καταγραφής.
Όλα φαίνονται να είναι καλά τώρα, πάμε στο ημερολόγιο και βλέπουμε εκεί... [κείμενο ποδήλατο]. Αλλά δεν μπορούμε να πούμε τίποτα γι 'αυτό, εκτός από το γεγονός ότι είναι ένα εξαιρετικό σχέδιο επειδή χρειάστηκαν 11 ms για να εκτελεστεί.
Όλα φαίνονται να είναι καλά - αλλά τίποτα δεν είναι ξεκάθαρο τι πραγματικά συνέβη. Εκτός από τη γενική ώρα, δεν βλέπουμε τίποτα πραγματικά. Επειδή το να βλέπεις ένα τέτοιο «αρνί» απλού κειμένου γενικά δεν είναι οπτικό.
Αλλά ακόμα κι αν δεν είναι προφανές, ακόμα κι αν είναι άβολο, υπάρχουν πιο θεμελιώδη προβλήματα:
- Ο κόμβος υποδεικνύει άθροισμα πόρων ολόκληρου του υποδέντρου κάτω από αυτόν. Δηλαδή, δεν μπορείτε απλώς να μάθετε πόσος χρόνος ξοδεύτηκε σε αυτήν τη συγκεκριμένη σάρωση ευρετηρίου εάν υπάρχει κάποια ένθετη κατάσταση κάτω από αυτήν. Πρέπει να κοιτάξουμε δυναμικά για να δούμε αν υπάρχουν «παιδιά» και μεταβλητές υπό όρους, CTE μέσα - και να αφαιρέσουμε όλα αυτά «στο μυαλό μας».
- Δεύτερο σημείο: η ώρα που υποδεικνύεται στον κόμβο είναι χρόνος εκτέλεσης ενός κόμβου. Εάν αυτός ο κόμβος εκτελέστηκε ως αποτέλεσμα, για παράδειγμα, ενός βρόχου μέσω εγγραφών πίνακα πολλές φορές, τότε ο αριθμός των βρόχων - κύκλοι αυτού του κόμβου - αυξάνεται στο σχέδιο. Αλλά ο ίδιος ο χρόνος ατομικής εκτέλεσης παραμένει ίδιος ως προς το σχέδιο. Δηλαδή, για να καταλάβετε πόσο καιρό εκτελέστηκε συνολικά αυτός ο κόμβος, πρέπει να πολλαπλασιάσετε ένα πράγμα με ένα άλλο - και πάλι, "στο κεφάλι σας".
Σε τέτοιες περιπτώσεις, κατανοήστε «Ποιος είναι ο πιο αδύναμος κρίκος;» σχεδόν αδύνατον. Επομένως, ακόμη και οι ίδιοι οι προγραμματιστές γράφουν στο "εγχειρίδιο" ότι "Η κατανόηση ενός σχεδίου είναι μια τέχνη που πρέπει να μάθεις, να βιώσεις...".
Αλλά έχουμε 1000 προγραμματιστές και δεν μπορείτε να μεταφέρετε αυτήν την εμπειρία σε καθέναν από αυτούς. Εγώ, εσύ, ξέρει, αλλά κάποιος εκεί πέρα δεν ξέρει πια. Ίσως θα μάθει, ή ίσως όχι, αλλά πρέπει να δουλέψει τώρα - και πού θα αποκτούσε αυτή την εμπειρία;
Οπτικοποίηση σχεδίου
Επομένως, συνειδητοποιήσαμε ότι για να αντιμετωπίσουμε αυτά τα προβλήματα, χρειαζόμαστε καλή οπτικοποίηση του σχεδίου.
Πρώτα περάσαμε "μέσα από την αγορά" - ας κοιτάξουμε στο Διαδίκτυο για να δούμε τι υπάρχει ακόμη.
Αλλά αποδείχθηκε ότι υπάρχουν πολύ λίγες σχετικά «ζωντανές» λύσεις που λίγο πολύ αναπτύσσονται - κυριολεκτικά, μόνο μία: του Hubert Lubaczewski. Όταν εισάγετε στο πεδίο "τροφοδοσία" μια αναπαράσταση κειμένου του σχεδίου, σας εμφανίζει έναν πίνακα με τα αναλυμένα δεδομένα:
- ο χρόνος επεξεργασίας του ίδιου του κόμβου
- συνολικός χρόνος για ολόκληρο το υποδέντρο
- αριθμός εγγραφών που ανακτήθηκαν και ήταν στατιστικά αναμενόμενοι
- το ίδιο το σώμα του κόμβου
Αυτή η υπηρεσία έχει επίσης τη δυνατότητα κοινής χρήσης ενός αρχείου συνδέσμων. Έριξες το σχέδιό σου εκεί και είπες: «Γεια, Βάσια, ορίστε ένας σύνδεσμος, κάτι δεν πάει καλά εκεί».
Υπάρχουν όμως και μικρά προβλήματα.
Πρώτον, μια τεράστια ποσότητα "copy-paste". Παίρνεις ένα κομμάτι από το κούτσουρο, το κολλάς εκεί μέσα και ξανά και ξανά.
Δεύτερον, η καμία ανάλυση του όγκου των δεδομένων που διαβάζονται — τα ίδια buffers με την έξοδο EXPLAIN (ANALYZE, BUFFERS), δεν το βλέπουμε εδώ. Απλώς δεν ξέρει πώς να τα αποσυναρμολογήσει, να τα καταλάβει και να συνεργαστεί μαζί τους. Όταν διαβάζετε πολλά δεδομένα και συνειδητοποιείτε ότι μπορεί να κάνετε λάθος κατανομή του δίσκου και της κρυφής μνήμης, αυτές οι πληροφορίες είναι πολύ σημαντικές.
Το τρίτο αρνητικό σημείο είναι η πολύ αδύναμη εξέλιξη αυτού του έργου. Οι δεσμεύσεις είναι πολύ μικρές, είναι καλό μια φορά κάθε έξι μήνες και ο κωδικός είναι σε Perl.
Αλλά όλα αυτά είναι «στίχοι», θα μπορούσαμε με κάποιο τρόπο να ζήσουμε με αυτό, αλλά υπάρχει ένα πράγμα που μας απομάκρυνε πολύ από αυτήν την υπηρεσία. Αυτά είναι σφάλματα στην ανάλυση της κοινής έκφρασης πίνακα (CTE) και διαφόρων δυναμικών κόμβων όπως το InitPlan/SubPlan.
Εάν πιστεύετε αυτή την εικόνα, τότε ο συνολικός χρόνος εκτέλεσης κάθε μεμονωμένου κόμβου είναι μεγαλύτερος από τον συνολικό χρόνο εκτέλεσης ολόκληρου του αιτήματος. Είναι απλό - ο χρόνος δημιουργίας αυτού του CTE δεν αφαιρέθηκε από τον κόμβο σάρωσης CTE. Ως εκ τούτου, δεν γνωρίζουμε πλέον τη σωστή απάντηση στο πόσο χρόνο κράτησε η ίδια η σάρωση CTE.
Τότε καταλάβαμε ότι ήρθε η ώρα να γράψουμε τα δικά μας - ρε! Κάθε προγραμματιστής λέει: "Τώρα θα γράψουμε τα δικά μας, θα είναι πολύ εύκολο!"
Πήραμε μια τυπική στοίβα για υπηρεσίες web: έναν πυρήνα που βασίζεται στο Node.js + Express, χρησιμοποιήσαμε το Bootstrap και το D3.js για όμορφα διαγράμματα. Και οι προσδοκίες μας δικαιώθηκαν πλήρως - λάβαμε το πρώτο πρωτότυπο σε 2 εβδομάδες:
- προσαρμοσμένο πρόγραμμα ανάλυσης
Δηλαδή, τώρα μπορούμε να αναλύσουμε οποιοδήποτε σχέδιο από αυτά που δημιουργούνται από την PostgreSQL. - σωστή ανάλυση των δυναμικών κόμβων - Σάρωση CTE, InitPlan, SubPlan
- ανάλυση της κατανομής των buffers - όπου διαβάζονται σελίδες δεδομένων από τη μνήμη, όπου από την τοπική κρυφή μνήμη, όπου από το δίσκο
- πήρε σαφήνεια
Για να μην τα «σκάψετε» όλα αυτά στο ημερολόγιο, αλλά για να δείτε αμέσως τον «αδύναμο κρίκο» στην εικόνα.
Έχουμε κάτι τέτοιο, με την επισήμανση σύνταξης που περιλαμβάνεται. Αλλά συνήθως οι προγραμματιστές μας δεν λειτουργούν πλέον με μια πλήρη αναπαράσταση του σχεδίου, αλλά με μια συντομότερη. Εξάλλου, έχουμε ήδη αναλύσει όλους τους αριθμούς και τους πετάμε δεξιά και αριστερά, και στη μέση αφήσαμε μόνο την πρώτη γραμμή, τι είδους κόμβος είναι: CTE Scan, CTE γενιά ή Seq Scan σύμφωνα με κάποιο σημάδι.
Αυτή είναι η συντομευμένη παράσταση που ονομάζουμε πρότυπο σχεδίου.
Τι άλλο θα ήταν βολικό; Θα ήταν βολικό να δούμε ποιο μερίδιο του συνολικού μας χρόνου κατανέμεται σε ποιον κόμβο - και απλώς «κολλήστε το» στο πλάι διάγραμμα πίτας.
Δείχνουμε τον κόμβο και βλέπουμε - αποδεικνύεται ότι η Seq Scan πήρε λιγότερο από το ένα τέταρτο του συνολικού χρόνου και τα υπόλοιπα 3/4 λήφθηκαν από το CTE Scan. Φρίκη! Αυτή είναι μια μικρή σημείωση σχετικά με τον "ρυθμό πυροδότησης" του CTE Scan εάν τα χρησιμοποιείτε ενεργά στα ερωτήματά σας. Δεν είναι πολύ γρήγορα - είναι κατώτερα ακόμη και από την κανονική σάρωση τραπεζιού.
Συνήθως, όμως, τέτοια διαγράμματα είναι πιο ενδιαφέροντα, πιο σύνθετα, όταν δείχνουμε αμέσως ένα τμήμα και βλέπουμε, για παράδειγμα, ότι περισσότερες από τις μισές φορές κάποια Seq Scan «έφαγε». Επιπλέον, υπήρχε κάποιο είδος φίλτρου μέσα, πολλά αρχεία απορρίφθηκαν σύμφωνα με αυτό... Μπορείτε να ρίξετε απευθείας αυτήν την εικόνα στον προγραμματιστή και να πείτε: «Βάσια, όλα είναι άσχημα εδώ για σένα! Βρείτε το, κοιτάξτε - κάτι δεν πάει καλά!».
Φυσικά, υπήρξαν κάποιες «τσούγκρες» που εμπλέκονται.
Το πρώτο πράγμα που συναντήσαμε ήταν το πρόβλημα στρογγυλοποίησης. Ο χρόνος κάθε μεμονωμένου κόμβου στο σχέδιο υποδεικνύεται με ακρίβεια 1 μs. Και όταν ο αριθμός των κύκλων κόμβων υπερβαίνει, για παράδειγμα, 1000 - μετά την εκτέλεση PostgreSQL διαιρείται "εντός της ακρίβειας", τότε κατά τον υπολογισμό πίσω παίρνουμε τον συνολικό χρόνο "κάπου μεταξύ 0.95ms και 1.05ms". Όταν η καταμέτρηση πηγαίνει στα μικροδευτερόλεπτα, αυτό είναι εντάξει, αλλά όταν είναι ήδη [χιλιοστά]δευτερόλεπτα, πρέπει να λάβετε υπόψη αυτές τις πληροφορίες όταν «λύνετε» πόρους στους κόμβους του σχεδίου «ποιος κατανάλωσε πόσο».
Το δεύτερο σημείο, πιο περίπλοκο, είναι η κατανομή των πόρων (αυτών των buffers) μεταξύ των δυναμικών κόμβων. Αυτό μας κόστισε τις πρώτες 2 εβδομάδες του πρωτοτύπου συν άλλες 4 εβδομάδες.
Είναι πολύ εύκολο να αντιμετωπίσουμε αυτό το είδος προβλήματος - κάνουμε ένα CTE και υποτίθεται ότι διαβάζουμε κάτι σε αυτό. Στην πραγματικότητα, η PostgreSQL είναι «έξυπνη» και δεν διαβάζει τίποτα απευθείας εκεί. Στη συνέχεια παίρνουμε τον πρώτο δίσκο από αυτό και σε αυτόν τον εκατόν πρώτο από το ίδιο CTE.
Εξετάζουμε το σχέδιο και καταλαβαίνουμε - είναι περίεργο, έχουμε 3 buffer (σελίδες δεδομένων) που «καταναλώνονται» στη σάρωση Seq, 1 ακόμη στη σάρωση CTE και 2 ακόμη στη δεύτερη σάρωση CTE. Δηλαδή, αν απλά τα συνοψίσουμε όλα, θα πάρουμε 6, αλλά από το tablet διαβάζουμε μόνο 3! Το CTE Scan δεν διαβάζει τίποτα από πουθενά, αλλά λειτουργεί απευθείας με τη μνήμη διεργασιών. Δηλαδή, κάτι δεν πάει καλά εδώ!
Πράγματι, αποδεικνύεται ότι εδώ είναι όλες εκείνες οι 3 σελίδες δεδομένων που ζητήθηκαν από το Seq Scan, πρώτα ζήτησε η 1η σάρωση CTE και μετά η 1η και του διαβάστηκαν άλλες 2. Δηλαδή συνολικά Δεδομένα διαβάστηκαν 2 σελίδες, όχι 3.
Και αυτή η εικόνα μας οδήγησε στο να καταλάβουμε ότι η εκτέλεση ενός σχεδίου δεν είναι πλέον ένα δέντρο, αλλά απλώς ένα είδος άκυκλου γραφήματος. Και πήραμε ένα διάγραμμα σαν αυτό, ώστε να καταλάβουμε "τι προήλθε από πού αρχικά". Δηλαδή, εδώ δημιουργήσαμε ένα CTE από το pg_class, και το ζητήσαμε δύο φορές, και σχεδόν όλος ο χρόνος μας ξοδεύτηκε στο υποκατάστημα όταν το ζητήσαμε τη 2η φορά. Είναι σαφές ότι η ανάγνωση της 101ης καταχώρισης είναι πολύ πιο ακριβή από την απλή ανάγνωση της 1ης καταχώρισης από το tablet.
Εκπνεύσαμε για λίγο. Είπαν: «Τώρα, Νέο, ξέρεις κουνγκ φου! Τώρα η εμπειρία μας βρίσκεται ακριβώς στην οθόνη σας. Τώρα μπορείτε να το χρησιμοποιήσετε».
Ενοποίηση ημερολογίου
Οι 1000 προγραμματιστές μας ανέπνευσαν με ανακούφιση. Αλλά καταλάβαμε ότι έχουμε μόνο εκατοντάδες διακομιστές "μάχης" και όλο αυτό το "copy-paste" από την πλευρά των προγραμματιστών δεν είναι καθόλου βολικό. Καταλάβαμε ότι έπρεπε να το μαζέψουμε μόνοι μας.
Γενικά, υπάρχει μια τυπική ενότητα που μπορεί να συλλέγει στατιστικά στοιχεία, ωστόσο, πρέπει επίσης να ενεργοποιηθεί στη διαμόρφωση - αυτό . Αλλά δεν μας ταίριαζε.
Πρώτον, εκχωρεί στα ίδια ερωτήματα χρησιμοποιώντας διαφορετικά σχήματα στην ίδια βάση δεδομένων διαφορετικά QueryIds. Δηλαδή, αν το κάνεις πρώτα SET search_path = '01'; SELECT * FROM user LIMIT 1;, και μετά SET search_path = '02'; και το ίδιο αίτημα, τότε τα στατιστικά στοιχεία αυτής της ενότητας θα έχουν διαφορετικές εγγραφές και δεν θα μπορώ να συλλέξω γενικά στατιστικά στοιχεία ειδικά στο πλαίσιο αυτού του προφίλ αιτήματος, χωρίς να λάβω υπόψη τα σχήματα.
Το δεύτερο σημείο που μας εμπόδισε να το χρησιμοποιήσουμε είναι έλλειψη σχεδίων. Δηλαδή δεν υπάρχει σχέδιο, υπάρχει μόνο το ίδιο το αίτημα. Βλέπουμε τι επιβραδύνθηκε, αλλά δεν καταλαβαίνουμε γιατί. Και εδώ επιστρέφουμε στο πρόβλημα ενός ταχέως μεταβαλλόμενου δεδομένων.
Και η τελευταία στιγμή - έλλειψη «γεγονότων». Δηλαδή, δεν μπορείτε να αντιμετωπίσετε μια συγκεκριμένη περίπτωση εκτέλεσης ερωτήματος - δεν υπάρχει, υπάρχουν μόνο συγκεντρωτικά στατιστικά στοιχεία. Αν και είναι δυνατό να δουλέψεις με αυτό, είναι απλώς πολύ δύσκολο.
Ως εκ τούτου, αποφασίσαμε να πολεμήσουμε το copy-paste και αρχίσαμε να γράφουμε συλλέκτη.
Ο συλλέκτης συνδέεται μέσω SSH, δημιουργεί μια ασφαλή σύνδεση με τον διακομιστή με τη βάση δεδομένων χρησιμοποιώντας ένα πιστοποιητικό και tail -F "κολλάει" σε αυτό στο αρχείο καταγραφής. Σε αυτή τη συνεδρία λοιπόν παίρνουμε έναν πλήρη «καθρέφτη» ολόκληρου του αρχείου καταγραφής, που δημιουργεί ο διακομιστής. Το φορτίο στον ίδιο τον διακομιστή είναι ελάχιστο, επειδή δεν αναλύουμε τίποτα εκεί, απλώς αντικατοπτρίζουμε την κίνηση.
Εφόσον είχαμε ήδη αρχίσει να γράφουμε τη διεπαφή στο Node.js, συνεχίσαμε να γράφουμε τον συλλέκτη σε αυτό. Και αυτή η τεχνολογία έχει δικαιολογηθεί, επειδή είναι πολύ βολικό να χρησιμοποιείτε JavaScript για να εργαστείτε με δεδομένα κειμένου ασθενώς μορφοποιημένα, που είναι το αρχείο καταγραφής. Και η ίδια η υποδομή Node.js ως πλατφόρμα υποστήριξης σάς επιτρέπει να εργάζεστε εύκολα και άνετα με συνδέσεις δικτύου, και μάλιστα με οποιεσδήποτε ροές δεδομένων.
Αντίστοιχα, "τεντώνουμε" δύο συνδέσεις: την πρώτη για να "ακούμε" το ίδιο το κούτσουρο και να το παίρνουμε στον εαυτό μας και η δεύτερη να ρωτάμε περιοδικά τη βάση. "Αλλά το αρχείο καταγραφής δείχνει ότι το σύμβολο με το oid 123 είναι αποκλεισμένο", αλλά αυτό δεν σημαίνει τίποτα για τον προγραμματιστή και θα ήταν ωραίο να ρωτήσετε τη βάση δεδομένων, "Τι είναι ούτως ή άλλως το OID = 123;" Και έτσι ρωτάμε περιοδικά τη βάση αυτό που δεν γνωρίζουμε ακόμη για τον εαυτό μας.
«Υπάρχει μόνο ένα πράγμα που δεν λάβατε υπόψη, υπάρχει ένα είδος μελισσών που μοιάζει με ελέφαντα!...» Ξεκινήσαμε να αναπτύσσουμε αυτό το σύστημα όταν θέλαμε να παρακολουθήσουμε 10 διακομιστές. Το πιο κρίσιμο κατά την κατανόησή μας, όπου προέκυψαν ορισμένα προβλήματα που ήταν δύσκολο να αντιμετωπιστούν. Αλλά κατά τη διάρκεια του πρώτου τριμήνου, λάβαμε εκατό για παρακολούθηση - επειδή το σύστημα λειτουργούσε, όλοι το ήθελαν, όλοι ήταν άνετοι.
Όλα αυτά πρέπει να προστεθούν, η ροή δεδομένων είναι μεγάλη και ενεργή. Στην πραγματικότητα, αυτό που παρακολουθούμε, αυτό που μπορούμε να αντιμετωπίσουμε, είναι αυτό που χρησιμοποιούμε. Χρησιμοποιούμε επίσης την PostgreSQL ως αποθήκευση δεδομένων. Και τίποτα δεν είναι πιο γρήγορο για να "χυθεί" δεδομένα σε αυτό από τον χειριστή COPY Οχι ακόμα.
Αλλά η απλή «έκχυση» δεδομένων δεν είναι στην πραγματικότητα η τεχνολογία μας. Διότι αν έχετε περίπου 50 χιλιάδες αιτήματα ανά δευτερόλεπτο σε εκατό διακομιστές, τότε αυτό θα δημιουργήσει 100-150 GB αρχείων καταγραφής την ημέρα. Ως εκ τούτου, έπρεπε να «κόψουμε» προσεκτικά τη βάση.
Πρώτον, το κάναμε χωρισμός την ημέρα, γιατί, σε γενικές γραμμές, κανείς δεν ενδιαφέρεται για τη συσχέτιση των ημερών. Τι διαφορά έχει αυτό που είχατε χθες, αν απόψε παρουσιάσατε μια νέα έκδοση της εφαρμογής - και ήδη μερικά νέα στατιστικά στοιχεία.
Δεύτερον, μάθαμε (αναγκαστήκαμε) πολύ, πολύ γρήγορα να γράψετε χρησιμοποιώντας COPY. Δηλαδή όχι μόνο COPYγιατί είναι πιο γρήγορος από INSERT, και ακόμα πιο γρήγορα.
Το τρίτο σημείο - έπρεπε εγκαταλείψτε τις σκανδάλες, αντίστοιχα, και τα ξένα κλειδιά. Δηλαδή, δεν έχουμε καθόλου αναφορική ακεραιότητα. Επειδή εάν έχετε έναν πίνακα που έχει ένα ζεύγος FK και λέτε στη δομή της βάσης δεδομένων ότι "εδώ είναι μια εγγραφή καταγραφής που αναφέρεται από το FK, για παράδειγμα, σε μια ομάδα εγγραφών", τότε όταν την εισάγετε, PostgreSQL δεν έχει τίποτα άλλο παρά πώς να το πάρει και να το κάνει ειλικρινά SELECT 1 FROM master_fk1_table WHERE ... με το αναγνωριστικό που προσπαθείτε να εισαγάγετε - απλώς για να ελέγξετε ότι αυτή η εγγραφή υπάρχει εκεί, ότι δεν «σπάσετε» αυτό το Ξένο Κλειδί με την εισαγωγή σας.
Αντί για μία εγγραφή στον πίνακα στόχο και τα ευρετήριά του, έχουμε το πρόσθετο πλεονέκτημα της ανάγνωσης από όλους τους πίνακες στους οποίους αναφέρεται. Αλλά δεν το χρειαζόμαστε καθόλου - καθήκον μας είναι να καταγράψουμε όσο το δυνατόν περισσότερα και όσο το δυνατόν γρηγορότερα με το λιγότερο φορτίο. Λοιπόν FK - κάτω!
Το επόμενο σημείο είναι η συγκέντρωση και ο κατακερματισμός. Αρχικά, τα εφαρμόσαμε στη βάση δεδομένων - τελικά, είναι βολικό να το κάνετε αμέσως, όταν φτάσει μια εγγραφή, σε κάποιο είδος tablet "συν ένα" ακριβώς στη σκανδάλη. Λοιπόν, είναι βολικό, αλλά το ίδιο κακό - εισάγετε έναν δίσκο, αλλά αναγκάζεστε να διαβάσετε και να γράψετε κάτι άλλο από έναν άλλο πίνακα. Επιπλέον, όχι μόνο διαβάζεις και γράφεις, το κάνεις και κάθε φορά.
Τώρα φανταστείτε ότι έχετε έναν πίνακα στον οποίο απλά μετράτε τον αριθμό των αιτημάτων που έχουν περάσει από έναν συγκεκριμένο κεντρικό υπολογιστή: +1, +1, +1, ..., +1. Και εσείς, καταρχήν, δεν το χρειάζεστε - όλα είναι δυνατά άθροισμα στη μνήμη στον συλλέκτη και αποστολή στη βάση δεδομένων με μία κίνηση +10.
Ναι, σε περίπτωση ορισμένων προβλημάτων, η λογική ακεραιότητά σας μπορεί να "καταρρεύσει", αλλά αυτή είναι μια σχεδόν μη ρεαλιστική περίπτωση - επειδή έχετε έναν κανονικό διακομιστή, έχει μια μπαταρία στον ελεγκτή, έχετε ένα αρχείο καταγραφής συναλλαγών, ένα αρχείο καταγραφής στο σύστημα αρχείων... Γενικά, δεν αξίζει τον κόπο. Η απώλεια παραγωγικότητας που λαμβάνετε από την εκτέλεση εναυσμάτων/FK δεν αξίζει τα έξοδα που κάνετε.
Το ίδιο συμβαίνει και με το hashing. Ένα συγκεκριμένο αίτημα πετάει προς εσάς, υπολογίζετε ένα συγκεκριμένο αναγνωριστικό από αυτό στη βάση δεδομένων, το γράφετε στη βάση δεδομένων και μετά το λέτε σε όλους. Όλα είναι καλά μέχρι που, τη στιγμή της ηχογράφησης, έρθει σε εσάς ένα δεύτερο άτομο που θέλει να ηχογραφήσει το ίδιο πράγμα - και μπλοκάρεστε, και αυτό είναι ήδη κακό. Επομένως, εάν μπορείτε να μεταφέρετε τη δημιουργία ορισμένων αναγνωριστικών στον πελάτη (σε σχέση με τη βάση δεδομένων), είναι καλύτερο να το κάνετε αυτό.
Απλώς ήταν τέλειο για εμάς να χρησιμοποιήσουμε το MD5 από το κείμενο - αίτημα, σχέδιο, πρότυπο,... Το υπολογίζουμε από την πλευρά του συλλέκτη και «χύνουμε» το έτοιμο ID στη βάση δεδομένων. Το μήκος του MD5 και η καθημερινή κατάτμηση μας επιτρέπουν να μην ανησυχούμε για πιθανές συγκρούσεις.
Αλλά για να καταγράψουμε όλα αυτά γρήγορα, χρειάστηκε να τροποποιήσουμε την ίδια τη διαδικασία εγγραφής.
Πώς γράφετε συνήθως δεδομένα; Έχουμε κάποιο είδος δεδομένων, το χωρίζουμε σε πολλούς πίνακες και μετά το ΑΝΤΙΓΡΑΦΕΙ - πρώτα στον πρώτο, μετά στο δεύτερο, στο τρίτο... Δεν είναι βολικό, γιατί φαίνεται να γράφουμε μια ροή δεδομένων σε τρία βήματα διαδοχικά. Δυσάρεστος. Μπορεί να γίνει πιο γρήγορα; Μπορώ!
Για να γίνει αυτό, αρκεί απλώς να αποσυντεθεί αυτές οι ροές παράλληλα μεταξύ τους. Αποδεικνύεται ότι έχουμε λάθη, αιτήματα, πρότυπα, μπλοκαρίσματα, ... πετώντας σε ξεχωριστά νήματα - και τα γράφουμε όλα παράλληλα. Αρκετά για αυτό κρατήστε ένα κανάλι COPY συνεχώς ανοιχτό για κάθε μεμονωμένο πίνακα στόχων.
Δηλαδή στον συλλέκτη υπάρχει πάντα ένα ρεύμα, στο οποίο μπορώ να γράψω τα δεδομένα που χρειάζομαι. Αλλά για να δει αυτά τα δεδομένα η βάση δεδομένων και κάποιος να μην κολλήσει περιμένοντας να γραφτούν αυτά τα δεδομένα, Το COPY πρέπει να διακόπτεται σε ορισμένα χρονικά διαστήματα. Για εμάς, η πιο αποτελεσματική περίοδος ήταν περίπου 100 ms - το κλείνουμε και αμέσως το ανοίγουμε ξανά στο ίδιο τραπέζι. Και αν δεν έχουμε αρκετή μία ροή κατά τη διάρκεια ορισμένων κορυφών, τότε κάνουμε συγκέντρωση μέχρι ένα ορισμένο όριο.
Επιπλέον, ανακαλύψαμε ότι για ένα τέτοιο προφίλ φόρτωσης, οποιαδήποτε συγκέντρωση, όταν οι εγγραφές συλλέγονται σε παρτίδες, είναι κακό. Κλασικό κακό είναι INSERT ... VALUES και επιπλέον 1000 δίσκοι. Επειδή σε εκείνο το σημείο έχετε μια αιχμή εγγραφής στα μέσα, και όλοι οι άλλοι που προσπαθούν να γράψουν κάτι στο δίσκο θα περιμένουν.
Για να απαλλαγείτε από τέτοιες ανωμαλίες, απλά μην συγκεντρώνετε τίποτα, μην αποθηκεύετε καθόλου. Και αν συμβεί προσωρινή αποθήκευση στο δίσκο (ευτυχώς, το Stream API στο Node.js σας επιτρέπει να το μάθετε) - αναβάλετε αυτήν τη σύνδεση. Όταν λάβετε ένα συμβάν ότι είναι ξανά δωρεάν, γράψτε του από τη συσσωρευμένη ουρά. Και ενώ είναι απασχολημένο, πάρτε το επόμενο δωρεάν από την πισίνα και γράψτε του.
Πριν εισαγάγουμε αυτήν την προσέγγιση στην καταγραφή δεδομένων, είχαμε περίπου 4K λειτουργίες εγγραφής και με αυτόν τον τρόπο μειώσαμε το φορτίο κατά 4 φορές. Τώρα έχουν αυξηθεί άλλες 6 φορές λόγω των νέων παρακολουθούμενων βάσεων δεδομένων - έως και 100MB/s. Και τώρα αποθηκεύουμε αρχεία καταγραφής για τους τελευταίους 3 μήνες σε όγκο περίπου 10-15 TB, ελπίζοντας ότι σε μόλις τρεις μήνες οποιοσδήποτε προγραμματιστής θα είναι σε θέση να λύσει οποιοδήποτε πρόβλημα.
Καταλαβαίνουμε τα προβλήματα
Αλλά η απλή συλλογή όλων αυτών των δεδομένων είναι καλή, χρήσιμη, σχετική, αλλά όχι αρκετή - πρέπει να γίνει κατανοητό. Γιατί αυτά είναι εκατομμύρια διαφορετικά σχέδια την ημέρα.
Αλλά τα εκατομμύρια δεν είναι διαχειρίσιμα, πρέπει πρώτα να κάνουμε «μικρότερα». Και, πρώτα απ 'όλα, πρέπει να αποφασίσετε πώς θα οργανώσετε αυτό το "μικρότερο" πράγμα.
Έχουμε εντοπίσει τρία βασικά σημεία:
- που απέστειλε αυτό το αίτημα
Δηλαδή από ποια εφαρμογή «έφθασε»: διεπαφή ιστού, backend, σύστημα πληρωμών ή κάτι άλλο. - όπου συνέβη
Σε ποιο συγκεκριμένο διακομιστή; Γιατί αν έχετε πολλούς διακομιστές κάτω από μια εφαρμογή και ξαφνικά ένας "χαζεύει" (επειδή "ο δίσκος είναι σάπιος", "διαρροή μνήμης", κάποιο άλλο πρόβλημα), τότε πρέπει να απευθυνθείτε συγκεκριμένα στον διακομιστή. - как το πρόβλημα εκδηλώθηκε με τον ένα ή τον άλλο τρόπο
Για να κατανοήσουμε το "ποιος" μας έστειλε ένα αίτημα, χρησιμοποιούμε ένα τυπικό εργαλείο - ορίζοντας μια μεταβλητή συνεδρίας: SET application_name = '{bl-host}:{bl-method}'; — στέλνουμε το όνομα του κεντρικού υπολογιστή επιχειρηματικής λογικής από τον οποίο προέρχεται το αίτημα και το όνομα της μεθόδου ή της εφαρμογής που το ξεκίνησε.
Αφού περάσουμε τον "κάτοχο" του αιτήματος, πρέπει να βγει στο αρχείο καταγραφής - για αυτό διαμορφώνουμε τη μεταβλητή log_line_prefix = ' %m [%p:%v] [%d] %r %a'. Για όσους ενδιαφέρονται, ίσως Τι σημαίνουν όλα αυτά. Αποδεικνύεται ότι βλέπουμε στο αρχείο καταγραφής:
- ώρα
- αναγνωριστικά διαδικασίας και συναλλαγής
- όνομα βάσης δεδομένων
- IP του ατόμου που έστειλε αυτό το αίτημα
- και όνομα μεθόδου
Τότε συνειδητοποιήσαμε ότι δεν είναι πολύ ενδιαφέρον να δούμε τη συσχέτιση για ένα αίτημα μεταξύ διαφορετικών διακομιστών. Δεν είναι συχνά ότι έχετε μια κατάσταση όπου μια εφαρμογή βιδώνει εξίσου εδώ και εκεί. Αλλά ακόμα κι αν είναι το ίδιο, κοιτάξτε οποιονδήποτε από αυτούς τους διακομιστές.
Ορίστε λοιπόν η περικοπή "ένας διακομιστής - μια μέρα" μας αρκούσε για οποιαδήποτε ανάλυση.
Η πρώτη αναλυτική ενότητα είναι η ίδια "δείγμα" - μια συντομευμένη μορφή παρουσίασης του σχεδίου, απαλλαγμένη από όλους τους αριθμητικούς δείκτες. Η δεύτερη περικοπή είναι η εφαρμογή ή η μέθοδος και η τρίτη περικοπή είναι ο συγκεκριμένος κόμβος σχεδίου που μας προκάλεσε προβλήματα.
Όταν περάσαμε από συγκεκριμένες περιπτώσεις σε πρότυπα, είχαμε δύο πλεονεκτήματα ταυτόχρονα:
- πολλαπλή μείωση του αριθμού των αντικειμένων για ανάλυση
Πρέπει να αναλύσουμε το πρόβλημα όχι πλέον με χιλιάδες ερωτήματα ή σχέδια, αλλά με δεκάδες πρότυπα. - χρονοδιάγραμμα
Δηλαδή, συνοψίζοντας τα «γεγονότα» σε μια συγκεκριμένη ενότητα, μπορείτε να εμφανίσετε την εμφάνισή τους κατά τη διάρκεια της ημέρας. Και εδώ μπορείτε να καταλάβετε ότι εάν έχετε κάποιο μοτίβο που συμβαίνει, για παράδειγμα, μία φορά την ώρα, αλλά πρέπει να συμβαίνει μία φορά την ημέρα, θα πρέπει να σκεφτείτε τι πήγε στραβά - ποιος το προκάλεσε και γιατί, ίσως θα έπρεπε να είναι εδώ δεν θα έπρεπε. Αυτή είναι μια άλλη μη αριθμητική, καθαρά οπτική, μέθοδος ανάλυσης.
Οι υπόλοιπες μέθοδοι βασίζονται στους δείκτες που εξάγουμε από το σχέδιο: πόσες φορές εμφανίστηκε ένα τέτοιο μοτίβο, ο συνολικός και μέσος χρόνος, πόσα δεδομένα διαβάστηκαν από το δίσκο και πόσα από τη μνήμη...
Επειδή, για παράδειγμα, έρχεστε στη σελίδα αναλυτικών στοιχείων για τον κεντρικό υπολογιστή, κοιτάξτε - κάτι αρχίζει να διαβάζεται πάρα πολύ στο δίσκο. Ο δίσκος στον διακομιστή δεν μπορεί να το χειριστεί - ποιος διαβάζει από αυτόν;
Και μπορείτε να ταξινομήσετε κατά οποιαδήποτε στήλη και να αποφασίσετε με τι θα αντιμετωπίσετε αυτή τη στιγμή - το φορτίο στον επεξεργαστή ή το δίσκο ή τον συνολικό αριθμό αιτημάτων... Το ταξινομήσαμε, εξετάσαμε τα "κορυφαία", το διορθώσαμε και κυκλοφόρησε μια νέα έκδοση της εφαρμογής.
Και αμέσως μπορείτε να δείτε διαφορετικές εφαρμογές που συνοδεύουν το ίδιο πρότυπο από ένα αίτημα όπως SELECT * FROM users WHERE login = 'Vasya'. Frontend, backend, επεξεργασία... Και αναρωτιέστε γιατί η επεξεργασία θα διάβαζε τον χρήστη εάν δεν αλληλεπιδρά μαζί του.
Ο αντίθετος τρόπος είναι να δεις αμέσως από την εφαρμογή τι κάνει. Για παράδειγμα, το frontend είναι αυτό, αυτό, αυτό και αυτό μία φορά την ώρα (το χρονοδιάγραμμα βοηθάει). Και τίθεται αμέσως το ερώτημα: φαίνεται ότι δεν είναι δουλειά του frontend να κάνει κάτι μία φορά την ώρα...
Μετά από κάποιο χρονικό διάστημα, καταλάβαμε ότι μας έλειπε συγκεντρωτικά στατιστικά κατά κόμβους σχεδίου. Απομονώσαμε από τα σχέδια μόνο εκείνους τους κόμβους που κάνουν κάτι με τα δεδομένα των ίδιων των πινάκων (διαβάστε/γράψτε τους με ευρετήριο ή όχι). Στην πραγματικότητα, προστίθεται μόνο μία πτυχή σε σχέση με την προηγούμενη εικόνα - πόσους δίσκους μας έφερε αυτός ο κόμβος;, και πόσες απορρίφθηκαν (Οι σειρές αφαιρέθηκαν από το φίλτρο).
Δεν έχετε κατάλληλο ευρετήριο στο πιάτο, κάνετε ένα αίτημα σε αυτό, ξεπερνά το ευρετήριο, πέφτει στο Seq Scan... έχετε φιλτράρει όλες τις εγγραφές εκτός από μία. Γιατί χρειάζεστε 100 εκατομμύρια φιλτραρισμένες εγγραφές την ημέρα; Δεν είναι καλύτερο να κάνετε roll up το ευρετήριο;
Έχοντας αναλύσει όλα τα σχέδια κόμβο προς κόμβο, συνειδητοποιήσαμε ότι υπάρχουν μερικές τυπικές δομές στα σχέδια που είναι πολύ πιθανό να φαίνονται ύποπτες. Και θα ήταν ωραίο να πείτε στον προγραμματιστή: "Φίλε, εδώ πρώτα διαβάζεις με ευρετήριο, μετά ταξινομείς και μετά αποκόπτεις" - κατά κανόνα, υπάρχει μία εγγραφή.
Όλοι όσοι έγραψαν ερωτήματα έχουν πιθανώς συναντήσει αυτό το μοτίβο: "Δώστε μου την τελευταία παραγγελία για τη Vasya, την ημερομηνία της." Και αν δεν έχετε ευρετήριο κατά ημερομηνία ή δεν υπάρχει ημερομηνία στο ευρετήριο που χρησιμοποιήσατε, τότε θα πάτησε ακριβώς την ίδια «τσούγκα» .
Αλλά ξέρουμε ότι πρόκειται για "τσάντα" - οπότε γιατί να μην πείτε αμέσως στον προγραμματιστή τι πρέπει να κάνει. Αντίστοιχα, όταν ανοίγουμε ένα σχέδιο τώρα, ο προγραμματιστής μας βλέπει αμέσως μια όμορφη εικόνα με συμβουλές, όπου του λένε αμέσως: "Έχεις προβλήματα εδώ και εκεί, αλλά λύνονται έτσι κι έτσι."
Ως αποτέλεσμα, ο όγκος της εμπειρίας που χρειαζόταν για την επίλυση προβλημάτων στην αρχή και τώρα έχει μειωθεί σημαντικά. Αυτό είναι το είδος του εργαλείου που έχουμε.
Πηγή: www.habr.com