Time Series Database:Preguntas frecuentes

Series y cardinalidad de series

• How do I perform modeling and what are the precautions?

• Why is series cardinality important?

Administración

• What should I note for system stability?

• How do I view the disk usage for a measurement?

• How do I delete data efficiently and securely?

• Why does a modified retention policy not take effect?

• Why are services frequently interrupted?

• Why is memory usage high and do I need to upgrade?

• Is storage scale-in supported?

• Does expanding a disk cause a restart?

• How long does a restart take?

• Is the built-in Grafana for InfluxDB supported?

• Why do I get an ip block error on access?

• How do I identify the version of TSDB for InfluxDB®?

• What is the relationship between a shard group duration and a retention policy?

• Why is no data lost after I change a retention policy?

• Why can TSDB for InfluxDB® not parse the microsecond unit?

Consulta de datos

• How do I troubleshoot slow queries?

• What determines the time interval returned by a GROUP BY time() query?

• Why does a query return no data or only partial data?

• Why does a GROUP BY time() query not return timestamps that occur after now()?

• Can I perform mathematical operations on timestamps?

• Can I identify the write precision from returned timestamps?

• When should I use single quotation marks and double quotation marks when I query data?

• Why is data lost after I create a new DEFAULT retention policy?

• Why does a query with a WHERE OR time clause return an empty result?

• Why does fill(previous) return an empty result?

• Why does an INTO query lose data?

• How do I query data when a tag key and a field key have the same name?

• How do I query data across measurements?

• Is the order of timestamps important?

• How do I SELECT data that has a tag but no tag value?

Escritura de datos

• Why does write jitter occur periodically?

• Precautions for line protocol writes

• Why is data not visible after it is written?

• Why does writing not resume after disk space is freed up from a full state?

• How do I write an integer field value?

• How does TSDB for InfluxDB® handle duplicate data points?

• What line feed does the HTTP API require?

• What words and characters should I avoid when I write data to TSDB for InfluxDB®?

• When should I use single quotation marks and double quotation marks when I write data?

• Is timestamp precision important?

Interfaz de línea de comandos (Influx CLI)

• Why can I not connect to TSDB for InfluxDB® using the command-line interface?

• How do I make the Influx CLI for TSDB for InfluxDB® return human-readable timestamps?

• How can a non-admin user use USE to specify a database?

• How do I use the Influx CLI for TSDB for InfluxDB® to write data to a non-default retention policy?

Tipos de datos

• Why can I not query a Boolean field value?

• How does TSDB for InfluxDB® handle field type discrepancies across shards?

• What are the minimum and maximum integers that TSDB for InfluxDB® can store?

• What are the minimum and maximum timestamps that TSDB for InfluxDB® can store?

• How do I know the data type stored in a field?

• Can I change the data type of a field?

Funciones de InfluxQL

• How do I perform mathematical operations in functions?

• Why does a query return epoch 0 as a timestamp?

• Which InfluxQL functions support nesting?

Migración de datos de InfluxDB

• How do I migrate a self-managed InfluxDB to the cloud?

• How do I migrate data between different InfluxDB instances in the cloud?

• How do I migrate data from InfluxDB to LindormTSDB?

¿Por qué es importante la cardinalidad de series?

TSDB for InfluxDB® mantiene un índice en memoria por cada serie. A medida que aumenta el número de series, también lo hace el uso de RAM. Una cardinalidad excesivamente alta puede desencadenar una excepción de falta de memoria (OOM) que finaliza el proceso. InfluxQL Reference

¿Cómo realizo el modelado y qué precauciones debo tomar?

Mantenga el número de series temporales por debajo de un millón. Para escenarios con grandes volúmenes de series temporales, utilice Introduction to LindormTSDB. Revise la guía de esquema y diseño de datos de InfluxDB. InfluxDB indexa las etiquetas para acelerar las consultas, pero un exceso de etiquetas provoca una inflación de series que ralentiza las lecturas y escrituras. Consideraciones clave:

• Evite usar etiquetas con valores de alta cardinalidad, como identificadores, valores hash y cadenas aleatorias.

• No almacene datos en nombres de mediciones ni en nombres de etiquetas. Almacene los datos en etiquetas y campos.

• No almacene múltiples fragmentos de información en una sola etiqueta. Divida la información en varias etiquetas.

• Si utiliza frecuentemente un campo en una cláusula GROUP BY, modélelo como una etiqueta.

¿Cómo identifico la versión de TSDB for InfluxDB®?

Utilice uno de los siguientes métodos:

• 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

• Inicie la interfaz de línea de comandos para TSDB for InfluxDB®

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

¿Cuál es la relación entre la duración de un grupo de shards y una directiva de retención?

