🥇Mudanzando a ClickHouse: 3 anos despois

Hai tres anos Viktor Tarnavsky e Alexey Milovidov de Yandex no escenario HighLoad++ contou, o bo que é ClickHouse e como non se ralentiza. E na seguinte etapa houbo Alexander Zaitsev с informe sobre mudarse a clickhouse doutro DBMS analítico e coa conclusión de que clickhouse, por suposto, bo, pero non moi cómodo. Cando en 2016 a empresa LifeStreet, onde Alexander traballaba entón, estaba a converter un sistema analítico de varios petabytes clickhouse, era unha fascinante "estrada de ladrillos amarelos" chea de perigos descoñecidos - clickhouse daquela parecía un campo minado.

Tres anos despois clickhouse foi moito mellor - durante este tempo Alexander fundou a empresa Altinity, que non só axuda ás persoas a moverse clickhouse decenas de proxectos, pero tamén mellora o produto en si xunto cos compañeiros de Yandex. Agora clickhouse aínda non é un paseo despreocupado, pero xa non é un campo minado.

Alexander leva traballando con sistemas distribuídos desde 2003, desenvolvendo grandes proxectos MySQL, Oracle и Vertica. No último HighLoad++ 2019 Alexander, un dos pioneiros do uso clickhouse, dixo o que é agora este DBMS. Coñeceremos as principais características clickhouse: en que se diferencia doutros sistemas e en que casos é máis eficaz utilizalo. Usando exemplos, analizaremos as prácticas recentes e probadas por proxectos para sistemas de construción baseados clickhouse.

Retrospectiva: o que pasou hai 3 anos

Hai tres anos traspasamos a empresa LifeStreet en clickhouse doutra base de datos analítica e a migración de análise da rede publicitaria tivo este aspecto:

Xuño 2016. En Fonte aberta apareceu clickhouse e comezou o noso proxecto;
Agosto Proba de concepto: gran rede de publicidade, infraestrutura e 200-300 terabytes de datos;
Outubro. Primeiros datos de produción;
decembro. A carga completa do produto é de 10-50 mil millóns de eventos por día.
Xuño 2017. Migración exitosa de usuarios a clickhouse, 2,5 petabytes de datos nun clúster de 60 servidores.

Durante o proceso migratorio, houbo unha comprensión crecente diso clickhouse é un bo sistema co que é agradable traballar, pero este é un proxecto interno de Yandex. Polo tanto, hai matices: Yandex tratará primeiro cos seus propios clientes internos e só despois coa comunidade e as necesidades dos usuarios externos, e ClickHouse non alcanzou o nivel empresarial en moitas áreas funcionais. É por iso que fundamos Altinity en marzo de 2017 para facer clickhouse aínda máis rápido e cómodo non só para Yandex, senón tamén para outros usuarios. E agora nós:

Adestramos e axudamos a construír solucións baseadas en clickhouse para que os clientes non se metan en problemas, e para que finalmente funcione a solución;
Ofrecemos asistencia 24/7 clickhouse- instalacións;
Desenvolvemos os nosos propios proxectos de ecosistemas;
Comprometémonos activamente con nós mesmos clickhouse, respondendo ás solicitudes dos usuarios que queiran ver determinadas funcións.

E, por suposto, axudamos a mudarse clickhouse с MySQL, Vertica, oráculo, Ameixeira verde, Redshift e outros sistemas. Estivemos implicados nunha variedade de movementos, e todos foron exitosos.

Por que moverse a clickhouse

Non ralentiza! Esta é a razón principal. clickhouse - Base de datos moi rápida para diferentes escenarios:

Citas aleatorias de persoas que traballan con persoas durante moito tempo clickhouse.

Escalabilidade. Nalgunha outra base de datos pode acadar un bo rendemento nunha peza de hardware, pero clickhouse pode escalar non só verticalmente, senón tamén horizontalmente, simplemente engadindo servidores. Non todo funciona tan ben como nos gustaría, pero funciona. Podes ampliar o sistema a medida que o teu negocio crece. É importante que non esteamos limitados pola solución agora e sempre hai potencial de desenvolvemento.

Portabilidade. Non hai apego a unha cousa. Por exemplo, con Amazon RedShift É difícil moverse a algún lugar. A clickhouse podes instalalo no teu portátil, servidor, implementalo na nube, ir a Kubernetes — Non existen restricións no funcionamento da infraestrutura. Isto é conveniente para todos, e esta é unha gran vantaxe da que moitas outras bases de datos similares non poden presumir.

