Time Series Database:FAQ

Séries et cardinalité des séries

• Comment effectuer la modélisation et quelles sont les précautions à prendre ?

• Pourquoi la cardinalité des séries est-elle importante ?

Administration

• Quels points surveiller pour la stabilité du système ?

• Comment consulter l'utilisation du disque pour une measurement ?

• Comment supprimer des données efficacement et en toute sécurité ?

• Pourquoi une politique de rétention modifiée ne prend-elle pas effet ?

• Pourquoi les services sont-ils fréquemment interrompus ?

• Pourquoi l'utilisation de la mémoire est-elle élevée et dois-je effectuer une mise à niveau ?

• La réduction de l'échelle du stockage est-elle prise en charge ?

• L'extension d'un disque provoque-t-elle un redémarrage ?

• Combien de temps dure un redémarrage ?

• Grafana intégré pour InfluxDB est-il pris en charge ?

• Pourquoi obtiens-je une erreur `ip block` lors de l'accès ?

• Comment identifier la version de TSDB for InfluxDB® ?

• Quelle est la relation entre la durée d'un groupe de shards et une politique de rétention ?

• Pourquoi aucune donnée n'est-elle perdue après la modification d'une politique de rétention ?

• Pourquoi TSDB for InfluxDB® ne peut-il pas analyser l'unité microseconde ?

Interrogation des données

• Comment résoudre les problèmes de lenteur des requêtes ?

• Qu'est-ce qui détermine l'intervalle de temps renvoyé par une requête GROUP BY time() ?

• Pourquoi une requête ne renvoie-t-elle aucune donnée ou seulement des données partielles ?

• Pourquoi une requête GROUP BY time() ne renvoie-t-elle pas les horodatages postérieurs à now() ?

• Puis-je effectuer des opérations mathématiques sur les horodatages ?

• Puis-je identifier la précision d'écriture à partir des horodatages renvoyés ?

• Quand utiliser des guillemets simples et doubles lors de l'interrogation des données ?

• Pourquoi des données sont-elles perdues après la création d'une nouvelle politique de rétention DEFAULT ?

• Pourquoi une requête avec une clause WHERE OR time renvoie-t-elle un résultat vide ?

• Pourquoi fill(previous) renvoie-t-il un résultat vide ?

• Pourquoi une requête INTO perd-elle des données ?

• Comment interroger les données lorsqu'une clé de tag et une clé de champ portent le même nom ?

• Comment interroger les données across measurements ?

• L'ordre des horodatages est-il important ?

• Comment SELECT des données possédant un tag mais sans valeur de tag ?

Écriture de données

• Pourquoi des variations d'écriture se produisent-elles périodiquement ?

• Précautions pour les écritures en line protocol

• Pourquoi les données ne sont-elles pas visibles après leur écriture ?

• Pourquoi l'écriture ne reprend-elle pas après la libération d'espace disque suite à un état plein ?

• Comment écrire une valeur de champ entière ?

• Comment TSDB for InfluxDB® gère-t-il les points de données en double ?

• Quel saut de ligne l'API HTTP requiert-elle ?

• Quels mots et caractères éviter lors de l'écriture de données dans TSDB for InfluxDB® ?

• Quand utiliser des guillemets simples et doubles lors de l'écriture de données ?

• La précision de l'horodatage est-elle importante ?

Interface en ligne de commande (Influx CLI)

• Pourquoi ne puis-je pas me connecter à TSDB for InfluxDB® via l'interface en ligne de commande ?

• Comment faire en sorte que l'Influx CLI pour TSDB for InfluxDB® renvoie des horodatages lisibles ?

• Comment un utilisateur non administrateur peut-il utiliser USE pour spécifier une base de données ?

• Comment utiliser l'Influx CLI pour TSDB for InfluxDB® afin d'écrire des données dans une politique de rétention non par défaut ?

Types de données

• Pourquoi ne puis-je pas interroger une valeur de champ booléenne ?

• Comment TSDB for InfluxDB® gère-t-il les écarts de type de champ entre les shards ?

• Quels sont les entiers minimum et maximum que TSDB for InfluxDB® peut stocker ?

• Quels sont les horodatages minimum et maximum que TSDB for InfluxDB® peut stocker ?

• Comment connaître le type de données stocké dans un champ ?

• Puis-je modifier le type de données d'un champ ?

Fonctions InfluxQL

• Comment effectuer des opérations mathématiques dans les fonctions ?

• Pourquoi une requête renvoie-t-elle epoch 0 comme horodatage ?

• Quelles fonctions InfluxQL supportent l'imbrication ?

Migration des données InfluxDB

• Comment migrer une instance InfluxDB auto-gérée vers le cloud ?

• Comment migrer des données entre différentes instances InfluxDB dans le cloud ?

• Comment migrer des données d'InfluxDB vers LindormTSDB ?

Pourquoi la cardinalité des séries est-elle importante ?

