SQL vs Flux: Επιλογή της σωστής γλώσσας ερωτήματος για δεδομένα χρονοσειρών

Μια εξέταση των πλεονεκτημάτων και των αδυναμιών της SQL και γιατί υπάρχουν οι σχεδιαστές επερωτήσεων, μέσω της σύγκρισης των TimescaleDB και InfluxDB

Γενικά στον κόσμο των γλωσσών ερωτημάτων βάσης δεδομένων, υπήρξαν δύο άκρα: πλήρης υποστήριξη SQL στο ένα άκρο και πλήρως προσαρμοσμένες γλώσσες (μερικές φορές γνωστές ως "NoSQL") από την άλλη.

Με τις βάσεις δεδομένων σειράς χρόνου, οι διαφορές μεταξύ αυτών των γλωσσών μπορούν να φανούν συγκρίνοντας το TimescaleDB και το InfluxDB.

Από την αρχή, το TimescaleDB υπήρξε σταθερό στο τέλος του SQL του φάσματος, ενσωματώνοντας πλήρως τη γλώσσα από την πρώτη ημέρα και αργότερα την επέκτεινε για να απλοποιήσει την ανάλυση της χρονοσειράς. Αυτό επέτρεψε στο TimescaleDB να απαιτήσει καμπύλη μηδενικής μάθησης για νέους χρήστες και του επέτρεψε να κληρονομήσει ολόκληρο το οικοσύστημα SQL των εργαλείων, των συνδέσμων και των επιλογών οπτικοποίησης τρίτου μέρους, το οποίο είναι μεγαλύτερο από αυτό οποιασδήποτε άλλης βάσης δεδομένων χρονολογικών σειρών.

Αντίθετα, το InfluxDB ξεκίνησε με μια γλώσσα αναζήτησης τύπου "SQL" (που ονομάζεται InfluxQL), τοποθετώντας τη στη μέση του φάσματος και πρόσφατα έκανε μια αξιοσημείωτη κίνηση προς το "προσαρμοσμένο" τέλος με τη νέα γλώσσα ερωτημάτων Flux. Αυτό επέτρεψε στην InfluxDB να δημιουργήσει μια νέα γλώσσα επερωτήσεων που οι δημιουργοί της θα υποστηρίζουν ότι ξεπερνιέται κάποιες ελλείψεις SQL που έχουν βιώσει. (Διαβάστε την ανακοίνωση ροής και την αντίδραση των ειδήσεων Hacker.)

Έτσι πώς συγκρίνουν αυτές οι δύο γλώσσες ερωτήσεων;

Για να αναλύσουμε τις διαφορές μεταξύ SQL και Flux, ας δούμε πρώτα γιατί η ομάδα InfluxDB δημιούργησε Flux, σε αντίθεση με την αγκαλιά της SQL.

Σύμφωνα με αυτό το post, το InfluxDB δημιούργησε Flux κυρίως για δύο λόγους:

  1. Υποστήριξη ερωτήματος: Συμπέρανε ότι η SQL δεν μπόρεσε εύκολα να χειριστεί τους τύπους των ερωτημάτων που θέλησαν να τρέξουν σε δεδομένα χρονολογικών σειρών.
  2. Σχεσιακή άλγεβρα έναντι λειτουργικής επεξεργασίας που βασίζεται στη ροή: Θεωρούσαν ότι μια γλώσσα ερωτημάτων της σειράς χρόνου απαιτούσε ένα λειτουργικό μοντέλο βασισμένο σε ροή, σε αντίθεση με το μοντέλο σχεσιακής άλγεβρας στην SQL.