TSDB for InfluxDB® almacena datos en grupos de shards. Un grupo de shards abarca un intervalo de tiempo específico. TSDB for InfluxDB® determina el intervalo de tiempo comprobando la DURATION de la directiva de retención (RP) correspondiente. La siguiente tabla muestra la relación predeterminada entre la DURATION de una RP y el intervalo de tiempo de un grupo de shards:

Utilice SHOW RETENTION POLICIES para consultar la duración del grupo de shards de una directiva de retención.

¿Por qué no se pierden datos después de cambiar una directiva de retención?

Es posible que los datos no se pierdan inmediatamente después de cambiar una directiva de retención por las siguientes razones:

• Primera razón posible (escenario más probable): De forma predeterminada, TSDB for InfluxDB® comprueba y aplica las RP cada 30 minutos. Es posible que deba esperar a la siguiente comprobación de RP antes de que TSDB for InfluxDB® elimine los datos que están fuera de la nueva DURATION de la RP.

• Segunda razón posible: Cambiar la DURATION y la SHARD DURATION de una RP puede provocar una retención de datos inesperada. TSDB for InfluxDB® almacena datos en grupos de shards. Cada grupo de shards abarca una RP y un intervalo de tiempo específicos. Cuando TSDB for InfluxDB® aplica una RP, elimina todo el grupo de shards, no puntos de datos individuales. TSDB for InfluxDB® no puede dividir grupos de shards. Si la nueva DURATION de la RP es menor que la antigua SHARD DURATION, y TSDB for InfluxDB® está escribiendo datos en un grupo de shards antiguo con una DURATION mayor, el sistema se ve obligado a almacenar todos los datos en ese grupo de shards. Esto ocurre incluso si algunos datos del grupo de shards están fuera de la nueva DURATION. Una vez que todos los datos del grupo de shards quedan fuera de la nueva DURATION, TSDB for InfluxDB® elimina todo el grupo de shards. Entonces, el sistema comienza a escribir datos en grupos de shards con la nueva SHARD DURATION más corta. Esto evita una mayor retención inesperada de datos.

¿Por qué TSDB for InfluxDB® no puede analizar la unidad de microsegundos?

La sintaxis para especificar la unidad de tiempo en microsegundos difiere al escribir, consultar y establecer la precisión en la interfaz de línea de comandos de TSDB for InfluxDB® (Influx CLI). La siguiente tabla muestra la sintaxis compatible para cada categoría:

¿Cómo soluciono problemas de consultas lentas?

Las consultas lentas suelen ser resultado de escanear demasiadas series temporales o demasiados datos sin procesar. Agregue filtros de etiquetas y de rango de tiempo a cada consulta. Utilice el comando EXPLAIN ANALYZE para diagnosticar el rendimiento: execution_time refleja la lectura y computación de datos, mientras que planning_time refleja el escaneo de series.

¿Qué determina el intervalo de tiempo devuelto por una consulta GROUP BY time()?

El intervalo de tiempo devuelto por una consulta GROUP BY time() coincide con los intervalos de tiempo predefinidos de TSDB for InfluxDB® o con un intervalo de desplazamiento especificado por el usuario. Consulte los siguientes ejemplos:

• Intervalos de tiempo predefinidos

  La siguiente consulta calcula el promedio de sunflowers entre las 6:15 p. m. y las 7:45 p. m., y agrupa los promedios por una hora:

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

  Los siguientes resultados muestran cómo TSDB for InfluxDB® mantiene sus intervalos de tiempo predefinidos.

  En este ejemplo, las 6 p. m. son un intervalo de tiempo predefinido, y las 7 p. m. también lo son. Dado que la cláusula WHERE especifica el rango de tiempo de la consulta, los datos anteriores a las 6:15 p. m. no se incluyen al calcular el promedio para el intervalo de las 6 p. m. Sin embargo, los datos utilizados para calcular el promedio del intervalo de las 6 p. m. deben ocurrir dentro de esa hora. Lo mismo aplica para el intervalo de las 7 p. m. Los datos utilizados para calcular el promedio del intervalo de las 7 p. m. deben ocurrir dentro de esa hora. Las líneas discontinuas muestran los puntos de datos utilizados para calcular cada promedio.

  Tenga en cuenta que, aunque la primera marca de tiempo en el resultado es 2016-08-29T18:00:00Z, el resultado de la consulta para ese intervalo de tiempo no incluye datos ocurridos antes de 2016-08-29T18:15:00Z, que es la hora de inicio especificada en la cláusula WHERE.

  Datos sin procesar:

  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