TSDB for InfluxDB® maintient un index en mémoire par série. À mesure que le nombre de séries augmente, l'utilisation de la RAM augmente également. Une cardinalité excessivement élevée peut déclencher une exception d'épuisement de la mémoire (OOM) qui termine le processus. Référence InfluxQL

Comment effectuer la modélisation et quelles sont les précautions à prendre ?

Maintenez le nombre de séries temporelles inférieur à un million. Pour les scénarios impliquant un grand nombre de séries temporelles, utilisez Présentation de LindormTSDB. Consultez le guide de schéma et de disposition des données InfluxDB. InfluxDB indexe les tags pour accélérer les requêtes, mais trop de tags provoquent une inflation des séries qui ralentit les lectures et les écritures. Points clés à considérer :

• Évitez d'utiliser des tags avec des valeurs à haute cardinalité, telles que les ID, les valeurs de hachage et les chaînes aléatoires.

• Ne stockez pas de données dans les noms de measurement ou les noms de tag. Stockez les données dans les tags et les champs.

• Ne stockez pas plusieurs informations dans un seul tag. Répartissez les informations dans plusieurs tags.

• Si vous utilisez fréquemment un champ dans une clause GROUP BY, modélisez-le comme un tag.

Comment identifier la version de TSDB for InfluxDB® ?

Utilisez l'une des méthodes suivantes :

• curl /ping

  $ curl -i 'https://<endpoint>:3242/ping?u=<username>&p=<password>'
  HTTP/1.1 204 No Content
  Content-Type: application/json
  X-Influxdb-Build: OSS
  X-Influxdb-Version: 1.7.x

• Démarrer l'interface en ligne de commande pour TSDB for InfluxDB®

  $ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242
  
  Connected to https://<endpoint>:3242 version 1.7.x

Quelle est la relation entre la durée d'un groupe de shards et une politique de rétention ?

TSDB for InfluxDB® stocke les données dans des groupes de shards. Un groupe de shards couvre un intervalle de temps spécifique. TSDB for InfluxDB® détermine l'intervalle de temps en vérifiant la DURATION de la politique de rétention (RP) concernée. Le tableau suivant liste la relation par défaut entre la DURATION d'une RP et l'intervalle de temps d'un groupe de shards :

Utilisez SHOW RETENTION POLICIES pour afficher la durée du groupe de shards d'une politique de rétention.

Pourquoi aucune donnée n'est-elle perdue après la modification d'une politique de rétention ?

Les données peuvent ne pas être perdues immédiatement après la modification d'une politique de rétention pour les raisons suivantes :

• Première raison possible (scénario le plus probable) : Par défaut, TSDB for InfluxDB® vérifie et applique les RPs toutes les 30 minutes. Vous devrez peut-être attendre la prochaine vérification de RP avant que TSDB for InfluxDB® ne supprime les données qui se trouvent en dehors de la nouvelle DURATION de la RP.

• Deuxième raison possible : La modification de la DURATION et de la SHARD DURATION d'une RP peut entraîner une rétention de données inattendue. TSDB for InfluxDB® stocke les données dans des groupes de shards. Chaque groupe de shards couvre une RP et un intervalle de temps spécifiques. Lorsque TSDB for InfluxDB® applique une RP, il supprime le groupe de shards entier, et non les points de données individuels. TSDB for InfluxDB® ne peut pas diviser les groupes de shards. Si la nouvelle DURATION de la RP est inférieure à l'ancienne SHARD DURATION, et que TSDB for InfluxDB® écrit des données dans un ancien groupe de shards avec une DURATION plus longue, le système est contraint de stocker toutes les données dans ce groupe de shards. Cela se produit même si certaines données du groupe de shards se trouvent en dehors de la nouvelle DURATION. Une fois que toutes les données du groupe de shards se trouvent en dehors de la nouvelle DURATION, TSDB for InfluxDB® supprime le groupe de shards entier. Le système commence alors à écrire des données dans des groupes de shards avec la nouvelle SHARD DURATION plus courte. Cela évite toute rétention de données inattendue supplémentaire.

Pourquoi TSDB for InfluxDB® ne peut-il pas analyser l'unité microseconde ?

La syntaxe pour spécifier l'unité de temps microseconde diffère selon qu'il s'agit d'écrire, d'interroger ou de définir la précision dans l'interface en ligne de commande TSDB for InfluxDB® (Influx CLI). Le tableau suivant montre la syntaxe prise en charge pour chaque catégorie :

Comment résoudre les problèmes liés aux requêtes lentes ?

Les requêtes lentes résultent généralement d'une analyse excessive de séries temporelles ou de volumes importants de données brutes. Ajoutez des filtres sur les tags et les plages horaires à chaque requête. Utilisez la commande EXPLAIN ANALYZE pour diagnostiquer les performances : execution_time reflète la lecture des données et le calcul, tandis que planning_time reflète l'analyse des séries.

Qu'est-ce qui détermine l'intervalle de temps renvoyé par une requête GROUP BY time() ?

L'intervalle de temps renvoyé par une requête GROUP BY time() correspond aux compartiments temporels prédéfinis de TSDB for InfluxDB® ou à un intervalle de décalage spécifié par l'utilisateur. Consultez les exemples suivants :

• Compartiments temporels prédéfinis

  La requête suivante calcule la moyenne de sunflowers entre 18 h 15 et 19 h 45, et regroupe les moyennes par heure :

  SELECT mean("sunflowers")
  FROM "flower_orders"
  WHERE time >='2016-08-29T18:15:00Z' AND time <='2016-08-29T19:45:00Z' GROUP BY time(1h)

  Les résultats suivants montrent comment TSDB for InfluxDB® conserve ses compartiments temporels prédéfinis.

  Dans cet exemple, 18 h constitue un compartiment temporel prédéfini, tout comme 19 h. Étant donné que la clause WHERE spécifie la plage horaire de la requête, les données antérieures à 18 h 15 ne sont pas incluses lors du calcul de la moyenne pour le compartiment de 18 h. Toutefois, les données utilisées pour calculer la moyenne du compartiment de 18 h doivent se situer dans l'heure de 18 h. Il en va de même pour le compartiment de 19 h : les données utilisées pour le calcul doivent se situer dans l'heure de 19 h. Les lignes pointillées indiquent les points de données utilisés pour calculer chaque moyenne.

  Notez que bien que le premier horodatage du résultat soit 2016-08-29T18:00:00Z, le résultat de la requête pour ce compartiment n'inclut pas les données antérieures à 2016-08-29T18:15:00Z, qui correspond à l'heure de début spécifiée dans la clause WHERE.

  Données brutes :

  name: flower_orders                                name: flower_orders
  —————————-------------------
  time                    sunflowers                 time                  mean
  2016-08-29T18:00:00Z    34                         2016-08-29T18:00:00Z    22.332
  |--|                                               2016-08-29T19:00:00Z    62.75
  2016-08-29T18:15:00Z    |28|
  2016-08-29T18:30:00Z    |19|
  2016-08-29T18:45:00Z    |20|
  |--|
  |--|
  2016-08-29T19:00:00Z    |56|
  2016-08-29T19:15:00Z    |76|
  2016-08-29T19:30:00Z    |29|
  2016-08-29T19:45:00Z    |90|
  |--|
  2016-08-29T20:00:00Z    70

• Intervalle de décalage

  La requête suivante calcule la moyenne de sunflowers entre 18 h 15 et 19 h 45, et regroupe les moyennes par heure. La requête applique également un décalage de 15 minutes aux compartiments temporels prédéfinis de TSDB for InfluxDB® :

  SELECT mean("sunflowers")
  FROM "flower_orders"
  WHERE time >='2016-08-29T18:15:00Z' AND time <='2016-08-29T19:45:00Z' GROUP BY time(1h,15m)
                                                                                    ---
                                                                                     |
                                                                                    offset interval

  Dans cet exemple, l'intervalle de décalage spécifié par l'utilisateur décale les compartiments temporels prédéfinis de TSDB for InfluxDB® de 15 minutes vers l'avant. Ainsi, la moyenne pour le compartiment de 18 h inclut les données comprises entre 18 h 15 et 19 h 15. La moyenne pour le compartiment de 19 h inclut les données comprises entre 19 h 15 et 20 h 15. Les lignes pointillées indiquent les points de données utilisés pour calculer chaque moyenne.

  Notez que le premier horodatage du résultat est désormais 2016-08-29T18:15:00Z, et non plus 2016-08-29T18:00:00Z.

  Données brutes et résultats :

  name: flower_orders                                name: flower_orders
  —————————-------------------
  time                    sunflowers                 time                  mean
  2016-08-29T18:00:00Z    34                         2016-08-29T18:15:00Z    30.75
  |--|                                               2016-08-29T19:15:00Z    65
  2016-08-29T18:15:00Z    |28|
  2016-08-29T18:30:00Z    |19|
  2016-08-29T18:45:00Z    |20|
  2016-08-29T19:00:00Z    |56|
  |--|
  |--|
  2016-08-29T19:15:00Z    |76|
  2016-08-29T19:30:00Z    |29|
  2016-08-29T19:45:00Z    |90|
  2016-08-29T20:00:00Z    |70|
  |--|

Pourquoi une requête ne renvoie-t-elle aucune donnée ou seulement des données partielles ?

Raisons courantes :

• Politique de rétention

  La première explication, et la plus fréquente, concerne les politiques de rétention (RP). TSDB for InfluxDB® interroge automatiquement les données depuis la politique de rétention DEFAULT de la base de données. Si vos données ne sont pas stockées dans la politique de rétention par défaut, TSDB for InfluxDB® ne renvoie aucun résultat, sauf si vous spécifiez explicitement la politique de rétention à utiliser.

• Clé de tag dans la clause SELECT

  La clause SELECT doit inclure au moins une clé de champ pour que la requête renvoie des données. Si la clause SELECT contient uniquement une ou plusieurs clés de tag, la requête renvoie un résultat vide. Pour plus d'informations, consultez la section Exploration des données.

• Plage horaire de la requête

  Une autre explication possible concerne la plage horaire de la requête. Par défaut, la plupart des requêtes SELECT couvrent la plage horaire comprise entre 1677-09-21 00:12:43.145224194 UTC et 2262-04-11T23:47:16.854775806Z UTC. En revanche, une requête SELECT incluant une clause GROUP BY time() couvre une plage horaire allant de 1677-09-21 00:12:43.145224194 à now(). Si vos données sont postérieures à now(), la requête GROUP BY time() ne couvre pas les données survenant après now(). Si une instruction de requête inclut une clause GROUP BY time() et comporte des données postérieures à now(), vous devez fournir une limite supérieure pour la plage horaire.

• Nom d'identifiant

  La dernière explication courante concerne le schéma, lorsqu'un champ et un tag portent le même nom. Si une clé de champ et une clé de tag sont identiques, le champ est prioritaire dans toutes les requêtes. Dans la requête, vous devez utiliser la syntaxe ::tag pour spécifier la clé de tag.

Pourquoi une requête GROUP BY time() ne renvoie-t-elle pas d'horodatages postérieurs à now() ?

La plage horaire par défaut pour la plupart des instructions SELECT s'étend de 1677-09-21 00:12:43.145224194 UTC à 2262-04-11T23:47:16.854775806Z UTC. Pour les instructions SELECT comportant une clause GROUP BY time(), la plage horaire par défaut s'étend de 1677-09-21 00:12:43.145224194 à now().

Pour interroger des données dont les horodatages sont postérieurs à now(), une instruction SELECT avec une clause GROUP BY time() doit fournir une limite horaire supérieure dans la clause WHERE.

Dans l'exemple suivant, la première requête couvre les données dont les horodatages sont compris entre 2015-09-18T21:30:00Z et now(). La deuxième requête couvre les données dont les horodatages sont compris entre 2015-09-18T21:30:00Z et 180 semaines après now().

> SELECT MEAN("boards") FROM "hillvalley" WHERE time >='2015-09-18T21:30:00Z' GROUP BY time(12m) fill(none)

> SELECT MEAN("boards") FROM "hillvalley" WHERE time >='2015-09-18T21:30:00Z' AND time <= now()+180w GROUP BY time(12m) fill(none)

Notez que la clause WHERE doit fournir une limite horaire supérieure pour remplacer la limite supérieure par défaut now(). La requête suivante réinitialise simplement la limite inférieure à now(), ce qui définit la plage horaire de la requête entre now() et now() :

> SELECT MEAN("boards") FROM "hillvalley" WHERE time >= now() GROUP BY time(12m) fill(none)
>

Détails de la syntaxe temporelle : Exploration des données.

Puis-je effectuer des opérations mathématiques sur les horodatages ?

TSDB for InfluxDB® ne prend pas en charge les opérations mathématiques sur les horodatages. Effectuez les calculs temporels côté client.

TSDB for InfluxDB® offre un support limité pour l'utilisation des fonctions InfluxQL sur les horodatages. La fonction ELAPSED() renvoie la différence entre les horodatages d'un seul champ.

Puis-je identifier la précision d'écriture à partir des horodatages renvoyés ?

TSDB for InfluxDB® stocke tous les horodatages en nanosecondes, quelle que soit la précision d'écriture. La base de données supprime silencieusement les zéros de fin des horodatages renvoyés, ce qui rend difficile l'identification de la précision d'écriture d'origine.

Dans l'exemple suivant, les tags precision_supplied et timestamp_supplied indiquent la précision temporelle et l'horodatage fournis par l'utilisateur lors de l'écriture des données. Étant donné que TSDB for InfluxDB® supprime silencieusement les zéros de fin de l'horodatage renvoyé, il est difficile d'identifier la précision d'écriture à partir de cet horodatage.

name: trails
-------------
time                  value  precision_supplied  timestamp_supplied
1970-01-01T01:00:00Z  3      n                   3600000000000
1970-01-01T01:00:00Z  5      h                   1
1970-01-01T02:00:00Z  4      n                   7200000000000
1970-01-01T02:00:00Z  6      h                   2

Quand dois-je utiliser des guillemets simples et des guillemets doubles lors de l'interrogation des données ?

Utilisez des guillemets simples pour encadrer les valeurs de chaîne, telles que les valeurs de tag. N'utilisez pas de guillemets simples pour encadrer les identifiants. Les identifiants incluent les noms de base de données, les noms de politique de rétention, les noms d'utilisateur, les noms de mesure, les clés de tag et les clés de champ.

Utilisez des guillemets doubles pour encadrer les identifiants s'ils commencent par un chiffre, contiennent des caractères autres que [A-z,0-9,_] ou constituent un mot-clé InfluxQL. Si un identifiant n'entre dans aucune de ces catégories, il n'est pas nécessaire de l'encadrer avec des guillemets doubles. Nous vous recommandons toutefois de le faire.

Exemples :

Requête valide : SELECT bikes_available FROM bikes WHERE station_id='9'