Flexibilidade. clickhouse non se limita a unha cousa, por exemplo, Yandex.Metrica, senón que se desenvolve e úsase en cada vez máis proxectos e industrias diferentes. Pódese ampliar engadindo novas capacidades para resolver novos problemas. Por exemplo, crese que almacenar rexistros nunha base de datos é unha mala educación, polo que se lles ocorreu Elasticsearch. Pero grazas á flexibilidade clickhouse, tamén pode almacenar rexistros nel, e moitas veces isto é aínda mellor que en Elasticsearch - dentro clickhouse isto require 10 veces menos ferro.

De balde Open Source. Non tes que pagar por nada. Non é necesario negociar o permiso para instalar o sistema no seu portátil ou servidor. Sen taxas ocultas. Ao mesmo tempo, ningunha outra tecnoloxía de base de datos de código aberto pode competir en velocidade clickhouse. MySQL, MariaDB, Greenplum - todos son moito máis lentos.

Comunidade, condución e diversión. Ter clickhouse excelente comunidade: encontros, chats e Alexey Milovidov, que nos carga a todos coa súa enerxía e optimismo.

Movéndose a ClickHouse

Para ir clickhouse por algún motivo, só necesitas tres cousas:

Comprender as limitacións clickhouse e para que non é axeitado.
Aproveitar tecnoloxía e os seus maiores puntos fortes.
Experimento. Incluso entendendo como funciona clickhouse, non sempre é posible prever cando será máis rápido, cando será máis lento, cando será mellor e cando será peor. Entón probalo.

Problema de movemento

Só hai un "pero": se te desprazas clickhouse doutra cousa, entón normalmente algo sae mal. Estamos afeitos a algunhas prácticas e cousas que funcionan na nosa base de datos favorita. Por exemplo, con calquera persoa que traballe SQAs bases de datos L consideran obrigatorias o seguinte conxunto de funcións:

transaccións;
restricións;
consistencia;
índices;
ACTUALIZAR/BORRAR;
NULL;
milisegundos;
moldes de tipo automático;
unións múltiples;
particións arbitrarias;
ferramentas de xestión de clusters.

A contratación é obrigatoria, pero hai tres anos en clickhouse Ningunha destas funcións estaba dispoñible! Agora queda menos da metade do que non se implementou: transaccións, restricións, coherencia, milisegundos e tipo casting.

E o principal é que en clickhouse algunhas prácticas e enfoques estándar non funcionan ou funcionan de forma diferente ao que estamos afeitos. Todo o que aparece en clickhouse, corresponde a "Camiño ClickHouse", é dicir. as funcións difiren doutras bases de datos. Por exemplo:

Non se seleccionan índices, pero omítense.
ACTUALIZAR/BORRAR non sincrónico, senón asíncrono.
Hai varias unións, pero non hai un planificador de consultas. Como se realizan entón, xeralmente non está moi claro para as persoas do mundo das bases de datos.

Scripts de ClickHouse

En 1960, un matemático estadounidense de orixe húngara Wigner EP escribiu un artigo "A eficacia irrazonable das matemáticas nas ciencias naturais” (“A incomprensible eficacia das matemáticas nas ciencias naturais”) que, por algunha razón, o mundo que nos rodea está ben descrito polas leis matemáticas. As matemáticas son unha ciencia abstracta e as leis físicas expresadas en forma matemática non son triviais e Wigner EP salientou que isto é moi estraño.

Desde o meu punto de vista, clickhouse - a mesma estrañeza. Para reformular a Wigner, podemos dicir isto: a inconcibible eficacia é sorprendente clickhouse nunha gran variedade de aplicacións analíticas!

Por exemplo, tomemos Almacén de datos en tempo real, no que se cargan datos case continuamente. Queremos recibir as súas solicitudes cunha segunda demora. Por favor, úsao clickhouse, porque este é o escenario para o que foi deseñado. clickhouse así é exactamente como se usa non só na web, senón tamén en mercadotecnia e análise financeira, AdTech, así como en Detección de frauden. EN Data Warehouse en tempo real utilízase un esquema estruturado complexo como "estrela" ou "fopo de neve", con moitas táboas Rexístrese se (ás veces múltiples), e os datos adoitan almacenarse e modificarse nalgúns sistemas.

