🥇Mudança para ClickHouse: 3 anos depois

Há três anos, Viktor Tarnavsky e Alexey Milovidov do Yandex no palco HighLoad ++ contado, quão bom é o ClickHouse e como ele não fica lento. E na próxima etapa houve Alexander Zaitsev с relatório sobre mudar para clickhouse de outro SGBD analítico e com a conclusão de que clickhouse, claro, bom, mas não muito conveniente. Quando em 2016 a empresa LifeStreet, onde Alexander trabalhava, estava convertendo um sistema analítico de vários petabytes para clickhouse, era uma fascinante “estrada de tijolos amarelos” cheia de perigos desconhecidos - clickhouse naquela época parecia um campo minado.

Três anos depois clickhouse ficou muito melhor - nessa época Alexander fundou a empresa Altinity, que não só ajuda as pessoas a se mudarem para clickhouse dezenas de projetos, mas também aprimora o próprio produto junto com colegas da Yandex. Agora clickhouse ainda não é um passeio despreocupado, mas não é mais um campo minado.

Alexander trabalha com sistemas distribuídos desde 2003, desenvolvendo grandes projetos em MySQL, Oráculo и vertical. No último HighLoad ++ 2019 Alexander, um dos pioneiros no uso clickhouse, disse o que é esse SGBD agora. Aprenderemos sobre os principais recursos clickhouse: como difere de outros sistemas e em que casos é mais eficaz utilizá-lo. Usando exemplos, veremos práticas recentes e testadas em projetos para a construção de sistemas baseados em clickhouse.

Retrospectiva: o que aconteceu há 3 anos

Há três anos transferimos a empresa LifeStreet em clickhouse de outro banco de dados analítico, e a migração analítica da rede de anúncios ficou assim:

Junho de 2016. Em Código aberto apareceu clickhouse e nosso projeto começou;
Agosto Prova de conceito: grande rede de publicidade, infraestrutura e 200-300 terabytes de dados;
Outubro. Primeiros dados de produção;
Dezembro. A carga total do produto é de 10 a 50 bilhões de eventos por dia.
Junho de 2017. Migração bem-sucedida de usuários para clickhouse, 2,5 petabytes de dados em um cluster de 60 servidores.

Durante o processo de migração, houve uma compreensão crescente de que clickhouse é um bom sistema e agradável de trabalhar, mas é um projeto interno do Yandex. Portanto, há nuances: o Yandex lidará primeiro com seus próprios clientes internos e só depois com a comunidade e as necessidades dos usuários externos, e o ClickHouse então não atingiu o nível empresarial em muitas áreas funcionais. É por isso que fundamos a Altinity em março de 2017 para fazer clickhouse ainda mais rápido e conveniente não apenas para Yandex, mas também para outros usuários. E agora nós:

Treinamos e ajudamos a construir soluções baseadas em clickhouse para que os clientes não tenham problemas e para que a solução funcione;
Oferecemos suporte 24 horas por dia, 7 dias por semana clickhouse- instalações;
Desenvolvemos nossos próprios projetos ecossistêmicos;
Nós nos comprometemos ativamente clickhouse, respondendo a solicitações de usuários que desejam ver determinados recursos.

E, claro, ajudamos na mudança para clickhouse с MySQL, vertical, Oracle, Ameixa verde, Redshift e outros sistemas. Estivemos envolvidos em uma variedade de movimentos e todos foram bem-sucedidos.

Por que mudar para clickhouse

Não desacelera! Esta é a principal razão. clickhouse - banco de dados muito rápido para diferentes cenários:

Citações aleatórias de pessoas que trabalham com pessoas há muito tempo clickhouse.

Escalabilidade. Em algum outro banco de dados você pode obter um bom desempenho em uma peça de hardware, mas clickhouse você pode escalar não apenas verticalmente, mas também horizontalmente, simplesmente adicionando servidores. Nem tudo funciona tão bem quanto gostaríamos, mas funciona. Você pode expandir o sistema à medida que sua empresa cresce. É importante que não estejamos limitados pela solução agora e que haja sempre potencial para desenvolvimento.

