Esta es una funcionalidad experimental que puede cambiar de formas incompatibles con versiones anteriores en futuras versiones.
Habilite el uso del motor de tabla TimeSeries
con el ajuste allow_experimental_time_series_table.
Ejecute el comando
set allow_experimental_time_series_table = 1.Sintaxis
La palabra clave
SAMPLES tiene el alias DATA, que se mantiene por compatibilidad con versiones anteriores.Uso
TimeSeries sin especificar una lista de columnas):
Columnas externas
Ejemplo:
metric_name esté vacío durante la inserción, lo que significa que el nombre de la métrica se especifica en tags con __name__, por ejemplo:
metric_family, type, unit y help:
Especificación de columnas externas
time_series se puede incluir explícitamente en una sentencia CREATE TABLE para sobrescribir su tipo predeterminado Array(Tuple(DateTime64(3), Float64)). ClickHouse extrae de la tupla los tipos de marca temporal y escalares, y los propaga a la tabla interna de muestras:
timestamp y value en la cláusula INNER COLUMNS de sample:
CREATE TABLE, los tipos declarados deben coincidir.
Tablas de destino
TimeSeries no tiene datos propios; todo se almacena en sus tablas de destino.
Esto es similar al funcionamiento de una vista materializada,
con la diferencia de que una vista materializada tiene una sola tabla de destino,
mientras que una tabla TimeSeries tiene tres tablas de destino llamadas samples, etiqueta y metrics.
Las tablas de destino pueden especificarse explícitamente en la consulta CREATE TABLE
o el motor de tabla TimeSeries puede generar automáticamente tablas de destino internas.
Las filas insertadas en una tabla TimeSeries se transforman, se dividen en bloques y se insertan en estas tres tablas de destino.
Las tablas de destino son las siguientes:
Tabla samples
La tabla tags contiene identificadores calculados para cada combinación de un nombre de métrica y etiquetas.
La tabla tags debe tener las siguientes columnas:
Tabla de métricas
Creación
TimeSeries.
La sentencia más sencilla
SHOW CREATE TABLE my_table):
INNER COLUMNS.
Las tablas de destino internas tienen nombres 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
y cada tabla de destino tiene su propio conjunto de columnas:
Crear una tabla AS desde una tabla existente
CREATE TABLE new_table AS existing_table copia de existing_table:
SETTINGSINNER COLUMNSpara cada tipoINNER ENGINEpara cada tipo
existing_table tiene destinos externos.
La lista de columnas externa se vuelve a generar y no se copia.
Ajuste de los tipos de las columnas
INNER COLUMNS. Por ejemplo, para almacenar marcas de tiempo en microsegundos y valores como Float32:
La columna id
id contiene identificadores; cada uno se calcula a partir de una combinación de un nombre de métrica y etiquetas.
El tipo y la expresión DEFAULT utilizados para generar los identificadores se pueden personalizar mediante la cláusula TAGS INNER COLUMNS:
id debe ser uno de estos: UUID, UInt64, UInt128 o FixedString(16). Si no se proporciona ninguna expresión DEFAULT, ClickHouse la elegirá automáticamente en función del tipo de id. Los tipos de id declarados en las tablas internas de samples y etiquetas deben coincidir.
La configuración id_generator permite la misma personalización sin usar la cláusula INNER COLUMNS:
id incluso si el DEFAULT de la columna contiene otra expresión.
Hay dos columnas que contienen mapas de etiquetas: tags y all_tags. En este ejemplo significan lo mismo; sin embargo, pueden ser diferentes
si se usa la configuración tags_to_columns. Esta configuración permite especificar que una etiqueta concreta debe almacenarse en una columna independiente en lugar de almacenarse
en un mapa dentro de la columna tags:
instance y job a la tabla de destino interna etiquetas.
En este caso, la columna tags no contendrá las etiquetas instance y job,
pero la columna all_tags sí las contendrá. La columna all_tags es efímera y su único propósito es servir para la expresión DEFAULT
de la columna id.
Motores de las tablas internas de destino
- la tabla samples usa MergeTree;
- la tabla tags usa AggregatingMergeTree porque los mismos datos suelen insertarse varias veces en esta tabla, por lo que hace falta una forma
de eliminar duplicados, y también porque es necesario realizar agregación para las columnas
min_timeymax_time; - la tabla metrics usa ReplacingMergeTree porque los mismos datos suelen insertarse varias veces en esta tabla, por lo que hace falta una forma de eliminar duplicados.
Tablas de destino externas
TimeSeries utilice una tabla creada manualmente:
id, timestamp, value y las <tag_value_column> enumeradas en tags_to_columns) deben coincidir con los que la tabla TimeSeries generaría internamente en otras circunstancias (consulte tabla Samples, tabla Etiquetas y tabla Metrics para conocer las restricciones de tipo). Las discrepancias de tipo se notifican en el momento de CREATE.
La expresión del generador de id para un destino externo de etiquetas se resuelve en tiempo de INSERT en el siguiente orden: la configuración id_generator (si está establecida), luego el DEFAULT declarado en la columna id de la tabla externa (si existe) y, por último, el generador canónico derivado del tipo de id. Por lo tanto, la configuración sobrescribe cualquier DEFAULT declarado en la tabla externa; consulte La columna id para obtener más detalles.
Modificar los ajustes
CREATE:
id_generatorfilter_by_min_time_and_max_time
id_generator cuando ya hay datos en la tabla de etiquetas puede generar IDs distintos para la misma combinación de métrica+tag: las filas antiguas conservan sus IDs anteriores y las nuevas usan el nuevo generador.
Los demás ajustes no se pueden cambiar con ALTER ... MODIFY SETTING porque quedan incorporados en el esquema de las tablas internas en el momento de CREATE.
Configuración
TimeSeries:
Funciones
TimeSeries como argumento: