Τον Απρίλιο, οι μηχανικοί της Avito συγκεντρώθηκαν για διαδικτυακές συγκεντρώσεις με τον Alexey Milovidov, τον κύριο προγραμματιστή του ClickHouse, και τον Kirill Shvakov, έναν προγραμματιστή Golang από την Integros. Συζητήσαμε πώς χρησιμοποιούμε το σύστημα διαχείρισης βάσεων δεδομένων και ποιες δυσκολίες αντιμετωπίζουμε.
Με βάση τη συνάντηση, δημιουργήσαμε ένα άρθρο με απαντήσεις ειδικών στις ερωτήσεις μας και του κοινού σχετικά με τα αντίγραφα ασφαλείας, την ανανέωση δεδομένων, τα εξωτερικά λεξικά, το πρόγραμμα οδήγησης Golang και τις ενημερώσεις της έκδοσης ClickHouse. Μπορεί να είναι χρήσιμο για προγραμματιστές που εργάζονται ήδη ενεργά με το Yandex DBMS και ενδιαφέρονται για το παρόν και το μέλλον του. Οι απαντήσεις του Aleksey Milovidov από προεπιλογή, εκτός αν αναφέρεται διαφορετικά.
Προσοχή, υπάρχει πολύ κείμενο κάτω από την περικοπή. Ελπίζουμε ότι το περιεχόμενο με ερωτήσεις θα σας βοηθήσει να πλοηγηθείτε.
περιεχόμενο
Εάν δεν θέλετε να διαβάσετε το κείμενο, μπορείτε να παρακολουθήσετε την ηχογράφηση των συγκεντρώσεων . Οι χρονικές σημάνσεις βρίσκονται στο πρώτο σχόλιο κάτω από το βίντεο.
Το ClickHouse ενημερώνεται συνεχώς, αλλά τα δεδομένα μας όχι. Τι να το κάνεις;
Το ClickHouse ενημερώνεται συνεχώς και τα δεδομένα μας που υποβλήθηκαν σε επεξεργασία από το optimize final δεν ενημερώνονται και βρίσκονται σε αντίγραφο ασφαλείας.
Ας υποθέσουμε ότι είχαμε κάποιο πρόβλημα και τα δεδομένα χάθηκαν. Αποφασίσαμε να κάνουμε επαναφορά και αποδείχθηκε ότι τα παλιά διαμερίσματα, τα οποία είναι αποθηκευμένα στους εφεδρικούς διακομιστές, είναι πολύ διαφορετικά από την έκδοση του ClickHouse που χρησιμοποιείται αυτήν τη στιγμή. Τι να κάνετε σε μια τέτοια κατάσταση και είναι δυνατόν;
Η κατάσταση στην οποία επαναφέρατε δεδομένα από ένα αντίγραφο ασφαλείας στην παλιά μορφή, αλλά στη νέα έκδοση δεν είναι συνδεδεμένα, είναι αδύνατη. Διασφαλίζουμε ότι η μορφή δεδομένων στο ClickHouse παραμένει πάντα συμβατή προς τα πίσω. Αυτό είναι πολύ πιο σημαντικό από τη συμβατότητα προς τα πίσω στη λειτουργικότητα, εάν η συμπεριφορά κάποιας σπάνια χρησιμοποιούμενης λειτουργίας έχει αλλάξει. Τα δεδομένα που είναι αποθηκευμένα στο δίσκο, η νέα έκδοση του ClickHouse θα πρέπει πάντα να μπορεί να τα διαβάσει. Αυτός είναι ο νόμος.
Ποιες είναι οι τρέχουσες βέλτιστες πρακτικές για τη δημιουργία αντιγράφων ασφαλείας δεδομένων από το ClickHouse;
Πώς να δημιουργήσετε αντίγραφα ασφαλείας, λαμβάνοντας υπόψη ότι έχουμε τελικές λειτουργίες βελτιστοποίησης, μια τεράστια βάση δεδομένων από terabyte και δεδομένα που ενημερώνονται, ας πούμε, τις τελευταίες τρεις ημέρες και μετά δεν τους συμβαίνουν διαδικασίες;
Μπορούμε να συγκεντρώσουμε τη δική μας λύση και να γράψουμε στο κεφάλι: συλλέξτε αυτά τα αντίγραφα ασφαλείας με αυτόν και τον τρόπο. Ίσως δεν χρειάζεται να πατερίσετε τίποτα, και το ποδήλατο εφευρέθηκε εδώ και πολύ καιρό;
Ας ξεκινήσουμε με τις βέλτιστες πρακτικές. Οι συνάδελφοί μου συμβουλεύουν πάντα, απαντώντας σε ερωτήσεις σχετικά με τα αντίγραφα ασφαλείας, να τους υπενθυμίζουν την υπηρεσία Yandex.Cloud, όπου αυτή η εργασία έχει ήδη επιλυθεί. Χρησιμοποιήστε το λοιπόν αν είναι δυνατόν.
Δεν υπάρχει ολοκληρωμένη λύση, εκατό τοις εκατό ενσωματωμένη στο ClickHouse, για δημιουργία αντιγράφων ασφαλείας. Υπάρχουν μερικά κενά που μπορείτε να χρησιμοποιήσετε. Για να λάβετε μια ολοκληρωμένη λύση, θα πρέπει είτε να τσιμπήσετε λίγο με το χέρι, είτε να φτιάξετε περιτυλίγματα σε μορφή σεναρίων.
Θα ξεκινήσω με τις απλούστερες λύσεις και θα ολοκληρώσω με τις πιο εξελιγμένες, ανάλογα με τον όγκο δεδομένων και το μέγεθος του συμπλέγματος. Όσο μεγαλύτερο είναι το σύμπλεγμα, τόσο πιο δύσκολη γίνεται η λύση.
Εάν ο πίνακας δεδομένων καταλαμβάνει μόνο μερικά gigabyte, η δημιουργία αντιγράφων ασφαλείας μπορεί να γίνει ως εξής:
- Αποθηκεύστε τον ορισμό των πινάκων, δηλαδή των μεταδεδομένων − εμφάνιση δημιουργίας πίνακα.
- Δημιουργήστε μια ένδειξη χρήσης χρησιμοποιώντας τον πελάτη ClickHouse − επιλέξτε * από το τραπέζι να αρχειοθετήσω. Από προεπιλογή, θα λάβετε ένα αρχείο σε μορφή TabSeparated. Εάν θέλετε να είστε πιο αποτελεσματικοί, μπορείτε να χρησιμοποιήσετε τη μορφή Native.
Εάν ο όγκος των δεδομένων είναι μεγαλύτερος, τότε το αντίγραφο ασφαλείας θα πάρει περισσότερο χρόνο και πολύ χώρο. Αυτό ονομάζεται λογικό αντίγραφο ασφαλείας, δεν συνδέεται με τη μορφή δεδομένων ClickHouse. Εάν είναι, τότε μπορείτε να πάρετε ένα αντίγραφο ασφαλείας και να το ανεβάσετε στη MySQL για ανάκτηση.
Για πιο προχωρημένες περιπτώσεις, το ClickHouse έχει μια ενσωματωμένη δυνατότητα δημιουργίας στιγμιότυπου κατατμήσεων στο τοπικό σύστημα αρχείων. Αυτή η δυνατότητα είναι διαθέσιμη κατόπιν αιτήματος. alter table freeze partition. Ή απλά αλλοιώστε το πάγωμα του τραπεζιού είναι ένα στιγμιότυπο ολόκληρου του πίνακα.
Το στιγμιότυπο θα δημιουργηθεί συνεπές για έναν πίνακα σε ένα θραύσμα, δηλαδή, είναι αδύνατο να δημιουργηθεί ένα συνεπές στιγμιότυπο ολόκληρου του συμπλέγματος με αυτόν τον τρόπο. Αλλά για τις περισσότερες εργασίες, δεν υπάρχει τέτοια ανάγκη και αρκεί να εκτελέσετε ένα αίτημα σε κάθε θραύσμα και να λάβετε ένα συνεπές στιγμιότυπο. Δημιουργείται με τη μορφή σκληρών συνδέσμων και επομένως δεν καταλαμβάνει επιπλέον χώρο. Στη συνέχεια, αντιγράφετε αυτό το στιγμιότυπο στον διακομιστή αντιγράφων ασφαλείας ή στον αποθηκευτικό χώρο που χρησιμοποιείτε για δημιουργία αντιγράφων ασφαλείας.
Η επαναφορά ενός τέτοιου αντιγράφου ασφαλείας είναι αρκετά εύκολη. Αρχικά, δημιουργείτε πίνακες σύμφωνα με τους υπάρχοντες ορισμούς πινάκων. Στη συνέχεια, αντιγράψτε τα αποθηκευμένα στιγμιότυπα διαμερίσματος στο Directory-Tatached για αυτούς τους πίνακες και εκτελέστε το ερώτημα επισυνάψτε το διαμέρισμα. Αυτή η λύση είναι αρκετά κατάλληλη για τις πιο σοβαρές ποσότητες δεδομένων.
Μερικές φορές χρειάζεστε κάτι ακόμα πιο cool - σε περιπτώσεις που έχετε δεκάδες ή και εκατοντάδες terabyte σε κάθε διακομιστή και εκατοντάδες διακομιστές. Υπάρχει μια λύση εδώ που κατασκόπισα από συναδέλφους από το Yandex.Metrica. Δεν θα το συνιστούσα σε όλους - διαβάστε το και αποφασίστε μόνοι σας αν είναι κατάλληλο ή όχι.
Πρώτα πρέπει να δημιουργήσετε πολλούς διακομιστές με μεγάλα ράφια δίσκων. Στη συνέχεια, αυξήστε πολλούς διακομιστές ClickHouse σε αυτούς τους διακομιστές και ρυθμίστε τους έτσι ώστε να λειτουργούν ως ένα άλλο αντίγραφο για τα ίδια θραύσματα. Στη συνέχεια, χρησιμοποιήστε το σύστημα αρχείων σε αυτούς τους διακομιστές ή κάποιο εργαλείο που σας επιτρέπει να δημιουργείτε στιγμιότυπα. Υπάρχουν δύο επιλογές εδώ. Η πρώτη επιλογή είναι τα στιγμιότυπα LVM, η δεύτερη επιλογή είναι το ZFS σε Linux.
Μετά από αυτό, κάθε μέρα που χρειάζεται να δημιουργείτε ένα στιγμιότυπο, θα βρίσκεται και θα καταλαμβάνει λίγο χώρο. Φυσικά, εάν αλλάξουν τα δεδομένα, με την πάροδο του χρόνου ο χώρος θα αυξηθεί. Μπορείτε να λάβετε αυτό το στιγμιότυπο ανά πάσα στιγμή και να επαναφέρετε τα δεδομένα, μια τόσο περίεργη απόφαση. Επιπλέον, πρέπει ακόμα να περιορίσετε αυτά τα αντίγραφα στη διαμόρφωση, ώστε να μην προσπαθούν να γίνουν ηγέτες.
Θα είναι δυνατό να οργανωθεί ένα ελεγχόμενο ανεκτέλεστο αντίγραφο στα φρεάτια;
Φέτος σχεδιάζετε να φτιάξετε άξονες στο ClickHouse. Θα είναι δυνατό να οργανωθεί ένα ελεγχόμενο ανεκτέλεστο αντίγραφο σε αυτά; Θα θέλαμε να το χρησιμοποιήσουμε για να προστατευθούμε από αρνητικά σενάρια με αλλαγές και άλλες αλλαγές.
Είναι δυνατόν να κάνουμε κάποιου είδους roll back για αλλαγές; Για παράδειγμα, σε έναν υπάρχοντα άξονα, πάρτε και πείτε ότι μέχρι αυτή τη στιγμή, εφαρμόστε τις αλλαγές και από αυτήν τη στιγμή, σταματήστε να εφαρμόζετε τις αλλαγές;
Εάν μια εντολή ήρθε στο σύμπλεγμα μας και την έσπασε, τότε έχουμε ένα αντίγραφο υπό όρους με καθυστέρηση μίας ώρας, όπου μπορούμε να πούμε ότι ας το χρησιμοποιήσουμε αυτήν τη στιγμή, αλλά δεν θα εφαρμόσουμε τις αλλαγές σε αυτό για τα τελευταία δέκα λεπτά;
Αρχικά, σχετικά με το ελεγχόμενο ανεκτέλεστο αντίγραφο. Υπήρξε ένα τέτοιο αίτημα από χρήστες και δημιουργήσαμε ένα ζήτημα στο Github με ένα αίτημα: "Αν κάποιος το χρειάζεται, κάντε ένα like, βάλτε μια καρδιά." Κανείς δεν πόνταρε και το θέμα έκλεισε. Ωστόσο, μπορείτε ήδη να έχετε αυτήν την ευκαιρία ρυθμίζοντας το ClickHouse. Είναι αλήθεια ότι ξεκινώντας μόνο από την έκδοση 20.3.
Το ClickHouse συγχωνεύει συνεχώς δεδομένα στο παρασκήνιο - συγχώνευση. Όταν γίνεται μια συγχώνευση, κάποιο σύνολο τμημάτων δεδομένων αντικαθίσταται με ένα μεγαλύτερο κομμάτι. Ταυτόχρονα, κομμάτια δεδομένων που υπήρχαν στο παρελθόν συνεχίζουν να παραμένουν στο δίσκο για κάποιο χρονικό διάστημα.
Πρώτον, συνεχίζουν να αποθηκεύονται όσο υπάρχουν επιλεγμένα ερωτήματα που τα χρησιμοποιούν, προκειμένου να διασφαλιστεί η μη αποκλειστική λειτουργία. Τα επιλεγμένα αιτήματα διαβάζονται αθόρυβα από παλιά κομμάτια.
Δεύτερον, υπάρχει επίσης ένα χρονικό όριο - παλιά κομμάτια δεδομένων βρίσκονται στο δίσκο για οκτώ λεπτά. Αυτά τα οκτώ λεπτά μπορούν να προσαρμοστούν και να μετατραπούν σε έστω και μία ημέρα. Αυτό θα κοστίσει χώρο στο δίσκο: ανάλογα με τη ροή δεδομένων, θα αποδειχθεί ότι την τελευταία ημέρα τα δεδομένα όχι μόνο θα διπλασιαστούν, αλλά μπορούν να γίνουν πέντε φορές περισσότερα. Αλλά σε περίπτωση σοβαρού προβλήματος, μπορείτε να σταματήσετε τον διακομιστή ClickHouse και να αντιμετωπίσετε τα πάντα.
Τώρα το ερώτημα είναι πώς προστατεύει αυτό από αλλοιώσεις. Αξίζει να ψάξετε πιο βαθιά εδώ, γιατί σε παλαιότερες εκδόσεις του ClickHouse, το alter λειτουργούσε με τέτοιο τρόπο που απλά άλλαζε απευθείας τα κομμάτια. Υπάρχει ένα κομμάτι δεδομένων με ορισμένα αρχεία, και το κάνουμε, για παράδειγμα, αλλαγή στήλης πτώσης. Στη συνέχεια, αυτή η στήλη αφαιρείται φυσικά από όλα τα κομμάτια.
Αλλά από την έκδοση 20.3, ο μηχανισμός αλλαγής έχει αλλάξει εντελώς και τώρα τα κομμάτια δεδομένων είναι πάντα αμετάβλητα. Δεν αλλάζουν καθόλου - οι αλλαγές λειτουργούν πλέον με τον ίδιο τρόπο όπως οι συγχωνεύσεις. Αντί να αλλάξουμε ένα κομμάτι στη θέση του, δημιουργούμε ένα νέο. Στο νέο τεμάχιο, τα αρχεία που δεν έχουν αλλάξει γίνονται σκληροί σύνδεσμοι και αν διαγράψουμε μια στήλη, απλά θα λείπει από το νέο κομμάτι. Το παλιό κομμάτι θα διαγραφεί από προεπιλογή μετά από οκτώ λεπτά και εδώ μπορείτε να τροποποιήσετε τις ρυθμίσεις που αναφέρονται παραπάνω.
Το ίδιο ισχύει για αλλοιώσεις όπως μεταλλάξεις. Όταν το κάνετε αλλαγή διαγραφής ή αλλαγή ενημέρωσης, δεν αλλάζει το κομμάτι, αλλά δημιουργεί ένα νέο. Και μετά διαγράφει το παλιό.
Τι γίνεται αν η δομή του πίνακα έχει αλλάξει;
Πώς να δημιουργήσετε ένα αντίγραφο ασφαλείας που δημιουργήθηκε με το παλιό σχήμα; Και η δεύτερη ερώτηση αφορά την υπόθεση με τα στιγμιότυπα και τα εργαλεία συστήματος αρχείων. Είναι το Btrfs κατάλληλο εδώ αντί του ZFS στο Linux LVM;
Εάν το κάνετε επισυνάψτε το διαμέρισμα κατατμήσεις με διαφορετική δομή, τότε το ClickHouse θα σας πει ότι αυτό δεν είναι δυνατό. Η λύση είναι αυτή. Το πρώτο είναι να δημιουργήσετε έναν προσωρινό πίνακα τύπου MergeTree με την παλιά δομή, να επισυνάψετε δεδομένα εκεί χρησιμοποιώντας την επισύναψη και να εκδώσετε ένα εναλλακτικό ερώτημα. Στη συνέχεια, μπορείτε είτε να αντιγράψετε ή να μεταφέρετε αυτά τα δεδομένα και να τα επισυνάψετε ξανά ή να χρησιμοποιήσετε το ερώτημα αλλαγή κατάτμησης μετακίνησης πίνακα.
Τώρα το δεύτερο ερώτημα είναι αν είναι δυνατό να χρησιμοποιηθεί το Btrfs. Για αρχή, αν έχετε LVM, τότε αρκούν τα στιγμιότυπα LVM και το σύστημα αρχείων μπορεί να είναι ext4, δεν πειράζει. Με το Btrts, όλα εξαρτώνται από την εμπειρία σας με αυτό. Αυτό είναι ένα ώριμο σύστημα αρχείων, αλλά εξακολουθούν να υπάρχουν κάποιες υποψίες για το πώς όλα θα λειτουργήσουν στην πράξη σε ένα συγκεκριμένο σενάριο. Δεν θα συνιστούσα να το χρησιμοποιήσετε εκτός αν έχετε Btrfs στην παραγωγή.
Ποιες είναι οι τρέχουσες βέλτιστες πρακτικές για την ανανέωση δεδομένων;
Το ζήτημα της αναδιάρθρωσης είναι πολύπλοκο και πολύπλευρο. Εδώ μπορείτε να απαντήσετε σε πολλές επιλογές ταυτόχρονα. Μπορείτε να μπείτε από τη μία πλευρά και να το πείτε αυτό - δεν υπάρχει ενσωματωμένη επιλογή αναδιάρθρωσης στο ClickHouse. Αλλά φοβάμαι ότι αυτή η απάντηση δεν θα ταιριάζει σε κανέναν. Επομένως, μπορείτε να πάτε από την άλλη πλευρά και να πείτε ότι το ClickHouse έχει πολλούς τρόπους για να ανανεώσει τα δεδομένα.
Εάν εξαντληθεί ο χώρος στο σύμπλεγμα ή δεν μπορεί να χειριστεί το φορτίο, προσθέτετε νέους διακομιστές. Αλλά αυτοί οι διακομιστές είναι άδειοι από προεπιλογή, δεν υπάρχουν δεδομένα σε αυτούς, δεν υπάρχει φόρτωση. Πρέπει να μετατοπίσετε τα δεδομένα έτσι ώστε να κατανέμονται ομοιόμορφα στο νέο, μεγαλύτερο σύμπλεγμα.
Ο πρώτος τρόπος για να γίνει αυτό είναι να αντιγράψετε μέρος των κατατμήσεων σε νέους διακομιστές χρησιμοποιώντας το ερώτημα αλλαγή κατάτμησης ανάκτησης πίνακα. Για παράδειγμα, είχατε κατατμήσεις ανά μήνες και παίρνετε τον πρώτο μήνα του 2017 και τον αντιγράφετε σε έναν νέο διακομιστή και, στη συνέχεια, αντιγράφετε τον τρίτο μήνα σε κάποιον άλλο νέο διακομιστή. Και έτσι κάνετε μέχρι να γίνει περισσότερο ή λιγότερο ομοιόμορφο.
Η μεταφορά μπορεί να πραγματοποιηθεί μόνο για τα διαμερίσματα που δεν αλλάζουν κατά την εγγραφή. Για νέες κατατμήσεις, η εγγραφή θα πρέπει να απενεργοποιηθεί, επειδή η μεταφορά τους δεν είναι ατομική. Διαφορετικά, θα καταλήξετε με διπλότυπα ή κενά στα δεδομένα. Ωστόσο, αυτή η μέθοδος είναι πρακτική και λειτουργεί αρκετά αποτελεσματικά. Τα έτοιμα συμπιεσμένα διαμερίσματα μεταδίδονται μέσω του δικτύου, δηλαδή τα δεδομένα δεν συμπιέζονται ή επανακωδικοποιούνται.
Αυτή η μέθοδος έχει ένα μειονέκτημα και εξαρτάται από το σύστημα διαμοιρασμού, εάν έχετε δεσμευτεί σε αυτό το σύστημα διαμοιρασμού, ποιο κλειδί διαμοιρασμού είχατε. Στο παράδειγμά σας για την περίπτωση με τις μετρήσεις, το κλειδί κοινής χρήσης είναι ένας κατακερματισμός της διαδρομής. Όταν επιλέγετε έναν κατανεμημένο πίνακα, πηγαίνει σε όλα τα θραύσματα του συμπλέγματος ταυτόχρονα και παίρνει δεδομένα από εκεί.
Αυτό σημαίνει ότι δεν έχει σημασία για εσάς ποια δεδομένα καταλήγουν σε ποιο θραύσμα. Το κύριο πράγμα είναι ότι τα δεδομένα σε μια διαδρομή καταλήγουν σε ένα θραύσμα, αλλά ποιο δεν είναι σημαντικό. Σε αυτήν την περίπτωση, η μεταφορά έτοιμων κατατμήσεων είναι τέλεια, γιατί με επιλεγμένα ερωτήματα, θα λάβετε επίσης πλήρη δεδομένα - τόσο πριν από την αναδιάρθρωση όσο και μετά, το σχήμα δεν έχει πραγματικά σημασία.
Υπάρχουν όμως περιπτώσεις που είναι πιο περίπλοκες. Εάν στο επίπεδο της λογικής εφαρμογής βασίζεστε σε ένα ειδικό σχήμα διαμοιρασμού, ότι αυτός ο πελάτης βρίσκεται σε ένα τέτοιο θραύσμα, και το αίτημα μπορεί να σταλεί αμέσως εκεί και όχι στον πίνακα Κατανεμημένο. Ή χρησιμοποιείτε μια αρκετά πρόσφατη έκδοση του ClickHouse και έχετε ενεργοποιήσει τη ρύθμιση βελτιστοποίηση παράλειψη αχρησιμοποίητων θραυσμάτων. Σε αυτήν την περίπτωση, κατά το ερώτημα επιλογής, θα αναλυθεί η έκφραση στην ενότητα Where και θα υπολογιστεί σε ποια θραύσματα θα μεταβείτε σύμφωνα με το σχήμα διαμοιρασμού. Αυτό λειτουργεί με την προϋπόθεση ότι τα δεδομένα αποσυντίθενται ακριβώς σύμφωνα με αυτό το σχήμα διαμοιρασμού. Εάν τα μετατοπίσατε χειροκίνητα, η αντιστοιχία μπορεί να αλλάξει.
Άρα αυτός είναι ο νούμερο ένα τρόπος. Και περιμένω την απάντησή σας, είναι κατάλληλη η μέθοδος ή προχωρήστε.
Vladimir Kolobaev, επικεφαλής διαχειριστής συστήματος στην Avito: Alexey, η μέθοδος που ανέφερες δεν ταιριάζει πολύ όταν χρειάζεται να απλώσεις το φορτίο, συμπεριλαμβανομένης της ανάγνωσης. Μπορούμε να πάρουμε ένα διαμέρισμα που είναι μηνιαίο και μπορούμε να μεταφέρουμε τον προηγούμενο μήνα σε έναν άλλο κόμβο, αλλά όταν έρθει ένα αίτημα για αυτά τα δεδομένα, θα το φορτώσουμε μόνο. Αλλά θα ήθελα να φορτώσω ολόκληρο το σύμπλεγμα, γιατί, διαφορετικά, για κάποιο χρονικό διάστημα, ολόκληρο το φορτίο ανάγνωσης θα υποβάλλεται σε επεξεργασία από δύο θραύσματα.
Alexey Milovidov: Η απάντηση εδώ είναι περίεργη - ναι, είναι κακό, αλλά μπορεί να λειτουργήσει. Θα εξηγήσω ακριβώς πώς. Αξίζει να δείτε το σενάριο φόρτωσης που συνοδεύει τα δεδομένα σας. Εάν πρόκειται για δεδομένα παρακολούθησης, τότε είναι σχεδόν βέβαιο ότι η συντριπτική πλειονότητα των αιτημάτων αφορά νέα δεδομένα.
Εγκαταστήσατε νέους διακομιστές, μετεγκαταστήσατε παλιά διαμερίσματα, αλλά αλλάξατε και τον τρόπο εγγραφής των φρέσκων δεδομένων. Και νέα δεδομένα θα διαδοθούν σε όλο το σύμπλεγμα. Έτσι, μετά από πέντε λεπτά, τα αιτήματα για τα τελευταία πέντε λεπτά θα φορτώσουν ομοιόμορφα το σύμπλεγμα, μετά από μια ημέρα, τα αιτήματα για μια ημέρα θα φορτώσουν ομοιόμορφα το σύμπλεγμα. Και τα αιτήματα για τον προηγούμενο μήνα, δυστυχώς, θα πάνε μόνο σε ένα μέρος των διακομιστών συμπλέγματος.
Συχνά όμως δεν θα έχετε αιτήματα για τον Φεβρουάριο του 2019. Πιθανότατα, εάν τα αιτήματα πάνε στο 2019, τότε θα είναι για ολόκληρο το 2019 - για μεγάλο χρονικό διάστημα, και όχι για κάποιο μικρό εύρος. Και τέτοια αιτήματα θα μπορούν επίσης να φορτώσουν ομοιόμορφα το σύμπλεγμα. Αλλά γενικά, η παρατήρησή σας είναι πολύ σωστή ότι πρόκειται για μια ad hoc λύση που δεν κατανέμει τα δεδομένα εντελώς ομοιόμορφα.
Έχω μερικά ακόμη σημεία για να απαντήσω στην ερώτηση. Ένα από αυτά αφορά το πώς να φτιάξετε αρχικά το σχέδιο θρυμματισμού έτσι ώστε να υπάρχει λιγότερος πόνος από το resharding. Αυτό δεν είναι πάντα δυνατό.
Για παράδειγμα, έχετε δεδομένα παρακολούθησης. Τα δεδομένα παρακολούθησης αυξάνονται για τρεις λόγους. Το πρώτο είναι η συσσώρευση ιστορικών δεδομένων. Το δεύτερο είναι η αύξηση της κυκλοφορίας. Και το τρίτο είναι η αύξηση του αριθμού των πραγμάτων που υπόκεινται σε παρακολούθηση. Υπάρχουν νέες μικροϋπηρεσίες και μετρήσεις που πρέπει να αποθηκευτούν.
Είναι πιθανό ότι από αυτά, η μεγαλύτερη αύξηση οφείλεται στον τρίτο λόγο - πρόκειται για αύξηση στη χρήση της παρακολούθησης. Και σε αυτή την περίπτωση, αξίζει να δούμε τη φύση του φορτίου, ποια είναι τα κύρια αιτήματα για επιλογή. Τα κύρια ερωτήματα επιλογής είναι πιθανό να ακολουθούν κάποιο υποσύνολο των μετρήσεων.
Για παράδειγμα, χρήση CPU σε ορισμένους διακομιστές από κάποια υπηρεσία. Αποδεικνύεται ότι υπάρχει κάποιο υποσύνολο κλειδιών με τα οποία λαμβάνετε αυτά τα δεδομένα. Και το ίδιο το αίτημα για αυτά τα δεδομένα είναι πιθανότατα αρκετά απλό και εκτελείται σε δεκάδες χιλιοστά του δευτερολέπτου. Χρησιμοποιείται για υπηρεσίες παρακολούθησης, για πίνακες εργαλείων. Ελπίζω να το κατάλαβα σωστά.
Vladimir Kolobaev: Γεγονός είναι ότι πολύ συχνά επικαλούμαστε ιστορικά δεδομένα, αφού συγκρίνουμε τη σημερινή θέση με την ιστορική σε πραγματικό χρόνο. Και είναι σημαντικό για εμάς να έχουμε γρήγορη πρόσβαση σε μεγάλο όγκο δεδομένων και το ClickHouse κάνει εξαιρετική δουλειά με αυτό.
Έχετε απόλυτο δίκιο, τα περισσότερα από τα αιτήματα ανάγνωσης βιώνουμε την τελευταία μέρα, όπως κάθε σύστημα παρακολούθησης. Ταυτόχρονα όμως, το φορτίο στα ιστορικά δεδομένα είναι επίσης αρκετά μεγάλο. Προέρχεται κυρίως από ένα σύστημα ειδοποίησης που περιστρέφεται κάθε τριάντα δευτερόλεπτα και λέει στο ClickHouse, «Δώσε μου τα δεδομένα για τις τελευταίες έξι εβδομάδες. Τώρα φτιάξτε μου έναν κινητό μέσο όρο από αυτά και ας συγκρίνουμε την τρέχουσα αξία με την ιστορική αξία.
Θα ήθελα να πω ότι για τέτοια πολύ φρέσκα αιτήματα έχουμε ένα άλλο μικρό τραπέζι στο οποίο αποθηκεύουμε δεδομένα μόνο δύο ημερών και τα κύρια αιτήματα πετούν σε αυτό. Στέλνουμε μόνο μεγάλα ιστορικά ερωτήματα σε έναν μεγάλο τεμαχισμένο πίνακα.
Alexey Milovidov: Δυστυχώς, αποδεικνύεται ότι είναι ελάχιστα εφαρμόσιμο για το σενάριο σας, αλλά θα περιγράψω δύο κακά και πολύπλοκα σχήματα διαμοιρασμού που δεν χρειάζεται να χρησιμοποιηθούν, αλλά χρησιμοποιούνται στην υπηρεσία φίλων μου.
Υπάρχει ένα κύριο σύμπλεγμα με συμβάντα Yandex.Metrics. Τα συμβάντα είναι προβολές σελίδας, κλικ και μεταβάσεις. Τα περισσότερα αιτήματα πηγαίνουν σε έναν συγκεκριμένο ιστότοπο. Ανοίγετε την υπηρεσία Yandex.Metrica, έχετε έναν ιστότοπο - avito.ru, μεταβείτε στην αναφορά και υποβάλλεται αίτημα για τον ιστότοπό σας.
Υπάρχουν όμως και άλλα αιτήματα - αναλυτικά και παγκόσμια, τα οποία υποβάλλονται από εσωτερικούς αναλυτές. Για κάθε περίπτωση, σημειώνω ότι οι εσωτερικοί αναλυτές κάνουν αιτήματα μόνο για υπηρεσίες Yandex. Ωστόσο, ακόμη και οι υπηρεσίες Yandex καταλαμβάνουν σημαντικό μερίδιο όλων των δεδομένων. Δεν πρόκειται για αιτήματα για συγκεκριμένους μετρητές, αλλά για ευρύτερο φιλτράρισμα.
Πώς να οργανώσετε τα δεδομένα με τέτοιο τρόπο ώστε όλα να λειτουργούν αποτελεσματικά για έναν μετρητή, καθώς και για καθολικά ερωτήματα; Μια άλλη δυσκολία έγκειται στο γεγονός ότι ο αριθμός των αιτημάτων στο ClickHouse για το σύμπλεγμα Metrics είναι αρκετές χιλιάδες ανά δευτερόλεπτο. Ταυτόχρονα, ένας διακομιστής ClickHouse δεν χειρίζεται μη τετριμμένα αιτήματα, για παράδειγμα, πολλές χιλιάδες ανά δευτερόλεπτο.
Το μέγεθος του συμπλέγματος είναι εξακόσιοι διακομιστές. Εάν απλώσετε απλώς έναν πίνακα Κατανεμημένο σε αυτό το σύμπλεγμα και στείλετε πολλές χιλιάδες αιτήματα εκεί, θα γίνει ακόμα χειρότερο από το να τα στείλετε σε έναν διακομιστή. Από την άλλη, η επιλογή να κατανέμονται ομοιόμορφα τα δεδομένα, και πάμε και ζητάμε από όλους τους διακομιστές, απορρίπτεται αμέσως.
Υπάρχει μια εκ διαμέτρου αντίθετη επιλογή. Φανταστείτε να μοιράζουμε δεδομένα ανά τοποθεσία και ένα αίτημα για έναν ιστότοπο πηγαίνει σε ένα θραύσμα. Τώρα το σύμπλεγμα θα μπορεί να βγάλει δέκα χιλιάδες αιτήματα ανά δευτερόλεπτο, αλλά σε ένα θραύσμα ένα αίτημα θα λειτουργεί πολύ αργά. Δεν θα κλιμακώνεται πλέον σε εύρος ζώνης. Ειδικά αν πρόκειται για ιστότοπο avito.ru. Δεν θα αποκαλύψω μυστικό αν πω ότι το Avito είναι ένα από τα πιο δημοφιλή site στο Runet. Και να το επεξεργαστούμε σε ένα κομμάτι θα ήταν τρελό.
Ως εκ τούτου, το σχέδιο διαμοιρασμού είναι διευθετημένο με πιο δύσκολο τρόπο. Ολόκληρο το σύμπλεγμα χωρίζεται σε έναν αριθμό συστάδων, τα οποία ονομάζουμε στρώματα. Μέσα σε κάθε συστάδα υπάρχουν από δέκα έως αρκετές δεκάδες θραύσματα. Υπάρχουν τριάντα εννέα τέτοια συμπλέγματα συνολικά.
Πώς γίνεται όλο αυτό; Ο αριθμός των συστάδων δεν αλλάζει - όπως ήταν πριν από τριάντα εννέα χρόνια, παραμένει ίδιος. Αλλά μέσα σε καθένα από αυτά, αυξάνουμε σταδιακά τον αριθμό των θραυσμάτων καθώς συσσωρεύονται δεδομένα. Και το σύστημα διαμοιρασμού στο σύνολό του είναι το εξής - η διαίρεση σε αυτά τα συμπλέγματα γίνεται ανά ιστότοπους και για να κατανοήσουμε ποιος ιστότοπος βρίσκεται σε ποιο σύμπλεγμα, χρησιμοποιείται γενικά μια ξεχωριστή μετα-βάση στη MySQL. Ένας ιστότοπος - σε ένα σύμπλεγμα. Και μέσα σε αυτό, η διαμοιρασμός γίνεται σύμφωνα με τα αναγνωριστικά των επισκεπτών.
Κατά την εγγραφή, τα χωρίζουμε με το υπόλοιπο του αναγνωριστικού επισκέπτη. Αλλά όταν προστίθεται ένα νέο θραύσμα, το σχήμα μοιρασμού αλλάζει, συνεχίζουμε να χωρίζουμε, αλλά με το υπόλοιπο να διαιρούμε με έναν άλλο αριθμό. Αυτό σημαίνει ότι ένας επισκέπτης βρίσκεται ήδη σε πολλούς διακομιστές και δεν μπορείτε να στοιχηματίσετε σε αυτόν. Αυτό γίνεται αποκλειστικά για να διασφαλιστεί ότι τα δεδομένα συμπιέζονται καλύτερα. Και όταν κάνουμε ερώτημα, πηγαίνουμε στον πίνακα Κατανεμημένο, ο οποίος κοιτάζει το σύμπλεγμα και έχει πρόσβαση σε δεκάδες διακομιστές. Αυτό είναι ένα τόσο ανόητο σχέδιο.
Αλλά η ιστορία μου θα είναι ελλιπής αν δεν πω ότι έχουμε εγκαταλείψει αυτό το σχήμα. Στο νέο σχήμα, αλλάξαμε τα πάντα και αντιγράψαμε όλα τα δεδομένα χρησιμοποιώντας το clickhouse-copier.
Στο νέο σχήμα, όλοι οι ιστότοποι χωρίζονται σε δύο κατηγορίες - μεγάλες και μικρές. Δεν ξέρω πώς επιλέχθηκε το όριο εκεί, αλλά ως αποτέλεσμα, αποδείχθηκε ότι οι μεγάλοι ιστότοποι καταγράφονται σε ένα σύμπλεγμα, όπου υπάρχουν 120 θραύσματα με τρία αντίγραφα σε κάθε ένα - δηλαδή, 360 διακομιστές. Και το σχέδιο διαμοιρασμού είναι τέτοιο που κάθε αίτημα πηγαίνει σε όλα τα θραύσματα ταυτόχρονα. Αν τώρα ανοίξετε οποιαδήποτε σελίδα αναφοράς για το avito.ru στο Yandex.Metrica, το αίτημα θα πάει σε 120 διακομιστές. Υπάρχουν λίγες μεγάλες τοποθεσίες στο Runet. Και τα αιτήματα δεν είναι χίλια το δευτερόλεπτο, αλλά ακόμη και λιγότερα από εκατό. Όλα αυτά μασώνται αθόρυβα από τον πίνακα Κατανεμημένων, που ο καθένας τους επεξεργάζεται 120 διακομιστές.
Και το δεύτερο σύμπλεγμα είναι για μικρές τοποθεσίες. Ακολουθεί ένα σχήμα διαμοιρασμού ανά αναγνωριστικό τοποθεσίας και κάθε αίτημα πηγαίνει σε ακριβώς ένα θραύσμα.
Το ClickHouse διαθέτει ένα βοηθητικό πρόγραμμα clickhouse-copier. Μπορείτε να πείτε για αυτήν;
Πρέπει να πω αμέσως ότι αυτή η λύση είναι πιο δυσκίνητη και κάπως λιγότερο παραγωγική. Το πλεονέκτημα είναι ότι κηλιδώνει πλήρως τα δεδομένα σύμφωνα με το σχήμα που καθορίζετε. Αλλά το μειονέκτημα του βοηθητικού προγράμματος είναι ότι δεν ανανεώνει καθόλου. Αντιγράφει δεδομένα από ένα σχήμα συμπλέγματος σε ένα άλλο σχήμα συμπλέγματος.
Αυτό σημαίνει ότι για να λειτουργήσει, πρέπει να έχετε δύο συμπλέγματα. Μπορούν να βρίσκονται στους ίδιους διακομιστές, αλλά, ωστόσο, τα δεδομένα δεν θα μετακινηθούν σταδιακά, αλλά θα αντιγραφούν.
Για παράδειγμα, υπήρχαν τέσσερις διακομιστές, τώρα υπάρχουν οκτώ. Δημιουργείτε έναν νέο κατανεμημένο πίνακα σε όλους τους διακομιστές, νέους τοπικούς πίνακες και εκκινείτε το clickhouse-copier, προσδιορίζοντας σε αυτό το σχήμα εργασίας που πρέπει να διαβάσει από εκεί, αποδεχτείτε το νέο σχήμα κοινής χρήσης και μεταφέρετε δεδομένα εκεί. Και θα χρειαστείτε μιάμιση φορά περισσότερο χώρο στους παλιούς διακομιστές από ό,τι έχετε τώρα, επειδή τα παλιά δεδομένα πρέπει να παραμείνουν σε αυτούς και τα μισά από τα ίδια παλιά δεδομένα θα έρθουν πάνω τους. Εάν σκεφτήκατε εκ των προτέρων ότι τα δεδομένα πρέπει να ανανεωθούν και υπάρχει χώρος, τότε αυτή η μέθοδος είναι κατάλληλη.
Πώς λειτουργεί το clickhouse-copier μέσα; Χωρίζει όλη την εργασία σε ένα σύνολο εργασιών για την επεξεργασία ενός διαμερίσματος ενός πίνακα σε ένα θραύσμα. Όλες αυτές οι εργασίες μπορούν να εκτελούνται παράλληλα και το clickhouse-copier μπορεί να εκτελέσει πολλές παρουσίες σε διαφορετικά μηχανήματα, αλλά αυτό που κάνει για ένα μεμονωμένο διαμέρισμα δεν είναι τίποτα άλλο από μια επιλογή εισαγωγής. Τα δεδομένα διαβάζονται, αποσυμπιέζονται, αναδιαμερίζονται, μετά συμπιέζονται ξανά, γράφονται κάπου, ταξινομούνται εκ νέου. Αυτή είναι μια πιο δύσκολη απόφαση.
Είχες ένα πιλοτικό πράγμα που λέγεται resharding. Τι γίνεται με αυτήν;
Πίσω το 2017, είχατε ένα πιλοτικό πράγμα που ονομαζόταν resharding. Υπάρχει ακόμη και μια επιλογή στο ClickHouse. Καταλαβαίνω ότι δεν απογειώθηκε. Μπορείτε να πείτε γιατί συνέβη; Φαίνεται να είναι πολύ σχετικό.
Το όλο πρόβλημα είναι ότι εάν χρειάζεται να ανανεώσετε τα δεδομένα στη θέση τους, απαιτείται ένας πολύ περίπλοκος συγχρονισμός για να γίνει αυτό ατομικά. Όταν αρχίσαμε να εξετάζουμε πώς λειτουργεί αυτός ο συγχρονισμός, έγινε σαφές ότι υπάρχουν θεμελιώδη προβλήματα. Και αυτά τα θεμελιώδη προβλήματα δεν είναι μόνο θεωρητικά, αλλά αμέσως άρχισαν να εμφανίζονται στην πράξη με τη μορφή κάτι που μπορεί να εξηγηθεί πολύ απλά - τίποτα δεν λειτουργεί.
Είναι δυνατή η συγχώνευση όλων των τμημάτων των δεδομένων πριν από τη μετάβαση σε αργούς δίσκους;
Μια ερώτηση σχετικά με το TTL με την επιλογή μετακίνησης σε αργό δίσκο στο πλαίσιο συγχωνεύσεων. Υπάρχει άλλος τρόπος εκτός από το cron για να συγχωνεύσετε όλα τα μέρη σε ένα πριν μεταβείτε σε αργούς δίσκους;
Η απάντηση στο ερώτημα εάν είναι δυνατόν να κολληθούν με κάποιο τρόπο αυτόματα όλα τα κομμάτια σε ένα πριν τη μεταφορά τους είναι όχι. Μου φαίνεται ότι αυτό δεν είναι απαραίτητο. Δεν μπορείτε να συγχωνεύσετε όλα τα μέρη σε ένα, αλλά απλώς να βασιστείτε στο γεγονός ότι θα μεταφερθούν αυτόματα σε αργούς δίσκους.
Έχουμε δύο κριτήρια για τους κανόνες μεταγραφής. Το πρώτο είναι καθώς γεμίζει. Εάν το τρέχον επίπεδο αποθήκευσης έχει λιγότερο από ένα ορισμένο ποσοστό ελεύθερου χώρου, επιλέγουμε ένα κομμάτι και το μετακινούμε σε πιο αργό χώρο αποθήκευσης. Ή μάλλον, όχι πιο αργά, αλλά το εξής - πώς το ρυθμίζετε.
Το δεύτερο κριτήριο είναι το μέγεθος. Μιλάει για μεταφορά μεγάλων κομματιών. Μπορείτε να προσαρμόσετε το όριο με βάση τον ελεύθερο χώρο σε έναν γρήγορο δίσκο και τα δεδομένα θα μετεγκατασταθούν αυτόματα.
Πώς να πραγματοποιήσετε μετεγκατάσταση σε νέες εκδόσεις του ClickHouse εάν δεν υπάρχει τρόπος να ελέγξετε τη συμβατότητα εκ των προτέρων;
Αυτό το θέμα συζητείται τακτικά λαμβάνοντας υπόψη διαφορετικές εκδοχές, και όμως. Πόσο ασφαλής είναι η αναβάθμιση από την έκδοση 19.11 στην 19.16 και, για παράδειγμα, από την 19.16 στην 20.3. Ποιος είναι ο καλύτερος τρόπος για να μετακινηθείτε σε νέες εκδόσεις χωρίς να μπορείτε να ελέγξετε τη συμβατότητα στο sandbox εκ των προτέρων;
Υπάρχουν μερικοί χρυσοί κανόνες εδώ. Πρώτα - . Είναι μεγάλο, αλλά υπάρχουν ξεχωριστά σημεία για μη συμβατές αλλαγές προς τα πίσω. Μην αντιμετωπίζετε αυτά τα αντικείμενα ως κόκκινη σημαία. Αυτές είναι συνήθως μικρές ασυμβατότητες που σχετίζονται με κάποια λειτουργικότητα άκρων που πιθανότατα δεν χρησιμοποιείτε.
Δεύτερον, εάν δεν υπάρχει τρόπος να ελέγξετε τη συμβατότητα στο sandbox και θέλετε να κάνετε αναβάθμιση αμέσως στην παραγωγή, η σύσταση είναι ότι δεν χρειάζεται να το κάνετε αυτό. Πρώτα δημιουργήστε ένα sandbox και δοκιμάστε. Εάν δεν υπάρχει περιβάλλον δοκιμής, τότε πιθανότατα δεν έχετε πολύ μεγάλη εταιρεία, πράγμα που σημαίνει ότι μπορείτε να αντιγράψετε ορισμένα από τα δεδομένα στον φορητό υπολογιστή σας και να βεβαιωθείτε ότι όλα λειτουργούν σωστά σε αυτόν. Μπορείτε ακόμη και να εμφανίσετε μερικά αντίγραφα τοπικά στον υπολογιστή σας. Ή μπορείτε να ανεβάσετε μια νέα έκδοση κάπου κοντά και να ανεβάσετε κάποια δεδομένα εκεί - δηλαδή, να δημιουργήσετε ένα αυτοσχέδιο περιβάλλον δοκιμής.
Ένας άλλος κανόνας είναι να μην ενημερώνεστε εντός μίας εβδομάδας μετά την κυκλοφορία της έκδοσης λόγω της σύλληψης σφαλμάτων στην παραγωγή και των επακόλουθων γρήγορων επιδιορθώσεων. Ας κατανοήσουμε την αρίθμηση της έκδοσης ClickHouse για να μην μπερδευτούμε.
Υπάρχει η έκδοση 20.3.4. Ο αριθμός 20 υποδεικνύει το έτος κατασκευής - 2020. Από την άποψη του τι υπάρχει μέσα, αυτό δεν έχει σημασία, επομένως δεν θα δώσουμε προσοχή σε αυτό. Περαιτέρω - 20.3. Ο δεύτερος αριθμός - σε αυτήν την περίπτωση 3 - αυξάνουμε κάθε φορά που κυκλοφορούμε μια έκδοση με κάποια νέα λειτουργικότητα. Εάν θέλουμε να προσθέσουμε κάποια δυνατότητα στο ClickHouse, πρέπει να αυξήσουμε αυτόν τον αριθμό. Δηλαδή, στην έκδοση 20.4 το ClickHouse θα λειτουργεί ακόμα καλύτερα. Το τρίτο ψηφίο είναι 20.3.4. Εδώ 4 είναι ο αριθμός των κυκλοφοριών ενημερώσεων κώδικα στις οποίες δεν προσθέσαμε νέες δυνατότητες, αλλά διορθώσαμε ορισμένα σφάλματα. Και το 4 σημαίνει ότι το κάναμε τέσσερις φορές.
Μην νομίζετε ότι είναι κάτι τρομερό. Συνήθως ο χρήστης μπορεί να εγκαταστήσει την πιο πρόσφατη έκδοση και θα λειτουργεί χωρίς προβλήματα με το χρόνο λειτουργίας ανά έτος. Φανταστείτε όμως ότι σε κάποια συνάρτηση επεξεργασίας bitmap, που προστέθηκε από τους Κινέζους συντρόφους μας, όταν περνούν λανθασμένα ορίσματα, ο διακομιστής κολλάει. Πρέπει να το διορθώσουμε αυτό. Θα κυκλοφορήσουμε μια νέα έκδοση ενημέρωσης κώδικα και το ClickHouse θα γίνει πιο σταθερό.
Εάν έχετε το ClickHouse που εργάζεται στην παραγωγή και έχει κυκλοφορήσει μια νέα έκδοση του ClickHouse με πρόσθετες δυνατότητες - για παράδειγμα, η 20.4.1 είναι η πρώτη, μην βιαστείτε να το βάλετε στην παραγωγή την πρώτη μέρα. Γιατί τη χρειάζεται καθόλου; Εάν δεν χρησιμοποιείτε ακόμα το ClickHouse, τότε μπορείτε να το εγκαταστήσετε και, πιθανότατα, όλα θα πάνε καλά. Αλλά εάν το ClickHouse λειτουργεί ήδη σταθερά, τότε μείνετε συντονισμένοι για ενημερώσεις κώδικα και ενημερώσεις - ποια προβλήματα διορθώνουμε.
Kirill Shvakov: Θέλω να προσθέσω λίγα σχετικά με τα περιβάλλοντα δοκιμής. Όλοι φοβούνται πολύ τα περιβάλλοντα δοκιμής και για κάποιο λόγο πιστεύουν ότι εάν έχετε ένα πολύ μεγάλο σύμπλεγμα ClickHouse, τότε το περιβάλλον δοκιμής δεν πρέπει να είναι μικρότερο ή τουλάχιστον δέκα φορές μικρότερο. Δεν είναι καθόλου έτσι.
Μπορώ να καταλάβω από το παράδειγμά μου. Έχω ένα έργο και υπάρχει το ClickHouse. Το περιβάλλον δοκιμής μας γι 'αυτόν είναι μια μικρή εικονική μηχανή στο Hetzner για είκοσι ευρώ, όπου αναπτύσσονται απολύτως τα πάντα. Για να γίνει αυτό, έχουμε πλήρη αυτοματοποίηση στο Ansible, και ως εκ τούτου, κατ 'αρχήν, δεν υπάρχει διαφορά πού να κυλήσουμε - σε σιδερένιους διακομιστές ή απλώς να αναπτύξουμε σε εικονικές μηχανές.
Τί μπορεί να γίνει? Θα ήταν ωραίο να δημιουργήσετε ένα παράδειγμα στην τεκμηρίωση του ClickHouse σχετικά με τον τρόπο ανάπτυξης ενός μικρού συμπλέγματος μόνοι σας - στο Docker, στο LXC, ίσως δημιουργήσετε ένα βιβλίο παιχνιδιού Ansible, επειδή διαφορετικοί άνθρωποι έχουν διαφορετικές αναπτύξεις. Αυτό θα κάνει πολλά πράγματα πιο εύκολα. Όταν παίρνετε και αναπτύσσετε ένα σύμπλεγμα σε πέντε λεπτά, είναι πολύ πιο εύκολο να προσπαθήσετε να καταλάβετε κάτι. Είναι πολύ πιο βολικό με αυτόν τον τρόπο, επειδή η κυκλοφορία μιας έκδοσης που δεν έχετε δοκιμάσει στην παραγωγή είναι ένας δρόμος προς το πουθενά. Μερικές φορές λειτουργεί και άλλες όχι. Και έτσι η ελπίδα για επιτυχία είναι κακό.
Maxim Kotyakov, ανώτερος μηχανικός υποστήριξης Avito: Θα προσθέσω λίγα για τα δοκιμαστικά περιβάλλοντα από μια σειρά προβλημάτων για μεγάλες εταιρείες. Διαθέτουμε ένα πλήρες σύμπλεγμα αποδοχής ClickHouse, σύμφωνα με σχήματα δεδομένων και ρυθμίσεις, ένα ακριβές αντίγραφο του τι είναι σε παραγωγή. Αυτό το σύμπλεγμα αναπτύσσεται σε μάλλον σάπια δοχεία με ελάχιστους πόρους. Γράφουμε εκεί ένα ορισμένο ποσοστό των δεδομένων παραγωγής, αφού υπάρχει η ευκαιρία να αναπαραχθεί το ρεύμα στον Κάφκα. Όλα συγχρονίζονται και κλιμακώνονται εκεί - τόσο όσον αφορά τη χωρητικότητα και τη ροή, και, θεωρητικά, όλα τα άλλα πράγματα ίσα, θα πρέπει να συμπεριφέρονται σαν παραγωγή όσον αφορά τις μετρήσεις. Οτιδήποτε δυνητικά εκρηκτικό τυλίγεται πρώτα σε αυτό το περίπτερο και εγχέεται εκεί για αρκετές ημέρες μέχρι να είναι έτοιμο. Αλλά φυσικά, αυτή η λύση είναι ακριβή, βαριά και με μη μηδενικό κόστος υποστήριξης.
Alexey Milovidov: Θα σας πω πώς είναι το δοκιμαστικό περιβάλλον των φίλων μας από το Yandex.Metrica. Το ένα σύμπλεγμα είχε περίπου 600 διακομιστές, το άλλο είχε 360 και υπάρχει ένα τρίτο και πολλά συμπλέγματα. Το περιβάλλον δοκιμής για ένα από αυτά είναι μόνο δύο θραύσματα με δύο αντίγραφα στο καθένα. Γιατί δύο θραύσματα; Για να μην είμαι μόνος. Και αντίγραφα, επίσης, να είναι. Μόνο ένα ελάχιστο ποσό που μπορείτε να αντέξετε οικονομικά.
Αυτό το περιβάλλον δοκιμής σάς επιτρέπει να ελέγχετε την υγεία των αιτημάτων και εάν κάτι έχει χαλάσει σε μεγάλο βαθμό. Αλλά συχνά προκύπτουν προβλήματα εντελώς διαφορετικής φύσης, όταν όλα λειτουργούν, αλλά υπάρχουν κάποιες μικρές αλλαγές με το φορτίο.
Θα σας δώσω ένα παράδειγμα. Αποφασίσαμε να εγκαταστήσουμε μια νέα έκδοση του ClickHouse. Είναι τοποθετημένο σε ένα περιβάλλον δοκιμής, αυτοματοποιημένες δοκιμές περνούν στο ίδιο το Yandex.Metrica, οι οποίες συγκρίνουν δεδομένα για την παλιά έκδοση και τη νέα, εκτελώντας ολόκληρο τον αγωγό. Και φυσικά, πράσινες δοκιμές του CI μας. Διαφορετικά, δεν θα είχαμε καν προτείνει αυτήν την έκδοση.
Ολα ειναι καλά. Αρχίζουμε να μπαίνουμε στην παραγωγή. Λαμβάνω ένα μήνυμα ότι το φορτίο έχει αυξηθεί αρκετές φορές στα γραφήματα. Επαναφέρουμε την έκδοση. Κοιτάζω το γράφημα και βλέπω: το φορτίο αυξήθηκε πραγματικά αρκετές φορές κατά τη διάρκεια της κυκλοφορίας και μειώθηκε ξανά όταν κυκλοφόρησε. Μετά αρχίσαμε να επαναφέρουμε την έκδοση. Και το φορτίο αυξήθηκε με τον ίδιο τρόπο και έπεσε πίσω με τον ίδιο τρόπο. Το συμπέρασμα λοιπόν είναι αυτό - το φορτίο έχει αυξηθεί σε σχέση με τον υπολογισμό, τίποτα δεν προκαλεί έκπληξη.
Τότε ήταν δύσκολο να πειστούν οι συνάδελφοι να εγκαταστήσουν τη νέα έκδοση τελικά. Λέω: «Δεν πειράζει, βγάλε. Κράτα τα δάχτυλά σου σταυρωμένα, όλα θα λειτουργήσουν. Τώρα το φορτίο έχει αυξηθεί στα charts, αλλά όλα είναι καλά. Περίμενε." Σε γενικές γραμμές, το κάναμε αυτό, και αυτό είναι - η έκδοση δημοσιεύεται στον ιστότοπο παραγωγής. Αλλά σχεδόν με κάθε υπολογισμό, προκύπτουν παρόμοια προβλήματα.
Το Kill Query υποτίθεται ότι σκοτώνει τα ερωτήματα, αλλά δεν το κάνει. Γιατί;
Ένας χρήστης ήρθε σε εμένα, κάποιο είδος αναλυτή, και δημιούργησε ένα συγκεκριμένο αίτημα, το οποίο έβαλε το σύμπλεγμα ClickHouse μου. Κάποιος κόμβος ή ένα ολόκληρο σύμπλεγμα, ανάλογα με το αντίγραφο ή το θραύσμα στο οποίο μπήκε το αίτημα. Βλέπω ότι όλοι οι πόροι της CPU σε αυτόν τον διακομιστή βρίσκονται στο ράφι, όλα είναι κόκκινα. Ταυτόχρονα, το ίδιο το ClickHouse ανταποκρίνεται σε αιτήματα. Και γράφω: "Παρακαλώ δείξτε μου τη λίστα διαδικασιών, το οποίο αίτημα δημιούργησε αυτήν την τρέλα."
Βρίσκω αυτό το αίτημα και γράφω kill to it. Και βλέπω ότι δεν συμβαίνει τίποτα. Ο διακομιστής μου είναι στο ράφι, το ClickHouse μετά μου δίνει μερικές εντολές, δείχνει ότι ο διακομιστής είναι ζωντανός και όλα είναι καλά. Αλλά έχω υποβάθμιση σε όλα τα αιτήματα χρηστών, η υποβάθμιση με καταχώριση στο ClickHouse ξεκινά και το ερώτημά μου kill δεν λειτουργεί. Γιατί; Νόμιζα ότι το kill query έπρεπε να σκοτώσει τα ερωτήματα, αλλά δεν το κάνει.
Τώρα θα υπάρξει μια μάλλον περίεργη απάντηση. Το θέμα είναι ότι το kill query δεν σκοτώνει αιτήματα.
Το Kill query βάζει ένα μικρό πλαίσιο ελέγχου που ονομάζεται "Θέλω αυτό το ερώτημα να σκοτωθεί". Και το ίδιο το αίτημα, κατά την επεξεργασία κάθε μπλοκ, κοιτάζει αυτή τη σημαία. Εάν έχει οριστεί, το αίτημα σταματά να λειτουργεί. Αποδεικνύεται ότι κανείς δεν σκοτώνει το αίτημα, ο ίδιος πρέπει να ελέγξει τα πάντα και να σταματήσει. Και αυτό θα πρέπει να λειτουργεί σε όλες τις περιπτώσεις όπου το αίτημα βρίσκεται σε κατάσταση επεξεργασίας μπλοκ. Θα επεξεργαστεί το επόμενο μπλοκ δεδομένων, θα ελέγξει τη σημαία και θα σταματήσει.
Αυτό δεν λειτουργεί σε περιπτώσεις όπου το αίτημα έχει αποκλειστεί σε κάποια λειτουργία. Είναι αλήθεια ότι αυτό πιθανότατα δεν είναι η περίπτωσή σας, επειδή, σύμφωνα με εσάς, χρησιμοποιεί ένα σωρό πόρους διακομιστή. Είναι πιθανό αυτό να μην λειτουργεί στην περίπτωση εξωτερικής ταξινόμησης και σε κάποιες άλλες λεπτομέρειες. Αλλά γενικά, αυτό δεν πρέπει να είναι, αυτό είναι ένα σφάλμα. Και το μόνο πράγμα που μπορώ να συμβουλεύσω είναι να ενημερώσω το ClickHouse.
Πώς να υπολογίσετε τον χρόνο απόκρισης υπό φορτίο ανάγνωσης;
Υπάρχει ένας πίνακας που αποθηκεύει συγκεντρωτικά είδη - διάφορους μετρητές. Ο αριθμός των γραμμών είναι περίπου εκατό εκατομμύρια. Είναι δυνατόν να υπολογίζετε σε προβλέψιμο χρόνο απόκρισης εάν ρίξετε 1K RPS σε 1K αντικείμενα;
Κρίνοντας από το πλαίσιο, μιλάμε για φόρτο ανάγνωσης, επειδή δεν υπάρχουν προβλήματα με τη γραφή - μπορούν να εισαχθούν τουλάχιστον χίλιες, τουλάχιστον εκατό χιλιάδες και μερικές φορές πολλά εκατομμύρια γραμμές.
Τα αιτήματα για ανάγνωση είναι πολύ διαφορετικά. Στην επιλογή 1, το ClickHouse μπορεί να εκτελέσει περίπου δεκάδες χιλιάδες αιτήματα ανά δευτερόλεπτο, επομένως ακόμη και τα αιτήματα για ένα μόνο κλειδί θα απαιτούν ήδη κάποιους πόρους. Και τέτοια ερωτήματα σημείου θα είναι πιο δύσκολα από ό,τι σε ορισμένες βάσεις δεδομένων κλειδιών-τιμών, επειδή για κάθε ανάγνωση είναι απαραίτητο να διαβάζετε το μπλοκ δεδομένων ανά ευρετήριο. Το ευρετήριό μας δεν απευθύνεται σε κάθε εγγραφή, αλλά σε κάθε εύρος. Δηλαδή, πρέπει να διαβάσετε ολόκληρο το εύρος - αυτές είναι 8192 γραμμές από προεπιλογή. Και πρέπει να αποσυμπιέσετε το μπλοκ συμπιεσμένων δεδομένων από 64 KB σε 1 MB. Τυπικά, τέτοια ερωτήματα σημείων χρειάζονται από μερικά χιλιοστά του δευτερολέπτου. Αλλά αυτή είναι η πιο εύκολη επιλογή.
Ας δοκιμάσουμε μια απλή αριθμητική. Εάν πολλαπλασιάσετε μερικά χιλιοστά του δευτερολέπτου επί χίλια, λαμβάνετε μερικά δευτερόλεπτα. Σαν να είναι αδύνατο να κρατήσουμε χίλια αιτήματα ανά δευτερόλεπτο, αλλά στην πραγματικότητα είναι εφικτό, γιατί έχουμε αρκετούς πυρήνες επεξεργαστή. Έτσι, κατ 'αρχήν, το ClickHouse 1000 RPS μπορεί μερικές φορές να κρατήσει, αλλά σε σύντομα αιτήματα, συγκεκριμένα σε σημεία.
Εάν πρέπει να κλιμακώσετε το σύμπλεγμα ClickHouse με βάση τον αριθμό των απλών αιτημάτων, τότε προτείνω το πιο απλό πράγμα - να αυξήσετε τον αριθμό των αντιγράφων και να στείλετε αιτήματα σε ένα τυχαίο αντίγραφο. Εάν ένα αντίγραφο περιέχει πεντακόσιες αιτήσεις ανά δευτερόλεπτο, κάτι που είναι απολύτως ρεαλιστικό, τότε τρία αντίγραφα θα χωρούν μιάμιση χιλιάδες.
Μερικές φορές, φυσικά, μπορείτε επίσης να διαμορφώσετε το ClickHouse για τον μέγιστο αριθμό αναγνώσεων σημείων. Τι χρειάζεται για αυτό; Το πρώτο είναι να μειωθεί η ευαισθησία του δείκτη. Ταυτόχρονα, δεν πρέπει να μειωθεί σε ένα, αλλά με βάση ότι ο αριθμός των εγγραφών στο ευρετήριο θα είναι αρκετά εκατομμύρια ή δεκάδες εκατομμύρια ανά διακομιστή. Εάν ο πίνακας έχει εκατό εκατομμύρια σειρές, τότε το 64 μπορεί να οριστεί ως ευαισθησία.
Μπορείτε να μειώσετε το μέγεθος του συμπιεσμένου μπλοκ. Υπάρχουν ρυθμίσεις για αυτό. ελάχιστο μέγεθος μπλοκ συμπίεσης, μέγιστο μέγεθος μπλοκ συμπίεσης. Μπορείτε να τα μειώσετε, να φορτώσετε ξανά δεδομένα και, στη συνέχεια, τα σημεία ερωτημάτων θα είναι πιο γρήγορα. Ωστόσο, το ClickHouse δεν είναι μια βάση δεδομένων κλειδιού-τιμής. Ένας μεγάλος αριθμός μικρών αιτημάτων είναι ένα αντί-μοτίβο φορτίου.
Kirill Shvakov: Θα δώσω συμβουλές σε περίπτωση που υπάρχουν απλοί λογιστές. Αυτή είναι μια αρκετά τυπική κατάσταση όταν κάποιο είδος μετρητή είναι αποθηκευμένο στο ClickHouse. Έχω έναν χρήστη, είναι από τη τάδε χώρα, κάποιο άλλο τρίτο πεδίο, και πρέπει να αυξήσω κάτι σταδιακά. Πάρτε τη MySQL, δημιουργήστε ένα μοναδικό κλειδί - στη MySQL είναι διπλό κλειδί και στη PostgreSQL είναι μια διένεξη - και προσθέστε ένα σύμβολο συν. Αυτό θα λειτουργήσει πολύ καλύτερα.
Όταν έχετε λίγα δεδομένα, δεν έχει πολύ νόημα να χρησιμοποιείτε το ClickHouse. Υπάρχουν τακτικές βάσεις δεδομένων και κάνουν καλή δουλειά.
Τι να τροποποιήσετε στο ClickHouse, ώστε να υπάρχουν περισσότερα δεδομένα στην κρυφή μνήμη;
Ας φανταστούμε την κατάσταση - οι διακομιστές έχουν 256 GB μνήμης RAM, στην καθημερινή ρουτίνα το ClickHouse διαρκεί περίπου 60-80 GB, στην αιχμή - έως και 130. Τι μπορεί να ενεργοποιηθεί και να τροποποιηθεί έτσι ώστε περισσότερα δεδομένα να βρίσκονται στη μνήμη cache και, κατά συνέπεια , υπάρχουν λιγότερες διαδρομές στο δίσκο;
Κατά κανόνα, η προσωρινή μνήμη σελίδων του λειτουργικού συστήματος κάνει καλά αυτήν την εργασία. Αν απλώς ανοίξετε το επάνω μέρος, κοιτάξετε εκεί αποθηκευμένο ή ελεύθερο - λέει επίσης πόσα είναι προσωρινά αποθηκευμένα - τότε μπορείτε να δείτε ότι όλη η ελεύθερη μνήμη χρησιμοποιείται για την κρυφή μνήμη. Και κατά την ανάγνωση αυτών των δεδομένων, δεν θα διαβαστούν από το δίσκο, αλλά από τη μνήμη RAM. Ταυτόχρονα, μπορώ να πω ότι η κρυφή μνήμη χρησιμοποιείται αποτελεσματικά, γιατί είναι τα συμπιεσμένα δεδομένα που αποθηκεύονται στην κρυφή μνήμη.
Ωστόσο, εάν θέλετε να επιταχύνετε ακόμη περισσότερο ορισμένα απλά ερωτήματα, είναι δυνατό να ενεργοποιήσετε μια προσωρινή μνήμη στα αποσυμπιεσμένα δεδομένα μέσα στο ClickHouse. Ονομάζεται μη συμπιεσμένη κρυφή μνήμη. Στο αρχείο διαμόρφωσης config.xml, ορίστε το μέγεθος της μη συμπιεσμένης προσωρινής μνήμης στην τιμή που χρειάζεστε - σας συμβουλεύω να μην υπερβαίνει τη μισή δωρεάν μνήμη RAM, επειδή η υπόλοιπη θα πάει κάτω από την προσωρινή μνήμη σελίδας.
Επιπλέον, υπάρχουν δύο ρυθμίσεις επιπέδου αιτήματος. Πρώτη ρύθμιση - χρησιμοποιήστε μη συμπιεσμένη κρυφή μνήμη - περιλαμβάνει τη χρήση του. Συνιστάται να το ενεργοποιήσετε για όλα τα αιτήματα, εκτός από τα βαριά, τα οποία μπορούν να διαβάσουν όλα τα δεδομένα και να ξεπλύνουν αυτήν την προσωρινή μνήμη. Και η δεύτερη ρύθμιση είναι κάτι σαν τον μέγιστο αριθμό γραμμών για χρήση της κρυφής μνήμης. Περιορίζει αυτόματα τα μεγάλα αιτήματα, ώστε να περάσουν από την προσωρινή μνήμη.
Πώς μπορώ να διαμορφώσω το storage_configuration για αποθήκευση στη μνήμη RAM;
Στη νέα τεκμηρίωση του ClickHouse, διάβασα τη σχετική ενότητα . Στην περιγραφή υπάρχει ένα παράδειγμα με γρήγορο SSD.
Αναρωτιέμαι πώς μπορείς να ρυθμίσεις το ίδιο με την εντατική μνήμη. Και μια ακόμα ερώτηση. Πώς λειτουργεί το Select με αυτήν την οργάνωση δεδομένων, θα διαβάσει ολόκληρο το σύνολο ή μόνο αυτό στο δίσκο και είναι αυτά τα δεδομένα συμπιεσμένα στη μνήμη; Και πώς λειτουργεί η ενότητα prewhere σε μια τέτοια οργάνωση δεδομένων;
Αυτή η ρύθμιση επηρεάζει την αποθήκευση τμημάτων δεδομένων και η μορφή τους δεν αλλάζει με κανέναν τρόπο.
Ας ρίξουμε μια πιο προσεκτική ματιά.
Μπορείτε να ρυθμίσετε την αποθήκευση δεδομένων στη μνήμη RAM. Όλα όσα έχουν ρυθμιστεί για έναν δίσκο είναι η διαδρομή του. Δημιουργείτε ένα διαμέρισμα tmpfs που είναι προσαρτημένο σε κάποια διαδρομή στο σύστημα αρχείων. Καθορίστε αυτήν τη διαδρομή ως τη διαδρομή αποθήκευσης δεδομένων για το πιο δημοφιλές διαμέρισμα, κομμάτια δεδομένων αρχίζουν να φτάνουν και να γράφονται εκεί, όλα είναι καλά.
Αλλά δεν συνιστώ να το κάνετε αυτό λόγω χαμηλής αξιοπιστίας, αν και αν έχετε τουλάχιστον τρία αντίγραφα σε διαφορετικά κέντρα δεδομένων, τότε μπορείτε. Εάν ναι, τα δεδομένα θα αποκατασταθούν. Φανταστείτε ότι ο διακομιστής απενεργοποιήθηκε ξαφνικά και ενεργοποιήθηκε ξανά. Το τμήμα τοποθετήθηκε ξανά, αλλά υπάρχει ένα κενό. Κατά την εκκίνηση, ο διακομιστής ClickHouse βλέπει ότι αυτά τα κομμάτια λείπουν, αν και, σύμφωνα με τα μεταδεδομένα του ZooKeeper, θα έπρεπε να λείπουν. Κοιτάζει σε ποια αντίγραφα βρίσκονται, τα ζητά και τα κατεβάζει. Έτσι, τα δεδομένα θα αποκατασταθούν.
Υπό αυτή την έννοια, η αποθήκευση δεδομένων στη μνήμη RAM δεν διαφέρει θεμελιωδώς από την αποθήκευσή τους στο δίσκο, επειδή όταν τα δεδομένα εγγράφονται στο δίσκο, πρώτα πέφτουν στην κρυφή μνήμη της σελίδας και γράφονται αργότερα. Εξαρτάται από το πώς έχει τοποθετηθεί το σύστημα αρχείων. Αλλά για κάθε περίπτωση, θα πω ότι το ClickHouse δεν συγχρονίζεται κατά την εισαγωγή.
Σε αυτήν την περίπτωση, τα δεδομένα στη μνήμη RAM αποθηκεύονται στην ίδια ακριβώς μορφή όπως στο δίσκο. Το ερώτημα επιλογής επιλέγει τα κομμάτια που θα διαβαστούν με τον ίδιο τρόπο, επιλέγει τα απαιτούμενα εύρη δεδομένων στα κομμάτια και τα διαβάζει. Και το prewhere λειτουργεί ακριβώς το ίδιο, ανεξάρτητα από το αν τα δεδομένα ήταν στη μνήμη RAM ή στο δίσκο.
Μέχρι ποιον αριθμό μοναδικών τιμών είναι αποτελεσματικό το Low Cardinality;
Η χαμηλή καρδινάτητα είναι δύσκολη. Συγκεντρώνει λεξικά δεδομένων, αλλά είναι τοπικά. Πρώτον, τα λεξικά είναι διαφορετικά για κάθε κομμάτι και δεύτερον, ακόμη και μέσα σε ένα κομμάτι μπορεί να είναι διαφορετικά για κάθε σειρά. Όταν ο αριθμός των μοναδικών τιμών φτάσει σε ένα όριο - ένα εκατομμύριο, νομίζω - το λεξικό απλώς παραμερίζεται και δημιουργείται ένα νέο.
Η απάντηση είναι γενικά: για κάθε τοπικό εύρος - ας πούμε, για κάθε μέρα - κάπου έως και ένα εκατομμύριο μοναδικές τιμές, το Low Cardinality είναι αποτελεσματικό. Μετά από αυτό, θα υπάρχει απλώς μια εναλλακτική, στην οποία θα χρησιμοποιηθούν πολλά διαφορετικά λεξικά, και όχι μόνο ένα. Θα λειτουργεί σχεδόν με τον ίδιο τρόπο όπως μια κανονική στήλη τύπου string, ίσως λίγο λιγότερο αποτελεσματικά, αλλά δεν θα υπάρξει σοβαρή υποβάθμιση της απόδοσης.
Ποιες είναι οι βέλτιστες πρακτικές για την αναζήτηση πλήρους κειμένου σε έναν πίνακα με πέντε δισεκατομμύρια σειρές;
Υπάρχουν διαφορετικές απαντήσεις. Το πρώτο είναι να πούμε ότι το ClickHouse δεν είναι μηχανή αναζήτησης πλήρους κειμένου. Υπάρχουν ειδικά συστήματα για αυτό, για παράδειγμα, и . Ωστόσο, βλέπω όλο και περισσότερους ανθρώπους που λένε ότι μετακινούνται από το Elasticsearch στο ClickHouse.
Γιατί συμβαίνει αυτό? Το εξηγούν από το γεγονός ότι το Elasticsearch παύει να αντεπεξέρχεται στο φορτίο ορισμένων τόμων, ξεκινώντας από τους δείκτες κτιρίων. Τα ευρετήρια γίνονται πολύ δυσκίνητα και, αν απλώς μεταφέρετε τα δεδομένα στο ClickHouse, αποδεικνύεται ότι αποθηκεύονται αρκετές φορές πιο αποτελεσματικά όσον αφορά τον όγκο. Ταυτόχρονα, τα ερωτήματα αναζήτησης συχνά δεν ήταν τέτοια που να ήταν απαραίτητο να βρεθεί κάποια φράση σε ολόκληρο τον όγκο των δεδομένων, λαμβάνοντας υπόψη τη μορφολογία, αλλά εντελώς διαφορετικές. Για παράδειγμα, για να βρείτε τις τελευταίες ώρες στα αρχεία καταγραφής για κάποια δευτερεύουσα ακολουθία byte.
Σε αυτήν την περίπτωση, δημιουργείτε ένα ευρετήριο στο ClickHouse, το πρώτο πεδίο στο οποίο θα είναι η ημερομηνία με την ώρα. Και η μεγαλύτερη αποκοπή δεδομένων θα είναι ακριβώς για το εύρος ημερομηνιών. Εντός του επιλεγμένου εύρους ημερομηνιών, κατά κανόνα, είναι ήδη δυνατή η εκτέλεση αναζήτησης πλήρους κειμένου ακόμη και χρησιμοποιώντας τη μέθοδο brute-force χρησιμοποιώντας παρόμοια. Η δήλωση "μου αρέσει" στο ClickHouse είναι η πιο αποτελεσματική δήλωση "μου αρέσει" που μπορείτε να βρείτε. Αν βρεις καλύτερο, πες μου.
Αλλά και πάλι, όπως είναι μια πλήρης σάρωση. Και η πλήρης σάρωση μπορεί να είναι αργή όχι μόνο στη CPU, αλλά και στο δίσκο. Εάν ξαφνικά έχετε ένα terabyte δεδομένων την ημέρα και ψάχνετε για μια λέξη σε μια μέρα, θα πρέπει να σαρώσετε ένα terabyte. Και είναι πιθανώς σε συνηθισμένους σκληρούς δίσκους, και ως αποτέλεσμα θα φορτωθούν με τέτοιο τρόπο ώστε να μην εισέλθετε σε αυτόν τον διακομιστή μέσω SSH.
Σε αυτή την περίπτωση, είμαι έτοιμος να προσφέρω ένα ακόμη μικρό κόλπο. Είναι από την κατηγορία των πειραματικών - μπορεί να λειτουργεί, μπορεί και όχι. Το ClickHouse έχει ευρετήρια πλήρους κειμένου με τη μορφή φίλτρων άνθισης τριγράμμων. Οι συνάδελφοί μας στο Arenadata έχουν ήδη δοκιμάσει αυτά τα ευρετήρια και συχνά λειτουργούν ακριβώς όπως προβλέπεται.
Για να τα χρησιμοποιήσετε σωστά, θα πρέπει να έχετε καλή κατανόηση του πώς ακριβώς λειτουργούν: τι είναι το φίλτρο άνθισης τρίγραμμα και πώς να επιλέξετε το μέγεθός του. Μπορώ να πω ότι θα βοηθήσουν για ερωτήματα σε κάποιες σπάνιες φράσεις, υποσυμβολοσειρές που σπάνια βρίσκονται στα δεδομένα. Σε αυτήν την περίπτωση, οι υποπεριοχές θα επιλέγονται από ευρετήρια και θα διαβάζονται λιγότερα δεδομένα.
Το ClickHouse πρόσθεσε πρόσφατα ακόμη πιο προηγμένες λειτουργίες για αναζήτηση πλήρους κειμένου. Αυτό είναι, πρώτον, η αναζήτηση μιας δέσμης υποσυμβολοσειρών ταυτόχρονα σε ένα πέρασμα, συμπεριλαμβανομένων επιλογών διάκρισης πεζών-κεφαλαίων, πεζών-κεφαλαίων, υποστηριζόμενων από UTF-8 ή μόνο ASCII. Επιλέξτε το πιο αποτελεσματικό που χρειάζεστε.
Έγινε επίσης αναζήτηση για πολλές κανονικές εκφράσεις σε ένα πέρασμα. Δεν χρειάζεται να γράψετε το Χ σαν μια υποσυμβολοσειρά ή το Χ σαν μια άλλη υποσυμβολοσειρά. Γράψτε αμέσως και όλα γίνονται όσο το δυνατόν πιο αποτελεσματικά.
Τρίτον, υπάρχει τώρα μια κατά προσέγγιση αναζήτηση για regexps και μια κατά προσέγγιση αναζήτηση για υποσυμβολοσειρές. Εάν κάποιος έγραψε μια λέξη με τυπογραφικό λάθος, θα γίνει αναζήτηση για τη μέγιστη αντιστοίχιση.
Ποιος είναι ο καλύτερος τρόπος για να οργανώσετε την πρόσβαση στο ClickHouse για μεγάλο αριθμό χρηστών;
Πείτε μας πώς να οργανώσουμε καλύτερα την πρόσβαση για μεγάλο αριθμό καταναλωτών και αναλυτών. Πώς να σχηματίσετε μια ουρά, να δώσετε προτεραιότητα σε μέγιστα ταυτόχρονα ερωτήματα και με ποια εργαλεία;
Εάν το σύμπλεγμα είναι αρκετά μεγάλο, τότε μια καλή λύση θα ήταν η αύξηση δύο ακόμη διακομιστών, που θα γίνουν το σημείο εισόδου για τους αναλυτές. Δηλαδή, μην αφήνετε τους αναλυτές σε συγκεκριμένα θραύσματα συμπλέγματος, αλλά απλώς δημιουργήστε δύο άδειους διακομιστές, χωρίς δεδομένα, και έχετε ήδη ορίσει δικαιώματα πρόσβασης σε αυτούς. Ταυτόχρονα, οι ρυθμίσεις χρήστη μεταφέρονται σε απομακρυσμένους διακομιστές κατά τη διάρκεια των κατανεμημένων αιτημάτων. Δηλαδή, ρυθμίζετε τα πάντα σε αυτούς τους δύο διακομιστές και οι ρυθμίσεις έχουν επίδραση σε ολόκληρο το σύμπλεγμα.
Κατ 'αρχήν, αυτοί οι διακομιστές είναι χωρίς δεδομένα, αλλά η ποσότητα της μνήμης RAM σε αυτούς είναι πολύ σημαντική για την εκτέλεση αιτημάτων. Ο δίσκος μπορεί επίσης να χρησιμοποιηθεί για προσωρινά δεδομένα εάν είναι ενεργοποιημένη η εξωτερική συγκέντρωση ή η εξωτερική ταξινόμηση.
Είναι σημαντικό να εξετάσετε τις ρυθμίσεις που σχετίζονται με όλα τα πιθανά όρια. Αν πάω τώρα στο σύμπλεγμα Yandex.Metrics ως αναλυτής και ορίσω ένα ερώτημα επιλέξτε μέτρηση από επιτυχίες, τότε θα μου δοθεί αμέσως μια εξαίρεση ότι δεν μπορώ να εκπληρώσω το αίτημα. Ο μέγιστος αριθμός σειρών που επιτρέπεται να σαρώνω είναι εκατό δισεκατομμύρια και υπάρχουν πενήντα τρισεκατομμύρια συνολικά στο σύμπλεγμα σε έναν πίνακα. Αυτός είναι ο πρώτος περιορισμός.
Ας υποθέσουμε ότι αφαιρώ το όριο στον αριθμό των σειρών και εκτελώ ξανά το ερώτημα. Στη συνέχεια θα δω την ακόλουθη εξαίρεση - η ρύθμιση είναι ενεργοποιημένη δείκτης δύναμης κατά ημερομηνία. Δεν μπορώ να εκτελέσω το ερώτημα εάν δεν έχω καθορίσει εύρος ημερομηνιών. Δεν χρειάζεται να βασίζεστε σε αναλυτές για να το εισάγετε χειροκίνητα. Μια τυπική περίπτωση - γράφεται ένα εύρος ημερομηνιών όπου η ημερομηνία του συμβάντος είναι μεταξύ μιας εβδομάδας. Στη συνέχεια, απλώς δεν όρισαν μια αγκύρωση εκεί, και αντί για και αποδείχθηκε ότι ταιριάζει ή - ή διεύθυνση URL. Εάν δεν υπάρχει όριο, θα ανιχνεύσει τη στήλη του URL και θα σπαταλήσει έναν τόνο πόρων.
Επιπλέον, το ClickHouse έχει δύο ρυθμίσεις προτεραιότητας. Δυστυχώς, είναι πολύ πρωτόγονοι. Το ένα λέγεται απλά προτεραιότητα. Εάν εκτελείται προτεραιότητα ≠ και αιτήματα με κάποια προτεραιότητα, αλλά εκτελείται ένα αίτημα με τιμή προτεραιότητας που είναι χαμηλότερη, που σημαίνει υψηλότερη προτεραιότητα, τότε ένα αίτημα με τιμή προτεραιότητας μεγαλύτερη από, που σημαίνει χαμηλότερη προτεραιότητα, είναι απλά ανεστάλη και δεν θα λειτουργήσει καθόλου κατά τη διάρκεια αυτής της περιόδου.
Αυτή είναι μια πολύ σκληρή ρύθμιση και δεν είναι κατάλληλη για καταστάσεις όπου υπάρχει σταθερό φορτίο στο σύμπλεγμα. Αλλά αν έχετε σύντομα, παρορμητικά αιτήματα που είναι σημαντικά και το σύμπλεγμα είναι ως επί το πλείστον αδρανές, αυτή η ρύθμιση θα ισχύει.
Καλείται η επόμενη ρύθμιση προτεραιότητας Προτεραιότητα νήματος λειτουργικού συστήματος. Απλώς εκθέτει όλα τα νήματα εκτέλεσης αιτημάτων στην καλή τιμή για τον προγραμματιστή Linux. Λειτουργεί έτσι-έτσι, αλλά εξακολουθεί να λειτουργεί. Εάν ορίσετε την ελάχιστη τιμή της ωραίας - είναι η μεγαλύτερη σε αξία, και επομένως η χαμηλότερη προτεραιότητα - και ορίσετε -19 για αιτήματα υψηλής προτεραιότητας, τότε η CPU θα καταναλώσει αιτήματα χαμηλής προτεραιότητας περίπου τέσσερις φορές λιγότερα από εκείνα υψηλής προτεραιότητας.
Πρέπει επίσης να ορίσετε τον μέγιστο χρόνο εκτέλεσης ερωτήματος - ας πούμε, πέντε λεπτά. Η ελάχιστη ταχύτητα εκτέλεσης αιτήματος είναι το πιο ωραίο πράγμα. Αυτή η ρύθμιση υπάρχει εδώ και πολύ καιρό και απαιτείται όχι μόνο να επιβεβαιωθεί ότι το ClickHouse δεν επιβραδύνει, αλλά και να το εξαναγκάσει.
Φανταστείτε ότι ρυθμίζετε: εάν ένα ερώτημα επεξεργάζεται λιγότερες από ένα εκατομμύριο σειρές ανά δευτερόλεπτο, δεν μπορείτε να το κάνετε αυτό. Αυτό ατιμάζει το καλό μας όνομα, την καλή μας βάση δεδομένων. Ας το απαγορεύσουμε. Στην πραγματικότητα υπάρχουν δύο ρυθμίσεις. Το ένα λέγεται ελάχιστη ταχύτητα εκτέλεσης - σε γραμμές ανά δευτερόλεπτο και το δεύτερο ονομάζεται timeout πριν από τον έλεγχο ελάχιστης ταχύτητας εκτέλεσης - δεκαπέντε δευτερόλεπτα από προεπιλογή. Δηλαδή, δεκαπέντε δευτερόλεπτα είναι δυνατά, και στη συνέχεια, αν αργά, τότε απλώς ρίξτε μια εξαίρεση - ματαιώστε το αίτημα.
Πρέπει επίσης να ορίσετε ποσοστώσεις. Το ClickHouse έχει μια ενσωματωμένη λειτουργία ορίου που μετράει την κατανάλωση πόρων. Αλλά, δυστυχώς, δεν είναι σιδερένιοι πόροι όπως CPU, δίσκοι, αλλά λογικοί - ο αριθμός των επεξεργασμένων αιτημάτων, των γραμμών και των byte που διαβάζονται. Και μπορείτε να ρυθμίσετε, για παράδειγμα, το πολύ εκατό αιτήματα μέσα σε πέντε λεπτά και χίλια αιτήματα ανά ώρα.
Γιατί είναι σημαντικό? Επειδή ορισμένα από τα αιτήματα αναλυτικών στοιχείων θα εκτελούνται μη αυτόματα απευθείας από τον πελάτη ClickHouse. Και όλα θα πάνε καλά. Αλλά αν έχετε προχωρημένους αναλυτές στην εταιρεία σας, θα γράψουν ένα σενάριο και μπορεί να υπάρχει σφάλμα στο σενάριο. Και αυτό το σφάλμα θα κάνει το αίτημα να εκτελεστεί σε έναν άπειρο βρόχο. Αυτό είναι που πρέπει να προστατευθεί.
Είναι δυνατόν να δοθούν τα αποτελέσματα ενός αιτήματος σε δέκα πελάτες;
Έχουμε αρκετούς χρήστες που τους αρέσει να έρχονται με πολύ μεγάλα αιτήματα ταυτόχρονα. Το αίτημα είναι μεγάλο, καταρχήν εκτελείται γρήγορα, αλλά λόγω του ότι υπάρχουν πολλά τέτοια αιτήματα ταυτόχρονα, γίνεται πολύ οδυνηρό. Είναι δυνατόν να εκτελεστεί το ίδιο αίτημα, που έφτασε δέκα φορές στη σειρά, μία φορά και να δώσει το αποτέλεσμα σε δέκα πελάτες;
Το πρόβλημα είναι ότι δεν έχουμε αποτελέσματα κρυφής μνήμης ή ενδιάμεση κρυφή μνήμη δεδομένων. Υπάρχει μια προσωρινή μνήμη σελίδας του λειτουργικού συστήματος, η οποία θα σας επιτρέψει να μην διαβάσετε ξανά δεδομένα από το δίσκο, αλλά, δυστυχώς, τα δεδομένα θα εξακολουθούν να αποσυμπιέζονται, να αποδεσμεύονται και να υποβάλλονται σε επανεπεξεργασία.
Θα ήθελα με κάποιο τρόπο να το αποφύγω αυτό, είτε αποθηκεύοντας προσωρινά ενδιάμεσα δεδομένα είτε τοποθετώντας παρόμοια ερωτήματα σε κάποιο είδος ουράς και προσθέτοντας μια κρυφή μνήμη αποτελεσμάτων. Τώρα έχουμε ένα αίτημα έλξης σε ανάπτυξη, το οποίο προσθέτει μια προσωρινή μνήμη αιτημάτων, αλλά μόνο για δευτερεύοντα αιτήματα στις ενότητες in and join - δηλαδή, η λύση είναι κατώτερη.
Ωστόσο, έχουμε και μια τέτοια κατάσταση. Ένα ιδιαίτερα κανονικό παράδειγμα είναι τα αιτήματα με σελιδοποίηση. Υπάρχει μια αναφορά, έχει πολλές σελίδες, και υπάρχει αίτημα για όριο 10. Μετά το ίδιο, αλλά όριο 10,10. Μετά άλλη σελίδα. Και το ερώτημα είναι, γιατί τα μετράμε όλα κάθε φορά; Τώρα όμως δεν υπάρχει λύση και δεν υπάρχει τρόπος να την αποφύγεις.
Υπάρχει μια εναλλακτική λύση που τοποθετείται ως sidecar δίπλα στο ClickHouse - .
Kirill Shvakov: Το ClickHouse Proxy διαθέτει ενσωματωμένο περιοριστή ρυθμού και ενσωματωμένη προσωρινή μνήμη αποτελεσμάτων. Έχουν γίνει πολλές ρυθμίσεις εκεί, γιατί λύθηκε μια παρόμοια εργασία. Ο διακομιστής μεσολάβησης σάς επιτρέπει να περιορίζετε τα αιτήματα τοποθετώντας τα στην ουρά και να διαμορφώνετε τη διάρκεια ζωής της προσωρινής μνήμης αιτημάτων. Εάν τα αιτήματα ήταν πραγματικά τα ίδια, ο διακομιστής μεσολάβησης θα τα δώσει πολλές φορές και θα πάει στο ClickHouse μόνο μία φορά.
Το Nginx έχει επίσης μια προσωρινή μνήμη στη δωρεάν έκδοση και αυτό θα λειτουργήσει επίσης. Το Nginx έχει ακόμη και ρυθμίσεις έτσι ώστε αν έρθουν αιτήματα ταυτόχρονα, θα σταματήσει άλλα μέχρι να ολοκληρωθεί. Αλλά είναι στο ClickHouse Proxy που οι ρυθμίσεις γίνονται πολύ καλύτερες. Κατασκευάστηκε ειδικά για το ClickHouse, ειδικά για αυτά τα αιτήματα, επομένως είναι πιο κατάλληλο. Λοιπόν, είναι εύκολο να το ρυθμίσετε.
Τι γίνεται με τις ασύγχρονες λειτουργίες και τις υλοποιημένες προβολές;
Υπάρχει τέτοιο πρόβλημα που οι λειτουργίες με τον κινητήρα αντικατάστασης είναι ασύγχρονες - πρώτα γράφονται τα δεδομένα και μετά καταρρέουν. Εάν ένα υλοποιημένο δισκίο με ορισμένα συσσωματώματα βρίσκεται κάτω από το tablet, τότε θα γραφτούν διπλότυπα σε αυτό. Και αν δεν υπάρχει πολύπλοκη λογική, τότε τα δεδομένα θα αντιγραφούν. Τι μπορεί να γίνει για αυτό;
Υπάρχει μια προφανής λύση - να εφαρμόσετε μια σκανδάλη σε μια συγκεκριμένη κλάση matview κατά τη διάρκεια μιας λειτουργίας ασύγχρονης κατάρρευσης. Υπάρχουν σχέδια "silver bullets" για την εφαρμογή μιας τέτοιας λειτουργικότητας;
Αξίζει να καταλάβουμε πώς λειτουργεί το deduplication. Αυτό που πρόκειται να πω δεν σχετίζεται με την ερώτηση, αλλά αξίζει να το θυμάστε για παν ενδεχόμενο.
Κατά την εισαγωγή σε έναν αναπαραγόμενο πίνακα, υπάρχει κατάργηση διπλότυπων όλων των εισαγόμενων μπλοκ. Εάν εισαγάγετε ξανά το ίδιο μπλοκ που περιέχει τον ίδιο αριθμό των ίδιων σειρών με την ίδια σειρά, τότε τα δεδομένα καταργούνται. Θα λάβετε "Ok" ως απόκριση στο ένθετο, αλλά μια παρτίδα δεδομένων θα γραφτεί στην πραγματικότητα και δεν θα αντιγραφεί.
Αυτό είναι απαραίτητο για βεβαιότητα. Εάν λάβετε "Ok" κατά την εισαγωγή, τότε τα δεδομένα σας έχουν εισαχθεί. Εάν λάβετε ένα σφάλμα από το ClickHouse, τότε δεν έχουν εισαχθεί και πρέπει να επαναλάβετε την εισαγωγή. Αλλά εάν η σύνδεση διακοπεί κατά την εισαγωγή, τότε δεν γνωρίζετε εάν τα δεδομένα έχουν εισαχθεί ή όχι. Η μόνη επιλογή είναι να επαναλάβετε ξανά το ένθετο. Εάν τα δεδομένα εισήχθησαν πράγματι και τα εισαγάγατε ξανά, υπάρχει αφαίρεση μπλοκ. Απαιτείται για την αποφυγή διπλότυπων.
Και είναι επίσης σημαντικό πώς λειτουργεί για υλοποιημένες απόψεις. Εάν τα δεδομένα καταργήθηκαν κατά την εισαγωγή στον κύριο πίνακα, τότε δεν θα μεταβούν ούτε στην υλοποιημένη προβολή.
Τώρα για την ερώτηση. Η κατάστασή σας είναι πιο περίπλοκη επειδή γράφετε αντίγραφα μεμονωμένων γραμμών. Δηλαδή, δεν είναι ολόκληρο το πακέτο διπλό, αλλά συγκεκριμένες γραμμές και καταρρέουν στο παρασκήνιο. Πράγματι, τα δεδομένα θα καταρρεύσουν στον κύριο πίνακα και τα μη συμπτυγμένα θα μεταβούν στην υλοποιημένη προβολή και δεν θα συμβεί τίποτα με τις υλοποιημένες προβολές κατά τη συγχώνευση. Επειδή μια υλοποιημένη προβολή δεν είναι τίποτα άλλο από ένα έναυσμα κατά την εισαγωγή. Τίποτα άλλο δεν συμβαίνει σε αυτό κατά τη διάρκεια άλλων επεμβάσεων.
Και δεν μπορώ να είμαι χαρούμενος εδώ. Αρκεί μόνο να αναζητηθεί μια συγκεκριμένη λύση για αυτή την περίπτωση. Για παράδειγμα, είναι δυνατή η αντικατάστασή του σε μια υλοποιημένη προβολή και η μέθοδος κατάργησης διπλότυπων, ίσως, θα λειτουργήσει με τον ίδιο τρόπο. Αλλά δυστυχώς, όχι πάντα. Εάν είναι αθροιστικό, τότε δεν θα λειτουργήσει.
Kirill Shvakov: Κάποτε είχαμε και οστική οικοδόμηση. Παρουσιάστηκε πρόβλημα ότι υπάρχουν εμφανίσεις διαφημίσεων και υπάρχουν ορισμένα δεδομένα που μπορούμε να εμφανίσουμε σε πραγματικό χρόνο - αυτά είναι απλώς εμφανίσεις. Σπάνια επαναλαμβάνονται, αλλά αν το κάνουν, θα τα καταρρεύσουμε ούτως ή άλλως. Και υπήρχαν πράγματα που δεν μπορούν να αναπαραχθούν - κλικ και όλη αυτή η ιστορία. Ήθελα όμως και να τα δείξω σχεδόν αμέσως.
Πώς έγιναν οι υλοποιημένες απόψεις; Υπήρχαν προβολές όπου γράφεται απευθείας - υπάρχει μια εγγραφή σε μη επεξεργασμένα δεδομένα, και είναι γραμμένη σε προβολές. Εκεί κάποια στιγμή τα δεδομένα δεν είναι πολύ σωστά, διπλασιάζονται κ.ο.κ. Και υπάρχει το δεύτερο μέρος του πίνακα, όπου φαίνονται ακριβώς ίδιες με τις υλοποιημένες απόψεις, δηλαδή είναι ακριβώς ίδιες στη δομή. Κάθε τόσο, υπολογίζουμε εκ νέου τα δεδομένα, μετράμε τα δεδομένα χωρίς διπλότυπα, γράφουμε σε αυτούς τους πίνακες.
Περάσαμε από το API - αυτό δεν θα λειτουργήσει στο ClickHouse με το χέρι. Και το API φαίνεται: όταν έχω την ημερομηνία της τελευταίας προσθήκης στον πίνακα, όπου είναι εγγυημένο ότι έχουν ήδη υπολογιστεί τα σωστά δεδομένα και κάνει ένα αίτημα σε έναν πίνακα και σε έναν άλλο πίνακα. Από το ένα αίτημα επιλέγει μέχρι ένα συγκεκριμένο χρονικό διάστημα και από το άλλο λαμβάνει αυτό που δεν έχει ακόμη υπολογιστεί. Και λειτουργεί, αλλά όχι μέσω ενός ClickHouse.
Εάν έχετε κάποιο είδος API - για αναλυτές, για χρήστες - τότε, κατ 'αρχήν, αυτή είναι μια επιλογή. Πάντα μετράς, πάντα μετράς. Αυτό μπορεί να γίνει μία φορά την ημέρα ή κάποια άλλη στιγμή. Επιλέγετε μόνοι σας το εύρος που δεν χρειάζεστε και δεν είναι κρίσιμο.
Το ClickHouse έχει πολλά αρχεία καταγραφής. Πώς μπορώ να δω όλα όσα συμβαίνουν στον διακομιστή σε μια στιγμή;
Το ClickHouse έχει πολύ μεγάλο αριθμό διαφορετικών αρχείων καταγραφής και αυτός ο αριθμός αυξάνεται. Σε νέες εκδόσεις, ορισμένες από αυτές είναι ακόμη και ενεργοποιημένες από προεπιλογή, σε παλαιότερες εκδόσεις πρέπει να είναι ενεργοποιημένες κατά την ενημέρωση. Ωστόσο, υπάρχουν όλο και περισσότεροι από αυτούς. Θα ήθελα επιτέλους να δω τι συμβαίνει τώρα με τον διακομιστή μου, ίσως σε κάποιο συνοπτικό ταμπλό.
Έχετε στην ομάδα του ClickHouse ή στις ομάδες των φίλων σας που υποστηρίζουν κάποια λειτουργικότητα έτοιμων πινάκων εργαλείων που θα εμφανίζουν αυτά τα αρχεία καταγραφής ως τελικό προϊόν; Τελικά, απλά κοιτάζοντας τα αρχεία καταγραφής στο ClickHouse είναι υπέροχο. Αλλά θα ήταν πολύ ωραίο αν ήταν ήδη προετοιμασμένο με τη μορφή ταμπλό. Θα έπαιρνα ψηλά σε αυτό.
Υπάρχουν πίνακες εργαλείων, αν και δεν είναι τυποποιημένοι. Έχουμε περίπου 60 ομάδες στην εταιρεία μας που χρησιμοποιούν το ClickHouse και το πιο περίεργο είναι ότι πολλές από αυτές έχουν πίνακες ελέγχου που έφτιαξαν οι ίδιοι, και λίγο διαφορετικοί. Ορισμένες ομάδες χρησιμοποιούν την εσωτερική εγκατάσταση του Yandex.Cloud. Υπάρχουν κάποιες έτοιμες αναφορές, αν και όχι όλες οι απαραίτητες. Άλλοι έχουν τα δικά τους.
Οι συνάδελφοί μου από τη Metrica έχουν το δικό τους ταμπλό στη Γραφάνα, και εγώ το δικό μου για το δικό τους σύμπλεγμα. Εξετάζω πράγματα όπως ένα χτύπημα προσωρινής μνήμης για μια προσωρινή μνήμη serif. Και ακόμα πιο δύσκολο είναι ότι χρησιμοποιούμε διαφορετικά εργαλεία. Δημιούργησα τον πίνακα ελέγχου μου σε ένα πολύ παλιό εργαλείο που ονομάζεται Graphite-web. Είναι εντελώς άσχημος. Και εξακολουθώ να το χρησιμοποιώ έτσι, αν και η Γραφάνα θα ήταν μάλλον πιο βολική και πιο όμορφη.
Το βασικό πράγμα στα ταμπλό είναι το ίδιο. Αυτές είναι μετρήσεις συστήματος για το σύμπλεγμα: CPU, μνήμη, δίσκος, δίκτυο. Άλλα είναι ο αριθμός των ταυτόχρονων αιτημάτων, ο αριθμός των ταυτόχρονων συγχωνεύσεων, ο αριθμός των αιτημάτων ανά δευτερόλεπτο, ο μέγιστος αριθμός τμημάτων για κατατμήσεις πίνακα MergeTree, η καθυστέρηση αναπαραγωγής, το μέγεθος της ουράς αναπαραγωγής, ο αριθμός των σειρών που εισάγονται ανά δευτερόλεπτο, τον αριθμό των μπλοκ που εισάγονται ανά δευτερόλεπτο. Αυτό είναι το μόνο που λαμβάνεται όχι από τα αρχεία καταγραφής, αλλά από τις μετρήσεις.
Vladimir Kolobaev: Alexey, θα ήθελα να διορθώσω λίγο. Υπάρχει η Γραφάνα. Το Grafana έχει μια πηγή δεδομένων που είναι το ClickHouse. Δηλαδή, μπορώ να κάνω αιτήματα από το Grafana απευθείας στο ClickHouse. Το ClickHouse έχει έναν πίνακα με αρχεία καταγραφής, είναι το ίδιο για όλους. Ως αποτέλεσμα, θέλω να αποκτήσω πρόσβαση σε αυτόν τον πίνακα καταγραφής στο Grafana και να δω τα αιτήματα που εφαρμόζει ο διακομιστής μου. Θα ήταν υπέροχο να έχουμε ένα τέτοιο ταμπλό.
Το ποδηλατούσα μόνος μου. Αλλά έχω μια ερώτηση - εάν είναι όλα τυποποιημένα και το Grafana χρησιμοποιείται από όλους, γιατί η Yandex δεν έχει έναν τέτοιο επίσημο πίνακα εργαλείων;
Kirill Shvakov: Στην πραγματικότητα, η πηγή δεδομένων που το ClickHouse υποστηρίζει τώρα το Altinity. Και θέλω απλώς να δώσω ένα διάνυσμα για το πού να σκάψω και ποιον να σπρώξω. Μπορείτε να τους ρωτήσετε, επειδή η Yandex εξακολουθεί να δημιουργεί το ClickHouse και όχι την ιστορία γύρω από αυτό. Η Altinity είναι η κύρια εταιρεία που προωθεί αυτήν τη στιγμή το ClickHouse. Δεν θα τον εγκαταλείψουν, αλλά θα τον στηρίξουν. Διότι κατ' αρχήν, για να ανεβάσετε έναν πίνακα ελέγχου στον ιστότοπο της Γραφάνα, χρειάζεται μόνο να εγγραφείτε και να τον ανεβάσετε - δεν υπάρχουν ιδιαίτερα προβλήματα.
Alexey Milovidov: Τον περασμένο χρόνο, το ClickHouse έχει προσθέσει πολλές δυνατότητες δημιουργίας προφίλ ερωτημάτων. Υπάρχουν μετρήσεις για κάθε αίτημα χρήσης πόρων. Και πιο πρόσφατα, προστέθηκε ένα προφίλ εξατομικευμένου ερωτήματος ακόμη χαμηλότερου επιπέδου για να δείτε πού ξοδεύει το ερώτημα κάθε χιλιοστό του δευτερολέπτου. Αλλά για να χρησιμοποιήσω αυτή τη λειτουργία, πρέπει να ανοίξω τον πελάτη της κονσόλας και να πληκτρολογήσω ένα ερώτημα που ξεχνάω συνέχεια. Το φύλαξα κάπου και πάντα ξεχνάω πού ακριβώς.
Μακάρι να υπήρχε ένα εργαλείο που λέει απλώς - εδώ είναι τα βαριά ερωτήματά σας, ομαδοποιημένα ανά κατηγορία ερωτημάτων. Έκανα κλικ σε ένα, και μου έλεγαν ότι είναι βαρύ επομένως. Τώρα δεν υπάρχει τέτοια λύση. Και είναι πραγματικά πολύ περίεργο που όταν οι άνθρωποι με ρωτούν: «Πες μου, υπάρχουν έτοιμοι πίνακες για τη Grafana;» από τον Kostyan. Δεν ξέρω τι είναι, δεν το έχω χρησιμοποιήσει μόνος μου».
Πώς να επηρεάσετε το merdzhi ώστε ο διακομιστής να μην πέσει στο OOM;
Έχω έναν πίνακα, υπάρχει μόνο ένα διαμέρισμα στον πίνακα, είναι το ReplacingMergeTree. Το γράφω δεδομένα εδώ και τέσσερα χρόνια. Έπρεπε να κάνω μια αλλαγή σε αυτό και να διαγράψω κάποια δεδομένα.
Το έκανα αυτό, και κατά τη διάρκεια της επεξεργασίας αυτού του αιτήματος, καταναλώθηκε όλη η μνήμη σε όλους τους διακομιστές του συμπλέγματος και όλοι οι διακομιστές του συμπλέγματος πήγαν μαζί στο OOM. Στη συνέχεια σηκώθηκαν όλοι μαζί, άρχισαν να συγχωνεύουν την ίδια λειτουργία, αυτό το μπλοκ δεδομένων και έπεσαν ξανά στο OOM. Μετά σηκώθηκαν πάλι και έπεσαν πάλι κάτω. Και αυτό το πράγμα δεν σταμάτησε.
Στη συνέχεια αποδείχθηκε ότι αυτό είναι στην πραγματικότητα ένα σφάλμα που τα παιδιά διόρθωσαν. Αυτό είναι πολύ ωραίο, σας ευχαριστώ πολύ. Όμως το υπόλειμμα παρέμεινε. Και τώρα, όταν σκέφτομαι την ανάγκη να κάνω μια συγκεκριμένη συγχώνευση στον πίνακα, έχω μια ερώτηση - γιατί δεν μπορώ να δεχτώ αυτές τις συγχωνεύσεις και με κάποιο τρόπο να τις επηρεάσω; Για παράδειγμα, περιορίστε τα με την απαιτούμενη ποσότητα μνήμης RAM ή, καταρχήν, με τον αριθμό τους, ο οποίος θα επεξεργαστεί τον συγκεκριμένο πίνακα.
Έχω έναν πίνακα που ονομάζεται "Μετρικές", παρακαλώ να τον επεξεργαστώ για μένα σε δύο ροές. Δεν χρειάζεται να κάνετε δέκα ή πέντε συγχωνεύσεις παράλληλα, κάντε το σε δύο. Νομίζω ότι σε δύο έχω αρκετή μνήμη, αλλά μπορεί να μην είναι αρκετή για να επεξεργαστώ δέκα. Γιατί ο φόβος παραμένει; Επειδή ο πίνακας μεγαλώνει και κάποια μέρα θα αντιμετωπίσω μια κατάσταση που, καταρχήν, δεν οφείλεται πλέον σε σφάλμα, αλλά λόγω του γεγονότος ότι τα δεδομένα θα αλλάξουν σε τόσο μεγάλο βαθμό που απλά δεν έχω αρκετή μνήμη ο διακομιστής. Και τότε ο διακομιστής θα πέσει στο OOM κατά τη συγχώνευση. Επιπλέον, μπορώ να ακυρώσω τη μετάλλαξη, αλλά η συγχώνευση έχει φύγει.
Ξέρετε, κατά τη συγχώνευση, ο διακομιστής δεν θα πέσει στο OOM, επειδή κατά τη συγχώνευση, η ποσότητα μνήμης RAM χρησιμοποιείται μόνο για ένα μικρό εύρος δεδομένων. Άρα όλα θα πάνε καλά ανεξάρτητα από τον όγκο των δεδομένων.
Vladimir Kolobaev: Πρόστιμο. Εδώ η στιγμή είναι τέτοια που αφού κάναμε μια διόρθωση σφαλμάτων, κατέβασα μια νέα έκδοση για τον εαυτό μου και σε ένα άλλο τραπέζι, μικρότερο, όπου υπάρχουν πολλά διαμερίσματα, έκανα μια παρόμοια λειτουργία. Και κατά τη συγχώνευση, περίπου 100 GB μνήμης RAM κάηκαν στον διακομιστή. Είχα 150 απασχολημένος, έφαγα 100 και είχα μείνει ένα παράθυρο 50 GB, οπότε δεν έπεσα στο OOM.
Τι με προστατεύει αυτήν τη στιγμή από το να πέσω στο OOM εάν καταναλώνει πραγματικά 100 GB μνήμης RAM; Τι να κάνετε σε μια κατάσταση εάν ξαφνικά τελειώσει η μνήμη RAM στο merdzh;
Alexey Milovidov: Υπάρχει τέτοιο πρόβλημα που η κατανάλωση RAM δεν περιορίζεται στο merdzhi. Και το δεύτερο πρόβλημα είναι ότι εάν έχει εκχωρηθεί μια συγχώνευση, τότε πρέπει να εκτελεστεί, επειδή είναι γραμμένη στο αρχείο καταγραφής αναπαραγωγής. Το αρχείο καταγραφής αναπαραγωγής είναι οι ενέργειες που απαιτούνται για να φέρει το αντίγραφο σε συνεπή κατάσταση. Εάν δεν κάνετε χειροκίνητους χειρισμούς που θα επαναφέρει αυτό το αρχείο καταγραφής αναπαραγωγής, η συγχώνευση θα πρέπει να πραγματοποιηθεί με τον ένα ή τον άλλο τρόπο.
Φυσικά, δεν θα ήταν περιττό να υπάρχει περιορισμός στη μνήμη RAM, η οποία «για κάθε περίπτωση» προστατεύει από το OOM. Δεν θα βοηθήσει την εκτέλεση της συγχώνευσης, θα ξεκινήσει ξανά, θα φτάσει σε κάποιο όριο, θα κάνει μια εξαίρεση και μετά θα ξεκινήσει ξανά - τίποτα καλό δεν θα προκύψει από αυτό. Αλλά καταρχήν, θα ήταν χρήσιμο να εισαχθεί αυτός ο περιορισμός.
Πώς θα γίνει η ανάπτυξη του προγράμματος οδήγησης Golang για το ClickHouse;
Ο οδηγός Golang που έγραψε ο Kirill Shvakov υποστηρίζεται πλέον επίσημα από την ομάδα ClickHouse. Αυτός , είναι πλέον μεγάλος και αληθινός.
Μια μικρή σημείωση. Υπάρχει μια υπέροχη και αγαπημένη αποθήκη κανονικών μορφών άπειρης τάξης - αυτή είναι η Vertica. Έχουν επίσης το δικό τους επίσημο πρόγραμμα οδήγησης python, το οποίο διατηρούν οι προγραμματιστές της Vertica. Και αρκετές φορές συνέβη ότι οι εκδόσεις του αποθηκευτικού χώρου και οι εκδόσεις του προγράμματος οδήγησης χωρίστηκαν αρκετά απότομα και ο οδηγός σταμάτησε να λειτουργεί κάποια στιγμή. Και το δεύτερο σημείο. Η υποστήριξη για αυτό το επίσημο πρόγραμμα οδήγησης, μου φαίνεται, διατηρείται από το σύστημα "θηλής" - τους γράφετε ένα θέμα και μένει για πάντα.
Έχω δύο ερωτήσεις. Τώρα το πρόγραμμα οδήγησης Golang του Kirill είναι ένας σχεδόν προεπιλεγμένος τρόπος επικοινωνίας από το Golang με το ClickHouse. Εκτός αν κάποιος εξακολουθεί να επικοινωνεί μέσω της διεπαφής http, επειδή του αρέσει πολύ. Πώς θα αναπτυχθεί αυτό το πρόγραμμα οδήγησης; Θα συγχρονιστεί με κάποιες αλλαγές στο ίδιο το αποθετήριο; Και ποια είναι η διαδικασία εξέτασης του θέματος;
Kirill Shvakov: Το πρώτο είναι πώς όλα τακτοποιούνται γραφειοκρατικά. Αυτό το σημείο δεν έχει συζητηθεί, οπότε δεν έχω τίποτα να απαντήσω.
Για να απαντήσουμε στην ερώτηση σχετικά με το ζήτημα, χρειαζόμαστε ένα μικρό ιστορικό του προγράμματος οδήγησης. Δούλευα σε μια εταιρεία που είχε πολλά δεδομένα. Ήταν ένα διαφημιστικό spinner με έναν τεράστιο αριθμό συμβάντων που έπρεπε να αποθηκευτούν κάπου. Και κάποια στιγμή εμφανίστηκε το ClickHouse. Χύσαμε δεδομένα σε αυτό και στην αρχή όλα ήταν καλά, αλλά μετά έπεσε το ClickHouse. Τότε αποφασίσαμε ότι δεν το χρειαζόμασταν.
Ένα χρόνο αργότερα, επιστρέψαμε στην ιδέα να χρησιμοποιήσουμε το ClickHouse και έπρεπε με κάποιο τρόπο να γράψουμε δεδομένα εκεί. Η εισροή ήταν αυτή - ο σίδηρος είναι πολύ αδύναμος, υπάρχουν λίγοι πόροι. Αλλά πάντα εργαζόμασταν με αυτόν τον τρόπο, και επομένως κοιτούσαμε προς το εγγενές πρωτόκολλο.
Εφόσον εργαζόμασταν στο Go, ήταν σαφές ότι χρειαζόμασταν έναν οδηγό Go. Το έκανα σχεδόν με πλήρη απασχόληση - ήταν η δουλειά μου. Μέχρι ένα σημείο το ανακαλούσαμε και καταρχήν κανείς δεν περίμενε ότι κάποιος άλλος εκτός από εμάς θα το χρησιμοποιούσε. Μετά ήρθε το CloudFlare με το ίδιο ακριβώς πρόβλημα και για λίγο δουλέψαμε πολύ ομαλά μαζί τους, γιατί είχαν τις ίδιες εργασίες. Και το κάναμε τόσο στο ίδιο το ClickHouse όσο και στο πρόγραμμα οδήγησης.
Κάποια στιγμή, απλά σταμάτησα να το κάνω, γιατί η δραστηριότητά μου όσον αφορά το ClickHouse και με τη δουλειά έχει αλλάξει λίγο. Επομένως τα θέματα δεν έχουν κλείσει. Περιοδικά, άτομα που χρειάζονται κάτι οι ίδιοι δεσμεύονται στο αποθετήριο. Μετά κοιτάζω το αίτημα έλξης και μερικές φορές επεξεργάζομαι κάτι μόνος μου, αλλά αυτό συμβαίνει σπάνια.
Θέλω να επιστρέψω στον οδηγό. Πριν από μερικά χρόνια, όταν ξεκίνησε όλο αυτό το θέμα, το ClickHouse ήταν επίσης διαφορετικό και με διαφορετικά χαρακτηριστικά. Τώρα υπάρχει κατανόηση του τρόπου ανακατασκευής του προγράμματος οδήγησης ώστε να είναι καλό. Αν συμβεί αυτό, τότε η έκδοση 2 θα είναι ούτως ή άλλως ασυμβίβαστη λόγω συσσωρευμένων πατερίτσες.
Δεν ξέρω πώς να το κανονίσω αυτό. Δεν έχω πολύ χρόνο ο ίδιος. Αν κάποιοι τελειώσουν τον οδηγό, μπορώ να τους βοηθήσω και να τους πω τι να κάνουν. Αλλά είναι η ενεργή συμμετοχή της Yandex στην ανάπτυξη του έργου που δεν έχει ακόμη συζητηθεί με κανέναν τρόπο.
Alexey Milovidov: Στην πραγματικότητα, δεν υπάρχει ακόμη γραφειοκρατία σχετικά με αυτούς τους οδηγούς. Το μόνο πράγμα είναι ότι μεταφέρονται σε έναν επίσημο οργανισμό, δηλαδή, αυτό το πρόγραμμα οδήγησης αναγνωρίζεται ως η επίσημη προεπιλεγμένη λύση για το Go. Υπάρχουν κάποιοι άλλοι οδηγοί, αλλά έρχονται χωριστά.
Δεν έχουμε καμία εξέλιξη για αυτούς τους οδηγούς μέσα. Το ερώτημα είναι αν μπορούμε να προσλάβουμε ένα άτομο, όχι ειδικά για αυτόν τον οδηγό, αλλά για την ανάπτυξη όλων των κοινοτικών οδηγών, ή μπορούμε να βρούμε κάποιον εκτός.
Το εξωτερικό λεξικό δεν ανυψώνεται μετά την επανεκκίνηση με ενεργοποιημένο το lazy_load. Τι να κάνω?
Έχουμε ενεργοποιημένη τη ρύθμιση lazy_load και μετά την επανεκκίνηση του διακομιστή, το ίδιο το λεξικό δεν ανεβαίνει. Ανυψώνεται μόνο αφού ο χρήστης αποκτήσει πρόσβαση σε αυτό το λεξικό. Και βγάζει σφάλμα στην πρώτη κλήση. Είναι δυνατό να φορτώσετε με κάποιο τρόπο αυτόματα τα λεξικά χρησιμοποιώντας το ClickHouse ή πρέπει πάντα να ελέγχετε μόνοι σας την ετοιμότητά τους, ώστε οι χρήστες να μην λαμβάνουν σφάλματα;
Ίσως έχουμε μια παλιά έκδοση του ClickHouse, οπότε το λεξικό δεν φορτώθηκε αυτόματα. Θα μπορούσε να είναι?
Πρώτον, τα λεξικά μπορούν να φορτωθούν αναγκαστικά χρησιμοποιώντας το ερώτημα επαναφόρτωση λεξικών συστήματος. Δεύτερον, σχετικά με το σφάλμα - εάν το λεξικό έχει ήδη φορτωθεί, τότε τα ερωτήματα θα λειτουργήσουν στα δεδομένα που φορτώθηκαν. Εάν το λεξικό δεν έχει ακόμη φορτωθεί, τότε θα φορτωθεί ακριβώς τη στιγμή της αίτησης.
Για βαριά λεξικά, αυτό δεν είναι πολύ βολικό. Για παράδειγμα, πρέπει να λάβετε ένα εκατομμύριο σειρές από τη MySQL. Κάποιος κάνει μια απλή επιλογή, αλλά αυτή η επιλογή θα περιμένει για τις ίδιες εκατομμύρια σειρές. Εδώ υπάρχουν δύο λύσεις. Το πρώτο είναι να απενεργοποιήσετε το lazy_load. Το δεύτερο είναι όταν ο διακομιστής ανεβαίνει, πριν ενεργοποιήσετε το φορτίο σε αυτόν, κάντε λεξικό επαναφόρτωσης συστήματος ή απλώς εκτελέστε ένα ερώτημα που χρησιμοποιεί ένα λεξικό. Στη συνέχεια θα φορτωθεί το λεξικό. Πρέπει να ελέγχετε τη διαθεσιμότητα των λεξικών με ενεργοποιημένη τη ρύθμιση lazy_load, επειδή το ClickHouse δεν τα ανασύρει αυτόματα.
Η απάντηση στην τελευταία ερώτηση είναι είτε η έκδοση είναι παλιά, είτε χρειάζεται αποσφαλμάτωση.
Τι γίνεται με το γεγονός ότι τα λεξικά επαναφόρτωσης συστήματος δεν φορτώνουν κανένα από τα πολλά λεξικά εάν τουλάχιστον ένα από αυτά διακοπεί με σφάλμα;
Υπάρχει μια άλλη ερώτηση σχετικά με τα λεξικά επαναφόρτωσης συστήματος. Έχουμε δύο λεξικά - το ένα δεν είναι φορτωμένο, το δεύτερο είναι φορτωμένο. Τα λεξικά επαναφόρτωσης συστήματος σε αυτήν την περίπτωση δεν φορτώνουν κανένα λεξικό και πρέπει να φορτώσετε από σημείο σε σημείο ένα συγκεκριμένο με το όνομά του χρησιμοποιώντας το λεξικό επαναφόρτωσης συστήματος. Σχετίζεται και αυτό με την έκδοση του ClickHouse;
θέλω να παρακαλώ. Αυτή η συμπεριφορά έχει αλλάξει. Έτσι, εάν ενημερώσετε το ClickHouse, θα αλλάξει επίσης. Εάν δεν είστε ικανοποιημένοι με την τρέχουσα συμπεριφορά επαναφόρτωση λεξικών συστήματος, ενημέρωση και ας ελπίσουμε ότι θα αλλάξει προς το καλύτερο.
Υπάρχει τρόπος να διαμορφώσετε τις λεπτομέρειες στη ρύθμιση παραμέτρων ClickHouse, αλλά να μην τις φωτίσετε σε σφάλματα;
Η επόμενη ερώτηση αφορά σφάλματα που σχετίζονται με το λεξικό, δηλαδή λεπτομέρειες. Έχουμε καταχωρίσει τα στοιχεία σύνδεσης στη διαμόρφωση ClickHouse στο λεξικό και σε περίπτωση σφάλματος, λαμβάνουμε αυτά τα στοιχεία και τον κωδικό πρόσβασης ως απάντηση.
Επιλύσαμε αυτό το σφάλμα προσθέτοντας λεπτομέρειες στη διαμόρφωση του προγράμματος οδήγησης ODBC. Υπάρχει κάποιος τρόπος για να διαμορφώσετε τις λεπτομέρειες στη διαμόρφωση ClickHouse, αλλά να μην εμφανιστούν αυτές οι λεπτομέρειες σε σφάλματα;
Εδώ, η λύση είναι πραγματικά - να καθορίσετε αυτά τα διαπιστευτήρια στο odbc.ini και στο ίδιο το ClickHouse, να καθορίσετε μόνο το Όνομα προέλευσης δεδομένων ODBC. Αυτό δεν θα συμβεί για άλλες πηγές λεξικού - ούτε για ένα λεξικό με MySQL, ούτε για τα υπόλοιπα, δεν θα πρέπει να δείτε τον κωδικό πρόσβασης στο μήνυμα σφάλματος. Για το ODBC, θα κοιτάξω επίσης - αν υπάρχει κάτι τέτοιο, απλά πρέπει να το αφαιρέσετε.
Μπόνους: φόντα για τον Zuma από συγκεντρώσεις
Κάνοντας κλικ στην εικόνα για τους πιο επίμονους αναγνώστες, θα ανοίξουν μπόνους φόντο από συγκεντρώσεις. Κατάσβεση της φωτιάς μαζί με τις τεχνολογικές μασκότ του Avito, συνεννόηση με συναδέλφους από το δωμάτιο του διαχειριστή του συστήματος ή μια παλιά λέσχη υπολογιστών και κρατώντας ένα καθημερινό κάτω από τη γέφυρα με φόντο γκράφιτι.
Πηγή: www.habr.com