Time Series Database:Perguntas frequentes

Séries e cardinalidade de séries

• Como modelar e quais cuidados tomar?

• Por que a cardinalidade de séries é importante?

Administração

• Quais pontos observar para garantir a estabilidade do sistema?

• Como visualizar o uso de disco de um measurement?

• Como excluir dados de forma eficiente e segura?

• Por que uma política de retenção modificada não entra em vigor?

• Por que ocorrem interrupções frequentes no serviço?

• Por que o uso de memória está alto e preciso fazer upgrade?

• Há suporte para redução de armazenamento?

• A expansão de disco causa reinicialização?

• Quanto tempo leva uma reinicialização?

• Há suporte para o Grafana integrado ao InfluxDB?

• Por que recebo um erro ip block ao acessar?

• Como identificar a versão do TSDB for InfluxDB®?

• Qual a relação entre a duração do grupo de shards e a política de retenção?

• Por que nenhum dado é perdido após alterar uma política de retenção?

• Por que o TSDB for InfluxDB® não consegue analisar a unidade de microssegundo?

Consulta de dados

• Como solucionar problemas de consultas lentas?

• O que determina o intervalo de tempo retornado por uma consulta GROUP BY time()?

• Por que uma consulta não retorna dados ou retorna apenas dados parciais?

• Por que uma consulta GROUP BY time() não retorna timestamps posteriores a now()?

• Posso executar operações matemáticas em timestamps?

• É possível identificar a precisão de gravação pelos timestamps retornados?

• Quando usar aspas simples e duplas ao consultar dados?

• Por que há perda de dados após criar uma nova política de retenção DEFAULT?

• Por que uma consulta com cláusula de tempo WHERE OR retorna resultado vazio?

• Por que fill(previous) retorna resultado vazio?

• Por que uma consulta INTO perde dados?

• Como consultar dados quando uma chave de tag e uma chave de campo têm o mesmo nome?

• Como consultar dados entre measurements?

• A ordem dos timestamps é importante?

• Como selecionar dados com SELECT que possuem tag mas nenhum valor de tag?

Gravação de dados

• Por que a instabilidade de gravação ocorre periodicamente?

• Cuidados com gravações via line protocol

• Por que os dados não ficam visíveis após a gravação?

• Por que a gravação não é retomada após liberar espaço em disco cheio?

• Como gravar um valor de campo inteiro?

• Como o TSDB for InfluxDB® lida com pontos de dados duplicados?

• Qual quebra de linha a HTTP API exige?

• Quais palavras e caracteres evitar ao gravar dados no TSDB for InfluxDB®?

• Quando usar aspas simples e duplas ao gravar dados?

• A precisão do timestamp é importante?

Interface de linha de comando (Influx CLI)

• Por que não consigo me conectar ao TSDB for InfluxDB® pela interface de linha de comando?

• Como configurar a Influx CLI do TSDB for InfluxDB® para retornar timestamps legíveis?

• Como um usuário não administrador pode usar USE para especificar um banco de dados?

• Como usar a Influx CLI do TSDB for InfluxDB® para gravar dados em uma política de retenção não padrão?

Tipos de dados

• Por que não consigo consultar um valor de campo Boolean?

• Como o TSDB for InfluxDB® lida com discrepâncias de tipo de campo entre shards?

• Quais são os inteiros mínimo e máximo armazenáveis no TSDB for InfluxDB®?

• Quais são os timestamps mínimo e máximo armazenáveis no TSDB for InfluxDB®?

• Como identificar o tipo de dados armazenado em um campo?

• Posso alterar o tipo de dados de um campo?

Funções InfluxQL

• Como executar operações matemáticas em funções?

• Por que uma consulta retorna epoch 0 como timestamp?

• Quais funções InfluxQL suportam aninhamento?

Migração de dados do InfluxDB

• Como migrar um InfluxDB autogerenciado para a cloud?

• Como migrar dados entre diferentes instâncias InfluxDB na cloud?

• Como migrar dados do InfluxDB para o LindormTSDB?

Por que a cardinalidade de séries é importante?

O TSDB for InfluxDB® mantém um índice na memória para cada série. Conforme o número de séries aumenta, o uso de RAM também cresce. Uma cardinalidade excessivamente alta pode desencadear uma exceção de falta de memória (OOM) e encerrar o processo. Referência do InfluxQL

