DBA bot Joe. Ανατόλι Στάνσλερ (Postgres.ai)

Πώς κατανοεί ένας προγραμματιστής υποστήριξης ότι ένα ερώτημα SQL θα λειτουργήσει καλά σε ένα "prod"; Στις μεγάλες ή ταχέως αναπτυσσόμενες εταιρείες δεν έχουν όλοι πρόσβαση στο «προϊόν». Και με την πρόσβαση, δεν μπορούν να ελεγχθούν ανώδυνα όλα τα αιτήματα και η δημιουργία αντιγράφου της βάσης δεδομένων συχνά διαρκεί ώρες. Για να λύσουμε αυτά τα προβλήματα, δημιουργήσαμε ένα τεχνητό DBA - Joe. Έχει ήδη εφαρμοστεί με επιτυχία σε αρκετές εταιρείες και βοηθά περισσότερους από δώδεκα προγραμματιστές.

Βίντεο:

Γεια σε όλους! Το όνομά μου είναι Anatoly Stansler. Δουλεύω σε μια εταιρεία postgres.ai. Δεσμευόμαστε να επιταχύνουμε τη διαδικασία ανάπτυξης αφαιρώντας τις καθυστερήσεις που σχετίζονται με την εργασία της Postgres από προγραμματιστές, DBA και QA.

Έχουμε εξαιρετικούς πελάτες και σήμερα μέρος της έκθεσης θα αφιερωθεί σε περιπτώσεις που συναντήσαμε ενώ εργαζόμασταν μαζί τους. Θα μιλήσω για το πώς τους βοηθήσαμε να λύσουν αρκετά σοβαρά προβλήματα.

Όταν αναπτύσσουμε και κάνουμε σύνθετες μεταναστεύσεις υψηλού φορτίου, αναρωτιόμαστε: «Θα απογειωθεί αυτή η μετανάστευση;». Χρησιμοποιούμε κριτική, χρησιμοποιούμε τις γνώσεις πιο έμπειρων συναδέλφων, ειδικών DBA. Και μπορούν να πουν αν θα πετάξει ή όχι.

Αλλά ίσως θα ήταν καλύτερο να μπορούσαμε να το δοκιμάσουμε μόνοι μας σε αντίγραφα πλήρους μεγέθους. Και σήμερα θα μιλήσουμε απλώς για το ποιες είναι οι προσεγγίσεις στις δοκιμές τώρα και πώς μπορεί να γίνει καλύτερα και με ποια εργαλεία. Θα μιλήσουμε επίσης για τα πλεονεκτήματα και τα μειονεκτήματα τέτοιων προσεγγίσεων και τι μπορούμε να διορθώσουμε εδώ.

Ποιος έχει κάνει ποτέ ευρετήρια απευθείας στο prod ή έχει κάνει κάποιες αλλαγές; Αρκετά. Και για ποιον οδήγησε αυτό στο γεγονός ότι χάθηκαν δεδομένα ή υπήρξαν διακοπές λειτουργίας; Τότε ξέρεις αυτόν τον πόνο. Δόξα τω Θεώ υπάρχουν αντίγραφα ασφαλείας.

Η πρώτη προσέγγιση είναι η δοκιμή στο prod. Ή, όταν ένας προγραμματιστής κάθεται σε ένα τοπικό μηχάνημα, έχει δεδομένα δοκιμής, υπάρχει κάποιο είδος περιορισμένης επιλογής. Και βγαίνουμε για να ωθήσουμε, και έχουμε αυτή την κατάσταση.

Πονάει, είναι ακριβό. Μάλλον είναι καλύτερο να μην το κάνετε.

Και ποιος είναι ο καλύτερος τρόπος για να το κάνετε;

Ας πάρουμε τη σταδιοποίηση και ας επιλέξουμε κάποιο μέρος της παραγωγής εκεί. Ή στην καλύτερη περίπτωση, ας πάρουμε μια πραγματική ώθηση, όλα τα δεδομένα. Και αφού το αναπτύξουμε τοπικά, θα ελέγξουμε επιπλέον για σταδιοποίηση.

Αυτό θα μας επιτρέψει να αφαιρέσουμε ορισμένα από τα λάθη, δηλαδή να αποτρέψουμε την εμφάνιση τους.

Ποια είναι τα προβλήματα;

• Το πρόβλημα είναι ότι μοιραζόμαστε αυτό το σκηνικό με συναδέλφους. Και πολύ συχνά συμβαίνει να κάνετε κάποια αλλαγή, μπαμ - και δεν υπάρχουν δεδομένα, η δουλειά είναι στο στόχαστρο. Η σταδιοποίηση ήταν πολλών terabyte. Και πρέπει να περιμένετε πολύ για να ανέβει ξανά. Και αποφασίζουμε να το οριστικοποιήσουμε αύριο. Αυτό ήταν, έχουμε εξέλιξη.
• Και, φυσικά, έχουμε πολλούς συναδέλφους που εργάζονται εκεί, πολλές ομάδες. Και πρέπει να γίνει χειροκίνητα. Και αυτό είναι άβολο.

Και αξίζει να πούμε ότι έχουμε μόνο μία προσπάθεια, μία βολή, αν θέλουμε να κάνουμε κάποιες αλλαγές στη βάση δεδομένων, να αγγίξουμε τα δεδομένα, να αλλάξουμε τη δομή. Και αν κάτι πήγε στραβά, αν υπήρξε σφάλμα στη μετεγκατάσταση, τότε δεν θα επιστρέψουμε γρήγορα.

Αυτό είναι καλύτερο από την προηγούμενη προσέγγιση, αλλά εξακολουθεί να υπάρχει μεγάλη πιθανότητα κάποιου είδους σφάλμα να πάει στην παραγωγή.

Τι μας εμποδίζει να δώσουμε σε κάθε προγραμματιστή έναν πάγκο δοκιμών, ένα αντίγραφο πλήρους μεγέθους; Νομίζω ότι είναι ξεκάθαρο τι εμποδίζει.

Ποιος έχει μια βάση δεδομένων μεγαλύτερη από ένα terabyte; Περισσότερο από το μισό δωμάτιο.

Και είναι ξεκάθαρο ότι το να κρατάς μηχανές για κάθε προγραμματιστή, όταν υπάρχει τόσο μεγάλη παραγωγή, είναι πολύ ακριβό, και επιπλέον χρειάζεται πολύς χρόνος.

