Εάν χρησιμοποιείτε βάση δεδομένων χρονοσειρών (timeseries db, ) ως κύριο αποθηκευτικό χώρο για έναν ιστότοπο με στατιστικά στοιχεία, τότε αντί να λύσετε το πρόβλημα, μπορείτε να έχετε πολλούς πονοκεφάλους. Εργάζομαι σε ένα έργο που χρησιμοποιεί μια τέτοια βάση δεδομένων και μερικές φορές το InfluxDB, το οποίο θα συζητηθεί, παρουσίαζε γενικά απροσδόκητες εκπλήξεις.
Αποποίηση ευθυνώνΣημείωση: Τα ζητήματα που εμφανίζονται αφορούν το InfluxDB 1.7.4.
Γιατί χρονοσειρές;
Το έργο είναι η παρακολούθηση συναλλαγών σε διάφορες αλυσίδες μπλοκ και η εμφάνιση στατιστικών στοιχείων. Συγκεκριμένα, εξετάζουμε την εκπομπή και την καύση σταθερών νομισμάτων (). Με βάση αυτές τις συναλλαγές, πρέπει να δημιουργήσετε γραφήματα και να εμφανίσετε συγκεντρωτικούς πίνακες.
Κατά την ανάλυση των συναλλαγών, προέκυψε μια ιδέα: να χρησιμοποιηθεί η βάση δεδομένων χρονοσειρών InfluxDB ως κύρια αποθήκευση. Οι συναλλαγές είναι χρονικά σημεία και ταιριάζουν καλά στο μοντέλο χρονοσειρών.
Οι λειτουργίες συνάθροισης φαίνονται επίσης πολύ βολικές - είναι ιδανικές για την επεξεργασία γραφημάτων με μεγάλη περίοδο. Ο χρήστης χρειάζεται ένα γράφημα για ένα χρόνο και η βάση δεδομένων περιέχει ένα σύνολο δεδομένων με χρονικό πλαίσιο πέντε λεπτών. Είναι άσκοπο να του στείλετε και τους εκατό χιλιάδες πόντους - εκτός από μια μακρά επεξεργασία, δεν θα χωρέσουν στην οθόνη. Μπορείτε να γράψετε τη δική σας υλοποίηση για την αύξηση του χρονικού πλαισίου ή να χρησιμοποιήσετε τις συναρτήσεις συγκέντρωσης που είναι ενσωματωμένες στο Influx. Με τη βοήθειά τους, μπορείτε να ομαδοποιήσετε δεδομένα ανά ημέρα και να στείλετε τους επιθυμητούς 365 βαθμούς.
Ήταν λίγο ενοχλητικό το γεγονός ότι τέτοιες βάσεις δεδομένων χρησιμοποιούνται συνήθως για τη συλλογή μετρήσεων. Παρακολούθηση διακομιστών, συσκευών iot, οτιδήποτε από το οποίο «ρέουν» εκατομμύρια σημεία της μορφής: [<χρόνος> - <μετρική τιμή>]. Αλλά εάν η βάση δεδομένων λειτουργεί καλά με μια μεγάλη ροή δεδομένων, τότε γιατί ένας μικρός όγκος να προκαλεί προβλήματα; Με αυτή τη σκέψη, χρησιμοποίησαν το InfluxDB.
Τι άλλο είναι βολικό στο InfluxDB
Εκτός από τις αναφερόμενες συναρτήσεις συγκέντρωσης, υπάρχει ένα άλλο υπέροχο πράγμα - συνεχείς ερωτήσεις (). Αυτός είναι ένας προγραμματιστής ενσωματωμένος στη βάση δεδομένων που μπορεί να επεξεργαστεί δεδομένα σε ένα χρονοδιάγραμμα. Για παράδειγμα, μπορείτε να ομαδοποιήσετε όλες τις εγγραφές για την ημέρα κάθε 24 ώρες, να υπολογίσετε τον μέσο όρο και να γράψετε ένα νέο σημείο σε έναν άλλο πίνακα χωρίς να γράψετε τα δικά σας ποδήλατα.
Υπάρχει επίσης πολιτικές διατήρησης () - ρύθμιση για τη διαγραφή δεδομένων μετά από μια ορισμένη περίοδο. Είναι χρήσιμο όταν, για παράδειγμα, πρέπει να αποθηκεύσετε το φορτίο στη CPU για μια εβδομάδα με μετρήσεις μία φορά το δευτερόλεπτο, αλλά σε απόσταση μερικών μηνών, δεν απαιτείται τέτοια ακρίβεια. Σε μια τέτοια περίπτωση, μπορείτε να κάνετε αυτό:
- Δημιουργήστε ένα συνεχές ερώτημα για τη συγκέντρωση δεδομένων σε έναν άλλο πίνακα.
- για τον πρώτο πίνακα, ορίστε μια πολιτική για τη διαγραφή μετρήσεων που είναι παλαιότερες από την ίδια εβδομάδα.
Και το Influx θα μειώσει το μέγεθος των δεδομένων και θα διαγράψει από μόνο του τα περιττά δεδομένα.
Σχετικά με τα αποθηκευμένα δεδομένα
Δεν αποθηκεύονται πολλά δεδομένα: περίπου 70 χιλιάδες συναλλαγές και άλλα εκατομμύρια σημεία με πληροφορίες αγοράς. Προσθήκη νέων καταχωρήσεων - όχι περισσότεροι από 3000 πόντους την ημέρα. Υπάρχουν επίσης μετρήσεις για τον ιστότοπο, αλλά υπάρχουν λίγα δεδομένα και, σύμφωνα με την πολιτική διατήρησης, αποθηκεύονται για όχι περισσότερο από ένα μήνα.
Προβλήματα
Κατά την ανάπτυξη και τις επακόλουθες δοκιμές της υπηρεσίας, εμφανίστηκαν όλο και περισσότερα κρίσιμα προβλήματα στη λειτουργία του InfluxDB.
1. Διαγραφή δεδομένων
Υπάρχει μια σειρά δεδομένων με συναλλαγές:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Το αποτέλεσμα:
Στέλνω μια εντολή για διαγραφή δεδομένων:
DELETE FROM transactions WHERE symbol=’USDT’Περαιτέρω κάνω αίτημα για απόκτηση ήδη διαγραμμένων δεδομένων. Και το Influx, αντί για κενή απόκριση, επιστρέφει ένα τμήμα δεδομένων που πρέπει να αφαιρεθεί.
Προσπαθώ να διαγράψω ολόκληρο τον πίνακα:
DROP MEASUREMENT transactionsΕλέγχω τη διαγραφή του πίνακα:
SHOW MEASUREMENTSΔεν βλέπω τον πίνακα στη λίστα, αλλά το νέο ερώτημα δεδομένων εξακολουθεί να επιστρέφει το ίδιο σύνολο συναλλαγών.
Το πρόβλημα μου προέκυψε μόνο μία φορά, αφού η περίπτωση διαγραφής είναι μεμονωμένη περίπτωση. Αλλά αυτή η συμπεριφορά της βάσης δεδομένων σαφώς δεν εντάσσεται στο πλαίσιο της «σωστής» δουλειάς. Αργότερα το github βρέθηκε ανοιχτό σχεδόν ενός έτους σε αυτό το θέμα.
Ως αποτέλεσμα, βοήθησε η αφαίρεση και η επακόλουθη αποκατάσταση ολόκληρης της βάσης δεδομένων.
2. Αριθμοί κινητής υποδιαστολής
Οι μαθηματικοί υπολογισμοί που χρησιμοποιούν τις ενσωματωμένες συναρτήσεις του InfluxDB δίνουν σφάλματα ακριβείας. Όχι ότι ήταν κάτι ασυνήθιστο, αλλά δυσάρεστο.
Στην περίπτωσή μου, τα δεδομένα έχουν οικονομική συνιστώσα και θα ήθελα να τα επεξεργαστώ με μεγάλη ακρίβεια. Εξαιτίας αυτού, σχεδιάζουμε να εγκαταλείψουμε τα συνεχή ερωτήματα.
3. Τα συνεχή ερωτήματα δεν μπορούν να προσαρμοστούν σε διαφορετικές ζώνες ώρας
Η υπηρεσία διαθέτει πίνακα με στατιστικά καθημερινών συναλλαγών. Για κάθε ημέρα, πρέπει να ομαδοποιήσετε όλες τις συναλλαγές για εκείνη την ημέρα. Αλλά η ημέρα για κάθε χρήστη θα ξεκινά σε διαφορετική ώρα, επομένως, το σύνολο των συναλλαγών είναι διαφορετικό. UTC είναι βάρδιες για τις οποίες θέλετε να συγκεντρώσετε δεδομένα.
Στο InfluxDB, κατά την ομαδοποίηση κατά ώρα, μπορείτε επιπλέον να καθορίσετε μια μετατόπιση, για παράδειγμα, για την ώρα Μόσχας (UTC + 3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Αλλά το αποτέλεσμα του ερωτήματος θα είναι λανθασμένο. Για κάποιο λόγο, τα δεδομένα που ομαδοποιούνται ανά ημέρα θα ξεκινήσουν ήδη από το 1677 (το InfluxDB υποστηρίζει επίσημα ένα χρονικό διάστημα από φέτος):
Για να παρακάμψετε αυτό το πρόβλημα, η υπηρεσία μεταφέρθηκε προσωρινά στο UTC + 0.
4. Απόδοση
Υπάρχουν πολλά σημεία αναφοράς στο Διαδίκτυο με συγκρίσεις του InfluxDB και άλλων βάσεων δεδομένων. Με την πρώτη ματιά, έμοιαζαν με υλικά μάρκετινγκ, αλλά τώρα νομίζω ότι υπάρχει κάποια αλήθεια σε αυτά.
Επιτρέψτε μου να σας πω την περίπτωσή μου.
Η υπηρεσία παρέχει μια μέθοδο API που επιστρέφει στατιστικά στοιχεία για τις τελευταίες XNUMX ώρες. Κατά τη διάρκεια των υπολογισμών, η μέθοδος θέτει ερωτήματα στη βάση δεδομένων τρεις φορές με τα ακόλουθα ερωτήματα:
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCΕξήγηση:
- Στο πρώτο αίτημα, λαμβάνουμε τους πιο πρόσφατους πόντους για κάθε νόμισμα με δεδομένα αγοράς. Οκτώ τελείες για οκτώ νομίσματα στην περίπτωσή μου.
- Το δεύτερο αίτημα λαμβάνει έναν νεότερο βαθμό.
- Το τρίτο ζητά μια λίστα συναλλαγών για τις τελευταίες XNUMX ώρες, μπορεί να υπάρχουν αρκετές εκατοντάδες από αυτές.
Επιτρέψτε μου να διευκρινίσω ότι στο InfluxDB, ένα ευρετήριο δημιουργείται αυτόματα από ετικέτες και με χρόνο, γεγονός που επιταχύνει τα ερωτήματα. Στο πρώτο αίτημα σύμβολο είναι μια ετικέτα.
Έκανα ένα stress test για αυτήν τη μέθοδο API. Για 25 RPS, ο διακομιστής έδειξε ένα πλήρες φορτίο έξι CPU:
Ταυτόχρονα, η διαδικασία NodeJs δεν έδωσε κανένα απολύτως φορτίο.
Η ταχύτητα εκτέλεσης μειώθηκε ήδη κατά 7-10 RPS: εάν ένας πελάτης μπορούσε να λάβει απάντηση σε 200 ms, τότε 10 πελάτες έπρεπε να περιμένουν για ένα δευτερόλεπτο. 25 RPS - το όριο από το οποίο υπέφερε η σταθερότητα, 500 σφάλματα επιστράφηκαν στους πελάτες.
Με τέτοιες επιδόσεις, είναι αδύνατο να χρησιμοποιήσουμε το Influx στο έργο μας. Επιπλέον, σε ένα έργο όπου η παρακολούθηση πρέπει να επιδεικνύεται σε πολλούς πελάτες, ενδέχεται να εμφανιστούν παρόμοια προβλήματα και ο διακομιστής μετρήσεων θα υπερφορτωθεί.
Παραγωγή
Το πιο σημαντικό συμπέρασμα από την εμπειρία που αποκτήθηκε είναι ότι δεν μπορείτε να συμπεριλάβετε μια άγνωστη τεχνολογία σε ένα έργο χωρίς επαρκή ανάλυση. Μια απλή εξέταση ανοιχτών εισιτηρίων στο github θα μπορούσε να παρέχει πληροφορίες για να μην ληφθεί το InfluxDB ως η κύρια αποθήκευση δεδομένων.
Το InfluxDB έπρεπε να ταιριάζει καλά στις εργασίες του έργου μου, αλλά όπως έδειξε η πρακτική, αυτή η βάση δεδομένων δεν ανταποκρίνεται στις ανάγκες και αναστατώνει πολύ.
Μπορείτε ήδη να βρείτε την έκδοση 2.0.0-beta στο αποθετήριο του έργου, μένει να ελπίζουμε ότι θα υπάρξουν σημαντικές βελτιώσεις στη δεύτερη έκδοση. Εν τω μεταξύ, θα πάω να μελετήσω την τεκμηρίωση του TimescaleDB.
Πηγή: www.habr.com