Como modelar e quais cuidados tomar?

Mantenha o número de séries temporais abaixo de um milhão. Para cenários com volume massivo de séries temporais, utilize o LindormTSDB. Revise o guia de schema e layout de dados do InfluxDB. O InfluxDB indexa tags para acelerar consultas, mas tags em excesso causam inflação de séries, tornando leituras e gravações mais lentas. Principais considerações:

• Evite tags com valores de alta cardinalidade, como IDs, hashes e strings aleatórias.

• Não armazene dados em nomes de measurements ou de tags. Armazene os dados em tags e campos.

• Não armazene múltiplas informações em uma única tag. Divida-as em várias tags.

• Se você usa frequentemente um campo em uma cláusula GROUP BY, modele-o como tag.

Como identificar a versão do TSDB for InfluxDB®?

Use um dos seguintes 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 a interface de linha de comando do TSDB for InfluxDB®

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

Qual a relação entre a duração do grupo de shards e a política de retenção?

O TSDB for InfluxDB® armazena dados em grupos de shards. Um grupo de shards cobre um intervalo de tempo específico. O TSDB for InfluxDB® determina esse intervalo verificando a DURATION da política de retenção (RP) relevante. A tabela a seguir lista a relação padrão entre a DURATION de uma RP e o intervalo de tempo de um grupo de shards:

Use SHOW RETENTION POLICIES para visualizar a duração do grupo de shards de uma política de retenção.

Por que nenhum dado é perdido após alterar uma política de retenção?

Os dados podem não ser perdidos imediatamente após a alteração de uma política de retenção pelos seguintes motivos:

• Primeiro motivo possível (cenário mais provável): Por padrão, o TSDB for InfluxDB® verifica e aplica RPs a cada 30 minutos. Talvez seja necessário aguardar a próxima verificação de RP antes que o TSDB for InfluxDB® exclua dados fora da nova DURATION da RP.

• Segundo motivo possível: Alterar a DURATION e a SHARD DURATION de uma RP pode levar a uma retenção inesperada de dados. O TSDB for InfluxDB® armazena dados em grupos de shards. Cada grupo de shards cobre uma RP e um intervalo de tempo específicos. Quando o TSDB for InfluxDB® aplica uma RP, ele exclui todo o grupo de shards, não pontos de dados individuais. O TSDB for InfluxDB® não pode dividir grupos de shards. Se a nova DURATION da RP for menor que a antiga SHARD DURATION, e o TSDB for InfluxDB® estiver gravando dados em um grupo de shards antigo com uma DURATION maior, o sistema será forçado a armazenar todos os dados nesse grupo de shards. Isso ocorre mesmo que alguns dados no grupo de shards estejam fora da nova DURATION. Assim que todos os dados no grupo de shards estiverem fora da nova DURATION, o TSDB for InfluxDB® exclui todo o grupo de shards. O sistema então começa a gravar dados em grupos de shards com a nova SHARD DURATION, mais curta. Isso evita futura retenção inesperada de dados.

Por que o TSDB for InfluxDB® não consegue analisar a unidade de microssegundo?

A sintaxe para especificar a unidade de tempo em microssegundos difere para gravação, consulta e definição de precisão na interface de linha de comando do TSDB for InfluxDB® (Influx CLI). A tabela a seguir mostra a sintaxe suportada para cada categoria:

Como solucionar problemas de consultas lentas?

Consultas lentas geralmente resultam da varredura de muitas séries temporais ou de muitos dados brutos. Adicione filtros de tag e intervalo de tempo a todas as consultas. Use o comando EXPLAIN ANALYZE para diagnosticar o desempenho: execution_time reflete a leitura e computação de dados, enquanto planning_time reflete a varredura de séries.

O que determina o intervalo de tempo retornado por uma consulta GROUP BY time()?

O intervalo de tempo retornado por uma consulta GROUP BY time() corresponde aos buckets de tempo predefinidos do TSDB for InfluxDB® ou a um intervalo de deslocamento especificado pelo usuário. Veja os exemplos a seguir:

• Buckets de tempo predefinidos

  A consulta a seguir calcula a média de sunflowers entre 18:15 e 19:45 e agrupa as médias por uma 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)

  Os resultados a seguir mostram como o TSDB for InfluxDB® mantém seus buckets de tempo predefinidos.

  Neste exemplo, 18h é um bucket de tempo predefinido, assim como 19h. Como a cláusula WHERE especifica o intervalo de tempo da consulta, os dados anteriores às 18:15 não são incluídos no cálculo da média para o bucket de tempo das 18h. No entanto, os dados usados para calcular a média do bucket das 18h devem ocorrer dentro dessa hora. O mesmo se aplica ao bucket das 19h. Os dados usados para calcular a média do bucket das 19h devem ocorrer dentro dessa hora. As linhas tracejadas mostram os pontos de dados usados para calcular cada média.

  Observe que, embora o primeiro timestamp no resultado seja 2016-08-29T18:00:00Z, o resultado da consulta para esse bucket de tempo não inclui dados anteriores a 2016-08-29T18:15:00Z, que é o horário inicial especificado na cláusula WHERE.

  Dados brutos:

  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 deslocamento

  A consulta a seguir calcula a média de sunflowers entre 18:15 e 19:45 e agrupa as médias por uma hora. A consulta também desloca os buckets de tempo predefinidos do TSDB for InfluxDB® em 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

  Neste exemplo, o intervalo de deslocamento especificado pelo usuário avança os buckets de tempo predefinidos do TSDB for InfluxDB® em 15 minutos. Agora, a média para o bucket de tempo das 18h inclui dados entre 18:15 e 19:15. A média para o bucket de tempo das 19h inclui dados entre 19:15 e 20:15. As linhas tracejadas mostram os pontos de dados usados para calcular cada média.

  Note que o primeiro timestamp no resultado agora é 2016-08-29T18:15:00Z, não 2016-08-29T18:00:00Z.

  Dados brutos e 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 que uma consulta não retorna dados ou retorna apenas dados parciais?

Motivos comuns:

• Política de retenção

  A explicação mais comum refere-se às políticas de retenção (RPs). O TSDB for InfluxDB® consulta automaticamente dados da RP DEFAULT do banco de dados. Se seus dados não estiverem armazenados na RP padrão, o TSDB for InfluxDB® não retornará resultados, a menos que você especifique explicitamente a RP a ser usada.

• Chave de tag na cláusula SELECT

  A cláusula SELECT deve incluir pelo menos uma chave de campo para que a consulta retorne dados. Se a cláusula SELECT contiver apenas uma ou mais chaves de tag, a consulta retornará um resultado vazio. Para mais informações, consulte Exploração de dados.

• Intervalo de tempo da consulta

  Outra explicação possível relaciona-se ao intervalo de tempo da consulta. Por padrão, a maioria das consultas SELECT cobre o intervalo de tempo entre 1677-09-21 00:12:43.145224194 UTC e 2262-04-11T23:47:16.854775806Z UTC. Uma consulta SELECT que inclui uma cláusula GROUP BY time(), no entanto, cobre um intervalo de tempo entre 1677-09-21 00:12:43.145224194 e now(). Se seus dados ocorrerem após now(), a consulta GROUP BY time() não cobrirá dados posteriores a now(). Se uma instrução de consulta incluir uma cláusula GROUP BY time() e tiver dados posteriores a now(), você precisará fornecer um limite superior para o intervalo de tempo.

• Nome do identificador

  A última explicação comum refere-se ao schema, onde um campo e uma tag têm o mesmo nome. Se uma chave de campo e uma chave de tag forem idênticas, o campo terá prioridade em todas as consultas. Na consulta, use a sintaxe ::tag para especificar a chave de tag.

Por que uma consulta GROUP BY time() não retorna timestamps posteriores a now()?

O intervalo de tempo padrão para a maioria das instruções SELECT fica entre 1677-09-21 00:12:43.145224194 UTC e 2262-04-11T23:47:16.854775806Z UTC. Para instruções SELECT com uma cláusula GROUP BY time(), o intervalo de tempo padrão fica entre 1677-09-21 00:12:43.145224194 e now().

Para consultar dados com timestamps posteriores a now(), uma instrução SELECT com uma cláusula GROUP BY time() deve fornecer um limite superior de tempo na cláusula WHERE.