Έχουμε πελάτες που έχουν συνειδητοποιήσει ότι είναι πολύ σημαντικό να δοκιμάζονται όλες οι αλλαγές σε αντίγραφα πλήρους μεγέθους, αλλά η βάση δεδομένων τους είναι μικρότερη από ένα terabyte και δεν υπάρχουν πόροι για τη διατήρηση ενός πάγκου δοκιμών για κάθε προγραμματιστή. Επομένως, πρέπει να κατεβάσουν τα dump τοπικά στο μηχάνημά τους και να δοκιμάσουν με αυτόν τον τρόπο. Παίρνει πολύ χρόνο.

Ακόμα κι αν το κάνετε μέσα στην υποδομή, τότε η λήψη ενός terabyte δεδομένων ανά ώρα είναι ήδη πολύ καλή. Αλλά χρησιμοποιούν λογικές χωματερές, κάνουν λήψη τοπικά από το cloud. Για αυτούς, η ταχύτητα είναι περίπου 200 gigabyte ανά ώρα. Και χρειάζεται ακόμα χρόνος για να γυρίσετε από τη λογική χωματερή, να ανακυκλώσετε τους δείκτες κ.λπ.

Αλλά χρησιμοποιούν αυτή την προσέγγιση επειδή τους επιτρέπει να διατηρούν το προϊόν αξιόπιστο.

Τι μπορούμε να κάνουμε εδώ; Ας κάνουμε τους πάγκους δοκιμών φθηνούς και ας δώσουμε σε κάθε προγραμματιστή τον δικό του πάγκο δοκιμών.

Και αυτό είναι δυνατό.

Και σε αυτήν την προσέγγιση, όταν φτιάχνουμε λεπτούς κλώνους για κάθε προγραμματιστή, μπορούμε να τους μοιραστούμε σε ένα μηχάνημα. Για παράδειγμα, εάν έχετε μια βάση δεδομένων 10 TB και θέλετε να τη δώσετε σε 10 προγραμματιστές, δεν χρειάζεται να έχετε βάσεις δεδομένων XNUMX x XNUMX TB. Χρειάζεστε μόνο ένα μηχάνημα για να δημιουργήσετε λεπτά απομονωμένα αντίγραφα για κάθε προγραμματιστή που χρησιμοποιεί ένα μηχάνημα. Θα σας πω πώς λειτουργεί λίγο αργότερα.

Πραγματικό παράδειγμα:

• DB - 4,5 terabyte.

• Μπορούμε να λάβουμε ανεξάρτητα αντίγραφα σε 30 δευτερόλεπτα.

Δεν χρειάζεται να περιμένετε για μια δοκιμαστική βάση και να εξαρτάται από το πόσο μεγάλη είναι. Μπορείτε να το αποκτήσετε σε δευτερόλεπτα. Θα είναι εντελώς απομονωμένα περιβάλλοντα, αλλά που μοιράζονται δεδομένα μεταξύ τους.

Αυτό είναι υπέροχο. Εδώ μιλάμε για μαγεία και παράλληλο σύμπαν.

Στην περίπτωσή μας, αυτό λειτουργεί χρησιμοποιώντας το σύστημα OpenZFS.

Το OpenZFS είναι ένα σύστημα αρχείων αντιγραφής σε εγγραφή που υποστηρίζει στιγμιότυπα και κλώνους εκτός συσκευασίας. Είναι αξιόπιστο και επεκτάσιμο. Είναι πολύ εύκολη στη διαχείριση. Μπορεί κυριολεκτικά να αναπτυχθεί σε δύο ομάδες.

Υπάρχουν και άλλες επιλογές:

• lvm,

• Αποθήκευση (για παράδειγμα, Pure Storage).

Το Εργαστήριο Βάσης Δεδομένων για το οποίο μιλάω είναι αρθρωτό. Μπορεί να υλοποιηθεί χρησιμοποιώντας αυτές τις επιλογές. Αλλά προς το παρόν, έχουμε επικεντρωθεί στο OpenZFS, επειδή υπήρχαν προβλήματα ειδικά με το LVM.

Πως δουλεύει? Αντί να αντικαθιστούμε τα δεδομένα κάθε φορά που τα αλλάζουμε, τα αποθηκεύουμε επισημαίνοντας απλώς ότι αυτά τα νέα δεδομένα προέρχονται από ένα νέο χρονικό σημείο, ένα νέο στιγμιότυπο.

Και στο μέλλον, όταν θέλουμε να κάνουμε rollback ή θέλουμε να κάνουμε έναν νέο κλώνο από κάποια παλαιότερη έκδοση, λέμε απλώς: "Εντάξει, δώστε μας αυτά τα μπλοκ δεδομένων που επισημαίνονται έτσι."

Και αυτός ο χρήστης θα εργαστεί με ένα τέτοιο σύνολο δεδομένων. Σταδιακά θα τα αλλάξει, θα φτιάξει τα δικά του στιγμιότυπα.

Και θα διακλαδίσουμε. Κάθε προγραμματιστής στην περίπτωσή μας θα έχει την ευκαιρία να έχει τον δικό του κλώνο που επεξεργάζεται και τα δεδομένα που μοιράζονται θα μοιράζονται μεταξύ όλων.

Για να αναπτύξετε ένα τέτοιο σύστημα στο σπίτι, πρέπει να λύσετε δύο προβλήματα:

• Το πρώτο είναι η πηγή των δεδομένων, από όπου θα τα πάρετε. Μπορείτε να ρυθμίσετε την αναπαραγωγή με την παραγωγή. Μπορείτε ήδη να χρησιμοποιήσετε τα αντίγραφα ασφαλείας που έχετε διαμορφώσει, ελπίζω. WAL-E, WAL-G ή Barman. Και ακόμα κι αν χρησιμοποιείτε κάποιο είδος λύσης Cloud, όπως RDS ή Cloud SQL, τότε μπορείτε να χρησιμοποιήσετε λογικές ενδείξεις. Ωστόσο, εξακολουθείτε να σας συμβουλεύουμε να χρησιμοποιείτε αντίγραφα ασφαλείας, γιατί με αυτήν την προσέγγιση θα διατηρήσετε επίσης τη φυσική δομή των αρχείων, η οποία θα σας επιτρέψει να είστε ακόμη πιο κοντά στις μετρήσεις που θα βλέπατε στην παραγωγή, προκειμένου να αντιμετωπιστούν τα προβλήματα που υπάρχουν.

• Το δεύτερο είναι όπου θέλετε να φιλοξενήσετε το Εργαστήριο Βάσης Δεδομένων. Θα μπορούσε να είναι Cloud, θα μπορούσε να είναι On-premise. Είναι σημαντικό να πούμε εδώ ότι το ZFS υποστηρίζει συμπίεση δεδομένων. Και το κάνει αρκετά καλά.

Φανταστείτε ότι για κάθε τέτοιο κλώνο, ανάλογα με τις λειτουργίες που κάνουμε με τη βάση, θα αναπτυχθεί κάποιο είδος dev. Για αυτό, ο dev θα χρειαστεί επίσης χώρο. Αλλά λόγω του γεγονότος ότι πήραμε μια βάση 4,5 terabyte, η ZFS θα τη συμπιέσει στα 3,5 terabyte. Αυτό μπορεί να διαφέρει ανάλογα με τις ρυθμίσεις. Και έχουμε ακόμα χώρο για dev.

Ένα τέτοιο σύστημα μπορεί να χρησιμοποιηθεί για διαφορετικές περιπτώσεις.

• Αυτοί είναι προγραμματιστές, DBA για επικύρωση ερωτημάτων, για βελτιστοποίηση.

• Αυτό μπορεί να χρησιμοποιηθεί σε δοκιμές QA για να δοκιμάσετε μια συγκεκριμένη μετεγκατάσταση προτού την προωθήσουμε για παραγωγή. Και μπορούμε επίσης να δημιουργήσουμε ειδικά περιβάλλοντα για QA με πραγματικά δεδομένα, όπου μπορούν να δοκιμάσουν νέες λειτουργίες. Και θα χρειαστούν δευτερόλεπτα αντί για ώρες αναμονής, και ίσως μέρες σε κάποιες άλλες περιπτώσεις όπου δεν χρησιμοποιούνται λεπτά αντίγραφα.

• Και άλλη περίπτωση. Εάν η εταιρεία δεν έχει ρυθμίσει ένα σύστημα ανάλυσης, τότε μπορούμε να απομονώσουμε έναν λεπτό κλώνο της βάσης προϊόντων και να τον δώσουμε σε μεγάλα ερωτήματα ή ειδικά ευρετήρια που μπορούν να χρησιμοποιηθούν στα αναλυτικά στοιχεία.

Με αυτή την προσέγγιση:

1. Χαμηλή πιθανότητα σφαλμάτων στο "prod", επειδή δοκιμάσαμε όλες τις αλλαγές σε δεδομένα πλήρους μεγέθους.

2. Έχουμε μια κουλτούρα δοκιμών, γιατί τώρα δεν χρειάζεται να περιμένετε ώρες για το δικό σας περίπτερο.

3. Και δεν υπάρχει κανένα εμπόδιο, καμία αναμονή μεταξύ των δοκιμών. Μπορείτε πραγματικά να πάτε και να ελέγξετε. Και θα είναι καλύτερα με αυτόν τον τρόπο καθώς επιταχύνουμε την ανάπτυξη.

• Θα υπάρξει λιγότερη ανακατασκευή. Λιγότερα σφάλματα θα καταλήξουν στην παραγωγή. Θα τα αναπαραστήσουμε λιγότερο αργότερα.

• Μπορούμε να αντιστρέψουμε τις μη αναστρέψιμες αλλαγές. Αυτή δεν είναι η τυπική προσέγγιση.

1. Αυτό είναι ευεργετικό γιατί μοιραζόμαστε τους πόρους των πάγκων δοκιμών.

Ήδη καλό, αλλά τι άλλο θα μπορούσε να επιταχυνθεί;

Χάρη σε ένα τέτοιο σύστημα, μπορούμε να μειώσουμε πολύ το όριο για την είσοδο σε τέτοιες δοκιμές.

Τώρα υπάρχει ένας φαύλος κύκλος, όταν ένας προγραμματιστής, για να αποκτήσει πρόσβαση σε πραγματικά δεδομένα πλήρους μεγέθους, πρέπει να γίνει ειδικός. Πρέπει να του εμπιστεύονται τέτοια πρόσβαση.

Αλλά πώς να αναπτυχθεί αν δεν υπάρχει. Τι γίνεται όμως αν έχετε στη διάθεσή σας μόνο ένα πολύ μικρό σύνολο δεδομένων δοκιμής; Τότε δεν θα έχετε πραγματική εμπειρία.

Πώς να βγείτε από αυτόν τον κύκλο; Ως πρώτη διεπαφή, βολική για προγραμματιστές οποιουδήποτε επιπέδου, επιλέξαμε το Slack bot. Αλλά μπορεί να είναι οποιαδήποτε άλλη διεπαφή.

Τι σας επιτρέπει να κάνετε; Μπορείτε να κάνετε ένα συγκεκριμένο ερώτημα και να το στείλετε σε ένα ειδικό κανάλι για τη βάση δεδομένων. Θα αναπτύξουμε αυτόματα έναν λεπτό κλώνο σε δευτερόλεπτα. Ας εκτελέσουμε αυτό το αίτημα. Συλλέγουμε μετρήσεις και προτάσεις. Ας δείξουμε μια οπτικοποίηση. Και τότε αυτός ο κλώνος θα παραμείνει έτσι ώστε αυτό το ερώτημα να μπορεί να βελτιστοποιηθεί με κάποιο τρόπο, να προσθέσει ευρετήρια κ.λπ.

Και επίσης το Slack μας δίνει ευκαιρίες για συνεργασία εκτός κουτιού. Δεδομένου ότι αυτό είναι απλώς ένα κανάλι, μπορείτε να ξεκινήσετε να συζητάτε αυτό το αίτημα ακριβώς εκεί στο νήμα για ένα τέτοιο αίτημα, κάνοντας ping στους συναδέλφους σας, τους DBA που βρίσκονται εντός της εταιρείας.

Αλλά υπάρχουν, φυσικά, προβλήματα. Επειδή αυτός είναι ο πραγματικός κόσμος και χρησιμοποιούμε έναν διακομιστή που φιλοξενεί πολλούς κλώνους ταυτόχρονα, πρέπει να συμπιέσουμε την ποσότητα της μνήμης και της ισχύος της CPU που είναι διαθέσιμη στους κλώνους.

Αλλά για να είναι εύλογες αυτές οι δοκιμές, πρέπει να λύσετε με κάποιο τρόπο αυτό το πρόβλημα.

Είναι σαφές ότι το σημαντικό σημείο είναι τα ίδια δεδομένα. Αλλά το έχουμε ήδη. Και θέλουμε να πετύχουμε την ίδια διαμόρφωση. Και μπορούμε να δώσουμε μια τέτοια σχεδόν ίδια διαμόρφωση.

Θα ήταν ωραίο να έχουμε το ίδιο υλικό όπως στην παραγωγή, αλλά μπορεί να διαφέρει.

Ας θυμηθούμε πώς λειτουργεί η Postgres με τη μνήμη. Έχουμε δύο κρυφές μνήμες. Ένα από το σύστημα αρχείων και ένα εγγενές Postgres, δηλαδή Shared Buffer Cache.