(Υπάρχει επίσης ένας τρίτος λόγος που δηλώνεται στη θέση: ότι η SQL επινοήθηκε τη δεκαετία του 1970. Αυτό το σημείο είναι περίεργο, λαμβάνοντας ιδιαίτερα υπόψη ότι άλλες γενετικές τεχνολογίες γεννήθηκαν επίσης στην ίδια εποχή: τη σχεσιακή βάση δεδομένων, τον μικροεπεξεργαστή και το Διαδίκτυο. οι τεχνολογίες, όπως το SQL, έχουν εξελιχθεί σημαντικά από την αρχική τους εφεύρεση, ενώ άλλες τεχνολογίες δεν έχουν. Επίσης, κοινές σύγχρονες γλώσσες, όπως τα αγγλικά, "εφευρέθηκαν" πριν από εκατοντάδες χρόνια, έχουν επίσης εξελιχθεί με την πάροδο του χρόνου, ενώ άλλες γλώσσες έχουν πέσει Επομένως, πιστεύουμε ότι η δεκαετία κατά την οποία εφευρέθηκε κάτι είναι άσχετη με τη συζήτηση αυτή. Με αυτό το πνεύμα, θα επιστρέψουμε στην κύρια συζήτηση.)

Ας ξεδιπλώσουμε και τους δύο αυτούς λόγους.

Υποστήριξη ερωτήματος

Εδώ είναι το κανονικό παράδειγμα που χρησιμοποιεί η InfluxDB στη θέση του, που υπολογίζει έναν εκθετικό κινητό μέσο (EMA), για να υποστηρίξει την αξίωσή τους:

Ροή:

από (db: "telegraf")
|> εύρος (αρχή: -1ωρο)
|> φίλτρο (fn: (r) => r._measurement == "foo")
|> εκθετικήMovingAverage (μέγεθος: -10s)

Οι συντάκτες των μηνυμάτων προσπαθούν να γράψουν αυτό το ερώτημα σε SQL και αντ 'αυτού να παράγουν ένα αρκετά περίπλοκο ερώτημα που υπολογίζει ένα απλό κινούμενο μέσο όρο:

SQL 1:

επιλέξτε id,
       θερμοκρασία,
       avg (temp) over (κατάτμηση κατά group_nr με βάση το time_read) ως rolling_avg
από (
  επιλέξτε id,
         θερμοκρασία,
         time_read,
         interval_group,
         id - row_number () πάνω από (κατά μερίδα ανά σειρά_ομάδας ταξινόμησης κατά time_read) ως group_nr
  από (
     επιλέξτε id,
            time_read,
            'epoch' :: timestamp + '900 δευτερόλεπτα' :: διάστημα * (απόσπασμα (epoch from time_read) :: int4 / 900) ως interval_group,
            temp
     από τις αναγνώσεις
  ) t1
) t2
σειρά από time_read;

Ναι, αυτό το παράδειγμα SQL είναι αρκετά λεπτομερής και υπολογίζει μόνο ένα μέρος της επιθυμητής εξόδου (δηλ. Υπολογίζει μόνο ένα κινούμενο μέσο όρο και όχι έναν εκθετικό κινούμενο μέσο όρο). Ως αποτέλεσμα, το επιχείρημά τους είναι ότι τα κοινά ερωτήματα που σχετίζονται με την χρονολογική σειρά (όπως το υπολογισμό ενός EMA) είναι αρκετά περίπλοκα στην SQL.

Θεωρούμε αυτό το επιχείρημα λανθασμένο για έναν βασικό λόγο. Ο μόνος τρόπος με τον οποίο η Flux θα μπορούσε να υποστηρίξει αυτή τη λειτουργία είναι αν οι δημιουργοί της έγραψαν τη δική τους εκθετικήMovingAverage () λειτουργία.

Κάποιος μπορεί επίσης να γράψει την ίδια λειτουργία στη σύγχρονη SQL, δημιουργώντας ένα προσαρμοσμένο σύνολο. Η δημιουργία ενός προσαρμοσμένου συνόλου υποστηρίζεται στις περισσότερες σύγχρονες υλοποιήσεις SQL, συμπεριλαμβανομένης της PostgreSQL. Η σύνταξη στην PostgreSQL είναι η ακόλουθη (μέσω StackOverflow):

SQL: Δημιουργία του προσαρμοσμένου αθροίσματος