• Intervalo de desplazamiento

  La siguiente consulta calcula el promedio de sunflowers entre las 6:15 p. m. y las 7:45 p. m., y agrupa los promedios por una hora. La consulta también desplaza los intervalos de tiempo predefinidos de TSDB for InfluxDB® en 15 minutos:

  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

  En este ejemplo, el intervalo de desplazamiento especificado por el usuario adelanta los intervalos de tiempo predefinidos de TSDB for InfluxDB® en 15 minutos. Ahora, el promedio para el intervalo de las 6 p. m. incluye datos entre las 6:15 p. m. y las 7:15 p. m. El promedio para el intervalo de las 7 p. m. incluye datos entre las 7:15 p. m. y las 8:15 p. m. Las líneas discontinuas muestran los puntos de datos utilizados para calcular cada promedio.

  Tenga en cuenta que la primera marca de tiempo en el resultado ahora es 2016-08-29T18:15:00Z, no 2016-08-29T18:00:00Z.

  Datos sin procesar y resultados:

  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|
  |--|

¿Por qué una consulta no devuelve datos o solo devuelve datos parciales?

Razones comunes:

• Directiva de retención

  La primera explicación y la más común se relaciona con las directivas de retención (RP). TSDB for InfluxDB® consulta automáticamente los datos de la RP DEFAULT de la base de datos. Si sus datos no están almacenados en la RP predeterminada, TSDB for InfluxDB® no devolverá ningún resultado a menos que especifique explícitamente la RP que se debe utilizar.

• Clave de etiqueta en la cláusula SELECT

  La cláusula SELECT debe incluir al menos una clave de campo para que la consulta devuelva datos. Si la cláusula SELECT contiene solo una o más claves de etiqueta, la consulta devuelve un resultado vacío. Para obtener más información, consulte Exploración de datos.

• Rango de tiempo de la consulta

  Otra posible explicación se relaciona con el rango de tiempo de la consulta. De forma predeterminada, la mayoría de las consultas SELECT cubren el rango de tiempo entre 1677-09-21 00:12:43.145224194 UTC y 2262-04-11T23:47:16.854775806Z UTC. Sin embargo, una consulta SELECT que incluye una cláusula GROUP BY time() cubre un rango de tiempo entre 1677-09-21 00:12:43.145224194 y now(). Si sus datos ocurren después de now(), la consulta GROUP BY time() no cubrirá los datos ocurridos después de now(). Si una sentencia de consulta incluye una cláusula GROUP BY time() y tiene datos que ocurren después de now(), debe proporcionar un límite superior para el rango de tiempo.

• Nombre de identificador

  La última explicación común se relaciona con el esquema, donde un campo y una etiqueta tienen el mismo nombre. Si una clave de campo y una clave de etiqueta son idénticas, se da prioridad al campo en todas las consultas. En la consulta, debe utilizar la sintaxis ::tag para especificar la clave de etiqueta.

¿Por qué una consulta GROUP BY time() no devuelve marcas de tiempo posteriores a now()?

El rango de tiempo predeterminado para la mayoría de las sentencias SELECT es entre 1677-09-21 00:12:43.145224194 UTC y 2262-04-11T23:47:16.854775806Z UTC. Para las sentencias SELECT con una cláusula GROUP BY time(), el rango de tiempo predeterminado es entre 1677-09-21 00:12:43.145224194 y now().

Para consultar datos con marcas de tiempo posteriores a now(), una sentencia SELECT con una cláusula GROUP BY time() debe proporcionar un límite de tiempo superior en la cláusula WHERE.

En el siguiente ejemplo, la primera consulta cubre datos con marcas de tiempo entre 2015-09-18T21:30:00Z y now(). La segunda consulta cubre datos con marcas de tiempo entre 2015-09-18T21:30:00Z y 180 semanas después de 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)

Tenga en cuenta que la cláusula WHERE debe proporcionar un límite de tiempo superior para anular el límite superior predeterminado now(). La siguiente consulta simplemente restablece el límite inferior a now(), haciendo que el rango de tiempo de la consulta sea entre now() y now():

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

Detalles de la sintaxis de tiempo: Data exploration.

¿Puedo realizar operaciones matemáticas en marcas de tiempo?

TSDB for InfluxDB® no admite operaciones matemáticas en marcas de tiempo. Realice los cálculos de tiempo en el lado del cliente.

TSDB for InfluxDB® ofrece soporte limitado para usar funciones de InfluxQL en marcas de tiempo. La función ELAPSED() devuelve la diferencia entre marcas de tiempo en un solo campo.

¿Puedo identificar la precisión de escritura a partir de las marcas de tiempo devueltas?

