Χαιρετισμούς, habr.
Αν κάποιος εκμεταλλευτεί το σύστημα και αντιμετώπισε πρόβλημα απόδοσης αποθήκευσης (IO, καταναλώνεται χώρος στο δίσκο), τότε η πιθανότητα να μεταφερθεί το ClickHouse ως αντικατάσταση θα πρέπει να τείνει σε μία. Αυτή η δήλωση υποδηλώνει ότι μια υλοποίηση τρίτου μέρους χρησιμοποιείται ήδη ως μετρήσεις λήψης δαίμονα, για παράδειγμα ή .
Το ClickHouse επιλύει καλά τα προβλήματα που περιγράφονται. Για παράδειγμα, μετά τη μεταφορά 2TiB δεδομένων από το whisper, χωρούν σε 300GiB. Δεν θα σταθώ στη σύγκριση λεπτομερώς· υπάρχουν πολλά άρθρα για αυτό το θέμα. Επιπλέον, μέχρι πρόσφατα, δεν ήταν όλα τέλεια με τον αποθηκευτικό χώρο ClickHouse.
Προβλήματα με τον καταναλωμένο χώρο
Με την πρώτη ματιά, όλα πρέπει να λειτουργούν καλά. ΕΠΟΜΕΝΟ , δημιουργήστε μια διαμόρφωση για το σχήμα αποθήκευσης μετρήσεων (περαιτέρω retention), στη συνέχεια δημιουργήστε έναν πίνακα σύμφωνα με τη σύσταση του επιλεγμένου backend για graphite-web: + ή , ανάλογα με το ποια στοίβα χρησιμοποιείται. Και... σκάει η ωρολογιακή βόμβα.
Για να καταλάβετε ποιο, πρέπει να γνωρίζετε πώς λειτουργούν τα ένθετα και την περαιτέρω διαδρομή ζωής των δεδομένων σε πίνακες κινητήρων της οικογένειας *MergeTree ClickHouse (γραφήματα που λαμβάνονται από Alexey Zatelepin):
- Έγινε εισαγωγή
блокδεδομένα. Στην περίπτωσή μας, ήταν οι μετρήσεις που έφτασαν.
- Κάθε τέτοιο μπλοκ ταξινομείται σύμφωνα με το κλειδί πριν εγγραφεί στο δίσκο.
ORDER BYκαθορίζεται κατά τη δημιουργία του πίνακα. - Μετά την ταξινόμηση,
кусок(part) τα δεδομένα εγγράφονται στο δίσκο.
- Ο διακομιστής παρακολουθεί στο παρασκήνιο ώστε να μην υπάρχουν πολλά τέτοια κομμάτια και εκκινεί το φόντο
слияния(merge, εφεξής συγχώνευση).
- Ο διακομιστής σταματά να εκτελείται συγχωνεύσεις από μόνος του μόλις σταματήσουν να ρέουν ενεργά δεδομένα στο
партицию(partition), αλλά μπορείτε να ξεκινήσετε τη διαδικασία χειροκίνητα με την εντολήOPTIMIZE. - Εάν έχει απομείνει μόνο ένα κομμάτι στο διαμέρισμα, τότε δεν θα μπορείτε να εκτελέσετε τη συγχώνευση χρησιμοποιώντας τη συνηθισμένη εντολή, πρέπει να χρησιμοποιήσετε
OPTIMIZE ... FINAL
Έτσι, φτάνουν οι πρώτες μετρήσεις. Και πιάνουν λίγο χώρο. Τα επόμενα γεγονότα μπορεί να διαφέρουν κάπως ανάλογα με πολλούς παράγοντες:
- Το κλειδί κατάτμησης μπορεί να είναι είτε πολύ μικρό (μια ημέρα) είτε πολύ μεγάλο (μερικούς μήνες).
- Η διαμόρφωση διατήρησης μπορεί να ταιριάζει σε πολλά σημαντικά όρια συγκέντρωσης δεδομένων εντός του ενεργού διαμερίσματος (όπου καταγράφονται οι μετρήσεις) ή ίσως όχι.
- Εάν υπάρχουν πολλά δεδομένα, τότε τα πρώτα κομμάτια, τα οποία λόγω της συγχώνευσης φόντου μπορεί να είναι ήδη τεράστια (αν επιλέξετε ένα μη βέλτιστο κλειδί κατάτμησης), δεν θα συγχωνευθούν με νέα μικρά κομμάτια.
Και τελειώνει πάντα το ίδιο. Ο χώρος που καταλαμβάνουν οι μετρήσεις στο ClickHouse αυξάνεται μόνο εάν:
- δεν ισχύουν
OPTIMIZE ... FINALχειροκίνητα ή - μην εισάγετε δεδομένα σε όλα τα διαμερίσματα σε συνεχή βάση, έτσι ώστε αργά ή γρήγορα να ξεκινήσει μια συγχώνευση φόντου
Η δεύτερη μέθοδος φαίνεται να είναι η πιο εύκολη στην εφαρμογή και, ως εκ τούτου, είναι εσφαλμένη και δοκιμάστηκε πρώτη.
Έγραψα ένα αρκετά απλό σενάριο python που έστελνε ψευδείς μετρήσεις για κάθε μέρα τα τελευταία 4 χρόνια και έτρεχε το cron κάθε ώρα.
Δεδομένου ότι ολόκληρη η λειτουργία του ClickHouse DBMS βασίζεται στο γεγονός ότι αυτό το σύστημα αργά ή γρήγορα θα κάνει όλη την εργασία στο παρασκήνιο, αλλά δεν είναι γνωστό πότε, δεν μπορούσα να περιμένω τη στιγμή που τα παλιά τεράστια κομμάτια θα αρχίσουν να συγχωνεύονται με νέα μικρά. Έγινε σαφές ότι έπρεπε να αναζητήσουμε έναν τρόπο αυτοματοποίησης των αναγκαστικών βελτιστοποιήσεων.
Πληροφορίες στους πίνακες συστήματος ClickHouse
Ας ρίξουμε μια ματιά στη δομή του πίνακα . Αυτές είναι περιεκτικές πληροφορίες για κάθε κομμάτι όλων των πινάκων στον διακομιστή ClickHouse. Περιλαμβάνει, μεταξύ άλλων, τις ακόλουθες στήλες:
- όνομα db (
database); - όνομα πίνακα (
table); - όνομα διαμερίσματος και αναγνωριστικό (
partition&partition_id); - όταν δημιουργήθηκε το κομμάτι (
modification_time); - ελάχιστη και μέγιστη ημερομηνία σε ένα κομμάτι (ο διαχωρισμός γίνεται ανά ημέρα) (
min_date&max_date);
Υπάρχει επίσης ένα τραπέζι , με τα ακόλουθα ενδιαφέροντα πεδία:
- όνομα db (
Tables.database); - όνομα πίνακα (
Tables.table); - μετρική ηλικία όταν πρέπει να εφαρμοστεί η επόμενη συγκέντρωση (
age);
Έτσι:
- Έχουμε έναν πίνακα με κομμάτια και έναν πίνακα με κανόνες συγκέντρωσης.
- Συνδυάζουμε την τομή τους και παίρνουμε όλους τους πίνακες *GraphiteMergeTree.
- Αναζητούμε όλα τα διαμερίσματα στα οποία:
- περισσότερα από ένα κομμάτια
- ή ήρθε η ώρα να εφαρμοστεί ο επόμενος κανόνας συγκέντρωσης, και
modification_timeπιο παλιά από αυτή τη στιγμή.
Реализация
Αυτό το αίτημα
SELECT
concat(p.database, '.', p.table) AS table,
p.partition_id AS partition_id,
p.partition AS partition,
-- Самое "старое" правило, которое может быть применено для
-- партиции, но не в будущем, см (*)
max(g.age) AS age,
-- Количество кусков в партиции
countDistinct(p.name) AS parts,
-- За самую старшую метрику в партиции принимается 00:00:00 следующего дня
toDateTime(max(p.max_date + 1)) AS max_time,
-- Когда партиция должна быть оптимизированна
max_time + age AS rollup_time,
-- Когда самый старый кусок в партиции был обновлён
min(p.modification_time) AS modified_at
FROM system.parts AS p
INNER JOIN
(
-- Все правила для всех таблиц *GraphiteMergeTree
SELECT
Tables.database AS database,
Tables.table AS table,
age
FROM system.graphite_retentions
ARRAY JOIN Tables
GROUP BY
database,
table,
age
) AS g ON
(p.table = g.table)
AND (p.database = g.database)
WHERE
-- Только активные куски
p.active
-- (*) И только строки, где правила аггрегации уже должны быть применены
AND ((toDateTime(p.max_date + 1) + g.age) < now())
GROUP BY
table,
partition
HAVING
-- Только партиции, которые младше момента оптимизации
(modified_at < rollup_time)
-- Или с несколькими кусками
OR (parts > 1)
ORDER BY
table ASC,
partition ASC,
age ASCεπιστρέφει καθένα από τα διαμερίσματα του πίνακα *GraphiteMergeTree των οποίων η συγχώνευση θα απελευθερώσει χώρο στο δίσκο. Το μόνο που μένει είναι να τα περάσετε όλα με ένα αίτημα OPTIMIZE ... FINAL. Η τελική υλοποίηση λαμβάνει επίσης υπόψη το γεγονός ότι δεν χρειάζεται να αγγίξετε διαμερίσματα με ενεργή εγγραφή.
Αυτό ακριβώς κάνει το έργο . Πρώην συνάδελφοι από το Yandex.Market το δοκίμασαν στην παραγωγή, το αποτέλεσμα της εργασίας φαίνεται παρακάτω.
Εάν εκτελείτε το πρόγραμμα σε διακομιστή με ClickHouse, απλά θα αρχίσει να λειτουργεί σε λειτουργία δαίμονα. Μία φορά την ώρα θα εκτελείται ένα αίτημα, ελέγχοντας εάν έχουν εμφανιστεί νέα διαμερίσματα παλαιότερα των τριών ημερών που μπορούν να βελτιστοποιηθούν.
Τα άμεσα σχέδιά μας είναι να παρέχουμε τουλάχιστον πακέτα deb, και αν είναι δυνατόν και rpm.
Αντί για ένα συμπέρασμα
Τους τελευταίους 9+ μήνες βρίσκομαι στην εταιρεία μου ξόδεψε πολύ χρόνο μπερδεύοντας στη διασταύρωση του ClickHouse και του graphite-web. Ήταν μια καλή εμπειρία, η οποία είχε ως αποτέλεσμα μια γρήγορη μετάβαση από το whisper στο ClickHouse ως αποθήκευση μετρήσεων. Ελπίζω αυτό το άρθρο να είναι κάτι σαν την αρχή μιας σειράς σχετικά με τις βελτιώσεις που έχουμε κάνει σε διάφορα μέρη αυτής της στοίβας και τι θα γίνει στο μέλλον.
Πολλά λίτρα μπύρας και ημέρες διαχείρισης δαπανήθηκαν για την ανάπτυξη του αιτήματος, μαζί με , για το οποίο θέλω να του εκφράσω την ευγνωμοσύνη μου. Και επίσης για την αναθεώρηση αυτού του άρθρου.
Πηγή: www.habr.com