Comparação de armazenamento de dados entre Elasticsearch e Clickhouse

1. Fundo

O Departamento de Tecnologia de Jingxingda adota a arquitetura JDQ+Flink+Elasticsearch no cenário de compra em grupo da comunidade para criar relatórios de dados em tempo real. Com o desenvolvimento do negócio, o Elasticsearch começou a expor algumas desvantagens: não é adequado para consultas de dados em grande escala, e a exportação de paginação de alta frequência leva a paralisações e altos custos de armazenamento.

As instruções de consulta do Elasticsearch têm altos custos de manutenção e a imprecisão dos dados ocorre em cenários de computação de agregação. Clickhouse é um banco de dados colunar, naturalmente adequado para cenários OLAP. Semelhante à sintaxe SQL, reduz os custos de desenvolvimento e aprendizado, usa algoritmos de compactação rápida para economizar custos de armazenamento e usa tecnologia de mecanismo de execução vetorial para reduzir bastante o tempo de cálculo. Portanto, para esta comparação, mude de Elasticsearch para Clickhouse.

2 OLAP

OLAP significa On-Line Analytical Processing, e Clickhouse é um típico sistema de gerenciamento de banco de dados analítico online OLAP (DBMS). O OLAP realiza principalmente análises complexas e operações resumidas nos dados. Por exemplo, nosso sistema de negócios faz estatísticas resumidas sobre todos os pedidos de grupo de transporte do dia todos os dias e calcula a taxa de entrega de cada província. Esta operação pertence ao processamento de dados OLAP. Semelhante ao OLAP, também existe um tipo de processamento de dados OLTP, que significa On-Line Transaction Processing.No cenário OLTP, a quantidade de operações simultâneas do usuário será grande, exigindo que o sistema responda às operações de dados em tempo real e precisam suportar transações. Mysql, Oracle, SQLServer, etc. são todos bancos de dados OLTP.

2.1 Características dos cenários OLTP

Tabelas largas, ou seja, cada tabela contém um grande número de colunas
Para leituras, algumas linhas são buscadas no banco de dados, mas apenas um pequeno subconjunto das colunas.
relativamente poucas consultas (normalmente centenas de consultas por segundo ou menos por servidor)
Os resultados da consulta são significativamente menores do que os dados de origem. Em outras palavras, os dados são filtrados ou agregados para que os resultados caibam na RAM de um único servidor
Principalmente solicitações de leitura
Os dados são atualizados em lotes consideráveis (>1.000 linhas) em vez de uma única linha; ou não são atualizados.
Para consultas simples, cerca de 50 milissegundos de latência são permitidos
Os dados nas colunas são relativamente pequenos: números e strings curtas (por exemplo, 60 bytes por URL)
Requer alta taxa de transferência (bilhões de linhas por segundo por servidor) ao processar uma única consulta
negócio não é necessário
Baixos requisitos para consistência de dados

3 recursos

3.1 Elasticsearch

Pesquisa: Aplicável ao índice invertido, cada campo pode ser indexado e usado para pesquisa, obter resposta de segundo nível quase em tempo real sob dados massivos, mecanismo de pesquisa de código aberto baseado em Lucene, fornecer pesquisa para pesquisa de texto completo, destaque , recomendação de pesquisa, etc. capacidade. Pesquisa Baidu, pesquisa de produtos Taobao, pesquisa de log, etc.
Análise de dados: o Elasticsearch fornece um grande número de APIs de análise de dados e recursos avançados de agregação, suportando análise e processamento de dados com base em dados massivos. Volume estatístico de pedidos, rastreador rastreando dados de um determinado produto de diferentes empresas de comércio eletrônico e análise de dados através do Elasticsearch (preços históricos, poder de compra etc. de cada plataforma)

3.2 Clickhouse

armazenamento colunar
Algoritmo de compactação: use a compactação de dados do algoritmo lz4 e zstd, alta taxa de compactação para reduzir o tamanho dos dados, reduzir o IO do disco e reduzir o uso da CPU.
Índice: Classifique os dados de acordo com a chave primária, o clickhouse pode concluir a pesquisa por dados específicos ou intervalo de dados em uma grande quantidade de dados em dezenas de milissegundos.
Processamento paralelo multi-core: ClickHouse usará todos os recursos disponíveis no servidor para concluir uma consulta com todas as suas forças.
Suporte para SQL: Uma linguagem de consulta declarativa baseada em SQL, em muitos casos idêntica ao padrão ANSI SQL. Suporta group by, order by, from, join, in e subconsultas não correlacionadas, etc.
Mecanismo vetorial: Para usar a CPU com eficiência, os dados não são apenas armazenados em colunas, mas também processados em vetores (uma parte da coluna), que podem usar a CPU com mais eficiência.
Atualização de dados em tempo real: os dados são sempre armazenados de forma incremental no MergeTree de maneira ordenada. Os dados podem ser gravados de forma contínua e eficiente na tabela sem nenhuma operação, como bloqueio. Tráfego de gravação a 50M-200M/s
Adequado para consultas online: resposta rápida e latência extremamente baixa
Funções avançadas de cálculo agregado

4 Nossos cenários de negócios

Para tabelas grandes e largas, leia um grande número de linhas e um pequeno número de colunas para consulta de cálculo de agregação de índice, e o conjunto de resultados é relativamente pequeno. As tabelas de dados são todas tabelas largas processadas pelo Flink, com muitas colunas. Ao consultar ou analisar dados, algumas colunas geralmente são selecionadas como colunas de dimensão e outras poucas colunas são usadas como colunas de índice para executar cálculos de agregação em toda a tabela ou dados dentro de um determinado intervalo. Esse processo verifica um grande número de linhas de dados, mas apenas algumas colunas são usadas.
Um grande número de consulta e exportação de paginação de lista
Os dados no Flink são anexados e gravados em grandes quantidades sem atualização
Às vezes, um cálculo de indicador requer uma varredura completa da tabela para cálculos de agregação
Raramente faz pesquisa de texto completo

Conclusão: Os cenários de relatório e análise de dados são cenários OLAP típicos. Em cenários de negócios, o banco de dados de armazenamento colunar Clickhouse tem mais vantagens do que o Elasticsearch. O Elasticsearch tem mais vantagens na pesquisa de texto completo, mas nosso cenário de pesquisa de texto completo é menor.

5 custo

Custo de aprendizagem: a sintaxe SQL da Clickhouse é mais simples do que a DSL da Elasticsearch Quase todo o P&D de back-end tem experiência em desenvolvimento Mysql, e o custo de aprendizagem é menor.
Custos de desenvolvimento, teste e manutenção: Clickhouse usa sintaxe SQL, que é semelhante ao modelo de desenvolvimento Mysql, e é mais fácil escrever testes de unidade. O Elasticsearch usa a API Java para concatenar instruções de consulta, que são complexas e difíceis de ler e manter.
Custo de O&M: Desconhecido, Clickhouse custa menos que Elasticsearch em cenários de log na Internet.
Custo do servidor:
A taxa de compactação de dados do Clickhouse é maior que a do Elasticsearch.O espaço em disco ocupado pelo ES para os mesmos dados de negócios é de 3 a 10 vezes o do Clickhouse, com uma média de 6 vezes. veja a foto 1
Clickhouse leva menos CPU e memória do que ES

Conclusão: No caso da mesma quantidade de dados, o espaço de armazenamento utilizado pelo Elasticsearch é de 3 a 10 vezes o do Clickhouse, com uma média de 6 vezes. Em termos de aprendizado, desenvolvimento, teste e manutenção abrangentes, o Clickhouse é mais amigável do que o Elasticsearch

6 testes

6.1 Configuração do servidor

Os seguintes são todos testados com base na configuração na figura abaixo

6.2 Teste de pressão de gravação

O seguinte é baseado na tabela wms_order_sku e nos resultados do teste obtidos pela gravação dupla de dados Elasticsearch e Clickhouse1000W+ por meio do Flink sob a condição de estabilidade comercial

Uso de CPU: Elasticsearch tem um alto uso de CPU, enquanto Clickhouse usa muito pouco CPU. Veja a Figura 2

Uso de memória: a memória Elasticsearch aumenta e GC frequente, enquanto o uso de memória Clickhouse é relativamente baixo e relativamente estável. Veja a Figura 3

Taxa de transferência de gravação: a velocidade de gravação independente do CH é de cerca de 50 a 200 MB/s. Se os dados gravados forem de 1 kb por linha, a velocidade de gravação é de 5 a 20 W/s. A Figura 4 (taxa de gravação) é o Internet Elasticsearch e o gráfico de comparação dos dados gravados pela Clickhouse, o desempenho de gravação do CH é 5 vezes maior que o do Elasticsearch na mesma amostra de dados. Como nossas tarefas atuais do Flink são escritas duas vezes, considerando a influência mútua, complementaremos os resultados do teste de pressão mais tarde.

Conclusão: O Elasticsearch consome mais memória e CPU do que o Clickhouse ao gravar dados em lotes. A memória consumida pelo Elasticsearch é 5,3 vezes maior que a do Clickhouse e a CPU consumida é 27,5 vezes maior que a do Clickhouse. A taxa de transferência é 5 vezes maior que a do Elasticsearch

6.3 Desempenho da consulta (teste de simultaneidade única)

Os cenários a seguir são cenários de alta frequência que aparecem em nossos relatórios de dados e análise de dados, portanto, o teste de desempenho da consulta é baseado nisso

Comparação de dados

A Clickhouse em si não tem uma grande diferença no desempenho da consulta quando a configuração do cluster é duplicada.CH2 (48C 182GB) é 14% mais lento que CH1 (80C 320GB) em média. Veja a Figura 5

O desempenho da consulta do Elasticsearch é muito afetado quando a configuração do cluster é duas vezes pior. ES2 (46C 320GB) é 40% mais lento que ES1 (78C 576GB) em média. Veja a Figura 6

Comparado com CH2 (48C 182GB) e ES2 (46C 320GB), o número de núcleos de CPU de ES2 e CH2 é semelhante, e a memória ES2 é 1,75 vezes maior que a do CH2, e a velocidade de resposta do CH2 é 12,7 vezes maior que a do ES2. Veja a Figura 7

Conclusão: O Elasticsearch é mais lento que o Clickhouse ao consultar dados, e a velocidade de resposta do Clickhouse é 12,7 vezes maior que a do Elasticsearch quando a configuração é semelhante. Em particular, a consulta de agregação multicampo baseada em tempo é 32 vezes mais rápida que o Clickhouse. A velocidade de resposta da consulta do Clickhouse é menos afetada pelo tamanho da configuração do cluster.

6.4 Teste de pressão de consulta (teste de alta simultaneidade, dados provenientes da Internet)

Como é mais complicado e demorado preparar testes de alta simultaneidade, conduziremos testes de estresse de consulta com base em nossos dados de negócios e cenários de negócios posteriormente. Os dados a seguir são provenientes de testes realizados pela Internet no cenário de retrato do usuário (volume de dados: 262933269), que é muito semelhante ao nosso cenário.

Conclusão: Clickhouse não suporta alta concorrência o suficiente, e a recomendação oficial é que o QPS máximo seja 100. A taxa de transferência não é tão amigável quanto o Elasticsearch sob alta simultaneidade

7 resumo

As vantagens e desvantagens de Clickhouse e Elasticsearch em comparação com Clickhouse.

vantagem:

O custo dos recursos de hardware é menor e, no mesmo cenário, a Clickhouse ocupa menos recursos.
O custo da mão de obra é menor, e os recém-chegados são mais amigáveis e fáceis de intervir no aprendizado, desenvolvendo testes de unidade e testes.
No cenário OLAP, o Clickhouse é mais adequado que o Elasticsearch, pois o cálculo de agregação é mais refinado e mais rápido que o Elasticsearch, além de economizar recursos de computação do servidor.
O desempenho de gravação é maior, que é 5 vezes maior que o do Elasticsearch nas mesmas circunstâncias, e os recursos do servidor consumidos durante a gravação são menores.
O Elasticsearch frequentemente GCs no caso de um grande número de exportações, o que pode causar sérios tempos de inatividade e não é tão estável quanto o Clickhouse.
O desempenho médio da consulta é 12,7 vezes maior que o do Elasticsearch, e o desempenho da consulta do Clickhouse é menos afetado pela configuração do servidor
Clickhouse pode obter melhor desempenho com o mesmo consumo mensal do servidor.

deficiência:

Não é tão bom quanto o Elasticsearch na pesquisa de texto completo e não é tão bom quanto o Elasticsearch em consultas de alta simultaneidade.

Autor: JD Logística Ma Hongyan

Fonte de conteúdo: comunidade de desenvolvedores JD Cloud