No exemplo a seguir, a primeira consulta cobre dados com timestamps entre 2015-09-18T21:30:00Z e now(). A segunda consulta cobre dados com timestamps entre 2015-09-18T21:30:00Z e 180 semanas apó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)

Note que a cláusula WHERE deve fornecer um limite superior de tempo para substituir o limite superior padrão now(). A consulta a seguir simplesmente redefine o limite inferior para now(), tornando o intervalo de tempo da consulta entre now() e now():

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

Detalhes da sintaxe de tempo: Exploração de dados.

Posso executar operações matemáticas em timestamps?

O TSDB for InfluxDB® não suporta operações matemáticas em timestamps. Execute cálculos de tempo no lado do cliente.

O TSDB for InfluxDB® oferece suporte limitado para o uso de funções InfluxQL em timestamps. A função ELAPSED() retorna a diferença entre timestamps em um único campo.

É possível identificar a precisão de gravação pelos timestamps retornados?

O TSDB for InfluxDB® armazena todos os timestamps em nanossegundos, independentemente da precisão de gravação. O banco de dados remove silenciosamente os zeros à direita dos timestamps retornados, dificultando a identificação da precisão original de gravação.

No exemplo a seguir, as tags precision_supplied e timestamp_supplied mostram a precisão de tempo e o timestamp fornecidos pelo usuário ao gravar os dados. Como o TSDB for InfluxDB® remove silenciosamente os zeros à direita do timestamp retornado, é difícil identificar a precisão de gravação a partir dele.

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

Quando usar aspas simples e duplas ao consultar dados?

Use aspas simples para envolver valores de string, como valores de tag. Não use aspas simples para envolver identificadores. Identificadores incluem nomes de bancos de dados, nomes de políticas de retenção, nomes de usuários, nomes de measurements, chaves de tag e chaves de campo.

Use aspas duplas para envolver identificadores se eles começarem com um dígito, contiverem caracteres diferentes de [A-z,0-9,_] ou forem uma palavra-chave InfluxQL. Se um identificador não se enquadrar em uma dessas categorias, não é necessário envolvê-lo em aspas duplas. No entanto, recomendamos que você o faça.

Exemplos:

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 inválida: SELECT 'bikes_available' FROM 'bikes' WHERE 'station_id'="9"

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

Use aspas simples para envolver strings de data e hora. Se você usar aspas duplas para envolver strings de data e hora, o TSDB for InfluxDB® retornará um erro (ERR: invalid operation: time and *influxql.VarRef are not compatible).

Exemplo:

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

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

Detalhes da sintaxe de tempo: Exploração de dados.

Por que há perda de dados após criar uma nova política de retenção DEFAULT?

Ao criar uma nova política de retenção (RP) padrão em um banco de dados, os dados da antiga RP padrão permanecem na RP antiga. Consultas que não especificam uma RP consultarão automaticamente dados da nova RP padrão, e todos os dados antigos podem parecer perdidos. Para consultar os dados antigos, qualifique totalmente os dados na consulta. Veja o exemplo a seguir:

Todos os dados no measurement fleeting pertencem à RP padrão, chamada one_hour:

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

Agora criamos uma nova RP padrão (two_hour) e executamos a mesma consulta:

> SELECT count(flounders) FROM fleeting
>

Para consultar os dados antigos, especifique a antiga RP padrão qualificando totalmente fleeting:

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

Por que uma consulta com cláusula de tempo WHERE OR retorna resultado vazio?

O TSDB for InfluxDB® não suporta OR na cláusula WHERE para especificar múltiplos intervalos de tempo. Se a cláusula WHERE de uma consulta usar OR para especificar múltiplos intervalos de tempo, o TSDB for InfluxDB® não retornará nenhum resultado.

Exemplo:

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

Por que fill(previous) retorna resultado vazio?

Se o valor anterior estiver fora do intervalo de tempo da consulta, fill(previous) não preencherá um valor para esse bucket de tempo.

No exemplo a seguir, o TSDB for InfluxDB® não preenche um valor para o bucket de tempo 2016-07-12T16:50:20Z-2016-07-12T16:50:30Z com o valor do bucket de tempo 2016-07-12T16:50:00Z-2016-07-12T16:50:10Z porque o intervalo de tempo da consulta não inclui o bucket de tempo anterior.