TSDB for InfluxDB® almacena todas las marcas de tiempo en nanosegundos, independientemente de la precisión de escritura. La base de datos elimina silenciosamente los ceros finales de las marcas de tiempo devueltas, lo que dificulta identificar la precisión de escritura original.

En el siguiente ejemplo, las etiquetas precision_supplied y timestamp_supplied muestran la precisión de tiempo y la marca de tiempo que el usuario proporcionó al escribir los datos. Debido a que TSDB for InfluxDB® elimina silenciosamente los ceros finales de la marca de tiempo devuelta, es difícil identificar la precisión de escritura a partir de la marca de tiempo devuelta.

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

¿Cuándo debo usar comillas simples y comillas dobles al consultar datos?

Utilice comillas simples para encerrar valores de cadena, como valores de etiqueta. No utilice comillas simples para encerrar identificadores. Los identificadores incluyen nombres de bases de datos, nombres de directivas de retención, nombres de usuario, nombres de mediciones, claves de etiqueta y claves de campo.

Utilice comillas dobles para encerrar identificadores si comienzan con un dígito, contienen caracteres distintos de [A-z,0-9,_] o son una palabra clave de InfluxQL. Si un identificador no entra en ninguna de estas categorías, no necesita encerrarlo entre comillas dobles. Sin embargo, le recomendamos que lo haga.

Ejemplos:

Consulta válida: SELECT bikes_available FROM bikes WHERE station_id='9'

Consulta válida: SELECT "bikes_available" FROM "bikes" WHERE "station_id"='9'

Consulta válida: SELECT MIN("avgrq-sz") AS "min_avgrq-sz" FROM telegraf

Consulta válida: SELECT * from "cr@zy" where "p^e"='2'

Consulta no válida: SELECT 'bikes_available' FROM 'bikes' WHERE 'station_id'="9"

Consulta no válida: SELECT * from cr@zy where p^e='2'

Utilice comillas simples para encerrar cadenas de fecha y hora. Si utiliza comillas dobles para encerrar cadenas de fecha y hora, TSDB for InfluxDB® devuelve un error (ERR: invalid operation: time and *influxql.VarRef are not compatible).

Ejemplo:

Consulta válida: SELECT "water_level" FROM "h2o_feet" WHERE time > '2015-08-18T23:00:01.232000000Z' AND time < '2015-09-19'

Consulta no válida: SELECT "water_level" FROM "h2o_feet" WHERE time > "2015-08-18T23:00:01.232000000Z" AND time < "2015-09-19"

Detalles de la sintaxis de tiempo: Data exploration.

¿Por qué se pierden datos después de crear una nueva directiva de retención DEFAULT?

Cuando crea una nueva directiva de retención (RP) predeterminada en una base de datos, los datos de la antigua RP predeterminada permanecen en la RP antigua. Las consultas que no especifican una RP consultarán automáticamente los datos de la nueva RP predeterminada, y todos los datos antiguos podrían parecer perdidos. Para consultar los datos antiguos, debe calificar completamente los datos en la consulta. Consulte el siguiente ejemplo:

Todos los datos en la medición fleeting pertenecen a la RP predeterminada, que se llama one_hour:

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

Ahora creamos una nueva RP predeterminada (two_hour) y ejecutamos la misma consulta:

> SELECT count(flounders) FROM fleeting
>

Para consultar los datos antiguos, debemos especificar la antigua RP predeterminada calificando completamente fleeting:

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

¿Por qué una consulta con una cláusula de tiempo WHERE OR devuelve un resultado vacío?

TSDB for InfluxDB® no admite OR en la cláusula WHERE para especificar múltiples rangos de tiempo. Si la cláusula WHERE de una consulta utiliza OR para especificar múltiples rangos de tiempo, TSDB for InfluxDB® no devuelve ningún resultado.

Ejemplo:

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

¿Por qué fill(previous) devuelve un resultado vacío?

Si el valor anterior está fuera del rango de tiempo de la consulta, fill(previous) no rellena un valor para ese intervalo de tiempo.

En el siguiente ejemplo, TSDB for InfluxDB® no rellena un valor para el intervalo de tiempo 2016-07-12T16:50:20Z-2016-07-12T16:50:30Z con el valor del intervalo de tiempo 2016-07-12T16:50:00Z-2016-07-12T16:50:10Z porque el rango de tiempo de la consulta no incluye el intervalo de tiempo anterior.

Datos de muestra:

> 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

Consulta 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

¿Por qué una consulta INTO pierde datos?

De forma predeterminada, una consulta INTO convierte las etiquetas de los datos de origen en campos dentro de los nuevos datos escritos. Esto puede provocar que TSDB for InfluxDB® sobrescriba puntos de datos que antes se diferenciaban por una etiqueta. Incluya GROUP BY * en todas las consultas INTO para conservar las etiquetas en los nuevos datos escritos.

