Introdução ao Comando DELETE

Após explorar os métodos de inserção e atualização de pontos de dados, é fundamental compreender o ciclo de vida completo da informação, incluindo a remoção adequada de registros obsoletos ou incorretos. No InfluxDB, a operação de exclusão é realizada através do comando DELETE, que possui particularidades distintas em comparação com bancos de dados relacionais tradicionais.

1. Sintaxe do DELETE

A estrutura oficial do comando para remoção de séries é definida da seguinte maneira:

DELETE FROM <measurement_name> WHERE [<tag_key>='<tag_value>'] | [<time interval>]

Embora a sintaxe lembre o SQL padrão, existe uma restrição crítica na cláusula WHERE: ela aceita apenas filtros baseados em tags e tempo. Não é possível utilziar campos (fields) como condição para exclusão.

Exemplos Práticos

Caso 1: Exclusão baseada em intervalo de tempo

Considere um measurement chamado server_stats. Abaixo, visualizamos os dados existentes e, em seguida, removemos registros posteriores a um timestamp específico.

> select * from server_stats
name: server_stats
time                cpu_usage host     memory_free region
----                --------- ----     ----------- ------
1680000000000000000 45.2      server_01 2048        us-east
1680000050000000000 48.5      server_01 2000        us-east
1680000100000000000 50.1      server_01 1980        us-east

> delete from server_stats where time >= 1680000100000000000

> select * from server_stats
name: server_stats
time                cpu_usage host     memory_free region
----                --------- ----     ----------- ------
1680000000000000000 45.2      server_01 2048        us-east
1680000050000000000 48.5      server_01 2000        us-east

Note que apenas o registro com timestamp igual ou superior ao especificado foi removido do conjunto de dados.

Caso 2: Exclusão baseada em Tags

Para remover dados associados a uma tag específica, utilizamos o nome da tag na condição. É importante observar que, caso o nome da tag seja uma palavra reservada (como name ou value), ela deve ser envolvida por aspas duplas.

> show tag keys from server_stats
name: server_stats
tagKey
------
host
region

> delete from server_stats where "host"='server_01'

> select * from server_stats
>

Após a execução, todas as séries correspondentes à tag host='server_01' foram eliminadas, resultando em um measurement vazio.

2. Interação com Políticas de Retenção (Retention Poilcies)

Uma dúvida comum surge ao trabalhar com múltiplas políticas de retenção (RP). A sintaxe básica do DELETE não especifica explicitamente a política alvo. Como o sistema comoprta-se nesse cenário?

Abaixo, inserimos dados na política padrão e em uma política personalizada chamada rp_monthly.

> insert server_stats,host=server_01,region=us-east cpu_usage=45.2,memory_free=2048i
> insert into "rp_monthly" server_stats,host=server_01,region=us-east cpu_usage=55.0,memory_free=1024i

> select * from server_stats
name: server_stats
time                cpu_usage host     memory_free region
----                --------- ----     ----------- ------
1680100000000000000 45.2      server_01 2048        us-east

> select * from "rp_monthly".server_stats
name: server_stats
time                cpu_usage host     memory_free region
----                --------- ----     ----------- ------
1680100050000000000 55.0      server_01 1024        us-east

Ao executar uma exclusão baseada em tag sem qualificar a política de retenção:

> delete from server_stats where "host"='server_01'

> select * from server_stats
> 
> select * from "rp_monthly".server_stats
>

Observa-se que a exclusão por tag afetou ambas as políticas. Isso ocorre porque a definição da série (composta pelas tags) é compartilhada ou identificada globalmente para aquele measurement, removendo os pontos em todas as políticas onde essa série existe.

Para validar o comportamento com filtros de tempo, inserimos novos dados em uma política diferente, rp_weekly:

> select * from server_stats
name: server_stats
time                cpu_usage host     memory_free region
----                --------- ----     ----------- ------
1680200000000000000 60.0      server_02 4096        us-west

> insert into "rp_weekly" server_stats,host=server_02,region=us-west cpu_usage=65.0,memory_free=3000i

> select * from "rp_weekly".server_stats
name: server_stats
time                cpu_usage host     memory_free region
----                --------- ----     ----------- ------
1680200050000000000 65.0      server_02 3000        us-west

> delete from server_stats where time=1680200050000000000

> select * from "rp_weekly".server_stats
> 
> select * from server_stats
name: server_stats
time                cpu_usage host     memory_free region
----                --------- ----     ----------- ------
1680200000000000000 60.0      server_02 4096        us-west

Neste cenário, a exclusão baseada no timestamp específico removeu o dado apenas da política rp_weekly, mantendo intacto o registro na política padrão. Isso demonstra que filtros temporais tendem a agir sobre os pontos específicos dentro do escopo da série consultada, enquanto a remoção por tag pode impactar a série inteira através das políticas de retenção associadas.