Este é um recurso experimental que pode mudar de formas incompatíveis com versões anteriores em lançamentos futuros.
Habilite o uso do motor de tabela TimeSeries
com a configuração allow_experimental_time_series_table.
Execute o comando
set allow_experimental_time_series_table = 1.Sintaxe
A palavra-chave
SAMPLES tem um alias DATA, mantido por compatibilidade com versões anteriores.Uso
TimeSeries sem especificar uma lista de colunas):
Colunas externas
Exemplo:
metric_name fique vazio na inserção; isso significa que o nome da métrica é especificado em tags, em __name__, por exemplo:
metric_family, type, unit e help:
Especificando colunas externas
time_series pode ser listada explicitamente em uma instrução CREATE TABLE para substituir seu tipo padrão Array(Tuple(DateTime64(3), Float64)). O ClickHouse extrai, da tupla, os tipos de timestamp e do valor escalar e os propaga para a tabela samples:
INNER COLUMNS de samples, os tipos das colunas de timestamp e valor:
CREATE TABLE, os tipos declarados deverão coincidir.
Tabelas de destino
TimeSeries não armazena dados próprios; tudo é armazenado em suas tabelas de destino.
Isso é semelhante ao funcionamento de uma visão materializada,
com a diferença de que uma visão materializada tem uma tabela de destino,
enquanto uma tabela TimeSeries tem três tabelas de destino chamadas samples, tags e metrics.
As tabelas de destino podem ser especificadas explicitamente na consulta CREATE TABLE
ou o motor de tabela TimeSeries pode gerar automaticamente tabelas de destino internas.
As linhas inseridas em uma tabela TimeSeries são transformadas, divididas em blocos e inseridas nessas três tabelas de destino.
As tabelas de destino são as seguintes:
Tabela samples
As colunas que o motor cria por conta própria recebem codecs de compressão de séries temporais:
timestamp CODEC(DoubleDelta, ZSTD(1)) e value CODEC(ZSTD(3)). Timestamps quase monotônicos mal
são comprimidos por codecs genéricos e podem, caso contrário, dominar o tamanho em disco da tabela samples.
Consulte também Ajustando os tipos das colunas.
A tabela tags contém identificadores calculados para cada combinação de nome de métrica e tags.
A tabela tags deve ter as colunas:
Tabela de métricas
Criação
TimeSeries.
A instrução mais simples
SHOW CREATE TABLE my_table):
INNER COLUMNS.
As tabelas de destino internas têm nomes como .inner_id.samples.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx,
.inner_id.tags.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, .inner_id.metrics.xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
e cada tabela de destino tem seu próprio conjunto de colunas:
Criando uma tabela AS com base em uma tabela existente
CREATE TABLE new_table AS existing_table copia da existing_table:
SETTINGSINNER COLUMNSpara cada tipoINNER ENGINEpara cada tipo
existing_table tiver alvos externos.
A lista externa de colunas é regenerada, e não copiada.
Ajustando os tipos das colunas
INNER COLUMNS. Por exemplo, para armazenar timestamps em microssegundos e valores como Float32, use:
A coluna id
id contém identificadores; cada identificador é calculado com base em uma combinação de nome de métrica e tags.
O tipo e a expressão DEFAULT usados para gerar identificadores podem ser personalizados por meio da cláusula TAGS INNER COLUMNS:
id pode ser de qualquer tipo comparável que não seja Nullable. Os tipos de id declarados nas tabelas internas samples e tags devem corresponder.
Se nenhuma expressão DEFAULT for fornecida para a coluna id e a configuração id_generator não estiver definida, ClickHouse escolherá a expressão DEFAULT automaticamente com base no tipo de id, mas apenas se o tipo de id for um dos seguintes: UUID, UInt64, UInt128, FixedString(16) ou uma tupla de dois desses tipos. Para essa tupla, a expressão escolhida automaticamente calcula um hash do nome de métrica no primeiro componente e um hash de todas as tags no segundo componente.
A configuração id_generator oferece a mesma personalização sem usar a cláusula INNER COLUMNS:
id, mesmo que o DEFAULT da coluna contenha uma expressão diferente.
A coluna tags contém todas as tags de uma série temporal, incluindo a tag __name__ com o nome de uma métrica.
A configuração tags_to_columns permite especificar que uma tag específica também deve ser armazenada em uma coluna separada
além do map dentro da coluna tags:
instance e job à tabela de destino interna de tags.
Os valores das tags instance e job serão armazenados tanto nessas colunas quanto na coluna tags.
Nas tabelas criadas por versões mais antigas do ClickHouse, a coluna
tags contém apenas as tags sem colunas
dedicadas e sem o nome da métrica, e a coluna all_tags é uma coluna efêmera preenchida na inserção
com todas as tags, exceto o nome da métrica.Motores de tabela das tabelas de destino internas
- a tabela samples usa MergeTree;
- a tabela tags usa AggregatingMergeTree porque os mesmos dados costumam ser inseridos várias vezes nessa tabela, então precisamos de uma forma
de remover duplicatas, além de ser necessário fazer agregação para as colunas
min_timeemax_time; - a tabela metrics usa ReplacingMergeTree porque os mesmos dados costumam ser inseridos várias vezes nessa tabela, então precisamos de uma forma de remover duplicatas.
tags) fora de sua chave de ordenação,
o que AggregatingMergeTree rejeita por padrão (consulte allow_dimensions_outside_sorting_key).
Isso é seguro aqui porque essas colunas dependem funcionalmente de id, que faz parte da chave de ordenação, portanto todas as
linhas que uma mesclagem em segundo plano combina compartilham os mesmos valores. Quando a tabela interna de tags é gerada ou seu
motor é especificado inline, como acima, TimeSeries define allow_dimensions_outside_sorting_key = 1 nela automaticamente;
para uma tabela externa de tags com agregação criada manualmente, você deve definir isso por conta própria.
Tabelas de destino externas
TimeSeries use uma tabela criada manualmente:
id, timestamp, value e os <tag_value_column> listados em tags_to_columns) devem corresponder aos que a tabela TimeSeries geraria internamente (consulte Tabela samples, Tabela de Tags e Tabela de métrica para as restrições de tipo). Incompatibilidades de tipo são informadas no momento do CREATE.
A expressão do gerador de ID para um destino externo de tags é resolvida no momento do INSERT, na seguinte ordem: a configuração id_generator (se definida), depois o DEFAULT declarado na coluna id da tabela externa (se houver) e, por fim, o gerador canônico derivado do tipo de id. Portanto, a configuração substitui qualquer DEFAULT declarado na tabela externa — consulte A coluna id para mais detalhes.
Alterando configurações
CREATE:
id_generatorfilter_by_min_time_and_max_time
id_generator quando já existem dados na tabela de tags pode gerar IDs diferentes para a mesma combinação de métrica+tag — as linhas antigas mantêm seus IDs antigos, e as linhas novas usam o novo gerador.
As outras configurações não podem ser alteradas com ALTER ... MODIFY SETTING porque são incorporadas ao esquema das tabelas internas no momento do CREATE.
Configurações
TimeSeries:
Funções
TimeSeries como argumento: