Δεδομένου ότι το ClickHouse είναι ένα εξειδικευμένο σύστημα, είναι σημαντικό να λαμβάνονται υπόψη οι ιδιαιτερότητες της αρχιτεκτονικής του κατά τη χρήση του. Σε αυτήν την αναφορά, ο Alexey θα μιλήσει για παραδείγματα τυπικών σφαλμάτων κατά τη χρήση του ClickHouse, τα οποία μπορεί να οδηγήσουν σε αναποτελεσματική εργασία. Χρησιμοποιώντας πρακτικά παραδείγματα, θα δείξουμε πώς η επιλογή του ενός ή του άλλου σχήματος επεξεργασίας δεδομένων μπορεί να αλλάξει την απόδοση κατά τάξεις μεγέθους.
Γεια σε όλους! Με λένε Alexey, φτιάχνω το ClickHouse.
Πρώτον, βιάζομαι να σας ευχαριστήσω αμέσως, δεν θα σας πω σήμερα τι είναι το ClickHouse. Για να είμαι ειλικρινής, το έχω βαρεθεί. Σας λέω κάθε φορά τι είναι. Και μάλλον όλοι γνωρίζουν ήδη.
Αντίθετα, θα σας πω ποια είναι η πιθανή γκανιότα, δηλαδή πώς μπορεί να γίνει κακή χρήση του ClickHouse. Στην πραγματικότητα, δεν πρέπει να φοβάστε, γιατί αναπτύσσουμε το ClickHouse ως ένα σύστημα που είναι απλό, βολικό και λειτουργεί ασυνήθιστα. Εγκατέστησα τα πάντα, κανένα πρόβλημα.
Ωστόσο, πρέπει να έχετε κατά νου ότι αυτό το σύστημα είναι εξειδικευμένο και μπορείτε εύκολα να σκοντάψετε σε μια ασυνήθιστη περίπτωση χρήσης που θα βγάλει αυτό το σύστημα από τη ζώνη άνεσής του.
Λοιπόν, τι είναι οι τσουγκράνες; Βασικά θα μιλήσω για τα αυτονόητα. Όλα είναι προφανή σε όλους, όλοι καταλαβαίνουν τα πάντα και μπορούν να χαίρονται που είναι τόσο έξυπνοι, και όσοι δεν καταλαβαίνουν θα μάθουν κάτι νέο.
Το πρώτο πιο απλό παράδειγμα, που, δυστυχώς, συμβαίνει συχνά, είναι ένας μεγάλος αριθμός ενθέτων με μικρές παρτίδες, δηλαδή ένας μεγάλος αριθμός μικρών ενθέτων.
Αν εξετάσουμε πώς το ClickHouse εκτελεί μια εισαγωγή, τότε μπορείτε να στείλετε τουλάχιστον ένα terabyte δεδομένων σε ένα αίτημα. Δεν είναι πρόβλημα.
Και ας δούμε ποια θα είναι η τυπική απόδοση. Για παράδειγμα, έχουμε έναν πίνακα με δεδομένα Yandex.Metrics. Επιτυχίες. 105 μερικές στήλες. 700 byte ασυμπίεστα. Και θα εισάγουμε με τον καλό τρόπο παρτίδες ενός εκατομμυρίου γραμμών.
Εισάγουμε στον πίνακα MergeTree, λαμβάνονται μισό εκατομμύριο σειρές ανά δευτερόλεπτο. Εξαιρετική. Σε έναν αναπαραγόμενο πίνακα - θα είναι λίγο λιγότερο, περίπου 400 σειρές ανά δευτερόλεπτο.
Και αν ενεργοποιήσετε το ένθετο απαρτίας, θα έχετε λίγο λιγότερη, αλλά και πάλι αξιοπρεπή απόδοση, 250 φορές το δευτερόλεπτο. Η εισαγωγή απαρτίας είναι μια μη τεκμηριωμένη δυνατότητα στο ClickHouse*.
* από το 2020, .
Τι θα συμβεί αν το κάνετε λάθος; Εισάγουμε μια σειρά στον πίνακα MergeTree και έχουμε 59 σειρές ανά δευτερόλεπτο. Αυτό είναι 10 φορές αργό. Στο ReplicatedMergeTree - 000 σειρές ανά δευτερόλεπτο. Και αν ενεργοποιηθεί η απαρτία, τότε λαμβάνονται 6 γραμμές ανά δευτερόλεπτο. Κατά τη γνώμη μου, αυτό είναι ένα είδος απόλυτης βλακείας. Πώς μπορείς να επιβραδύνεις έτσι; Λέει ακόμη και στο μπλουζάκι μου ότι το ClickHouse δεν πρέπει να επιβραδύνει. Αλλά παρόλα αυτά συμβαίνει μερικές φορές.
Στην πραγματικότητα, αυτό είναι το ελάττωμά μας. Θα μπορούσαμε να το είχαμε κάνει να δουλέψει μια χαρά, αλλά δεν το κάναμε. Και δεν το κάναμε, γιατί το σενάριό μας δεν το χρειαζόταν. Είχαμε ήδη παρτίδες. Μόλις λάβαμε παρτίδες στην είσοδο, και κανένα πρόβλημα. Συνδέστε το και όλα λειτουργούν μια χαρά. Αλλά, φυσικά, όλα τα σενάρια είναι πιθανά. Για παράδειγμα, όταν έχετε μια δέσμη διακομιστών στους οποίους δημιουργούνται δεδομένα. Και δεν εισάγουν δεδομένα τόσο συχνά, αλλά εξακολουθούν να λαμβάνουν συχνά ένθετα. Και πρέπει με κάποιο τρόπο να το αποφύγεις αυτό.
Από τεχνική άποψη, η ουσία είναι ότι όταν κάνετε μια εισαγωγή στο ClickHouse, τα δεδομένα δεν εισέρχονται σε κανένα memtable. Δεν έχουμε καν μια πραγματική δομή καταγραφής MergeTree, αλλά απλώς ένα MergeTree, επειδή δεν υπάρχει ούτε αρχείο καταγραφής ούτε memTable. Απλώς γράφουμε αμέσως τα δεδομένα στο σύστημα αρχείων, που έχουν ήδη αποσυντεθεί σε στήλες. Και αν έχετε 100 στήλες, τότε περισσότερα από 200 αρχεία θα πρέπει να εγγραφούν σε ξεχωριστό κατάλογο. Όλα αυτά είναι πολύ δυσκίνητα.
Και τίθεται το ερώτημα: "Πώς να το κάνουμε σωστά;" Σε μια τέτοια κατάσταση, πρέπει να γράψετε με κάποιο τρόπο δεδομένα στο ClickHouse.
Μέθοδος 1. Αυτός είναι ο ευκολότερος τρόπος. Χρησιμοποιήστε κάποιο είδος κατανεμημένης ουράς. Για παράδειγμα, ο Κάφκα. Απλώς αφαιρείτε δεδομένα από τον Κάφκα, τα συλλέγουμε μία φορά το δευτερόλεπτο. Και όλα θα πάνε καλά, ηχογραφείτε, όλα λειτουργούν μια χαρά.
Τα μειονεκτήματα είναι ότι ο Κάφκα είναι ένα άλλο δυσκίνητο κατανεμημένο σύστημα. Καταλαβαίνω επίσης αν έχετε ήδη τον Κάφκα στην παρέα σας. Είναι καλό, είναι βολικό. Αλλά αν δεν υπάρχει, τότε θα πρέπει να το σκεφτείτε τρεις φορές πριν σύρετε ένα άλλο κατανεμημένο σύστημα στο έργο σας. Και γι' αυτό αξίζει να εξετάσουμε εναλλακτικές λύσεις.
Μέθοδος 2. Εδώ είναι μια τέτοια παλιάς σχολής εναλλακτική και ταυτόχρονα πολύ απλή. Έχετε κάποιο είδος διακομιστή που δημιουργεί τα αρχεία καταγραφής σας; Και απλώς γράφει τα αρχεία καταγραφής σας σε ένα αρχείο. Και μια φορά το δευτερόλεπτο, για παράδειγμα, μετονομάζουμε αυτό το αρχείο, ανοίγουμε ένα νέο. Και ένα ξεχωριστό σενάριο είτε από το cron είτε από κάποιον δαίμονα παίρνει το παλαιότερο αρχείο και το γράφει στο ClickHouse. Εάν γράφετε αρχεία καταγραφής μία φορά το δευτερόλεπτο, τότε όλα θα πάνε καλά.
Αλλά το μειονέκτημα αυτής της μεθόδου είναι ότι εάν ο διακομιστής σας στον οποίο δημιουργούνται τα αρχεία καταγραφής έχει εξαφανιστεί κάπου, τότε θα εξαφανιστούν και τα δεδομένα.
Μέθοδος 3. Υπάρχει ένας άλλος ενδιαφέρον τρόπος, ο οποίος είναι χωρίς καθόλου προσωρινά αρχεία. Για παράδειγμα, έχετε κάποιο είδος διαφημιστικού spinner ή κάποιο άλλο ενδιαφέρον δαίμονα που δημιουργεί δεδομένα. Και μπορείτε να συγκεντρώσετε μια δέσμη δεδομένων απευθείας στη μνήμη RAM, στο buffer. Και όταν περάσει αρκετός χρόνος, αφήνετε αυτό το buffer στην άκρη, δημιουργείτε ένα νέο και εισάγετε ό,τι έχει ήδη συσσωρευτεί στο ClickHouse σε ξεχωριστό νήμα.
Από την άλλη, τα δεδομένα εξαφανίζονται επίσης με το kill -9. Εάν ο διακομιστής σας πέσει, θα χάσετε αυτά τα δεδομένα. Και ένα άλλο πρόβλημα είναι ότι εάν δεν μπορούσατε να γράψετε στη βάση δεδομένων, τότε τα δεδομένα σας θα συσσωρευτούν στη μνήμη RAM. Και είτε τελειώνει η μνήμη RAM, είτε απλά χάνετε δεδομένα.
Μέθοδος 4. Ένας άλλος ενδιαφέρων τρόπος. Έχετε κάποια διαδικασία διακομιστή; Και μπορεί να στείλει δεδομένα στο ClickHouse ταυτόχρονα, αλλά να το κάνει σε μία σύνδεση. Για παράδειγμα, έστειλα ένα αίτημα http με κωδικοποίηση μεταφοράς: τεμαχισμένο με ένθετο. Και δημιουργεί κομμάτια όχι πολύ σπάνια, μπορείτε να στείλετε κάθε γραμμή, αν και θα υπάρχει ένα γενικό κόστος για τη διαμόρφωση αυτών των δεδομένων.
Ωστόσο, σε αυτήν την περίπτωση, τα δεδομένα θα σταλούν αμέσως στο ClickHouse. Και το ίδιο το ClickHouse θα τα αποθηκεύσει.
Υπάρχουν όμως και προβλήματα. Τώρα θα χάσετε δεδομένα, συμπεριλαμβανομένου του πότε η διεργασία σας τερματίζεται και εάν η διαδικασία ClickHouse σκοτωθεί, επειδή θα είναι ένα ημιτελές ένθετο. Και στο ClickHouse τα ένθετα είναι ατομικά μέχρι κάποιο καθορισμένο όριο στο μέγεθος των σειρών. Κατ 'αρχήν, αυτός είναι ένας ενδιαφέρον τρόπος. Επίσης μπορεί να χρησιμοποιηθεί.
Μέθοδος 5. Εδώ είναι ένας άλλος ενδιαφέρον τρόπος. Αυτός είναι ένα είδος διακομιστή που έχει αναπτυχθεί από την κοινότητα για ομαδοποίηση δεδομένων. Δεν το έχω κοιτάξει ο ίδιος, οπότε δεν μπορώ να εγγυηθώ τίποτα. Ωστόσο, δεν υπάρχουν εγγυήσεις για το ίδιο το ClickHouse. Αυτό είναι επίσης ανοιχτού κώδικα, αλλά από την άλλη πλευρά, θα μπορούσατε να συνηθίσετε σε κάποιο πρότυπο ποιότητας που προσπαθούμε να παρέχουμε. Αλλά για αυτό το πράγμα - δεν ξέρω, πήγαινε στο GitHub, δες τον κώδικα. Ίσως έγραψαν κάτι καλό.
*από το 2020, θα πρέπει επίσης να ληφθούν υπόψη .
Μέθοδος 6. Ένας άλλος τρόπος είναι να χρησιμοποιήσετε πίνακες buffer. Το πλεονέκτημα αυτής της μεθόδου είναι ότι είναι πολύ εύκολο να ξεκινήσετε τη χρήση. Δημιουργήστε έναν πίνακα buffer και εισαγάγετε σε αυτόν.
Αλλά το μειονέκτημα είναι ότι το πρόβλημα δεν λύνεται πλήρως. Εάν με ρυθμό του τύπου MergeTree πρέπει να ομαδοποιήσετε δεδομένα κατά μία παρτίδα ανά δευτερόλεπτο, τότε με ρυθμό σε έναν πίνακα προσωρινής αποθήκευσης, θα πρέπει να ομαδοποιήσετε τουλάχιστον έως πολλές χιλιάδες ανά δευτερόλεπτο. Εάν υπάρχουν περισσότερες από 10 ανά δευτερόλεπτο, θα είναι ακόμα κακό. Και αν εισάγετε σε παρτίδες, τότε είδατε ότι εκεί λαμβάνονται εκατό χιλιάδες γραμμές ανά δευτερόλεπτο. Και αυτό είναι ήδη σε αρκετά βαριά δεδομένα.
Και επίσης οι πίνακες buffer δεν έχουν αρχείο καταγραφής. Και αν κάτι δεν πάει καλά με τον διακομιστή σας, τότε τα δεδομένα θα χαθούν.
Και ως μπόνους, πρόσφατα είχαμε την ευκαιρία να συλλέξουμε δεδομένα από τον Κάφκα στο ClickHouse. Υπάρχει μια επιτραπέζια μηχανή - Kafka. Απλώς δημιουργείς. Και μπορείτε να κρεμάσετε υλοποιημένες απόψεις σε αυτό. Σε αυτήν την περίπτωση, θα βγάλει τα δεδομένα από τον Κάφκα και θα τα εισάγει στους πίνακες που χρειάζεστε.
Και αυτό που είναι ιδιαίτερα ευχάριστο σε αυτή την ευκαιρία είναι ότι δεν τα καταφέραμε. Αυτό είναι ένα χαρακτηριστικό της κοινότητας. Και όταν λέω «κοινοτικό χαρακτηριστικό», το λέω χωρίς καμία περιφρόνηση. Διαβάσαμε τον κώδικα, κάναμε μια αναθεώρηση, θα πρέπει να λειτουργεί καλά.
* από το 2020, υπάρχει παρόμοια υποστήριξη για .
Τι άλλο μπορεί να είναι ενοχλητικό ή απροσδόκητο κατά την εισαγωγή δεδομένων; Εάν κάνετε ένα ερώτημα εισαγωγής τιμών και γράψτε μερικές υπολογισμένες εκφράσεις σε τιμές. Για παράδειγμα, η now() είναι επίσης μια αξιολογημένη έκφραση. Και σε αυτήν την περίπτωση, το ClickHouse αναγκάζεται να εκκινήσει τον διερμηνέα αυτών των εκφράσεων για κάθε γραμμή και η απόδοση θα μειωθεί κατά τάξεις μεγέθους. Καλύτερα να το αποφύγεις.
* αυτή τη στιγμή, το πρόβλημα έχει λυθεί πλήρως, δεν υπάρχει πλέον παλινδρόμηση απόδοσης κατά τη χρήση παραστάσεων σε VALUES.
Ένα άλλο παράδειγμα όπου μπορεί να υπάρχουν κάποια προβλήματα είναι όταν τα δεδομένα σας σε μία παρτίδα ανήκουν σε μια δέσμη κατατμήσεων. Από προεπιλογή, το ClickHouse κατατμήσεις ανά μήνα. Και αν εισαγάγετε μια παρτίδα εκατομμυρίων σειρών και υπάρχουν δεδομένα για αρκετά χρόνια, τότε θα έχετε αρκετές δεκάδες κατατμήσεις εκεί. Και αυτό ισοδυναμεί με το γεγονός ότι θα υπάρχουν παρτίδες αρκετές δεκάδες φορές μικρότερες, γιατί στο εσωτερικό τους πάντα χωρίζονται πρώτα σε χωρίσματα.
* Πρόσφατα στο ClickHouse σε πειραματική λειτουργία προστέθηκε υποστήριξη για τη συμπαγή μορφή τμημάτων και κομματιών στη μνήμη RAM με αρχείο καταγραφής εγγραφής, η οποία λύνει σχεδόν πλήρως το πρόβλημα.
Τώρα εξετάστε το δεύτερο είδος προβλήματος - την πληκτρολόγηση δεδομένων.
Η πληκτρολόγηση δεδομένων μπορεί να είναι αυστηρή και μερικές φορές συμβολοσειρά. Συμβολοσειρά - αυτό είναι όταν μόλις πήρατε και δηλώσατε ότι έχετε όλα τα πεδία τύπου string. Είναι χάλια. Δεν χρειάζεται να το κάνετε αυτό.
Ας βρούμε πώς να το κάνουμε σωστά σε περιπτώσεις που θέλετε να πείτε ότι έχουμε κάποιο πεδίο, μια συμβολοσειρά και αφήστε το ClickHouse να το καταλάβει μόνο του, αλλά δεν θα κάνω ατμόλουτρο. Αλλά εξακολουθεί να αξίζει να καταβάλετε κάποια προσπάθεια.
Για παράδειγμα, έχουμε μια διεύθυνση IP. Σε μια περίπτωση, το αποθηκεύσαμε ως συμβολοσειρά. Για παράδειγμα, 192.168.1.1. Διαφορετικά, θα είναι ένας αριθμός τύπου UInt32*. 32 bit είναι αρκετά για μια διεύθυνση IPv4.
Πρώτον, παραδόξως, τα δεδομένα θα συμπιεστούν περίπου το ίδιο. Θα υπάρχει διαφορά, σίγουρα, αλλά όχι τόσο μεγάλη. Άρα δεν υπάρχουν ιδιαίτερα προβλήματα με την είσοδο/έξοδο του δίσκου.
Υπάρχει όμως μια σοβαρή διαφορά στον χρόνο της CPU και στον χρόνο εκτέλεσης του ερωτήματος.
Ας μετρήσουμε τον αριθμό των μοναδικών διευθύνσεων IP εάν είναι αποθηκευμένες ως αριθμοί. Προκύπτουν 137 εκατομμύρια γραμμές ανά δευτερόλεπτο. Αν είναι το ίδιο με τις γραμμές, τότε 37 εκατομμύρια γραμμές ανά δευτερόλεπτο. Δεν ξέρω γιατί έγινε αυτή η σύμπτωση. Αυτά τα αιτήματα τα έχω κάνει μόνος μου. Αλλά παρόλα αυτά περίπου 4 φορές πιο αργά.
Και αν υπολογίσετε τη διαφορά στο χώρο του δίσκου, τότε υπάρχει επίσης διαφορά. Και η διαφορά είναι περίπου το ένα τέταρτο, επειδή υπάρχουν πολλές μοναδικές διευθύνσεις IP. Και αν υπήρχαν γραμμές με μικρό αριθμό διαφορετικών τιμών, τότε θα είχαν συμπιεστεί αθόρυβα στο λεξικό στον ίδιο περίπου τόμο.
Και η τετραπλάσια διαφορά ώρας δεν βρίσκεται στο δρόμο. Ίσως, φυσικά, να μην σε νοιάζει, αλλά όταν βλέπω μια τέτοια διαφορά, στεναχωριέμαι.
Ας εξετάσουμε διαφορετικές περιπτώσεις.
1. Μια περίπτωση που έχετε λίγες διαφορετικές μοναδικές αξίες. Σε αυτήν την περίπτωση, χρησιμοποιούμε μια απλή πρακτική που πιθανώς γνωρίζετε και μπορείτε να χρησιμοποιήσετε για οποιοδήποτε DBMS. Όλα αυτά έχουν νόημα όχι μόνο για το ClickHouse. Απλώς γράψτε τα αριθμητικά αναγνωριστικά στη βάση δεδομένων. Και μπορείτε να μετατρέψετε σε χορδές και πίσω στο πλάι της εφαρμογής σας.
Για παράδειγμα, έχετε μια περιοχή. Και προσπαθείτε να το αποθηκεύσετε ως συμβολοσειρά. Και θα γραφτεί εκεί: Μόσχα και Περιφέρεια Μόσχας. Και όταν βλέπω ότι το "Moscow" είναι γραμμένο εκεί, τότε αυτό δεν είναι τίποτα, και όταν είναι MO, κατά κάποιο τρόπο γίνεται εντελώς λυπηρό. Τόσα byte.
Αντίθετα, γράφουμε απλώς τον αριθμό Ulnt32 και το 250. Έχουμε 250 στο Yandex, αλλά το δικό σας μπορεί να είναι διαφορετικό. Για κάθε περίπτωση, θα πω ότι το ClickHouse έχει μια ενσωματωμένη δυνατότητα να λειτουργεί με μια γεωβάση. Απλώς γράφετε έναν κατάλογο με περιοχές, συμπεριλαμβανομένου ενός ιεραρχικού, δηλαδή θα υπάρχει η Μόσχα, η περιοχή της Μόσχας και όλα όσα χρειάζεστε. Και μπορείτε να κάνετε μετατροπή σε επίπεδο αιτήματος.
Η δεύτερη επιλογή είναι περίπου η ίδια, αλλά με υποστήριξη στο ClickHouse. Είναι ένας τύπος δεδομένων Enum. Απλώς γράφετε όλες τις τιμές που χρειάζεστε μέσα στο Enum. Για παράδειγμα, τον τύπο της συσκευής και γράψτε εκεί: επιτραπέζιος υπολογιστής, κινητό, tablet, τηλεόραση. Μόνο 4 επιλογές.
Το μειονέκτημα είναι ότι πρέπει να αλλάζετε περιοδικά. Προστέθηκε μόνο μία επιλογή. Φτιάχνουμε alter table. Στην πραγματικότητα, το alter table στο ClickHouse είναι δωρεάν. Ειδικά δωρεάν για το Enum επειδή τα δεδομένα στο δίσκο δεν αλλάζουν. Ωστόσο, το alter αποκτά μια κλειδαριά * στο τραπέζι και πρέπει να περιμένει μέχρι να ολοκληρωθούν όλες οι επιλογές. Και μόνο αφού αυτή η αλλαγή θα εκτελεστεί, δηλαδή, υπάρχουν ακόμα κάποιες ενοχλήσεις.
* στις πρόσφατες εκδόσεις του ClickHouse, το ALTER είναι εντελώς μη αποκλειστικό.
Μια άλλη επιλογή αρκετά μοναδική για το ClickHouse είναι η σύνδεση εξωτερικών λεξικών. Μπορείτε να γράψετε αριθμούς στο ClickHouse και να διατηρήσετε τους καταλόγους σας σε οποιοδήποτε σύστημα είναι κατάλληλο για εσάς. Για παράδειγμα, μπορείτε να χρησιμοποιήσετε: MySQL, Mongo, Postgres. Μπορείτε ακόμη να δημιουργήσετε τη δική σας microservice, η οποία θα στείλει αυτά τα δεδομένα μέσω http. Και στο επίπεδο ClickHouse, γράφετε μια συνάρτηση που θα μετατρέψει αυτά τα δεδομένα από αριθμούς σε συμβολοσειρές.
Αυτός είναι ένας εξειδικευμένος αλλά πολύ αποτελεσματικός τρόπος για να πραγματοποιήσετε μια ένωση σε εξωτερικό τραπέζι. Και υπάρχουν δύο επιλογές. Σε μία επιλογή, αυτά τα δεδομένα θα αποθηκευτούν πλήρως στην κρυφή μνήμη, θα υπάρχουν πλήρως στη μνήμη RAM και θα ενημερώνονται σε ορισμένα διαστήματα. Και σε μια άλλη επιλογή, εάν αυτά τα δεδομένα δεν χωρούν στη μνήμη RAM, τότε μπορείτε να τα αποθηκεύσετε εν μέρει.
Εδώ είναι ένα παράδειγμα. Υπάρχει Yandex.Direct. Και υπάρχει διαφημιστική εταιρεία και πανό. Υπάρχουν πιθανώς δεκάδες εκατομμύρια διαφημιστικές εταιρείες. Και χωράει περίπου στη μνήμη RAM. Και υπάρχουν δισεκατομμύρια πανό, δεν χωράνε. Και χρησιμοποιούμε ένα αποθηκευμένο λεξικό από τη MySQL.
Το μόνο πρόβλημα είναι ότι το αποθηκευμένο λεξικό θα λειτουργεί καλά εάν το ποσοστό επιτυχίας είναι κοντά στο 100%. Εάν είναι μικρότερο, τότε κατά την επεξεργασία αιτημάτων για κάθε πακέτο δεδομένων, θα χρειαστεί να λάβετε πραγματικά τα κλειδιά που λείπουν και να πάτε για λήψη δεδομένων από τη MySQL. Σχετικά με το ClickHouse, μπορώ ακόμα να εγγυηθώ ότι - ναι, δεν επιβραδύνεται, δεν θα μιλήσω για άλλα συστήματα.
Και ως μπόνους, τα λεξικά είναι ένας πολύ εύκολος τρόπος για να ενημερώσετε τα δεδομένα στο ClickHouse αναδρομικά. Δηλαδή είχες αναφορά σε διαφημιστικές εταιρείες, απλά ο χρήστης άλλαξε τη διαφημιστική εταιρεία και σε όλα τα παλιά δεδομένα, σε όλες τις αναφορές άλλαξαν και αυτά τα δεδομένα. Εάν γράψετε γραμμές απευθείας στον πίνακα, τότε δεν θα μπορείτε να τις ενημερώσετε.
Ένας άλλος τρόπος όταν δεν ξέρετε πού να βρείτε τα αναγνωριστικά για τις συμβολοσειρές σας. μπορείτε απλά να κατακερματίσετε. Και η πιο εύκολη επιλογή είναι να πάρετε ένα hash 64-bit.
Το μόνο πρόβλημα είναι ότι εάν ο κατακερματισμός είναι 64-bit, τότε είναι σχεδόν βέβαιο ότι θα έχετε συγκρούσεις. Γιατί αν υπάρχουν ένα δισεκατομμύριο γραμμές, τότε η πιθανότητα γίνεται ήδη απτή.
Και δεν θα ήταν πολύ καλό να κατακερματίζονται έτσι τα ονόματα των διαφημιστικών εταιρειών. Αν μπερδευτούν οι διαφημιστικές καμπάνιες διαφορετικών εταιρειών, τότε θα υπάρχει κάτι ακατανόητο.
Και υπάρχει ένα απλό κόλπο. Είναι αλήθεια ότι δεν είναι επίσης πολύ κατάλληλο για σοβαρά δεδομένα, αλλά αν κάτι δεν είναι πολύ σοβαρό, τότε απλώς προσθέστε ένα άλλο αναγνωριστικό πελάτη στο κλειδί του λεξικού. Και τότε θα έχετε συγκρούσεις, αλλά μόνο εντός ενός πελάτη. Και χρησιμοποιούμε αυτήν τη μέθοδο για τον χάρτη συνδέσμων στο Yandex.Metrica. Έχουμε url εκεί, αποθηκεύουμε hashes. Και ξέρουμε ότι υπάρχουν και συγκρούσεις, φυσικά. Αλλά όταν εμφανίζεται μια σελίδα, τότε η πιθανότητα ότι είναι σε μια σελίδα για έναν χρήστη ότι ορισμένες url κολλάνε μεταξύ τους και αυτό θα παρατηρηθεί, τότε αυτό μπορεί να παραμεληθεί.
Ως μπόνους, για πολλές λειτουργίες, αρκούν μόνο οι κατακερματισμοί και οι ίδιες οι συμβολοσειρές δεν μπορούν να αποθηκευτούν πουθενά.
Ένα άλλο παράδειγμα εάν οι συμβολοσειρές είναι σύντομες, όπως τομείς ιστότοπου. Μπορούν να αποθηκευτούν ως έχουν. Ή, για παράδειγμα, η γλώσσα του προγράμματος περιήγησης ru είναι 2 byte. Λυπάμαι βέβαια για τα bytes, αλλά μην ανησυχείς, τα 2 bytes δεν είναι κρίμα. Παρακαλώ κρατήστε το ως έχει, μην ανησυχείτε.
Μια άλλη περίπτωση είναι όταν, αντίθετα, υπάρχουν πολλές χορδές και ταυτόχρονα υπάρχουν πολλές μοναδικές σε αυτές, ακόμη και το σύνολο είναι δυνητικά απεριόριστο. Χαρακτηριστικό παράδειγμα είναι οι φράσεις αναζήτησης ή οι διευθύνσεις URL. Αναζήτηση φράσεων, μεταξύ άλλων λόγω τυπογραφικών σφαλμάτων. Ας δούμε πόσες μοναδικές φράσεις αναζήτησης ανά ημέρα. Και αποδεικνύεται ότι είναι σχεδόν τα μισά από όλα τα γεγονότα. Και σε αυτή την περίπτωση, μπορεί να σκεφτείτε ότι πρέπει να ομαλοποιήσετε τα δεδομένα, να μετρήσετε τα αναγνωριστικά, να τα βάλετε σε ξεχωριστό πίνακα. Αλλά δεν χρειάζεται να το κάνετε αυτό. Απλώς κρατήστε αυτές τις γραμμές ως έχουν.
Καλύτερα - μην εφεύρετε τίποτα, γιατί αν το αποθηκεύσετε ξεχωριστά, θα χρειαστεί να κάνετε μια ένωση. Και αυτή η σύνδεση είναι στην καλύτερη περίπτωση μια τυχαία πρόσβαση στη μνήμη, αν εξακολουθεί να χωράει στη μνήμη. Αν δεν ταιριάζει, τότε θα υπάρξουν προβλήματα γενικά.
Και αν τα δεδομένα είναι αποθηκευμένα στη θέση τους, τότε απλώς διαβάζονται με τη σωστή σειρά από το σύστημα αρχείων και όλα είναι καλά.
Εάν έχετε url ή κάποια άλλη σύνθετη μεγάλη συμβολοσειρά, τότε θα πρέπει να σκεφτείτε το γεγονός ότι μπορείτε να υπολογίσετε κάποιο συμπίεση εκ των προτέρων και να το γράψετε σε ξεχωριστή στήλη.
Για url, για παράδειγμα, μπορείτε να αποθηκεύσετε τον τομέα χωριστά. Και αν χρειάζεστε πραγματικά έναν τομέα, τότε απλώς χρησιμοποιήστε αυτήν τη στήλη και οι διευθύνσεις URL θα ψεύδονται και δεν θα τις αγγίξετε καν.
Ας δούμε ποια είναι η διαφορά. Το ClickHouse έχει μια εξειδικευμένη λειτουργία που υπολογίζει τον τομέα. Είναι πολύ γρήγορο, το έχουμε βελτιστοποιήσει. Και, για να είμαι ειλικρινής, δεν συμμορφώνεται καν με το RFC, αλλά παρόλα αυτά λαμβάνει όλα όσα χρειαζόμαστε.
Και σε μια περίπτωση, απλά θα πάρουμε τα url και θα υπολογίσουμε τον τομέα. Αποδεικνύεται 166 χιλιοστά του δευτερολέπτου. Και αν πάρετε έναν έτοιμο τομέα, τότε αποδεικνύεται μόνο 67 χιλιοστά του δευτερολέπτου, δηλαδή σχεδόν τρεις φορές πιο γρήγορα. Και πιο γρήγορα, όχι επειδή πρέπει να κάνουμε κάποιους υπολογισμούς, αλλά επειδή διαβάζουμε λιγότερα δεδομένα.
Για κάποιο λόγο, ένα αίτημα, που είναι πιο αργό, παίρνει μεγαλύτερη ταχύτητα σε gigabyte ανά δευτερόλεπτο. Γιατί διαβάζει περισσότερα gigabytes. Αυτά είναι εντελώς περιττά δεδομένα. Το αίτημα φαίνεται να εκτελείται πιο γρήγορα, αλλά χρειάζεται περισσότερος χρόνος για να ολοκληρωθεί.
Και αν κοιτάξετε τον όγκο των δεδομένων στο δίσκο, αποδεικνύεται ότι η διεύθυνση URL είναι 126 megabyte και ο τομέας είναι μόνο 5 megabyte. Αποδεικνύεται 25 φορές λιγότερο. Ωστόσο, το ερώτημα εξακολουθεί να είναι μόνο 4 φορές ταχύτερο. Αλλά αυτό συμβαίνει γιατί τα δεδομένα είναι καυτά. Και αν ήταν κρύο, πιθανότατα θα ήταν 25 φορές πιο γρήγορο λόγω εισόδου/εξόδου του δίσκου.
Παρεμπιπτόντως, αν αξιολογήσετε πόσο ο τομέας είναι μικρότερος από το url, τότε αποδεικνύεται ότι είναι περίπου 4 φορές. Αλλά για κάποιο λόγο, τα δεδομένα στο δίσκο χρειάζονται 25 φορές λιγότερα. Γιατί; Λόγω συμπίεσης. Και το url συμπιέζεται και ο τομέας συμπιέζεται. Αλλά συχνά το url περιέχει ένα σωρό σκουπίδια.
Και, φυσικά, αξίζει να χρησιμοποιήσετε τους σωστούς τύπους δεδομένων που έχουν σχεδιαστεί ειδικά για τις σωστές τιμές ή για αυτές που ταιριάζουν. Εάν είστε σε IPv4, τότε αποθηκεύστε το UInt32*. Αν IPv6, τότε FixedString(16), επειδή μια διεύθυνση IPv6 είναι 128 bit, δηλαδή αποθηκεύεται απευθείας σε δυαδική μορφή.
Τι γίνεται όμως αν μερικές φορές έχετε διευθύνσεις IPv4 και μερικές φορές IPv6; Ναι, μπορείτε να κρατήσετε και τα δύο. Μια στήλη για το IPv4, μια άλλη για το IPv6. Φυσικά, υπάρχει η επιλογή αντιστοίχισης IPv4 σε IPv6. Αυτό θα λειτουργήσει επίσης, αλλά αν χρειάζεστε συχνά μια διεύθυνση IPv4 στα αιτήματά σας, τότε θα ήταν ωραίο να τη βάλετε σε ξεχωριστή στήλη.
* Το ClickHouse διαθέτει πλέον ξεχωριστούς τύπους δεδομένων IPv4, IPv6 που αποθηκεύουν δεδομένα τόσο αποτελεσματικά όσο και οι αριθμοί, αλλά τα αντιπροσωπεύουν τόσο βολικά όσο οι συμβολοσειρές.
Είναι επίσης σημαντικό να σημειωθεί ότι αξίζει να γίνει προεπεξεργασία των δεδομένων εκ των προτέρων. Για παράδειγμα, μερικά ακατέργαστα κούτσουρα έρχονται σε εσάς. Και, ίσως, δεν πρέπει να τα βάλετε αμέσως στο ClickHouse, αν και είναι πολύ δελεαστικό να μην κάνετε τίποτα και όλα θα λειτουργήσουν. Αλλά εξακολουθεί να αξίζει τον κόπο να πραγματοποιηθούν εκείνοι οι υπολογισμοί που είναι δυνατοί.
Για παράδειγμα, έκδοση προγράμματος περιήγησης. Σε κάποιο γειτονικό τμήμα, στο οποίο δεν θέλω να δείξω το δάχτυλο, η έκδοση του προγράμματος περιήγησης αποθηκεύεται εκεί ως εξής, δηλαδή ως συμβολοσειρά: 12.3. Και μετά, για να κάνουν μια αναφορά, παίρνουν αυτή τη συμβολοσειρά και διαιρούν με έναν πίνακα και μετά με το πρώτο στοιχείο του πίνακα. Φυσικά, όλα επιβραδύνουν. Ρώτησα γιατί το κάνουν αυτό. Μου είπαν ότι δεν τους αρέσει η πρόωρη βελτιστοποίηση. Και δεν μου αρέσει η πρόωρη απαισιοδοξία.
Άρα σε αυτή την περίπτωση θα ήταν πιο σωστό να χωρίσουμε σε 4 στήλες. Μην φοβάστε εδώ, γιατί αυτό είναι το ClickHouse. Το ClickHouse είναι μια βάση δεδομένων στηλών. Και όσο πιο προσεγμένες κολώνες, τόσο το καλύτερο. Θα υπάρχουν 5 BrowserVersion, κάντε 5 στήλες. Είναι εντάξει.
Τώρα σκεφτείτε τι πρέπει να κάνετε εάν έχετε πολλές πολύ μακριές χορδές, πολύ μεγάλους πίνακες. Δεν χρειάζεται καθόλου να αποθηκευτούν στο ClickHouse. Αντίθετα, μπορείτε να αποθηκεύσετε μόνο κάποιο αναγνωριστικό στο ClickHouse. Και αυτές οι μεγάλες ουρές τους σπρώχνουν σε κάποιο άλλο σύστημα.
Για παράδειγμα, μία από τις υπηρεσίες μας αναλυτικών στοιχείων έχει ορισμένες παραμέτρους συμβάντων. Και αν υπάρχουν πολλές παράμετροι στα γεγονότα, απλώς αποθηκεύουμε τις πρώτες 512 που συναντάμε. Γιατί το 512 δεν είναι κρίμα.
Και αν δεν μπορείτε να αποφασίσετε για τους τύπους δεδομένων σας, τότε μπορείτε επίσης να γράψετε δεδομένα στο ClickHouse, αλλά σε έναν προσωρινό πίνακα τύπου Log, ο οποίος είναι ειδικός για προσωρινά δεδομένα. Μετά από αυτό, μπορείτε να αναλύσετε τι είδους κατανομή τιμών έχετε εκεί, τι υπάρχει γενικά και να δημιουργήσετε τους σωστούς τύπους.
* Τώρα το ClickHouse έχει έναν τύπο δεδομένων που σας επιτρέπει να αποθηκεύετε αποτελεσματικά χορδές με λιγότερη προσπάθεια.
Τώρα εξετάστε μια άλλη ενδιαφέρουσα περίπτωση. Μερικές φορές τα πράγματα λειτουργούν με έναν περίεργο τρόπο για τους ανθρώπους. Πάω και το βλέπω αυτό. Και φαίνεται αμέσως ότι αυτό έγινε από κάποιον πολύ έμπειρο, έξυπνο διαχειριστή που έχει μεγάλη εμπειρία στη ρύθμιση της MySQL έκδοσης 3.23.
Εδώ βλέπουμε χίλιους πίνακες, καθένας από τους οποίους περιέχει το υπόλοιπο της διαίρεσης δεν είναι σαφές τι με χίλια.
Κατ' αρχήν, σέβομαι την εμπειρία των άλλων, συμπεριλαμβανομένης της κατανόησης του είδους ταλαιπωρίας που μπορεί να αποκτήσει αυτή η εμπειρία.
Και οι λόγοι είναι λίγο πολύ ξεκάθαροι. Αυτά είναι παλιά στερεότυπα που μπορεί να έχουν συσσωρευτεί κατά την εργασία με άλλα συστήματα. Για παράδειγμα, οι πίνακες MyISAM δεν έχουν πρωτεύον κλειδί συμπλέγματος. Και αυτός ο τρόπος κοινής χρήσης δεδομένων μπορεί να είναι μια απέλπιδα προσπάθεια να αποκτήσετε την ίδια λειτουργικότητα.
Ένας άλλος λόγος είναι ότι είναι δύσκολο να κάνετε οποιαδήποτε αλλαγή σε μεγάλα τραπέζια. Όλα θα μπλοκαριστούν. Αν και στις σύγχρονες εκδόσεις της MySQL, αυτό το πρόβλημα δεν είναι πλέον τόσο σοβαρό.
Ή, για παράδειγμα, microsharding, αλλά περισσότερα για αυτό αργότερα.
Στο ClickHouse, δεν χρειάζεται να το κάνετε αυτό, επειδή, πρώτον, το πρωτεύον κλειδί είναι ομαδοποιημένο, τα δεδομένα ταξινομούνται από το πρωτεύον κλειδί.
Και μερικές φορές οι άνθρωποι με ρωτούν: "Πώς αλλάζει η απόδοση των ερωτημάτων εύρους στο ClickHouse ανάλογα με το μέγεθος του πίνακα;". Λέω ότι δεν αλλάζει καθόλου. Για παράδειγμα, έχετε έναν πίνακα με ένα δισεκατομμύριο σειρές και διαβάζετε ένα εύρος ενός εκατομμυρίου σειρών. Ολα ειναι καλά. Εάν ο πίνακας έχει ένα τρισεκατομμύριο σειρές και διαβάζετε ένα εκατομμύριο σειρές, τότε θα είναι σχεδόν το ίδιο.
Και, δεύτερον, δεν απαιτούνται κομμάτια όπως χειροκίνητα χωρίσματα. Εάν μπείτε και δείτε τι υπάρχει στο σύστημα αρχείων, θα δείτε ότι ένας πίνακας είναι πολύ σοβαρό πράγμα. Και εκεί μέσα υπάρχει κάτι σαν χωρίσματα. Δηλαδή, το ClickHouse κάνει τα πάντα για εσάς και δεν χρειάζεται να υποφέρετε.
Το Alter στο ClickHouse είναι δωρεάν εάν αλλάξει η στήλη προσθήκη/απόθεση.
Και δεν πρέπει να κάνετε μικρά τραπέζια, γιατί αν έχετε 10 σειρές ή 10 σειρές στο τραπέζι σας, τότε δεν πειράζει καθόλου. Το ClickHouse είναι ένα σύστημα που βελτιστοποιεί την απόδοση, όχι την καθυστέρηση, επομένως δεν έχει νόημα να επεξεργαστούμε 000 γραμμές.
Είναι σωστό να χρησιμοποιείτε ένα μεγάλο τραπέζι. Ξεφορτωθείτε τα παλιά στερεότυπα, όλα θα πάνε καλά.
Και ως μπόνους, στην πιο πρόσφατη έκδοση, έχουμε την ευκαιρία να δημιουργήσουμε ένα αυθαίρετο κλειδί κατάτμησης για να εκτελούμε κάθε είδους εργασίες συντήρησης σε μεμονωμένα διαμερίσματα.
Για παράδειγμα, χρειάζεστε πολλούς μικρούς πίνακες, για παράδειγμα, όταν χρειάζεται να επεξεργαστείτε κάποια ενδιάμεσα δεδομένα, λαμβάνετε κομμάτια και πρέπει να κάνετε έναν μετασχηματισμό σε αυτά πριν γράψετε στον τελικό πίνακα. Για αυτήν την περίπτωση, υπάρχει ένας υπέροχος επιτραπέζιος κινητήρας - StripeLog. Είναι σαν το TinyLog, μόνο καλύτερο.
* Τώρα το ClickHouse έχει περισσότερα .
Ένα άλλο anti-pattern είναι το microsharding. Για παράδειγμα, πρέπει να κάνετε κοινή χρήση δεδομένων και έχετε 5 διακομιστές και αύριο θα υπάρχουν 6 διακομιστές. Και σκέφτεστε πώς να εξισορροπήσετε ξανά αυτά τα δεδομένα. Και αντί αυτού, δεν χωρίζετε σε 5 θραύσματα, αλλά σε 1 θραύσματα. Στη συνέχεια, αντιστοιχίζετε καθένα από αυτά τα microshard σε έναν ξεχωριστό διακομιστή. Και θα πετύχετε σε έναν διακομιστή, για παράδειγμα, 000 ClickHouse, για παράδειγμα. Ξεχωριστή παρουσία σε ξεχωριστές θύρες ή ξεχωριστές βάσεις δεδομένων.
Αλλά στο ClickHouse αυτό δεν είναι πολύ καλό. Επειδή ακόμη και μία παρουσία του ClickHouse προσπαθεί να χρησιμοποιήσει όλους τους διαθέσιμους πόρους διακομιστή για την επεξεργασία ενός αιτήματος. Δηλαδή, έχετε κάποιο είδος διακομιστή και εκεί, για παράδειγμα, 56 πυρήνες επεξεργαστή. Εκτελείτε ένα ερώτημα που διαρκεί ένα δευτερόλεπτο και θα χρησιμοποιεί 56 πυρήνες. Και αν τοποθετήσετε 200 ClickHouses σε έναν διακομιστή εκεί, τότε αποδεικνύεται ότι θα ξεκινήσουν 10 νήματα. Γενικά όλα θα πάνε πολύ άσχημα.
Ένας άλλος λόγος είναι ότι η κατανομή της εργασίας σε αυτές τις περιπτώσεις θα είναι άνιση. Κάποιοι θα τελειώσουν νωρίτερα, κάποιοι θα τελειώσουν αργότερα. Αν όλα αυτά συνέβαιναν σε μία περίπτωση, τότε το ίδιο το ClickHouse θα είχε καταλάβει πώς να διανείμει σωστά τα δεδομένα μεταξύ των ροών.
Και ένας άλλος λόγος είναι ότι θα έχετε επικοινωνία μεταξύ επεξεργαστών μέσω TCP. Τα δεδομένα θα πρέπει να σειριοποιηθούν, να αποσειροποιηθούν, και αυτός είναι ένας τεράστιος αριθμός microshards. Απλώς δεν θα λειτουργήσει.
Ένα άλλο antipattern, αν και δύσκολα μπορεί να ονομαστεί antipattern. Αυτό είναι ένα μεγάλο ποσό προ-συγκέντρωσης.
Σε γενικές γραμμές, η προ-συγκέντρωση είναι καλή. Είχατε ένα δισεκατομμύριο σειρές, τις συγκεντρώσατε και έγιναν 1 σειρές και τώρα το ερώτημα εκτελείται άμεσα. Ολα είναι υπέροχα. Έτσι μπορείς να το κάνεις. Και για αυτό, ακόμη και το ClickHouse έχει έναν ειδικό τύπο πίνακα AggregatingMergeTree που κάνει σταδιακή συγκέντρωση καθώς εισάγονται δεδομένα.
Αλλά υπάρχουν φορές που πιστεύετε ότι θα συγκεντρώσουμε δεδομένα όπως αυτό και θα συγκεντρώσουμε δεδομένα όπως αυτό. Και σε κάποιο γειτονικό τμήμα, δεν θέλω να πω ούτε ποιο, χρησιμοποιούν πίνακες SummingMergeTree για άθροιση με το πρωτεύον κλειδί και 20 στήλες χρησιμοποιούνται ως πρωτεύον κλειδί. Για κάθε ενδεχόμενο άλλαξα τα ονόματα κάποιων στηλών για συνωμοσία, αλλά μέχρι εκεί.
Και προκύπτουν τέτοια προβλήματα. Πρώτον, ο όγκος των δεδομένων που έχετε δεν μειώνεται πολύ. Για παράδειγμα, μειώνεται κατά τρεις φορές. Τρεις φορές θα ήταν μια καλή τιμή για να αντέξετε οικονομικά τα απεριόριστα αναλυτικά στοιχεία που συνοδεύουν τα μη συγκεντρωτικά δεδομένα. Εάν τα δεδομένα συγκεντρωθούν, τότε λαμβάνετε μόνο άθλια στατιστικά αντί για αναλυτικά στοιχεία.
Και τι είναι ιδιαίτερα καλό; Ότι αυτοί οι άνθρωποι από το επόμενο τμήμα, πάνε και ζητούν μερικές φορές να προσθέσουν μια ακόμη στήλη στο πρωτεύον κλειδί. Δηλαδή, έχουμε συγκεντρώσει τα δεδομένα έτσι, και τώρα θέλουμε λίγο περισσότερο. Αλλά δεν υπάρχει εναλλακτικό πρωτεύον κλειδί στο ClickHouse. Επομένως, πρέπει να γράψετε μερικά σενάρια σε C ++. Και δεν μου αρέσουν τα σενάρια, ακόμα κι αν είναι σε C++.
Και αν κοιτάξετε για ποιο σκοπό δημιουργήθηκε το ClickHouse, τότε τα μη συγκεντρωτικά δεδομένα είναι ακριβώς το σενάριο για το οποίο γεννήθηκε. Εάν χρησιμοποιείτε το ClickHouse για μη συγκεντρωτικά δεδομένα, τότε τα κάνετε όλα σωστά. Εάν συγκεντρώνεστε, τότε αυτό μερικές φορές συγχωρείται.
Μια άλλη ενδιαφέρουσα περίπτωση είναι τα αιτήματα σε έναν άπειρο βρόχο. Μερικές φορές πηγαίνω σε κάποιο διακομιστή παραγωγής και κοιτάζω τη λίστα διαδικασιών εμφάνισης εκεί. Και κάθε φορά ανακαλύπτω ότι κάτι τρομερό συμβαίνει.
Για παράδειγμα, εδώ είναι αυτό. Είναι αμέσως σαφές ότι ήταν δυνατό να γίνουν τα πάντα με ένα αίτημα. Απλώς γράψτε τη διεύθυνση url και τη λίστα εκεί.
Γιατί πολλά τέτοια αιτήματα σε έναν άπειρο βρόχο είναι κακά; Εάν το ευρετήριο δεν χρησιμοποιείται, τότε θα έχετε πολλά περάσματα στα ίδια δεδομένα. Αλλά αν χρησιμοποιείται ευρετήριο, για παράδειγμα, έχετε ένα πρωτεύον κλειδί στο ru και γράφετε url = κάτι εκεί. Και νομίζετε ότι ένα url θα διαβαστεί από τον πίνακα, όλα θα πάνε καλά. Αλλά πραγματικά όχι. Επειδή το ClickHouse κάνει τα πάντα σε παρτίδες.
Όταν χρειάζεται να διαβάσει κάποιο εύρος δεδομένων, διαβάζει λίγο περισσότερο, γιατί το ευρετήριο στο ClickHouse είναι αραιό. Αυτό το ευρετήριο δεν σας επιτρέπει να βρείτε μία μεμονωμένη σειρά στον πίνακα, μόνο κάποιο είδος εύρους. Και τα δεδομένα συμπιέζονται σε μπλοκ. Για να διαβάσετε μια γραμμή, πρέπει να πάρετε ολόκληρο το μπλοκ και να το αποσυμπιέσετε. Και αν εκτελέσετε ένα σωρό ερωτήματα, θα έχετε πολλές διασταυρώσεις από αυτές και θα έχετε πολλή δουλειά να κάνετε ξανά και ξανά.
Και ως μπόνους, μπορείτε να δείτε ότι στο ClickHouse δεν πρέπει να φοβάστε να μεταφέρετε ακόμη και megabyte, ακόμη και εκατοντάδες megabyte στην ενότητα IN. Θυμάμαι από την πρακτική μας ότι εάν περάσουμε ένα σωρό τιμές στην ενότητα IN στη MySQL, για παράδειγμα, περάσουμε 100 megabyte ορισμένων αριθμών εκεί, τότε η MySQL τρώει 10 gigabyte μνήμης και δεν συμβαίνει τίποτα άλλο. όλα λειτουργούν άσχημα.
Και το δεύτερο πράγμα είναι ότι στο ClickHouse, εάν τα ερωτήματά σας χρησιμοποιούν ευρετήριο, τότε δεν είναι πάντα πιο αργή από μια πλήρη σάρωση, δηλαδή εάν χρειάζεται να διαβάσετε σχεδόν ολόκληρο τον πίνακα, θα πάει διαδοχικά και θα διαβάσει ολόκληρο τον πίνακα. Γενικά θα το καταλάβει.
Ωστόσο, υπάρχουν κάποιες δυσκολίες. Για παράδειγμα, ότι το IN με ένα δευτερεύον ερώτημα δεν χρησιμοποιεί το ευρετήριο. Αλλά αυτό είναι το πρόβλημά μας και πρέπει να το διορθώσουμε. Δεν υπάρχει τίποτα θεμελιώδες εδώ. Ας το κάνουμε*.
Και ένα άλλο ενδιαφέρον πράγμα είναι ότι εάν έχετε ένα πολύ μεγάλο αίτημα και η επεξεργασία κατανεμημένων αιτημάτων βρίσκεται σε εξέλιξη, τότε αυτό το πολύ μεγάλο αίτημα θα σταλεί σε κάθε διακομιστή χωρίς συμπίεση. Για παράδειγμα, 100 megabyte και 500 διακομιστές. Και, κατά συνέπεια, 50 gigabyte θα μεταφερθούν μέσω του δικτύου. Θα μεταφερθεί και μετά θα εκτελεστούν όλα με επιτυχία.
* χρησιμοποιείται ήδη όλα διορθώθηκαν όπως είχε υποσχεθεί.
Και είναι αρκετά συνηθισμένο εάν τα αιτήματα προέρχονται από το API. Για παράδειγμα, έχετε κάνει κάποιου είδους υπηρεσία. Και αν κάποιος χρειάζεται την υπηρεσία σας, τότε άνοιξες το API και κυριολεκτικά δύο μέρες μετά βλέπεις ότι κάτι ακατανόητο συμβαίνει. Όλα είναι υπερφορτωμένα και έρχονται κάποια τρομερά αιτήματα που δεν έπρεπε ποτέ να γίνουν.
Και υπάρχει μόνο μία λύση. Εάν έχετε ανοίξει το API, τότε θα πρέπει να το κόψετε. Για παράδειγμα, για να εισαγάγετε ορισμένες ποσοστώσεις. Δεν υπάρχουν άλλες λογικές επιλογές. Διαφορετικά, θα γράψουν αμέσως σενάριο και θα υπάρξουν προβλήματα.
Και το ClickHouse έχει ένα ειδικό χαρακτηριστικό - αυτός είναι ο υπολογισμός των ποσοστώσεων. Επιπλέον, μπορείτε να μεταφέρετε το κλειδί ποσόστωσής σας. Αυτό είναι, για παράδειγμα, ένα εσωτερικό αναγνωριστικό χρήστη. Και οι ποσοστώσεις θα υπολογίζονται ανεξάρτητα για καθένα από αυτά.
Τώρα ένα άλλο ενδιαφέρον. Αυτό είναι χειροκίνητη αναπαραγωγή.
Γνωρίζω πολλές περιπτώσεις όπου, παρά το γεγονός ότι το ClickHouse έχει ενσωματωμένη υποστήριξη αναπαραγωγής, οι άνθρωποι αναπαράγουν το ClickHouse με μη αυτόματο τρόπο.
Ποια είναι η αρχή; Έχετε έναν αγωγό επεξεργασίας δεδομένων. Και λειτουργεί ανεξάρτητα, για παράδειγμα, σε διαφορετικά κέντρα δεδομένων. Γράφετε τα ίδια δεδομένα με τον ίδιο τρόπο στο ClickHouse, όπως ήταν. Είναι αλήθεια ότι η πρακτική δείχνει ότι τα δεδομένα θα εξακολουθούν να αποκλίνουν λόγω κάποιων ιδιαιτεροτήτων στον κώδικά σας. Ελπίζω ότι στο δικό σου.
Και περιοδικά πρέπει ακόμα να συγχρονίζετε μη αυτόματα. Για παράδειγμα, μια φορά το μήνα οι διαχειριστές κάνουν rsync.
Στην πραγματικότητα, είναι πολύ πιο εύκολο να χρησιμοποιήσετε την ενσωματωμένη αναπαραγωγή στο ClickHouse. Αλλά μπορεί να υπάρχουν κάποιες αντενδείξεις, γιατί για αυτό πρέπει να χρησιμοποιήσετε το ZooKeeper. Δεν θα πω τίποτα κακό για το ZooKeeper, κατ 'αρχήν, το σύστημα λειτουργεί, αλλά συμβαίνει ότι οι άνθρωποι δεν το χρησιμοποιούν λόγω java-phobia, επειδή το ClickHouse είναι ένα τόσο καλό σύστημα γραμμένο σε C ++ που μπορείτε να χρησιμοποιήσετε και όλα θα πάνε καλά. Και ZooKeeper σε java. Και με κάποιο τρόπο δεν θέλετε καν να κοιτάξετε, αλλά μετά μπορείτε να χρησιμοποιήσετε τη μη αυτόματη αναπαραγωγή.
Το ClickHouse είναι ένα πρακτικό σύστημα. Λαμβάνει υπόψη τις ανάγκες σας. Εάν έχετε μη αυτόματη αναπαραγωγή, τότε μπορείτε να δημιουργήσετε έναν κατανεμημένο πίνακα που εξετάζει τα μη αυτόματα αντίγραφά σας και κάνει μια ανακατεύθυνση μεταξύ τους. Και υπάρχει ακόμη και μια ειδική επιλογή που σας επιτρέπει να αποφύγετε τα flops, ακόμα κι αν οι γραμμές σας αποκλίνουν συστηματικά.
Επιπλέον, μπορεί να υπάρχουν προβλήματα εάν χρησιμοποιείτε πρωτόγονους επιτραπέζιους κινητήρες. Το ClickHouse είναι ένας τέτοιος κατασκευαστής που έχει μια δέσμη διαφορετικών μηχανών πίνακα. Για όλες τις σοβαρές περιπτώσεις, όπως αναγράφεται στην τεκμηρίωση, χρησιμοποιήστε πίνακες της οικογένειας MergeTree. Και όλα τα υπόλοιπα - αυτό ισχύει για μεμονωμένες περιπτώσεις ή για δοκιμές.
Σε έναν πίνακα MergeTree, δεν χρειάζεται να έχετε ημερομηνία και ώρα. Μπορείτε ακόμα να χρησιμοποιήσετε. Εάν δεν υπάρχει ημερομηνία και ώρα, γράψτε ότι η προεπιλογή είναι 2000. Θα λειτουργήσει και δεν θα απαιτήσει πόρους.
Και στη νέα έκδοση του διακομιστή, μπορείτε ακόμη και να καθορίσετε ότι έχετε προσαρμοσμένη κατάτμηση χωρίς κλειδί κατάτμησης. Το ίδιο θα είναι.
Από την άλλη πλευρά, μπορούν να χρησιμοποιηθούν πρωτόγονοι επιτραπέζιοι κινητήρες. Για παράδειγμα, συμπληρώστε τα δεδομένα μία φορά και δείτε, στρίψτε και διαγράψτε. Μπορείτε να χρησιμοποιήσετε το αρχείο καταγραφής.
Ή αποθήκευση μικρών όγκων για ενδιάμεση επεξεργασία είναι το StripeLog ή το TinyLog.
Η μνήμη μπορεί να χρησιμοποιηθεί εάν υπάρχει μικρός όγκος δεδομένων και απλώς στρίψτε κάτι στη μνήμη RAM.
Στο ClickHouse δεν αρέσουν πολύ τα δεδομένα που έχουν εκ νέου κανονικοποιηθεί.
Ιδού ένα χαρακτηριστικό παράδειγμα. Αυτός είναι ένας τεράστιος αριθμός url. Τα βάζεις στο διπλανό τραπέζι. Και μετά αποφασίσαμε να κάνουμε ένα JOIN μαζί τους, αλλά αυτό δεν θα λειτουργήσει, κατά κανόνα, επειδή το ClickHouse υποστηρίζει μόνο Hash JOIN. Εάν δεν υπάρχει αρκετή μνήμη RAM για πολλά δεδομένα με τα οποία μπορείτε να συνδεθείτε, τότε το JOIN δεν θα λειτουργήσει *.
Εάν τα δεδομένα είναι υψηλής ταυτότητας, τότε μην ανησυχείτε, αποθηκεύστε τα σε αποκανονική μορφή, οι διευθύνσεις URL βρίσκονται απευθείας στον κύριο πίνακα.
* και τώρα το ClickHouse έχει επίσης μια σύνδεση συγχώνευσης και λειτουργεί σε συνθήκες όπου τα ενδιάμεσα δεδομένα δεν χωρούν στη μνήμη RAM. Αλλά αυτό είναι αναποτελεσματικό και η σύσταση παραμένει έγκυρη.
Κάποια ακόμη παραδείγματα, αλλά ήδη αμφιβάλλω αν είναι αντι-μοτίβα ή όχι.
Το ClickHouse έχει ένα γνωστό μειονέκτημα. Δεν ξέρει πώς να ενημερώσει *. Κατά μία έννοια, αυτό είναι ακόμη και καλό. Εάν έχετε κάποια σημαντικά δεδομένα, για παράδειγμα, λογιστικά, τότε κανείς δεν θα μπορεί να τα στείλει, γιατί δεν υπάρχουν ενημερώσεις.
* Η υποστήριξη για ενημέρωση και διαγραφή σε λειτουργία δέσμης έχει προστεθεί εδώ και καιρό.
Υπάρχουν όμως ορισμένοι ειδικοί τρόποι που επιτρέπουν την εμφάνιση ενημερώσεων στο παρασκήνιο. Για παράδειγμα, πίνακες τύπου ReplaceMergeTree. Κάνουν ενημερώσεις κατά τις συγχωνεύσεις φόντου. Μπορείτε να το εξαναγκάσετε με τον πίνακα βελτιστοποίησης. Αλλά μην το κάνετε πολύ συχνά, γιατί θα αντικαταστήσει πλήρως το διαμέρισμα.
Κατανεμημένες ΣΥΝΔΕΣΕΙΣ στο ClickHouse - και αυτό δεν αντιμετωπίζεται καλά από τον προγραμματιστή ερωτημάτων.
Κακό, αλλά μερικές φορές εντάξει.
Χρησιμοποιώντας το ClickHouse απλώς για να διαβάσετε ξανά δεδομένα με επιλογή*.
Δεν θα συνιστούσα τη χρήση του ClickHouse για ογκώδεις υπολογισμούς. Αλλά αυτό δεν είναι απολύτως αληθές, γιατί ήδη απομακρυνόμαστε από αυτήν τη σύσταση. Και πρόσφατα προσθέσαμε τη δυνατότητα εφαρμογής μοντέλων μηχανικής εκμάθησης στο ClickHouse - Catboost. Και με ανησυχεί, γιατί σκέφτομαι: «Τι φρίκη. Αυτός είναι πόσοι κύκλοι ανά byte βγαίνουν! Είναι κρίμα για μένα να ξεκινάω κύκλους ρολογιού σε byte.
Αλλά μην φοβάστε, εγκαταστήστε το ClickHouse, όλα θα πάνε καλά. Αν μη τι άλλο, έχουμε μια κοινότητα. Παρεμπιπτόντως, η κοινότητα είσαι εσύ. Και αν έχετε προβλήματα, μπορείτε τουλάχιστον να μεταβείτε στη συνομιλία μας και ελπίζω ότι θα βοηθηθείτε.
ερωτήσεις
Ευχαριστώ για την αναφορά! Πού να παραπονεθείτε για τη συντριβή του ClickHouse;
Μπορείτε να παραπονεθείτε σε εμένα προσωπικά αυτή τη στιγμή.
Πρόσφατα άρχισα να χρησιμοποιώ το ClickHouse. Αμέσως έπεσε η διεπαφή cli.
Είστε τυχεροί.
Λίγο αργότερα, άφησα τον διακομιστή με μια μικρή επιλογή.
Έχεις ταλέντο.
Άνοιξα ένα σφάλμα GitHub, αλλά αγνοήθηκε.
Θα δούμε.
Ο Aleksey με ξεγέλασε να παρευρεθώ στην έκθεση, υποσχόμενος να μου πει πώς συμπιέζεις τα δεδομένα μέσα.
Πολύ απλό.
Αυτό κατάλαβα χθες. Πιο συγκεκριμένα.
Δεν υπάρχουν τρομερά κόλπα. Είναι απλώς συμπίεση μπλοκ προς μπλοκ. Η προεπιλογή είναι LZ4, μπορείτε να ενεργοποιήσετε το ZSTD*. Μπλοκ από 64 kilobyte έως 1 megabyte.
* Υπάρχει επίσης υποστήριξη για εξειδικευμένους κωδικοποιητές συμπίεσης που μπορούν να χρησιμοποιηθούν σε αλυσίδα με άλλους αλγόριθμους.
Είναι τα μπλοκ απλώς ακατέργαστα δεδομένα;
Όχι ακριβώς ωμό. Υπάρχουν πίνακες. Εάν έχετε μια αριθμητική στήλη, τότε οι αριθμοί σε μια σειρά στοιβάζονται σε έναν πίνακα.
Είναι σαφές.
Alexey, ένα παράδειγμα που ήταν με το uniqExact μέσω IP, δηλαδή το γεγονός ότι το uniqExact χρειάζεται περισσότερο χρόνο για να μετρήσει με συμβολοσειρές παρά με αριθμούς, και ούτω καθεξής. Τι γίνεται αν εφαρμόσουμε μια προσποίηση με τα αυτιά μας και γύψο τη στιγμή της διόρθωσης; Δηλαδή φαίνεται ότι είπες ότι δεν διαφέρει πολύ στον δίσκο. Αν διαβάσουμε γραμμές από το δίσκο, χυτά, τότε θα έχουμε αδρανή πιο γρήγορα ή όχι; Ή μήπως ακόμα κερδίζουμε οριακά εδώ; Μου φαίνεται ότι το δοκιμάσατε, αλλά για κάποιο λόγο δεν το υποδείξατε στο σημείο αναφοράς.
Νομίζω ότι θα είναι πιο αργό από κανένα καστ. Σε αυτήν την περίπτωση, η διεύθυνση IP πρέπει να αναλυθεί από τη συμβολοσειρά. Φυσικά, στο ClickHouse, η ανάλυση διευθύνσεων IP είναι επίσης βελτιστοποιημένη. Προσπαθήσαμε πολύ σκληρά, αλλά στο ίδιο σημείο έχετε τους αριθμούς γραμμένους σε δέκα χιλιοστά μορφή. Πολύ άβολα. Από την άλλη πλευρά, η συνάρτηση uniqExact θα λειτουργεί πιο αργά στις συμβολοσειρές, όχι μόνο επειδή πρόκειται για συμβολοσειρές, αλλά και επειδή επιλέγεται μια διαφορετική εξειδίκευση του αλγορίθμου. Οι χορδές απλώς χειρίζονται διαφορετικά.
Και αν πάρουμε έναν πιο πρωτόγονο τύπο δεδομένων; Για παράδειγμα, έγραψαν το αναγνωριστικό χρήστη που έχουμε, το έγραψαν ως γραμμή και μετά το έριξαν, θα είναι πιο διασκεδαστικό ή όχι;
Αμφιβάλλω. Νομίζω ότι θα είναι ακόμα πιο λυπηρό, γιατί τελικά η ανάλυση των αριθμών είναι σοβαρό πρόβλημα. Μου φαίνεται ότι αυτός ο συνάδελφος είχε μια αναφορά για το πόσο δύσκολο είναι να αναλύεις αριθμούς σε δέκα χιλιοστά μορφή, αλλά ίσως όχι.
Alexey, ευχαριστώ πολύ για την αναφορά! Και σας ευχαριστώ πολύ για το ClickHouse! Έχω μια ερώτηση σχετικά με τα σχέδια. Υπάρχει δυνατότητα στα σχέδια για ελλιπή ενημέρωση λεξικών;
δηλαδή μερική επανεκκίνηση;
Ναι ναι. Όπως η δυνατότητα να ορίσετε ένα πεδίο MySQL εκεί, δηλαδή να ενημερώσετε μετά, ώστε να φορτώνονται μόνο αυτά τα δεδομένα εάν το λεξικό είναι πολύ μεγάλο.
Πολύ ενδιαφέρον χαρακτηριστικό. Και, μου φαίνεται, κάποιος το πρότεινε στη συνομιλία μας. Ίσως να ήσουν ακόμα και εσύ.
Δεν νομίζω.
Ωραία, τώρα αποδεικνύεται ότι δύο αιτήματα. Και μπορείτε να αρχίσετε να το κάνετε σιγά σιγά. Αλλά θέλω να σας προειδοποιήσω αμέσως ότι αυτή η δυνατότητα είναι αρκετά απλή στην εφαρμογή. Δηλαδή, θεωρητικά, χρειάζεται απλώς να γράψετε τον αριθμό έκδοσης στον πίνακα και στη συνέχεια να γράψετε: η έκδοση είναι μικρότερη από τέτοια και τέτοια. Και αυτό σημαίνει ότι, πιθανότατα, θα το προσφέρουμε στους ενθουσιώδεις. Είστε ενθουσιώδης;
Ναι, αλλά δυστυχώς όχι σε C++.
Μπορούν οι συνάδελφοί σας να γράφουν σε C++;
Θα βρω κάποιον.
Εξαιρετική*.
* η δυνατότητα προστέθηκε δύο μήνες μετά την αναφορά - αναπτύχθηκε από τον συντάκτη της ερώτησης και υποβλήθηκε από τον ίδιο .
Σας ευχαριστούμε!
Γειά σου! Ευχαριστώ για την αναφορά! Αναφέρατε ότι το ClickHouse καταναλώνει πολύ καλά όλους τους πόρους που διαθέτει. Και ο ομιλητής δίπλα στη Luxoft μίλησε για την απόφασή του για τη Russian Post. Είπε ότι τους άρεσε πολύ το ClickHouse, αλλά δεν το χρησιμοποίησαν αντί για τον κύριο ανταγωνιστή τους ακριβώς επειδή έφαγε ολόκληρο τον επεξεργαστή. Και δεν μπορούσαν να το χωρέσουν στην αρχιτεκτονική τους, στο ZooKeeper τους με λιμενεργάτες. Είναι δυνατόν να περιοριστεί με κάποιο τρόπο το ClickHouse ώστε να μην καταναλώνει ό,τι είναι διαθέσιμο σε αυτό;
Ναι, είναι δυνατό και πολύ εύκολο. Εάν θέλετε να καταναλώνετε λιγότερους πυρήνες, τότε απλώς γράψτε set max_threads = 1. Και αυτό είναι όλο, θα εκτελέσει το αίτημα σε έναν πυρήνα. Επιπλέον, μπορείτε να καθορίσετε διαφορετικές ρυθμίσεις για διαφορετικούς χρήστες. Άρα κανένα πρόβλημα. Και πείτε στους συναδέλφους σας από τη Luxoft ότι δεν είναι καλό που δεν βρήκαν αυτήν τη ρύθμιση στην τεκμηρίωση.
Alexey, γεια! Θα ήθελα να κάνω αυτή την ερώτηση. Δεν είναι η πρώτη φορά που ακούω ότι πολλοί άνθρωποι αρχίζουν να χρησιμοποιούν το ClickHouse ως χώρο αποθήκευσης αρχείων καταγραφής. Στο ρεπορτάζ είπατε να μην το κάνετε αυτό, δηλαδή δεν χρειάζεται να αποθηκεύσετε μεγάλες ουρές. Τι πιστεύετε γι 'αυτό;
Πρώτον, τα κούτσουρα συνήθως δεν είναι μεγάλες ουρές. Υπάρχουν βέβαια και εξαιρέσεις. Για παράδειγμα, κάποια υπηρεσία γραμμένη σε java ρίχνει μια εξαίρεση, καταγράφεται. Και έτσι σε έναν ατελείωτο βρόχο, και εξαντλείται ο χώρος του σκληρού δίσκου. Η λύση είναι πολύ απλή. Εάν οι γραμμές είναι πολύ μεγάλες, τότε κόψτε τις. Τι σημαίνει μακρύς; Δεκάδες kilobyte είναι κακό *.
* στις πρόσφατες εκδόσεις του ClickHouse, η "προσαρμοστική ευρεσιτεχνία ευρετηρίου" είναι ενεργοποιημένη, η οποία καταργεί το πρόβλημα της αποθήκευσης μεγάλων συμβολοσειρών ως επί το πλείστον.
Είναι φυσιολογικό ένα kilobyte;
Είναι φυσιολογικό.
Γειά σου! Ευχαριστώ για την αναφορά! Ρώτησα ήδη για αυτό στη συνομιλία, αλλά δεν θυμάμαι αν έλαβα απάντηση. Υπάρχει κάποιο σχέδιο επέκτασης του τμήματος WITH με τρόπο CTE;
Οχι ακόμα. Το τμήμα ΜΕ είναι κάπως επιπόλαιο. Είναι σαν ένα μικρό χαρακτηριστικό για εμάς.
Καταλαβαίνω. Ευχαριστώ!
Ευχαριστώ για την αναφορά! Πολύ ενδιαφέρον! παγκόσμιο ερώτημα. Σχεδιάζεται να γίνει, ίσως με τη μορφή κάποιου είδους stubs, τροποποίηση της διαγραφής δεδομένων;
Αναγκαίως. Αυτή είναι η πρώτη μας εργασία στην ουρά μας. Τώρα σκεφτόμαστε ενεργά πώς να κάνουμε τα πάντα σωστά. Και θα πρέπει να αρχίσετε να πατάτε το πληκτρολόγιο*.
* πάτησε τα κουμπιά στο πληκτρολόγιο και όλα έγιναν.
Θα επηρεάσει κατά κάποιο τρόπο την απόδοση του συστήματος ή όχι; Το ένθετο θα είναι τόσο γρήγορο όσο είναι τώρα;
Ίσως οι ίδιες οι διαγραφές, οι ίδιες οι ενημερώσεις να είναι πολύ βαριές, αλλά αυτό δεν θα επηρεάσει την απόδοση των επιλογών και την απόδοση των ενθέτων με κανέναν τρόπο.
Και μια ακόμη μικρή ερώτηση. Στην παρουσίαση μιλήσατε για το πρωτεύον κλειδί. Αντίστοιχα, έχουμε κατάτμηση, η οποία είναι μηνιαία από προεπιλογή, σωστά; Και όταν ορίζουμε ένα εύρος ημερομηνιών που χωράει σε ένα μήνα, τότε διαβάζουμε μόνο αυτό το διαμέρισμα, σωστά;
Ναι.
Μια ερώτηση. Εάν δεν μπορούμε να επιλέξουμε κανένα πρωτεύον κλειδί, τότε είναι σωστό να το κάνουμε ακριβώς από το πεδίο «Ημερομηνία» ώστε στο παρασκήνιο να υπάρχει μικρότερη αναδιάρθρωση αυτών των δεδομένων ώστε να χωρούν με πιο τακτικό τρόπο; Εάν δεν έχετε ερωτήματα εύρους και δεν μπορείτε καν να επιλέξετε κάποιο πρωτεύον κλειδί, αξίζει να βάλετε μια ημερομηνία στο πρωτεύον κλειδί;
Ναι.
Ίσως είναι λογικό να βάλουμε στο πρωτεύον κλειδί ένα πεδίο με το οποίο τα δεδομένα θα συμπιέζονται καλύτερα εάν ταξινομηθούν με αυτό το πεδίο. Για παράδειγμα, αναγνωριστικό χρήστη. Ο χρήστης, για παράδειγμα, πηγαίνει στον ίδιο ιστότοπο. Σε αυτήν την περίπτωση, βάλτε το αναγνωριστικό χρήστη και την ώρα. Και τότε τα δεδομένα σας θα συμπιεστούν καλύτερα. Όσον αφορά την ημερομηνία, εάν πραγματικά δεν έχετε και δεν έχετε ποτέ ερωτήματα εύρους για ημερομηνίες, τότε δεν μπορείτε να βάλετε την ημερομηνία στο πρωτεύον κλειδί.
Εντάξει, σας ευχαριστώ πολύ!
Πηγή: www.habr.com