HighLoad++ Μόσχα 2018, Αίθουσα Συνεδρίων. 9 Νοεμβρίου, 15:00
Περιλήψεις και παρουσίαση:
Yuri Nasretdinov (VKontakte): η αναφορά θα μιλήσει για την εμπειρία της εφαρμογής του ClickHouse στην εταιρεία μας - γιατί το χρειαζόμαστε, πόσα δεδομένα αποθηκεύουμε, πώς τα γράφουμε κ.λπ.
Πρόσθετα υλικά:
Γιούρι Νασρεντίνοφ: - Γεια σε όλους! Ονομάζομαι Yuri Nasretdinov, όπως έχω ήδη συστηθεί. Δουλεύω στο VKontakte. Θα μιλήσω για το πώς εισάγουμε δεδομένα στο ClickHouse από τον στόλο των διακομιστών μας (δεκάδες χιλιάδες).
Τι είναι τα κούτσουρα και γιατί τα συλλέγουμε;
Τι θα σας πούμε: τι κάναμε, γιατί χρειαζόμασταν το "ClickHouse", αντίστοιχα, γιατί το επιλέξαμε, τι είδους απόδοση μπορείτε περίπου να αποκτήσετε χωρίς να ρυθμίσετε κάτι ειδικά. Θα σας πω περαιτέρω για πίνακες buffer, για τα προβλήματα που είχαμε με αυτούς και για τις λύσεις μας που αναπτύξαμε από ανοιχτό κώδικα - KittenHouse και Lighthouse.
Γιατί χρειαζόταν να κάνουμε τίποτα απολύτως (όλα είναι πάντα καλά στο VKontakte, σωστά;). Θέλαμε να συλλέξουμε αρχεία καταγραφής εντοπισμού σφαλμάτων (και υπήρχαν εκατοντάδες terabyte δεδομένων εκεί), ίσως με κάποιο τρόπο θα ήταν πιο βολικό να υπολογίζουμε στατιστικά. και έχουμε ένα στόλο δεκάδων χιλιάδων διακομιστών από τους οποίους πρέπει να γίνουν όλα αυτά.
Γιατί αποφασίσαμε; Μάλλον είχαμε λύσεις για την αποθήκευση κορμών. Εδώ - υπάρχει ένα τέτοιο δημόσιο "Backend VK". Συνιστώ ανεπιφύλακτα να εγγραφείτε σε αυτό.
Τι είναι τα κούτσουρα; Αυτή είναι μια μηχανή που επιστρέφει κενές συστοιχίες. Οι κινητήρες στο VK είναι αυτό που άλλοι αποκαλούν microservices. Και εδώ είναι ένα χαμογελαστό αυτοκόλλητο (αρκετά πολλά likes). Πως και έτσι? Λοιπόν, ακούστε περαιτέρω!
Τι μπορεί να χρησιμοποιηθεί για την αποθήκευση κορμών; Είναι αδύνατο να μην αναφέρουμε τον Χαντούπ. Στη συνέχεια, για παράδειγμα, Rsyslog (αποθήκευση αυτών των αρχείων καταγραφής σε αρχεία). LSD. Ποιος ξέρει τι είναι το LSD; Όχι, όχι αυτό το LSD. Αποθηκεύστε αρχεία, αντίστοιχα, επίσης. Λοιπόν, το ClickHouse είναι μια περίεργη επιλογή.
Clickhouse και ανταγωνιστές: απαιτήσεις και ευκαιρίες
Τι θέλουμε? Θέλουμε να διασφαλίσουμε ότι δεν χρειάζεται να ανησυχούμε πολύ για τη λειτουργία, ώστε να λειτουργεί εκτός συσκευασίας, κατά προτίμηση με ελάχιστη διαμόρφωση. Θέλουμε να γράψουμε πολλά και να γράφουμε γρήγορα. Και θέλουμε να το κρατήσουμε για κάθε λογής μήνες, χρόνια, δηλαδή για πολύ καιρό. Ίσως θέλουμε να καταλάβουμε κάποιο πρόβλημα με το οποίο ήρθαν σε εμάς και είπαν, "Κάτι δεν λειτουργεί εδώ", και αυτό ήταν πριν από 3 μήνες) και θέλουμε να μπορούμε να δούμε τι συνέβη πριν από 3 μήνες " Η συμπίεση δεδομένων – είναι ξεκάθαρο γιατί θα ήταν πλεονέκτημα – γιατί μειώνει τον χώρο που καταλαμβάνει.
Και έχουμε μια τόσο ενδιαφέρουσα απαίτηση: μερικές φορές γράφουμε την έξοδο ορισμένων εντολών (για παράδειγμα, αρχεία καταγραφής), μπορεί να είναι περισσότερα από 4 kilobyte αρκετά εύκολα. Και αν αυτό το πράγμα λειτουργεί μέσω UDP, τότε δεν χρειάζεται να ξοδέψετε... δεν θα έχει κανένα "υπέρβαρο" για τη σύνδεση και για μεγάλο αριθμό διακομιστών αυτό θα είναι ένα πλεονέκτημα.
Ας δούμε τι μας προσφέρει ο ανοιχτός κώδικας. Πρώτον, έχουμε το Logs Engine - αυτός είναι ο κινητήρας μας. Κατ' αρχήν, μπορεί να κάνει τα πάντα, μπορεί ακόμη και να γράφει μεγάλες γραμμές. Λοιπόν, δεν συμπιέζει με διαφάνεια δεδομένα - μπορούμε να συμπιέσουμε μεγάλες στήλες μόνοι μας, αν θέλουμε... φυσικά, δεν το θέλουμε (αν είναι δυνατόν). Το μόνο πρόβλημα είναι ότι μπορεί να δώσει μόνο ό,τι ταιριάζει στη μνήμη του. Για να διαβάσετε τα υπόλοιπα, πρέπει να λάβετε το binlog αυτού του κινητήρα και, κατά συνέπεια, χρειάζεται πολύς χρόνος.
Τι άλλες επιλογές υπάρχουν; Για παράδειγμα, "Hadup". Ευκολία στη λειτουργία... Ποιος πιστεύει ότι το Hadup είναι εύκολο να στηθεί; Φυσικά, δεν υπάρχουν προβλήματα με την ηχογράφηση. Κατά την ανάγνωση, μερικές φορές προκύπτουν ερωτήσεις. Καταρχήν, θα έλεγα ότι μάλλον όχι, ειδικά για κορμούς. Μακροχρόνια αποθήκευση - φυσικά, ναι, συμπίεση δεδομένων - ναι, μεγάλες συμβολοσειρές - είναι σαφές ότι μπορείτε να κάνετε εγγραφή. Αλλά ηχογράφηση από μεγάλο αριθμό διακομιστών... Κάτι πρέπει να κάνετε μόνοι σας!
Rsyslog. Στην πραγματικότητα, το χρησιμοποιήσαμε ως εφεδρική επιλογή, ώστε να μπορούμε να το διαβάσουμε χωρίς να ρίξουμε το binlog, αλλά δεν μπορεί να γράψει μεγάλες γραμμές· κατ 'αρχήν, δεν μπορεί να γράψει περισσότερα από 4 kilobyte. Πρέπει να κάνετε συμπίεση δεδομένων με τον ίδιο τρόπο μόνοι σας. Η ανάγνωση θα προέρχεται από αρχεία.
Στη συνέχεια, υπάρχει η «badushka» ανάπτυξη του LSD. Ουσιαστικά το ίδιο με το "Rsyslog": υποστηρίζει μεγάλες συμβολοσειρές, αλλά δεν μπορεί να λειτουργήσει μέσω UDP και, στην πραγματικότητα, εξαιτίας αυτού, δυστυχώς, πολλά πράγματα πρέπει να ξαναγραφτούν εκεί. Το LSD πρέπει να επανασχεδιαστεί για να μπορεί να καταγράφει από δεκάδες χιλιάδες διακομιστές.
Και εδώ! Μια αστεία επιλογή είναι το ElasticSearch. Πώς να το πω? Με το διάβασμα τα πάει καλά, δηλαδή διαβάζει γρήγορα, αλλά όχι πολύ καλά με το γράψιμο. Πρώτον, εάν συμπιέζει δεδομένα, είναι πολύ αδύναμο. Πιθανότατα, μια πλήρης αναζήτηση απαιτεί μεγαλύτερες δομές δεδομένων από τον αρχικό τόμο. Είναι δύσκολο να λειτουργήσει και συχνά προκύπτουν προβλήματα με αυτό. Και, πάλι, ηχογράφηση σε Elastic - πρέπει να κάνουμε τα πάντα μόνοι μας.
Εδώ το ClickHouse είναι μια ιδανική επιλογή, φυσικά. Το μόνο πράγμα είναι ότι η εγγραφή από δεκάδες χιλιάδες διακομιστές είναι ένα πρόβλημα. Αλλά τουλάχιστον υπάρχει ένα πρόβλημα, μπορούμε να προσπαθήσουμε να το λύσουμε με κάποιο τρόπο. Και η υπόλοιπη έκθεση αφορά αυτό το πρόβλημα. Τι είδους απόδοση μπορείτε να περιμένετε από το ClickHouse;
Πώς θα το εισάγουμε; MergeTree
Ποιος από εσάς δεν έχει ακούσει ή ξέρει για το "ClickHouse"; Πρέπει να σου πω, έτσι δεν είναι; Πολύ γρήγορα. Η εισαγωγή εκεί - 1-2 gigabit ανά δευτερόλεπτο, εκρήξεις έως και 10 gigabit ανά δευτερόλεπτο μπορεί πραγματικά να αντέξει αυτήν τη διαμόρφωση - υπάρχουν δύο Xeon 6 πυρήνων (δηλαδή, ούτε το πιο ισχυρό), 256 gigabyte μνήμης RAM, 20 terabyte στο RAID (κανείς δεν έχει ρυθμιστεί, προεπιλεγμένες ρυθμίσεις). Ο Alexey Milovidov, προγραμματιστής του ClickHouse, πιθανότατα κάθεται εκεί και κλαίει επειδή δεν ρυθμίσαμε τίποτα (όλα λειτουργούσαν έτσι για εμάς). Αντίστοιχα, μπορεί να επιτευχθεί ταχύτητα σάρωσης, ας πούμε, περίπου 6 δισεκατομμυρίων γραμμών ανά δευτερόλεπτο εάν τα δεδομένα είναι καλά συμπιεσμένα. Αν σας αρέσει το % σε μια συμβολοσειρά κειμένου - 100 εκατομμύρια γραμμές ανά δευτερόλεπτο, δηλαδή, φαίνεται αρκετά γρήγορο.
Πώς θα το εισάγουμε; Λοιπόν, ξέρετε ότι η VK χρησιμοποιεί PHP. Θα εισάγουμε από κάθε εργαζόμενο PHP μέσω HTTP στο "ClickHouse", στον πίνακα MergeTree για κάθε εγγραφή. Ποιος βλέπει πρόβλημα με αυτό το σχήμα; Για κάποιο λόγο, δεν σήκωσαν όλοι τα χέρια ψηλά. Επιτρέψτε μου να σας πω.
Πρώτον, υπάρχουν πολλοί διακομιστές - κατά συνέπεια, θα υπάρχουν πολλές συνδέσεις (κακές). Τότε είναι καλύτερο να εισάγετε δεδομένα στο MergeTree όχι συχνότερα από μία φορά ανά δευτερόλεπτο. Και ποιος ξέρει γιατί; Εντάξει εντάξει. Θα σας πω λίγα περισσότερα για αυτό. Μια άλλη ενδιαφέρουσα ερώτηση είναι ότι δεν κάνουμε αναλύσεις, δεν χρειάζεται να εμπλουτίσουμε τα δεδομένα, δεν χρειαζόμαστε ενδιάμεσους διακομιστές, θέλουμε να εισάγουμε απευθείας στο "ClickHouse" (κατά προτίμηση - όσο πιο άμεσα, τόσο το καλύτερο).
Αντίστοιχα, πώς γίνεται η εισαγωγή στο MergeTree; Γιατί είναι καλύτερο να το εισάγετε όχι συχνότερα από μία φορά το δευτερόλεπτο ή λιγότερο συχνά; Το γεγονός είναι ότι το "ClickHouse" είναι μια βάση δεδομένων στηλών και ταξινομεί τα δεδομένα σε αύξουσα σειρά του πρωτεύοντος κλειδιού και όταν κάνετε μια εισαγωγή, δημιουργείται ένας αριθμός αρχείων τουλάχιστον ίσος με τον αριθμό των στηλών στις οποίες ταξινομούνται τα δεδομένα με αύξουσα σειρά του πρωτεύοντος κλειδιού (δημιουργείται ένας ξεχωριστός κατάλογος, ένα σύνολο αρχείων στο δίσκο για κάθε ένθετο). Έπειτα έρχεται η επόμενη εισαγωγή, και στο βάθος συνδυάζονται σε μεγαλύτερα «χωρίσματα». Εφόσον τα δεδομένα είναι ταξινομημένα, είναι δυνατή η «συγχώνευση» δύο ταξινομημένων αρχείων χωρίς να καταναλώνεται μεγάλη μνήμη.
Αλλά, όπως μπορείτε να μαντέψετε, εάν γράψετε 10 αρχεία για κάθε ένθετο, τότε το ClickHouse (ή ο διακομιστής σας) θα τελειώσει γρήγορα, επομένως συνιστάται η εισαγωγή σε μεγάλες παρτίδες. Ως εκ τούτου, δεν ξεκινήσαμε ποτέ το πρώτο σχέδιο στην παραγωγή. Λανσάραμε αμέσως ένα, το οποίο εδώ το Νο 2 έχει:
Εδώ φανταστείτε ότι υπάρχουν περίπου χίλιοι διακομιστές στους οποίους έχουμε ξεκινήσει, υπάρχει μόνο PHP. Και σε κάθε διακομιστή υπάρχει ο τοπικός μας πράκτορας, τον οποίο ονομάσαμε "Kittenhouse", ο οποίος διατηρεί μία σύνδεση με το "ClickHouse" και εισάγει δεδομένα κάθε λίγα δευτερόλεπτα. Εισάγει δεδομένα όχι στο MergeTree, αλλά σε έναν πίνακα buffer, ο οποίος χρησιμεύει ακριβώς για να αποφευχθεί η άμεση εισαγωγή απευθείας στο MergeTree.
Εργασία με πίνακες προσωρινής αποθήκευσης
Τι είναι? Οι πίνακες προσωρινής μνήμης είναι ένα κομμάτι μνήμης που μοιράζεται (δηλαδή, μπορεί να εισαχθεί συχνά σε αυτό). Αποτελούνται από πολλά κομμάτια και κάθε ένα από τα κομμάτια λειτουργεί ως ανεξάρτητο buffer και ξεπλένονται ανεξάρτητα (αν έχετε πολλά κομμάτια στο buffer, τότε θα υπάρχουν πολλά ένθετα ανά δευτερόλεπτο). Είναι δυνατή η ανάγνωση από αυτούς τους πίνακες - τότε διαβάζετε την ένωση των περιεχομένων του buffer και του γονικού πίνακα, αλλά αυτή τη στιγμή η εγγραφή είναι μπλοκαρισμένη, επομένως είναι καλύτερα να μην διαβάζετε από εκεί. Και οι πίνακες buffer δείχνουν πολύ καλό QPS, δηλαδή μέχρι 3 χιλιάδες QPS δεν θα έχετε κανένα απολύτως πρόβλημα κατά την εισαγωγή. Είναι σαφές ότι εάν ο διακομιστής χάσει την ισχύ, τότε τα δεδομένα μπορούν να χαθούν, επειδή αποθηκεύτηκαν μόνο στη μνήμη.
Ταυτόχρονα, το σχήμα με buffer περιπλέκει το ALTER, γιατί πρέπει πρώτα να απορρίψετε τον παλιό πίνακα buffer με το παλιό σχήμα (τα δεδομένα δεν θα εξαφανιστούν πουθενά, γιατί θα ξεπλυθούν πριν διαγραφεί ο πίνακας). Στη συνέχεια, «αλλάζετε» τον πίνακα που χρειάζεστε και δημιουργείτε ξανά τον πίνακα buffer. Αντίστοιχα, ενώ δεν υπάρχει πίνακας buffer, τα δεδομένα σας δεν θα ρέουν πουθενά, αλλά μπορείτε να τα έχετε στο δίσκο τουλάχιστον τοπικά.
Τι είναι το Kittenhouse και πώς λειτουργεί;
Τι είναι το KittenHouse; Αυτός είναι ένας πληρεξούσιος. Μαντέψτε ποια γλώσσα; Συγκέντρωσα τα περισσότερα θέματα διαφημιστικής εκστρατείας στην αναφορά μου - "Clickhouse", Go, ίσως θυμηθώ κάτι άλλο. Ναι, αυτό είναι γραμμένο στο Go, γιατί δεν ξέρω πραγματικά πώς να γράφω σε C, δεν θέλω.
Αντίστοιχα, διατηρεί μια σύνδεση με κάθε διακομιστή και μπορεί να γράψει στη μνήμη. Για παράδειγμα, αν γράψουμε αρχεία καταγραφής σφαλμάτων στο Clickhouse, τότε εάν το Clickhouse δεν έχει χρόνο να εισαγάγει δεδομένα (εξάλλου, αν γράφονται πάρα πολλά), τότε δεν διογκώνουμε τη μνήμη - απλώς πετάμε τα υπόλοιπα. Γιατί αν γράψουμε πολλά gigabits ανά δευτερόλεπτο σφαλμάτων, τότε πιθανότατα μπορούμε να πετάξουμε μερικά. Το Kittenhouse μπορεί να το κάνει αυτό. Επιπλέον, μπορεί να εκτελέσει αξιόπιστη παράδοση, δηλαδή εγγραφή στο δίσκο στο τοπικό μηχάνημα και μία φορά κάθε φορά (εκεί, μία φορά κάθε δύο δευτερόλεπτα) προσπαθεί να παραδώσει δεδομένα από αυτό το αρχείο. Και στην αρχή χρησιμοποιήσαμε την κανονική μορφή Values - όχι κάποια δυαδική μορφή, μια μορφή κειμένου (όπως στην κανονική SQL).
Αλλά μετά συνέβη αυτό. Χρησιμοποιήσαμε αξιόπιστη παράδοση, γράψαμε αρχεία καταγραφής και μετά αποφασίσαμε (ήταν ένα σύμπλεγμα δοκιμών υπό όρους)... Τέθηκε για αρκετές ώρες και επανήλθε, και ξεκίνησε μια εισαγωγή από χίλιους διακομιστές - αποδείχθηκε ότι το Clickhouse είχε ακόμα "Νήμα στη σύνδεση" - κατά συνέπεια, σε χίλιες συνδέσεις, μια ενεργή εισαγωγή οδηγεί σε μέσο φόρτο στον διακομιστή περίπου μιάμιση χιλιάδα. Παραδόξως, ο διακομιστής δεχόταν αιτήματα, αλλά τα δεδομένα εισήχθησαν ακόμα μετά από κάποιο χρονικό διάστημα. αλλά ήταν πολύ δύσκολο για τον διακομιστή να το εξυπηρετήσει...
Προσθέστε nginx
Μια τέτοια λύση για το μοντέλο Thread ανά σύνδεση είναι το nginx. Εγκαταστήσαμε το nginx μπροστά από το Clickhouse, ρυθμίσαμε ταυτόχρονα την εξισορρόπηση για δύο αντίγραφα (η ταχύτητα εισαγωγής μας αυξήθηκε κατά 2 φορές, αν και δεν είναι γεγονός ότι αυτό θα έπρεπε να ισχύει) και περιορίσαμε τον αριθμό των συνδέσεων στο Clickhouse, στο upstream και, κατά συνέπεια, περισσότερες από 50 συνδέσεις, φαίνεται ότι δεν έχει νόημα η εισαγωγή.
Στη συνέχεια συνειδητοποιήσαμε ότι αυτό το σχήμα έχει γενικά μειονεκτήματα, επειδή έχουμε μόνο ένα nginx εδώ. Αντίστοιχα, εάν αυτό το nginx καταρρεύσει, παρά την παρουσία αντιγράφων, χάνουμε δεδομένα ή, τουλάχιστον, δεν γράφουμε πουθενά. Γι' αυτό φτιάξαμε το δικό μας load balancing. Συνειδητοποιήσαμε επίσης ότι το "Clickhouse" εξακολουθεί να είναι κατάλληλο για κούτσουρα και ο "δαίμονας" άρχισε επίσης να γράφει τα κούτσουρα του στο "Clickhouse" - πολύ βολικό, για να είμαι ειλικρινής. Εξακολουθούμε να το χρησιμοποιούμε για άλλους «δαίμονες».
Στη συνέχεια ανακαλύψαμε αυτό το ενδιαφέρον πρόβλημα: εάν χρησιμοποιείτε μια μη τυπική μέθοδο εισαγωγής σε λειτουργία SQL, αναγκάζει έναν πλήρη αναλυτή SQL που βασίζεται σε AST, ο οποίος είναι αρκετά αργός. Αντίστοιχα, προσθέσαμε ρυθμίσεις για να διασφαλίσουμε ότι αυτό δεν θα συμβεί ποτέ. Κάναμε load balancing, υγειονομικούς ελέγχους, ώστε αν πεθάνει κάποιος, να αφήνουμε ακόμα τα δεδομένα. Τώρα έχουμε πολλούς πίνακες που χρειαζόμαστε για να έχουμε διαφορετικά συμπλέγματα Clickhouse. Και αρχίσαμε επίσης να σκεφτόμαστε άλλες χρήσεις - για παράδειγμα, θέλαμε να γράψουμε αρχεία καταγραφής από μονάδες nginx, αλλά δεν ξέρουν πώς να επικοινωνούν χρησιμοποιώντας το RPC μας. Λοιπόν, θα ήθελα να τους μάθω πώς να στέλνουν τουλάχιστον με κάποιο τρόπο - για παράδειγμα, να λαμβάνουν συμβάντα στο localhost μέσω UDP και στη συνέχεια να τα προωθούν στο Clickhouse.
Ένα βήμα μακριά από τη λύση
Το τελικό σχήμα άρχισε να μοιάζει με αυτό (η τέταρτη έκδοση αυτού του σχήματος): σε κάθε διακομιστή μπροστά από το Clickhouse υπάρχει nginx (στον ίδιο διακομιστή) και απλώς εκτελεί αιτήματα μεσολάβησης στον localhost με όριο στον αριθμό των συνδέσεων 50 κομμάτια. Και αυτό το σχέδιο λειτουργούσε ήδη αρκετά, όλα ήταν πολύ καλά με αυτό.
Ζήσαμε έτσι περίπου ένα μήνα. Όλοι ήταν ευχαριστημένοι, πρόσθεσαν πίνακες, πρόσθεσαν, πρόσθεσαν... Γενικά, αποδείχθηκε ότι ο τρόπος που προσθέσαμε πίνακες buffer δεν ήταν πολύ βέλτιστος (ας το πούμε έτσι). Κάναμε 16 κομμάτια σε κάθε τραπέζι και ένα διάστημα φλας μερικών δευτερολέπτων. είχαμε 20 πίνακες και κάθε τραπέζι λάμβανε 8 ένθετα ανά δευτερόλεπτο - και σε αυτό το σημείο ξεκίνησε το “Clickhouse”... οι εγγραφές άρχισαν να επιβραδύνονται. Δεν πέρασαν καν... Το Nginx από προεπιλογή είχε ένα τόσο ενδιαφέρον πράγμα που αν οι συνδέσεις τελείωναν στο upstream, τότε απλώς επέστρεφε το "502" σε όλα τα νέα αιτήματα.
Και εδώ έχουμε (μόλις κοίταξα τα αρχεία καταγραφής στο ίδιο το Clickhouse) περίπου το μισό τοις εκατό των αιτημάτων απέτυχαν. Κατά συνέπεια, η χρήση του δίσκου ήταν υψηλή, υπήρξαν πολλές συγχωνεύσεις. Λοιπόν, τι έκανα; Φυσικά, δεν μπήκα στον κόπο να καταλάβω γιατί τελείωσε ακριβώς η σύνδεση και η ανοδική ροή.
Αντικατάσταση του nginx με έναν αντίστροφο διακομιστή μεσολάβησης
Αποφάσισα ότι πρέπει να το διαχειριστούμε μόνοι μας, δεν χρειάζεται να το αφήσουμε στο nginx - η nginx δεν γνωρίζει τι πίνακες υπάρχουν στο Clickhouse και αντικατέστησα το nginx με έναν αντίστροφο διακομιστή μεσολάβησης, τον οποίο έγραψα και ο ίδιος.
Τι κάνει? Λειτουργεί με βάση τη βιβλιοθήκη fasthttp «goshnoy», δηλαδή γρήγορα, σχεδόν τόσο γρήγορα όσο το nginx. Συγγνώμη, Igor, αν είσαι παρών εδώ (σημείωση: Ο Igor Sysoev είναι Ρώσος προγραμματιστής που δημιούργησε τον διακομιστή ιστού nginx). Μπορεί να καταλάβει τι είδους ερωτήματα είναι αυτά – INSERT ή SELECT – κατά συνέπεια, διατηρεί διαφορετικές ομάδες σύνδεσης για διαφορετικούς τύπους ερωτημάτων.
Αντίστοιχα, ακόμα κι αν δεν έχουμε χρόνο να ολοκληρώσουμε τα αιτήματα εισαγωγής, θα περάσουν οι «επιλογές» και το αντίστροφο. Και ομαδοποιεί τα δεδομένα σε πίνακες buffer - με ένα μικρό buffer: εάν υπήρχαν σφάλματα, λάθη σύνταξης κ.λπ. - έτσι ώστε να μην επηρεάζουν σε μεγάλο βαθμό τα υπόλοιπα δεδομένα, επειδή όταν απλώς εισάγαμε σε πίνακες buffer, είχε μικρό "bachi", και όλα τα συντακτικά λάθη επηρέασαν μόνο αυτό το μικρό κομμάτι. και εδώ θα επηρεάσουν ήδη ένα μεγάλο buffer. Το μικρό είναι 1 megabyte, δηλαδή όχι τόσο μικρό.
Η εισαγωγή ενός συγχρονισμού και ουσιαστικά η αντικατάσταση του nginx, κάνει ουσιαστικά το ίδιο πράγμα που έκανε το nginx πριν - δεν χρειάζεται να αλλάξετε το τοπικό "Kittenhouse" για αυτό. Και επειδή χρησιμοποιεί fasthttp, είναι πολύ γρήγορο - μπορείτε να κάνετε περισσότερα από 100 χιλιάδες αιτήματα ανά δευτερόλεπτο για μεμονωμένα ένθετα μέσω ενός αντίστροφου διακομιστή μεσολάβησης. Θεωρητικά, μπορείτε να εισάγετε μία γραμμή τη φορά στον αντίστροφο διακομιστή μεσολάβησης του kittenhouse, αλλά φυσικά δεν το κάνουμε αυτό.
Το σχήμα άρχισε να μοιάζει με αυτό: "Kittenhouse", ο αντίστροφος διακομιστής μεσολάβησης ομαδοποιεί πολλά αιτήματα σε πίνακες και, με τη σειρά τους, οι πίνακες buffer τα εισάγουν στους κύριους.
Το Killer είναι μια προσωρινή λύση, το Kitten είναι μόνιμη
Αυτό είναι ένα ενδιαφέρον πρόβλημα... Έχει κάποιος από εσάς χρησιμοποιήσει το fasthttp; Ποιος χρησιμοποίησε το fasthttp με αιτήματα POST; Πιθανώς, αυτό πραγματικά δεν θα έπρεπε να είχε γίνει, επειδή αποθηκεύει το σώμα του αιτήματος από προεπιλογή και το μέγεθος του buffer μας ορίστηκε στα 16 megabyte. Η εισαγωγή σταμάτησε να συνεχίζεται κάποια στιγμή και κομμάτια των 16 megabyte άρχισαν να φτάνουν από όλους τους δεκάδες χιλιάδες διακομιστές, και όλα αποθηκεύτηκαν στην προσωρινή μνήμη πριν σταλούν στο Clickhouse. Κατά συνέπεια, η μνήμη εξαντλήθηκε, ο Out-Of-Memory Killer ήρθε και σκότωσε τον αντίστροφο διακομιστή μεσολάβησης (ή το "Clickhouse", το οποίο θεωρητικά θα μπορούσε να "φάει" περισσότερο από το αντίστροφο διακομιστή μεσολάβησης). Ο κύκλος επαναλήφθηκε. Δεν είναι ένα πολύ ευχάριστο πρόβλημα. Αν και πέσαμε σε αυτό μόνο μετά από αρκετούς μήνες λειτουργίας.
Τι έκανα? Και πάλι, δεν μου αρέσει να καταλαβαίνω τι ακριβώς συνέβη. Νομίζω ότι είναι αρκετά προφανές ότι δεν πρέπει να αποθηκεύετε προσωρινά τη μνήμη. Δεν μπόρεσα να κάνω patch το fasthttp, αν και προσπάθησα. Βρήκα όμως έναν τρόπο να το κάνω έτσι ώστε να μην χρειάζεται να μπαλώσω τίποτα και βρήκα τη δική μου μέθοδο στο HTTP - την ονόμασα ΓΑΤΑΚΙ. Λοιπόν, είναι λογικό - "VK", "Kitten" ... Τι άλλο; ..
Εάν ένα αίτημα έρθει στον διακομιστή με τη μέθοδο Kitten, τότε ο διακομιστής θα πρέπει να απαντήσει "νιαούρισμα" - λογικά. Εάν ανταποκριθεί σε αυτό, τότε θεωρείται ότι καταλαβαίνει αυτό το πρωτόκολλο, και στη συνέχεια παρεμποδίζω τη σύνδεση (το fasthttp έχει τέτοια μέθοδο) και η σύνδεση μπαίνει σε λειτουργία "raw". Γιατί το χρειάζομαι; Θέλω να ελέγξω πώς γίνεται η ανάγνωση από συνδέσεις TCP. Το TCP έχει μια υπέροχη ιδιότητα: εάν κανείς δεν διαβάζει από την άλλη πλευρά, τότε η εγγραφή αρχίζει να περιμένει και η μνήμη δεν δαπανάται ιδιαίτερα σε αυτό.
Και έτσι διάβασα από περίπου 50 πελάτες τη φορά (από πενήντα γιατί πενήντα θα πρέπει σίγουρα να είναι αρκετά, ακόμα κι αν το ποσοστό προέρχεται από άλλο DC)... Η κατανάλωση έχει μειωθεί με αυτήν την προσέγγιση τουλάχιστον 20 φορές, αλλά εγώ, για να είμαι ειλικρινής , δεν μπόρεσα να μετρήσω ακριβώς την ώρα, γιατί είναι ήδη άσκοπη (έχει φτάσει ήδη στο επίπεδο του λάθους). Το πρωτόκολλο είναι δυαδικό, δηλαδή περιέχει το όνομα του πίνακα και τα δεδομένα. δεν υπάρχουν κεφαλίδες http, επομένως δεν χρησιμοποίησα υποδοχή ιστού (δεν χρειάζεται να επικοινωνώ με προγράμματα περιήγησης - έφτιαξα ένα πρωτόκολλο που ταιριάζει στις ανάγκες μας). Και όλα έγιναν καλά μαζί του.
Το buffer table είναι λυπηρό
Πρόσφατα συναντήσαμε ένα άλλο ενδιαφέρον χαρακτηριστικό των buffer tables. Και αυτό το πρόβλημα είναι ήδη πολύ πιο οδυνηρό από τα άλλα. Ας φανταστούμε αυτήν την κατάσταση: χρησιμοποιείτε ήδη ενεργά το Clickhouse, έχετε δεκάδες διακομιστές Clickhouse και έχετε ορισμένα αιτήματα που χρειάζονται πολύ χρόνο για να διαβάσετε (ας πούμε, περισσότερο από 60 δευτερόλεπτα). και έρχεσαι και κάνεις το Alter αυτή τη στιγμή... Στο μεταξύ, οι "επιλογές" που ξεκίνησαν πριν από το "Alter" δεν θα συμπεριληφθούν σε αυτόν τον πίνακα, το "Alter" δεν θα ξεκινήσει - πιθανώς ορισμένες λειτουργίες του τρόπου λειτουργίας του "Clickhouse" στο αυτό το μέρος. Ίσως αυτό μπορεί να διορθωθεί; Ή είναι αδύνατο;
Σε γενικές γραμμές, είναι σαφές ότι στην πραγματικότητα αυτό δεν είναι τόσο μεγάλο πρόβλημα, αλλά με τους πίνακες buffer γίνεται πιο οδυνηρό. Επειδή, ας πούμε, το χρονικό όριο του "Alter" σας (και μπορεί να λήξει σε άλλο κεντρικό υπολογιστή - όχι στον δικό σας, αλλά σε ένα αντίγραφο, για παράδειγμα), τότε... Διαγράψατε τον πίνακα buffer, το "Alter" σας ( ή κάποιο άλλο κεντρικό υπολογιστή) έληξε. τότε παρουσιάστηκε σφάλμα "Alter") - πρέπει ακόμα να βεβαιωθείτε ότι τα δεδομένα συνεχίζουν να γράφονται: δημιουργείτε τους πίνακες buffer πίσω (σύμφωνα με το ίδιο σχήμα με τον γονικό πίνακα), στη συνέχεια Το "Alter" περνάει, τελειώνει τελικά και το buffer του πίνακα αρχίζει να διαφέρει σε σχήμα από το γονικό. Ανάλογα με το τι ήταν το "Alter", το ένθετο μπορεί να μην πηγαίνει πλέον σε αυτόν τον πίνακα προσωρινής αποθήκευσης - αυτό είναι πολύ λυπηρό.
Υπάρχει επίσης ένα τέτοιο σημάδι (ίσως το παρατήρησε κάποιος) - ονομάζεται query_thread_log στις νέες εκδόσεις του Clickhouse. Από προεπιλογή, σε κάποια έκδοση υπήρχε ένα. Εδώ έχουμε συγκεντρώσει 840 εκατομμύρια εγγραφές σε μερικούς μήνες (100 gigabyte). Αυτό οφείλεται στο γεγονός ότι γράφτηκαν "ένθετα" εκεί (ίσως τώρα, παρεμπιπτόντως, να μην γράφονται). Όπως σας είπα, τα "ένθετα" μας είναι μικρά - είχαμε πολλά "ένθετα" στους πίνακες buffer. Είναι σαφές ότι αυτό είναι απενεργοποιημένο - απλώς σας λέω αυτό που είδα στον διακομιστή μας. Γιατί; Αυτό είναι ένα άλλο επιχείρημα κατά της χρήσης πινάκων buffer! Ο Spotty είναι πολύ λυπημένος.
Ποιος ήξερε ότι το όνομα αυτού του τύπου ήταν Spotty; Οι υπάλληλοι της VK σήκωσαν τα χέρια ψηλά. ΕΝΤΑΞΕΙ.
Σχετικά με τα σχέδια για το "KitttenHouse"
Τα σχέδια συνήθως δεν μοιράζονται, σωστά; Ξαφνικά δεν θα τα εκπληρώσετε και δεν θα φαίνεστε πολύ καλά στα μάτια των άλλων. Αλλά θα πάρω το ρίσκο! Θέλουμε να κάνουμε το εξής: οι πίνακες buffer, μου φαίνεται, εξακολουθούν να είναι ένα δεκανίκι και πρέπει να αποθηκεύσουμε την εισαγωγή μόνοι μας. Αλλά εξακολουθούμε να μην θέλουμε να το αποθηκεύσουμε στο δίσκο, επομένως θα αποθηκεύσουμε την εισαγωγή στη μνήμη.
Αντίστοιχα, όταν γίνει μια "εισαγωγή", δεν θα είναι πλέον σύγχρονη - θα λειτουργεί ήδη ως πίνακας προσωρινής αποθήκευσης, θα εισάγεται στον γονικό πίνακα (καλά, κάποια μέρα αργότερα) και θα αναφέρει μέσω ενός ξεχωριστού καναλιού ποια ένθετα έχουν περάσει και ποια Δεν έχετε.
Γιατί δεν μπορώ να φύγω από το σύγχρονο ένθετο; Είναι πολύ πιο βολικό. Το γεγονός είναι ότι αν εισαγάγετε από 10 χιλιάδες κεντρικούς υπολογιστές, τότε όλα είναι καλά - θα πάρετε λίγο από κάθε κεντρικό υπολογιστή, εισάγετε εκεί μία φορά το δευτερόλεπτο, όλα είναι καλά. Αλλά θα ήθελα αυτό το σχήμα να λειτουργεί, για παράδειγμα, από δύο μηχανήματα, ώστε να μπορείτε να κάνετε λήψη με υψηλή ταχύτητα - ίσως να μην έχετε το μέγιστο από το Clickhouse, αλλά να γράψετε τουλάχιστον 100 megabyte ανά δευτερόλεπτο από ένα μηχάνημα μέσω ενός αντίστροφου διακομιστή μεσολάβησης - Αυτό το σχήμα πρέπει να κλιμακωθεί σε μεγάλες και μικρές ποσότητες, επομένως δεν μπορούμε να περιμένουμε ένα δευτερόλεπτο για κάθε εισαγωγή, επομένως πρέπει να είναι ασύγχρονη. Και με τον ίδιο τρόπο, οι ασύγχρονες επιβεβαιώσεις θα πρέπει να έρχονται μετά την ολοκλήρωση της εισαγωγής. Θα ξέρουμε αν πέρασε ή όχι.
Το πιο σημαντικό είναι ότι σε αυτό το σχήμα γνωρίζουμε με βεβαιότητα αν η εισαγωγή έγινε ή όχι. Φανταστείτε αυτήν την κατάσταση: έχετε έναν πίνακα buffer, γράψατε κάτι σε αυτόν και, ας πούμε, ο πίνακας μπήκε σε λειτουργία μόνο για ανάγνωση και προσπάθησε να ξεπλύνετε το buffer. Πού θα πάνε τα δεδομένα; Θα παραμείνουν στο buffer. Αλλά δεν μπορούμε να είμαστε σίγουροι για αυτό - τι γίνεται αν υπάρχει κάποιο άλλο σφάλμα, λόγω του οποίου τα δεδομένα δεν θα παραμείνουν στο buffer... (Απευθύνεται στον Alexey Milovidov, Yandex, προγραμματιστής ClickHouse) Ή θα παραμείνει; Πάντα? Ο Alexey μας πείθει ότι όλα θα πάνε καλά. Δεν έχουμε λόγο να μην τον πιστέψουμε. Αλλά το ίδιο: αν δεν χρησιμοποιήσουμε πίνακες buffer, τότε δεν θα υπάρχουν προβλήματα με αυτούς. Η δημιουργία διπλάσιων πινάκων είναι επίσης άβολη, αν και καταρχήν δεν υπάρχουν μεγάλα προβλήματα. Αυτό είναι το σχέδιο.
Ας μιλήσουμε για το διάβασμα
Τώρα ας μιλήσουμε για το διάβασμα. Εδώ γράψαμε και το δικό μας εργαλείο. Φαίνεται, λοιπόν, γιατί να γράψετε το δικό σας όργανο εδώ;... Και ποιος χρησιμοποίησε το Tabix; Κάπως λίγοι σήκωσαν τα χέρια ψηλά... Και ποιος είναι ικανοποιημένος με την απόδοση του Tabix; Λοιπόν, δεν είμαστε ευχαριστημένοι με αυτό και δεν είναι πολύ βολικό για την προβολή δεδομένων. Είναι καλό για αναλυτικά στοιχεία, αλλά μόνο για προβολή δεν είναι σαφώς βελτιστοποιημένο. Έγραψα λοιπόν τη δική μου, τη δική μου διεπαφή.
Είναι πολύ απλό - μπορεί να διαβάσει μόνο δεδομένα. Δεν ξέρει να δείχνει γραφικά, δεν ξέρει να κάνει τίποτα. Μπορεί όμως να δείξει τι χρειαζόμαστε: για παράδειγμα, πόσες σειρές υπάρχουν στον πίνακα, πόσο χώρο καταλαμβάνει (χωρίς να τον αναλύσουμε σε στήλες), δηλαδή, μια πολύ βασική διεπαφή είναι αυτό που χρειαζόμαστε.
Και μοιάζει πολύ με το Sequel Pro, αλλά δημιουργήθηκε μόνο στο Bootstrap του Twitter και στη δεύτερη έκδοση. Ρωτάς: "Γιούρι, γιατί στη δεύτερη έκδοση;" Ποια χρονιά? 2018; Γενικά, το έκανα πριν από πολύ καιρό για το "Muscle" (MySQL) και μόλις άλλαξα μερικές γραμμές στα ερωτήματα εκεί και άρχισε να λειτουργεί για το "Clickhouse", για το οποίο ευχαριστώ ιδιαιτέρως! Επειδή ο αναλυτής είναι πολύ παρόμοιος με τον "μυϊκό" και τα ερωτήματα είναι πολύ παρόμοια - πολύ βολικά, ειδικά στην αρχή.
Λοιπόν, μπορεί να φιλτράρει πίνακες, μπορεί να δείξει τη δομή και τα περιεχόμενα του πίνακα, σας επιτρέπει να ταξινομήσετε, να φιλτράρετε κατά στήλες, να εμφανίζει το ερώτημα που οδήγησε στο αποτέλεσμα, τις επηρεαζόμενες σειρές (πόσες ως αποτέλεσμα), δηλαδή βασικά πράγματα για την προβολή δεδομένων. Αρκετά γρήγορα.
Υπάρχει και συντάκτης. Ειλικρινά προσπάθησα να κλέψω ολόκληρο τον συντάκτη από το Tabix, αλλά δεν τα κατάφερα. Αλλά κατά κάποιο τρόπο λειτουργεί. Καταρχήν, αυτό είναι όλο.
Το "Clickhouse" είναι κατάλληλο για κρησφύγετα
Θέλω να σας πω ότι το Clickhouse, παρά όλα τα προβλήματα που περιγράφονται, είναι πολύ κατάλληλο για κούτσουρα. Το πιο σημαντικό, λύνει το πρόβλημά μας - είναι πολύ γρήγορο και σας επιτρέπει να φιλτράρετε αρχεία καταγραφής κατά στήλες. Καταρχήν, οι πίνακες buffer δεν έχουν καλή απόδοση, αλλά συνήθως κανείς δεν ξέρει γιατί... Ίσως τώρα γνωρίζετε καλύτερα πού θα έχετε προβλήματα.
TCP; Γενικά, στο VK είναι συνηθισμένο να χρησιμοποιείται UDP. Και όταν χρησιμοποίησα το TCP... Φυσικά, κανείς δεν μου είπε: «Γιούρι, τι λες! Δεν μπορείτε, χρειάζεστε UDP." Αποδείχθηκε ότι το TCP δεν είναι τόσο τρομακτικό. Το μόνο πράγμα είναι, αν έχετε δεκάδες χιλιάδες δραστικές ενώσεις που γράφετε, πρέπει να το προετοιμάσετε λίγο πιο προσεκτικά. αλλά είναι δυνατό και αρκετά εύκολο.
Υποσχέθηκα να δημοσιεύσω το "Kittenhouse" και το "Lighthouse" στο HighLoad Siberia εάν όλοι εγγραφούν στο δημόσιο "VK backend" μας... Και ξέρετε, δεν έγιναν όλοι συνδρομητές... Φυσικά, δεν θα απαιτήσω να εγγραφείτε στο δικό μας δημόσιο. Εξακολουθείτε να είστε πάρα πολλοί, κάποιος μπορεί ακόμη και να προσβληθεί, αλλά παρόλα αυτά, παρακαλώ εγγραφείτε (και εδώ πρέπει να κάνω μάτια σαν αυτά της γάτας). Αυτό είναι . Ευχαριστώ πολύ! Το Github είναι δικό μας . Με το Clickhouse τα μαλλιά σας θα είναι απαλά και μεταξένια.
Μόλυβδος: - Φίλοι, τώρα για ερωτήσεις. Αμέσως μετά παρουσιάζουμε το πιστοποιητικό εκτίμησης και την έκθεσή σας για το VHS.
Yuri Nasretdinov (εφεξής καλούμενος YN): – Πώς καταφέρατε να καταγράψετε την αναφορά μου για το VHS αν μόλις τελείωσε;
Μόλυβδος: – Επίσης, δεν μπορείτε να προσδιορίσετε πλήρως πώς θα λειτουργήσει ή όχι το «Clickhouse»! Φίλοι, 5 λεπτά για ερωτήσεις!
ερωτήσεις
Ερώτηση του κοινού (εφεξής «Q»): - Καλό απόγευμα. Ευχαριστώ πολύ για την αναφορά. Έχω δύο ερωτήσεις. Θα ξεκινήσω με κάτι επιπόλαιο: επηρεάζει ο αριθμός των γραμμάτων t στο όνομα «Kittenhouse» στα διαγράμματα (3, 4, 7...) την ικανοποίηση των γατών;
YN: - Ποσότητα τι;
З: – Γράμμα τ. Υπάρχουν τρία t, κάπου γύρω στα τρία t.
YN: - Δεν το διόρθωσα; Λοιπόν, φυσικά και ναι! Αυτά είναι διαφορετικά προϊόντα - απλά σας εξαπατούσα όλο αυτό το διάστημα. Εντάξει, αστειεύομαι - δεν πειράζει. Α, εδώ! Όχι, το ίδιο είναι, έκανα τυπογραφικό λάθος.
З: - Ευχαριστώ. Το δεύτερο ερώτημα είναι σοβαρό. Από όσο καταλαβαίνω, στο Clickhouse, οι πίνακες buffer ζουν αποκλειστικά στη μνήμη, δεν αποθηκεύονται στο δίσκο και, κατά συνέπεια, δεν είναι επίμονοι.
YN: - Ναί.
З: – Και ταυτόχρονα, ο πελάτης σας αποθηκεύει buffer στο δίσκο, κάτι που συνεπάγεται κάποια εγγύηση παράδοσης αυτών των ίδιων αρχείων καταγραφής. Αλλά αυτό δεν είναι σε καμία περίπτωση εγγυημένο στο Clickhouse. Εξηγήστε πώς πραγματοποιείται η εγγύηση, λόγω τι;.. Εδώ είναι αυτός ο μηχανισμός πιο αναλυτικά
YN: – Ναι, θεωρητικά δεν υπάρχουν αντιφάσεις εδώ, γιατί όταν το Clickhouse πέφτει, μπορείτε πραγματικά να το εντοπίσετε με ένα εκατομμύριο διαφορετικούς τρόπους. Εάν το Clickhouse κολλήσει (αν τελειώσει λανθασμένα), μπορείτε, χοντρικά μιλώντας, να επαναφέρετε λίγο από το αρχείο καταγραφής σας που σημειώσατε και να ξεκινήσετε από τη στιγμή που όλα ήταν πολύ καλά. Ας πούμε ότι κάνεις ένα λεπτό προς τα πίσω, δηλαδή θεωρείται ότι τα έχεις ξεπλύνει όλα σε ένα λεπτό.
З: – Δηλαδή, το «Kittenhouse» κρατάει περισσότερο το παράθυρο και, σε περίπτωση πτώσης, μπορεί να το αναγνωρίσει και να το τυλίξει;
YN: – Αλλά αυτό είναι στη θεωρία. Στην πράξη, δεν το κάνουμε αυτό και η αξιόπιστη παράδοση είναι από μηδέν έως άπειρες φορές. Αλλά κατά μέσο όρο ένα. Είμαστε ικανοποιημένοι ότι εάν το Clickhouse κολλήσει για κάποιο λόγο ή οι διακομιστές «επανεκκινήσουν», τότε χάνουμε λίγο. Σε όλες τις άλλες περιπτώσεις δεν θα γίνει τίποτα.
З: - Γειά σου. Από την αρχή μου φάνηκε ότι όντως θα χρησιμοποιούσατε το UDP από την αρχή της έκθεσης. Έχεις http, όλα αυτά... Και τα περισσότερα προβλήματα που περιέγραψες, όπως καταλαβαίνω, προκλήθηκαν από τη συγκεκριμένη λύση...
YN: – Τι χρησιμοποιούμε το TCP;
З: - Ουσιαστικά ναι.
YN: - Οχι.
З: – Με το fasthttp είχατε προβλήματα, με τη σύνδεση είχατε προβλήματα. Εάν είχατε μόλις χρησιμοποιήσει το UDP, θα είχατε εξοικονομήσει λίγο χρόνο. Λοιπόν, θα υπήρχαν προβλήματα με μεγάλα μηνύματα ή κάτι άλλο...
YN: - Με τι?
З: – Με μακροσκελή μηνύματα, αφού μπορεί να μην ταιριάζει στο MTU, κάτι άλλο... Λοιπόν, μπορεί να υπάρχουν δικά τους προβλήματα. Το ερώτημα είναι: γιατί όχι UDP;
YN: – Πιστεύω ότι οι συγγραφείς που ανέπτυξαν το TCP/IP είναι πολύ πιο έξυπνοι από εμένα και ξέρουν καλύτερα από μένα πώς να σειριοποιούν τα πακέτα (έτσι ώστε να πηγαίνουν), ταυτόχρονα να προσαρμόζουν το παράθυρο αποστολής, να μην υπερφορτώνουν το δίκτυο, να δίνουν σχόλια για το τι δεν διαβάζεται, χωρίς να υπολογίζω από την άλλη πλευρά... Όλα αυτά τα προβλήματα, κατά τη γνώμη μου, θα υπήρχαν στο UDP, μόνο που θα έπρεπε να γράψω ακόμη περισσότερο κώδικα από ό,τι έγραψα ήδη για να εφαρμόσω το ίδιο πράγμα και το πιθανότερο πτωχώς. Δεν μου αρέσει καν να γράφω σε C, πόσο μάλλον εκεί…
З: - Απλά βολικό! Στάλθηκε εντάξει και μην περιμένετε τίποτα - είναι εντελώς ασύγχρονο. Επέστρεψε μια ειδοποίηση ότι όλα ήταν καλά - αυτό σημαίνει ότι έφτασε. Αν δεν έρθει, σημαίνει ότι είναι κακό.
YN: – Χρειάζομαι και τα δύο – Πρέπει να μπορώ να στείλω και τα δύο με εγγύηση παράδοσης και χωρίς εγγύηση παράδοσης. Αυτά είναι δύο διαφορετικά σενάρια. Πρέπει να μην χάσω κάποια κούτσουρα ή να μην τα χάσω εντός λογικής.
З: – Δεν θα χάσω χρόνο. Αυτό πρέπει να συζητηθεί περισσότερο. Ευχαριστώ.
Μόλυβδος: – Ποιος έχει ερωτήσεις – τα χέρια στον ουρανό!
З: - Γεια, είμαι η Σάσα. Κάπου στη μέση της αναφοράς, εμφανίστηκε μια αίσθηση ότι, εκτός από το TCP, ήταν δυνατό να χρησιμοποιηθεί μια έτοιμη λύση - κάποιο είδος Κάφκα.
YN: – Λοιπόν... Σας είπα ότι δεν θέλω να χρησιμοποιήσω ενδιάμεσους διακομιστές, γιατί... στον Κάφκα, αποδεικνύεται ότι έχουμε δέκα χιλιάδες κεντρικούς υπολογιστές. Στην πραγματικότητα, έχουμε περισσότερους - δεκάδες χιλιάδες οικοδεσπότες. Μπορεί επίσης να είναι επώδυνο να κάνεις με τον Κάφκα χωρίς πληρεξούσιους. Επιπλέον, το πιο σημαντικό, εξακολουθεί να δίνει "latency", δίνει επιπλέον κεντρικούς υπολογιστές που πρέπει να έχετε. Αλλά δεν θέλω να τα έχω - θέλω...
З: «Αλλά στο τέλος αποδείχθηκε έτσι κι αλλιώς».
YN: – Όχι, δεν υπάρχουν οικοδεσπότες! Όλα αυτά λειτουργούν σε κεντρικούς υπολογιστές Clickhouse.
З: - Λοιπόν, και το "Kittenhouse", που είναι το αντίστροφο - πού μένει;
YN: – Στον κεντρικό υπολογιστή Clickhouse, δεν γράφει τίποτα στο δίσκο.
З: - Ας υποθέσουμε.
Μόλυβδος: - Είσαι ικανοποιημένος? Μπορούμε να σας δώσουμε μισθό;
З: - Ναι μπορείς. Στην πραγματικότητα, υπάρχουν πολλά δεκανίκια για να πάρουμε το ίδιο πράγμα, και τώρα - η προηγούμενη απάντηση στο θέμα του TCP έρχεται σε αντίθεση, κατά τη γνώμη μου, με αυτήν την κατάσταση. Απλώς αισθάνομαι ότι όλα θα μπορούσαν να είχαν γίνει στα γόνατά μου σε πολύ λιγότερο χρόνο.
YN: – Και επίσης γιατί δεν ήθελα να χρησιμοποιήσω τον Κάφκα, επειδή υπήρχαν πολλά παράπονα στη συνομιλία του Clickhouse Telegram ότι, για παράδειγμα, χάθηκαν μηνύματα από τον Κάφκα. Όχι από τον ίδιο τον Κάφκα, αλλά στην ενσωμάτωση του Κάφκα και του Κλίκχαους. ή κάτι δεν συνδέθηκε εκεί. Σε γενικές γραμμές, θα ήταν απαραίτητο να γράψουμε έναν πελάτη για τον Κάφκα τότε. Δεν νομίζω ότι θα μπορούσε να υπάρξει πιο απλή ή πιο αξιόπιστη λύση.
З: – Πες μου, γιατί δεν δοκίμασες ουρές ή κάποιο κοινό λεωφορείο; Αφού λέτε ότι με τον ασύγχρονο θα μπορούσατε να στείλετε τα ίδια τα αρχεία καταγραφής μέσω της ουράς και να λάβετε την απάντηση ασύγχρονα μέσω της ουράς;
YN: – Προτείνετε ποιες ουρές θα μπορούσαν να χρησιμοποιηθούν;
З: – Οποιαδήποτε, έστω και χωρίς εγγύηση ότι είναι εντάξει. Κάποιο είδος Redis, RMQ...
YN: – Έχω την αίσθηση ότι το Redis πιθανότατα δεν θα μπορέσει να τραβήξει έναν τέτοιο όγκο εισαγωγής ακόμη και σε έναν κεντρικό υπολογιστή (με την έννοια πολλών διακομιστών) που βγάζει το Clickhouse. Δεν μπορώ να το υποστηρίξω με κανένα στοιχείο (δεν το έχω συγκριθεί), αλλά μου φαίνεται ότι το Redis δεν είναι η καλύτερη λύση εδώ. Κατ 'αρχήν, αυτό το σύστημα μπορεί να θεωρηθεί ως μια αυτοσχέδια ουρά μηνυμάτων, αλλά η οποία είναι προσαρμοσμένη μόνο για το "Clickhouse"
Μόλυβδος: – Γιούρι, σε ευχαριστώ πολύ. Προτείνω να τελειώσουμε τις ερωτήσεις και τις απαντήσεις εδώ και να πούμε σε ποιον από αυτούς που έκαναν την ερώτηση θα δώσουμε το βιβλίο.
YN: – Θα ήθελα να δώσω ένα βιβλίο στον πρώτο που έκανε μια ερώτηση.
Μόλυβδος: - Εκπληκτικός! Εξαιρετική! Υπέροχο! Ευχαριστώ πολύ!
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com