Tomemos outro escenario - Serie Temporal: seguimento de dispositivos, redes, estatísticas de uso, Internet das cousas. Aquí atopamos eventos bastante sinxelos ordenados no tempo. clickhouse non foi desenvolvido orixinalmente para iso, pero demostrou funcionar ben, polo que as grandes empresas utilizan clickhouse como repositorio de información de seguimento. Para explorar se é adecuado clickhouse para as series temporais, fixemos un punto de referencia baseado no enfoque e os resultados InfluxDB и TimecaleDB - especializada series temporais bases de datos. ResultouQue clickhouse, aínda sen optimización para tales tarefas, gaña nun campo estranxeiro:

В series temporais Normalmente úsase unha táboa estreita: varias columnas pequenas. Moitos datos poden proceder da monitorización, millóns de rexistros por segundo, e normalmente veñen en pequenas ráfagas (en tempo real streaming). Polo tanto, é necesario un script de inserción diferente e as propias consultas teñen as súas propias especificidades.

rexistro Management. Recoller rexistros nunha base de datos adoita ser malo, pero clickhouse isto pódese facer con algúns comentarios como se describe anteriormente. Moitas empresas usan clickhouse precisamente para este fin. Neste caso, usamos unha táboa ancha plana onde almacenamos os rexistros completos (por exemplo, no formulario JSON), ou cortado en anacos. Os datos adoitan cargarse en lotes grandes (ficheiros) e buscamos por algún campo.

Para cada unha destas funcións adoitan utilizarse bases de datos especializadas. clickhouse un pode facelo todo e tan ben que os supera. Vexamos agora máis de cerca series temporais escenario e como "cociñar" correctamente clickhouse para este escenario.

Serie Temporal

Actualmente este é o escenario principal para o cal clickhouse considerada a solución estándar. Series temporais é un conxunto de eventos ordenados no tempo, que representan cambios nalgún proceso ao longo do tempo. Por exemplo, esta podería ser a frecuencia cardíaca por día ou o número de procesos no sistema. Todo o que dá garrapatas ao tempo con algunhas dimensións é series temporais:

A maioría deste tipo de eventos proveñen do seguimento. Isto pode ser non só supervisar a web, senón tamén dispositivos reais: coches, sistemas industriais, Internet das cousas, fábricas ou taxis non tripulados, no maleteiro dos que xa está poñendo Yandex clickhouse-servidor.

Por exemplo, hai empresas que recollen datos dos barcos. Cada poucos segundos, os sensores do barco portacontedores envían centos de medicións diferentes. Os enxeñeiros estúdanos, constrúen modelos e tratan de comprender a eficiencia con que se usa o buque, porque un buque portacontedores non debería estar inactivo nin un segundo. Calquera tempo de inactividade é unha perda de diñeiro, polo que é importante prever a ruta para que as paradas sexan mínimas.

Hoxe en día hai un crecemento das bases de datos especializadas que miden series temporais. No sitio Motores DB As diferentes bases de datos están clasificadas dalgún xeito e podes visualizalas por tipo:

O tipo de máis rápido crecemento é series temporaiss. As bases de datos gráficas tamén están crecendo, pero series temporaiss foron crecendo máis rápido nos últimos anos. Os representantes típicos desta familia de bases de datos son InfluxDB, Prometeu, KDB, TimecaleDB (construído sobre PostgreSQL), solucións de Amazonas. clickhouse tamén se pode usar aquí e úsase. Permíteme darche algúns exemplos públicos.

Unha das pioneiras é a empresa CloudFlare (CDN-provedor). Vixían o seu CDN través clickhouse (DNS- solicitudes, HTTP-consultas) cunha carga enorme - 6 millóns de eventos por segundo. Todo pasa Kafka, vai a clickhouse, que ofrece a oportunidade de ver paneis de control de eventos no sistema en tempo real.

Comcast - un dos líderes en telecomunicacións en USA: Internet, televisión dixital, telefonía. Crearon un sistema de control similar CDN no marco Open Source o proxecto Control de tráfico Apache para traballar cos teus enormes datos. clickhouse usado como backend para a análise.

percona incorporado clickhouse dentro do teu PMMpara almacenar o seguimento de varios MySQL.

Requisitos específicos

As bases de datos de series temporais teñen os seus propios requisitos específicos.