Δημιουργία ή ΑΝΤΙΚΑΤΑΣΤΑΣΗ ΛΕΙΤΟΥΡΓΙΑΣ exponential_moving_average_sfunc
(αριθμητική κατάσταση, επόμενη αριθμητική, αλφαριθμητική)
RETURNS αριθμητική γλώσσα SQL AS
$$
ΕΠΙΛΕΓΩ
         ΥΠΟΘΕΣΗ
                WHEN η κατάσταση είναι NULL THEN next_value
                ELSE άλφα * επόμενη_τιμή + (1-άλφα) * κατάσταση
         ΤΕΛΟΣ
$$;
CREATE AGGREGATE exponential_moving_average (αριθμητική, αριθμητική)
(sfunc = exponential_moving_average_sfunc, stype = αριθμητικό);

(Αυτή είναι μια απλή συνάρτηση SQL συνόλων παράθυρο που υπολογίζει τον εκθετικό κινούμενο μέσο όρο.Αυτή είναι μια συνθετική συνάρτηση επειδή παίρνει πολλές γραμμές εισόδου και είναι μια συνάρτηση παραθύρου επειδή υπολογίζει μια τιμή για κάθε γραμμή εισόδου.Στην σύγκριση, θα ήταν μια συνάθροιση αλλά όχι μια συνάρτηση παραθύρου, ενώ η σύγκριση του δέλτα μεταξύ δύο σειρών θα ήταν μια συνάρτηση παραθύρου αλλά όχι ένα σύνολο. Ναι, η SQL είναι ισχυρή.)

Στη συνέχεια, η ερώτηση για τον εκθετικό κινούμενο μέσο όρο ολόκληρου του συνόλου δεδομένων μπορεί να είναι μάλλον απλή:

SQL 2:

SELECT time,
       exponential_moving_average (τιμή, 0.5) OVER (ΠΑΡΑΓΓΕΛΙΑ ΚΑΤΑ ΤΟ ΧΡΟΝΟ)
Από τηλέγραφο
WHERE μέτρηση = 'foo' και χρόνος> τώρα () - '1 ώρα';

Αυτή η λειτουργία σας επιτρέπει επίσης να υπολογίσετε το EMA όχι μόνο κατά τη διάρκεια του χρόνου αλλά και από οποιαδήποτε άλλη στήλη (π.χ. "σύμβολο"). Στο παρακάτω παράδειγμα, υπολογίζουμε το EMA για κάθε διαφορετικό σύμβολο μετοχών με την πάροδο του χρόνου:

SQL 3:

SELECT ημερομηνία,
       σύμβολο,
       exponential_moving_average (όγκος, 0.5) OVER (
         PARTITION BY σύμβολο ORDER BY date ASC)
Από τηλέγραφο
WHERE μέτρηση = 'foo' και χρόνος> τώρα () - '1 ώρα'
ORDER BY ημερομηνία, σύμβολο;

(Μπορείτε να δείτε περισσότερα σε αυτό το SQL Fiddle.)

Ναι, η σύνταξη μιας νέας λειτουργίας απαιτεί κάποια εργασία, αλλά λιγότερη εργασία από την εκμάθηση μιας εντελώς νέας γλώσσας, για να μην αναφέρουμε ότι αναγκάζετε όλους τους άλλους (που θα μπορούσαν απλά να χρησιμοποιήσουν την ίδια λειτουργία) για να μάθουν αυτή τη γλώσσα.

Ως προγραμματιστές μιας βάσης δεδομένων, θα υποστηρίζαμε επίσης ότι η σύνταξη μιας νέας λειτουργίας SQL απαιτεί πολύ λιγότερη εργασία απ ​​'ό, τι η γραφή μιας νέας γλώσσας ερωτήματος από την αρχή. Ειδικά αν σκεφτεί κανείς ότι ακόμα και μετά τη σύνταξη της γλώσσας, θα χρειαστεί ακόμα να γράψουμε την ίδια συγκεκριμένη λειτουργία (κάτι που έκαναν οι δημιουργοί Flux).