> 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

• Consulta INTO sin GROUP BY *

  Una consulta INTO sin la cláusula GROUP BY * convierte la etiqueta color en un campo dentro de los nuevos datos escritos. En los datos de origen, los puntos de datos nugget y rumple se diferencian únicamente por la etiqueta color. Cuando color se convierte en un campo, TSDB for InfluxDB® considera que los puntos de datos nugget y rumple son duplicados, por lo que sobrescribe el punto de datos nugget con el punto de datos 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

• Consulta INTO con GROUP BY *

  Una consulta INTO con la cláusula GROUP BY * conserva la etiqueta color en los nuevos datos escritos. En este caso, los puntos de datos nugget y rumple permanecen como puntos distintos, y TSDB for InfluxDB® no sobrescribe ningún dato.

  > 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

¿Cómo consulto datos cuando una clave de etiqueta y una clave de campo tienen el mismo nombre?

Utilice la sintaxis :: para especificar si una clave es de campo o de etiqueta. Datos de ejemplo:

> 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

• Especificar que la clave es un campo

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

• Especificar que la clave es una etiqueta

  > 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

¿Cómo consulto datos entre varias mediciones?

No se admiten operaciones matemáticas ni agrupaciones entre mediciones. Todos los datos deben residir en la misma medición. TSDB for InfluxDB® no es una base de datos relacional; evite mapear datos entre distintas mediciones.

¿Es importante el orden de las marcas de tiempo?

No. Las pruebas muestran que existe muy poca diferencia en el tiempo que tarda TSDB for InfluxDB® en completar las siguientes consultas:

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

¿Cómo SELECT datos que tienen una etiqueta pero sin valor de etiqueta?

Utilice '' para especificar un valor de etiqueta vacío. Por ejemplo:

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

¿Cómo escribo un valor de campo entero?

Al escribir un entero, agregue una i al final del valor del campo. Si no agrega la i, TSDB for InfluxDB® trata el valor del campo como un número de punto flotante.

Para escribir un entero: value=100i. Para escribir un número de punto flotante: value=100.

¿Cómo maneja TSDB for InfluxDB® los puntos de datos duplicados?

Un punto de datos se identifica de forma única por su nombre de medición, conjunto de etiquetas y marca de tiempo. Si envía un punto de datos que tiene la misma medición, conjunto de etiquetas y marca de tiempo que un punto existente, pero con un conjunto de campos diferente, el conjunto de campos del punto de datos se convierte en la unión de los conjuntos antiguo y nuevo. Si existe algún conflicto, prevalece el nuevo conjunto de campos. Este es el comportamiento esperado.

Por ejemplo:

Punto de datos anterior: cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

Nuevo punto de datos: cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000000

Después de enviar el nuevo punto de datos, TSDB for InfluxDB® sobrescribe el valor de val_1 con el nuevo valor de campo, y se conserva el valor 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

Para almacenar ambos puntos de datos, puede realizar lo siguiente:

• Introducir una nueva etiqueta para garantizar la unicidad.

  Punto de datos anterior: cpu_load,hostname=server02,az=us_west,uniq=1 val_1=24.5,val_2=7 1234567890000000

  Nuevo punto de datos: cpu_load,hostname=server02,az=us_west,uniq=2 val_1=5.24 1234567890000000

  Después de escribir el nuevo punto de datos en 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

• Incrementar la marca de tiempo en un nanosegundo.

  Punto de datos anterior: cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

  Nuevo punto de datos: cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000001

  Después de escribir el nuevo punto de datos en 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

¿Qué salto de línea requiere la API HTTP?

El protocolo de línea para TSDB for InfluxDB® depende del carácter de salto de línea (\n, que corresponde a ASCII 0x0A) para indicar el final de una línea y el inicio de otra. Un archivo o conjunto de datos que utilice un carácter de salto de línea distinto de \n provocará un error de bad timestamp o unable to parse.

Windows utiliza \r\n (retorno de carro + salto de línea), lo cual es incompatible.

¿Qué palabras y caracteres debo evitar al escribir datos en TSDB for InfluxDB®?

• Palabras clave de InfluxQL

  Si utiliza una palabra clave de InfluxQL como identificador, debe encerrar ese identificador entre comillas dobles en cada consulta. De lo contrario, se producirá un error. Los identificadores incluyen nombres de consultas continuas, nombres de bases de datos, claves de campo, nombres de mediciones, nombres de directivas de retención, claves de etiqueta y nombres de usuario.