Dados de amostra:

> 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 que uma consulta INTO perde dados?

Por padrão, uma consulta INTO converte tags dos dados de origem em campos nos dados recém-gravados. Isso pode fazer com que o TSDB for InfluxDB® sobrescreva pontos de dados anteriormente diferenciados por uma tag. Inclua GROUP BY * em todas as consultas INTO para preservar as tags nos dados recém-gravados.

> 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 sem GROUP BY *

  Uma consulta INTO sem uma cláusula GROUP BY * converte a tag color em um campo nos dados recém-gravados. Nos dados de origem, os pontos de dados nugget e rumple são diferenciados apenas pela tag color. Assim que color se torna um campo, o TSDB for InfluxDB® considera os pontos de dados nugget e rumple como duplicatas. Ele sobrescreve o ponto de dados nugget com o ponto de dados 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 com GROUP BY *

  Uma consulta INTO com uma cláusula GROUP BY * preserva a tag color nos dados recém-gravados. Nesse caso, os pontos de dados nugget e rumple permanecem distintos, e o TSDB for InfluxDB® não sobrescreve nenhum dado.

  > 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

Como consultar dados quando uma chave de tag e uma chave de campo têm o mesmo nome?

Use a sintaxe :: para especificar se uma chave é uma chave de campo ou uma chave de tag. Dados de amostra:

> 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 a chave é um 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 a chave é uma 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

Como consultar dados entre measurements?

Operações matemáticas ou agrupamentos entre measurements não são suportados. Todos os dados devem residir no mesmo measurement. O TSDB for InfluxDB® não é um banco de dados relacional — evite mapear dados entre measurements.

A ordem dos timestamps é importante?

Não. Resultados de testes mostram que há pouquíssima diferença no tempo que o TSDB for InfluxDB® leva para concluir as seguintes consultas:

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

Como selecionar dados com SELECT que possuem tag mas nenhum valor de tag?

Use '' para especificar um valor de tag vazio. Por exemplo:

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

Como gravar um valor de campo inteiro?

Ao gravar um inteiro, anexe um i ao final do valor do campo. Se você não anexar um i, o TSDB for InfluxDB® tratará o valor do campo como um número de ponto flutuante.

Gravar um inteiro: value=100i. Gravar um número de ponto flutuante: value=100.

Como o TSDB for InfluxDB® lida com pontos de dados duplicados?

Um ponto de dados é identificado exclusivamente pelo nome do measurement, conjunto de tags e timestamp. Se você enviar um ponto de dados que tenha o mesmo measurement, conjunto de tags e timestamp de um ponto de dados existente, mas com um conjunto de campos diferente, o conjunto de campos do ponto de dados se tornará a união dos conjuntos de campos antigo e novo. Se houver conflitos, o novo conjunto de campos terá precedência. Este é o comportamento esperado.

Por exemplo:

Ponto de dados antigo: cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

Novo ponto de dados: cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000000

Após enviar o novo ponto de dados, o TSDB for InfluxDB® sobrescreve o valor de val_1 com o novo valor de campo, e o valor de val_2 é mantido:

> 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 armazenar ambos os pontos de dados, você pode:

• Introduzir uma nova tag para garantir unicidade.

  Ponto de dados antigo: cpu_load,hostname=server02,az=us_west,uniq=1 val_1=24.5,val_2=7 1234567890000000

  Novo ponto de dados: cpu_load,hostname=server02,az=us_west,uniq=2 val_1=5.24 1234567890000000

  Após gravar o novo ponto de dados no 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 o timestamp em um nanossegundo.

  Ponto de dados antigo: cpu_load,hostname=server02,az=us_west val_1=24.5,val_2=7 1234567890000000

  Novo ponto de dados: cpu_load,hostname=server02,az=us_west val_1=5.24 1234567890000001

  Após gravar o novo ponto de dados no 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

Qual quebra de linha a HTTP API exige?

O line protocol do TSDB for InfluxDB® depende do caractere de quebra de linha (\n, que é ASCII 0x0A) para indicar o fim de uma linha e o início de outra. Um arquivo ou dado que use um caractere de quebra de linha diferente de \n causará um erro bad timestamp ou unable to parse.

