Τα τελευταία χρόνια, οι βάσεις δεδομένων χρονοσειρών έχουν μετατραπεί από ένα περίεργο πράγμα (υψηλά εξειδικευμένο που χρησιμοποιείται είτε σε ανοιχτά συστήματα παρακολούθησης (και συνδέονται με συγκεκριμένες λύσεις) είτε σε έργα Big Data) σε «καταναλωτικό προϊόν». Στην επικράτεια της Ρωσικής Ομοσπονδίας, πρέπει να δοθούν ιδιαίτερες ευχαριστίες στη Yandex και στο ClickHouse για αυτό. Μέχρι αυτό το σημείο, εάν χρειαζόταν να αποθηκεύσετε μεγάλο όγκο δεδομένων χρονοσειρών, έπρεπε είτε να συμβιβαστείτε με την ανάγκη να δημιουργήσετε μια τερατώδη στοίβα Hadoop και να τη διατηρήσετε, είτε να επικοινωνήσετε με πρωτόκολλα μεμονωμένα για κάθε σύστημα.
Μπορεί να φαίνεται ότι το 2019 ένα άρθρο για το οποίο αξίζει να χρησιμοποιηθεί το TSDB θα αποτελείται από μία μόνο πρόταση: «απλώς χρησιμοποιήστε το ClickHouse». Αλλά... υπάρχουν αποχρώσεις.
Πράγματι, το ClickHouse αναπτύσσεται ενεργά, η βάση των χρηστών αυξάνεται και η υποστήριξη είναι πολύ ενεργή, αλλά έχουμε γίνει όμηροι της δημόσιας επιτυχίας του ClickHouse, η οποία έχει επισκιάσει άλλες, ίσως πιο αποτελεσματικές/αξιόπιστες λύσεις;
Στις αρχές του περασμένου έτους, ξεκινήσαμε να επεξεργαζόμαστε εκ νέου το δικό μας σύστημα παρακολούθησης, κατά το οποίο προέκυψε το ζήτημα της επιλογής μιας κατάλληλης βάσης δεδομένων για την αποθήκευση δεδομένων. Θέλω να μιλήσω για την ιστορία αυτής της επιλογής εδώ.
Δήλωση προβλήματος
Πρώτα απ' όλα ένας απαραίτητος πρόλογος. Γιατί χρειαζόμαστε καθόλου το δικό μας σύστημα παρακολούθησης και πώς σχεδιάστηκε;
Ξεκινήσαμε να παρέχουμε υπηρεσίες υποστήριξης το 2008 και μέχρι το 2010 έγινε σαφές ότι ήταν δύσκολο να συγκεντρωθούν δεδομένα σχετικά με τις διεργασίες που συνέβαιναν στην υποδομή πελατών με τις λύσεις που υπήρχαν εκείνη την εποχή (μιλάμε για, Θεέ μου, Cacti, Zabbix και ο αναδυόμενος Γραφίτης).
Οι βασικές απαιτήσεις μας ήταν:
- υποστήριξη (εκείνη την εποχή - δεκάδες, και στο μέλλον - εκατοντάδες) πελατών σε ένα σύστημα και ταυτόχρονα την παρουσία ενός κεντρικού συστήματος διαχείρισης ειδοποιήσεων.
- ευελιξία στη διαχείριση του συστήματος προειδοποίησης (κλιμάκωση ειδοποιήσεων μεταξύ αξιωματικών υπηρεσίας, προγραμματισμός, βάση γνώσεων)·
- την ικανότητα λεπτομερούς λεπτομέρειας γραφημάτων (ο Zabbix εκείνη την εποχή απέδιδε γραφήματα με τη μορφή εικόνων).
- μακροχρόνια αποθήκευση μεγάλου όγκου δεδομένων (ένα έτος ή περισσότερο) και δυνατότητα γρήγορης ανάκτησής τους.
Σε αυτό το άρθρο μας ενδιαφέρει το τελευταίο σημείο.
Μιλώντας για αποθήκευση, οι απαιτήσεις ήταν οι εξής:
- το σύστημα πρέπει να λειτουργεί γρήγορα.
- είναι επιθυμητό το σύστημα να έχει διεπαφή SQL.
- το σύστημα πρέπει να είναι σταθερό και να έχει ενεργή βάση χρηστών και υποστήριξη (κάποτε αντιμετωπίσαμε την ανάγκη υποστήριξης συστημάτων όπως το MemcacheDB, το οποίο δεν αναπτύχθηκε πλέον ή ο κατανεμημένος χώρος αποθήκευσης MooseFS, ο εντοπισμός σφαλμάτων του οποίου διατηρήθηκε στα κινέζικα: επαναλαμβάνουμε αυτή την ιστορία για το έργο μας δεν ήθελε)?
- συμμόρφωση με το θεώρημα της ΚΓΠ: Συνέπεια (απαιτείται) - τα δεδομένα πρέπει να είναι ενημερωμένα, δεν θέλουμε το σύστημα διαχείρισης ειδοποιήσεων να μην λαμβάνει νέα δεδομένα και να μην λαμβάνει ειδοποιήσεις σχετικά με τη μη άφιξη δεδομένων για όλα τα έργα. Ανοχή κατάτμησης (απαιτείται) - δεν θέλουμε να αποκτήσουμε σύστημα Split Brain. Διαθεσιμότητα (όχι κρίσιμη, εάν υπάρχει ενεργό αντίγραφο) - μπορούμε να μεταβούμε στο εφεδρικό σύστημα μόνοι μας σε περίπτωση ατυχήματος, χρησιμοποιώντας κωδικό.
Παραδόξως, εκείνη την εποχή η MySQL αποδείχθηκε η ιδανική λύση για εμάς. Η δομή των δεδομένων μας ήταν εξαιρετικά απλή: αναγνωριστικό διακομιστή, αναγνωριστικό μετρητή, χρονική σήμανση και τιμή. Η γρήγορη δειγματοληψία των θερμών δεδομένων εξασφαλίστηκε από μια μεγάλη δεξαμενή προσωρινής αποθήκευσης και η δειγματοληψία ιστορικών δεδομένων εξασφαλίστηκε από το SSD.
Έτσι, επιτύχαμε ένα δείγμα φρέσκων δεδομένων δύο εβδομάδων, με λεπτομέρεια έως και 200 ms πριν από την πλήρη απόδοση των δεδομένων και ζήσαμε σε αυτό το σύστημα για αρκετό καιρό.
Εν τω μεταξύ, ο χρόνος πέρασε και ο όγκος των δεδομένων αυξήθηκε. Μέχρι το 2016, οι όγκοι δεδομένων έφτασαν τα δεκάδες terabyte, κάτι που ήταν σημαντικό κόστος στο πλαίσιο της ενοικιαζόμενης αποθήκευσης SSD.
Μέχρι εκείνη τη στιγμή, οι στηλώδεις βάσεις δεδομένων είχαν γίνει ευρέως διαδεδομένες, τις οποίες αρχίσαμε να σκεφτόμαστε ενεργά: στις στηλώδεις βάσεις δεδομένων, τα δεδομένα αποθηκεύονται, όπως καταλαβαίνετε, σε στήλες, και αν κοιτάξετε τα δεδομένα μας, είναι εύκολο να δείτε ένα μεγάλο αριθμός των διπλότυπων που θα μπορούσαν, στο Εάν χρησιμοποιείτε μια βάση δεδομένων στηλών, να τη συμπιέσετε χρησιμοποιώντας συμπίεση.
Ωστόσο, το βασικό σύστημα της εταιρείας συνέχισε να λειτουργεί σταθερά και δεν ήθελα να πειραματιστώ με τη μετάβαση σε κάτι άλλο.
Το 2017, στο συνέδριο Percona Live στο Σαν Χοσέ, οι προγραμματιστές του Clickhouse πιθανότατα ανακοίνωσαν τον εαυτό τους για πρώτη φορά. Με την πρώτη ματιά, το σύστημα ήταν έτοιμο για παραγωγή (καλά, το Yandex.Metrica είναι ένα σκληρό σύστημα παραγωγής), η υποστήριξη ήταν γρήγορη και απλή και, το πιο σημαντικό, η λειτουργία ήταν απλή. Από το 2018 έχουμε ξεκινήσει τη διαδικασία μετάβασης. Αλλά μέχρι τότε, υπήρχαν πολλά συστήματα TSDB «ενήλικες» και δοκιμασμένα στο χρόνο και αποφασίσαμε να αφιερώσουμε σημαντικό χρόνο και να συγκρίνουμε εναλλακτικές για να βεβαιωθούμε ότι δεν υπήρχαν εναλλακτικές λύσεις στο Clickhouse, σύμφωνα με τις απαιτήσεις μας.
Εκτός από τις ήδη καθορισμένες απαιτήσεις αποθήκευσης, έχουν εμφανιστεί νέες:
- το νέο σύστημα θα πρέπει να παρέχει τουλάχιστον την ίδια απόδοση με την MySQL στον ίδιο όγκο υλικού.
- Η αποθήκευση του νέου συστήματος θα πρέπει να καταλαμβάνει πολύ λιγότερο χώρο.
- Το DBMS πρέπει να είναι ακόμα εύκολο στη διαχείριση.
- Ήθελα να αλλάξω την εφαρμογή ελάχιστα κατά την αλλαγή του DBMS.
Ποια συστήματα αρχίσαμε να εξετάζουμε;
Apache Hive/Apache Impala
Μια παλιά, δοκιμασμένη στη μάχη Hadoop στοίβα. Ουσιαστικά, είναι μια διεπαφή SQL που βασίζεται στην αποθήκευση δεδομένων σε εγγενείς μορφές σε HDFS.
Πλεονεκτήματα.
- Με σταθερή λειτουργία, είναι πολύ εύκολη η κλίμακα δεδομένων.
- Υπάρχουν λύσεις στηλών για αποθήκευση δεδομένων (λιγότερος χώρος).
- Πολύ γρήγορη εκτέλεση παράλληλων εργασιών όταν υπάρχουν διαθέσιμοι πόροι.
Μειονεκτήματα
- Είναι Hadoop και είναι δύσκολο στη χρήση. Εάν δεν είμαστε έτοιμοι να πάρουμε μια έτοιμη λύση στο cloud (και δεν είμαστε έτοιμοι από άποψη κόστους), ολόκληρη η στοίβα θα πρέπει να συναρμολογηθεί και να υποστηριχθεί από τα χέρια των διαχειριστών και πραγματικά δεν θέλουμε Αυτό.
- Τα δεδομένα συγκεντρώνονται .
Ωστόσο:
Η ταχύτητα επιτυγχάνεται με την κλιμάκωση του αριθμού των υπολογιστικών διακομιστών. Με απλά λόγια, εάν είμαστε μια μεγάλη εταιρεία, που ασχολείται με την ανάλυση και είναι σημαντικό για την επιχείρηση να συγκεντρώνει πληροφορίες όσο το δυνατόν γρηγορότερα (ακόμη και με το κόστος της χρήσης μεγάλου όγκου υπολογιστικών πόρων), αυτή μπορεί να είναι η επιλογή μας. Αλλά δεν ήμασταν έτοιμοι να πολλαπλασιάσουμε τον στόλο υλικού για να επιταχύνουμε τις εργασίες.
Druid/Pinot
Υπάρχουν πολλά περισσότερα για το TSDB συγκεκριμένα, αλλά και πάλι, η στοίβα Hadoop.
Υπάρχει .
Με λίγα λόγια: Το Druid/Pinot φαίνονται καλύτερα από το Clickhouse σε περιπτώσεις όπου:
- Έχετε μια ετερογενή φύση δεδομένων (στην περίπτωσή μας, καταγράφουμε μόνο χρονοσειρές μετρήσεων διακομιστή και, στην πραγματικότητα, αυτός είναι ένας πίνακας. Αλλά μπορεί να υπάρχουν και άλλες περιπτώσεις: χρονοσειρές εξοπλισμού, οικονομικές χρονοσειρές κ.λπ. - η καθεμία με τη δική του δομή, η οποία πρέπει να συγκεντρωθεί και να υποβληθεί σε επεξεργασία).
- Επιπλέον, υπάρχουν πολλά από αυτά τα δεδομένα.
- Εμφανίζονται και εξαφανίζονται πίνακες και δεδομένα με χρονοσειρές (δηλαδή, κάποιο σύνολο δεδομένων έφτασε, αναλύθηκε και διαγράφηκε).
- Δεν υπάρχει σαφές κριτήριο με το οποίο μπορούν να χωριστούν τα δεδομένα.
Σε αντίθετες περιπτώσεις, το ClickHouse αποδίδει καλύτερα και αυτή είναι η περίπτωσή μας.
Κάντε κλικ στο σπίτι
- SQL-όπως
- Εύκολο στη διαχείριση.
- Ο κόσμος λέει ότι λειτουργεί.
Επιλέγεται για δοκιμή.
InfluxDB
Μια ξένη εναλλακτική στο ClickHouse. Από τα μειονεκτήματα: Η υψηλή διαθεσιμότητα υπάρχει μόνο στην εμπορική έκδοση, αλλά πρέπει να συγκριθεί.
Επιλέγεται για δοκιμή.
Κασσάνδρα
Από τη μία πλευρά, γνωρίζουμε ότι χρησιμοποιείται για την αποθήκευση μετρικών χρονοσειρών από συστήματα παρακολούθησης όπως, για παράδειγμα, ή OkMeter. Ωστόσο, υπάρχουν συγκεκριμένες λεπτομέρειες.
Η Κασσάνδρα δεν είναι μια στήλη βάσης δεδομένων με την παραδοσιακή έννοια. Μοιάζει περισσότερο με προβολή γραμμής, αλλά κάθε γραμμή μπορεί να έχει διαφορετικό αριθμό στηλών, γεγονός που καθιστά εύκολη την οργάνωση μιας προβολής στηλών. Υπό αυτή την έννοια, είναι σαφές ότι με ένα όριο 2 δισεκατομμυρίων στηλών, είναι δυνατή η αποθήκευση ορισμένων δεδομένων σε στήλες (και τις ίδιες χρονοσειρές). Για παράδειγμα, στη MySQL υπάρχει όριο 4096 στηλών και είναι εύκολο να πέσει πάνω σε ένα σφάλμα με τον κωδικό 1117 αν προσπαθήσετε να κάνετε το ίδιο.
Ο κινητήρας Cassandra επικεντρώνεται στην αποθήκευση μεγάλων ποσοτήτων δεδομένων σε ένα κατανεμημένο σύστημα χωρίς κύριο, και το προαναφερθέν θεώρημα Cassandra CAP αφορά περισσότερο το AP, δηλαδή τη διαθεσιμότητα δεδομένων και την αντίσταση στην κατάτμηση. Έτσι, αυτό το εργαλείο μπορεί να είναι εξαιρετικό εάν χρειάζεται μόνο να γράψετε σε αυτήν τη βάση δεδομένων και σπάνια να διαβάσετε από αυτήν. Και εδώ είναι λογικό να χρησιμοποιείται η Κασσάνδρα ως «ψυχρή» αποθήκευση. Δηλαδή, ως ένα μακροπρόθεσμο, αξιόπιστο μέρος για την αποθήκευση μεγάλων ποσοτήτων ιστορικών δεδομένων που σπάνια χρειάζονται, αλλά μπορούν να ανακτηθούν εάν είναι απαραίτητο. Ωστόσο, για λόγους πληρότητας, θα το δοκιμάσουμε κι εμείς. Αλλά, όπως είπα νωρίτερα, δεν υπάρχει καμία επιθυμία να ξαναγράψουμε ενεργά τον κώδικα για την επιλεγμένη λύση βάσης δεδομένων, επομένως θα το δοκιμάσουμε κάπως περιορισμένα - χωρίς να προσαρμόσουμε τη δομή της βάσης δεδομένων στις ιδιαιτερότητες της Κασσάνδρας.
Προμηθέας
Λοιπόν, από περιέργεια, αποφασίσαμε να δοκιμάσουμε την απόδοση της αποθήκευσης Prometheus - απλώς για να καταλάβουμε αν είμαστε πιο γρήγοροι ή πιο αργοί από τις τρέχουσες λύσεις και κατά πόσο.
Μεθοδολογία και αποτελέσματα δοκιμών
Έτσι, δοκιμάσαμε 5 βάσεις δεδομένων στις ακόλουθες 6 διαμορφώσεις: ClickHouse (1 κόμβος), ClickHouse (κατανεμημένος πίνακας για 3 κόμβους), InfluxDB, Mysql 8, Cassandra (3 κόμβοι) και Prometheus. Το σχέδιο δοκιμής έχει ως εξής:
- ανεβάστε ιστορικά δεδομένα για μια εβδομάδα (840 εκατομμύρια τιμές ανά ημέρα, 208 χιλιάδες μετρήσεις).
- δημιουργούμε ένα φορτίο εγγραφής (εξετάστηκαν 6 τρόποι φόρτωσης, βλέπε παρακάτω).
- Παράλληλα με την εγγραφή, κάνουμε περιοδικά επιλογές, μιμούμενοι τα αιτήματα ενός χρήστη που εργάζεται με γραφήματα. Για να μην περιπλέκουμε πολύ τα πράγματα, επιλέξαμε δεδομένα για 10 μετρήσεις (τόσες ακριβώς υπάρχουν στο γράφημα της CPU) για μια εβδομάδα.
Φορτώνουμε προσομοιώνοντας τη συμπεριφορά του παράγοντα παρακολούθησης, ο οποίος στέλνει τιμές σε κάθε μέτρηση μία φορά κάθε 15 δευτερόλεπτα. Ταυτόχρονα, μας ενδιαφέρει να διαφοροποιήσουμε:
- ο συνολικός αριθμός μετρήσεων στις οποίες εγγράφονται τα δεδομένα·
- διάστημα για την αποστολή τιμών σε μία μέτρηση.
- μέγεθος παρτίδας.
Σχετικά με το μέγεθος της παρτίδας. Δεδομένου ότι δεν συνιστάται η φόρτωση σχεδόν όλων των πειραματικών βάσεων δεδομένων μας με μεμονωμένα ένθετα, θα χρειαστούμε ένα ρελέ που συλλέγει εισερχόμενες μετρήσεις και τις ομαδοποιεί σε ομάδες και τις γράφει στη βάση δεδομένων ως ένθετο παρτίδας.
Επίσης, για να κατανοήσουμε καλύτερα πώς να ερμηνεύσουμε στη συνέχεια τα δεδομένα που λαμβάνονται, ας φανταστούμε ότι δεν στέλνουμε απλώς μια δέσμη μετρήσεων, αλλά οι μετρήσεις οργανώνονται σε διακομιστές - 125 μετρήσεις ανά διακομιστή. Εδώ ο διακομιστής είναι απλώς μια εικονική οντότητα - απλώς για να καταλάβουμε ότι, για παράδειγμα, 10000 μετρήσεις αντιστοιχούν σε περίπου 80 διακομιστές.
Και εδώ, λαμβάνοντας όλα αυτά υπόψη, είναι οι 6 τρόποι φόρτωσης εγγραφής της βάσης δεδομένων μας:
Εδώ υπάρχουν δύο σημεία. Πρώτον, για την Κασσάνδρα αυτά τα μεγέθη παρτίδων αποδείχθηκαν πολύ μεγάλα, εκεί χρησιμοποιήσαμε τιμές 50 ή 100. Και δεύτερον, αφού ο Προμηθέας λειτουργεί αυστηρά σε λειτουργία έλξης, δηλ. Το ίδιο πηγαίνει και συλλέγει δεδομένα από πηγές μετρήσεων (και ακόμη και το pushgateway, παρά το όνομα, δεν αλλάζει ριζικά την κατάσταση), τα αντίστοιχα φορτία υλοποιήθηκαν χρησιμοποιώντας έναν συνδυασμό στατικών ρυθμίσεων.
Τα αποτελέσματα των δοκιμών είναι τα εξής:
Τι αξίζει να σημειωθεί: φανταστικά γρήγορα δείγματα από τον Προμηθέα, τρομερά αργά δείγματα από την Κασσάνδρα, απαράδεκτα αργά δείγματα από το InfluxDB. Όσον αφορά την ταχύτητα εγγραφής, το ClickHouse κέρδισε τους πάντες και ο Προμηθέας δεν συμμετέχει στον διαγωνισμό, γιατί φτιάχνει μόνος του ένθετα και δεν μετράμε τίποτα.
Ως αποτέλεσμα,: Οι ClickHouse και InfluxDB έδειξαν ότι είναι οι καλύτεροι, αλλά ένα cluster από το Influx μπορεί να δημιουργηθεί μόνο με βάση την έκδοση Enterprise, η οποία κοστίζει χρήματα, ενώ το ClickHouse δεν κοστίζει τίποτα και κατασκευάζεται στη Ρωσία. Είναι λογικό ότι στις ΗΠΑ η επιλογή είναι μάλλον υπέρ του inInfluxDB και στη χώρα μας υπέρ του ClickHouse.
Πηγή: www.habr.com