• Time

  La palabra clave time es un caso especial. time puede usarse como nombre de consulta continua, nombre de base de datos, nombre de medición, nombre de directiva de retención y nombre de usuario. En estos casos, no es necesario encerrar time entre comillas dobles en una consulta. Sin embargo, time no puede ser una clave de campo ni una clave de etiqueta. TSDB for InfluxDB® rechaza las escrituras de datos que utilizan time como clave de campo o de etiqueta, y devuelve un error para dichas escrituras. Consulte los siguientes ejemplos:

  • Escribir y consultar datos con time como medición.

    > INSERT time value=1
    
    > SELECT * FROM time
    
    name: time
    time                            value
    ---------
    2017-02-07T18:28:27.349785384Z  1

    En TSDB for InfluxDB®, time es un nombre de medición válido.

  • Escribir e intentar consultar datos con time como clave de campo.

    > INSERT mymeas time=1
    ERR:{"error":"partial write: invalid field name: input field \"time\" on measurement \"mymeas\" is invalid dropped=1"}

    En TSDB for InfluxDB®, time no es una clave de campo válida. El sistema no puede escribir el punto de datos y devuelve un error 400.

  • Escribir e intentar consultar datos con time como clave de etiqueta.

    > INSERT mymeas,time=1 value=1
    ERR:{"error":"partial write: invalid tag key: input tag \"time\" on measurement \"mymeas\" is invalid dropped=1"}

    En TSDB for InfluxDB®, time no es una clave de etiqueta válida. El sistema no puede escribir el punto de datos y devuelve un error 400.

• Caracteres

  Para mantener expresiones regulares y citas sencillas, evite usar los siguientes caracteres en los identificadores: \ (barra invertida), ^ (acento circunflejo), $ (signo de dólar), ' (comilla simple), " (comilla doble), = (signo igual) y , (coma).

¿Cuándo debo usar comillas simples y comillas dobles al escribir datos?

• Evite encerrar identificadores entre comillas al escribir con el protocolo de línea, ya que esto complica las consultas. Los identificadores incluyen nombres de consultas continuas, nombres de bases de datos, claves de campo, nombres de mediciones, nombres de directivas de retención, nombres de suscripciones, claves de etiqueta y nombres de usuario.

  • Escribir una medición con comillas dobles: INSERT "bikes" bikes_available=3. Consulta aplicable: SELECT * FROM "\"bikes\""

  • Escribir una medición con comillas simples: INSERT 'bikes' bikes_available=3. Consulta aplicable: SELECT * FROM "\'bikes\'"

  • Escribir una medición sin comillas: INSERT bikes bikes_available=3. Consulta aplicable: SELECT * FROM "bikes"

• Utilice comillas dobles para encerrar valores de campo de tipo cadena.

  Escritura: INSERT bikes happiness="level 2". Consulta aplicable: SELECT * FROM "bikes" WHERE "happiness"='level 2'

• Escape los caracteres especiales con una barra invertida en lugar de encerrarlos entre comillas.

  Escritura: INSERT wacky va\"ue=4. Consulta aplicable: SELECT "va\"ue" FROM "wacky"

¿Es importante la precisión de la marca de tiempo?

Para obtener un rendimiento óptimo de escritura, utilice la precisión de tiempo más baja posible.

En los siguientes dos ejemplos, la primera solicitud usa la precisión predeterminada (nanosegundos), mientras que la segunda establece la precisión en segundos:

curl -i -XPOST "https://<endpoint>:3242/write?db=weather&u=<username>&p=<password>" --data-binary 'temperature,location=1 value=90 1472666050000000000'

curl -i -XPOST "https://<endpoint>:3242/write?db=weather&precision=s&u=<username>&p=<password>" --data-binary 'temperature,location=1 value=90 1472666050'

La contrapartida es que una precisión más baja aumenta la probabilidad de marcas de tiempo duplicadas, lo que puede causar sobrescritura de datos.

¿Por qué no puedo conectarme a TSDB for InfluxDB® mediante la interfaz de línea de comandos?

Compruebe una por una las siguientes condiciones:

• Debe contar con permisos de ejecución. Ejecute el comando chmod +x ./influx para agregar los permisos necesarios.

• Debe especificar la opción -ssl en la instrucción de conexión.

• Para la opción -host, especifique únicamente la cadena de conexión, como ts-bp17j28j2y7pm****.influxdata.rds.aliyuncs.com. No agregue el protocolo ni el número de puerto.

¿Cómo configuro Influx CLI para TSDB for InfluxDB® para que devuelva marcas de tiempo legibles?

Al conectarse por primera vez a Influx CLI, especifique la precisión rfc3339:

$ influx -ssl -username <username> -password <password> -host <endpoint> -port 3242 -precision rfc3339

