InfluxQL (Influx Query Language) est un langage de requête semblable au SQL pour TSDB for InfluxDB. Cette référence couvre la spécification syntaxique complète, y compris la notation, les littéraux, les instructions, les clauses, les expressions et le fonctionnement interne du moteur de requêtes.
Dans cette rubrique
Notation
La syntaxe InfluxQL est spécifiée à l'aide de la forme Backus-Naur étendue (EBNF), la même notation que celle utilisée dans la spécification du langage de programmation Go.
Production = production_name "=" [ Expression ] "." .
Expression = Alternative { "|" Alternative } .
Alternative = Term { Term } .
Term = production_name | token [ "…" token ] | Group | Option | Repetition .
Group = "(" Expression ")" .
Option = "[" Expression "]" .
Repetition = "{" Expression "}" .
Opérateurs de notation par ordre de priorité croissante :
| alternation
() grouping
[] option (0 or 1 times)
{} repetition (0 to n times)
Éléments de requête
Caractères
InfluxQL prend en charge le texte Unicode encodé en UTF-8.
newline = /* the Unicode code point U+000A */ .
unicode_char = /* an arbitrary Unicode code point except newline */ .
Lettres et chiffres
Les lettres InfluxQL incluent les caractères ASCII et les traits de soulignement. Les traits de soulignement (U+005F) se comportent comme des lettres. InfluxQL ne prend en charge que les chiffres décimaux.
letter = ascii_letter | "_" .
ascii_letter = "A" … "Z" | "a" … "z" .
digit = "0" … "9" .
Identificateurs
Les identificateurs nomment les bases de données, les politiques de rétention, les utilisateurs, les mesures, les clés de tag et les clés de champ.
Les identificateurs entre guillemets doubles peuvent :
Contenir des caractères Unicode (mais pas de sauts de ligne)
Utiliser
\"pour échapper les guillemets doublesContenir des mots clés InfluxQL
Les identificateurs sans guillemets doivent :
Commencer par une lettre ASCII ou un trait de soulignement
Contenir uniquement des lettres ASCII, des chiffres et des traits de soulignement
identifier = unquoted_identifier | quoted_identifier .
unquoted_identifier = ( letter ) { letter | digit } .
quoted_identifier = `"` unicode_char { unicode_char } `"` .
Exemples :
cpu
_cpu_stats
"1h"
"anything really"
"1_Crazy-1337.identifier>NAME"
Mots clés
ALL ALTER ANY AS ASC BEGIN
BY CREATE CONTINUOUS DATABASE DATABASES DEFAULT
DELETE DESC DESTINATIONS DIAGNOSTICS DISTINCT DROP
DURATION END EVERY EXPLAIN FIELD FOR
FROM GRANT GRANTS GROUP GROUPS IN
INF INSERT INTO KEY KEYS KILL
LIMIT SHOW MEASUREMENT MEASUREMENTS NAME OFFSET
ON ORDER PASSWORD POLICY POLICIES PRIVILEGES
QUERIES QUERY READ REPLICATION RESAMPLE RETENTION
REVOKE SELECT SERIES SET SHARD SHARDS
SLIMIT SOFFSET STATS SUBSCRIPTION SUBSCRIPTIONS TAG
TO USER USERS VALUES WHERE WITH
WRITE
Lorsqu'ils sont utilisés comme identificateurs dans les instructions de requête, les mots clés doivent être entourés de guillemets doubles.
Exception : time
Le mot clé time peut être utilisé comme identificateur sans guillemets doubles dans les noms suivants : requête continue, base de données, mesure, politique de rétention, abonnement et utilisateur. Cependant, time ne peut pas être utilisé comme clé de champ ou clé de tag ; toute tentative d'écriture de données avec time comme clé de champ ou clé de tag renvoie une erreur.
Littéraux
Entiers
InfluxQL ne prend en charge que les entiers décimaux. Les entiers hexadécimaux et octaux ne sont pas pris en charge.
int_lit = ( "1" … "9" ) { digit } .
Nombres à virgule flottante
InfluxQL prend en charge les nombres à virgule flottante, mais pas les exposants.
float_lit = int_lit "." int_lit .
Chaînes
Les chaînes doivent être entourées de guillemets simples. Utilisez \' pour échapper les guillemets simples au sein d'une chaîne.
string_lit = `'` { unicode_char } `'` .
Durées
Un littéral de durée se compose d'un entier suivi immédiatement d'une unité de temps, sans espace entre eux. Plusieurs unités peuvent être combinées pour exprimer une durée.
duration_lit = int_lit duration_unit .
duration_unit = "ns" | "u" | "µ" | "ms" | "s" | "m" | "h" | "d" | "w" .
Unités valides
| Unité | Description |
|---|---|
ns |
Nanoseconde (un milliardième de seconde) |
u ou µ |
Microseconde (un millionième de seconde) |
ms |
Milliseconde (un millième de seconde) |
s |
Seconde |
m |
Minute |
h |
Heure |
d |
Jour |
w |
Semaine |
Date et heure
La date et l'heure dans InfluxQL suivent les règles de formatage et d'analyse de Go plutôt que l'EBNF. L'horodatage de référence — 2 janvier 2006, 15:04:05 — définit le format requis :
time_lit = "2006-01-02 15:04:05.999999" | "2006-01-02" .
Valeurs booléennes
bool_lit = TRUE | FALSE .
Expressions régulières
regex_lit = "/" { unicode_char } "/" .
Opérateurs : =~ correspond, !~ ne correspond pas.
Les expressions régulières peuvent être utilisées pour :
Les clés de champ et les clés de tag dans les clauses
SELECTLes mesures dans les clauses
FROMLes valeurs de tag dans les clauses
WHERELes clés de tag dans les clauses
GROUP BY
Les expressions régulières ne peuvent pas être utilisées pour :
Les valeurs de champ non textuelles dans les clauses
WHERELes bases de données
Les politiques de rétention
Requêtes
Une requête se compose d'une ou plusieurs instructions séparées par des points-virgules (;).
query = statement { ";" statement } .
statement = alter_retention_policy_stmt |
create_continuous_query_stmt |
create_database_stmt |
create_retention_policy_stmt |
create_subscription_stmt |
create_user_stmt |
delete_stmt |
drop_continuous_query_stmt |
drop_database_stmt |
drop_measurement_stmt |
drop_retention_policy_stmt |
drop_series_stmt |
drop_shard_stmt |
drop_subscription_stmt |
drop_user_stmt |
explain_stmt |
explain_analyze_stmt |
grant_stmt |
kill_query_statement |
revoke_stmt |
select_stmt |
show_continuous_queries_stmt |
show_databases_stmt |
show_diagnostics_stmt |
show_field_key_cardinality_stmt |
show_field_keys_stmt |
show_grants_stmt |
show_measurement_cardinality_stmt |
show_measurement_exact_cardinality_stmt |
show_measurements_stmt |
show_queries_stmt |
show_retention_policies_stmt |
show_series_cardinality_stmt |
show_series_exact_cardinality_stmt |
show_series_stmt |
show_shard_groups_stmt |
show_shards_stmt |
show_stats_stmt |
show_subscriptions_stmt |
show_tag_key_cardinality_stmt |
show_tag_key_exact_cardinality_stmt |
show_tag_keys_stmt |
show_tag_values_stmt |
show_tag_values_cardinality_stmt |
show_users_stmt .
Instructions
DELETE
TSDB for InfluxDB® prend en charge les opérations de suppression. En raison de la syntaxe de suppression sous-jacente dans InfluxDB®, les opérations de suppression peuvent provoquer des interblocages et entraîner des échecs de lecture/écriture. Évitez d'effectuer des opérations de suppression dans TSDB for InfluxDB®.
delete_stmt = "DELETE" ( from_clause | where_clause | from_clause where_clause ) .
Exemples :
DELETE FROM "cpu"
DELETE FROM "cpu" WHERE time < '2000-01-01T00:00:00Z'
DELETE WHERE time < '2000-01-01T00:00:00Z'
EXPLAIN
EXPLAIN analyse et planifie une requête, puis renvoie un résumé estimé du coût des ressources.
Contrairement aux moteurs SQL qui prennent en charge les opérations de jointure, InfluxQL ne prend pas en charge les jointures. La sortie du plan reflète les coûts spécifiques aux requêtes InfluxQL : le nombre de séries temporelles accessibles, le nombre d'itérateurs lisant les fichiers Time-Structured Merge Tree (TSM) et le nombre de blocs TSM analysés.
Un résultat EXPLAIN comprend :
Expression
Champs auxiliaires
Nombre de shards
Nombre de séries
Valeurs mises en cache
Nombre de fichiers
Nombre de blocs
Taille des blocs
Exemple :
> EXPLAIN SELECT sum(pointReq) FROM "_internal"."monitor"."write" GROUP BY hostname;
QUERY PLAN
----------
EXPRESSION: sum(pointReq::integer)
NUMBER OF SHARDS: 2
NUMBER OF SERIES: 2
CACHED VALUES: 110
NUMBER OF FILES: 1
NUMBER OF BLOCKS: 1
SIZE OF BLOCKS: 931
EXPLAIN ANALYZE
EXPLAIN ANALYZE exécute une requête InfluxQL et renvoie les coûts réels des ressources mesurés pendant l'exécution.
explain_analyze_stmt = "EXPLAIN ANALYZE" select_stmt .
Exemple :
> EXPLAIN ANALYZE SELECT sum(pointReq) FROM "_internal"."monitor"."write" GROUP BY hostname;
EXPLAIN ANALYZE
---------------
.
└── select
├── execution_time: 242.167µs
├── planning_time: 2.165637ms
├── total_time: 2.407804ms
└── field_iterators
├── labels
│ └── statement: SELECT sum(pointReq::integer) FROM "_internal"."monitor"."write" GROUP BY hostname
└── expression
├── labels
│ └── expr: sum(pointReq::integer)
├── create_iterator
│ ├── labels
│ │ ├── measurement: write
│ │ └── shard_id: 57
│ ├── cursors_ref: 1
│ ├── cursors_aux: 0
│ ├── cursors_cond: 0
│ ├── float_blocks_decoded: 0
│ ├── float_blocks_size_bytes: 0
│ ├── integer_blocks_decoded: 1
│ ├── integer_blocks_size_bytes: 931
│ ├── unsigned_blocks_decoded: 0
│ ├── unsigned_blocks_size_bytes: 0
│ ├── string_blocks_decoded: 0
│ ├── string_blocks_size_bytes: 0
│ ├── boolean_blocks_decoded: 0
│ ├── boolean_blocks_size_bytes: 0
│ └── planning_time: 1.401099ms
└── create_iterator
├── labels
│ ├── measurement: write
│ └── shard_id: 58
├── cursors_ref: 1
├── cursors_aux: 0
├── cursors_cond: 0
├── float_blocks_decoded: 0
├── float_blocks_size_bytes: 0
├── integer_blocks_decoded: 0
├── integer_blocks_size_bytes: 0
├── unsigned_blocks_decoded: 0
├── unsigned_blocks_size_bytes: 0
├── string_blocks_decoded: 0
├── string_blocks_size_bytes: 0
├── boolean_blocks_decoded: 0
├── boolean_blocks_size_bytes: 0
└── planning_time: 76.192µs
KILL QUERY
KILL QUERY arrête une requête en cours d'exécution grâce à son ID de requête.
kill_query_statement = "KILL QUERY" query_id .
Pour trouver l'ID de requête, exécutez SHOW QUERIES. Le champ qid dans le résultat correspond à l'ID de requête.
Exemple :
-- Kill the query with qid 36
KILL QUERY 36
SELECT
select_stmt = "SELECT" fields from_clause [ into_clause ] [ where_clause ]
[ group_by_clause ] [ order_by_clause ] [ limit_clause ]
[ offset_clause ] [ slimit_clause ] [ soffset_clause ] [ timezone_clause ] .
Exemples :
Interrogez les données de toutes les mesures dont le préfixe est cpu, et écrivez les résultats dans les mêmes noms de mesure dans la politique de rétention cpu_1h :
SELECT mean("value") INTO "cpu_1h".:MEASUREMENT FROM /cpu.*/
Interrogez les données de la mesure cpu, regroupées par jour dans le fuseau horaire America/Chicago :
SELECT mean("value") FROM "cpu" GROUP BY region, time(1d) fill(0) tz('America/Chicago')
SHOW CARDINALITY
SHOW CARDINALITY est une famille de commandes permettant d'interroger la cardinalité des mesures, des séries, des clés de tag, des valeurs de tag et des clés de champ.
Deux modes sont disponibles :
Cardinalité estimée : calculée à partir d'un plan interne. Faible surcharge quelle que soit la taille des données. Utilisez ce mode par défaut.
Cardinalité exacte : calculée à partir des données TSM. Surcharge élevée pour les grands ensembles de données. Utilisez ce mode uniquement lorsque votre cas d'utilisation exige une précision absolue.
Le filtrage basé sur le temps est disponible uniquement lorsque la fonctionnalité Time Series Index (TSI) est activée pour votre base de données.
Pour la syntaxe de chaque instruction individuelle, consultez :
SHOW CONTINUOUS QUERIES
show_continuous_queries_stmt = "SHOW CONTINUOUS QUERIES" .
Exemple :
-- List all continuous queries
SHOW CONTINUOUS QUERIES
SHOW DATABASES
show_databases_stmt = "SHOW DATABASES" .
Exemple :
-- List all databases
SHOW DATABASES
SHOW DIAGNOSTICS
Renvoie les informations sur le nœud, y compris les informations de build, les détails d'exécution, le nom d'hôte, la configuration du serveur, l'utilisation de la mémoire et les diagnostics d'exécution Go.
show_diagnostics_stmt = "SHOW DIAGNOSTICS" .
SHOW FIELD KEY CARDINALITY
Renvoie la cardinalité estimée ou exacte de l'ensemble des clés de champ. Sans clause ON, la base de données actuelle est utilisée.
L'utilisation de clauses facultatives renvoie la cardinalité exacte. Le filtrage temporel nécessite TSI ; le filtre time ne peut pas être utilisé dans les clauses WHERE.
show_field_key_cardinality_stmt =
"SHOW FIELD KEY CARDINALITY"
[ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]
show_field_key_exact_cardinality_stmt =
"SHOW FIELD KEY EXACT CARDINALITY"
[ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]
Exemples :
-- Estimated cardinality for the current database
SHOW FIELD KEY CARDINALITY
-- Exact cardinality for a specified database
SHOW FIELD KEY EXACT CARDINALITY ON mydb
SHOW FIELD KEYS
show_field_keys_stmt = "SHOW FIELD KEYS" [ on_clause ] [ from_clause ] .
Exemples :
-- Show field keys and value types from all measurements
SHOW FIELD KEYS
-- Show field keys and value types from a specific measurement
SHOW FIELD KEYS FROM "cpu"
SHOW GRANTS
show_grants_stmt = "SHOW GRANTS FOR" user_name .
Exemple :
-- Show grants for jdoe
SHOW GRANTS FOR "jdoe"
SHOW MEASUREMENT CARDINALITY
Renvoie la cardinalité estimée ou exacte de l'ensemble des mesures. Sans clause ON, la base de données actuelle est utilisée.
L'utilisation de clauses facultatives renvoie la cardinalité exacte. Le filtrage temporel nécessite TSI ; le filtre time ne peut pas être utilisé dans les clauses WHERE.
show_measurement_cardinality_stmt =
"SHOW MEASUREMENT CARDINALITY"
[ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]
show_measurement_exact_cardinality_stmt =
"SHOW MEASUREMENT EXACT CARDINALITY"
[ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]
Exemples :
-- Estimated cardinality for the current database
SHOW MEASUREMENT CARDINALITY
-- Exact cardinality for a specified database
SHOW MEASUREMENT EXACT CARDINALITY ON mydb
SHOW MEASUREMENTS
show_measurements_stmt = "SHOW MEASUREMENTS" [ on_clause ] [ with_measurement_clause ] [ where_clause ] [ limit_clause ] [ offset_clause ] .
Exemples :
-- List all measurements
SHOW MEASUREMENTS
-- Measurements where region = 'uswest' and host = 'serverA'
SHOW MEASUREMENTS WHERE "region" = 'uswest' AND "host" = 'serverA'
-- Measurements starting with 'h2o'
SHOW MEASUREMENTS WITH MEASUREMENT =~ /h2o.*/
SHOW QUERIES
show_queries_stmt = "SHOW QUERIES" .
Exemple :
-- List all currently running queries
SHOW QUERIES
SHOW RETENTION POLICIES
show_retention_policies_stmt = "SHOW RETENTION POLICIES" [ on_clause ] .
Exemple :
-- List all retention policies for a database
SHOW RETENTION POLICIES ON "mydb"
SHOW SERIES
show_series_stmt = "SHOW SERIES" [ on_clause ] [ from_clause ] [ where_clause ] [ limit_clause ] [ offset_clause ] .
Exemple :
SHOW SERIES FROM "telegraf"."autogen"."cpu" WHERE cpu = 'cpu8'
SHOW SERIES CARDINALITY
Renvoie la cardinalité estimée ou exacte de l'ensemble des séries. Sans clause ON, la base de données actuelle est utilisée.
La cardinalité des séries affecte directement l'utilisation de la RAM.
L'utilisation de clauses facultatives renvoie la cardinalité exacte. Le filtrage temporel nécessite TSI ; le filtre time ne peut pas être utilisé dans les clauses WHERE.
show_series_cardinality_stmt =
"SHOW SERIES CARDINALITY"
[ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]
show_series_exact_cardinality_stmt =
"SHOW SERIES EXACT CARDINALITY"
[ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]
Exemples :
-- Estimated cardinality for the current database
SHOW SERIES CARDINALITY
-- Estimated cardinality for a specified database
SHOW SERIES CARDINALITY ON mydb
-- Exact cardinality for the current database
SHOW SERIES EXACT CARDINALITY
-- Exact cardinality for a specified database
SHOW SERIES EXACT CARDINALITY ON mydb
SHOW SHARD GROUPS
show_shard_groups_stmt = "SHOW SHARD GROUPS" .
Exemple :
SHOW SHARD GROUPS
SHOW SHARDS
show_shards_stmt = "SHOW SHARDS" .
Exemple :
SHOW SHARDS
SHOW STATS
Renvoie des informations statistiques sur un nœud TSDB for InfluxDB et ses composants disponibles.
show_stats_stmt = "SHOW STATS [ FOR '<component>' | 'indexes' ]"
SHOW STATS
Renvoie les statistiques pour tous les composants, à l'exception de l'utilisation de la mémoire d'index. Les valeurs statistiques sont stockées en mémoire et réinitialisées à zéro lors du redémarrage du nœud. TSDB for InfluxDB exécute automatiquement SHOW STATS toutes les 10 secondes pour remplir la base de données _internal.
SHOW STATS FOR \<component\>
Renvoie les statistiques pour un composant spécifique. Pour le composant runtime, renvoie un résumé de l'utilisation de la mémoire basé sur le package d'exécution Go.
SHOW STATS FOR 'indexes'
Renvoie l'utilisation estimée de la mémoire pour tous les index. Ces informations sont exclues de SHOW STATS car leur calcul consomme beaucoup de ressources.
Exemple :
> SHOW STATS
name: runtime
-------------
Alloc Frees HeapAlloc HeapIdle HeapInUse HeapObjects HeapReleased HeapSys Lookups Mallocs NumGC NumGoroutine PauseTotalNs Sys TotalAlloc
4136056 6684537 4136056 34586624 5816320 49412 0 40402944 110 6733949 83 44 36083006 46692600 439945704
name: graphite
tags: proto=tcp
batches_tx bytes_rx connections_active connections_handled points_rx points_tx
---------- -------- ------------------ ------------------- --------- ---------
159 3999750 0 1 158110 158110
SHOW SUBSCRIPTIONS
show_subscriptions_stmt = "SHOW SUBSCRIPTIONS" .
Exemple :
SHOW SUBSCRIPTIONS
SHOW TAG KEY CARDINALITY
Renvoie la cardinalité estimée ou exacte de l'ensemble des clés de tag. Sans clause ON, la base de données actuelle est utilisée.
L'utilisation de clauses facultatives renvoie la cardinalité exacte. Le filtrage temporel nécessite TSI ; le filtre time ne peut pas être utilisé dans les clauses WHERE.
show_tag_key_cardinality_stmt =
"SHOW TAG KEY CARDINALITY"
[ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]
show_tag_key_exact_cardinality_stmt =
"SHOW TAG KEY EXACT CARDINALITY"
[ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ]
Exemples :
-- Estimated tag key cardinality
SHOW TAG KEY CARDINALITY
-- Exact tag key cardinality
SHOW TAG KEY EXACT CARDINALITY
SHOW TAG KEYS
show_tag_keys_stmt = "SHOW TAG KEYS" [ on_clause ] [ from_clause ] [ where_clause ]
[ limit_clause ] [ offset_clause ] .
Exemples :
-- List all tag keys
SHOW TAG KEYS
-- Tag keys from the cpu measurement
SHOW TAG KEYS FROM "cpu"
-- Tag keys from cpu where region = 'uswest'
SHOW TAG KEYS FROM "cpu" WHERE "region" = 'uswest'
-- Tag keys where host = 'serverA'
SHOW TAG KEYS WHERE "host" = 'serverA'
SHOW TAG VALUES
show_tag_values_stmt = "SHOW TAG VALUES" [ on_clause ] [ from_clause ] with_tag_clause [ where_clause ]
[ limit_clause ] [ offset_clause ] .
Exemples :
-- All tag values for the region tag across all measurements
SHOW TAG VALUES WITH KEY = "region"
-- Tag values for the region tag from the cpu measurement
SHOW TAG VALUES FROM "cpu" WITH KEY = "region"
-- Tag values for all tag keys that don't contain the letter 'c'
SHOW TAG VALUES WITH KEY !~ /.*c.*/
-- Tag values for region and host from cpu where service = 'redis'
SHOW TAG VALUES FROM "cpu" WITH KEY IN ("region", "host") WHERE "service" = 'redis'
SHOW TAG VALUES CARDINALITY
Renvoie la cardinalité estimée ou exacte des valeurs de tag pour les clés de tag spécifiées. Sans clause ON, la base de données actuelle est utilisée.
L'utilisation de clauses facultatives renvoie la cardinalité exacte. Le filtrage temporel nécessite TSI.
show_tag_values_cardinality_stmt =
"SHOW TAG VALUES CARDINALITY"
[ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ] with_key_clause
show_tag_values_exact_cardinality_stmt =
"SHOW TAG VALUES EXACT CARDINALITY"
[ on_clause ] [ from_clause ] [ where_clause ] [ group_by_clause ] [ limit_clause ] [ offset_clause ] with_key_clause
Exemples :
-- Estimated cardinality for a tag key
SHOW TAG VALUES CARDINALITY WITH KEY = "myTagKey"
-- Exact cardinality for a tag key
SHOW TAG VALUES EXACT CARDINALITY WITH KEY = "myTagKey"
SHOW USERS
show_users_stmt = "SHOW USERS" .
Exemple :
-- List all users
SHOW USERS
Clauses
from_clause = "FROM" measurements .
group_by_clause = "GROUP BY" dimensions fill(fill_option) .
into_clause = "INTO" ( measurement | back_ref ) .
limit_clause = "LIMIT" int_lit .
offset_clause = "OFFSET" int_lit .
slimit_clause = "SLIMIT" int_lit .
soffset_clause = "SOFFSET" int_lit .
timezone_clause = tz(string_lit) .
on_clause = "ON" db_name .
order_by_clause = "ORDER BY" sort_fields .
to_clause = "TO" user_name .
where_clause = "WHERE" expr .
with_measurement_clause = "WITH MEASUREMENT" ( "=" measurement | "=~" regex_lit ) .
with_tag_clause = "WITH KEY" ( "=" tag_key | "!=" tag_key | "=~" regex_lit | "IN (" tag_keys ")" ) .
Expressions
binary_op = "+" | "-" | "*" | "/" | "%" | "&" | "|" | "^" | "AND" |
"OR" | "=" | "!=" | "<>" | "<" | "<=" | ">" | ">=" .
expr = unary_expr { binary_op unary_expr } .
unary_expr = "(" expr ")" | var_ref | time_lit | string_lit | int_lit |
float_lit | bool_lit | duration_lit | regex_lit .
Autres éléments grammaticaux
alias = "AS" identifier .
back_ref = ( policy_name ".:MEASUREMENT" ) |
( db_name "." [ policy_name ] ".:MEASUREMENT" ) .
db_name = identifier .
dimension = expr .
dimensions = dimension { "," dimension } .
field_key = identifier .
field = expr [ alias ] .
fields = field { "," field } .
fill_option = "null" | "none" | "previous" | int_lit | float_lit | "linear" .
host = string_lit .
measurement = measurement_name |
( policy_name "." measurement_name ) |
( db_name "." [ policy_name ] "." measurement_name ) .
measurements = measurement { "," measurement } .
measurement_name = identifier | regex_lit .
password = string_lit .
policy_name = identifier .
privilege = "ALL" [ "PRIVILEGES" ] | "READ" | "WRITE" .
query_id = int_lit .
query_name = identifier .
retention_policy = identifier .
retention_policy_option = retention_policy_duration |
retention_policy_replication |
retention_policy_shard_group_duration |
"DEFAULT" .
retention_policy_duration = "DURATION" duration_lit .
retention_policy_replication = "REPLICATION" int_lit .
retention_policy_shard_group_duration = "SHARD DURATION" duration_lit .
retention_policy_name = "NAME" identifier .
series_id = int_lit .
shard_id = int_lit .
sort_field = field_key [ ASC | DESC ] .
sort_fields = sort_field { "," sort_field } .
subscription_name = identifier .
tag_key = identifier .
tag_keys = tag_key { "," tag_key } .
user_name = identifier .
var_ref = measurement .
Commentaires
Ajoutez des commentaires dans les instructions InfluxQL pour documenter vos requêtes.
Commentaire sur une seule ligne : commence par
--et se termine au saut de ligne suivant. Ne peut pas s'étendre sur plusieurs lignes.Commentaire multiligne : commence par
/*et se termine par*/. Peut s'étendre sur plusieurs lignes. Les commentaires multilignes imbriqués ne sont pas pris en charge.
Fonctionnement interne du moteur de requêtes
Comprendre comment le moteur de requêtes exécute InfluxQL vous aide à rédiger des requêtes efficaces et à interpréter la sortie de EXPLAIN ANALYZE.
Cycle de vie d'une requête
Chaque requête InfluxQL suit quatre étapes :
L'instruction est tokenisée et analysée en un arbre de syntaxe abstraite (AST) — la représentation en mémoire de la requête.
L'AST est transmis à l'exécuteur de requêtes, qui le dirige vers le gestionnaire approprié. Les requêtes de métadonnées vont au service de métadonnées ; les instructions
SELECTs'exécutent contre les shards.Le moteur de requêtes identifie les shards correspondant à la plage de temps dans l'instruction
SELECT, puis crée un itérateur pour chaque champ interrogé.Les itérateurs sont transmis à un émetteur, qui libère les itérateurs, combine les points de données résultants, convertit les points de données simples basés sur le temps en objets complexes et les renvoie au client.
Itérateurs
Les itérateurs constituent l'abstraction centrale du moteur de requêtes. Chaque itérateur fournit une interface simple pour diffuser des points de données. Par exemple, un FloatIterator diffuse des points de données à virgule flottante :
type FloatIterator interface {
Next() *FloatPoint
}
Les itérateurs sont créés via l'interface IteratorCreator :
type IteratorCreator interface {
CreateIterator(opt *IteratorOptions) (Iterator, error)
}
IteratorOptions spécifie les champs à lire, la plage de temps et les dimensions de regroupement. IteratorCreator est disponible aux niveaux Shards, Shard et Engine, ce qui permet au moteur de pousser les opérations — par exemple, de pré-agréger les données avant que COUNT() ne renvoie les résultats.
Les itérateurs peuvent être composés : DistinctIterator calcule les valeurs distinctes dans chaque fenêtre de temps à partir d'un itérateur d'entrée ; FillIterator génère des valeurs de remplacement pour les points de données manquants.
Un exemple composé — calcul de la dérivée d'une moyenne :
SELECT DERIVATIVE(MEAN(value), 20m) FROM cpu GROUP BY time(10m)
Cela produit un mean iterator (à partir des shards), enveloppé par un derivative iterator au niveau du moteur.
Champs auxiliaires
Les fonctions sélectrices telles que FIRST(), LAST(), MIN() et MAX() renvoient à la fois le point de données sélectionné et les champs connexes de la même ligne.
Par exemple :
SELECT FIRST(value), host FROM cpu GROUP BY time(1h)
Cela renvoie la value du premier point de données de chaque heure ainsi que l'host associé. En interne, le moteur utilise un seul type de point de données value et attache host en tant que champ auxiliaire — un champ transporté avec la valeur principale jusqu'à ce qu'il atteigne l'émetteur. L'émetteur sépare ensuite les champs auxiliaires et les dirige vers leurs itérateurs respectifs.
Itérateurs intégrés
Le moteur de requêtes fournit les types d'itérateurs intégrés suivants :
| Itérateur | Objectif |
|---|---|
| Merge iterator | Fusionne un ou plusieurs itérateurs du même type sans tri par temps. Utilisé pour les requêtes d'agrégation nécessitant un accès rapide et ne requérant pas d'ordre. |
| Sorted merge iterator | Fusionne et trie les points de données par temps. Plus lent que les merge iterators. Utilisé pour les requêtes non agrégées renvoyant des données brutes dans l'ordre chronologique. |
| Limit iterator | Limite les points de données par nom ou groupe de tags, en fonction des clauses LIMIT et OFFSET. |
| Fill iterator | Génère des valeurs de remplacement pour les points de données manquants : null, none, la valeur précédente, une valeur numérique spécifiée ou une interpolation linéaire. |
| Buffered iterator | Renvoie les points de données à un état non lu afin qu'ils puissent être relus. Utilisé pour les opérations de consultation anticipée des fenêtres de temps. |
| Reduce iterator | Applique une fonction de réduction à chaque point de données dans une fenêtre de temps, renvoyant tous les résultats après la fermeture de la fenêtre. Utilisé pour les agrégats simples comme COUNT(). |
| Reduce slice iterator | Collecte tous les points de données dans une fenêtre de temps, puis transmet la tranche complète à une fonction de réduction. Utilisé pour les agrégats comme DERIVATIVE(). |
| Transform iterator | Applique une fonction de transformation à chaque point de données d'entrée pour produire un résultat d'expression binaire. |
| Dedupe iterator | Supprime les doublons de points de données et ne renvoie que les valeurs uniques. Consomme beaucoup de ressources ; convient uniquement aux petits ensembles de données tels que les requêtes de métadonnées. |
Itérateurs d'appel
Les fonctions InfluxQL s'exécutent à deux niveaux :
Niveau shard : les fonctions comme
COUNT()s'exécutent au sein de chaque shard. Uncount iteratoragrège plusieurs itérateurs de comptage par shard en un total. Ces itérateurs sont créés à l'aide deNewCallIterator().Niveau engine : les fonctions comme
DERIVATIVE()nécessitent tous les points de données d'une fenêtre de temps avant de calculer les résultats. Ces itérateurs ne peuvent pas être poussés vers des shards individuels — le moteur de requêtes les construit après avoir collecté la sortie des shards.
InfluxDB® est une marque déposée par InfluxData, qui n'est pas affiliée à TSDB for InfluxDB® et ne l'approuve pas.