Είναι σημαντικό να σημειωθεί ότι η κοινόχρηστη προσωρινή μνήμη προσωρινής αποθήκευσης εκχωρείται όταν ξεκινά το Postgres, ανάλογα με το μέγεθος που καθορίζετε στη διαμόρφωση.

Και η δεύτερη κρυφή μνήμη χρησιμοποιεί όλο τον διαθέσιμο χώρο.

Και όταν κάνουμε πολλούς κλώνους σε ένα μηχάνημα, αποδεικνύεται ότι γεμίζουμε σταδιακά τη μνήμη. Και με την καλή έννοια, η κοινή προσωρινή μνήμη προσωρινής αποθήκευσης είναι το 25% της συνολικής ποσότητας μνήμης που είναι διαθέσιμη στο μηχάνημα.

Και αποδεικνύεται ότι αν δεν αλλάξουμε αυτήν την παράμετρο, τότε θα μπορούμε να εκτελέσουμε μόνο 4 περιπτώσεις σε ένα μηχάνημα, δηλαδή 4 από όλους αυτούς τους λεπτούς κλώνους. Και αυτό, φυσικά, είναι κακό, γιατί θέλουμε να έχουμε πολύ περισσότερα από αυτά.

Αλλά από την άλλη πλευρά, η προσωρινή μνήμη προσωρινής αποθήκευσης χρησιμοποιείται για την εκτέλεση ερωτημάτων για ευρετήρια, δηλαδή, το σχέδιο εξαρτάται από το πόσο μεγάλες είναι οι κρυφές μας μνήμες. Και αν απλώς πάρουμε αυτήν την παράμετρο και τη μειώσουμε, τότε τα σχέδιά μας μπορούν να αλλάξουν πολλά.

Για παράδειγμα, αν έχουμε μεγάλη κρυφή μνήμη στο prod, τότε η Postgres θα προτιμήσει να χρησιμοποιήσει ένα ευρετήριο. Και αν όχι, τότε θα υπάρχει SeqScan. Και τι νόημα θα είχε αν τα σχέδιά μας δεν συνέπιπταν;

Αλλά εδώ καταλήγουμε στο συμπέρασμα ότι στην πραγματικότητα το σχέδιο στο Postgres δεν εξαρτάται από το συγκεκριμένο μέγεθος που καθορίζεται στο Shared Buffer στο σχέδιο, εξαρτάται από το effect_cache_size.

Το Effective_cache_size είναι το εκτιμώμενο ποσό της προσωρινής μνήμης που είναι διαθέσιμο σε εμάς, δηλαδή το άθροισμα της προσωρινής μνήμης προσωρινής μνήμης και της προσωρινής μνήμης του συστήματος αρχείων. Αυτό ορίζεται από τη διαμόρφωση. Και αυτή η μνήμη δεν εκχωρείται.

Και λόγω αυτής της παραμέτρου, μπορούμε να ξεγελάσουμε την Postgres, λέγοντας ότι έχουμε πραγματικά πολλά διαθέσιμα δεδομένα, ακόμα κι αν δεν έχουμε αυτά τα δεδομένα. Και έτσι, τα σχέδια θα συμπέσουν πλήρως με την παραγωγή.

Αλλά αυτό μπορεί να επηρεάσει το χρονοδιάγραμμα. Και βελτιστοποιούμε τα ερωτήματα βάσει χρονισμού, αλλά είναι σημαντικό ο χρονισμός να εξαρτάται από πολλούς παράγοντες:

• Εξαρτάται από το φορτίο που βρίσκεται επί του παρόντος στο prod.

• Εξαρτάται από τα χαρακτηριστικά του ίδιου του μηχανήματος.

Και αυτή είναι μια έμμεση παράμετρος, αλλά στην πραγματικότητα μπορούμε να βελτιστοποιήσουμε ακριβώς με βάση τον όγκο των δεδομένων που θα διαβάσει αυτό το ερώτημα για να έχουμε το αποτέλεσμα.

Και αν θέλετε ο συγχρονισμός να είναι κοντά σε αυτό που θα δούμε στο prod, τότε πρέπει να πάρουμε το πιο παρόμοιο υλικό και, ενδεχομένως, ακόμη περισσότερο ώστε να χωρέσουν όλοι οι κλώνοι. Αλλά αυτός είναι ένας συμβιβασμός, δηλαδή θα λάβετε τα ίδια σχέδια, θα δείτε πόσα δεδομένα θα διαβάσει ένα συγκεκριμένο ερώτημα και θα μπορείτε να συμπεράνετε εάν αυτό το ερώτημα είναι καλό (ή μετεγκατάσταση) ή κακό, πρέπει ακόμα να βελτιστοποιηθεί .

Ας ρίξουμε μια ματιά στον τρόπο με τον οποίο ο Joe έχει βελτιστοποιηθεί ειδικά.

Ας πάρουμε ένα αίτημα από ένα πραγματικό σύστημα. Σε αυτήν την περίπτωση, η βάση δεδομένων είναι 1 terabyte. Και θέλουμε να μετρήσουμε τον αριθμό των φρέσκων δημοσιεύσεων που είχαν περισσότερα από 10 likes.

Γράφουμε ένα μήνυμα στο κανάλι, έχει αναπτυχθεί ένας κλώνος για εμάς. Και θα δούμε ότι ένα τέτοιο αίτημα θα ολοκληρωθεί σε 2,5 λεπτά. Αυτό είναι το πρώτο πράγμα που παρατηρούμε.

Ο B Joe θα σας δείξει αυτόματες προτάσεις με βάση το σχέδιο και τις μετρήσεις.

Θα δούμε ότι το ερώτημα επεξεργάζεται πάρα πολλά δεδομένα για να πάρει έναν σχετικά μικρό αριθμό σειρών. Και χρειάζεται κάποιο είδος εξειδικευμένου ευρετηρίου, καθώς παρατηρήσαμε ότι υπάρχουν πάρα πολλές φιλτραρισμένες σειρές στο ερώτημα.

Ας ρίξουμε μια πιο προσεκτική ματιά στο τι συνέβη. Πράγματι, βλέπουμε ότι έχουμε διαβάσει σχεδόν ενάμιση gigabyte δεδομένων από την προσωρινή μνήμη αρχείων ή ακόμα και από το δίσκο. Και αυτό δεν είναι καλό, γιατί πήραμε μόνο 142 γραμμές.

Και, φαίνεται, έχουμε μια σάρωση ευρετηρίου εδώ και θα έπρεπε να είχε λειτουργήσει γρήγορα, αλλά επειδή φιλτράραμε πάρα πολλές γραμμές (έπρεπε να τις μετρήσουμε), το αίτημα σιγά-σιγά λειτούργησε.