Inserción rápida de moitos axentes. Temos que inserir datos de moitos fluxos moi rapidamente. clickhouse Faino ben porque todas as súas insercións non bloquean. Calquera inserir é un ficheiro novo no disco e as pequenas insercións pódense almacenar nun buffer dun xeito ou doutro. EN clickhouse É mellor inserir datos en lotes grandes en lugar de unha liña á vez.
Esquema flexible. En series temporais normalmente non coñecemos completamente a estrutura dos datos. É posible construír un sistema de monitorización para unha aplicación específica, pero entón é difícil usalo para outra aplicación. Isto require un esquema máis flexible. clickhouse, permíteche facelo, aínda que é unha base moi tecleada.
Almacenamento eficiente e esquecemento de datos. Normalmente en series temporais unha gran cantidade de datos, polo que deben almacenarse da forma máis eficiente posible. Por exemplo, ás InfluxDB unha boa compresión é a súa característica principal. Pero ademais de almacenar, tamén debes poder "esquecer" os datos antigos e facer algún tipo submostraxe - reconto automático de áridos.
Consultas rápidas sobre datos agregados. Ás veces é interesante mirar os últimos 5 minutos cunha precisión de milisegundos, pero nos datos mensuais é posible que non se necesite unha granularidade de minutos ou segundos; as estatísticas xerais son suficientes. Este tipo de apoio é necesario, se non, unha solicitude de 3 meses tardará moito en completarse incluso en clickhouse.
Solicitudes como "último punto, a partir de». Estes son típicos para series temporais consultas: mira a última medición ou estado do sistema nun momento no tempo t. Non son consultas moi agradables para unha base de datos, pero tamén hai que poder realizalas.
Serie temporal de “pegado”.. Series temporais é unha serie temporal. Se hai dúas series temporais, moitas veces deben estar conectadas e correlacionadas. Non é conveniente facelo en todas as bases de datos, especialmente con series temporais non aliñadas: aquí están algúns puntos de tempo, hai outros. Podes considerar a media, pero de súpeto aínda haberá un buraco alí, polo que non está claro.

Vexamos como se cumpren estes requisitos clickhouse.

O esquema

В clickhouse esquema para series temporais pódese facer de diferentes xeitos, dependendo do grao de regularidade dos datos. É posible construír un sistema con datos regulares cando coñecemos todas as métricas de antemán. Por exemplo, fixen isto CloudFlare con seguimento CDN é un sistema ben optimizado. Podes construír un sistema máis xeral que supervisa toda a infraestrutura e varios servizos. No caso de datos irregulares, descoñecemos de antemán o que estamos vixiando, e este é probablemente o caso máis común.

Datos regulares. Columnas. O esquema é sinxelo: columnas cos tipos necesarios:

CREATE TABLE cpu (
  created_date Date DEFAULT today(),  
  created_at DateTime DEFAULT now(),  
  time String,  
  tags_id UInt32,  /* join to dim_tag */
  usage_user Float64,  
  usage_system Float64,  
  usage_idle Float64,  
  usage_nice Float64,  
  usage_iowait Float64,  
  usage_irq Float64,  
  usage_softirq Float64,  
  usage_steal Float64,  
  usage_guest Float64,  
  usage_guest_nice Float64
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Esta é unha táboa normal que supervisa algún tipo de actividade de carga do sistema (usuario, sistema, inactivo, bo). Simple e cómodo, pero non flexible. Se queremos un esquema máis flexible, podemos usar matrices.

Datos irregulares. Arrays:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  )
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Estrutura Anidado son dúas matrices: métricas.nome и métricas.valor. Aquí pode almacenar datos de seguimento tan arbitrarios como unha matriz de nomes e unha matriz de medidas para cada evento. Para optimizar máis, en lugar dunha estrutura deste tipo, podes facer varias. Por exemplo, un para flotar-valor, outro - para int- quere dicir porque int Quero almacenar de forma máis eficiente.

Pero esa estrutura é máis difícil de acceder. Terás que usar unha construción especial, usando funcións especiais para sacar primeiro os valores do índice e despois da matriz:

SELECT max(metrics.value[indexOf(metrics.name,'usage_user')]) FROM ...

Pero aínda funciona bastante rápido. Outra forma de almacenar datos irregulares é por fila.

Datos irregulares. Cordas. Neste método tradicional, sen matrices, os nomes e os valores almacénanse simultaneamente. Se 5 medicións proceden dun dispositivo á vez, xeraranse 000 filas na base de datos:

CREATE TABLE cpu_rlc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metric_name LowCardinality(String),  
  metric_value Float64
) ENGINE = MergeTree(created_date, (metric_name, tags_id, created_at), 8192);


