Τα VictoriaMetrics, TimescaleDB και InfluxDB συγκρίθηκαν στο σε ένα σύνολο δεδομένων με ένα δισεκατομμύριο σημεία δεδομένων που ανήκουν σε 40K μοναδικές χρονοσειρές.
Πριν από μερικά χρόνια υπήρξε μια εποχή του Zabbix. Κάθε διακομιστής γυμνού μετάλλου δεν είχε περισσότερους από μερικούς δείκτες - χρήση CPU, χρήση RAM, χρήση δίσκου και χρήση δικτύου. Με αυτόν τον τρόπο, οι μετρήσεις από χιλιάδες διακομιστές μπορούν να χωρέσουν σε 40 χιλιάδες μοναδικές χρονοσειρές και το Zabbix μπορεί να χρησιμοποιήσει τη MySQL ως backend για δεδομένα χρονοσειρών :)
Επί του παρόντος μόνος με προεπιλεγμένες διαμορφώσεις παρέχει πάνω από 500 μετρήσεις στον μέσο κεντρικό υπολογιστή. Υπάρχουν πολλά για διάφορες βάσεις δεδομένων, διακομιστές ιστού, συστήματα υλικού κ.λπ. Όλα παρέχουν μια ποικιλία χρήσιμων μετρήσεων. Ολα αρχίζουν να ορίζουν διάφορους δείκτες για τον εαυτό τους. Υπάρχει το Kubernetes με συμπλέγματα και ομάδες που εκθέτουν πολλές μετρήσεις. Αυτό έχει ως αποτέλεσμα οι διακομιστές να εκθέτουν χιλιάδες μοναδικές μετρήσεις ανά κεντρικό υπολογιστή. Έτσι, η μοναδική χρονοσειρά 40K δεν είναι πλέον υψηλή ισχύς. Γίνεται mainstream και θα πρέπει να το χειρίζεται εύκολα οποιοδήποτε σύγχρονο TSDB σε έναν μόνο διακομιστή.
Ποιος είναι ο μεγάλος αριθμός μοναδικών χρονοσειρών αυτή τη στιγμή; Μάλλον 400K ή 4M; Ή 40 μέτρα; Ας συγκρίνουμε τα σύγχρονα TSDB με αυτούς τους αριθμούς.
Εγκατάσταση ενός σημείου αναφοράς
είναι ένα εξαιρετικό εργαλείο συγκριτικής αξιολόγησης για τα TSDB. Σας επιτρέπει να δημιουργήσετε έναν αυθαίρετο αριθμό μετρήσεων περνώντας τον απαιτούμενο αριθμό χρονοσειρών διαιρεμένο με 10 - σημαία (πρώην -scale-var). 10 είναι ο αριθμός των μετρήσεων (μετρήσεων) που δημιουργούνται σε κάθε κεντρικό υπολογιστή ή διακομιστή. Τα ακόλουθα σύνολα δεδομένων δημιουργήθηκαν χρησιμοποιώντας TSBS για το σημείο αναφοράς:
- 400K μοναδικές χρονοσειρές, διάστημα 60 δευτερολέπτων μεταξύ των σημείων δεδομένων, τα δεδομένα εκτείνονται σε 3 ολόκληρες ημέρες, ~1.7B συνολικός αριθμός σημείων δεδομένων.
- Μοναδικές χρονοσειρές 4M, διάστημα 600 δευτερολέπτων, τα δεδομένα εκτείνονται σε 3 ολόκληρες ημέρες, ~1.7B συνολικός αριθμός σημείων δεδομένων.
- Μοναδικές χρονοσειρές 40 εκατομμυρίων, διάστημα 1 ώρας, τα δεδομένα εκτείνονται σε 3 ολόκληρες ημέρες, ~2.8 B συνολικός αριθμός σημείων δεδομένων.
Ο πελάτης και ο διακομιστής λειτουργούσαν σε αποκλειστικές παρουσίες στο Google cloud. Αυτές οι περιπτώσεις είχαν τις ακόλουθες διαμορφώσεις:
- vCPU: 16
- RAM: 60 GB
- Αποθήκευση: Τυπικός σκληρός δίσκος 1 TB. Παρέχει ταχύτητα ανάγνωσης/εγγραφής 120 Mbps, 750 λειτουργίες ανάγνωσης ανά δευτερόλεπτο και 1,5K εγγραφές ανά δευτερόλεπτο.
Τα TSDB εξήχθησαν από επίσημες εικόνες docker και εκτελέστηκαν στο docker με τις ακόλουθες διαμορφώσεις:
-
VictoriaMetrics:
docker run -it --rm -v /mnt/disks/storage/vmetrics-data:/victoria-metrics-data -p 8080:8080 valyala/victoria-metrics -
Απαιτούνται τιμές InfluxDB (-e) για την υποστήριξη υψηλής ισχύος. Δείτε λεπτομέρειες στο ):
docker run -it --rm -p 8086:8086 -e INFLUXDB_DATA_MAX_VALUES_PER_TAG=4000000 -e INFLUXDB_DATA_CACHE_MAX_MEMORY_SIZE=100g -e INFLUXDB_DATA_MAX_SERIES_PER_DATABASE=0 -v /mnt/disks/storage/influx-data:/var/lib/influxdb influxdb -
TimescaleDB (η διαμόρφωση έχει ληφθεί από αρχείο):
MEM=`free -m | grep "Mem" | awk ‘{print $7}’`
let "SHARED=$MEM/4"
let "CACHE=2*$MEM/3"
let "WORK=($MEM-$SHARED)/30"
let "MAINT=$MEM/16"
let "WAL=$MEM/16"
docker run -it — rm -p 5432:5432
--shm-size=${SHARED}MB
-v /mnt/disks/storage/timescaledb-data:/var/lib/postgresql/data
timescale/timescaledb:latest-pg10 postgres
-cmax_wal_size=${WAL}MB
-clog_line_prefix="%m [%p]: [%x] %u@%d"
-clogging_collector=off
-csynchronous_commit=off
-cshared_buffers=${SHARED}MB
-ceffective_cache_size=${CACHE}MB
-cwork_mem=${WORK}MB
-cmaintenance_work_mem=${MAINT}MB
-cmax_files_per_process=100Ο φορτωτής δεδομένων εκτελέστηκε με 16 παράλληλα νήματα.
Αυτό το άρθρο περιέχει αποτελέσματα μόνο για κριτήρια αξιολόγησης εισαγωγής. Τα αποτελέσματα του επιλεκτικού δείκτη αναφοράς θα δημοσιευθούν σε ξεχωριστό άρθρο.
400K μοναδικές χρονοσειρές
Ας ξεκινήσουμε με απλά στοιχεία - 400K. Αποτελέσματα αναφοράς:
- VictoriaMetrics: 2,6 εκατομμύρια σημεία δεδομένων ανά δευτερόλεπτο. Χρήση RAM: 3 GB; τελικό μέγεθος δεδομένων στο δίσκο: 965 MB
- InfluxDB: 1.2M σημεία δεδομένων ανά δευτερόλεπτο. Χρήση RAM: 8.5 GB; τελικό μέγεθος δεδομένων στο δίσκο: 1.6 GB
- Χρονική κλίμακα: 849K σημεία δεδομένων ανά δευτερόλεπτο. Χρήση RAM: 2,5 GB; τελικό μέγεθος δεδομένων στο δίσκο: 50 GB
Όπως μπορείτε να δείτε από τα παραπάνω αποτελέσματα, η VictoriaMetrics κερδίζει σε απόδοση εισαγωγής και λόγο συμπίεσης. Το Timeline κερδίζει στη χρήση RAM, αλλά χρησιμοποιεί πολύ χώρο στο δίσκο - 29 byte ανά σημείο δεδομένων.
Ακολουθούν τα γραφήματα χρήσης της CPU για καθένα από τα TSDB κατά τη διάρκεια της συγκριτικής αξιολόγησης:
Παραπάνω είναι ένα στιγμιότυπο οθόνης: VictoriaMetrics - Φόρτωση CPU κατά τη δοκιμή εισαγωγής για μια μοναδική μέτρηση 400K.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: InfluxDB - Φόρτωση CPU κατά τη δοκιμή εισαγωγής για μοναδική μέτρηση 400K.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: TimescaleDB - Φόρτωση CPU κατά τη δοκιμή εισαγωγής για μια μοναδική μέτρηση 400K.
Το VictoriaMetrics χρησιμοποιεί όλους τους διαθέσιμους vCPU, ενώ το InfluxDB υποχρησιμοποιεί ~2 από 16 vCPU.
Το Timescale χρησιμοποιεί μόνο 3-4 από τις 16 vCPU. Οι υψηλές αναλογίες iowait και συστήματος στο γράφημα χρονικής κλίμακας TimescaleDB υποδεικνύουν μια συμφόρηση στο υποσύστημα εισόδου/εξόδου (I/O). Ας δούμε τα γραφήματα χρήσης εύρους ζώνης δίσκου:
Παραπάνω είναι ένα στιγμιότυπο οθόνης: VictoriaMetrics - Χρήση εύρους ζώνης δίσκου στη δοκιμή εισαγωγής για Unique Metrics 400K.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: InfluxDB - Χρήση εύρους ζώνης δίσκου στη δοκιμή εισαγωγής για Unique Metrics 400K.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: TimescaleDB - Χρήση εύρους ζώνης δίσκου στη δοκιμή εισαγωγής για Unique Metrics 400K.
Η VictoriaMetrics καταγράφει δεδομένα στα 20 Mbps με κορυφές έως και 45 Mbps. Οι κορυφές αντιστοιχούν σε μεγάλες μερικές συγχωνεύσεις στο δέντρο .
Το InfluxDB εγγράφει δεδομένα με ταχύτητα 160 MB/s, ενώ μια μονάδα δίσκου 1 TB ταχύτητα εγγραφής 120 MB/s.
Το TimescaleDB περιορίζεται σε απόδοση εγγραφής 120 Mbps, αλλά μερικές φορές σπάει αυτό το όριο και φτάνει τα 220 Mbps σε τιμές αιχμής. Αυτές οι κορυφές αντιστοιχούν στις κοιλάδες της ανεπαρκούς χρήσης της CPU στο προηγούμενο γράφημα.
Ας δούμε τα γραφήματα χρήσης εισόδου/εξόδου (I/O):
Παραπάνω είναι ένα στιγμιότυπο οθόνης: VictoriaMetrics - Εισαγωγή δοκιμαστικής χρήσης I/O για μοναδικές μετρήσεις 400K.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: InfluxDB - Εισαγωγή δοκιμαστικής χρήσης I/O για μοναδικές μετρήσεις 400K.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: TimescaleDB - Εισαγωγή δοκιμαστικής χρήσης I/O για μοναδικές μετρήσεις 400K.
Είναι πλέον σαφές ότι το TimescaleDB φτάνει στο όριο εισόδου/εξόδου του, επομένως δεν μπορεί να χρησιμοποιήσει τα υπόλοιπα 12 vCPU.
Μοναδικές χρονοσειρές 4M
Οι χρονοσειρές 4M φαίνονται λίγο προκλητικές. Αλλά οι ανταγωνιστές μας περνούν με επιτυχία αυτή την εξέταση. Αποτελέσματα αναφοράς:
- VictoriaMetrics: 2,2 εκατομμύρια σημεία δεδομένων ανά δευτερόλεπτο. Χρήση RAM: 6 GB; τελικό μέγεθος δεδομένων στο δίσκο: 3 GB.
- InfluxDB: 330K σημεία δεδομένων ανά δευτερόλεπτο. Χρήση RAM: 20,5 GB; τελικό μέγεθος δεδομένων στο δίσκο: 18,4 GB.
- TimescaleDB: 480K σημεία δεδομένων ανά δευτερόλεπτο. Χρήση RAM: 2,5 GB; τελικό μέγεθος δεδομένων στο δίσκο: 52 GB.
Η απόδοση του InfluxDB μειώθηκε από 1,2 εκατομμύρια σημεία δεδομένων ανά δευτερόλεπτο για μια χρονοσειρά 400K σε 330K σημεία δεδομένων ανά δευτερόλεπτο για μια χρονοσειρά 4M. Αυτή είναι μια σημαντική απώλεια απόδοσης σε σύγκριση με άλλους ανταγωνιστές. Ας δούμε τα γραφήματα χρήσης της CPU για να κατανοήσουμε τη βασική αιτία αυτής της απώλειας:
Παραπάνω είναι ένα στιγμιότυπο οθόνης: VictoriaMetrics - Χρήση CPU κατά τη δοκιμή εισαγωγής για μια μοναδική χρονοσειρά 4M.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: InfluxDB - Χρήση CPU κατά τη δοκιμή εισαγωγής για μοναδικές χρονοσειρές 4M.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: TimescaleDB - Χρήση CPU κατά τη δοκιμή εισαγωγής για μια μοναδική χρονοσειρά 4M.
Η VictoriaMetrics χρησιμοποιεί σχεδόν όλη την ισχύ της μονάδας επεξεργασίας (CPU). Η πτώση στο τέλος αντιστοιχεί στις υπόλοιπες συγχωνεύσεις LSM μετά την εισαγωγή όλων των δεδομένων.
Το InfluxDB χρησιμοποιεί μόνο 8 από 16 vCPU, ενώ το TimsecaleDB χρησιμοποιεί 4 από 16 vCPU. Τι κοινό έχουν τα γραφήματα τους; Υψηλό μερίδιο iowait, το οποίο υποδηλώνει και πάλι μια συμφόρηση I/O.
Το TimescaleDB έχει υψηλό μερίδιο system. Υποθέτουμε ότι η υψηλή ισχύς είχε ως αποτέλεσμα πολλές ή πολλές κλήσεις συστήματος .
Ας δούμε τα γραφήματα απόδοσης δίσκου:
Παραπάνω είναι ένα στιγμιότυπο οθόνης: VictoriaMetrics - Χρήση εύρους ζώνης δίσκου για την εισαγωγή μοναδικών μετρήσεων 4M.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: InfluxDB - Χρήση εύρους ζώνης δίσκου για την εισαγωγή μοναδικών μετρήσεων 4M.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: TimescaleDB - Χρήση εύρους ζώνης δίσκου για την εισαγωγή μοναδικών μετρήσεων 4M.
Το VictoriaMetrics έφτασε στο όριο των 120 MB/s στο μέγιστο, ενώ η μέση ταχύτητα εγγραφής ήταν 40 MB/s. Είναι πιθανό ότι πραγματοποιήθηκαν αρκετές βαριές συντήξεις LSM κατά τη διάρκεια της αιχμής.
Το InfluxDB αποσπά και πάλι μια μέση απόδοση εγγραφής 200 MB/s με κορυφές έως και 340 MB/s σε δίσκο με όριο εγγραφής 120 MB/s :)
Το TimescaleDB δεν είναι πλέον περιορισμένο στο δίσκο. Φαίνεται να περιορίζεται από κάτι άλλο που σχετίζεται με το υψηλό ποσοστό системной Φορτίο CPU.
Ας δούμε τα γραφήματα χρήσης IO:
Παραπάνω είναι ένα στιγμιότυπο οθόνης: VictoriaMetrics - Χρήση εισόδου/εξόδου κατά τη δοκιμή εισαγωγής για μια μοναδική χρονοσειρά 4M.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: InfluxDB - Χρήση εισόδου/εξόδου κατά τη δοκιμή εισαγωγής για μια μοναδική χρονοσειρά 4M.
Παραπάνω είναι ένα στιγμιότυπο οθόνης: TimescaleDB - Χρήση εισόδου/εξόδου κατά τη δοκιμή εισαγωγής για μοναδικές χρονοσειρές 4M.
Τα μοτίβα χρήσης IO αντικατοπτρίζουν εκείνα του εύρους ζώνης δίσκου - Το InfluxDB είναι περιορισμένο σε IO, ενώ τα VictoriaMetrics και TimescaleDB διαθέτουν εφεδρικούς πόρους IO.
40M μοναδική χρονοσειρά
40 εκατομμύρια μοναδικές χρονικές σειρές ήταν πολύ μεγάλες για το InfluxDB :)
Αποτελέσματα αναφοράς:
- VictoriaMetrics: 1,7 εκατομμύρια σημεία δεδομένων ανά δευτερόλεπτο. Χρήση RAM: 29 GB; Χρήση χώρου στο δίσκο: 17 GB.
- InfluxDB: Δεν ολοκληρώθηκε γιατί απαιτούσε περισσότερα από 60 GB μνήμης RAM.
- TimescaleDB: 330K σημεία δεδομένων ανά δευτερόλεπτο, χρήση RAM: 2,5 GB. Χρήση χώρου στο δίσκο: 84 GB.
Το TimescaleDB δείχνει εξαιρετικά χαμηλή και σταθερή χρήση RAM στα 2,5 GB - το ίδιο όπως και για τις μοναδικές μετρήσεις 4M και 400K.
Το VictoriaMetrics κλιμακώθηκε αργά με ρυθμό 100 σημείων δεδομένων ανά δευτερόλεπτο έως ότου υποβληθούν σε επεξεργασία και τα 40 εκατομμύρια ονόματα μετρικών με ετικέτες. Στη συνέχεια πέτυχε έναν σταθερό ρυθμό εισαγωγής 1,5-2,0 M σημείων δεδομένων ανά δευτερόλεπτο, έτσι το τελικό αποτέλεσμα ήταν 1,7 εκατομμύρια σημεία δεδομένων ανά δευτερόλεπτο.
Τα γραφήματα για μοναδικές χρονοσειρές 40M είναι παρόμοια με τα γραφήματα για μοναδικές χρονοσειρές 4M, οπότε ας τα παραλείψουμε.
Ευρήματα
- Τα σύγχρονα TSDB είναι ικανά να επεξεργάζονται ένθετα για εκατομμύρια μοναδικές χρονοσειρές σε έναν μόνο διακομιστή. Στο επόμενο άρθρο, θα δοκιμάσουμε πόσο καλά εκτελεί η επιλογή των TSDBs σε εκατομμύρια μοναδικές χρονολογικές σειρές.
- Η ανεπαρκής χρήση της CPU συνήθως υποδηλώνει μια συμφόρηση I/O. Μπορεί επίσης να υποδεικνύει ότι το μπλοκάρισμα είναι πολύ χονδροειδές, με μόνο μερικά νήματα να μπορούν να εκτελούνται κάθε φορά.
- Το σημείο συμφόρησης εισόδου/εξόδου υπάρχει, ειδικά σε αποθηκευτικό χώρο χωρίς SSD, όπως εικονικές συσκευές μπλοκ παρόχων cloud.
- Η VictoriaMetrics παρέχει την καλύτερη βελτιστοποίηση για αργή, χαμηλή αποθήκευση I/O. Παρέχει την καλύτερη ταχύτητα και τον καλύτερο λόγο συμπίεσης.
Κατεβάστε και δοκιμάστε το στα δεδομένα σας. Το αντίστοιχο στατικό δυαδικό είναι διαθέσιμο στο .
Διαβάστε περισσότερα για τη VictoriaMetrics σε αυτό .
Ενημέρωση: δημοσιευμένη με αναπαραγώγιμα αποτελέσματα.
Ενημέρωση #2: Διαβάστε επίσης .
Ενημέρωση #3: !
Συνομιλία Telegram:
Πηγή: www.habr.com