Δεδομένου του μεγάλου συνόλου προηγούμενων προσπαθειών στο SQL για την εκτέλεση εργασιών όπως ο υπολογισμός ενός EMA (όπως το StackOverflow) και δεδομένης της επεκτασιμότητας της SQL, θα υποστηρίζαμε επίσης ότι η δαπάνη περισσότερου χρόνου στη SQL θα ήταν καλύτερη απόδοση της επένδυσης παρά μάθηση ή ακόμα και ανάπτυξη μιας νέας γλώσσας ερωτήματος από την αρχή, πόσο μάλλον να αναγκάσει όλους τους μελλοντικούς χρήστες της βάσης δεδομένων να μάθουν επίσης αυτή τη γλώσσα.

Τι γίνεται με τη φρασεολογία;

Θα μπορούσε κανείς να υποστηρίξει ότι η σύνταξη Flux είναι ελαφρώς λιγότερο λεπτομερή από τη σύνταξη SQL. Αλλά αναγκάζοντας τους χρήστες να μάθουν μια νέα γλώσσα ερωτήματος, ώστε να μπορούν να αποθηκεύσουν μερικές πληκτρολογήσεις όταν γράφουν τα ερωτήματά τους, αισθάνεται σαν λάθος συμβιβασμός. Ο προγραμματισμός της πολυπλοκότητας των γλωσσών δεν αφορά πραγματικά τον αριθμό των πληκτρολογήσεων ενός τύπου αλλά την ψυχική επιβάρυνση: για παράδειγμα, ένα πρόγραμμα 1 γραμμής σε μια γλώσσα μπορεί στην πραγματικότητα να είναι πιο δύσκολο και χρονοβόρο να γράφει (και να διατηρεί) 5 γραμμών σε άλλη γλώσσα.

Τι γίνεται με το πρότυπο SQL;

Θα μπορούσαμε επίσης να υποστηρίξουμε ότι η δημιουργία νέων λειτουργιών (ή aggregates) σπάει το πρότυπο SQL. Η κατοχή ενός προτύπου είναι πολύτιμη για δύο λόγους: τη φορητότητα του κώδικα και την επαναχρησιμοποίηση δεξιοτήτων. Εδώ διαπιστώνουμε ότι η επέκταση της SQL εξακολουθεί να είναι μια ανώτερη διαδρομή από τη χρήση μιας νέας γλώσσας ερωτήματος. Κατά τη δημιουργία νέων λειτουργιών στο SQL μειώνει τη φορητότητα του κώδικα, κάνει πολύ λιγότερο από την υιοθέτηση μιας μη τυποποιημένης γλώσσας. Και επειδή η σύνταξη των νέων λειτουργιών είναι αρκετά παρόμοια (αν όχι ισοδύναμη) με το πρότυπο, επιτρέπει στους χρήστες της βάσης δεδομένων να αξιοποιούν τις υπάρχουσες γνώσεις τους από άλλα συστήματα, κάτι που δεν θα ήταν δυνατό με μια μη τυπική γλώσσα. Και η εκτατότητα SQL σας επιτρέπει να διαμορφώσετε τη γλώσσα γύρω από τον τομέα προβλημάτων σας.

Σχεσιακή άλγεβρα έναντι λειτουργικής επεξεργασίας με βάση τη ροή

Ο άλλος λόγος που αναφέρει η InfluxDB για την ανάπτυξη του Flux είναι ότι ήθελαν μια γλώσσα που επεξεργάστηκε τα δεδομένα σε λειτουργικό μοντέλο βασισμένο σε ροή, έναντι SQL που βασίζεται σε σχεσιακή άλγεβρα και σύνολα.

Για παράδειγμα, οι δημιουργοί ροής ήθελαν να αλυσοδέσουν εύκολα τα βήματα επεξεργασίας ερωτημάτων με έναν αυξητικό τρόπο. Το επιχείρημά τους είναι ότι οι πράξεις αλυσοποίησης και η δημιουργία πρόσθετων ερωτημάτων δεν είναι εύκολη στην SQL. Στην ροή, αυτή η αλυσιδωτή σύνδεση δημιουργείται από τον χειριστή του σωλήνα προς τα εμπρός ("|>"). Η ροή επιτρέπει επίσης την εκτέλεση αυθαίρετου κώδικα σε κάθε βήμα του αγωγού (π.χ. ο χειριστής φίλτρου στο παραπάνω παράδειγμα).