SELECT 
    maxIf(metric_value, metric_name = 'usage_user'),
    ... 
FROM cpu_r
WHERE metric_name IN ('usage_user', ...)

clickhouse fai fronte a isto: ten extensións especiais clickhouse SQL. Por exemplo máx — unha función especial que calcula o máximo por unha métrica cando se cumpre algunha condición. Podes escribir varias destas expresións nunha solicitude e calcular inmediatamente o valor de varias métricas.

Comparemos tres enfoques:

detalles

Aquí engadín "Tamaño de datos de disco" para algúns conxuntos de datos de proba. No caso das columnas, temos o menor tamaño de datos: máxima compresión, máxima velocidade de consulta, pero pagamos por ter que gravar todo á vez.

No caso das matrices, todo é un pouco peor. Os datos aínda están ben comprimidos e pódese almacenar un patrón irregular. Pero clickhouse - unha base de datos en columnas, e cando comezamos a almacenar todo nunha matriz, convértese nunha fila e pagamos pola flexibilidade con eficiencia. Para calquera operación, terás que ler toda a matriz na memoria e, a continuación, atopar nela o elemento desexado e, se a matriz crece, a velocidade degrádase.

Nunha das empresas que utiliza este enfoque (por exemplo, Über), as matrices córtanse en anacos de 128 elementos. Os datos de varios miles de métricas cun volume de 200 TB de datos/día non se almacenan nunha matriz, senón en 10 ou 30 matrices cunha lóxica de almacenamento especial.

O enfoque máis sinxelo é con cordas. Pero os datos están mal comprimidos, o tamaño da táboa é grande e mesmo cando as consultas se basean en varias métricas, ClickHouse non funciona de forma óptima.

Esquema híbrido

Supoñamos que escollemos un circuíto matricial. Pero se sabemos que a maioría dos nosos paneis mostran só métricas de usuarios e sistemas, tamén podemos materializar estas métricas en columnas desde unha matriz a nivel de táboa deste xeito:

CREATE TABLE cpu_alc (
  created_date Date,  
  created_at DateTime,  
  time String,  
  tags_id UInt32,  
  metrics Nested(
    name LowCardinality(String),  
    value Float64
  ),
  usage_user Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_user')],
  usage_system Float64 
             MATERIALIZED metrics.value[indexOf(metrics.name,'usage_system')]
) ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Ao inserir clickhouse os contará automaticamente. Deste xeito podes combinar negocios co pracer: o esquema é flexible e xeral, pero sacamos as columnas de uso máis frecuente. Teña en conta que isto non requiriu cambiar a inserción e ETLque segue inserindo matrices na táboa. Acabamos de facelo ALTER TABLE, engadiu un par de altofalantes e obtivemos un esquema híbrido e máis rápido que podes comezar a usar de inmediato.

Códecs e compresión

Para series temporais Importa o ben que empaquete os datos porque a cantidade de información pode ser moi grande. EN clickhouse Hai un conxunto de ferramentas para conseguir un efecto de compresión de 1:10, 1:20 e ás veces máis. Isto significa que 1 TB de datos descomprimidos no disco ocupa entre 50 e 100 GB. O tamaño menor é bo, os datos pódense ler e procesar máis rápido.

Para conseguir un alto nivel de compresión, clickhouse admite os seguintes códecs:

Táboa de exemplo:

CREATE TABLE benchmark.cpu_codecs_lz4 (
    created_date Date DEFAULT today(), 
    created_at DateTime DEFAULT now() Codec(DoubleDelta, LZ4), 
    tags_id UInt32, 
    usage_user Float64 Codec(Gorilla, LZ4), 
    usage_system Float64 Codec(Gorilla, LZ4), 
    usage_idle Float64 Codec(Gorilla, LZ4), 
    usage_nice Float64 Codec(Gorilla, LZ4), 
    usage_iowait Float64 Codec(Gorilla, LZ4), 
    usage_irq Float64 Codec(Gorilla, LZ4), 
    usage_softirq Float64 Codec(Gorilla, LZ4), 
    usage_steal Float64 Codec(Gorilla, LZ4), 
    usage_guest Float64 Codec(Gorilla, LZ4), 
    usage_guest_nice Float64 Codec(Gorilla, LZ4), 
    additional_tags String DEFAULT ''
)
ENGINE = MergeTree(created_date, (tags_id, created_at), 8192);