Requête valide : SELECT "bikes_available" FROM "bikes" WHERE "station_id"='9'

Requête valide : SELECT MIN("avgrq-sz") AS "min_avgrq-sz" FROM telegraf

Requête valide : SELECT * from "cr@zy" where "p^e"='2'

Requête invalide : SELECT 'bikes_available' FROM 'bikes' WHERE 'station_id'="9"

Requête invalide : SELECT * from cr@zy where p^e='2'

Utilisez des guillemets simples pour encadrer les chaînes de date et d'heure. Si vous utilisez des guillemets doubles pour encadrer les chaînes de date et d'heure, TSDB for InfluxDB® renvoie une erreur (ERR: invalid operation: time and *influxql.VarRef are not compatible).

Exemple :

Requête valide : SELECT "water_level" FROM "h2o_feet" WHERE time > '2015-08-18T23:00:01.232000000Z' AND time < '2015-09-19'

Requête invalide : SELECT "water_level" FROM "h2o_feet" WHERE time > "2015-08-18T23:00:01.232000000Z" AND time < "2015-09-19"

Détails de la syntaxe temporelle : Exploration des données.

Pourquoi des données sont-elles perdues après la création d'une nouvelle politique de rétention DEFAULT ?

Lorsque vous créez une nouvelle politique de rétention (RP) par défaut dans une base de données, les données de l'ancienne RP par défaut restent dans cette dernière. Les requêtes qui ne spécifient pas de RP interrogent automatiquement les données depuis la nouvelle RP par défaut, ce qui peut donner l'impression que toutes les anciennes données ont été perdues. Pour interroger les anciennes données, vous devez qualifier pleinement les données dans la requête. Consultez l'exemple suivant :

Toutes les données de la mesure fleeting appartiennent à la RP par défaut, nommée one_hour :

> SELECT count(flounders) FROM fleeting
name: fleeting
--------------
time                     count
1970-01-01T00:00:00Z     8

Nous créons maintenant une nouvelle RP par défaut (two_hour) et exécutons la même requête :

> SELECT count(flounders) FROM fleeting
>

Pour interroger les anciennes données, nous devons spécifier l'ancienne RP par défaut en qualifiant pleinement fleeting :

> SELECT count(flounders) FROM fish.one_hour.fleeting
name: fleeting
--------------
time                     count
1970-01-01T00:00:00Z     8

Pourquoi une requête avec une clause de temps WHERE OR renvoie-t-elle un résultat vide ?

TSDB for InfluxDB® ne prend pas en charge l'opérateur OR dans la clause WHERE pour spécifier plusieurs plages horaires. Si la clause WHERE d'une requête utilise OR pour spécifier plusieurs plages horaires, TSDB for InfluxDB® ne renvoie aucun résultat.

Exemple :

> SELECT * FROM "absolutismus" WHERE time ='2016-07-31T20:07:00Z' OR time ='2016-07-31T23:07:17Z'
>

Pourquoi fill(previous) renvoie-t-il un résultat vide ?

Si la valeur précédente se situe en dehors de la plage horaire de la requête, fill(previous) ne remplit pas de valeur pour ce compartiment temporel.

Dans l'exemple suivant, TSDB for InfluxDB® ne remplit pas de valeur pour le compartiment temporel 2016-07-12T16:50:20Z-2016-07-12T16:50:30Z avec la valeur du compartiment temporel 2016-07-12T16:50:00Z-2016-07-12T16:50:10Z, car la plage horaire de la requête n'inclut pas le compartiment temporel antérieur.

Exemple de données :

> SELECT * FROM "cupcakes"
name: cupcakes
--------------
time                   chocolate
2016-07-12T16:50:00Z   3
2016-07-12T16:50:10Z   2
2016-07-12T16:50:40Z   12
2016-07-12T16:50:50Z   11

Requête GROUP BY time() :

> SELECT max("chocolate") FROM "cupcakes" WHERE time >='2016-07-12T16:50:20Z' AND time <='2016-07-12T16:51:10Z' GROUP BY time(20s) fill(previous)
name: cupcakes
--------------
time                   max
2016-07-12T16:50:20Z
2016-07-12T16:50:40Z   12
2016-07-12T16:51:00Z   12

Pourquoi une requête INTO entraîne-t-elle une perte de données ?

Par défaut, une requête INTO convertit les tags des données source en champs dans les données nouvellement écrites. Cela peut amener TSDB for InfluxDB® à écraser des points de données qui étaient auparavant différenciés par un tag. Incluez GROUP BY * dans toutes les requêtes INTO pour conserver les tags dans les données nouvellement écrites.

> SELECT * FROM "french_bulldogs"
name: french_bulldogs
---------------------
time                  color  name
2016-05-25T00:05:00Z  peach  nugget
2016-05-25T00:05:00Z  grey   rumple
2016-05-25T00:10:00Z  black  prince