Και αυτό συνέβη στο σχέδιο λόγω του γεγονότος ότι οι συνθήκες στο ερώτημα και οι συνθήκες στο ευρετήριο εν μέρει δεν ταιριάζουν.

Ας προσπαθήσουμε να κάνουμε το ευρετήριο πιο ακριβές και να δούμε πώς αλλάζει η εκτέλεση του ερωτήματος μετά από αυτό.

Η δημιουργία του ευρετηρίου κράτησε αρκετά, αλλά τώρα ελέγχουμε το ερώτημα και βλέπουμε ότι ο χρόνος αντί για 2,5 λεπτά είναι μόνο 156 χιλιοστά του δευτερολέπτου, που είναι αρκετά καλό. Και διαβάζουμε μόνο 6 megabyte δεδομένων.

Και τώρα χρησιμοποιούμε σάρωση μόνο ευρετηρίου.

Μια άλλη σημαντική ιστορία είναι ότι θέλουμε να παρουσιάσουμε το σχέδιο με έναν πιο κατανοητό τρόπο. Έχουμε εφαρμόσει οπτικοποίηση χρησιμοποιώντας γραφήματα φλόγας.

Αυτό είναι ένα διαφορετικό αίτημα, πιο έντονο. Και κατασκευάζουμε γραφήματα φλόγας σύμφωνα με δύο παραμέτρους: αυτός είναι ο όγκος δεδομένων που μέτρησε ένας συγκεκριμένος κόμβος στο σχέδιο και στο χρονισμό, δηλαδή ο χρόνος εκτέλεσης του κόμβου.

Εδώ μπορούμε να συγκρίνουμε συγκεκριμένους κόμβους μεταξύ τους. Και θα είναι ξεκάθαρο ποιο από αυτά χρειάζεται περισσότερο ή λιγότερο, κάτι που συνήθως είναι δύσκολο να γίνει σε άλλες μεθόδους απόδοσης.

Φυσικά, όλοι γνωρίζουν το εξηγ.depesz.com. Ένα καλό χαρακτηριστικό αυτής της οπτικοποίησης είναι ότι αποθηκεύουμε το σχέδιο κειμένου και επίσης βάζουμε ορισμένες βασικές παραμέτρους σε έναν πίνακα, ώστε να μπορούμε να ταξινομήσουμε.

Και οι προγραμματιστές που δεν έχουν ακόμη εμβαθύνει σε αυτό το θέμα χρησιμοποιούν επίσης το explore.depesz.com, επειδή είναι πιο εύκολο γι' αυτούς να καταλάβουν ποιες μετρήσεις είναι σημαντικές και ποιες όχι.

Υπάρχει μια νέα προσέγγιση στην οπτικοποίηση - αυτό είναι το εξηγ.dalibo.com. Κάνουν μια οπτικοποίηση δέντρου, αλλά είναι πολύ δύσκολο να συγκρίνουμε κόμβους μεταξύ τους. Εδώ μπορείτε να καταλάβετε καλά τη δομή, ωστόσο, εάν υπάρχει μεγάλο αίτημα, τότε θα χρειαστεί να κάνετε κύλιση εμπρός και πίσω, αλλά και μια επιλογή.

Колаборация

Και, όπως είπα, το Slack μας δίνει την ευκαιρία να συνεργαστούμε. Για παράδειγμα, εάν συναντήσουμε ένα σύνθετο ερώτημα που δεν είναι σαφές πώς να βελτιστοποιήσετε, μπορούμε να διευκρινίσουμε αυτό το ζήτημα με τους συναδέλφους μας σε ένα νήμα στο Slack.

Μας φαίνεται ότι είναι σημαντικό να κάνουμε δοκιμή σε δεδομένα πλήρους μεγέθους. Για να γίνει αυτό, δημιουργήσαμε το εργαλείο Update Database Lab, το οποίο είναι διαθέσιμο σε ανοιχτό κώδικα. Μπορείτε επίσης να χρησιμοποιήσετε το bot Joe. Μπορείτε να το πάρετε τώρα και να το εφαρμόσετε στο χώρο σας. Όλοι οι οδηγοί είναι διαθέσιμοι εκεί.

Είναι επίσης σημαντικό να σημειωθεί ότι η ίδια η λύση δεν είναι επαναστατική, επειδή υπάρχει η Delphix, αλλά είναι μια εταιρική λύση. Είναι τελείως κλειστό, είναι πανάκριβο. Ειδικευόμαστε ειδικά στην Postgres. Όλα αυτά είναι προϊόντα ανοιχτού κώδικα. Ελα μαζί μας!

Εδώ τελειώνω. Ευχαριστώ!

ερωτήσεις

Γειά σου! Ευχαριστώ για την αναφορά! Πολύ ενδιαφέρον, ειδικά για μένα, γιατί έλυσα το ίδιο πρόβλημα πριν λίγο καιρό. Και έτσι έχω μια σειρά από ερωτήσεις. Ελπίζω να πάρω τουλάχιστον ένα μέρος του.

Αναρωτιέμαι πώς υπολογίζετε τη θέση για αυτό το περιβάλλον; Η τεχνολογία σημαίνει ότι υπό ορισμένες συνθήκες, οι κλώνοι σας μπορούν να αυξηθούν στο μέγιστο μέγεθος. Σε γενικές γραμμές, εάν έχετε μια βάση δεδομένων δέκα terabyte και 10 κλώνους, τότε είναι εύκολο να προσομοιώσετε μια κατάσταση όπου κάθε κλώνος ζυγίζει 10 μοναδικά δεδομένα. Πώς υπολογίζεις αυτό το μέρος, δηλαδή εκείνο το δέλτα για το οποίο μίλησες, στο οποίο θα ζουν αυτοί οι κλώνοι;

Καλή ερώτηση. Είναι σημαντικό να παρακολουθείτε συγκεκριμένους κλώνους εδώ. Και αν ένας κλώνος έχει κάποια πολύ μεγάλη αλλαγή, αρχίζει να μεγαλώνει, τότε μπορούμε πρώτα να εκδώσουμε μια προειδοποίηση στον χρήστη σχετικά με αυτό ή να σταματήσουμε αμέσως αυτόν τον κλώνο για να μην έχουμε μια κατάσταση αποτυχίας.

Ναι, έχω μια ένθετη ερώτηση. Δηλαδή, πώς διασφαλίζετε τον κύκλο ζωής αυτών των μονάδων; Έχουμε αυτό το πρόβλημα και μια εντελώς ξεχωριστή ιστορία. Πώς συμβαίνει αυτό;

Υπάρχει κάποιο ttl για κάθε κλώνο. Βασικά, έχουμε ένα σταθερό ttl.