Διαπιστώνουμε ότι αυτό το επιχείρημα έχει κάποια αξία, αλλά όχι χωρίς συμβιβασμούς.

Πρώτον, συμφωνούμε ότι η εγγραφή των αυξανόμενων ερωτημάτων στην SQL δεν είναι τόσο εύκολη όσο η αλυσιδωτή εξαγωγή από μια συνάρτηση σε άλλη (αν και οι υπο-SELECTs και οι Κοινές εκφράσεις πίνακα καθιστούν αυτό ευκολότερο). Η ενημέρωση ενός ερωτήματος απαιτεί τυπικά κάποια επαναδιατύπωση.

Ωστόσο, αυτός ο περιορισμός δεν είναι αυθαίρετος, αλλά υπάρχει για έναν καλό λόγο: μια γλώσσα ερωτήματος που προδιαγράφει μια παραγγελία πράξεων εγγενώς αποδυναμώνει την ικανότητα της βάσης δεδομένων να κάνει τη δουλειά της.

Η δύναμη των πράξεων αναδιάταξης

Μια από τις πιο χρήσιμες βελτιστοποιήσεις μιας βάσης δεδομένων, μέσω ενός προγραμματιστή επερωτήσεων, είναι η αναδιάταξη των λειτουργιών για την επίτευξη ταχύτερης εκτέλεσης ερωτήματος. Αυτό επιτρέπει στον προγραμματιστή να αναλύσει ένα ερώτημα, τα δεδομένα και οποιεσδήποτε σχετικές δομές δεδομένων (π.χ. ευρετήρια) και να επεξεργαστεί τις επερωτήσεις για να επιτύχει ταχύτερη εκτέλεση. Αλλά για να γίνει αυτό, ο προγραμματιστής επερωτήσεων πρέπει να γνωρίζει ότι οι εργασίες αναδιάταξης δεν θα αλλάξουν την έξοδο.

Στην SQL, οι χρήστες λένε στη βάση δεδομένων ποια ερώτηση θέλουν να απαντήσουν (χωρίς καμία ιδέα για την παραγγελία πράξεων) και αφήστε τη βάση δεδομένων να εκτελέσει τη βέλτιστη διαδρομή για την επιστροφή της απάντησης. (Στην PostgreSQL, οι χρήστες εμπιστεύονται τον προγραμματιστή επερωτήσεων για να το κάνουν αυτό.)

Ακολουθεί ένα παράδειγμα (χρησιμοποιώντας το SQL 2 από πριν): Θέλω τον εκθετικό σταθμισμένο κινητό μέσο όρο foo κατά την τελευταία ώρα να ομαδοποιούνται ανά διαστήματα 10 δευτερολέπτων, αλλά θέλω η βάση δεδομένων να υπολογίσει την απάντηση σε ό, τι καθορίζει είναι ο βέλτιστος τρόπος. Για να απαντήσουμε σε αυτό το αίτημα, η βάση δεδομένων μπορεί να αποφασίσει να χρησιμοποιήσει ένα ευρετήριο για το metric = fooand στη συνέχεια να φιλτράρει την τελευταία ώρα ή, εναλλακτικά, να χρησιμοποιήσει ένα δείκτη για την τελευταία ώρα και στη συνέχεια να φιλτράρει μετρικά = foo.