• Requête INTO sans GROUP BY *

  Une requête INTO sans clause GROUP BY * convertit le tag color en champ dans les données nouvellement écrites. Dans les données source, les points de données nugget et rumple ne sont différenciés que par le tag color. Une fois que color devient un champ, TSDB for InfluxDB® considère les points de données nugget et rumple comme des doublons. Le système écrase le point de données nugget avec le point de données rumple.

  > SELECT * INTO "all_dogs" FROM "french_bulldogs"
  name: result
  ------------
  time                  written
  1970-01-01T00:00:00Z  3
  
  > SELECT * FROM "all_dogs"
  name: all_dogs
  --------------
  time                  color  name
  2016-05-25T00:05:00Z  grey   rumple                <---- no more nugget
  2016-05-25T00:10:00Z  black  prince

• Requête INTO avec GROUP BY *

  Une requête INTO avec une clause GROUP BY * conserve le tag color dans les données nouvellement écrites. Dans ce cas, les points de données nugget et rumple restent distincts et TSDB for InfluxDB® n'écrase aucune donnée.

  > SELECT "name" INTO "all_dogs" FROM "french_bulldogs" GROUP BY *
  name: result
  ------------
  time                  written
  1970-01-01T00:00:00Z  3
  
  > SELECT * FROM "all_dogs"
  name: all_dogs
  --------------
  time                  color  name
  2016-05-25T00:05:00Z  peach  nugget
  2016-05-25T00:05:00Z  grey   rumple
  2016-05-25T00:10:00Z  black  prince

Comment interroger des données lorsqu'une clé de tag et une clé de champ portent le même nom ?

Utilisez la syntaxe :: pour spécifier si une clé est une clé de champ ou une clé de tag. Exemple de données :

> INSERT candied,almonds=true almonds=50,half_almonds=51 1465317610000000000
> INSERT candied,almonds=true almonds=55,half_almonds=56 1465317620000000000

> SELECT * FROM "candied"
name: candied
-------------
time                   almonds  almonds_1  half_almonds
2016-06-07T16:40:10Z   50       true       51
2016-06-07T16:40:20Z   55       true       56

• Spécifier que la clé est un champ

  > SELECT * FROM "candied" WHERE "almonds"::field > 51
  name: candied
  -------------
  time                   almonds  almonds_1  half_almonds
  2016-06-07T16:40:20Z   55       true       56

• Spécifier que la clé est un tag

  > SELECT * FROM "candied" WHERE "almonds"::tag='true'
  name: candied
  -------------
  time                   almonds  almonds_1  half_almonds
  2016-06-07T16:40:10Z   50       true       51
  2016-06-07T16:40:20Z   55       true       56

Comment interroger des données entre plusieurs mesures ?

Les opérations mathématiques ou le regroupement entre plusieurs mesures ne sont pas pris en charge. Toutes les données doivent résider dans la même mesure. TSDB for InfluxDB® n'est pas une base de données relationnelle ; évitez de mapper les données entre différentes mesures.

L'ordre des horodatages est-il important ?

Non. Les résultats des tests montrent qu'il existe très peu de différence dans le temps nécessaire à TSDB for InfluxDB® pour exécuter les requêtes suivantes :

SELECT ... FROM ... WHERE time > 'timestamp1' AND time < 'timestamp2'
SELECT ... FROM ... WHERE time < 'timestamp2' AND time > 'timestamp1'

Comment SELECT des données qui possèdent un tag mais aucune valeur de tag ?

Utilisez '' pour spécifier une valeur de tag vide. Par exemple :

> SELECT * FROM "vases" WHERE priceless=''
name: vases
-----------
time                   origin   priceless
2016-07-20T18:42:00Z   8

Comment écrire une valeur de champ entière ?

Pour écrire un entier, ajoutez un i à la fin de la valeur du champ. Sans ce suffixe, TSDB for InfluxDB® interprète la valeur comme un nombre à virgule flottante.

Exemple d'écriture d'un entier : value=100i. Exemple d'écriture d'un nombre à virgule flottante : value=100.

Comment TSDB for InfluxDB® gère-t-il les points de données en double ?

Un point de données est identifié de manière unique par son nom de mesure, son ensemble de tags et son horodatage. Si vous soumettez un point de données partageant la même mesure, le même ensemble de tags et le même horodatage qu'un point existant, mais avec un ensemble de champs différent, l'ensemble de champs résultant fusionne les anciens et les nouveaux champs. En cas de conflit, la nouvelle valeur prévaut. Il s'agit du comportement attendu.

Prenons l'exemple suivant :

Ancien point de données : cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

Nouveau point de données : cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000000

Après soumission du nouveau point de données, TSDB for InfluxDB® écrase la valeur de val_1 avec la nouvelle valeur, tout en conservant la valeur de val_2 :

> SELECT * FROM "cpu_load" WHERE time =1234567890000000
name: cpu_load
--------------
time                      az        hostname   val_1   val_2
1970-01-15T06:56:07.89Z   us_west   server02   5.247

Pour conserver les deux points de données distincts, vous pouvez :