Τι, αν όχι μυστικό;

1 ώρα, δηλαδή σε αδράνεια - 1 ώρα. Αν δεν χρησιμοποιείται, τότε το χτυπάμε. Αλλά δεν υπάρχει καμία έκπληξη εδώ, αφού μπορούμε να ανεβάσουμε τον κλώνο σε δευτερόλεπτα. Και αν το χρειαστείτε ξανά, τότε παρακαλώ.

Με ενδιαφέρει επίσης η επιλογή των τεχνολογιών, γιατί, για παράδειγμα, χρησιμοποιούμε πολλές μεθόδους παράλληλα για τον έναν ή τον άλλο λόγο. Γιατί ZFS; Γιατί δεν χρησιμοποίησες το LVM; Αναφέρατε ότι υπήρχαν προβλήματα με το LVM. Ποια ήταν τα προβλήματα; Κατά τη γνώμη μου, η πιο βέλτιστη επιλογή είναι με αποθήκευση, όσον αφορά την απόδοση.

Ποιο είναι το κύριο πρόβλημα με το ZFS; Το γεγονός ότι πρέπει να τρέξετε στον ίδιο κεντρικό υπολογιστή, δηλαδή όλες οι παρουσίες θα βρίσκονται στο ίδιο λειτουργικό σύστημα. Και στην περίπτωση αποθήκευσης, μπορείτε να συνδέσετε διαφορετικό εξοπλισμό. Και το σημείο συμφόρησης είναι μόνο εκείνα τα μπλοκ που βρίσκονται στο σύστημα αποθήκευσης. Και το ζήτημα της επιλογής των τεχνολογιών είναι ενδιαφέρον. Γιατί όχι LVM;

Συγκεκριμένα, μπορούμε να συζητήσουμε το LVM στο meetup. Σχετικά με την αποθήκευση - είναι απλά ακριβό. Μπορούμε να εφαρμόσουμε το σύστημα ZFS οπουδήποτε. Μπορείτε να το αναπτύξετε στον υπολογιστή σας. Μπορείτε απλά να κάνετε λήψη του αποθετηρίου και να το αναπτύξετε. Το ZFS εγκαθίσταται σχεδόν παντού αν μιλάμε για Linux. Δηλαδή, παίρνουμε μια πολύ ευέλικτη λύση. Και εκτός κουτιού, η ZFS δίνει πολλά. Μπορείτε να ανεβάσετε όσα δεδομένα θέλετε, να συνδέσετε μεγάλο αριθμό δίσκων, υπάρχουν στιγμιότυπα. Και, όπως είπα, είναι εύκολο στη διαχείριση. Δηλαδή, φαίνεται πολύ ευχάριστο στη χρήση. Είναι δοκιμασμένος, είναι πολλών ετών. Έχει μια πολύ μεγάλη κοινότητα που μεγαλώνει. Το ZFS είναι μια πολύ αξιόπιστη λύση.

Nikolai Samokhvalov: Μπορώ να σχολιάσω περαιτέρω; Με λένε Νικολάι, συνεργαζόμαστε με τον Ανατόλι. Συμφωνώ ότι η αποθήκευση είναι εξαιρετική. Και ορισμένοι από τους πελάτες μας έχουν Pure Storage κ.λπ.

Ο Anatoly σημείωσε σωστά ότι εστιάζουμε στην αρθρωτή. Και στο μέλλον, μπορείτε να εφαρμόσετε μία διεπαφή - τραβήξτε ένα στιγμιότυπο, δημιουργήστε έναν κλώνο, καταστρέψτε τον κλώνο. Είναι όλα εύκολα. Και η αποθήκευση είναι δροσερή, αν είναι.

Αλλά το ZFS είναι διαθέσιμο σε όλους. Η DelPhix είναι ήδη αρκετά, έχει 300 πελάτες. Από αυτούς, το fortune 100 έχει 50 πελάτες, δηλαδή απευθύνονται στη NASA κλπ. Ήρθε η ώρα να αποκτήσουν όλοι αυτή την τεχνολογία. Και γι' αυτό έχουμε έναν πυρήνα ανοιχτού κώδικα. Έχουμε ένα τμήμα διεπαφής που δεν είναι ανοιχτού κώδικα. Αυτή είναι η πλατφόρμα που θα δείξουμε. Θέλουμε όμως να είναι προσβάσιμο σε όλους. Θέλουμε να κάνουμε μια επανάσταση ώστε όλοι οι δοκιμαστές να σταματήσουν να μαντεύουν σε φορητούς υπολογιστές. Πρέπει να γράψουμε SELECT και αμέσως να δούμε ότι αργεί. Σταματήστε να περιμένετε να σας ενημερώσει το DBA. Εδώ είναι ο βασικός στόχος. Και νομίζω ότι θα φτάσουμε όλοι σε αυτό. Και φτιάχνουμε αυτό το πράγμα για να το έχουν όλοι. Επομένως το ZFS, γιατί θα είναι διαθέσιμο παντού. Ευχαριστώ την κοινότητα για την επίλυση προβλημάτων και για την κατοχή άδειας ανοιχτού κώδικα κ.λπ.*

Χαιρετίσματα! Ευχαριστώ για την αναφορά! Το όνομά μου είναι Maxim. Έχουμε ασχοληθεί με τα ίδια θέματα. Αποφάσισαν μόνοι τους. Πώς μοιράζεστε πόρους μεταξύ αυτών των κλώνων; Κάθε κλώνος μπορεί να κάνει το δικό του ανά πάσα στιγμή: ο ένας δοκιμάζει ένα πράγμα, ο άλλος ένα άλλο, κάποιος δημιουργεί ένα ευρετήριο, κάποιος έχει μια βαριά δουλειά. Και αν μπορείτε ακόμα να διαιρέσετε με CPU, τότε με IO, πώς διαιρείτε; Αυτή είναι η πρώτη ερώτηση.

Και η δεύτερη ερώτηση αφορά την ανομοιότητα των κερκίδων. Ας πούμε ότι έχω ZFS εδώ και όλα είναι ωραία, αλλά ο πελάτης στο prod δεν έχει ZFS, αλλά ext4, για παράδειγμα. Πώς σε αυτή την περίπτωση;