Portabilidade. Não há apego a uma coisa. Por exemplo, com Amazon RedShift É difícil mudar para algum lugar. A clickhouse você pode instalá-lo em seu laptop, servidor, implantá-lo na nuvem, acessar Kubernetes — não existem restrições ao funcionamento da infraestrutura. Isso é conveniente para todos e é uma grande vantagem da qual muitos outros bancos de dados semelhantes não podem se orgulhar.

Flexibilidade. clickhouse não para em uma coisa, por exemplo, Yandex.Metrica, mas se desenvolve e é usado em cada vez mais projetos e indústrias diferentes. Pode ser expandido adicionando novas capacidades para resolver novos problemas. Por exemplo, acredita-se que armazenar logs em um banco de dados é falta de educação, então eles criaram ElasticSearch. Mas graças à flexibilidade clickhouse, você também pode armazenar logs nele, e muitas vezes isso é ainda melhor do que em ElasticSearch - em clickhouse isso requer 10 vezes menos ferro.

Livre Open Source. Você não precisa pagar por nada. Não há necessidade de negociar permissão para instalar o sistema em seu laptop ou servidor. Sem taxas ocultas. Ao mesmo tempo, nenhuma outra tecnologia de banco de dados de código aberto pode competir em velocidade com clickhouse. MySQL, MariaDB, Greenplum - eles são todos muito mais lentos.

Comunidade, motivação e Diversão. Em clickhouse excelente comunidade: encontros, chats e Alexey Milovidov, que carrega a todos nós com sua energia e otimismo.

Mudando para ClickHouse

Ir para clickhouse por algum motivo, você só precisa de três coisas:

Entenda as limitações clickhouse e para que não é adequado.
Aproveitar-se tecnologia e seus maiores pontos fortes.
Experimentar. Mesmo entendendo como funciona clickhouse, nem sempre é possível prever quando será mais rápido, quando será mais lento, quando será melhor e quando será pior. Então experimente.

Problema de mudança

Só existe um “mas”: se você mudar para clickhouse de outra coisa, então geralmente algo dá errado. Estamos acostumados com algumas práticas e coisas que funcionam em nosso banco de dados favorito. Por exemplo, qualquer pessoa que trabalhe com SQOs bancos de dados L consideram obrigatório o seguinte conjunto de funções:

transações;
restrições;
consistência;
índices;
ATUALIZAR/EXCLUIR;
NULOS;
milissegundos;
moldes automáticos;
múltiplas junções;
partições arbitrárias;
ferramentas de gerenciamento de cluster.

O recrutamento é obrigatório, mas há três anos em clickhouse Nenhuma dessas funções estava disponível! Agora resta menos da metade do que não foi implementado: transações, restrições, consistência, milissegundos e conversão de tipo.

E o principal é que em clickhouse algumas práticas e abordagens padrão não funcionam ou funcionam de maneira diferente do que estamos acostumados. Tudo o que aparece em clickhouse, corresponde a "Maneira ClickHouse", ou seja funções diferem de outros bancos de dados. Por exemplo:

Os índices não são selecionados, mas ignorados.
ATUALIZAR/EXCLUIR não síncrono, mas assíncrono.
Existem várias junções, mas não há planejador de consultas. Como eles são executados geralmente não é muito claro para as pessoas do mundo dos bancos de dados.

Scripts ClickHouse

Em 1960, um matemático americano de origem húngara EP Wigner escreveu um artigo "A eficácia irracional da matemática nas ciências naturais” (“A Eficácia Incompreensível da Matemática nas Ciências Naturais”) que o mundo que nos rodeia é, por alguma razão, bem descrito por leis matemáticas. A matemática é uma ciência abstrata, e as leis físicas expressas em forma matemática não são triviais, e EP Wigner enfatizou que isso é muito estranho.