Aquí definimos o codec DobreDelta nun caso, no segundo - Gorila, e definitivamente engadiremos máis LZ4 compresión. Como resultado, o tamaño dos datos no disco redúcese moito:

Isto mostra o espazo que ocupan os mesmos datos, pero usando códecs e compresións diferentes:

nun ficheiro GZIP no disco;
en ClickHouse sen códecs, pero con compresión ZSTD;
en ClickHouse con códecs e compresión LZ4 e ZSTD.

Pódese ver que as táboas con códecs ocupan moito menos espazo.

Tamaño importa

Non menos importante elixe tipo de datos correcto:

En todos os exemplos anteriores usei Flotador 64. Pero se escollemos Flotador 32, entón iso sería aínda mellor. Isto foi ben demostrado polos rapaces de Perkona no artigo ligado anteriormente. É importante utilizar o tipo máis compacto que sexa axeitado para a tarefa: aínda menos para o tamaño do disco que para a velocidade de consulta. clickhouse moi sensible a isto.

Se pode usar int32 en vez de int64, entón espera un aumento case dobre no rendemento. Os datos ocupan menos memoria e toda a "aritmética" funciona moito máis rápido. clickhouse internamente é un sistema moi estritamente tipificado, aproveita ao máximo todas as posibilidades que ofrecen os sistemas modernos.

Agregación e Vistas materializadas

A agregación e as vistas materializadas permítenche crear agregados para diferentes ocasións:

Por exemplo, pode ter datos de orixe non agregados e pode anexar a eles varias vistas materializadas con suma automática a través dun motor especial SummingMergeTree (SMT). SMT é unha estrutura especial de datos agregados que calcula os agregados automaticamente. Os datos en bruto insírense na base de datos, agréganse automaticamente e pódense utilizar inmediatamente os paneis.

TTL - "esquecer" datos antigos

Como "esquecer" os datos que xa non son necesarios? clickhouse sabe como facelo. Ao crear táboas, pode especificar TTL expresións: por exemplo, que almacenamos datos de minutos durante un día, datos diarios durante 30 días e nunca tocamos datos semanais ou mensuais:

CREATE TABLE aggr_by_minute
…
TTL time + interval 1 day

CREATE TABLE aggr_by_day
…
TTL time + interval 30 day

CREATE TABLE aggr_by_week
…
/* no TTL */

Multinivel - dividir os datos en discos

Levando esta idea máis aló, pódense almacenar os datos clickhouse en diferentes lugares. Supoñamos que queremos almacenar os datos quentes da última semana nun local moi rápido SSD, e poñemos máis datos históricos noutro lugar. EN clickhouse agora é posible:

Pode configurar unha política de almacenamento (política de almacenamento) Entón clickhouse transferirá automaticamente os datos ao alcanzar determinadas condicións a outro almacenamento.

Pero iso non é todo. Ao nivel dunha táboa específica, pode definir regras para o momento exacto en que os datos pasan ao almacenamento en frío. Por exemplo, os datos gárdanse nun disco moi rápido durante 7 días e todo o que é máis antigo transfírese a un lento. Isto é bo porque permite manter o sistema ao máximo rendemento, ao tempo que controla os custos e non malgasta o diñeiro en datos fríos:

CREATE TABLE 
... 
TTL date + INTERVAL 7 DAY TO VOLUME 'cold_volume', 
    date + INTERVAL 180 DAY DELETE

Oportunidades únicas clickhouse

En case todo clickhouse Hai tales "destacados", pero están compensados pola exclusividade, algo que non está noutras bases de datos. Por exemplo, aquí tes algunhas das características únicas clickhouse:

Arrays. En clickhouse moi bo soporte para matrices, así como a capacidade de realizar cálculos complexos sobre elas.
Estruturas de datos agregados. Esta é unha das "funcións asasinas" clickhouse. A pesar de que os mozos de Yandex din que non queremos agregar datos, todo está agregado en clickhouse, porque é rápido e cómodo.
Vistas materializadas. Xunto coas estruturas de datos agregados, as vistas materializadas permítenche facer máis cómodo en tempo real agregación.
ClickHouse SQL. Esta é unha extensión lingüística SQL con algunhas funcións adicionais e exclusivas que só están dispoñibles en clickhouse. Antes, era como unha expansión por unha banda, e unha desvantaxe por outra. Agora case todas as desvantaxes en comparación con SQL 92 quitámolo, agora é só unha extensión.
Lambda-expresións. Aínda están nalgunha base de datos?
ML-apoiar. Isto está dispoñible en diferentes bases de datos, algúns son mellores, outros son peores.
código aberto. Podemos ampliar clickhouse xuntos. Agora dentro clickhouse uns 500 colaboradores, e este número está en constante crecemento.