Οι ερωτήσεις είναι πολύ καλές. Ανέφερα λίγο αυτό το πρόβλημα με το γεγονός ότι μοιραζόμαστε πόρους. Και η λύση είναι αυτή. Φανταστείτε ότι δοκιμάζετε στη σκηνή. Μπορείς να έχεις και μια τέτοια κατάσταση την ίδια στιγμή που κάποιος δίνει ένα φορτίο, κάποιος άλλος. Και ως αποτέλεσμα, βλέπετε ακατανόητες μετρήσεις. Ακόμη και το ίδιο πρόβλημα μπορεί να είναι και με την παραγωγή. Όταν θέλετε να ελέγξετε κάποιο αίτημα και να δείτε ότι υπάρχει κάποιο πρόβλημα με αυτό - λειτουργεί αργά, τότε στην πραγματικότητα το πρόβλημα δεν ήταν στο αίτημα, αλλά στο γεγονός ότι υπάρχει κάποιο είδος παράλληλου φορτίου.

Και επομένως, είναι σημαντικό εδώ να εστιάσουμε στο ποιο θα είναι το σχέδιο, ποια βήματα θα κάνουμε στο σχέδιο και πόσα δεδομένα θα συγκεντρώσουμε για αυτό. Το γεγονός ότι οι δίσκοι μας, για παράδειγμα, θα φορτωθούν με κάτι, θα επηρεάσει συγκεκριμένα τον χρονισμό. Αλλά μπορούμε να εκτιμήσουμε πόσο φορτωμένο είναι αυτό το αίτημα με βάση τον όγκο των δεδομένων. Δεν είναι τόσο σημαντικό ότι την ίδια στιγμή θα υπάρχει κάποιο είδος εκτέλεσης.

Έχω δύο ερωτήσεις. Αυτό είναι πολύ ωραίο πράγμα. Υπήρξαν περιπτώσεις όπου τα δεδομένα παραγωγής είναι κρίσιμα, όπως οι αριθμοί πιστωτικών καρτών; Υπάρχει ήδη κάτι έτοιμο ή είναι μια ξεχωριστή εργασία; Και η δεύτερη ερώτηση - υπάρχει κάτι τέτοιο για τη MySQL;

Σχετικά με τα δεδομένα. Θα κάνουμε συσκότιση μέχρι να το κάνουμε. Αλλά αν αναπτύξετε ακριβώς τον Joe, εάν δεν δώσετε πρόσβαση σε προγραμματιστές, τότε δεν υπάρχει πρόσβαση στα δεδομένα. Γιατί; Επειδή ο Τζο δεν δείχνει δεδομένα. Δείχνει μόνο μετρήσεις, σχέδια και τέλος. Αυτό έγινε επίτηδες, γιατί αυτή είναι μια από τις απαιτήσεις του πελάτη μας. Ήθελαν να μπορούν να βελτιστοποιήσουν χωρίς να δίνουν σε όλους πρόσβαση.

Σχετικά με τη MySQL. Αυτό το σύστημα μπορεί να χρησιμοποιηθεί για οτιδήποτε αποθηκεύει κατάσταση στο δίσκο. Και αφού κάνουμε Postgres, τώρα κάνουμε πρώτα όλους τους αυτοματισμούς για την Postgres. Θέλουμε να αυτοματοποιήσουμε τη λήψη δεδομένων από ένα αντίγραφο ασφαλείας. Διαμορφώνουμε σωστά το Postgres. Ξέρουμε πώς να κάνουμε σχέδια να ταιριάζουν κ.λπ.

Επειδή όμως το σύστημα είναι επεκτάσιμο, μπορεί να χρησιμοποιηθεί και για MySQL. Και υπάρχουν τέτοια παραδείγματα. Η Yandex έχει κάτι παρόμοιο, αλλά δεν το δημοσιεύουν πουθενά. Το χρησιμοποιούν μέσα στο Yandex.Metrica. Και υπάρχει απλώς μια ιστορία για τη MySQL. Αλλά οι τεχνολογίες είναι οι ίδιες, ZFS.

Ευχαριστώ για την αναφορά! Έχω επίσης μερικές ερωτήσεις. Αναφέρατε ότι η κλωνοποίηση μπορεί να χρησιμοποιηθεί για αναλύσεις, για παράδειγμα για τη δημιουργία επιπλέον ευρετηρίων εκεί. Μπορείτε να πείτε λίγα περισσότερα για το πώς λειτουργεί;

Και θα κάνω αμέσως τη δεύτερη ερώτηση για την ομοιότητα των κερκίδων, την ομοιότητα των σχεδίων. Το σχέδιο εξαρτάται επίσης από τα στατιστικά στοιχεία που συλλέγει η Postgres. Πώς λύνετε αυτό το πρόβλημα;

Σύμφωνα με τα analytics, δεν υπάρχουν συγκεκριμένες περιπτώσεις, γιατί δεν το έχουμε χρησιμοποιήσει ακόμα, αλλά υπάρχει τέτοια ευκαιρία. Αν μιλάμε για ευρετήρια, τότε φανταστείτε ότι ένα ερώτημα κυνηγάει έναν πίνακα με εκατοντάδες εκατομμύρια εγγραφές και μια στήλη που συνήθως δεν είναι ευρετηριασμένη στην παραγωγή. Και θέλουμε να υπολογίσουμε κάποια δεδομένα εκεί. Εάν αυτό το αίτημα αποσταλεί στο prod, τότε υπάρχει πιθανότητα να είναι απλό στο prod, επειδή το αίτημα θα διεκπεραιωθεί εκεί για ένα λεπτό.

Οκ, ας φτιάξουμε έναν λεπτό κλώνο που δεν είναι τρομερό να σταματήσει για λίγα λεπτά. Και για να κάνουμε πιο άνετη την ανάγνωση των αναλυτικών στοιχείων, θα προσθέσουμε δείκτες για τις στήλες στις οποίες μας ενδιαφέρουν τα δεδομένα.

Το ευρετήριο θα δημιουργείται κάθε φορά;

Μπορείτε να το κάνετε έτσι ώστε να αγγίζουμε τα δεδομένα, να κάνουμε στιγμιότυπα και, στη συνέχεια, να ανακτήσουμε από αυτό το στιγμιότυπο και να προωθήσουμε νέα αιτήματα. Δηλαδή, μπορείτε να το κάνετε έτσι ώστε να μπορείτε να αυξήσετε νέους κλώνους με ήδη επικολλημένους δείκτες.

Όσον αφορά την ερώτηση σχετικά με τα στατιστικά, αν κάνουμε επαναφορά από ένα αντίγραφο ασφαλείας, αν κάνουμε αναπαραγωγή, τότε τα στατιστικά μας θα είναι ακριβώς τα ίδια. Επειδή έχουμε ολόκληρη τη φυσική δομή δεδομένων, δηλαδή, θα φέρουμε τα δεδομένα ως έχουν και με όλες τις στατιστικές μετρήσεις.