Με το Flux, οι χρήστες λένε στη βάση δεδομένων όχι μόνο την ερώτηση που θέλουν να απαντήσουν, αλλά και τη σειρά με την οποία θα επεξεργαστούν τα δεδομένα για να παραγάγουν το αποτέλεσμα. Στο παράδειγμα ροής: Επιλέξτε όλα τα δεδομένα την προηγούμενη ώρα. στη συνέχεια φιλτράρετε για μια δεδομένη μέτρηση. τότε υπολογίστε τον εκθετικό κινούμενο μέσο όρο της εν λόγω μετρικής ομαδοποιημένης ανά διαστήματα 10 δευτερολέπτων. Αυτό περιορίζει τον προγραμματιστή επερωτήσεων για να φιλτράρει πρώτα τα δεδομένα κατά την πρώτη ώρα (ίσως χρησιμοποιώντας ένα ευρετήριο) και έπειτα να φιλτράρει μετρικά.

Δεν ήταν δυνατή η αναδιάταξη του σχετικού ερωτήματος από τον προγραμματιστή ροής; Η απάντηση δεν είναι πάντοτε. Το Flux σχεδιάζεται να είναι μια γλώσσα δέσμης ενεργειών, όχι μόνο μια γλώσσα ερωτήματος, που σημαίνει ότι επιτρέπει αυθαίρετες λειτουργίες (δηλαδή, όχι μόνο καθαρές λειτουργίες). Οι αυθαίρετες λειτουργίες μπορούν να έχουν παρενέργειες που εμποδίζουν την αναδιάταξη. (Για παράδειγμα, αν μια λειτουργία πυροδοτεί συμβάντα ή ειδοποιήσεις σε ένα άλλο σύστημα, θα ήταν λάθος η αναδιάταξή της, καθώς τότε το άλλο σύστημα θα λάμβανε διαφορετική σειρά παραγγελιών).

Η διαφορά ανέρχεται σε αυτό: σε σύγκριση με το σχεσιακό αλγεβρικό μοντέλο SQL, το λειτουργικό μοντέλο ροής που βασίζεται στη ροή του Flux παρέχει μεγαλύτερο έλεγχο στον χρήστη, αλλά με το κόστος της μείωσης της ισχύος της βάσης δεδομένων και του προγραμματιστή επερωτήσεων.

Γιατί υπάρχουν προγραμματιστές ερωτήσεων

Ας κάνουμε ένα βήμα πίσω για να καταλάβουμε γιατί υπάρχουν οι σχεδιαστές επερωτήσεων. Καθώς μια βάση δεδομένων γίνεται πιο προηγμένη, η επιλογή της βέλτιστης διαδρομής εκτέλεσης για την εκτέλεση ενός ερωτήματος γίνεται πιο δύσκολη. Όταν εισάγονται λειτουργίες όπως συνδέσεις, πολλαπλά ευρετήρια ή ακόμα και τύποι ευρετηρίου, ο αριθμός των τρόπων που μπορεί να εκτελεστεί ένα ερώτημα πολλαπλασιάζεται: π.χ., διαδοχικές σαρώσεις, σαρώσεις δεικτών, συνδέσεις κατακερματισμού, συνδέσεις ευρετηρίων, σαρώσεις bitmap κλπ.

Λαμβάνοντας υπόψη ένα ερώτημα λογικής πολυπλοκότητας σε μια βάση δεδομένων εύλογων δυνατοτήτων, οι χρήστες βάσης δεδομένων σπάνια θα έχουν την τεχνογνωσία για να καθορίσουν ποια μέθοδο είναι καλύτερη. Επιπλέον, ακόμη και αν ορισμένοι χρήστες έχουν αυτή την τεχνογνωσία, μπορεί να μην έχουν το σωστό πλαίσιο, επειδή η καλύτερη μέθοδος εξαρτάται συχνά από τις ιδιότητες δεδομένων που μπορούν να αλλάξουν με την πάροδο του χρόνου (π.χ., ο αριθμός των ξεχωριστών αντικειμένων έναντι της διαθέσιμης μνήμης μηχανής για την επιλογή ενός in- μνήμη ή μέθοδος διαχωρισμού σε δίσκο). Η ώθηση αυτών των αποφάσεων στον προγραμματιστή μειώνει την επιβάρυνση των προγραμματιστών. (Υπάρχει ένας παραλληλισμός εδώ με την ανάπτυξη λογισμικού και μεταγλωττιστές. Σήμερα, είναι πιο λογικό να γράφετε καθαρό κώδικα και να επιτρέπετε στον μεταγλωττιστή να το βελτιστοποιήσει και να μην βελτιστοποιηθεί με το χέρι στον κώδικα.)