O Windows usa \r\n (retorno de carro + quebra de linha), que é incompatível.

Quais palavras e caracteres evitar ao gravar dados no TSDB for InfluxDB®?

• Palavras-chave InfluxQL

  Se você usar uma palavra-chave InfluxQL como identificador, deverá envolver esse identificador em aspas duplas em todas as consultas. O uso incorreto causará erro. Identificadores são nomes de consultas contínuas, nomes de bancos de dados, chaves de campo, nomes de measurements, nomes de políticas de retenção, chaves de tag e nomes de usuários.

• Time

  A palavra-chave time é um caso especial. time pode ser nome de consulta contínua, nome de banco de dados, nome de measurement, nome de política de retenção e nome de usuário. Nesses casos, não é necessário envolver time em aspas duplas na consulta. time não pode ser chave de campo ou chave de tag. O TSDB for InfluxDB® rejeita gravações de dados que usam time como chave de campo ou chave de tag e retorna um erro. Veja os exemplos a seguir:

  • Gravar e consultar dados com time como measurement.

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

    No TSDB for InfluxDB®, time é um nome de measurement válido.

  • Gravar e tentar consultar dados com time como chave de campo.

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

    No TSDB for InfluxDB®, time não é uma chave de campo válida. O sistema não consegue gravar o ponto de dados e retorna um erro 400.

  • Gravar e tentar consultar dados com time como chave de tag.

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

    No TSDB for InfluxDB®, time não é uma chave de tag válida. O sistema não consegue gravar o ponto de dados e retorna um erro 400.

• Caracteres

  Para manter expressões regulares e citações simples, evite usar os seguintes caracteres em identificadores: \ (barra invertida), ^ (circunflexo), $ (cifrão), ' (aspas simples), " (aspas duplas), = (sinal de igual) e , (vírgula).

Quando usar aspas simples e duplas ao gravar dados?

• Evite envolver identificadores em aspas ao gravar com line protocol — isso complica as consultas. Identificadores são nomes de consultas contínuas, nomes de bancos de dados, chaves de campo, nomes de measurements, nomes de políticas de retenção, nomes de assinaturas, chaves de tag e nomes de usuários.

  • Gravar um measurement com aspas duplas: INSERT "bikes" bikes_available=3. Consulta aplicável: SELECT * FROM "\"bikes\""

  • Gravar um measurement com aspas simples: INSERT 'bikes' bikes_available=3. Consulta aplicável: SELECT * FROM "\'bikes\'"

  • Gravar um measurement sem aspas: INSERT bikes bikes_available=3. Consulta aplicável: SELECT * FROM "bikes"

• Use aspas duplas para envolver valores de campo do tipo string.

  Gravar: INSERT bikes happiness="level 2". Consulta aplicável: SELECT * FROM "bikes" WHERE "happiness"='level 2'

• Escape caracteres especiais com barra invertida em vez de envolvê-los em aspas.

  Gravar: INSERT wacky va\"ue=4. Consulta aplicável: SELECT "va\"ue" FROM "wacky"

A precisão do timestamp é importante?

Para obter desempenho ideal de gravação, use a precisão de tempo mais grosseira possível.

Nos dois exemplos a seguir, a primeira solicitação usa a precisão padrão (nanossegundos), enquanto a segunda define a precisão para 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'

A contrapartida: precisões mais grosseiras aumentam a chance de timestamps duplicados, o que pode causar sobrescrita de dados.

Por que não consigo me conectar ao TSDB for InfluxDB® pela interface de linha de comando?

Confirme as seguintes condições uma a uma:

• Você deve ter permissões de execução. Execute o comando chmod +x ./influx para adicionar permissões.

• A opção -ssl deve ser especificada na instrução de conexão.

• Para a opção -host, especifique apenas a string de conexão, como ts-bp17j28j2y7pm****.influxdata.rds.aliyuncs.com. Não adicione o protocolo e o número da porta.

Como configurar a Influx CLI do TSDB for InfluxDB® para retornar timestamps legíveis?

Ao se conectar pela primeira vez à Influx CLI, especifique a precisão rfc3339:

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

Alternativamente, especifique a precisão após conectar-se à Influx CLI:

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

Detalhes: Interface de linha de comando (Influx CLI).

Como um usuário não administrador pode usar USE para especificar um banco de dados?

Se um usuário não administrador tiver permissões READ e WRITE, ou apenas permissão READ para um banco de dados, ele poderá executar a instrução USE <database_name>. Se um usuário não administrador tentar usar USE para especificar um banco de dados para o qual não possui permissão READ e WRITE, ou READ, o sistema retornará um erro:

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

Como usar a Influx CLI do TSDB for InfluxDB® para gravar dados em uma política de retenção não padrão?

Use a sintaxe INSERT INTO [<database>.]<retention_policy> <line_protocol> para gravar dados em uma política de retenção não padrão. (Este método de especificar o banco de dados e a política de retenção é permitido apenas na Influx CLI. Se você gravar dados via HTTP, deve usar os parâmetros db e rp para especificar o banco de dados e a política de retenção, respectivamente. Especificar a política de retenção é opcional.) Veja o exemplo a seguir.

> 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

Qualifique totalmente o measurement para consultar dados em uma política de retenção não padrão. Use a seguinte sintaxe para qualificar totalmente um measurement:

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

Por que não consigo consultar um valor de campo Boolean?

A sintaxe para gravar e consultar valores Boolean é diferente.

Por exemplo, SELECT * FROM "hamlet" WHERE "bool"=True retorna todos os pontos de dados onde bool é igual a TRUE. No entanto, SELECT * FROM "hamlet" WHERE "bool"=T não retorna nenhum resultado.

Como o TSDB for InfluxDB® lida com discrepâncias de tipo de campo entre shards?

Um valor de campo pode ser um número de ponto flutuante, um inteiro, uma string ou um valor Boolean. Dentro de um shard, o tipo de dados de um valor de campo deve ser consistente. No entanto, entre shards diferentes, o tipo de dados de um valor de campo pode variar.

• Instrução SELECT

  Uma instrução SELECT retorna todos os valores de campo do mesmo tipo de dados por padrão. Se o tipo de dados de um valor de campo não for o mesmo em shards diferentes, o TSDB for InfluxDB® primeiro executa uma conversão de tipo, se aplicável. Em seguida, retorna todos os valores na seguinte ordem de tipos de dados: número de ponto flutuante, inteiro, string, Boolean. Se o tipo de um valor de campo diferir em seus dados, use a sintaxe <field_key>::<type> para consultar os diferentes tipos de dados. Veja o exemplo a seguir:

  O measurement just_my_type tem um campo chamado my_field. my_field tem quatro valores de campo em quatro shards diferentes, e o tipo de dados de cada valor de campo é diferente (número de ponto flutuante, inteiro, string e Boolean, respectivamente).

  SELECT retorna apenas os valores de campo de ponto flutuante e inteiros. Nos resultados, o TSDB for InfluxDB® força a conversão do inteiro para um número de ponto flutuante.

  > 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> [...] retorna todos os tipos de dados. O TSDB for InfluxDB® gera dados de cada tipo em uma coluna separada e usa um nome de coluna incremental. Sempre que possível, o TSDB for InfluxDB® converte um valor de campo para outro tipo de dados. Ele converte o inteiro 7 para um número de ponto flutuante na primeira coluna e o número de ponto flutuante 9.879034 para um inteiro na segunda coluna. O TSDB for InfluxDB® não pode converter um número de ponto flutuante ou um inteiro para uma string ou um valor Boolean.

  > 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 retorna cada tipo de dados em cada shard correspondente à chave de campo. Veja o exemplo a seguir:

  O measurement just_my_type tem um campo chamado my_field. my_field tem quatro valores de campo em quatro shards diferentes, e o tipo de dados de cada valor de campo é diferente (número de ponto flutuante, inteiro, string e Boolean, respectivamente).

  SHOW FIELD KEYS retorna todos os quatro tipos de dados:

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

Quais são os inteiros mínimo e máximo armazenáveis no TSDB for InfluxDB®?

O TSDB for InfluxDB® armazena todos os inteiros como tipos de dados int64 com sinal. Os valores válidos mínimo e máximo para int64 são -9023372036854775808 e 9023372036854775807, respectivamente. Referência: Go builtins.