Alternativamente, especifique la precisión después de conectarse a Influx CLI:

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

Detalles: Command-line interface (Influx CLI).

¿Cómo puede un usuario sin privilegios de administrador usar USE para especificar una base de datos?

Si un usuario sin privilegios de administrador tiene permisos READ y WRITE, o solo permiso READ sobre una base de datos, podrá ejecutar la instrucción USE <database_name>. Si un usuario sin privilegios de administrador intenta usar USE para especificar una base de datos para la cual no tiene permisos READ y WRITE, o permiso READ, el sistema devuelve un error:

ERR: Database <database_name> doesn't exist. Run SHOW DATABASES for a list of existing databases.

¿Cómo uso Influx CLI para TSDB for InfluxDB® con el fin de escribir datos en una directiva de retención no predeterminada?

Utilice la sintaxis INSERT INTO [<database>.]<retention_policy> <line_protocol> para escribir datos en una directiva de retención no predeterminada. (Este método para especificar la base de datos y la directiva de retención solo se permite en Influx CLI. Si escribe datos a través de HTTP, debe usar los parámetros db y rp para especificar la base de datos y la directiva de retención, respectivamente. Especificar la directiva de retención es opcional). Consulte el siguiente ejemplo.

> INSERT INTO one_day mortality bool=true
Using retention policy one_day
> SELECT * FROM "mydb"."one_day"."mortality"
name: mortality
---------------
time                             bool
2016-09-13T22:29:43.229530864Z   true

Debe calificar completamente la medición para consultar datos en una directiva de retención no predeterminada. Utilice la siguiente sintaxis para calificar completamente una medición:

"<database>"."<retention_policy>"."<measurement>"

¿Por qué no puedo consultar un valor de campo booleano?

La sintaxis para escribir y consultar valores booleanos es diferente.

Por ejemplo, SELECT * FROM "hamlet" WHERE "bool"=True devuelve todos los puntos de datos donde bool es igual a TRUE. Sin embargo, SELECT * FROM "hamlet" WHERE "bool"=T no devuelve ningún resultado.

¿Cómo maneja TSDB for InfluxDB® las discrepancias de tipos de campo entre shards?

Un valor de campo puede ser un número de punto flotante, un entero, una cadena o un valor booleano. Dentro de un mismo shard, el tipo de datos de un valor de campo debe ser consistente. No obstante, entre diferentes shards, el tipo de datos de un valor de campo puede variar.

• Instrucción SELECT

  Una instrucción SELECT devuelve de forma predeterminada todos los valores de campo del mismo tipo de datos. Si el tipo de datos de un valor de campo no es el mismo en diferentes shards, TSDB for InfluxDB® realiza primero una conversión de tipos, si es aplicable. Luego, devuelve todos los valores en el siguiente orden de tipos de datos: número de punto flotante, entero, cadena y booleano. Si el tipo de un valor de campo difiere en sus datos, utilice la sintaxis <field_key>::<type> para consultar los distintos tipos de datos. Consulte el siguiente ejemplo:

  La medición just_my_type tiene un campo llamado my_field. my_field posee cuatro valores de campo en cuatro shards diferentes, y el tipo de datos de cada valor es distinto (número de punto flotante, entero, cadena y booleano, respectivamente).

  SELECT devuelve únicamente los valores de campo de punto flotante y enteros. En los resultados, TSDB for InfluxDB® fuerza la conversión del entero a un número de punto flotante.

  > 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

  SELECT <field_key>::<type> [...] devuelve todos los tipos de datos. TSDB for InfluxDB® genera los datos de cada tipo en una columna separada y utiliza un nombre de columna incremental. Cuando es posible, TSDB for InfluxDB® convierte un valor de campo a otro tipo de datos. Convierte el entero 7 a un número de punto flotante en la primera columna, y el número de punto flotante 9.879034 a un entero en la segunda columna. TSDB for InfluxDB® no puede convertir un número de punto flotante o un entero a una cadena o a un valor booleano.

  > 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

• Consulta SHOW FIELD KEYS

  SHOW FIELD KEYS devuelve cada tipo de datos en cada shard que corresponde a la clave de campo. Consulte el siguiente ejemplo:

  La medición just_my_type tiene un campo llamado my_field. my_field posee cuatro valores de campo en cuatro shards diferentes, y el tipo de datos de cada valor es distinto (número de punto flotante, entero, cadena y booleano, respectivamente).

  SHOW FIELD KEYS devuelve los cuatro tipos de datos:

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

¿Cuáles son los enteros mínimo y máximo que puede almacenar TSDB for InfluxDB®?

