Η συνεισφορά της Yandex στις ακόλουθες βάσεις δεδομένων θα επανεξεταστεί.
- Κάντε κλικ στο σπίτι
- Οδύσσεια
- Ανάκτηση σε ένα χρονικό σημείο (WAL-G)
- PostgreSQL (συμπεριλαμβανομένων λογαριασμών, Amcheck, heapcheck)
- Greenplum
Βίντεο:
Γειά σου Κόσμε! Το όνομά μου είναι Andrey Borodin. Και αυτό που κάνω στο Yandex.Cloud είναι να αναπτύσσω ανοιχτές σχεσιακές βάσεις δεδομένων προς το συμφέρον των πελατών Yandex.Cloud και Yandex.Cloud.
Σε αυτήν την ομιλία, θα μιλήσουμε για τις προκλήσεις που αντιμετωπίζουν οι ανοιχτές βάσεις δεδομένων σε κλίμακα. Γιατί είναι σημαντικό? Γιατί μικρά, μικρά προβλήματα που, σαν τα κουνούπια, μετά γίνονται ελέφαντες. Γίνονται μεγάλα όταν έχετε πολλά συμπλέγματα.
Αλλά αυτό δεν είναι το κύριο πράγμα. Συμβαίνουν απίστευτα πράγματα. Πράγματα που συμβαίνουν σε μία στις εκατομμύριο περιπτώσεις. Και σε ένα περιβάλλον cloud, πρέπει να είστε προετοιμασμένοι για αυτό, γιατί τα απίστευτα πράγματα γίνονται πολύ πιθανά όταν κάτι υπάρχει σε κλίμακα.
Αλλά! Ποιο είναι το πλεονέκτημα των ανοιχτών βάσεων δεδομένων; Γεγονός είναι ότι έχετε μια θεωρητική ευκαιρία να αντιμετωπίσετε οποιοδήποτε πρόβλημα. Έχετε τον πηγαίο κώδικα, έχετε γνώσεις προγραμματισμού. Το συνδυάζουμε και δουλεύει.
Ποιες προσεγγίσεις υπάρχουν για την εργασία σε λογισμικό ανοιχτού κώδικα;
- Η πιο απλή προσέγγιση είναι η χρήση λογισμικού. Εάν χρησιμοποιείτε πρωτόκολλα, εάν χρησιμοποιείτε πρότυπα, εάν χρησιμοποιείτε μορφές, εάν γράφετε ερωτήματα σε λογισμικό ανοιχτού κώδικα, τότε το υποστηρίζετε ήδη.
- Μεγαλώνεις το οικοσύστημά του. Κάνεις την πιθανότητα έγκαιρου εντοπισμού ενός σφάλματος μεγαλύτερη. Αυξάνετε την αξιοπιστία αυτού του συστήματος. Αυξάνεις τη διαθεσιμότητα προγραμματιστών στην αγορά. Βελτιώνετε αυτό το λογισμικό. Είστε ήδη ένας συνεισφέρων, αν μόλις καταφέρατε να αποκτήσετε στυλ και ασχοληθήκατε με κάτι εκεί.
- Μια άλλη κατανοητή προσέγγιση είναι η χορηγία λογισμικού ανοιχτού κώδικα. Για παράδειγμα, το γνωστό πρόγραμμα Google Summer of Code, όταν η Google πληρώνει σε μεγάλο αριθμό μαθητών από όλο τον κόσμο κατανοητά χρήματα, ώστε να αναπτύξουν ανοιχτά έργα λογισμικού που πληρούν ορισμένες απαιτήσεις αδειοδότησης.
- Αυτή είναι μια πολύ ενδιαφέρουσα προσέγγιση επειδή επιτρέπει στο λογισμικό να εξελίσσεται χωρίς να απομακρύνει την εστίαση από την κοινότητα. Η Google, ως γίγαντας της τεχνολογίας, δεν λέει ότι θέλουμε αυτή τη δυνατότητα, θέλουμε να διορθώσουμε αυτό το σφάλμα και εδώ πρέπει να ψάξουμε. Η Google λέει: «Κάνε αυτό που κάνεις. Απλώς συνεχίστε να δουλεύετε με τον τρόπο που εργάζεστε και όλα θα πάνε καλά».
- Η επόμενη προσέγγιση για τη συμμετοχή σε ανοιχτό κώδικα είναι η συμμετοχή. Όταν αντιμετωπίζετε πρόβλημα σε λογισμικό ανοιχτού κώδικα και υπάρχουν προγραμματιστές, οι προγραμματιστές σας αρχίζουν να λύνουν τα προβλήματα. Αρχίζουν να κάνουν την υποδομή σας πιο αποτελεσματική, τα προγράμματά σας πιο γρήγορα και πιο αξιόπιστα.
Ένα από τα πιο διάσημα έργα Yandex στον τομέα του λογισμικού ανοιχτού κώδικα είναι το ClickHouse. Αυτή είναι μια βάση δεδομένων που γεννήθηκε ως απάντηση στις προκλήσεις που αντιμετωπίζει το Yandex.Metrica.
Και ως βάση δεδομένων, δημιουργήθηκε σε ανοιχτό κώδικα για να δημιουργηθεί ένα οικοσύστημα και να το αναπτύξει μαζί με άλλους προγραμματιστές (όχι μόνο εντός του Yandex). Και τώρα αυτό είναι ένα μεγάλο έργο στο οποίο συμμετέχουν πολλές διαφορετικές εταιρείες.
Στο Yandex.Cloud, δημιουργήσαμε το ClickHouse πάνω από το Yandex Object Storage, δηλαδή πάνω από το cloud storage.
Γιατί είναι αυτό σημαντικό στο cloud; Επειδή οποιαδήποτε βάση δεδομένων λειτουργεί σε αυτό το τρίγωνο, σε αυτήν την πυραμίδα, σε αυτήν την ιεραρχία τύπων μνήμης. Έχετε γρήγορους αλλά μικρούς καταχωρητές και φθηνούς μεγάλους αλλά αργούς SSD, σκληρούς δίσκους και κάποιες άλλες συσκευές μπλοκ. Και αν είστε αποτελεσματικοί στην κορυφή της πυραμίδας, τότε έχετε μια γρήγορη βάση δεδομένων. Εάν είστε αποτελεσματικοί στο κάτω μέρος αυτής της πυραμίδας, τότε έχετε μια κλίμακα δεδομένων. Και από αυτή την άποψη, η προσθήκη ενός άλλου επιπέδου από κάτω είναι μια λογική προσέγγιση για την αύξηση της επεκτασιμότητας της βάσης δεδομένων.
Πώς θα μπορούσε να γίνει; Αυτό είναι ένα σημαντικό σημείο σε αυτήν την έκθεση.
- Θα μπορούσαμε να εφαρμόσουμε το ClickHouse μέσω MDS. Το MDS είναι μια εσωτερική διεπαφή αποθήκευσης cloud Yandex. Είναι πιο περίπλοκο από το κοινό πρωτόκολλο S3, αλλά είναι πιο κατάλληλο για μια συσκευή μπλοκ. Είναι καλύτερο για την καταγραφή δεδομένων. Απαιτεί περισσότερο προγραμματισμό. Οι προγραμματιστές θα προγραμματίσουν, είναι ακόμη καλό, είναι ενδιαφέρον.
- Το S3 είναι μια πιο κοινή προσέγγιση που κάνει τη διεπαφή απλούστερη με κόστος μικρότερης προσαρμογής σε ορισμένους τύπους φόρτου εργασίας.
Φυσικά, θέλοντας να προσφέρουμε λειτουργικότητα σε ολόκληρο το οικοσύστημα του ClickHouse και να κάνουμε την εργασία που χρειάζεται μέσα στο Yandex.Cloud, αποφασίσαμε να βεβαιωθούμε ότι ολόκληρη η κοινότητα του ClickHouse θα επωφεληθεί από αυτό. Εφαρμόσαμε το ClickHouse μέσω S3, όχι το ClickHouse μέσω MDS. Και αυτό είναι πολλή δουλειά.
Βιβλιογραφικές αναφορές:
"Επίπεδο αφαίρεσης συστήματος αρχείων"
"Ενσωμάτωση AWS SDK S3"
"Βασική υλοποίηση της διεπαφής IDisk για S3"
"Ενσωμάτωση μηχανών αποθήκευσης αρχείων καταγραφής με διεπαφή IDisk"
"Υποστήριξη μηχανισμού καταγραφής για S3 και SeekableReadBuffer"
"Υποστήριξη Storage Stripe Log S3"
"Αρχική υποστήριξη Storage MergeTree για S3"
"Πλήρης υποστήριξη MergeTree για S3"
"Υποστήριξη ReplicatedMergeTree μέσω S3"
"Προσθήκη προεπιλεγμένων διαπιστευτηρίων και προσαρμοσμένων κεφαλίδων για αποθήκευση s3"
"S3 με δυναμική διαμόρφωση διακομιστή μεσολάβησης"
"S3 με διακομιστή μεσολάβησης"
Αυτή είναι μια λίστα αιτημάτων έλξης για την υλοποίηση ενός εικονικού συστήματος αρχείων στο ClickHouse. Αυτός είναι ένας μεγάλος αριθμός αιτημάτων έλξης.
Βιβλιογραφικές αναφορές:
"Βέλτιστη υλοποίηση σκληρών συνδέσμων DiskS3"
"Πελάτης S3 HTTP — Αποφύγετε την αντιγραφή ροής απόκρισης στη μνήμη"
«Αποφύγετε την αντιγραφή ολόκληρης της ροής απόκρισης στη μνήμη στο S3 HTTP
πελάτης"
"Δυνατότητα προσωρινής αποθήκευσης και δημιουργίας ευρετηρίου αρχείων για δίσκο S3"
"Μετακίνηση εξαρτημάτων από το DiskLocal στο DiskS3 παράλληλα"
Όμως η δουλειά δεν τελείωσε εκεί. Μετά τη δημιουργία της δυνατότητας, χρειάστηκε περισσότερη δουλειά για να βελτιστοποιηθεί αυτή η λειτουργία.
Βιβλιογραφικές αναφορές:
"Προσθήκη συμβάντων SelectedRows και SelectedBytes"
"Προσθήκη συμβάντων δημιουργίας προφίλ από αίτημα S3 στο system.events"
"Προσθήκη QueryTimeMicroseconds, SelectQueryTimeMicroseconds και InsertQueryTimeMicroseconds"
Και τότε ήταν απαραίτητο να γίνει διαγνώσιμη, να ρυθμιστεί η παρακολούθηση και να γίνει διαχειρίσιμη.
Και όλα αυτά έγιναν έτσι ώστε ολόκληρη η κοινότητα, ολόκληρο το οικοσύστημα του ClickHouse, να λάβει το αποτέλεσμα αυτής της δουλειάς.
Ας περάσουμε στις βάσεις δεδομένων συναλλαγών, στις βάσεις δεδομένων OLTP, που είναι πιο κοντά σε εμένα προσωπικά.
Αυτό είναι το τμήμα ανάπτυξης DBMS ανοιχτού κώδικα. Αυτοί οι τύποι κάνουν μαγικά δρόμου για να βελτιώσουν τις ανοιχτές βάσεις δεδομένων συναλλαγών.
Ένα από τα έργα, χρησιμοποιώντας ένα παράδειγμα του οποίου μπορούμε να μιλήσουμε για το πώς και τι κάνουμε, είναι το Connection Pooler στο Postgres.
Το Postgres είναι μια βάση δεδομένων διεργασιών. Αυτό σημαίνει ότι η βάση δεδομένων θα πρέπει να έχει όσο το δυνατόν λιγότερες συνδέσεις δικτύου που χειρίζονται συναλλαγές.
Από την άλλη πλευρά, σε ένα περιβάλλον cloud, μια τυπική κατάσταση είναι όταν χίλιες συνδέσεις έρχονται σε ένα σύμπλεγμα ταυτόχρονα. Και η αποστολή του συνεργείου σύνδεσης είναι να συσκευάσει χίλιες συνδέσεις σε έναν μικρό αριθμό συνδέσεων διακομιστή.
Μπορούμε να πούμε ότι ο ομαδοποιητής σύνδεσης είναι ο τηλεφωνητής που αναδιατάσσει τα byte έτσι ώστε να φτάσουν αποτελεσματικά στη βάση δεδομένων.
Δυστυχώς, δεν υπάρχει καλή ρωσική λέξη για το πόλιερ σύνδεσης. Μερικές φορές ονομάζεται συνδέσεις πολυπλέκτη. Εάν ξέρετε πώς να ονομάσετε το συγκρότημα σύνδεσης, τότε φροντίστε να μου πείτε, θα χαρώ πολύ να μιλήσω τη σωστή ρωσική τεχνική γλώσσα.
Ερευνήσαμε πόλες σύνδεσης που ήταν κατάλληλα για ένα διαχειριζόμενο σύμπλεγμα postgres. Και το PgBouncer ήταν η καλύτερη επιλογή για εμάς. Ωστόσο, αντιμετωπίσαμε μια σειρά προβλημάτων με το PgBouncer. Πριν από πολλά χρόνια, ο Volodya Borodin έδωσε αναφορές ότι χρησιμοποιούμε το PgBouncer, μας αρέσουν τα πάντα, αλλά υπάρχουν αποχρώσεις, υπάρχει κάτι για να δουλέψουμε.
Και δουλέψαμε. Διορθώσαμε τα προβλήματα που αντιμετωπίσαμε, διορθώσαμε το Bouncer και προσπαθήσαμε να προωθήσουμε τα αιτήματα έλξης προς τα πάνω. Αλλά το θεμελιώδες single-threading ήταν δύσκολο να εργαστεί κανείς.
Έπρεπε να μαζέψουμε καταρράκτες από μπαλωμένα Bouncers. Όταν έχουμε πολλούς Bouncers με ένα νήμα, οι συνδέσεις στο επάνω στρώμα μεταφέρονται στο εσωτερικό στρώμα των Bouncers. Αυτό είναι ένα σύστημα με κακή διαχείριση που είναι δύσκολο να κατασκευαστεί και να κλιμακωθεί εμπρός και πίσω.
Καταλήξαμε στο συμπέρασμα ότι δημιουργήσαμε το δικό μας pooler σύνδεσης, το οποίο ονομάζεται Odyssey. Το γράψαμε από την αρχή.
Το 2019, στο συνέδριο PgCon, παρουσίασα αυτό το pooler στην κοινότητα προγραμματιστών. Τώρα έχουμε λίγο λιγότερα από 2 αστέρια στο GitHub, δηλαδή το έργο είναι ζωντανό, το έργο είναι δημοφιλές.
Και αν δημιουργήσετε ένα σύμπλεγμα Postgres στο Yandex.Cloud, τότε θα είναι ένα σύμπλεγμα με ενσωματωμένο Odyssey, το οποίο διαμορφώνεται εκ νέου κατά την κλιμάκωση του συμπλέγματος εμπρός ή πίσω.
Τι μάθαμε από αυτό το έργο; Η έναρξη ενός ανταγωνιστικού έργου είναι πάντα ένα επιθετικό βήμα, είναι ένα ακραίο μέτρο όταν λέμε ότι υπάρχουν προβλήματα που δεν λύνονται αρκετά γρήγορα, δεν λύνονται στα χρονικά διαστήματα που θα μας βόλευαν. Αλλά αυτό είναι ένα αποτελεσματικό μέτρο.
Το PgBouncer άρχισε να αναπτύσσεται πιο γρήγορα.
Και τώρα εμφανίστηκαν άλλα έργα. Για παράδειγμα, το pgagroal, το οποίο αναπτύσσεται από προγραμματιστές της Red Hat. Επιδιώκουν παρόμοιους στόχους και εφαρμόζουν παρόμοιες ιδέες, αλλά, φυσικά, με τις δικές τους ιδιαιτερότητες, που είναι πιο κοντά στους προγραμματιστές του pgagroal.
Μια άλλη περίπτωση συνεργασίας με την κοινότητα postgres επανέρχεται σε ένα χρονικό σημείο. Αυτή είναι η ανάκτηση μετά από μια αποτυχία, αυτή είναι η ανάκτηση από ένα αντίγραφο ασφαλείας.
Υπάρχουν πολλά αντίγραφα ασφαλείας και είναι όλα διαφορετικά. Σχεδόν κάθε προμηθευτής Postgres έχει τη δική του εφεδρική λύση.
Εάν πάρετε όλα τα εφεδρικά συστήματα, δημιουργήσετε έναν πίνακα χαρακτηριστικών και υπολογίσετε αστειευόμενοι την ορίζουσα σε αυτόν τον πίνακα, θα είναι μηδέν. Τι σημαίνει αυτό? Τι γίνεται αν πάρετε ένα συγκεκριμένο αρχείο αντιγράφου ασφαλείας, τότε δεν μπορεί να συναρμολογηθεί από κομμάτια όλων των άλλων. Είναι μοναδικό στην εφαρμογή του, είναι μοναδικό στο σκοπό του, είναι μοναδικό στις ιδέες που είναι ενσωματωμένες σε αυτό. Και είναι όλα συγκεκριμένα.
Ενώ εργαζόμασταν σε αυτό το ζήτημα, η CitusData ξεκίνησε το έργο WAL-G. Αυτό είναι ένα εφεδρικό σύστημα που δημιουργήθηκε με προσοχή στο περιβάλλον του cloud. Τώρα το CitusData είναι ήδη μέρος της Microsoft. Και εκείνη τη στιγμή, μας άρεσαν πολύ οι ιδέες που είχαν τεθεί στις αρχικές κυκλοφορίες του WAL-G. Και αρχίσαμε να συνεισφέρουμε σε αυτό το έργο.
Τώρα υπάρχουν πολλές δεκάδες προγραμματιστές σε αυτό το έργο, αλλά οι 10 κορυφαίοι συνεισφέροντες στο WAL-G περιλαμβάνουν 6 Yandexoids. Φέραμε πολλές από τις ιδέες μας εκεί. Και, φυσικά, τα εφαρμόσαμε μόνοι μας, τα δοκιμάσαμε μόνοι μας, τα προωθήσαμε μόνοι μας στην παραγωγή, τα χρησιμοποιούμε μόνοι μας, εμείς οι ίδιοι καταλαβαίνουμε πού να προχωρήσουμε στη συνέχεια, ενώ αλληλεπιδρούμε με τη μεγάλη κοινότητα WAL-G.
Και από την άποψή μας, τώρα αυτό το εφεδρικό σύστημα, λαμβάνοντας υπόψη τις προσπάθειές μας, έχει γίνει το βέλτιστο για περιβάλλον cloud. Αυτό είναι το καλύτερο κόστος δημιουργίας αντιγράφων ασφαλείας Postgres στο cloud.
Τι σημαίνει? Προωθούσαμε μια αρκετά μεγάλη ιδέα: η δημιουργία αντιγράφων ασφαλείας πρέπει να είναι ασφαλής, φθηνή στη λειτουργία και όσο το δυνατόν πιο γρήγορη επαναφορά.
Γιατί να είναι φθηνό να λειτουργήσει; Όταν τίποτα δεν είναι χαλασμένο, δεν πρέπει να ξέρετε ότι έχετε αντίγραφα ασφαλείας. Όλα λειτουργούν καλά, σπαταλάτε όσο το δυνατόν λιγότερη CPU, χρησιμοποιείτε όσο το δυνατόν λιγότερους πόρους του δίσκου σας και στέλνετε όσο το δυνατόν λιγότερα byte στο δίκτυο για να μην παρεμποδίσετε το ωφέλιμο φορτίο των πολύτιμων υπηρεσιών σας.
Και όταν όλα χαλάσουν, για παράδειγμα, ο διαχειριστής έριξε τα δεδομένα, κάτι πήγε στραβά και πρέπει επειγόντως να επιστρέψετε στο παρελθόν, ανακτάτε με όλα τα χρήματα, επειδή θέλετε τα δεδομένα σας να επιστρέψουν γρήγορα και άθικτα.
Και προωθήσαμε αυτή την απλή ιδέα. Και, όπως φαίνεται, καταφέραμε να το εφαρμόσουμε.
Αλλά δεν είναι μόνο αυτό. Θέλαμε ένα ακόμη μικρό πράγμα. Θέλαμε πολλές διαφορετικές βάσεις δεδομένων. Δεν χρησιμοποιούν όλοι οι πελάτες μας το Postgres. Μερικοί άνθρωποι χρησιμοποιούν MySQL, MongoDB. Στην κοινότητα, άλλοι προγραμματιστές έχουν υποστηρίξει το FoundationDB. Και αυτή η λίστα διευρύνεται συνεχώς.
Στην κοινότητα αρέσει η ιδέα της λειτουργίας της βάσης δεδομένων σε ένα διαχειριζόμενο περιβάλλον στο cloud. Και οι προγραμματιστές διατηρούν τις βάσεις δεδομένων τους, για τις οποίες μπορούν να δημιουργηθούν αντίγραφα ασφαλείας ομοιόμορφα μαζί με το Postgres με το εφεδρικό μας σύστημα.
Τι μάθαμε από αυτή την ιστορία; Το προϊόν μας, ως τμήμα ανάπτυξης, δεν είναι γραμμές κώδικα, δεν είναι δηλώσεις, δεν είναι αρχεία. Το προϊόν μας δεν είναι αιτήματα έλξης. Αυτές είναι οι ιδέες που μεταφέρουμε στην κοινότητα. Αυτή είναι η τεχνολογική τεχνογνωσία και η κίνηση της τεχνολογίας προς ένα περιβάλλον cloud.
Υπάρχει μια τέτοια βάση δεδομένων όπως η Postgres. Μου αρέσει περισσότερο ο πυρήνας της Postgres. Ξοδεύω πολύ χρόνο αναπτύσσοντας τον πυρήνα της Postgres με την κοινότητα.
Αλλά εδώ πρέπει να πούμε ότι το Yandex.Cloud έχει μια εσωτερική εγκατάσταση διαχειριζόμενων βάσεων δεδομένων. Και ξεκίνησε εδώ και πολύ καιρό στο Yandex.Mail. Η τεχνογνωσία που οδήγησε τώρα στη διαχείριση Postgres συσσωρεύτηκε όταν η αλληλογραφία ήθελε να μεταφερθεί στην Postgres.
Η αλληλογραφία έχει πολύ παρόμοιες απαιτήσεις με το cloud. Χρειάζεται να είστε σε θέση να κλιμακωθείτε σε απροσδόκητη εκθετική ανάπτυξη σε οποιοδήποτε σημείο των δεδομένων σας. Και η αλληλογραφία είχε ήδη φορτίο με μερικές εκατοντάδες εκατομμύρια γραμματοκιβώτια ενός τεράστιου αριθμού χρηστών που υποβάλλουν συνεχώς πολλά αιτήματα.
Και αυτή ήταν μια αρκετά σοβαρή πρόκληση για την ομάδα που ανέπτυξε την Postgres. Τότε, τυχόν προβλήματα που αντιμετωπίσαμε αναφέρθηκαν στην κοινότητα. Και αυτά τα προβλήματα διορθώθηκαν και διορθώθηκαν από την κοινότητα σε ορισμένα σημεία ακόμη και στο επίπεδο πληρωμένης υποστήριξης για κάποιες άλλες βάσεις δεδομένων και ακόμη καλύτερα. Δηλαδή, μπορείτε να στείλετε μια επιστολή στον χάκερ PgSQL και να λάβετε απάντηση εντός 40 λεπτών. Η υποστήριξη επί πληρωμή σε ορισμένες βάσεις δεδομένων μπορεί να πιστεύει ότι υπάρχουν πράγματα με μεγαλύτερη προτεραιότητα από το σφάλμα σας.
Τώρα η εσωτερική εγκατάσταση του Postgres είναι μερικά petabyte δεδομένων. Αυτά είναι μερικά εκατομμύρια αιτήματα ανά δευτερόλεπτο. Αυτά είναι χιλιάδες συστάδες. Είναι πολύ μεγάλης κλίμακας.
Υπάρχει όμως μια απόχρωση. Δεν ζει σε φανταχτερούς δίσκους δικτύου, αλλά σε αρκετά απλό υλικό. Και υπάρχει ένα δοκιμαστικό περιβάλλον ειδικά για ενδιαφέροντα νέα πράγματα.
Και σε μια συγκεκριμένη στιγμή στο περιβάλλον δοκιμής λάβαμε ένα μήνυμα που υποδεικνύει ότι παραβιάστηκαν τα εσωτερικά αμετάβλητα των ευρετηρίων της βάσης δεδομένων.
Ένα αμετάβλητο είναι κάποιο είδος σχέσης που περιμένουμε να διατηρείται πάντα.
Μια πολύ κρίσιμη κατάσταση για εμάς. Υποδεικνύει ότι ορισμένα δεδομένα μπορεί να έχουν χαθεί. Και η απώλεια δεδομένων είναι κάτι εντελώς καταστροφικό.
Η γενική ιδέα που ακολουθούμε στις διαχειριζόμενες βάσεις δεδομένων είναι ότι ακόμη και με προσπάθεια, θα είναι δύσκολο να χαθούν δεδομένα. Ακόμα κι αν τα αφαιρέσετε σκόπιμα, θα χρειαστεί να αγνοήσετε την απουσία τους για μεγάλο χρονικό διάστημα. Η ασφάλεια των δεδομένων είναι μια θρησκεία που ακολουθούμε αρκετά επιμελώς.
Και εδώ προκύπτει μια κατάσταση που υποδηλώνει ότι μπορεί να υπάρξει μια κατάσταση για την οποία μπορεί να μην είμαστε προετοιμασμένοι. Και αρχίσαμε να προετοιμαζόμαστε για αυτήν την κατάσταση.
Το πρώτο πράγμα που κάναμε ήταν να θάψουμε τα κούτσουρα από αυτές τις χιλιάδες συστάδες. Βρήκαμε ποια από τα συμπλέγματα βρίσκονταν σε δίσκους με προβληματικό υλικολογισμικό που έχανε ενημερώσεις σελίδας δεδομένων. Σημειώθηκαν όλοι οι κωδικοί δεδομένων Postgres. Και επισημάναμε εκείνα τα μηνύματα που υποδεικνύουν παραβιάσεις εσωτερικών αμετάβλητων με κώδικα που έχει σχεδιαστεί για τον εντοπισμό καταστροφής δεδομένων.
Αυτό το patch έγινε πρακτικά αποδεκτό από την κοινότητα χωρίς πολλή συζήτηση, γιατί σε κάθε συγκεκριμένη περίπτωση ήταν προφανές ότι κάτι κακό είχε συμβεί και έπρεπε να αναφερθεί στο αρχείο καταγραφής.
Μετά από αυτό, φτάσαμε στο σημείο ότι έχουμε παρακολούθηση που σαρώνει τα αρχεία καταγραφής. Και σε περίπτωση ύποπτων μηνυμάτων, ξυπνά τον αξιωματικό υπηρεσίας, και ο αξιωματικός υπηρεσίας το επισκευάζει.
Αλλά! Η σάρωση αρχείων καταγραφής είναι μια φθηνή λειτουργία σε ένα σύμπλεγμα και καταστροφικά ακριβή για χίλια συμπλέγματα.
Γράψαμε μια επέκταση που ονομάζεται . Δημιουργεί μια προβολή της βάσης δεδομένων στην οποία μπορείτε να επιλέξετε οικονομικά και γρήγορα στατιστικά στοιχεία για σφάλματα του παρελθόντος. Και αν χρειαστεί να ξυπνήσουμε τον αξιωματικό υπηρεσίας, τότε θα το μάθουμε χωρίς να σαρώσουμε αρχεία gigabyte, αλλά εξάγοντας μερικά byte από τον πίνακα κατακερματισμού.
Αυτή η επέκταση έχει υιοθετηθεί, για παράδειγμα, στο αποθετήριο για . Εάν θέλετε να το χρησιμοποιήσετε, μπορείτε να το εγκαταστήσετε μόνοι σας. Φυσικά είναι ανοιχτού κώδικα.
Αλλά δεν είναι μόνο αυτό. Αρχίσαμε να χρησιμοποιούμε το Amcheck, μια επέκταση που δημιουργήθηκε από κοινότητα, για να βρούμε αμετάβλητες παραβιάσεις σε ευρετήρια.
Και ανακαλύψαμε ότι αν το χειριστείτε σε κλίμακα, υπάρχουν σφάλματα. Αρχίσαμε να τα διορθώνουμε. Οι διορθώσεις μας έγιναν δεκτές.
Ανακαλύψαμε ότι αυτή η επέκταση δεν μπορεί να αναλύσει δείκτες GiST & GIT. Τους κάναμε να στηρίξουν. Αλλά αυτή η υποστήριξη εξακολουθεί να συζητείται από την κοινότητα, επειδή αυτή είναι μια σχετικά νέα λειτουργικότητα και υπάρχουν πολλές λεπτομέρειες εκεί.
Και ανακαλύψαμε επίσης ότι κατά τον έλεγχο των ευρετηρίων για παραβιάσεις στον οδηγό αναπαραγωγής, στον κύριο, όλα λειτουργούν καλά, αλλά στα αντίγραφα, στον ακόλουθο, η αναζήτηση για διαφθορά δεν είναι τόσο αποτελεσματική. Δεν ελέγχονται όλα τα αμετάβλητα. Και ένα αμετάβλητο μας ενόχλησε πολύ. Και περάσαμε ενάμιση χρόνο επικοινωνώντας με την κοινότητα για να ενεργοποιήσουμε αυτόν τον έλεγχο σε αντίγραφα.
Γράψαμε κώδικα που πρέπει να ακολουθεί όλα τα... πρωτόκολλα. Συζητήσαμε αυτό το patch για αρκετό καιρό με τον Peter Gaghan από το Crunchy Data. Έπρεπε να τροποποιήσει ελαφρώς το υπάρχον B-tree στο Postgres για να αποδεχτεί αυτό το patch. Έγινε δεκτός. Και τώρα ο έλεγχος των ευρετηρίων σε αντίγραφα έχει γίνει επίσης αρκετά αποτελεσματικός για τον εντοπισμό των παραβιάσεων που αντιμετωπίσαμε. Δηλαδή, αυτές είναι οι παραβιάσεις που μπορεί να προκληθούν από σφάλματα στο υλικολογισμικό του δίσκου, σφάλματα στο Postgres, σφάλματα στον πυρήνα του Linux και προβλήματα υλικού. Ένας αρκετά εκτενής κατάλογος των πηγών προβλημάτων για τα οποία προετοιμαζόμασταν.
Αλλά εκτός από τα ευρετήρια, υπάρχει ένα μέρος όπως το σωρό, δηλαδή το μέρος όπου αποθηκεύονται τα δεδομένα. Και δεν υπάρχουν πολλά αμετάβλητα που θα μπορούσαν να ελεγχθούν.
Έχουμε μια επέκταση που ονομάζεται Heapcheck. Αρχίσαμε να το αναπτύσσουμε. Και παράλληλα, μαζί με εμάς, η εταιρεία EnterpriseDB άρχισε επίσης να γράφει μια ενότητα, την οποία ονόμασαν Heapcheck με τον ίδιο τρόπο. Μόνο εμείς το λέγαμε PgHeapcheck και εκείνοι μόλις το έλεγαν Heapcheck. Το έχουν με παρόμοιες λειτουργίες, ελαφρώς διαφορετική υπογραφή, αλλά με τις ίδιες ιδέες. Τα εφάρμοσαν λίγο καλύτερα σε κάποια σημεία. Και το δημοσίευσαν σε ανοιχτό κώδικα πριν.
Και τώρα αναπτύσσουμε την επέκτασή τους, γιατί δεν είναι πλέον η επέκτασή τους, αλλά η επέκταση της κοινότητας. Και στο μέλλον, αυτό είναι μέρος του πυρήνα που θα παρέχεται σε όλους ώστε να γνωρίζουν εκ των προτέρων για μελλοντικά προβλήματα.
Σε ορισμένα σημεία, καταλήξαμε ακόμη και στο συμπέρασμα ότι έχουμε ψευδώς θετικά στοιχεία στα συστήματα παρακολούθησης. Για παράδειγμα, το σύστημα 1C. Όταν χρησιμοποιεί μια βάση δεδομένων, η Postgres μερικές φορές γράφει δεδομένα σε αυτήν που μπορεί να διαβάσει, αλλά το pg_dump δεν μπορεί να διαβάσει.
Αυτή η κατάσταση έμοιαζε με διαφθορά στο σύστημα ανίχνευσης προβλημάτων. Ο αξιωματικός υπηρεσίας ξύπνησε. Ο αξιωματικός υπηρεσίας κοίταξε τι συνέβαινε. Μετά από λίγο ήρθε ένας πελάτης και είπε ότι έχω προβλήματα. Ο συνοδός εξήγησε ποιο ήταν το πρόβλημα. Αλλά το πρόβλημα βρίσκεται στον πυρήνα της Postgres.
Βρήκα μια συζήτηση σχετικά με αυτό το χαρακτηριστικό. Και έγραψε ότι συναντήσαμε αυτό το χαρακτηριστικό και ήταν δυσάρεστο, ένα άτομο ξύπνησε τη νύχτα για να καταλάβει τι ήταν.
Η κοινότητα απάντησε, «Ω, πρέπει πραγματικά να το διορθώσουμε».
Έχω μια απλή αναλογία. Εάν περπατάτε με ένα παπούτσι που έχει έναν κόκκο άμμου μέσα, τότε, κατ 'αρχήν, μπορείτε να προχωρήσετε - δεν υπάρχει πρόβλημα. Αν πουλάς μπότες σε χιλιάδες ανθρώπους, τότε ας φτιάξουμε μπότες χωρίς άμμο καθόλου. Και αν ένας από τους χρήστες των παπουτσιών σας πρόκειται να τρέξει έναν μαραθώνιο, τότε θέλετε να φτιάξετε πολύ καλά παπούτσια και στη συνέχεια να τα κλιμακώσετε σε όλους τους χρήστες σας. Και τέτοιοι απροσδόκητοι χρήστες βρίσκονται πάντα στο περιβάλλον cloud. Υπάρχουν πάντα χρήστες που εκμεταλλεύονται το σύμπλεγμα με κάποιο πρωτότυπο τρόπο. Πρέπει πάντα να προετοιμάζεστε για αυτό.
Τι μάθαμε εδώ; Μάθαμε ένα απλό πράγμα: το πιο σημαντικό είναι να εξηγήσουμε στην κοινότητα ότι υπάρχει πρόβλημα. Εάν η κοινότητα έχει αναγνωρίσει το πρόβλημα, τότε προκύπτει φυσικός ανταγωνισμός για την επίλυση του προβλήματος. Γιατί όλοι θέλουν να λύσουν ένα σημαντικό πρόβλημα. Όλοι οι πωλητές, όλοι οι χάκερ καταλαβαίνουν ότι οι ίδιοι μπορούν να πατήσουν αυτή τη γκανιότα, οπότε θέλουν να τους εξαφανίσουν.
Εάν εργάζεστε σε ένα πρόβλημα, αλλά δεν ενοχλεί κανέναν εκτός από εσάς, αλλά το εργάζεστε συστηματικά και τελικά θεωρείται πρόβλημα, τότε το αίτημα έλξης σας θα γίνει σίγουρα αποδεκτό. Η ενημέρωση κώδικα θα γίνει αποδεκτή, οι βελτιώσεις σας ή ακόμα και τα αιτήματα για βελτιώσεις θα ελεγχθούν από την κοινότητα. Στο τέλος της ημέρας, κάνουμε τη βάση δεδομένων καλύτερη ο ένας για τον άλλον.
Μια ενδιαφέρουσα βάση δεδομένων είναι η Greenplum. Είναι μια εξαιρετικά παράλληλη βάση δεδομένων που βασίζεται στη βάση κωδικών Postgres, την οποία γνωρίζω πολύ καλά.
Και η Greenplum έχει ενδιαφέρουσα λειτουργικότητα - προσαρτήστε βελτιστοποιημένους πίνακες. Αυτοί είναι πίνακες στους οποίους μπορείτε να προσθέσετε γρήγορα. Μπορούν να είναι είτε στηλώδεις είτε σε σειρά.
Αλλά δεν υπήρχε ομαδοποίηση, δηλαδή δεν υπήρχε λειτουργία όπου μπορείτε να τακτοποιήσετε τα δεδομένα που βρίσκονται στον πίνακα σύμφωνα με τη σειρά που βρίσκεται σε ένα από τα ευρετήρια.
Τα παιδιά από το ταξί ήρθαν κοντά μου και μου είπαν: «Αντρέι, ξέρεις την Πόστγκρες. Και εδώ είναι σχεδόν το ίδιο. Εναλλαγή σε 20 λεπτά. Το παίρνεις και το κάνεις». Σκέφτηκα ότι ναι, ξέρω την Postgres, αλλάζοντας για 20 λεπτά - πρέπει να το κάνω αυτό.
Αλλά όχι, δεν ήταν 20 λεπτά, το έγραψα σε μήνες. Στο συνέδριο PgConf.Russia, πλησίασα τον Heikki Linakangas από το Pivotal και ρώτησα: «Υπάρχουν προβλήματα με αυτό; Γιατί δεν υπάρχει προσθήκη βελτιστοποιημένης ομαδοποίησης πινάκων;» Λέει: «Παίρνετε τα δεδομένα. Τακτοποιείς, αναδιατάσσεις. Είναι απλώς μια δουλειά». Εγώ: "Ω, ναι, απλά πρέπει να το πάρεις και να το κάνεις." Λέει: «Ναι, χρειαζόμαστε ελεύθερα χέρια για να το κάνουμε αυτό». Σκέφτηκα ότι πρέπει οπωσδήποτε να το κάνω αυτό.
Και λίγους μήνες αργότερα υπέβαλα ένα αίτημα έλξης που υλοποιούσε αυτή τη λειτουργία. Αυτό το αίτημα έλξης εξετάστηκε από το Pivotal μαζί με την κοινότητα. Φυσικά, υπήρχαν σφάλματα.
Αλλά το πιο ενδιαφέρον είναι ότι όταν συγχωνεύτηκε αυτό το αίτημα έλξης, εντοπίστηκαν σφάλματα στο ίδιο το Greenplum. Διαπιστώσαμε ότι οι πίνακες σωρού μερικές φορές διακόπτουν τη συναλλακτικότητα όταν συγκεντρώνονται. Και αυτό είναι κάτι που πρέπει να διορθωθεί. Και είναι στο μέρος που μόλις άγγιξα. Και η φυσική μου αντίδραση ήταν – εντάξει, επιτρέψτε μου να το κάνω κι αυτό.
Διόρθωσα αυτό το σφάλμα. Έστειλε ένα αίτημα έλξης στους επισκευαστές. Σκοτώθηκε.
Μετά από αυτό αποδείχθηκε ότι αυτή η λειτουργικότητα πρέπει να αποκτηθεί στην έκδοση Greenplum για το PostgreSQL 12. Δηλαδή, η 20λεπτη περιπέτεια συνεχίζεται με νέες ενδιαφέρουσες περιπέτειες. Ήταν ενδιαφέρον να αγγίξουμε την τρέχουσα εξέλιξη, όπου η κοινότητα κόβει νέα και πιο σημαντικά χαρακτηριστικά. Είναι παγωμένο.
Αλλά δεν τελείωσε εκεί. Μετά από όλα, αποδείχθηκε ότι έπρεπε να γράψουμε τεκμηρίωση για όλα αυτά.
Άρχισα να γράφω τεκμηρίωση. Ευτυχώς, ήρθαν και οι ντοκιμαντέρ από το Pivotal. Τα αγγλικά είναι η μητρική τους γλώσσα. Με βοήθησαν με την τεκμηρίωση. Μάλιστα, οι ίδιοι ξαναέγραψαν αυτό που πρότεινα σε πραγματικά αγγλικά.
Και εδώ, όπως φαίνεται, η περιπέτεια τελείωσε. Και ξέρετε τι έγινε τότε; Τα παιδιά από το ταξί ήρθαν κοντά μου και μου είπαν: «Υπάρχουν ακόμα δύο περιπέτειες, η καθεμία για 10 λεπτά». Και τι να τους πω; Είπα ότι τώρα θα δώσω μια αναφορά σε κλίμακα, μετά θα δούμε τις περιπέτειές σας, γιατί αυτή είναι μια ενδιαφέρουσα δουλειά.
Τι μάθαμε από αυτή την υπόθεση; Επειδή η εργασία με ανοιχτό κώδικα σημαίνει πάντα εργασία με ένα συγκεκριμένο άτομο, λειτουργεί πάντα με την κοινότητα. Γιατί σε κάθε στάδιο δούλεψα με κάποιον προγραμματιστή, κάποιον δοκιμαστή, κάποιον χάκερ, κάποιον ντοκιμαντέρ, κάποιον αρχιτέκτονα. Δεν δούλεψα με την Greenplum, δούλεψα με ανθρώπους γύρω από την Greenplum.
Αλλά! Υπάρχει ένα άλλο σημαντικό σημείο - είναι απλώς δουλειά. Δηλαδή έρχεσαι, πίνεις καφέ, γράφεις κώδικα. Όλα τα είδη των απλών αμετάβλητων λειτουργούν. Κάντε το κανονικά - θα είναι μια χαρά! Και είναι πολύ ενδιαφέρουσα δουλειά. Υπάρχει ένα αίτημα για αυτήν την εργασία από πελάτες Yandex.Cloud, χρήστες των συμπλεγμάτων μας τόσο εντός όσο και εκτός Yandex. Και νομίζω ότι θα αυξηθεί ο αριθμός των έργων στα οποία συμμετέχουμε και θα αυξηθεί και το βάθος της εμπλοκής μας.
Αυτό είναι όλο. Ας περάσουμε στις ερωτήσεις.
Συνεδρία ερωτήσεων
Γειά σου! Έχουμε άλλη μια συνάντηση ερωτήσεων και απαντήσεων. Και στο στούντιο ο Αντρέι Μποροντίν. Αυτό είναι το άτομο που μόλις σας είπε για τη συνεισφορά του Yandex.Cloud και του Yandex στον ανοιχτό κώδικα. Η έκθεσή μας τώρα δεν αφορά αποκλειστικά το Cloud, αλλά ταυτόχρονα βασιζόμαστε σε τέτοιες τεχνολογίες. Χωρίς αυτό που κάνατε μέσα στο Yandex, δεν θα υπήρχε υπηρεσία στο Yandex.Cloud, επομένως σας ευχαριστώ προσωπικά από εμένα. Και η πρώτη ερώτηση από την εκπομπή: «Ποιο είναι γραμμένο το καθένα από τα έργα που αναφέρατε;»
Το εφεδρικό σύστημα στο WAL-G είναι γραμμένο στο Go. Αυτό είναι ένα από τα νεότερα έργα που έχουμε δουλέψει. Είναι κυριολεκτικά μόλις 3 ετών. Και μια βάση δεδομένων συχνά αφορά την αξιοπιστία. Και αυτό σημαίνει ότι οι βάσεις δεδομένων είναι αρκετά παλιές και συνήθως είναι γραμμένες σε C. Το έργο Postgres ξεκίνησε πριν από περίπου 30 χρόνια. Τότε το C89 ήταν η σωστή επιλογή. Και είναι γραμμένο το Postgres. Οι πιο σύγχρονες βάσεις δεδομένων όπως το ClickHouse είναι συνήθως γραμμένες σε C++. Όλη η ανάπτυξη του συστήματος βασίζεται σε C και C++.
Μια ερώτηση από τον οικονομικό μας διευθυντή, ο οποίος είναι υπεύθυνος για τα έξοδα στο Cloud: "Γιατί το Cloud ξοδεύει χρήματα για την υποστήριξη ανοιχτού κώδικα;"
Υπάρχει μια απλή απάντηση για τον οικονομικό διευθυντή εδώ. Αυτό το κάνουμε για να βελτιώσουμε τις υπηρεσίες μας. Με ποιους τρόπους μπορούμε να τα πάμε καλύτερα; Μπορούμε να κάνουμε τα πράγματα πιο αποτελεσματικά, πιο γρήγορα και να κάνουμε τα πράγματα πιο κλιμακωτά. Αλλά για εμάς, αυτή η ιστορία αφορά κυρίως την αξιοπιστία. Για παράδειγμα, σε ένα εφεδρικό σύστημα ελέγχουμε το 100% των ενημερώσεων κώδικα που ισχύουν για αυτό. Ξέρουμε ποιος είναι ο κωδικός. Και είμαστε πιο άνετοι να κυκλοφορήσουμε νέες εκδόσεις στην παραγωγή. Δηλαδή, πρώτα από όλα, πρόκειται για αυτοπεποίθηση, για ετοιμότητα για ανάπτυξη και για αξιοπιστία
Μια άλλη ερώτηση: "Διαφέρουν οι απαιτήσεις των εξωτερικών χρηστών που ζουν στο Yandex.Cloud από τους εσωτερικούς χρήστες που ζουν στο εσωτερικό Cloud;"
Το προφίλ φόρτωσης είναι, φυσικά, διαφορετικό. Αλλά από τη σκοπιά του τμήματός μου, όλες οι ιδιαίτερες και ενδιαφέρουσες θήκες δημιουργούνται σε ένα μη τυποποιημένο φορτίο. Προγραμματιστές με φαντασία, προγραμματιστές που κάνουν το απροσδόκητο, είναι εξίσου πιθανό να βρεθούν τόσο εσωτερικά όσο και εξωτερικά. Από αυτή την άποψη, είμαστε όλοι περίπου ίδιοι. Και, πιθανώς, το μόνο σημαντικό χαρακτηριστικό μέσα στη λειτουργία των βάσεων δεδομένων Yandex θα είναι ότι μέσα στο Yandex έχουμε μια διδασκαλία. Κάποια στιγμή, κάποια ζώνη διαθεσιμότητας μπαίνει εντελώς στη σκιά και όλες οι υπηρεσίες Yandex πρέπει με κάποιο τρόπο να συνεχίσουν να λειτουργούν παρά αυτό. Αυτή είναι μια μικρή διαφορά. Αλλά δημιουργεί πολλή ανάπτυξη έρευνας στη διεπαφή της βάσης δεδομένων και της στοίβας δικτύου. Διαφορετικά, οι εξωτερικές και εσωτερικές εγκαταστάσεις δημιουργούν τα ίδια αιτήματα για χαρακτηριστικά και παρόμοια αιτήματα για τη βελτίωση της αξιοπιστίας και της απόδοσης.
Επόμενη ερώτηση: "Πώς αισθάνεστε προσωπικά για το γεγονός ότι πολλά από αυτά που κάνετε χρησιμοποιούνται από άλλα Σύννεφα;" Δεν θα ονομάσουμε συγκεκριμένα, αλλά πολλά έργα που έγιναν στο Yandex.Cloud χρησιμοποιούνται στα σύννεφα άλλων ανθρώπων.
Αυτό είναι ωραίο. Πρώτον, είναι ένα σημάδι ότι έχουμε κάνει κάτι σωστά. Και ξύνει το εγώ. Και είμαστε πιο σίγουροι ότι πήραμε τη σωστή απόφαση. Από την άλλη, αυτή είναι η ελπίδα ότι στο μέλλον αυτό θα μας φέρει νέες ιδέες, νέα αιτήματα από τρίτους χρήστες. Τα περισσότερα ζητήματα στο GitHub δημιουργούνται από μεμονωμένους διαχειριστές συστήματος, μεμονωμένους DBA, μεμονωμένους αρχιτέκτονες, μεμονωμένους μηχανικούς, αλλά μερικές φορές άτομα με συστηματική εμπειρία έρχονται και λένε ότι στο 30% ορισμένων περιπτώσεων έχουμε αυτό το πρόβλημα και ας σκεφτούμε πώς να το λύσουμε. Αυτό είναι που περιμένουμε περισσότερο. Ανυπομονούμε να μοιραστούμε εμπειρίες με άλλες πλατφόρμες cloud.
Μίλησες πολύ για τον μαραθώνιο. Ξέρω ότι έτρεξες έναν μαραθώνιο στη Μόσχα. Σαν άποτέλεσμα? Ξεπέρασε τα παιδιά από την PostgreSQL;
Όχι, ο Όλεγκ Μπαρτούνοφ τρέχει πολύ γρήγορα. Τελείωσε μια ώρα μπροστά μου. Γενικά, είμαι ευχαριστημένος με το πόσο μακριά έφτασα. Για μένα, το να τελειώσω ήταν ένα επίτευγμα. Συνολικά, είναι εκπληκτικό το γεγονός ότι υπάρχουν τόσοι πολλοί δρομείς στην κοινότητα των postgres. Μου φαίνεται ότι υπάρχει κάποιο είδος σχέσης μεταξύ των αερόβιων αθλημάτων και της επιθυμίας για προγραμματισμό συστημάτων.
Λέτε να μην υπάρχουν δρομείς στο ClickHouse;
Ξέρω σίγουρα ότι είναι εκεί. Το ClickHouse είναι επίσης μια βάση δεδομένων. Παρεμπιπτόντως, ο Όλεγκ μου γράφει τώρα: "Πάμε για τρέξιμο μετά την αναφορά;" Είναι θαυμάσια ιδέα.
Μια άλλη ερώτηση από την εκπομπή από τον Νικήτα: "Γιατί διορθώσατε μόνοι σας το σφάλμα στο Greenplum και δεν το δώσατε σε juniors;" Είναι αλήθεια ότι δεν είναι πολύ σαφές ποιο είναι το σφάλμα και σε ποια υπηρεσία, αλλά πιθανώς εννοεί αυτό για το οποίο μιλήσατε.
Ναι, καταρχήν, θα μπορούσε να είχε δοθεί σε κάποιον. Ήταν απλώς ο κωδικός που μόλις άλλαξα. Και ήταν φυσικό να συνεχίσω να το κάνω αμέσως. Καταρχήν, η ιδέα της ανταλλαγής εμπειρογνωμοσύνης με την ομάδα είναι καλή ιδέα. Σίγουρα θα μοιραστούμε τις εργασίες της Greenplum μεταξύ όλων των μελών του τμήματός μας.
Μιας και μιλάμε για juniors, ιδού μια ερώτηση. Το άτομο αποφάσισε να δημιουργήσει το πρώτο commit στο Postgres. Τι χρειάζεται να κάνει για να κάνει την πρώτη δέσμευση;
Αυτή είναι μια ενδιαφέρουσα ερώτηση: "Πού να ξεκινήσω;" Συνήθως είναι αρκετά δύσκολο να ξεκινήσετε με κάτι στον πυρήνα. Στο Postgres, για παράδειγμα, υπάρχει μια λίστα εργασιών. Αλλά στην πραγματικότητα, αυτό είναι ένα φύλλο αυτού που προσπάθησαν να κάνουν, αλλά δεν τα κατάφεραν. Αυτά είναι περίπλοκα πράγματα. Και συνήθως μπορείτε να βρείτε κάποια βοηθητικά προγράμματα στο οικοσύστημα, κάποιες επεκτάσεις που μπορούν να βελτιωθούν, που προσελκύουν λιγότερη προσοχή από τους προγραμματιστές πυρήνα. Και, κατά συνέπεια, υπάρχουν περισσότερα σημεία ανάπτυξης εκεί. Στο πρόγραμμα Google Summer of code, κάθε χρόνο η κοινότητα postgres προβάλλει πολλά διαφορετικά θέματα που θα μπορούσαν να αντιμετωπιστούν. Φέτος είχαμε, νομίζω, τρεις μαθητές. Κάποιος έγραψε ακόμη και στο WAL-G για θέματα που είναι σημαντικά για την Yandex. Στο Greenplum, όλα είναι πιο απλά από ό,τι στην κοινότητα Postgres, επειδή οι χάκερ της Greenplum αντιμετωπίζουν πολύ καλά τα αιτήματα έλξης και αρχίζουν να ελέγχουν αμέσως. Η αποστολή ενός patch στην Postgres είναι θέμα μηνών, αλλά η Greenplum θα έρθει σε μια μέρα και θα δει τι έχετε κάνει. Ένα άλλο πράγμα είναι ότι η Greenplum πρέπει να λύσει τα τρέχοντα προβλήματα. Το Greenplum δεν χρησιμοποιείται ευρέως, επομένως η εύρεση του προβλήματός σας είναι αρκετά δύσκολη. Και πρώτα απ 'όλα, πρέπει να λύσουμε προβλήματα, φυσικά.
Πηγή: www.habr.com