Do meu ponto de vista, clickhouse - a mesma estranheza. Para reformular Wigner, podemos dizer o seguinte: a eficiência inconcebível é surpreendente clickhouse em uma ampla variedade de aplicações analíticas!

Por exemplo, vamos pegar Armazém de dados em tempo real, no qual os dados são carregados quase continuamente. Queremos receber solicitações dele com um segundo atraso. Por favor - use-o clickhouse, porque este é o cenário para o qual foi projetado. clickhouse é exatamente assim que é usado não apenas na web, mas também em marketing e análises financeiras, AdTech, bem como em Detecção de frauden. EM Armazém de dados em tempo real um esquema estruturado complexo como “estrela” ou “floco de neve” é usado, muitas tabelas com Cadastre-se (às vezes múltiplos), e os dados geralmente são armazenados e alterados em alguns sistemas.

Vamos pegar outro cenário - Séries temporais: monitoramento de dispositivos, redes, estatísticas de uso, Internet das coisas. Aqui encontramos eventos bastante simples ordenados no tempo. clickhouse não foi originalmente desenvolvido para isso, mas mostrou funcionar bem, por isso as grandes empresas utilizam clickhouse como repositório de informações de monitoramento. Para explorar se é adequado clickhouse para séries temporais, fizemos um benchmark com base na abordagem e nos resultados InfluxDB и Escala de tempoDB - especializado série temporal bancos de dados. AcabouQue clickhouse, mesmo sem otimização para tais tarefas, vence em campo estrangeiro:

В série temporal Normalmente é usada uma tabela estreita - várias colunas pequenas. Muitos dados podem vir do monitoramento – milhões de registros por segundo – e geralmente vêm em pequenas rajadas (em tempo real transmissão). Portanto, é necessário um script de inserção diferente, e as próprias consultas têm suas especificidades.

Log Management. Coletar logs em um banco de dados geralmente é ruim, mas clickhouse isso pode ser feito com alguns comentários conforme descrito acima. Muitas empresas usam clickhouse exatamente para esse fim. Neste caso, usamos uma tabela plana onde armazenamos todos os logs (por exemplo, no formato JSON) ou cortado em pedaços. Os dados geralmente são carregados em grandes lotes (arquivos) e pesquisamos por algum campo.

Para cada uma dessas funções, normalmente são utilizados bancos de dados especializados. clickhouse pode-se fazer tudo e tão bem que os supera. Vamos agora dar uma olhada mais de perto série temporal cenário e como “cozinhar” corretamente clickhouse para este cenário.

Séries Temporais

Atualmente este é o principal cenário para o qual clickhouse considerada a solução padrão. Série temporal é um conjunto de eventos ordenados no tempo, representando mudanças em algum processo ao longo do tempo. Por exemplo, pode ser a frequência cardíaca por dia ou o número de processos no sistema. Tudo o que dá tique-taque ao tempo com algumas dimensões é série temporal:

A maioria desses tipos de eventos vem do monitoramento. Isto pode ser não apenas monitorar a web, mas também dispositivos reais: carros, sistemas industriais, Internet das coisas, fábricas ou táxis não tripulados, em cujo porta-malas Yandex já está colocando clickhouse-servidor.

Por exemplo, existem empresas que recolhem dados de navios. A cada poucos segundos, os sensores do navio porta-contêineres enviam centenas de medições diferentes. Os engenheiros os estudam, constroem modelos e tentam entender a eficiência do uso da embarcação, pois um navio porta-contêineres não deve ficar parado nem por um segundo. Qualquer paragem é uma perda de dinheiro, por isso é importante prever o percurso para que as paragens sejam mínimas.

Atualmente há um crescimento de bases de dados especializadas que medem série temporal. o sítio Motores de banco de dados Os diferentes bancos de dados são classificados de alguma forma e você pode visualizá-los por tipo:

O tipo de crescimento mais rápido é série temporalS. Os bancos de dados gráficos também estão crescendo, mas série temporals têm crescido mais rapidamente nos últimos anos. Os representantes típicos desta família de bancos de dados são InfluxDB, Prometeu, KDB, Escala de tempoDB (construído em PostgreSQL), soluções de Amazon. clickhouse pode ser usado aqui também e é usado. Deixe-me dar alguns exemplos públicos.

Uma das pioneiras é a empresa CloudFlare (CDN-fornecedor). Eles monitoram seus CDN através clickhouse (DNS-solicitações de, HTTP-consultas) com uma carga enorme - 6 milhões de eventos por segundo. Tudo passa Kafka, vai para clickhouse, que oferece a oportunidade de ver painéis de eventos do sistema em tempo real.

Comcast - um dos líderes em telecomunicações nos EUA: Internet, televisão digital, telefonia. Eles criaram um sistema de controle semelhante CDN dentro de Open Source projeto Controle de tráfego Apache para trabalhar com seus enormes dados. clickhouse usado como back-end para análises.

percona construídas em clickhouse dentro do seu PMMpara armazenar monitoramento de vários MySQL.

Requisitos Específicos

Os bancos de dados de série temporal têm seus próprios requisitos específicos.

Inserção rápida de muitos agentes. Temos que inserir dados de muitos fluxos muito rapidamente. clickhouse Ele faz isso bem porque todas as suas inserções não bloqueiam. Qualquer inserir é um novo arquivo no disco e pequenas inserções podem ser armazenadas em buffer de uma forma ou de outra. EM clickhouse É melhor inserir dados em lotes grandes em vez de uma linha por vez.
Esquema flexível. Em série temporal geralmente não conhecemos completamente a estrutura de dados. É possível construir um sistema de monitoramento para uma aplicação específica, mas é difícil utilizá-lo para outra aplicação. Isto requer um esquema mais flexível. clickhouse, permite fazer isso, mesmo sendo uma base fortemente tipada.
Armazenamento eficiente e esquecimento de dados. Geralmente em série temporal uma enorme quantidade de dados, por isso devem ser armazenados da forma mais eficiente possível. Por exemplo, em InfluxDB boa compressão é sua principal característica. Mas além de armazenar, você também precisa “esquecer” dados antigos e fazer algum tipo de redução de amostragem — contagem automática de agregados.
Consultas rápidas em dados agregados. Às vezes é interessante observar os últimos 5 minutos com uma precisão de milissegundos, mas em dados mensais, a granularidade de minuto ou segundo pode não ser necessária - estatísticas gerais são suficientes. É necessário um apoio deste tipo, caso contrário um pedido de 3 meses demorará muito tempo a ser concluído, mesmo em clickhouse.
Pedidos como "último ponto, a partir de». Estes são típicos para série temporal consultas: observe a última medição ou estado do sistema em um momento no tempo t. Essas consultas não são muito agradáveis para um banco de dados, mas você também precisa saber realizá-las.
“Colando” séries temporais. Série temporal é uma série temporal. Se houver duas séries temporais, elas geralmente precisam ser conectadas e correlacionadas. Não é conveniente fazer isso em todos os bancos de dados, especialmente com séries temporais desalinhadas: aqui estão alguns pontos no tempo, há outros. Você pode considerar a média, mas de repente ainda haverá um buraco ali, então não está claro.

Vamos ver como esses requisitos são atendidos em clickhouse.

Condução

В clickhouse esquema para série temporal pode ser feito de diferentes maneiras, dependendo do grau de regularidade dos dados. É possível construir um sistema com base em dados regulares quando conhecemos todas as métricas com antecedência. Por exemplo, eu fiz isso CloudFlare com monitoramento CDN é um sistema bem otimizado. Você pode construir um sistema mais geral que monitore toda a infraestrutura e diversos serviços. No caso de dados irregulares, não sabemos antecipadamente o que estamos a monitorizar – e este é provavelmente o caso mais comum.