Consultas complicadas

В clickhouse hai moitas formas diferentes de facer o mesmo. Por exemplo, pode devolver o último valor dunha táboa de tres formas diferentes para CPU (tamén hai un cuarto, pero aínda é máis exótico).

O primeiro mostra o cómodo que é facelo clickhouse consultas cando quere comprobar iso tupla contidos na subconsulta. Isto é algo que persoalmente botaba de menos noutras bases de datos. Se quero comparar algo cunha subconsulta, noutras bases de datos só se pode comparar con el un escalar, pero para varias columnas teño que escribir Rexístrese se. En clickhouse podes usar tupla:

SELECT *
  FROM cpu 
 WHERE (tags_id, created_at) IN 
    (SELECT tags_id, max(created_at)
        FROM cpu 
        GROUP BY tags_id)

O segundo método fai o mesmo pero usa unha función agregada argMax:

SELECT 
    argMax(usage_user), created_at),
    argMax(usage_system), created_at),
...
 FROM cpu

В clickhouse Hai varias ducias de funcións agregadas, e se usas combinadores, segundo as leis da combinatoria obterás uns mil delas. ArgMax - unha das funcións que calcula o valor máximo: a solicitude devolve o valor uso_usuario, no que se alcanza o valor máximo creado_en:

SELECT now() as created_at,
       cpu.*
  FROM (SELECT DISTINCT tags_id from cpu) base 
  ASOF LEFT JOIN cpu USING (tags_id, created_at)

ASOF ÚNETE — “pegar” filas con diferentes tempos. Esta é unha característica única para as bases de datos que só está dispoñible en kdb+. Se hai dúas series temporais con tempos diferentes, ASOF ÚNETE permítelle movelos e combinalos nunha única solicitude. Para cada valor dunha serie temporal, atópase o valor máis próximo da outra e devólvense na mesma liña:

Funcións analíticas

No estándar SQL-2003 podes escribir así:

SELECT origin,
       timestamp,
       timestamp -LAG(timestamp, 1) OVER (PARTITION BY origin ORDER BY timestamp) AS duration,
       timestamp -MIN(timestamp) OVER (PARTITION BY origin ORDER BY timestamp) AS startseq_duration,
       ROW_NUMBER() OVER (PARTITION BY origin ORDER BY timestamp) AS sequence,
       COUNT() OVER (PARTITION BY origin ORDER BY timestamp) AS nb
  FROM mytable
ORDER BY origin, timestamp;

В clickhouse Non podes facelo: non admite o estándar SQL-2003 e probablemente nunca o faga. En cambio, en clickhouse É habitual escribir así:

Prometín lambdas: aquí están!

Este é un análogo da consulta analítica no estándar SQL-2003: conta a diferenza entre ambos marca de tempo, duración, número ordinal - todo o que normalmente consideramos funcións analíticas. EN clickhouse Contámolos a través de matrices: primeiro contraemos os datos nunha matriz, despois facemos todo o que queremos na matriz e despois expandímolas de novo. Non é moi cómodo, require un amor pola programación funcional como mínimo, pero é moi flexible.

Características especiais

Ademais, en clickhouse moitas funcións especializadas. Por exemplo, como determinar cantas sesións teñen lugar á vez? Unha tarefa típica de vixilancia é determinar a carga máxima cunha solicitude. EN clickhouse Hai unha función especial para este fin:

En xeral, ClickHouse ten funcións especiais para moitos propósitos:

runningDifference, runningAcumular, veciño;
sumaMap(clave, valor);
timeSeriesGroupSum(uid, timestamp, value);
timeSeriesGroupRateSum(uid, timestamp, value);
skewPop, skewSamp, kurtPop, kurtSamp;
CON RECHEO / CON LAVADAS;
SimpleLinearRegression, estocásticoLinearRegression.

Esta non é unha lista completa de funcións, hai entre 500 e 600 en total. Consello: todas as funcións en clickhouse está na táboa do sistema (non todos están documentados, pero todos son interesantes):

select * from system.functions order by name