Αυτός είναι ο λόγος για τον οποίο οι επιχειρησιακές βάσεις δεδομένων από το σύστημα R της δεκαετίας του 1970 χρησιμοποίησαν μια δηλωτική γλώσσα σε συνδυασμό με έναν προγραμματιστή επερωτήσεων για να ωθήσουν αυτή την απόφαση στη βάση δεδομένων και όχι στον προγραμματιστή.

Λαμβάνοντας υπόψη ότι οι σχεδιαστές ερωτημάτων βάσης δεδομένων έχουν αυξηθεί μόνο στην εξουσία και την πολυπλοκότητα από τότε και ότι οι νέες προσεγγίσεις που βασίζονται στη μηχανική μάθηση προτείνονται για να προωθήσουν ακόμη περισσότερο τον ρόλο του προγραμματιστή επερωτήσεων, φαίνεται ότι δίνοντας στον προγραμματιστή επερωτήσεων περισσότερη δύναμη είναι η σωστή προσέγγιση. Αυτό γίνεται όλο και πιο δύσκολο αν κάποιος χρησιμοποιεί μια γλώσσα με χαρακτηριστικά παραγγελίας που αναλαμβάνουν την ευθύνη του προγραμματισμού των ερωτημάτων μακριά από τη βάση δεδομένων.

Εν ολίγοις, το να δίνετε στον χρήστη μεγαλύτερο έλεγχο προσθέτοντας σειριακές εντολές σε μια γλώσσα επερωτήσεων μπορεί να φαίνεται δελεαστικό. Αλλά σε αντάλλαγμα, περιορίζει επίσης τη δύναμη του προγραμματιστή επερωτήσεων και έτσι ζητά από τους χρήστες σας να γίνουν εμπειρογνώμονες βάσης δεδομένων ή λέει ότι είναι εντάξει να εγκαταλείψουμε τη βελτιστοποίηση της λανθάνουσας περιόδου ερωτήσεων. Ωστόσο, η πραγματικότητα είναι ότι η λανθάνουσα ερώτηση είναι πιθανό να είναι σημαντική και ότι οι περισσότεροι χρήστες της βάσης δεδομένων σας πιθανόν να μην είναι ειδικοί της βάσης δεδομένων, επειδή οι ρόλοι τους επικεντρώνονται σε άλλους τομείς: π.χ. ανάπτυξη λογισμικού, DevOps, επιχειρηματικές αναλύσεις, λειτουργίες.

Ως σχεδιαστές βάσεων δεδομένων, θα προτιμούσαμε να δημιουργήσουμε μια βάση δεδομένων που να μπορεί να εμπιστευθεί με μεγαλύτερη ευθύνη και να επιτρέψει στους χρήστες μας να επικεντρωθούν στην κύρια δουλειά τους. Αυτός είναι ο λόγος για τον οποίο πιστεύουμε ότι το λειτουργικό μοντέλο που βασίζεται στη ροή είναι η λανθασμένη προσέγγιση για μια γλώσσα ερώτησης βάσης δεδομένων, συμπεριλαμβανομένης μίας για μια βάση δεδομένων χρονοσειρών.

Περίληψη: SQL> Flux

Για τις περισσότερες περιπτώσεις χρήσης, πιστεύουμε ότι η SQL είναι η σωστή γλώσσα ερωτήματος για μια βάση δεδομένων χρονοσειρών.

Σε ορισμένες περιπτώσεις, ο μεγαλύτερος έλεγχος χρήστη του Flux μπορεί να είναι προτιμότερος, αλλά μόνο εάν η επιφάνεια των πιθανών χρηστών είναι μικρή και αισθάνεστε σίγουροι ότι όλοι οι χρήστες σας μπορούν να εμπιστευτούν επιλέγοντας τη βέλτιστη διαδρομή εκτέλεσης ερωτήματος όχι τόσο σημαντικό).