Dados regulares. Colunas. O esquema é simples - colunas com os tipos necessários:

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 é uma tabela regular que monitora algum tipo de atividade de carregamento do sistema (usuário, ., inativo, agradável). Simples e conveniente, mas não flexível. Se quisermos um esquema mais flexível, podemos usar arrays.

Dados irregulares. Matrizes:

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 Aninhada são duas matrizes: métricas.nome и métricas.valor. Aqui você pode armazenar dados de monitoramento arbitrários como uma matriz de nomes e uma matriz de medições para cada evento. Para maior otimização, em vez de uma dessas estruturas, você pode fazer várias. Por exemplo, um para flutuar-valor, outro - para int-significando porque int Quero armazenar com mais eficiência.

Mas tal estrutura é mais difícil de acessar. Você terá que usar uma construção especial, usando funções especiais para extrair os valores primeiro do índice e depois do array:

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

Mas ainda funciona muito rapidamente. Outra forma de armazenar dados irregulares é por linha.

Dados irregulares. Cordas. Neste método tradicional, sem arrays, nomes e valores são armazenados simultaneamente. Se 5 medições vierem de um dispositivo de uma só vez, 000 linhas serão geradas no banco de dados:

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 lida com isso - tem extensões especiais clickhouse SQL. Por exemplo, maxIf — uma função especial que calcula o máximo por uma métrica quando alguma condição é atendida. Você pode escrever várias dessas expressões em uma solicitação e calcular imediatamente o valor de várias métricas.

Vamos comparar três abordagens:

Detalhes

Aqui adicionei "Tamanho dos dados do disco" para alguns conjuntos de dados de teste. No caso das colunas, temos o menor tamanho de dados: compressão máxima, velocidade máxima de consulta, mas pagamos por ter que registrar tudo de uma vez.

No caso dos arrays, tudo é um pouco pior. Os dados ainda estão bem compactados e um padrão irregular pode ser armazenado. Mas clickhouse - um banco de dados colunar, e quando começamos a armazenar tudo em um array, ele se transforma em um array, e pagamos pela flexibilidade com eficiência. Para qualquer operação, você terá que ler todo o array na memória e, em seguida, encontrar o elemento desejado nele - e se o array aumentar, a velocidade diminuirá.

Numa das empresas que utiliza esta abordagem (por exemplo, Uber), as matrizes são cortadas em pedaços de 128 elementos. Dados de vários milhares de métricas com um volume de 200 TB de dados/dia são armazenados não em um array, mas em 10 ou 30 arrays com lógica de armazenamento especial.

A abordagem mais simples é com strings. Mas os dados são mal compactados, o tamanho da tabela é grande e mesmo quando as consultas são baseadas em diversas métricas, o ClickHouse não funciona de maneira ideal.

Esquema híbrido

Vamos supor que escolhemos um circuito array. Mas se soubermos que a maioria dos nossos painéis mostram apenas métricas do usuário e do sistema, podemos materializar adicionalmente essas métricas em colunas de uma matriz no nível da tabela desta forma:

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 irá contá-los automaticamente. Desta forma, você pode combinar negócios com prazer: o esquema é flexível e geral, mas retiramos as colunas mais utilizadas. Observe que isso não exigiu a troca da pastilha e ETLque continua a inserir matrizes na tabela. Acabamos de fazer ALTERAR A TABELA, adicionamos alguns alto-falantes e obtivemos um esquema híbrido e mais rápido que você pode começar a usar imediatamente.

Codecs e compactação

Para série temporal É importante quão bem você empacota os dados porque a quantidade de informações pode ser muito grande. EM clickhouse Existe um conjunto de ferramentas para obter um efeito de compressão de 1:10, 1:20 e às vezes mais. Isso significa que 1 TB de dados descompactados no disco ocupa 50-100 GB. Tamanho menor é bom, os dados podem ser lidos e processados mais rapidamente.

Para atingir um alto nível de compressão, clickhouse suporta os seguintes codecs:

Tabela 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);

Aqui definimos o codec DuploDelta em um caso, no segundo - gorila, e com certeza adicionaremos mais LZ4 compressão. Como resultado, o tamanho dos dados no disco é bastante reduzido:

Isso mostra quanto espaço os mesmos dados ocupam, mas usando codecs e compactações diferentes:

em um arquivo GZIP em disco;
no ClickHouse sem codecs, mas com compactação ZSTD;
no ClickHouse com codecs e compressão LZ4 e ZSTD.

Percebe-se que as tabelas com codecs ocupam muito menos espaço.

O tamanho importa

Não menos importante выбрать tipo de dados correto:

Em todos os exemplos acima usei Flutuar64. Mas se escolhermos Flutuar32, então isso seria ainda melhor. Isso foi bem demonstrado pelo pessoal da Perkona no artigo do link acima. É importante usar o tipo mais compacto e adequado para a tarefa: ainda menos para tamanho de disco do que para velocidade de consulta. clickhouse muito sensível a isso.

Se você pode usar int32 ao invés de int64, então espere um aumento quase duplo no desempenho. Os dados ocupam menos memória e toda a “aritmética” funciona muito mais rápido. clickhouse internamente é um sistema de tipo muito rigoroso, que aproveita ao máximo todas as possibilidades que os sistemas modernos oferecem.

Agregação e Vistas Materializadas

Agregações e visualizações materializadas permitem criar agregações para diferentes ocasiões:

Por exemplo, você pode ter dados de origem não agregados e pode anexar várias visualizações materializadas a eles com soma automática por meio de um mecanismo especial SummingMergeTree (SMT). SMT é uma estrutura especial de agregação de dados que calcula agregados automaticamente. Os dados brutos são inseridos no banco de dados, são agregados automaticamente e os painéis podem ser usados imediatamente nele.

TTL - “esquecer” dados antigos

Como “esquecer” dados que não são mais necessários? clickhouse sabe como fazer isso. Ao criar tabelas, você pode especificar TTL expressões: por exemplo, que armazenamos dados de minutos por um dia, dados diários por 30 dias e nunca tocamos em dados semanais ou mensais:

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 */

Multicamada - dividir dados entre discos

Levando essa ideia adiante, os dados podem ser armazenados em clickhouse em lugares diferentes. Suponha que queiramos armazenar dados importantes da última semana em um local muito rápido. SSD, e colocamos mais dados históricos em outro lugar. EM clickhouse isso agora é possível:

Você pode configurar uma política de armazenamento (política de armazenamento) Então clickhouse transferirá automaticamente os dados ao atingir certas condições para outro armazenamento.

Mas isso não é tudo. No nível de uma tabela específica, você pode definir regras para exatamente quando os dados vão para o armazenamento frio. Por exemplo, os dados são armazenados em um disco muito rápido por 7 dias, e tudo o que é mais antigo é transferido para um disco lento. Isso é bom porque permite manter o sistema com desempenho máximo, ao mesmo tempo que controla custos e não desperdiça dinheiro com dados frios:

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

Características únicas clickhouse

Em quase tudo clickhouse Existem tais “destaques”, mas eles são compensados pela exclusividade – algo que não está em outras bases de dados. Por exemplo, aqui estão alguns dos recursos exclusivos clickhouse:

Matrizes. Em clickhouse suporte muito bom para arrays, bem como a capacidade de realizar cálculos complexos neles.
Agregando Estruturas de Dados. Este é um dos "recursos matadores" clickhouse. Apesar de o pessoal do Yandex dizer que não queremos agregar dados, tudo é agregado em clickhouse, porque é rápido e conveniente.
Visualizações materializadas. Juntamente com a agregação de estruturas de dados, as visualizações materializadas permitem que você faça análises convenientes em tempo real agregação.
SQL do ClickHouse. Esta é uma extensão de linguagem SQL com alguns recursos adicionais e exclusivos que estão disponíveis apenas em clickhouse. Anteriormente, era como uma expansão por um lado e uma desvantagem por outro. Agora, quase todas as desvantagens em comparação com SQL 92 nós o removemos, agora é apenas uma extensão.
Lambda-expressões. Eles ainda estão em algum banco de dados?
ML-apoiar. Isto está disponível em diferentes bancos de dados, alguns são melhores, outros são piores.
Código aberto. Podemos expandir clickhouse junto. Agora em clickhouse cerca de 500 colaboradores, e esse número está em constante crescimento.

Consultas complicadas

В clickhouse existem muitas maneiras diferentes de fazer a mesma coisa. Por exemplo, você pode retornar o último valor de uma tabela de três maneiras diferentes para CPU (há também um quarto, mas é ainda mais exótico).

A primeira mostra como é conveniente fazer em clickhouse consultas quando você quiser verificar isso tupla contido na subconsulta. Isso é algo que eu pessoalmente senti falta em outros bancos de dados. Se eu quiser comparar algo com uma subconsulta, em outros bancos de dados apenas um escalar poderá ser comparado com ela, mas para várias colunas preciso escrever Cadastre-se. Em clickhouse você pode 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 faz a mesma coisa, mas usa uma função agregada argMax:

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

В clickhouse existem várias dezenas de funções agregadas e, se você usar combinadores, de acordo com as leis da combinatória, obterá cerca de mil delas. ArgMax - uma das funções que calcula o valor máximo: a solicitação retorna o valor uso_usuário, em que o valor máximo é alcançado criado em:

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

ASOF JUNTE-SE — “colar” linhas com tempos diferentes. Este é um recurso exclusivo para bancos de dados que está disponível apenas em kdb+. Se houver duas séries temporais com tempos diferentes, ASOF JUNTE-SE permite movê-los e mesclá-los em uma solicitação. Para cada valor em uma série temporal, o valor mais próximo na outra é encontrado e eles são retornados na mesma linha:

Funções Analíticas

No padrão SQL-2003 você pode escrever assim:

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 Você não pode fazer isso - não suporta o padrão SQL-2003 e provavelmente nunca fará isso. Em vez disso, em clickhouse É costume escrever assim:

Eu prometi lambdas - aqui estão elas!

Este é um análogo da consulta analítica no padrão SQL-2003: ele conta a diferença entre os dois carimbo de data/hora, duração, número ordinal - tudo o que normalmente consideramos funções analíticas. EM clickhouse Nós os contamos por meio de arrays: primeiro recolhemos os dados em um array, depois fazemos tudo o que queremos no array e depois os expandimos novamente. Não é muito conveniente, requer no mínimo amor pela programação funcional, mas é muito flexível.

Características especiais

Além disso, em clickhouse muitas funções especializadas. Por exemplo, como determinar quantas sessões estão ocorrendo simultaneamente? Uma tarefa típica de monitoramento é determinar a carga máxima com uma solicitação. EM clickhouse Existe uma função especial para este propósito:

Em geral, ClickHouse possui funções especiais para diversas finalidades:

runningDifference, runningAccumulate, vizinho;
sumMap(chave, valor);
timeSeriesGroupSum(uid, carimbo de data/hora, valor);
timeSeriesGroupRateSum(uid, carimbo de data/hora, valor);
skewPop, skewSamp, kurtPop, kurtSamp;
COM PREENCHIMENTO / COM LAÇOS;
simpleLinearRegression, stochasticLinearRegression.

Esta não é uma lista completa de funções, existem 500-600 no total. Dica: todas as funções em clickhouse está na tabela do sistema (nem todos estão documentados, mas todos são interessantes):

select * from system.functions order by name

clickhouse ele armazena muitas informações sobre si mesmo, incluindo tabelas de log, log_de_consulta, log de rastreamento, log de operações com blocos de dados (log_parte), log de métricas e log do sistema, que geralmente grava no disco. As métricas de registro são série temporal в clickhouse de fato clickhouse: O próprio banco de dados pode desempenhar um papel série temporal bancos de dados, “devorando-se” assim.