Εδώ υπάρχει ένα άλλο πρόβλημα. Εάν χρησιμοποιείτε μια λύση cloud, τότε μόνο λογικές χωματερές είναι διαθέσιμες εκεί, επειδή η Google, η Amazon δεν σας επιτρέπουν να τραβήξετε φυσικό αντίγραφο. Θα υπάρξει τέτοιο πρόβλημα.

Ευχαριστώ για την αναφορά. Υπήρχαν δύο καλές ερωτήσεις εδώ σχετικά με τη MySQL και την κοινή χρήση πόρων. Αλλά, στην πραγματικότητα, όλα καταλήγουν στο γεγονός ότι αυτό δεν είναι ένα θέμα συγκεκριμένου DBMS, αλλά του συστήματος αρχείων στο σύνολό του. Και, κατά συνέπεια, τα θέματα της κοινής χρήσης πόρων θα πρέπει επίσης να επιλυθούν από εκεί, όχι στο τέλος ότι είναι Postgres, αλλά στο σύστημα αρχείων, στον διακομιστή, για παράδειγμα.

Η ερώτησή μου είναι λίγο διαφορετική. Είναι πιο κοντά στη βάση δεδομένων πολλαπλών επιπέδων, όπου υπάρχουν πολλά επίπεδα. Για παράδειγμα, ρυθμίσαμε μια ενημέρωση εικόνας δέκα terabyte, κάνουμε αναπαραγωγή. Και χρησιμοποιούμε ειδικά αυτή τη λύση για βάσεις δεδομένων. Η αναπαραγωγή βρίσκεται σε εξέλιξη, τα δεδομένα ενημερώνονται. Εδώ εργάζονται παράλληλα 100 υπάλληλοι, οι οποίοι εκτοξεύουν συνεχώς αυτές τις διαφορετικές λήψεις. Τι να κάνω? Πώς να βεβαιωθείτε ότι δεν υπάρχει σύγκρουση, ότι κυκλοφόρησαν ένα και μετά άλλαξε το σύστημα αρχείων και όλες αυτές οι εικόνες πήγαν;

Δεν θα πάνε γιατί έτσι λειτουργεί το ZFS. Μπορούμε να κρατήσουμε χωριστά σε ένα νήμα τις αλλαγές του συστήματος αρχείων που οφείλονται στην αναπαραγωγή. Και διατηρήστε τους κλώνους που χρησιμοποιούν οι προγραμματιστές σε παλαιότερες εκδόσεις των δεδομένων. Και λειτουργεί για εμάς, όλα είναι εντάξει με αυτό.

Αποδεικνύεται ότι η ενημέρωση θα πραγματοποιηθεί ως πρόσθετο επίπεδο και όλες οι νέες εικόνες θα μεταφερθούν ήδη, με βάση αυτό το επίπεδο, σωστά;

Από προηγούμενα επίπεδα που ήταν από προηγούμενες επαναλήψεις.

Τα προηγούμενα επίπεδα θα πέσουν, αλλά θα αναφέρονται στο παλιό επίπεδο και θα τραβήξουν νέες εικόνες από το τελευταίο επίπεδο που ελήφθη στην ενημέρωση;

Σε γενικές γραμμές, ναι.

Τότε ως συνέπεια θα έχουμε μέχρι ένα σύκο στρώσεις. Και με τον καιρό θα χρειαστεί να συμπιεστούν;

Ναι όλα είναι σωστά. Υπάρχει κάποιο παράθυρο. Κρατάμε εβδομαδιαία στιγμιότυπα. Εξαρτάται από τον πόρο που έχετε. Εάν έχετε τη δυνατότητα να αποθηκεύσετε πολλά δεδομένα, μπορείτε να αποθηκεύσετε στιγμιότυπα για μεγάλο χρονικό διάστημα. Δεν θα φύγουν από μόνα τους. Δεν θα υπάρξει καταστροφή δεδομένων. Εάν τα στιγμιότυπα είναι ξεπερασμένα, όπως μας φαίνεται, δηλαδή εξαρτάται από την πολιτική της εταιρείας, τότε μπορούμε απλά να τα διαγράψουμε και να ελευθερώσουμε χώρο.

Γεια σας, ευχαριστώ για την αναφορά! Ερώτηση για τον Τζο. Είπατε ότι ο πελάτης δεν ήθελε να δώσει σε όλους πρόσβαση στα δεδομένα. Αυστηρά μιλώντας, εάν ένα άτομο έχει το αποτέλεσμα του Explain Analyze, τότε μπορεί να κοιτάξει τα δεδομένα.

Ειναι ετσι. Για παράδειγμα, μπορούμε να γράψουμε: "SELECT FROM WHERE email = to that". Δηλαδή, δεν θα δούμε τα ίδια τα δεδομένα, αλλά μπορούμε να δούμε κάποια έμμεσα σημάδια. Αυτό πρέπει να γίνει κατανοητό. Αλλά από την άλλη, είναι όλα εκεί. Έχουμε έλεγχο των αρχείων καταγραφής, έχουμε τον έλεγχο άλλων συναδέλφων που βλέπουν επίσης τι κάνουν οι προγραμματιστές. Και αν κάποιος προσπαθήσει να το κάνει αυτό, τότε η υπηρεσία ασφαλείας θα έρθει σε αυτόν και θα ασχοληθεί με αυτό το θέμα.

Καλό απόγευμα Ευχαριστώ για την αναφορά! Έχω μια σύντομη ερώτηση. Εάν η εταιρεία δεν χρησιμοποιεί το Slack, υπάρχει κάποια δέσμευση για αυτό τώρα ή είναι δυνατό για τους προγραμματιστές να αναπτύξουν παρουσίες για να συνδέσουν μια δοκιμαστική εφαρμογή στις βάσεις δεδομένων;

Τώρα υπάρχει ένας σύνδεσμος για το Slack, δηλαδή δεν υπάρχει άλλος αγγελιοφόρος, αλλά θέλω πραγματικά να κάνω υποστήριξη και για άλλους αγγελιοφόρους. Τι μπορείς να κάνεις? Μπορείτε να αναπτύξετε το DB Lab χωρίς τον Joe, να πάτε με τη βοήθεια του REST API ή με τη βοήθεια της πλατφόρμας μας και να δημιουργήσετε κλώνους και να συνδεθείτε με το PSQL. Αλλά αυτό μπορεί να γίνει εάν είστε έτοιμοι να δώσετε στους προγραμματιστές σας πρόσβαση στα δεδομένα, επειδή δεν θα υπάρχει πλέον καμία οθόνη.

Δεν χρειάζομαι αυτό το στρώμα, αλλά χρειάζομαι μια τέτοια ευκαιρία.

Τότε ναι, μπορεί να γίνει.

Πηγή: www.habr.com