Onde o ClickHouse faz sentido na arquitetura
ClickHouse brilha em cargas analíticas, mas performance não significa simplesmente substituir o banco transacional da aplicação.
Nos últimos dias venho fazendo alguns testes com o ClickHouse e tentando entender, na prática, onde ele realmente faz sentido.
O ClickHouse é um banco de dados colunar, voltado principalmente para cargas analíticas (OLAP). A diferença para um banco tradicional orientado a linhas começa a ficar interessante quando pensamos no tipo de consulta.
Imagine uma tabela com centenas de milhões ou até bilhões de registros de eventos. Uma consulta para saber, por exemplo, a quantidade de acessos por mês, por cidade ou por tipo de usuário pode precisar percorrer uma quantidade enorme de dados.
Em um banco colunar, como o ClickHouse, os dados são organizados por coluna. Isso permite ler apenas aquilo que a consulta realmente precisa, além de aproveitar muito bem compressão e processamento vetorizado.
Na prática, é aí que ele começa a brilhar:
- agregações sobre grandes volumes de dados;
- filtros e scans massivos;
- consultas analíticas complexas;
- excelente compressão;
- processamento de eventos em grande escala;
- possibilidade de distribuir a carga horizontalmente.
Mas uma coisa que estou achando interessante nesse estudo é perceber que performance não significa simplesmente trocar o banco atual por ClickHouse. Ele resolve muito bem determinados problemas, principalmente quando o foco é análise de grandes volumes de dados. Não é necessariamente a melhor escolha para substituir o banco transacional de uma aplicação.
Por isso, estou tentando olhar menos para a tecnologia isoladamente e mais para onde ela se encaixa na arquitetura. Uma possibilidade que estou explorando é justamente utilizar bancos relacionais para a operação do sistema e o ClickHouse como uma camada especializada para analytics, dashboards e exploração de grandes volumes de eventos.
Ainda estou testando e pensando em alguns projetos onde isso poderia fazer sentido.