• Ajouter un nouveau tag pour garantir l'unicité.

  Ancien point de données : cpu_load,hostname=server02,az=us_west,uniq=1 val_1=24.5,val_2=7 1234567890000000

  Nouveau point de données : cpu_load,hostname=server02,az=us_west,uniq=2 val_1=5.24 1234567890000000

  Résultat après écriture dans TSDB for InfluxDB® :

  > SELECT * FROM "cpu_load" WHERE time =1234567890000000
  name: cpu_load
  --------------
  time                      az        hostname   uniq   val_1   val_2
  1970-01-15T06:56:07.89Z   us_west   server02   124.57
  1970-01-15T06:56:07.89Z   us_west   server02   25.24

• Incrémenter l'horodatage d'une nanoseconde.

  Ancien point de données : cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

  Nouveau point de données : cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000001

  Résultat après écriture dans TSDB for InfluxDB® :

  > SELECT * FROM "cpu_load" WHERE time >=1234567890000000 and time <=1234567890000001
  name: cpu_load
  --------------
  time                             az        hostname   val_1   val_2
  1970-01-15T06:56:07.89Z          us_west   server02   24.57
  1970-01-15T06:56:07.890000001Z   us_west   server02   5.24

Quel caractère de saut de ligne l'API HTTP requiert-elle ?

