Θα δούμε πώς λειτουργεί το Zabbix με τη βάση δεδομένων TimescaleDB ως backend. Θα σας δείξουμε πώς να ξεκινήσετε από το μηδέν και πώς να κάνετε μετεγκατάσταση από την PostgreSQL. Θα παρέχουμε επίσης συγκριτικά τεστ απόδοσης των δύο διαμορφώσεων.
HighLoad++ Siberia 2019. Tomsk Hall. 24 Ιουνίου, 16:00. Διατριβές και . Το επόμενο συνέδριο HighLoad++ θα πραγματοποιηθεί στις 6 και 7 Απριλίου 2020 στην Αγία Πετρούπολη. Λεπτομέρειες και εισιτήρια .
Andrey Gushchin (εφεξής – AG): – Είμαι μηχανικός τεχνικής υποστήριξης της ZABBIX (εφεξής «Zabbix»), εκπαιδευτής. Εργάζομαι στην τεχνική υποστήριξη για περισσότερα από 6 χρόνια και έχω άμεση εμπειρία με την απόδοση. Σήμερα θα μιλήσω για την απόδοση που μπορεί να προσφέρει το TimescaleDB σε σύγκριση με το κανονικό PostgreSQL 10. Επίσης, ένα εισαγωγικό μέρος για το πώς λειτουργεί γενικά.
Κορυφαίες προκλήσεις παραγωγικότητας: από τη συλλογή δεδομένων έως τον καθαρισμό δεδομένων
Αρχικά, υπάρχουν ορισμένες προκλήσεις απόδοσης που αντιμετωπίζει κάθε σύστημα παρακολούθησης. Η πρώτη πρόκληση παραγωγικότητας είναι η γρήγορη συλλογή και επεξεργασία δεδομένων.
Ένα καλό σύστημα παρακολούθησης θα πρέπει να λαμβάνει γρήγορα, έγκαιρα όλα τα δεδομένα, να τα επεξεργάζεται σύμφωνα με εκφράσεις ενεργοποίησης, δηλαδή να τα επεξεργάζεται σύμφωνα με ορισμένα κριτήρια (αυτό είναι διαφορετικό σε διαφορετικά συστήματα) και να τα αποθηκεύει σε μια βάση δεδομένων για να χρησιμοποιήσει αυτά τα δεδομένα στο μελλοντικός.
Η δεύτερη πρόκληση απόδοσης είναι η αποθήκευση ιστορικού. Αποθηκεύστε συχνά σε μια βάση δεδομένων και έχετε γρήγορη και εύκολη πρόσβαση σε αυτές τις μετρήσεις που συλλέχθηκαν σε μια χρονική περίοδο. Το πιο σημαντικό πράγμα είναι ότι αυτά τα δεδομένα είναι βολικά για λήψη, χρησιμοποιήστε τα σε αναφορές, γραφήματα, ενεργοποιητές, σε ορισμένες τιμές κατωφλίου, για ειδοποιήσεις κ.λπ.
Η τρίτη πρόκληση απόδοσης είναι η εκκαθάριση ιστορικού, δηλαδή όταν φτάσετε στο σημείο όπου δεν χρειάζεται να αποθηκεύσετε λεπτομερείς μετρήσεις που έχουν συλλεχθεί για 5 χρόνια (ακόμα και μήνες ή δύο μήνες). Ορισμένοι κόμβοι δικτύου διαγράφηκαν ή ορισμένοι κεντρικοί υπολογιστές, οι μετρήσεις δεν χρειάζονται πλέον επειδή είναι ήδη ξεπερασμένες και δεν συλλέγονται πλέον. Όλα αυτά πρέπει να καθαριστούν ώστε η βάση δεδομένων σας να μην μεγαλώσει πολύ. Γενικά, το ιστορικό εκκαθάρισης είναι τις περισσότερες φορές μια σοβαρή δοκιμή για την αποθήκευση - συχνά έχει πολύ ισχυρό αντίκτυπο στην απόδοση.
Πώς να λύσετε προβλήματα προσωρινής αποθήκευσης;
Τώρα θα μιλήσω συγκεκριμένα για το Zabbix. Στο Zabbix, η πρώτη και η δεύτερη κλήση επιλύονται με χρήση προσωρινής αποθήκευσης.
Συλλογή και επεξεργασία δεδομένων - Χρησιμοποιούμε RAM για την αποθήκευση όλων αυτών των δεδομένων. Αυτά τα δεδομένα θα συζητηθούν τώρα με περισσότερες λεπτομέρειες.
Επίσης στην πλευρά της βάσης δεδομένων υπάρχει κάποια προσωρινή αποθήκευση για κύριες επιλογές - για γραφήματα και άλλα πράγματα.
Προσωρινή αποθήκευση στο πλάι του ίδιου του διακομιστή Zabbix: έχουμε ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Τι είναι?
Το ConfigurationCache είναι η κύρια κρυφή μνήμη στην οποία αποθηκεύουμε μετρήσεις, κεντρικούς υπολογιστές, στοιχεία δεδομένων, κανόνες ετικέτας. όλα όσα χρειάζεστε για να επεξεργαστείτε την προεπεξεργασία, να συλλέξετε δεδομένα, από ποιους κεντρικούς υπολογιστές να συλλέξετε, με ποια συχνότητα. Όλα αυτά αποθηκεύονται στο ConfigurationCache για να μην πηγαίνουν στη βάση δεδομένων και δημιουργούνται περιττά ερωτήματα. Μετά την εκκίνηση του διακομιστή, ενημερώνουμε αυτήν την κρυφή μνήμη (δημιουργούμε) και την ενημερώνουμε περιοδικά (ανάλογα με τις ρυθμίσεις διαμόρφωσης).
Προσωρινή αποθήκευση στο Zabbix. Συλλογή δεδομένων
Εδώ το διάγραμμα είναι αρκετά μεγάλο:
Οι κυριότεροι στο σχέδιο είναι αυτοί οι συλλέκτες:
Αυτές είναι οι ίδιες οι διαδικασίες συναρμολόγησης, διάφοροι «pollers» που είναι υπεύθυνοι για διαφορετικούς τύπους συγκροτημάτων. Συλλέγουν δεδομένα μέσω icmp, ipmi και διαφόρων πρωτοκόλλων και τα μεταφέρουν όλα σε προεπεξεργασία.
Προεπεξεργασία HistoryCache
Επίσης, αν έχουμε υπολογισμένα στοιχεία δεδομένων (όσοι γνωρίζουν το Zabbix), δηλαδή υπολογισμένα, στοιχεία δεδομένων συνάθροισης, τα παίρνουμε απευθείας από το ValueCache. Θα σας πω πώς γεμίζεται αργότερα. Όλοι αυτοί οι συλλέκτες χρησιμοποιούν το ConfigurationCache για να λάβουν τις εργασίες τους και στη συνέχεια να τις περάσουν στην προεπεξεργασία.
Η προεπεξεργασία χρησιμοποιεί επίσης το ConfigurationCache για τη λήψη βημάτων προεπεξεργασίας και επεξεργάζεται αυτά τα δεδομένα με διάφορους τρόπους. Ξεκινώντας από την έκδοση 4.2, το έχουμε μετακινήσει σε διακομιστή μεσολάβησης. Αυτό είναι πολύ βολικό, επειδή η ίδια η προεπεξεργασία είναι μια αρκετά δύσκολη λειτουργία. Και αν έχετε ένα πολύ μεγάλο Zabbix, με μεγάλο αριθμό στοιχείων δεδομένων και υψηλή συχνότητα συλλογής, τότε αυτό απλοποιεί πολύ τη δουλειά.
Αντίστοιχα, αφού έχουμε επεξεργαστεί αυτά τα δεδομένα με κάποιο τρόπο χρησιμοποιώντας προεπεξεργασία, τα αποθηκεύουμε στο HistoryCache για να τα επεξεργαστούμε περαιτέρω. Αυτό ολοκληρώνει τη συλλογή δεδομένων. Προχωράμε στην κύρια διαδικασία.
Έργο του History syncer
Η κύρια διαδικασία στο Zabbix (καθώς είναι μονολιθική αρχιτεκτονική) είναι το History syncer. Αυτή είναι η κύρια διαδικασία που ασχολείται συγκεκριμένα με την ατομική επεξεργασία κάθε στοιχείου δεδομένων, δηλαδή κάθε τιμής:
- η τιμή προέρχεται (την παίρνει από το HistoryCache).
- ελέγχει στο Configuration syncer: εάν υπάρχουν ερεθίσματα για υπολογισμό - τα υπολογίζει.
εάν υπάρχει - δημιουργεί συμβάντα, δημιουργεί κλιμάκωση προκειμένου να δημιουργηθεί μια ειδοποίηση, εάν είναι απαραίτητο σύμφωνα με τη διαμόρφωση. - καταγράφει τα εναύσματα για επακόλουθη επεξεργασία, συνάθροιση. Εάν αθροίσετε την τελευταία ώρα και ούτω καθεξής, αυτή η τιμή απομνημονεύεται από το ValueCache για να μην μεταβεί στον πίνακα ιστορικού. Έτσι, η ValueCache γεμίζει με τα απαραίτητα δεδομένα που είναι απαραίτητα για τον υπολογισμό των ενεργειών, των υπολογισμένων στοιχείων κ.λπ.
- Στη συνέχεια, ο συγχρονισμός ιστορικού εγγράφει όλα τα δεδομένα στη βάση δεδομένων.
- η βάση δεδομένων τα εγγράφει στο δίσκο - εδώ τελειώνει η διαδικασία επεξεργασίας.
Βάση δεδομένων. Προσωρινή αποθήκευση
Στην πλευρά της βάσης δεδομένων, όταν θέλετε να προβάλετε γραφήματα ή ορισμένες αναφορές για συμβάντα, υπάρχουν διάφορες κρυφές μνήμες. Αλλά σε αυτήν την έκθεση δεν θα μιλήσω γι' αυτά.
Για τη MySQL υπάρχει το Innodb_buffer_pool και μια δέσμη διαφορετικών κρυφών μνήμων που μπορούν επίσης να ρυθμιστούν.
Αυτά όμως είναι τα κυριότερα:
- shared_buffers;
- effect_cache_size;
- shared_pool.
Για όλες τις βάσεις δεδομένων, είπα ότι υπάρχουν ορισμένες κρυφές μνήμες που σας επιτρέπουν να αποθηκεύετε στη μνήμη RAM τα δεδομένα που χρειάζονται συχνά για ερωτήματα. Έχουν τις δικές τους τεχνολογίες για αυτό.
Σχετικά με την απόδοση της βάσης δεδομένων
Αντίστοιχα, υπάρχει ένα ανταγωνιστικό περιβάλλον, δηλαδή ο διακομιστής Zabbix συλλέγει δεδομένα και τα καταγράφει. Κατά την επανεκκίνηση, διαβάζει επίσης από το ιστορικό για να γεμίσει το ValueCache και ούτω καθεξής. Εδώ μπορείτε να έχετε σενάρια και αναφορές που χρησιμοποιούν το Zabbix API, το οποίο είναι χτισμένο σε μια διεπαφή ιστού. Το Zabbix API εισέρχεται στη βάση δεδομένων και λαμβάνει τα απαραίτητα δεδομένα για τη λήψη γραφημάτων, αναφορών ή κάποιου είδους λίστας συμβάντων, πρόσφατων προβλημάτων.
Επίσης μια πολύ δημοφιλής λύση οπτικοποίησης είναι η Grafana, την οποία χρησιμοποιούν οι χρήστες μας. Δυνατότητα απευθείας σύνδεσης τόσο μέσω του Zabbix API όσο και μέσω της βάσης δεδομένων. Δημιουργεί επίσης έναν ορισμένο ανταγωνισμό για την απόκτηση δεδομένων: απαιτείται καλύτερος, καλύτερος συντονισμός της βάσης δεδομένων για τη συμμόρφωση με την ταχεία παράδοση των αποτελεσμάτων και τις δοκιμές.
Εκκαθάριση ιστορικού. Ο Zabbix έχει Housekeeper
Η τρίτη κλήση που χρησιμοποιείται στο Zabbix είναι η εκκαθάριση ιστορικού χρησιμοποιώντας το Housekeeper. Το Housekeeper ακολουθεί όλες τις ρυθμίσεις, δηλαδή, τα στοιχεία δεδομένων μας υποδεικνύουν τη διάρκεια αποθήκευσης (σε ημέρες), τη διάρκεια αποθήκευσης των τάσεων και τη δυναμική των αλλαγών.
Δεν μίλησα για το TrendCache, το οποίο υπολογίζουμε εν κινήσει: φτάνουν δεδομένα, τα συγκεντρώνουμε για μία ώρα (κυρίως αυτοί είναι αριθμοί για την τελευταία ώρα), το ποσό είναι μέσος/ελάχιστο και το καταγράφουμε μία φορά την ώρα στο πίνακας της δυναμικής των αλλαγών («Τάσεις») . Το "Housekeeper" ξεκινά και διαγράφει δεδομένα από τη βάση δεδομένων χρησιμοποιώντας κανονικές επιλογές, κάτι που δεν είναι πάντα αποτελεσματικό.
Πώς να καταλάβετε ότι είναι αναποτελεσματικό; Μπορείτε να δείτε την ακόλουθη εικόνα στα γραφήματα απόδοσης των εσωτερικών διεργασιών:
Ο συγχρονιστής ιστορικού σας είναι συνεχώς απασχολημένος (κόκκινο γράφημα). Και το «κόκκινο» γράφημα που βρίσκεται στην κορυφή. Αυτό είναι ένα "Housekeeper" που ξεκινά και περιμένει τη βάση δεδομένων να διαγράψει όλες τις σειρές που έχει καθορίσει.
Ας πάρουμε κάποιο αναγνωριστικό στοιχείου: πρέπει να διαγράψετε τις τελευταίες 5 χιλιάδες. φυσικά με ευρετήρια. Αλλά συνήθως το σύνολο δεδομένων είναι αρκετά μεγάλο - η βάση δεδομένων εξακολουθεί να το διαβάζει από το δίσκο και να το τοποθετεί στην κρυφή μνήμη, και αυτή είναι μια πολύ δαπανηρή λειτουργία για τη βάση δεδομένων. Ανάλογα με το μέγεθός του, αυτό μπορεί να οδηγήσει σε ορισμένα προβλήματα απόδοσης.
Μπορείτε να απενεργοποιήσετε το Housekeeper με απλό τρόπο - έχουμε μια οικεία διεπαφή ιστού. Ρυθμίσεις στο Administration general (ρυθμίσεις για "Housekeeper") απενεργοποιούμε την εσωτερική καθαριότητα για εσωτερική ιστορία και τάσεις. Συνεπώς, το Housekeeper δεν ελέγχει πλέον αυτό:
Τι μπορείτε να κάνετε μετά; Το απενεργοποιήσατε, τα γραφήματα σας έχουν ισοπεδωθεί... Ποια περαιτέρω προβλήματα θα μπορούσαν να προκύψουν σε αυτήν την περίπτωση; Τι μπορεί να βοηθήσει;
Διαμερισμός (τμηματοποίηση)
Συνήθως αυτό ρυθμίζεται με διαφορετικό τρόπο σε κάθε σχεσιακή βάση δεδομένων που έχω παραθέσει. Η MySQL έχει τη δική της τεχνολογία. Αλλά συνολικά μοιάζουν πολύ όταν πρόκειται για PostgreSQL 10 και MySQL. Φυσικά, υπάρχουν πολλές εσωτερικές διαφορές στον τρόπο με τον οποίο υλοποιούνται όλα και πώς επηρεάζουν την απόδοση. Αλλά γενικά, η δημιουργία ενός νέου διαμερίσματος συχνά οδηγεί επίσης σε ορισμένα προβλήματα.
Ανάλογα με τη ρύθμισή σας (πόσα δεδομένα δημιουργείτε σε μια ημέρα), συνήθως ορίζουν το ελάχιστο - αυτό είναι 1 ημέρα / παρτίδα και για "τάσεις", δυναμική αλλαγών - 1 μήνας / νέα παρτίδα. Αυτό μπορεί να αλλάξει εάν έχετε πολύ μεγάλη εγκατάσταση.
Ας πούμε αμέσως για το μέγεθος της ρύθμισης: έως και 5 χιλιάδες νέες τιμές ανά δευτερόλεπτο (τα λεγόμενα nvps) - αυτό θα θεωρηθεί μια μικρή "ρύθμιση". Μέσος όρος - από 5 έως 25 χιλιάδες τιμές ανά δευτερόλεπτο. Όλα όσα αναφέρονται παραπάνω είναι ήδη μεγάλες και πολύ μεγάλες εγκαταστάσεις που απαιτούν πολύ προσεκτική διαμόρφωση της βάσης δεδομένων.
Σε πολύ μεγάλες εγκαταστάσεις, η 1 ημέρα μπορεί να μην είναι η βέλτιστη. Προσωπικά έχω δει κατατμήσεις στην MySQL των 40 gigabyte την ημέρα (και μπορεί να υπάρχουν περισσότερα). Αυτός είναι ένας πολύ μεγάλος όγκος δεδομένων, ο οποίος μπορεί να οδηγήσει σε ορισμένα προβλήματα. Πρέπει να μειωθεί.
Γιατί χρειάζεστε κατάτμηση;
Αυτό που παρέχει το Partitioning, νομίζω ότι όλοι γνωρίζουν, είναι η κατάτμηση πίνακα. Συχνά πρόκειται για ξεχωριστά αρχεία σε δίσκους και αιτήματα έκτασης. Επιλέγει ένα διαμέρισμα πιο βέλτιστα εάν είναι μέρος της κανονικής κατάτμησης.
Για το Zabbix, συγκεκριμένα, χρησιμοποιείται κατά εύρος, κατά εύρος, δηλαδή χρησιμοποιούμε χρονοσφραγίδα (κανονικός αριθμός, χρόνος από την αρχή της εποχής). Καθορίζετε την αρχή της ημέρας/το τέλος της ημέρας και αυτό είναι το διαμέρισμα. Αντίστοιχα, εάν ζητάτε δεδομένα που είναι δύο ημερών, τα πάντα ανακτώνται από τη βάση δεδομένων πιο γρήγορα, επειδή χρειάζεται μόνο να φορτώσετε ένα αρχείο στη μνήμη cache και να το επιστρέψετε (και όχι έναν μεγάλο πίνακα).
Πολλές βάσεις δεδομένων επιταχύνουν επίσης την εισαγωγή (εισαγωγή σε έναν θυγατρικό πίνακα). Μιλάω αφηρημένα προς το παρόν, αλλά και αυτό είναι δυνατό. Ο διαχωρισμός συχνά βοηθά.
Elasticsαναζήτηση για NoSQL
Πρόσφατα, στην έκδοση 3.4, εφαρμόσαμε μια λύση NoSQL. Προστέθηκε η δυνατότητα γραφής στο Elasticsearch. Μπορείτε να γράψετε ορισμένους τύπους: εσείς επιλέγετε - είτε γράφετε αριθμούς είτε μερικά σημάδια. έχουμε κείμενο συμβολοσειράς, μπορείτε να γράψετε αρχεία καταγραφής στο Elasticsearch... Κατά συνέπεια, η διεπαφή ιστού θα έχει επίσης πρόσβαση στο Elasticsearch. Αυτό λειτουργεί εξαιρετικά σε ορισμένες περιπτώσεις, αλλά αυτή τη στιγμή μπορεί να χρησιμοποιηθεί.
TimescaleDB. Υπερτραπέζιοι
Για το 4.4.2 δώσαμε προσοχή σε ένα πράγμα όπως το TimescaleDB. Τι είναι? Αυτή είναι μια επέκταση για την PostgreSQL, δηλαδή έχει μια εγγενή διεπαφή PostgreSQL. Επιπλέον, αυτή η επέκταση σάς επιτρέπει να εργάζεστε πολύ πιο αποτελεσματικά με δεδομένα χρονοσειρών και να έχετε αυτόματη κατάτμηση. Πως μοιάζει:
Αυτό είναι hypertable - υπάρχει μια τέτοια έννοια στο Timescale. Αυτός είναι ένας υπερπίνακας που δημιουργείτε και περιέχει κομμάτια. Τα κομμάτια είναι διαμερίσματα, αυτά είναι θυγατρικοί πίνακες, αν δεν κάνω λάθος. Είναι πραγματικά αποτελεσματικό.
TimescaleDB και PostgreSQL
Όπως διαβεβαιώνουν οι κατασκευαστές του TimescaleDB, χρησιμοποιούν έναν πιο σωστό αλγόριθμο για την επεξεργασία ερωτημάτων, ιδιαίτερα ένθετων, που τους επιτρέπει να έχουν περίπου σταθερή απόδοση με αυξανόμενο μέγεθος του ένθετου δεδομένων. Δηλαδή, μετά από 200 εκατομμύρια σειρές Postgres, η συνηθισμένη αρχίζει να πέφτει πολύ και χάνει την απόδοση κυριολεκτικά στο μηδέν, ενώ το Timescale σάς επιτρέπει να εισάγετε ένθετα όσο το δυνατόν πιο αποτελεσματικά με οποιοδήποτε όγκο δεδομένων.
Πώς να εγκαταστήσετε το TimescaleDB; Είναι απλό!
Είναι στην τεκμηρίωση, περιγράφεται - μπορείτε να το εγκαταστήσετε από πακέτα για οποιοδήποτε... Εξαρτάται από τα επίσημα πακέτα Postgres. Μπορεί να μεταγλωττιστεί χειροκίνητα. Έτυχε ότι έπρεπε να μεταγλωττίσω για τη βάση δεδομένων.
Στο Zabbix ενεργοποιούμε απλώς την επέκταση. Νομίζω ότι όσοι χρησιμοποίησαν το Extention στο Postgres... Απλώς ενεργοποιείτε το Extention, το δημιουργείτε για τη βάση δεδομένων Zabbix που χρησιμοποιείτε.
Και το τελευταίο βήμα...
TimescaleDB. Μετανάστευση πινάκων ιστορίας
Πρέπει να δημιουργήσετε έναν υπερπίνακα. Υπάρχει μια ειδική λειτουργία για αυτό - Δημιουργία hypertable. Σε αυτό, η πρώτη παράμετρος είναι ο πίνακας που χρειάζεται σε αυτήν τη βάση δεδομένων (για τον οποίο πρέπει να δημιουργήσετε έναν υπερπίνακα).
Το πεδίο με το οποίο δημιουργείται και το chunk_time_interval (αυτό είναι το διάστημα των κομματιών (διαμερίσματα που πρέπει να χρησιμοποιηθούν). 86 είναι μία ημέρα.
Παράμετρος Migrate_data: Εάν εισαγάγετε το true, τότε αυτό θα μετεγκαταστήσει όλα τα τρέχοντα δεδομένα σε προδημιουργημένα κομμάτια.
Έχω χρησιμοποιήσει ο ίδιος το migrate_data - χρειάζεται αρκετός χρόνος, ανάλογα με το πόσο μεγάλη είναι η βάση δεδομένων σας. Είχα πάνω από ένα terabyte - χρειάστηκε πάνω από μία ώρα για να δημιουργήσω. Σε ορισμένες περιπτώσεις, κατά τη διάρκεια των δοκιμών, διέγραψα ιστορικά δεδομένα για κείμενο (history_text) και συμβολοσειρά (history_str) για να μην τα μεταφέρω - δεν ήταν πραγματικά ενδιαφέροντα για μένα.
Και κάνουμε την τελευταία ενημέρωση στο db_exttention: εγκαθιστούμε το timescaledb έτσι ώστε η βάση δεδομένων και, ειδικότερα, το Zabbix μας να καταλάβει ότι υπάρχει db_extination. Το ενεργοποιεί και χρησιμοποιεί τη σωστή σύνταξη και ερωτήματα στη βάση δεδομένων, χρησιμοποιώντας εκείνα τα «χαρακτηριστικά» που είναι απαραίτητα για το TimescaleDB.
Διαμόρφωση διακομιστή
Χρησιμοποίησα δύο διακομιστές. Ο πρώτος διακομιστής είναι μια αρκετά μικρή εικονική μηχανή, 20 επεξεργαστές, 16 gigabyte μνήμης RAM. Ρύθμισα το Postgres 10.8 σε αυτό:
Το λειτουργικό σύστημα ήταν Debian, το σύστημα αρχείων ήταν xfs. Έκανα ελάχιστες ρυθμίσεις για τη χρήση αυτής της συγκεκριμένης βάσης δεδομένων, μείον αυτό που θα χρησιμοποιήσει το ίδιο το Zabbix. Στο ίδιο μηχάνημα υπήρχε διακομιστής Zabbix, PostgreSQL και πράκτορες φόρτωσης.
Έχω χρησιμοποιήσει 50 ενεργούς παράγοντες που χρησιμοποιούν LoadableModule για να δημιουργήσουν γρήγορα διαφορετικά αποτελέσματα. Είναι αυτοί που δημιούργησαν τις συμβολοσειρές, τους αριθμούς και ούτω καθεξής. Γέμισα τη βάση δεδομένων με πολλά δεδομένα. Αρχικά, η διαμόρφωση περιείχε 5 χιλιάδες στοιχεία δεδομένων ανά κεντρικό υπολογιστή και περίπου κάθε στοιχείο δεδομένων περιείχε ένα έναυσμα - προκειμένου αυτό να είναι μια πραγματική ρύθμιση. Μερικές φορές χρειάζεστε ακόμη και περισσότερες από μία σκανδάλες για χρήση.
Ρύθμισα το διάστημα ενημέρωσης και το ίδιο το φορτίο χρησιμοποιώντας όχι μόνο 50 πράκτορες (προσθέτοντας περισσότερους), αλλά και χρησιμοποιώντας δυναμικά στοιχεία δεδομένων και μειώνοντας το διάστημα ενημέρωσης στα 4 δευτερόλεπτα.
Δοκιμή απόδοσης. PostgreSQL: 36 χιλιάδες NVP
Η πρώτη εκκίνηση, η πρώτη ρύθμιση που είχα ήταν σε καθαρό PostreSQL 10 σε αυτό το υλικό (35 χιλιάδες τιμές ανά δευτερόλεπτο). Σε γενικές γραμμές, όπως μπορείτε να δείτε στην οθόνη, η εισαγωγή δεδομένων διαρκεί κλάσματα του δευτερολέπτου - όλα είναι καλά και γρήγορα, μονάδες SSD (200 gigabyte). Το μόνο πράγμα είναι ότι τα 20 GB γεμίζουν αρκετά γρήγορα.
Θα υπάρξουν πολλά τέτοια γραφήματα στο μέλλον. Αυτός είναι ένας τυπικός πίνακας εργαλείων απόδοσης διακομιστή Zabbix.
Το πρώτο γράφημα είναι ο αριθμός των τιμών ανά δευτερόλεπτο (μπλε, πάνω αριστερά), 35 χιλιάδες τιμές σε αυτήν την περίπτωση. Αυτό (επάνω κέντρο) είναι η φόρτωση των διαδικασιών κατασκευής και αυτό (πάνω δεξιά) είναι η φόρτωση των εσωτερικών διεργασιών: συγχρονιστές ιστορικού και housekeeper, που εδώ (κάτω κέντρο) εκτελείται εδώ και αρκετό καιρό.
Αυτό το γράφημα (κάτω κέντρο) δείχνει τη χρήση ValueCache - πόσες επισκέψεις ValueCache για κανόνες ετικέτας (αρκετές χιλιάδες τιμές ανά δευτερόλεπτο). Ένα άλλο σημαντικό γράφημα είναι το τέταρτο (κάτω αριστερά), το οποίο δείχνει τη χρήση του HistoryCache, για το οποίο μίλησα, το οποίο είναι ένα buffer πριν από την εισαγωγή στη βάση δεδομένων.
Δοκιμή απόδοσης. PostgreSQL: 50 χιλιάδες NVP
Στη συνέχεια, αύξησα το φορτίο σε 50 χιλιάδες τιμές ανά δευτερόλεπτο στο ίδιο υλικό. Όταν φορτώθηκε από το Housekeeper, καταγράφηκαν 10 χιλιάδες τιμές σε 2-3 δευτερόλεπτα με υπολογισμό. Τι, στην πραγματικότητα, φαίνεται στο παρακάτω στιγμιότυπο οθόνης:
Η "Οικοκυράχος" έχει ήδη αρχίσει να παρεμβαίνει στην εργασία, αλλά γενικά, το φορτίο στους παγιδευτές ιστορίας είναι ακόμα στο επίπεδο του 60% (τρίτο γράφημα, επάνω δεξιά). Το HistoryCache αρχίζει ήδη να γεμίζει ενεργά ενώ εκτελείται το Housekeeper (κάτω αριστερά). Ήταν περίπου μισό gigabyte, 20% γεμάτο.
Δοκιμή απόδοσης. PostgreSQL: 80 χιλιάδες NVP
Στη συνέχεια το αύξησα σε 80 χιλιάδες τιμές ανά δευτερόλεπτο:
Ήταν περίπου 400 χιλιάδες στοιχεία δεδομένων, 280 χιλιάδες εναύσματα. Το ένθετο, όπως μπορείτε να δείτε, ως προς το φορτίο των βυθιζόμενων ιστορικών (υπήρχαν 30 από αυτούς) ήταν ήδη αρκετά υψηλό. Στη συνέχεια αύξησα διάφορες παραμέτρους: ιστορικούς βυθιστές, κρυφή μνήμη... Σε αυτό το υλικό, το φορτίο στα βυθίσματα ιστορικού άρχισε να αυξάνεται στο μέγιστο, σχεδόν «στο ράφι» - κατά συνέπεια, το HistoryCache πήγε σε πολύ υψηλό φορτίο:
Όλο αυτό το διάστημα παρακολούθησα όλες τις παραμέτρους του συστήματος (πώς χρησιμοποιείται ο επεξεργαστής, RAM) και ανακάλυψα ότι η χρήση του δίσκου ήταν μέγιστη - πέτυχα τη μέγιστη χωρητικότητα αυτού του δίσκου σε αυτό το υλικό, σε αυτήν την εικονική μηχανή. Το "Postgres" άρχισε να απορρίπτει δεδομένα αρκετά ενεργά σε τέτοια ένταση και ο δίσκος δεν είχε πλέον χρόνο να γράψει, να διαβάσει...
Πήρα έναν άλλο διακομιστή που είχε ήδη 48 επεξεργαστές και 128 gigabyte μνήμης RAM:
Το "συντόνισα" επίσης - εγκατέστησα το History syncer (60 τεμάχια) και πέτυχα αποδεκτές επιδόσεις. Στην πραγματικότητα, δεν είμαστε «στο ράφι», αλλά αυτό είναι πιθανώς το όριο της παραγωγικότητας, όπου είναι ήδη απαραίτητο να κάνουμε κάτι για αυτό.
Δοκιμή απόδοσης. TimescaleDB: 80 χιλιάδες NVP
Το κύριο καθήκον μου ήταν να χρησιμοποιήσω το TimescaleDB. Κάθε γράφημα δείχνει μια βύθιση:
Αυτές οι αποτυχίες είναι ακριβώς η μετεγκατάσταση δεδομένων. Μετά από αυτό, στον διακομιστή Zabbix, το προφίλ φόρτωσης των history sinkers, όπως μπορείτε να δείτε, άλλαξε πολύ. Σας επιτρέπει να εισάγετε δεδομένα σχεδόν 3 φορές πιο γρήγορα και να χρησιμοποιείτε λιγότερο HistoryCache - κατά συνέπεια, τα δεδομένα θα παραδίδονται στην ώρα τους. Και πάλι, 80 χιλιάδες τιμές ανά δευτερόλεπτο είναι ένα αρκετά υψηλό ποσοστό (φυσικά, όχι για το Yandex). Συνολικά πρόκειται για μια αρκετά μεγάλη εγκατάσταση, με έναν διακομιστή.
Δοκιμή απόδοσης PostgreSQL: 120 χιλιάδες NVP
Στη συνέχεια, αύξησα την αξία του αριθμού των στοιχείων δεδομένων σε μισό εκατομμύριο και έλαβα μια υπολογισμένη τιμή 125 χιλιάδων ανά δευτερόλεπτο:
Και πήρα αυτά τα γραφήματα:
Κατ 'αρχήν, αυτή είναι μια λειτουργική εγκατάσταση, μπορεί να λειτουργήσει για αρκετό καιρό. Αλλά επειδή είχα μόνο ένα δίσκο 1,5 terabyte, τον χρησιμοποίησα σε μερικές μέρες. Το πιο σημαντικό είναι ότι ταυτόχρονα δημιουργήθηκαν νέα διαμερίσματα στο TimescaleDB, και αυτό ήταν εντελώς απαρατήρητο για την απόδοση, κάτι που δεν μπορεί να ειπωθεί για τη MySQL.
Συνήθως, τα διαμερίσματα δημιουργούνται τη νύχτα, επειδή αυτό γενικά εμποδίζει την εισαγωγή και την εργασία με πίνακες και μπορεί να οδηγήσει σε υποβάθμιση της υπηρεσίας. Σε αυτή την περίπτωση δεν ισχύει αυτό! Το κύριο καθήκον ήταν να δοκιμαστούν οι δυνατότητες του TimescaleDB. Το αποτέλεσμα ήταν ο ακόλουθος αριθμός: 120 χιλιάδες τιμές ανά δευτερόλεπτο.
Υπάρχουν επίσης παραδείγματα στην κοινότητα:
Το άτομο ενεργοποίησε επίσης το TimescaleDB και το φόρτο χρήσης του io.weight έπεσε στον επεξεργαστή. και η χρήση εσωτερικών στοιχείων διεργασίας έχει επίσης μειωθεί λόγω της συμπερίληψης του TimescaleDB. Επιπλέον, αυτοί είναι συνηθισμένοι δίσκοι pancake, δηλαδή μια συνηθισμένη εικονική μηχανή σε συνηθισμένους δίσκους (όχι SSD)!
Για ορισμένες μικρές ρυθμίσεις που περιορίζονται από την απόδοση του δίσκου, το TimescaleDB, κατά τη γνώμη μου, είναι μια πολύ καλή λύση. Θα σας επιτρέψει να συνεχίσετε να εργάζεστε πριν μεταβείτε σε ταχύτερο υλικό για τη βάση δεδομένων.
Σας προσκαλώ όλους στις εκδηλώσεις μας: Διάσκεψη στη Μόσχα, Σύνοδο στη Ρίγα. Χρησιμοποιήστε τα κανάλια μας - Telegram, φόρουμ, IRC. Αν έχετε απορίες, ελάτε στο γραφείο μας, μπορούμε να μιλήσουμε για τα πάντα.
Ερωτήσεις κοινού
Ερώτηση από το κοινό (στο εξής - A): - Εάν το TimescaleDB είναι τόσο εύκολο στη διαμόρφωση και δίνει μια τέτοια ώθηση στην απόδοση, τότε ίσως αυτό θα έπρεπε να χρησιμοποιηθεί ως βέλτιστη πρακτική για τη διαμόρφωση του Zabbix με το Postgres; Και υπάρχουν παγίδες και μειονεκτήματα αυτής της λύσης ή τελικά, αν αποφάσισα να φτιάξω το Zabbix για μένα, μπορώ εύκολα να πάρω το Postgres, να εγκαταστήσω αμέσως εκεί το Timescale, να το χρησιμοποιήσω και να μην σκεφτώ κανένα πρόβλημα;
AG: – Ναι, θα έλεγα ότι αυτή είναι μια καλή σύσταση: χρησιμοποιήστε το Postgres αμέσως με την επέκταση TimescaleDB. Όπως είπα ήδη, πολλές καλές κριτικές, παρά το γεγονός ότι αυτό το "χαρακτηριστικό" είναι πειραματικό. Αλλά στην πραγματικότητα οι δοκιμές δείχνουν ότι αυτή είναι μια εξαιρετική λύση (με το TimescaleDB) και νομίζω ότι θα εξελιχθεί! Παρακολουθούμε πώς αναπτύσσεται αυτή η επέκταση και θα κάνουμε αλλαγές όπως απαιτείται.
Ακόμη και κατά την ανάπτυξη, βασιστήκαμε σε ένα από τα γνωστά «χαρακτηριστικά» τους: ήταν δυνατό να δουλέψουμε με κομμάτια λίγο διαφορετικά. Αλλά στη συνέχεια το έκοψαν στην επόμενη κυκλοφορία και έπρεπε να σταματήσουμε να βασιζόμαστε σε αυτόν τον κωδικό. Θα συνιστούσα να χρησιμοποιήσετε αυτήν τη λύση σε πολλές ρυθμίσεις. Εάν χρησιμοποιείτε MySQL... Για μέσες ρυθμίσεις, οποιαδήποτε λύση λειτουργεί καλά.
Α: – Στα τελευταία γραφήματα από την κοινότητα, υπήρχε ένα γράφημα με το "Housekeeper":
Συνέχισε να δουλεύει. Τι κάνει το Housekeeper με το TimescaleDB;
AG: – Τώρα δεν μπορώ να πω με σιγουριά – θα κοιτάξω τον κώδικα και θα σας πω με περισσότερες λεπτομέρειες. Χρησιμοποιεί ερωτήματα TimescaleDB όχι για να διαγράψει κομμάτια, αλλά για να τα συγκεντρώσει με κάποιο τρόπο. Δεν είμαι έτοιμος να απαντήσω ακόμα σε αυτήν την τεχνική ερώτηση. Θα μάθουμε περισσότερα στο περίπτερο σήμερα ή αύριο.
Α: – Έχω μια παρόμοια ερώτηση – σχετικά με την απόδοση της λειτουργίας διαγραφής στο Timescale.
Α (απάντηση από το κοινό): – Όταν διαγράφετε δεδομένα από έναν πίνακα, εάν το κάνετε μέσω διαγραφής, τότε πρέπει να περάσετε από τον πίνακα - διαγράψτε, καθαρίστε, επισημάνετε τα πάντα για μελλοντική υποπίεση. Στο Timescale, αφού έχετε κομμάτια, μπορείτε να ρίξετε. Σε γενικές γραμμές, λέτε απλώς στο αρχείο που βρίσκεται σε μεγάλα δεδομένα: "Διαγραφή!"
Η Timescale απλά καταλαβαίνει ότι ένα τέτοιο κομμάτι δεν υπάρχει πλέον. Και δεδομένου ότι είναι ενσωματωμένο στο πρόγραμμα σχεδιασμού ερωτημάτων, χρησιμοποιεί γάντζους για να συλλάβει τις συνθήκες σας σε επιλεγμένες ή άλλες λειτουργίες και καταλαβαίνει αμέσως ότι αυτό το κομμάτι δεν υπάρχει πλέον - "Δεν θα πάω πια εκεί!" (τα δεδομένα δεν είναι διαθέσιμα). Αυτό είναι όλο! Δηλαδή, μια σάρωση πίνακα αντικαθίσταται από μια διαγραφή δυαδικού αρχείου, επομένως είναι γρήγορη.
Α: – Έχουμε ήδη θίξει το θέμα της μη SQL. Από όσο καταλαβαίνω, το Zabbix δεν χρειάζεται πραγματικά να τροποποιήσει τα δεδομένα και όλα αυτά είναι κάτι σαν αρχείο καταγραφής. Είναι δυνατόν να χρησιμοποιηθούν εξειδικευμένες βάσεις δεδομένων που δεν μπορούν να αλλάξουν τα δεδομένα τους, αλλά ταυτόχρονα αποθηκεύουν, συσσωρεύουν και διανέμουν πολύ πιο γρήγορα - το Clickhouse, για παράδειγμα, κάτι σαν Κάφκα;... Ο Κάφκα είναι επίσης ένα αρχείο καταγραφής! Είναι δυνατόν να ενσωματωθούν με κάποιο τρόπο;
AG: - Η εκφόρτωση μπορεί να γίνει. Έχουμε ένα συγκεκριμένο "χαρακτηριστικό" από την έκδοση 3.4: μπορείτε να γράψετε όλα τα ιστορικά αρχεία, τα γεγονότα, οτιδήποτε άλλο σε αρχεία. και στη συνέχεια στείλτε το σε οποιαδήποτε άλλη βάση δεδομένων χρησιμοποιώντας κάποιο πρόγραμμα χειρισμού. Στην πραγματικότητα, πολλοί άνθρωποι ξαναδουλεύουν και γράφουν απευθείας στη βάση δεδομένων. Εν κινήσει, οι καταβόθρες ιστορίας γράφουν όλα αυτά σε αρχεία, περιστρέφουν αυτά τα αρχεία και ούτω καθεξής, και μπορείτε να τα μεταφέρετε στο Clickhouse. Δεν μπορώ να πω για σχέδια, αλλά ίσως η περαιτέρω υποστήριξη για λύσεις NoSQL (όπως το Clickhouse) θα συνεχιστεί.
Α: – Γενικά, αποδεικνύεται ότι μπορείτε να απαλλαγείτε εντελώς από τα postgres;
AG: – Φυσικά, το πιο δύσκολο κομμάτι στο Zabbix είναι οι ιστορικοί πίνακες, που δημιουργούν τα περισσότερα προβλήματα και γεγονότα. Σε αυτήν την περίπτωση, εάν δεν αποθηκεύετε συμβάντα για μεγάλο χρονικό διάστημα και αποθηκεύετε το ιστορικό με τις τάσεις σε κάποια άλλη γρήγορη αποθήκευση, τότε γενικά, νομίζω, δεν θα υπάρχουν προβλήματα.
Α: – Μπορείτε να υπολογίσετε πόσο πιο γρήγορα θα λειτουργήσουν όλα εάν μεταβείτε στο Clickhouse, για παράδειγμα;
AG: – Δεν το έχω δοκιμάσει. Νομίζω ότι τουλάχιστον οι ίδιοι αριθμοί μπορούν να επιτευχθούν πολύ απλά, δεδομένου ότι το Clickhouse έχει τη δική του διεπαφή, αλλά δεν μπορώ να πω με βεβαιότητα. Είναι καλύτερα να κάνετε δοκιμή. Όλα εξαρτώνται από τη διαμόρφωση: πόσους κεντρικούς υπολογιστές έχετε και ούτω καθεξής. Η εισαγωγή είναι ένα πράγμα, αλλά πρέπει επίσης να ανακτήσετε αυτά τα δεδομένα - Grafana ή κάτι άλλο.
Α: – Δηλαδή μιλάμε για ισότιμο αγώνα και όχι για το μεγάλο πλεονέκτημα αυτών των γρήγορων βάσεων δεδομένων;
AG: – Νομίζω ότι όταν ενσωματωθούμε, θα υπάρξουν πιο ακριβείς δοκιμές.
Α: – Πού πήγε το παλιό καλό RRD; Τι σας έκανε να μεταβείτε στις βάσεις δεδομένων SQL; Αρχικά, όλες οι μετρήσεις συλλέχθηκαν στο RRD.
AG: – Ο Zabbix είχε RRD, ίσως σε μια πολύ αρχαία έκδοση. Υπήρχαν πάντα βάσεις δεδομένων SQL - μια κλασική προσέγγιση. Η κλασική προσέγγιση είναι η MySQL, η PostgreSQL (υπάρχουν εδώ και πολύ καιρό). Δεν χρησιμοποιήσαμε σχεδόν ποτέ μια κοινή διεπαφή για βάσεις δεδομένων SQL και RRD.
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com