TSDB for InfluxDB® almacena todos los enteros como tipos de datos int64 con signo. Los valores mínimo y máximo válidos para int64 son -9023372036854775808 y 9023372036854775807, respectivamente. Referencia: Go builtins.

El uso de valores cercanos al entero mínimo o máximo, pero aún dentro de los límites, puede provocar resultados inesperados. Algunas funciones y operadores convierten el tipo de datos int64 a float64 durante el cálculo, lo que puede causar problemas de desbordamiento.

¿Cuáles son las marcas de tiempo mínima y máxima que puede almacenar TSDB for InfluxDB®?

La marca de tiempo mínima es -9223372036854775806 o 1677-09-21T00:12:43.145224194Z, y la marca de tiempo máxima es 9223372036854775806 o 2262-04-11T23:47:16.854775806Z. Las marcas de tiempo fuera de este rango devuelven un error de análisis sintáctico.

¿Cómo sé qué tipo de datos se almacena en un campo?

La consulta SHOW FIELD KEYS también devuelve el tipo de datos del campo.

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

¿Puedo cambiar el tipo de datos de un campo?

TSDB for InfluxDB® ofrece un soporte muy limitado para cambiar el tipo de datos de un campo. La sintaxis <field_key>::<type> admite la conversión de un valor de campo de entero a número de punto flotante, o de número de punto flotante a entero. Los detalles de la conversión se encuentran en Exploración de datos. No es posible convertir un número de punto flotante o un entero a una cadena o a un valor booleano, ni viceversa.

Métodos para cambiar el tipo de datos de un campo:

• Escribir los datos en un campo diferente

  La solución más sencilla consiste en escribir los datos con el nuevo tipo de datos en un campo diferente dentro de la misma serie.

• Usar el sistema de shards

  Dentro de un mismo shard, el tipo de datos de un valor de campo no puede variar. Sin embargo, entre diferentes shards, el tipo de datos de un valor de campo sí puede ser distinto.

  Para cambiar el tipo de datos de un campo, un usuario puede emplear la consulta SHOW SHARDS para identificar el valor end_time del shard actual. Si la marca de tiempo de un punto de datos ocurre después del end_time, TSDB for InfluxDB® permite escribir datos de un tipo diferente en un campo existente. Por ejemplo, si un campo originalmente aceptaba enteros, después del end_time podrá aceptar números de punto flotante.

  Tenga en cuenta que esto no cambia el tipo de datos del campo en el shard original.

¿Cómo realizo operaciones matemáticas dentro de funciones?

TSDB for InfluxDB® no admite operaciones matemáticas dentro de las funciones. Como alternativa, utilice subconsultas:

InfluxQL no admite la siguiente sintaxis:

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

En su lugar, podemos usar una subconsulta para obtener el mismo resultado:

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

Detalles sobre subconsultas: Data exploration.

¿Por qué una consulta devuelve epoch 0 como marca de tiempo?

En TSDB for InfluxDB®, epoch 0 (1970-01-01T00:00:00Z) se utiliza frecuentemente como una marca de tiempo nula. Si solicita una consulta para la cual no se puede devolver ninguna marca de tiempo, como una función de agregación sin un rango de tiempo especificado, TSDB for InfluxDB® devuelve epoch 0 como marca de tiempo.

¿Qué funciones de InfluxQL admiten anidamiento?

Las siguientes funciones de InfluxQL admiten anidamiento:

• COUNT() con DISTINCT() anidado

• CUMULATIVE_SUM()

• DERIVATIVE()

• DIFFERENCE()

• ELAPSED()

• MOVING_AVERAGE()

• NON_NEGATIVE_DERIVATIVE()

• HOLT_WINTERS() y HOLT_WINTERS_WITH_FIT()

Para obtener información sobre cómo utilizar subconsultas en lugar de funciones anidadas, consulte Exploración de datos.

¿Cómo migro una instancia de InfluxDB autogestionada a la nube?

Utilice la herramienta oficial de InfluxDB influx_inspect para exportar archivos de protocolo de línea desde su servidor de InfluxDB autogestionado. A continuación, utilice command-line interface (Influx CLI) para importar los archivos a TSDB for InfluxDB®.

¿Cómo migro datos entre diferentes instancias de InfluxDB en la nube?

No existe ninguna herramienta de migración integrada entre instancias de InfluxDB. Exporte los datos mediante consultas e impórtelos manualmente. Utilice filtros de tiempo y etiquetas para procesar la migración por lotes y evitar consultas grandes que afecten la estabilidad.

¿Cómo migro datos de InfluxDB a LindormTSDB?

Importe todos los datos desde su instancia de TSDB for InfluxDB® hacia LindormTSDB. TSDB for InfluxDB® historical data migration solutions.