é um sistema de gerenciamento de banco de dados colunar de código aberto para processamento analítico de consultas online (OLAP), criado por Yandex. É usado por Yandex, CloudFlare, VK.com, Badoo e outros serviços em todo o mundo para armazenar grandes quantidades de dados (inserindo milhares de linhas por segundo ou petabytes de dados armazenados em disco).
Em um SGBD regular, “string”, cujos exemplos são MySQL, Postgres, MS SQL Server, os dados são armazenados na seguinte ordem:
Nesse caso, os valores relacionados a uma linha são armazenados fisicamente nas proximidades. Em DBMSs colunares, os valores de diferentes colunas são armazenados separadamente e os dados de uma coluna são armazenados juntos:
Exemplos de SGBDs colunares são Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
A empresa é uma despachante de correspondência comecei a usar Clickhouse em 2018 para relatórios e fiquei muito impressionado com sua simplicidade, escalabilidade, suporte SQL e velocidade. A velocidade deste SGBD beirava a magia.
Simplicidade
Clickhouse é instalado no Ubuntu com um único comando. Se você conhece SQL, pode começar imediatamente a usar o Clickhouse para atender às suas necessidades. No entanto, isso não significa que você pode “mostrar criar tabela” no MySQL e copiar e colar o SQL no Clickhouse.
Comparado ao MySQL, existem diferenças importantes de tipo de dados nas definições de esquema de tabela, portanto, você ainda precisará de algum tempo para alterar as definições de esquema de tabela e aprender os mecanismos de tabela para se sentir confortável.
Clickhouse funciona muito bem sem nenhum software adicional, mas se quiser usar a replicação, você precisará instalar o ZooKeeper. A análise de desempenho de consulta mostra excelentes resultados - as tabelas do sistema contêm todas as informações e todos os dados podem ser recuperados usando SQL antigo e enfadonho.
Desempenho
- comparações de Clickhouse com Vertica e MySQL na configuração do servidor: dois soquetes Intel® Xeon® CPU E5-2650 v2 @ 2.60GHz; 128 GiB de RAM; md RAID-5 em 8 HDD SATA de 6 TB, ext4.
- comparação do Clickhouse com o armazenamento em nuvem Amazon RedShift.
- Trechos do blog :
O banco de dados ClickHouse tem um design muito simples - todos os nós do cluster têm a mesma funcionalidade e usam apenas o ZooKeeper para coordenação. Construímos um pequeno cluster de vários nós e realizamos testes, durante os quais descobrimos que o sistema tem um desempenho bastante impressionante, o que corresponde às vantagens declaradas em benchmarks analíticos de SGBD. Decidimos dar uma olhada mais de perto no conceito por trás do ClickHouse. O primeiro obstáculo à pesquisa foi a falta de ferramentas e a pequena comunidade ClickHouse, por isso nos aprofundamos no design deste SGBD para entender como ele funciona.
ClickHouse não suporta o recebimento de dados diretamente do Kafka, pois é apenas um banco de dados, então escrevemos nosso próprio serviço de adaptador em Go. Ele leu mensagens codificadas pelo Cap'n Proto do Kafka, converteu-as em TSV e inseriu-as no ClickHouse em lotes por meio da interface HTTP. Posteriormente, reescrevemos esse serviço para usar a biblioteca Go em conjunto com a própria interface do ClickHouse para melhorar o desempenho. Ao avaliar o desempenho de recebimento de pacotes, descobrimos uma coisa importante - descobriu-se que para ClickHouse esse desempenho depende fortemente do tamanho do pacote, ou seja, do número de linhas inseridas simultaneamente. Para entender por que isso acontece, estudamos como o ClickHouse armazena dados.
O principal mecanismo, ou melhor, família de mecanismos de tabela, usado pelo ClickHouse para armazenar dados é o MergeTree. Este mecanismo é conceitualmente semelhante ao algoritmo LSM usado no Google BigTable ou Apache Cassandra, mas evita a construção de uma tabela de memória intermediária e grava os dados diretamente no disco. Isto proporciona excelente rendimento de gravação, já que cada pacote inserido é classificado apenas pela chave primária, compactado e gravado no disco para formar um segmento.
A ausência de uma tabela de memória ou de qualquer conceito de “frescura” dos dados também significa que eles só podem ser adicionados; o sistema não suporta alteração ou exclusão. Atualmente, a única maneira de excluir dados é excluí-los por mês, já que os segmentos nunca ultrapassam o limite de um mês. A equipe ClickHouse está trabalhando ativamente para tornar esse recurso personalizável. Por outro lado, torna os segmentos de gravação e mesclagem livres de contenção, de modo que o rendimento do recebimento é escalonado linearmente com o número de inserções simultâneas até que ocorra E/S ou saturação do núcleo.
No entanto, isso também significa que o sistema não é adequado para pacotes pequenos, portanto, os serviços e insersores Kafka são usados para buffer. Em seguida, o ClickHouse em segundo plano continua a realizar constantemente a fusão de segmentos, de modo que muitas pequenas informações serão combinadas e gravadas mais vezes, aumentando assim a intensidade da gravação. No entanto, muitas peças não conectadas causarão um estrangulamento agressivo das inserções enquanto a mesclagem continuar. Descobrimos que o melhor compromisso entre a ingestão em tempo real e o desempenho da ingestão é ingerir um número limitado de inserções por segundo na tabela.
A chave para o desempenho da leitura da tabela é a indexação e a localização dos dados no disco. Não importa quão rápido seja o processamento, quando o mecanismo precisar digitalizar terabytes de dados do disco e usar apenas uma parte deles, isso levará algum tempo. ClickHouse é um armazenamento colunar, portanto cada segmento contém um arquivo para cada coluna (coluna) com valores ordenados para cada linha. Dessa forma, colunas inteiras ausentes na consulta podem ser ignoradas primeiro e, em seguida, várias células podem ser processadas em paralelo com a execução vetorizada. Para evitar uma varredura completa, cada segmento possui um pequeno arquivo de índice.
Dado que todas as colunas são ordenadas pela “chave primária”, o arquivo de índice contém apenas os rótulos (linhas capturadas) de cada enésima linha para poder mantê-los na memória mesmo para tabelas muito grandes. Por exemplo, você pode definir as configurações padrão para “marcar cada 8192 linhas” e, em seguida, indexação “escassa” de uma tabela com 1 trilhão. linhas que cabem facilmente na memória ocuparão apenas 122 caracteres.
Desenvolvimento de sistema
O desenvolvimento e melhoria do Clickhouse podem ser rastreados em e certifique-se de que o processo de “crescimento” esteja acontecendo em um ritmo impressionante.
Popularidade
A popularidade do Clickhouse parece estar crescendo exponencialmente, especialmente na comunidade de língua russa. A conferência High Load 2018 do ano passado (Moscou, 8 a 9 de novembro de 2018) mostrou que monstros como vk.com e Badoo usam Clickhouse, com o qual inserem dados (por exemplo, logs) de dezenas de milhares de servidores simultaneamente. Em um vídeo de 40 minutos . Em breve postaremos a transcrição no Habr para maior comodidade de trabalhar com o material.
Aplicações
Depois de passar algum tempo pesquisando, acho que há áreas onde o ClickHouse poderia ser útil ou substituir completamente outras soluções mais tradicionais e populares, como MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot e Druida. A seguir descrevemos os detalhes do uso do ClickHouse para modernizar ou substituir completamente o SGBD acima.
Estendendo MySQL e PostgreSQL
Recentemente, substituímos parcialmente o MySQL pelo ClickHouse em nossa plataforma de newsletter . O problema era que o MySQL, devido a um design ruim, estava registrando cada email enviado e cada link naquele email com um hash base64, criando uma enorme tabela MySQL (email_stats). Depois de enviar apenas 10 milhões de e-mails para assinantes do serviço, essa tabela ocupou 150 GB de espaço de arquivo e o MySQL começou a ser “estúpido” em consultas simples. Para corrigir o problema de espaço no arquivo, usamos com sucesso a compactação de tabela InnoDB, que o reduziu por um fator de 4. No entanto, ainda não faz sentido armazenar mais de 20-30 milhões de e-mails no MySQL apenas para ler o histórico, já que qualquer consulta simples que por algum motivo precise fazer uma varredura completa resulta em troca e muitos erros. /O load, sobre o qual recebemos regularmente avisos do Zabbix.
Clickhouse usa dois algoritmos de compressão que reduzem o volume de dados em aproximadamente , mas neste caso específico os dados eram particularmente "compressíveis".
Substituindo ELK
Com base na minha própria experiência, a pilha ELK (ElasticSearch, Logstash e Kibana, neste caso específico ElasticSearch) requer muito mais recursos para ser executada do que o necessário para armazenar logs. ElasticSearch é um ótimo mecanismo se você precisar de uma boa pesquisa de log de texto completo (o que eu não acho que você realmente precise), mas estou me perguntando por que ele se tornou o mecanismo de registro padrão de fato. Seu desempenho de ingestão combinado com o Logstash nos causou problemas mesmo sob cargas bastante leves e exigiu que adicionássemos cada vez mais RAM e espaço em disco. Como banco de dados, Clickhouse é melhor que ElasticSearch pelos seguintes motivos:
- Suporte ao dialeto SQL;
- O melhor grau de compactação dos dados armazenados;
- Suporte para pesquisas de expressões regulares Regex em vez de pesquisas de texto completo;
- Agendamento de consultas aprimorado e maior desempenho geral.
Atualmente, o maior problema que surge ao comparar ClickHouse com ELK é a falta de soluções para upload de logs, bem como a falta de documentação e tutoriais sobre o tema. Além disso, cada usuário pode configurar o ELK utilizando o manual Digital Ocean, o que é muito importante para a rápida implementação de tais tecnologias. Existe um mecanismo de banco de dados, mas ainda não existe um Filebeat para ClickHouse. Sim, está lá e um sistema para trabalhar com logs , existe uma ferramenta para inserir dados do arquivo de log no ClickHouse, mas tudo isso leva mais tempo. No entanto, ClickHouse ainda é o líder devido à sua simplicidade, por isso mesmo os iniciantes podem instalá-lo facilmente e começar a usá-lo de forma totalmente funcional em apenas 10 minutos.
Preferindo soluções minimalistas, tentei usar o FluentBit, uma ferramenta para envio de logs com pouquíssima memória, junto com o ClickHouse, evitando o uso do Kafka. No entanto, pequenas incompatibilidades precisam ser resolvidas, como antes que isso possa ser feito sem a camada proxy que converte os dados do FluentBit para ClickHouse.
Como alternativa, o Kibana pode ser usado como backend do ClickHouse . Pelo que entendi, isso pode causar problemas de desempenho ao renderizar um grande número de pontos de dados, especialmente com versões mais antigas do Grafana. Ainda não tentamos isso na Qwintry, mas reclamações sobre isso aparecem de vez em quando no canal de suporte ClickHouse no Telegram.
Substituição do Google Big Query e Amazon RedShift (solução para grandes empresas)
O caso de uso ideal para o BigQuery é carregar 1 TB de dados JSON e executar consultas analíticas neles. Big Query é um produto excelente cuja escalabilidade não pode ser exagerada. Este é um software muito mais complexo que o ClickHouse, que roda em um cluster interno, mas do ponto de vista do cliente tem muito em comum com o ClickHouse. O BigQuery pode ficar caro rapidamente quando você começa a pagar por SELECT, por isso é uma verdadeira solução SaaS com todos os seus prós e contras.
ClickHouse é a melhor escolha quando você está executando muitas consultas computacionalmente caras. Quanto mais consultas SELECT você executa todos os dias, mais faz sentido substituir o Big Query pelo ClickHouse, porque essa substituição pode economizar milhares de dólares quando se trata de muitos terabytes de dados sendo processados. Isso não se aplica aos dados armazenados, que são bastante baratos para processar no Big Query.
Em um artigo do cofundador da Altinity, Alexander Zaitsev fala sobre os benefícios dessa migração de DBMS.
Substituição do TimescaleDB
TimescaleDB é uma extensão do PostgreSQL que otimiza o trabalho com séries temporais em um banco de dados regular (, ).
Embora ClickHouse não seja um concorrente sério no nicho de séries temporais, mas sim de estrutura colunar e execução de consultas vetoriais, é muito mais rápido que o TimescaleDB na maioria dos casos de processamento de consultas analíticas. Ao mesmo tempo, o desempenho de recebimento de dados em lote do ClickHouse é aproximadamente 3 vezes maior e também utiliza 20 vezes menos espaço em disco, o que é muito importante para processar grandes volumes de dados históricos: .
Ao contrário do ClickHouse, a única maneira de economizar espaço em disco no TimescaleDB é usar ZFS ou sistemas de arquivos semelhantes.
As próximas atualizações do ClickHouse provavelmente introduzirão a compactação delta, o que o tornará ainda mais adequado para processar e armazenar dados de séries temporais. TimescaleDB pode ser uma escolha melhor do que ClickHouse simples nos seguintes casos:
- pequenas instalações com pouca RAM (<3 GB);
- um grande número de pequenos INSERTs que você não deseja armazenar em buffer em fragmentos grandes;
- melhor consistência, uniformidade e requisitos ACID;
- Suporte PostGIS;
- juntando-se às tabelas PostgreSQL existentes, uma vez que o Timescale DB é essencialmente PostgreSQL.
Concorrência com sistemas Hadoop e MapReduce
Hadoop e outros produtos MapReduce podem realizar muitos cálculos complexos, mas tendem a funcionar com enormes latências. ClickHouse corrige esse problema processando terabytes de dados e produzindo resultados quase instantaneamente. Assim, ClickHouse é muito mais eficaz na realização de pesquisas analíticas rápidas e interativas, o que deve ser do interesse dos cientistas de dados.
Competição com Pinot e Druida
Os concorrentes mais próximos da ClickHouse são os produtos de código aberto colunares e linearmente escaláveis Pinot e Druid. Um excelente trabalho comparando esses sistemas está publicado no artigo 1 fevereiro 2018
Este artigo precisa ser atualizado - diz que ClickHouse não suporta operações UPDATE e DELETE, o que não é totalmente verdade para as versões mais recentes.
Não temos muita experiência com esses bancos de dados, mas realmente não gosto da complexidade da infraestrutura necessária para executar o Druid e o Pinot - é um monte de peças móveis cercadas por Java por todos os lados.
Druid e Pinot são projetos de incubadora Apache, cujo progresso é abordado em detalhes pelo Apache nas páginas do projeto GitHub. Pinot apareceu na incubadora em outubro de 2018, e Druida nasceu 8 meses antes - em fevereiro.
A falta de informação sobre como o AFS funciona levanta algumas questões, e talvez estúpidas, para mim. Eu me pergunto se os autores do Pinot perceberam que a Fundação Apache é mais favorável ao Druida, e se essa atitude em relação ao concorrente causou um sentimento de inveja? Será que o desenvolvimento do Druida desacelerará e o desenvolvimento do Pinot acelerará se os defensores do primeiro de repente se interessarem pelo último?
Desvantagens do ClickHouse
Imaturidade: Obviamente, esta ainda não é uma tecnologia enfadonha, mas em qualquer caso, nada parecido é observado em outros SGBDs colunares.
Inserções pequenas não funcionam bem em alta velocidade: as inserções devem ser divididas em pedaços maiores porque o desempenho de inserções pequenas diminui proporcionalmente ao número de colunas em cada linha. É assim que o ClickHouse armazena dados em disco – cada coluna representa 1 arquivo ou mais, então para inserir 1 linha contendo 100 colunas, você precisa abrir e gravar pelo menos 100 arquivos. É por isso que o buffer de inserções requer um intermediário (a menos que o próprio cliente forneça buffer) - geralmente Kafka ou algum tipo de sistema de gerenciamento de filas. Você também pode usar o mecanismo de tabela Buffer para copiar posteriormente grandes blocos de dados em tabelas MergeTree.
As junções de tabelas são limitadas pela RAM do servidor, mas pelo menos estão lá! Por exemplo, Druid e Pinot não possuem tais conexões, pois são difíceis de implementar diretamente em sistemas distribuídos que não suportam a movimentação de grandes blocos de dados entre nós.
Descobertas
Planejamos usar amplamente o ClickHouse no Qwintry nos próximos anos, pois este SGBD oferece um excelente equilíbrio entre desempenho, baixa sobrecarga, escalabilidade e simplicidade. Tenho certeza de que ele começará a se espalhar rapidamente assim que a comunidade ClickHouse apresentar mais maneiras de usá-lo em instalações de pequeno e médio porte.
Alguns anúncios 🙂
Obrigado por ficar com a gente. Gostou dos nossos artigos? Quer ver mais conteúdos interessantes? Apoie-nos fazendo um pedido ou recomendando a amigos, , um análogo exclusivo de servidores básicos, que foi inventado por nós para você: (disponível com RAID1 e RAID10, até 24 núcleos e até 40 GB DDR4).
Dell R730xd 2x mais barato no data center Equinix Tier IV em Amsterdã? Só aqui na Holanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US$ 99! Ler sobre
Fonte: habr.com