Le protocole de ligne de TSDB for InfluxDB® repose sur le caractère de saut de ligne (\n

Écriture

Interrogation

t, f

√

❌

T, F

√

❌

true, false

√

√

True, False

√

√

TRUE, FALSE

√

√

Par exemple, SELECT * FROM "hamlet" WHERE "bool"=True renvoie tous les points de données où bool est égal à TRUE. En revanche, SELECT * FROM "hamlet" WHERE "bool"=T ne renvoie aucun résultat.

Comment TSDB for InfluxDB® gère-t-il les incohérences de type de champ entre les shards ?

Une valeur de champ peut être un nombre à virgule flottante, un entier, une chaîne ou une valeur booléenne. Au sein d'un même shard, le type de données d'une valeur de champ doit rester cohérent. Toutefois, ce type peut varier d'un shard à l'autre.

• Instruction SELECT

  Par défaut, une instruction SELECT renvoie toutes les valeurs de champ ayant le même type de données. Si le type de données d'une valeur de champ diffère selon les shards, TSDB for InfluxDB® effectue d'abord une conversion de type si possible, puis renvoie toutes les valeurs selon l'ordre suivant : nombre à virgule flottante, entier, chaîne, booléen. Si vos données contiennent des types de champ variés, utilisez la syntaxe <field_key>::<type> pour interroger les différents types. Voici un exemple :

  La mesure just_my_type contient un champ nommé my_field. Ce champ my_field présente quatre valeurs dans quatre shards différents, chacune ayant un type de données distinct (nombre à virgule flottante, entier, chaîne et booléen).

  L'instruction SELECT ne renvoie que les valeurs de type nombre à virgule flottante et entier. Dans les résultats, TSDB for InfluxDB® convertit forcement l'entier en nombre à virgule flottante.

  > SELECT * FROM just_my_type
  
  name: just_my_type
  ------------------
  time                      my_field
  2016-06-03T15:45:00Z      9.87034
  2016-06-03T16:45:00Z      7

  L'instruction SELECT <field_key>::<type> [...] renvoie tous les types de données. TSDB for InfluxDB® place les données de chaque type dans une colonne distincte, en incrémentant le nom de la colonne. Lorsque c'est possible, le système convertit la valeur de champ vers un autre type de données. Il convertit l'entier 7 en nombre à virgule flottante dans la première colonne, et le nombre à virgule flottante 9.879034 en entier dans la deuxième colonne. TSDB for InfluxDB® ne peut pas convertir un nombre à virgule flottante ou un entier en chaîne ou en booléen.

  > SELECT "my_field"::float,"my_field"::integer,"my_field"::string,"my_field"::boolean FROM just_my_type
  
  name: just_my_type
  ------------------
  time                   my_field  my_field_1  my_field_2  my_field_3
  2016-06-03T15:45:00Z9.870349
  2016-06-03T16:45:00Z77
  2016-06-03T17:45:00Z                         a string
  2016-06-03T18:45:00Z                                     true

• Requête SHOW FIELD KEYS

  La commande SHOW FIELD KEYS renvoie tous les types de données présents dans chaque shard pour la clé de champ donnée. Voici un exemple :

  La mesure just_my_type contient un champ nommé my_field. Ce champ my_field présente quatre valeurs dans quatre shards différents, chacune ayant un type de données distinct (nombre à virgule flottante, entier, chaîne et booléen).

  La commande SHOW FIELD KEYS renvoie les quatre types de données :

  > SHOW FIELD KEYS
  
  name: just_my_type
  fieldKey   fieldType
  -----------------
  my_field   float
  my_field   string
  my_field   integer
  my_field   boolean

Quelles sont les valeurs entières minimales et maximales que TSDB for InfluxDB® peut stocker ?

TSDB for InfluxDB® stocke tous les entiers sous forme de données signées int64. Les valeurs valides minimales et maximales pour le type int64 sont respectivement -9023372036854775808 et 9023372036854775807. Référence : Go builtins.

L'utilisation de valeurs proches des limites minimales ou maximales, bien que restant dans les plages autorisées, peut produire des résultats inattendus. Certaines fonctions et opérateurs convertissent le type de données int64 en float64 lors des calculs, ce qui peut provoquer des dépassements de capacité.

Quelles sont les valeurs d'horodatage minimales et maximales que TSDB for InfluxDB® peut stocker ?

L'horodatage minimal est -9223372036854775806 (soit 1677-09-21T00:12:43.145224194Z) et l'horodatage maximal est 9223372036854775806 (soit 2262-04-11T23:47:16.854775806Z). Les horodatages en dehors de cette plage génèrent une erreur d'analyse.

Comment connaître le type de données stocké dans un champ ?

La requête SHOW FIELD KEYS renvoie également le type de données du champ.

> SHOW FIELD KEYS FROM all_the_types
name: all_the_types
-------------------
fieldKey  fieldType
blue      string
green     boolean
orange    integer
yellow    float

Puis-je modifier le type de données d'un champ ?

TSDB for InfluxDB® offre un support très limité pour la modification du type de données d'un champ. La syntaxe <field_key>::<type> permet de convertir une valeur de champ d'un entier vers un nombre à virgule flottante, ou inversement. Consultez la section Exploration des données pour plus de détails sur les conversions. Il est impossible de convertir un nombre à virgule flottante ou un entier en chaîne ou en booléen, et vice versa.

Méthodes pour modifier le type de données d'un champ :

• Écrire les données dans un champ différent

  La solution la plus simple consiste à écrire les données avec le nouveau type de données dans un champ différent de la même série.

• Utiliser le système de shards

  Au sein d'un shard, le type de données d'une valeur de champ ne peut pas varier. En revanche, il peut différer d'un shard à l'autre.

  Pour modifier le type de données d'un champ, utilisez la requête SHOW SHARDS afin d'identifier l'end_time du shard actuel. Si l'horodatage d'un point de données est postérieur à l'end_time, TSDB for InfluxDB® autorise l'écriture de données d'un type différent dans un champ existant. Par exemple, un champ acceptant initialement des entiers pourra accepter des nombres à virgule flottante après l'end_time.

  Notez que cette opération ne modifie pas le type de données du champ dans le shard d'origine.

Comment effectuer des opérations mathématiques dans les fonctions ?

TSDB for InfluxDB® ne prend pas en charge les opérations mathématiques directement au sein des fonctions. Utilisez des sous-requêtes comme solution de contournement :

InfluxQL ne prend pas en charge la syntaxe suivante :

SELECT MEAN("dogs"-"cats") from "pet_daycare"

À la place, utilisez une sous-requête pour obtenir le même résultat :

> SELECT MEAN("difference") FROM (SELECT "dogs"-"cat" AS "difference" FROM "pet_daycare")

Détails sur les sous-requêtes : Exploration des données.

Pourquoi une requête renvoie-t-elle epoch 0 comme horodatage ?

Dans TSDB for InfluxDB®, epoch 0 (1970-01-01T00:00:00Z) sert souvent d'horodatage nul. Si vous exécutez une requête pour laquelle aucun horodatage ne peut être renvoyé, telle qu'une fonction d'agrégation sans plage de temps spécifiée, TSDB for InfluxDB® renvoie epoch 0 comme horodatage.

Quelles fonctions InfluxQL prennent en charge l'imbrication ?

Les fonctions InfluxQL suivantes prennent en charge l'imbrication :

• COUNT() avec DISTINCT() imbriqué

• CUMULATIVE_SUM()

• DERIVATIVE()

• DIFFERENCE()

• ELAPSED()

• MOVING_AVERAGE()

• NON_NEGATIVE_DERIVATIVE()

• HOLT_WINTERS() et HOLT_WINTERS_WITH_FIT()

Pour savoir comment utiliser des sous-requêtes à la place des fonctions imbriquées, consultez la section Exploration des données.

Comment migrer une instance InfluxDB auto-gérée vers le cloud ?

Utilisez l'outil officiel InfluxDB influx_inspect pour exporter des fichiers au format protocole de ligne depuis votre serveur InfluxDB auto-géré. Importez ensuite ces fichiers dans TSDB for InfluxDB® via l'interface de ligne de commande (Influx CLI).

Comment migrer des données entre différentes instances InfluxDB dans le cloud ?

Aucun outil de migration intégré n'existe entre les instances InfluxDB. Exportez les données via des requêtes et importez-les manuellement. Utilisez des filtres temporels et de tags pour traiter la migration par lots et éviter les requêtes volumineuses susceptibles d'affecter la stabilité.

Comment migrer des données d'InfluxDB vers LindormTSDB ?

Importez les données complètes de votre instance TSDB for InfluxDB® vers LindormTSDB. Solutions de migration des données historiques TSDB for InfluxDB®.