Usar valores próximos ao inteiro mínimo ou máximo, mas ainda dentro dos limites, pode levar a resultados inesperados. Algumas funções e operadores convertem o tipo de dados int64 para float64 durante o cálculo, o que pode causar problemas de overflow.

Quais são os timestamps mínimo e máximo armazenáveis no TSDB for InfluxDB®?

O timestamp mínimo é -9223372036854775806 ou 1677-09-21T00:12:43.145224194Z, e o timestamp máximo é 9223372036854775806 ou 2262-04-11T23:47:16.854775806Z. Timestamps fora desse intervalo retornam um erro de análise.

Como identificar o tipo de dados armazenado em um campo?

A consulta SHOW FIELD KEYS também retorna o tipo de dados do campo.

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

Posso alterar o tipo de dados de um campo?

O TSDB for InfluxDB® oferece suporte muito limitado para alterar o tipo de dados de um campo. A sintaxe <field_key>::<type> suporta a conversão de um valor de campo de inteiro para ponto flutuante ou de ponto flutuante para inteiro. Detalhes da conversão estão em Exploração de dados. Você não pode converter um número de ponto flutuante ou um inteiro para uma string ou um valor Boolean, ou vice-versa.

Métodos para alterar o tipo de dados de um campo:

• Gravar os dados em um campo diferente

  A solução mais simples é gravar os dados com o novo tipo de dados em um campo diferente na mesma série.

• Usar o sistema de shards

  Dentro de um shard, o tipo de dados de um valor de campo não pode variar. No entanto, entre shards diferentes, o tipo de dados de um valor de campo pode ser diferente.

  Para alterar o tipo de dados de um campo, use a consulta SHOW SHARDS para identificar o end_time do shard atual. Se o timestamp de um ponto de dados ocorrer após o end_time, o TSDB for InfluxDB® permite que dados de um tipo diferente sejam gravados em um campo existente. Por exemplo, um campo originalmente aceitava inteiros, mas após o end_time, o campo pode aceitar números de ponto flutuante.

  Note que isso não altera o tipo de dados do campo no shard original.

Como executar operações matemáticas em funções?

O TSDB for InfluxDB® não suporta operações matemáticas dentro de funções. Use subconsultas como alternativa:

O InfluxQL não suporta a seguinte sintaxe:

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

Em vez disso, use uma subconsulta para obter o mesmo resultado:

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

Detalhes sobre subconsultas: Exploração de dados.

Por que uma consulta retorna epoch 0 como timestamp?

No TSDB for InfluxDB®, epoch 0 (1970-01-01T00:00:00Z) é frequentemente usado como um timestamp nulo. Se você solicitar uma consulta para a qual nenhum timestamp possa ser retornado, como uma função de agregação sem intervalo de tempo especificado, o TSDB for InfluxDB® retornará epoch 0 como timestamp.

Quais funções InfluxQL suportam aninhamento?

As seguintes funções InfluxQL suportam aninhamento:

• COUNT() com DISTINCT() aninhado

• CUMULATIVE_SUM()

• DERIVATIVE()

• DIFFERENCE()

• ELAPSED()

• MOVING_AVERAGE()

• NON_NEGATIVE_DERIVATIVE()

• HOLT_WINTERS() e HOLT_WINTERS_WITH_FIT()

Para informações sobre como usar subconsultas em vez de funções aninhadas, consulte Exploração de dados.

Como migrar um InfluxDB autogerenciado para a cloud?

Use a ferramenta oficial influx_inspect do InfluxDB para exportar arquivos de line protocol do seu servidor InfluxDB autogerenciado. Em seguida, use a interface de linha de comando (Influx CLI) para importar os arquivos para o TSDB for InfluxDB®.

Como migrar dados entre diferentes instâncias InfluxDB na cloud?

Não existe ferramenta de migração integrada entre instâncias InfluxDB. Exporte dados com consultas e importe manualmente. Use filtros de tempo e tag para lotear a migração e evitar consultas grandes que afetem a estabilidade.

Como migrar dados do InfluxDB para o LindormTSDB?

Importe dados completos da sua instância TSDB for InfluxDB® para o LindormTSDB. Consulte Soluções de migração de dados históricos do TSDB for InfluxDB®.