Isto também é algo único - já que fazemos um bom trabalho para série temporal, por que não podemos armazenar tudo o que precisamos dentro de nós? Nós não precisamos Prometeu, guardamos tudo para nós mesmos. Conectado grafana e nós nos monitoramos. No entanto, se clickhouse cai, não veremos por que, então eles geralmente não fazem isso.

Cluster grande ou muitos pequenos clickhouse

O que é melhor: um cluster grande ou muitos ClickHouses pequenos? Abordagem tradicional para DWH é um grande cluster no qual os circuitos são alocados para cada aplicação. Procuramos o administrador do banco de dados - nos deu um diagrama, e eles nos deram um:

В clickhouse você pode fazer isso de forma diferente. Você pode personalizar cada aplicativo clickhouse:

Não precisamos mais do grande monstruoso DWH e administradores intratáveis. Podemos dar a cada aplicativo o seu próprio clickhouse, e o desenvolvedor pode fazer isso sozinho, já que clickhouse muito fácil de instalar e não requer administração complexa:

Mas se tivermos muito clickhouse, e você precisa instalá-lo com frequência, então deseja automatizar esse processo. Para isso podemos, por exemplo, usar Kubernetes и clique-operador. EM ClickHouse do Kubernetes você pode colocar “on-click”: posso clicar em um botão, executar o manifesto e o banco de dados está pronto. Posso criar imediatamente um diagrama, começar a enviar métricas lá e em 5 minutos tenho um painel pronto grafana. É tão simples!

O resultado?

Assim, clickhouse - isto é:

Быстро. Todo mundo sabe disso.
Justo. Um pouco polêmico, mas acredito que seja difícil no treinamento, fácil no combate. Se você entende como clickhouse funciona, então tudo é muito simples.
Universalmente. É adequado para diferentes cenários: DWH, série temporal, armazenamento de log. Mas não é OLTP banco de dados, então não tente fazer inserções e leituras curtas lá.
Curiosamente. Provavelmente aquele que trabalha com clickhouse, vivenciou muitos momentos interessantes no bom e no mau sentido. Por exemplo, saiu uma nova versão, tudo parou de funcionar. Ou quando você lutou com uma tarefa por dois dias, mas depois de fazer uma pergunta no chat do Telegram, a tarefa foi resolvida em dois minutos. Ou como na conferência do relatório de Lesha Milovidov, uma captura de tela de clickhouse quebrou a transmissão HighLoad ++. Esse tipo de coisa acontece o tempo todo e dificulta a nossa vida. clickhouse brilhante e interessante!

Você pode assistir à apresentação aqui.

A tão esperada reunião de desenvolvedores de sistemas de alta carga em HighLoad ++ acontecerá nos dias 9 e 10 de novembro em Skolkovo. Por fim, esta será uma conferência offline (embora com todos os cuidados), uma vez que a energia do HighLoad++ não pode ser empacotada online.

Para a conferência, encontramos e mostramos cases sobre as capacidades máximas da tecnologia: HighLoad++ foi, é e será o único lugar onde você pode aprender em dois dias como funcionam o Facebook, Yandex, VKontakte, Google e Amazon.

Tendo realizado nossas reuniões sem interrupção desde 2007, este ano nos reuniremos pela 14ª vez. Durante esse período, a conferência cresceu 10 vezes; no ano passado, o principal evento do setor reuniu 3339 participantes, 165 palestrantes, relatórios e encontros, e 16 trilhas estavam acontecendo simultaneamente.
No ano passado foram 20 autocarros, 5280 litros de chá e café, 1650 litros de sucos de fruta e 10200 garrafas de água. E mais 2640 quilos de alimentos, 16 mil pratos e 000 mil copos. Aliás, com o dinheiro arrecadado com papel reciclado, plantamos 25 mudas de carvalho :)

Você pode comprar ingressos aqui, receba notícias sobre a conferência - aqui, e fale em todas as redes sociais: Telegram, Facebook, Vkontakte и Twitter.

Fonte: habr.com

Mudança para a ClickHouse: 3 anos depois