Με άλλα λόγια, υπάρχουν σημαντικά συμπεράσματα για την υιοθέτηση μιας προσαρμοσμένης γλώσσας ερωτήματος, ιδιαίτερα μιας βασισμένης σε λειτουργικό μοντέλο που βασίζεται στη ροή, όπως το Flux. Συγκεκριμένα, η συγχώνευση της γλώσσας ερωτήματος με μια γλώσσα δέσμης ενεργειών μπορεί να δώσει περισσότερη δύναμη στους χρήστες της βάσης δεδομένων, αλλά αυτό μειώνει τη δύναμη της βάσης δεδομένων. Εάν η SQL φαίνεται απρόσιτη για τους λειτουργικούς προγραμματιστές, θα συνιστούσαμε να χρησιμοποιείτε πολλά από τα ORM (π.χ. Django) ή τις γλώσσες δέσμης ενεργειών (π.χ. Python, R) που μπορούν να καθίσουν στην κορυφή, αντί να εξασθενήσουν τη βάση δεδομένων σας.

Το γεγονός είναι ότι οι νέες γλώσσες ερωτήσεων εισάγουν σημαντικά έξοδα και μειώνουν την αναγνωσιμότητα. Επιβάλλουν μια μεγαλύτερη καμπύλη εκμάθησης σε νέους χρήστες και διαθέτουν ελλιπή συμβατά εργαλεία.

Και δεν μπορεί να είναι μια βιώσιμη επιλογή: η ανοικοδόμηση του συστήματός σας και η εκ νέου εκπαίδευση της επιχείρησής σας για να γράψετε και να διαβάσετε μια νέα γλώσσα αναζήτησης συχνά δεν είναι πρακτικά δυνατή. Ιδιαίτερα αν χρησιμοποιείτε ήδη εργαλεία συμβατά με την SQL πάνω από τη βάση δεδομένων, π.χ. Tableau για οπτικοποίηση.

Λόγω αυτών των λόγων, θα μπορούσε κανείς να υποστηρίξει ότι η επιλογή της γλώσσας ερωτήματος είναι τα πιο σημαντικά κριτήρια για την επιλογή μιας βάσης δεδομένων: η αξιοπιστία ή η απόδοση δεν έχει σημασία αν η μέθοδος εγγραφής / πρόσβασης σε δεδομένα είναι ασυμβίβαστη με τις ανάγκες σας.

Αυτός είναι και ο λόγος για τον οποίο η SQL επιστρέφει ως γλώσσα επιλογής της επιλογής για την υποδομή δεδομένων γενικά.

Αν επιλέξετε SQL για δεδομένα χρονοσειρών, τότε θεωρήστε TimescaleDB - τη μόνη βάση δεδομένων σειράς χρόνου που υποστηρίζει πλήρη SQL.

Η απόφαση είναι δική σας, αλλά σας παροτρύνουμε να σταθμίσετε προσεκτικά τα υπέρ και τα κατά για να αποφύγετε την επένδυση σε λάθος επιλογή. Μετά από όλα, μερικά πράγματα ² που δημιουργήθηκαν αρχικά ³ κατά τη δεκαετία του 19704 εξακολουθούν να είναι5 αρκετά καλά6.

[1] 1972: Ο Νονός

[2] 1972: HBO

[3] 1974: Η δεισιδαιμονία του Stevie Wonder

[4] 1975: Η μποέμικη ραψωδία της Βασίλισσας

[5] 1976: Apple Computer

[6] 1977: Star Wars

Σαν αυτή τη θέση; Παρακαλούμε να συστήσετε και / ή να μοιραστείτε.

Θέλετε να μάθετε περισσότερα; Γίνετε μέλος της κοινότητας μας Slack, ακολουθήστε μας εδώ στο Medium, ελέγξτε το GitHub και εγγραφείτε για την αλληλογραφία της κοινότητας παρακάτω.