clickhouse almacena moita información sobre si mesmo, incluíndo táboas de rexistro, rexistro_de_consultas, rexistro de rastrexo, rexistro de operacións con bloques de datos (rexistro_parte), rexistro de métricas e rexistro do sistema, que normalmente escribe no disco. As métricas de rexistro son series temporais в clickhouse de feito clickhouse: A propia base de datos pode desempeñar un papel series temporais bases de datos, "devorándose" así.

Isto tamén é algo único, xa que facemos un bo traballo series temporais, por que non podemos almacenar todo o que necesitamos dentro de nós? Non necesitamos Prometeu, gardámolo todo para nós. Conectado grafana e vixímonos a nós mesmos. Porén, se clickhouse cae, non veremos por que, polo que normalmente non o fan.

Cúmulo grande ou moitos pequenos clickhouse

Que é mellor: un clúster grande ou moitas ClickHouses pequenas? Aproximación tradicional DWH é un gran clúster no que se asignan circuítos para cada aplicación. Chegamos ao administrador da base de datos: dános un diagrama e déronnos un:

В clickhouse podes facelo doutro xeito. Podes facer que cada aplicación sexa túa clickhouse:

Xa non necesitamos o grande monstruoso DWH e administradores intratables. Podemos darlle a cada aplicación o seu clickhouse, e o desenvolvedor pode facelo el mesmo, xa que clickhouse moi doado de instalar e non require unha administración complexa:

Pero se temos moito clickhouse, e necesitas instalalo a miúdo, entón queres automatizar este proceso. Para iso podemos, por exemplo, utilizar Kubernetes и clickhouse-operador. EN Kubernetes ClickHouse podes poñelo "ao clic": podo facer clic nun botón, executar o manifesto e a base de datos está lista. Podo crear inmediatamente un diagrama, comezar a cargar métricas alí e en 5 minutos teño un panel listo grafana. É tan sinxelo!

O resultado?

Así, clickhouse - Isto:

Rapidamente. Todo o mundo sabe isto.
Simplemente. Un pouco polémico, pero creo que é difícil nos adestramentos, fácil no combate. Se entendes como clickhouse funciona, entón todo é moi sinxelo.
Universalmente. É adecuado para diferentes escenarios: DWH, series temporais, almacenamento de rexistros. Pero non o é OLTP base de datos, así que non tente facer insercións curtas e lecturas alí.
Curiosamente. Probablemente o que traballa clickhouse, viviu moitos momentos interesantes no bo e no mal sentido. Por exemplo, saíu unha nova versión, todo deixou de funcionar. Ou cando loitaches cunha tarefa durante dous días, pero despois de facer unha pregunta no chat de Telegram, a tarefa resolveuse en dous minutos. Ou como na conferencia na reportaxe de Lesha Milovidov, unha captura de pantalla de clickhouse rompeu a emisión HighLoad++. Este tipo de cousas ocorren todo o tempo e dificultan a nosa vida. clickhouse brillante e interesante!

Podes ver a presentación aquí.

A tan esperada reunión de desenvolvedores de sistemas de alta carga en HighLoad++ terá lugar os días 9 e 10 de novembro en Skolkovo. Finalmente, esta será unha conferencia fóra de liña (aínda que con todas as precaucións establecidas), xa que a enerxía de HighLoad++ non se pode empaquetar en liña.

Para a conferencia, atopamos e mostrámosche casos sobre as máximas capacidades da tecnoloxía: HighLoad++ foi, é e será o único lugar onde podes aprender en dous días como funcionan Facebook, Yandex, VKontakte, Google e Amazon.

Celebrando as nosas reunións sen interrupción dende o ano 2007, este ano reunirémonos por 14a vez. Durante este tempo, a conferencia creceu 10 veces; o ano pasado, o evento clave da industria congregou a 3339 participantes, 165 relatores, informes e encontros, e 16 temas estaban funcionando simultáneamente.
O ano pasado houbo 20 autobuses, 5280 litros de té e café, 1650 litros de bebidas de froita e 10200 botellas de auga. E outros 2640 quilogramos de comida, 16 pratos e 000 cuncas. Por certo, co diñeiro recadado do papel reciclado, plantamos 25 mudas de carballo :)

Podes mercar entradas aquí, recibe noticias sobre a conferencia - aquí, e fala en todas as redes sociais: Telegrama, Facebook, VKontakte и chilro.

Fonte: www.habr.com

Traslado a ClickHouse: 3 anos despois