Skip to main content
Este guia faz parte de uma coleção de descobertas reunidas em encontros da comunidade. Para ver mais soluções práticas e insights, você pode explorar por problema específico. Precisa de dicas para depurar um problema em produção? Confira o guia da comunidade Debugging Insights. Estas histórias mostram como empresas tiveram sucesso ao usar o ClickHouse em seus casos de uso, algumas até desafiando categorias tradicionais de bancos de dados e provando que, às vezes, a ferramenta “errada” acaba sendo exatamente a solução certa.

​
ClickHouse como limitador de taxa

Quando a Craigslist precisou adicionar um sistema de rate limiting de primeira linha para proteger seus usuários, enfrentou a mesma decisão que toda equipe de engenharia encontra: seguir a abordagem convencional e usar Redis, ou explorar algo diferente. Brad Lhotsky, na Craigslist, sabia que o Redis era a escolha padrão — praticamente todo tutorial e exemplo de rate limiting na internet usa Redis, e por um bom motivo. Ele tem primitivas ricas para operações de rate limiting, padrões bem estabelecidos e um histórico comprovado. Mas a experiência da Craigslist com Redis não batia com os exemplos de manual. “Nossa experiência com Redis não é como nos filmes… há vários problemas estranhos de manutenção que enfrentamos quando reiniciamos um nó em um cluster Redis e algum pico de latência atinge o front-end.” Para uma equipe pequena que valoriza a simplicidade operacional, essas dores de cabeça estavam se tornando um problema real. Então, quando Brad recebeu os requisitos de rate limiting, adotou uma abordagem diferente: “Perguntei ao meu chefe: ‘O que você acha desta ideia? Talvez eu possa tentar isso com ClickHouse?’” A ideia era incomum — usar um banco de dados analítico para algo que normalmente seria resolvido na camada de cache — mas atendia aos requisitos centrais deles: operar em fail-open, não acrescentar penalidades de latência e ser segura do ponto de vista de manutenção para uma equipe pequena. A solução aproveitou a infraestrutura existente, na qual os logs de acesso já fluíam para o ClickHouse via Kafka. Em vez de manter um cluster Redis separado, eles podiam analisar padrões de requisição diretamente nos dados de logs de acesso e injetar regras de rate limiting na API de ACL existente. A abordagem implicava uma latência um pouco maior do que no Redis, que “meio que trapaceia ao materializar esse conjunto de dados de antemão” em vez de fazer consultas de agregação em tempo real, mas as consultas ainda eram concluídas em menos de 100 milissegundos. Principais resultados:
  • Grande melhoria em relação à infraestrutura baseada em Redis
  • O TTL integrado para limpeza automática eliminou a sobrecarga de manutenção
  • A flexibilidade do SQL permitiu regras complexas de rate limiting além de contadores simples
  • Aproveitou o pipeline de dados existente em vez de exigir infraestrutura separada

​
ClickHouse para análise de clientes

Quando a ServiceNow precisou modernizar sua plataforma de análise mobile, surgiu uma pergunta simples: “Por que substituir algo que funciona?” Amir Vaza, da ServiceNow, sabia que o sistema existente era confiável, mas as demandas dos clientes estavam ultrapassando sua capacidade. “A motivação para substituir um modelo confiável existente vem, na verdade, do lado do produto”, explicou Amir. A ServiceNow oferecia análise mobile como parte da sua solução para web, mobile e chatbots, mas os clientes queriam uma flexibilidade analítica que fosse além dos dados pré-agregados. O sistema anterior usava cerca de 30 tabelas diferentes com dados pré-agregados segmentados por dimensões fixas: aplicação, versão do app e plataforma. Para propriedades personalizadas — pares chave-valor que os clientes podiam enviar — eles criavam contadores separados para cada grupo. Essa abordagem oferecia alto desempenho no dashboard, mas tinha uma grande limitação. “Embora isso seja ótimo para uma análise rápida dos valores, como mencionei, essa limitação leva a uma grande perda de contexto analítico”, observou Amir. Os clientes não conseguiam realizar análises complexas da jornada do cliente nem fazer perguntas como “quantas sessões começaram com o termo de busca ‘research RSA token’” e então analisar o que esses usuários fizeram em seguida. A estrutura pré-agregada eliminava o contexto sequencial necessário para análises em várias etapas, e cada nova dimensão analítica exigia trabalho de engenharia para pré-agregar e armazenar os dados. Então, quando as limitações ficaram claras, a ServiceNow migrou para o ClickHouse e eliminou completamente essas restrições de pré-computação. Em vez de calcular cada variável antecipadamente, eles transformaram os metadados em pontos de dados e inseriram tudo diretamente no ClickHouse. Eles usaram a fila de async insert do ClickHouse, que Amir chamou de “realmente incrível”, para lidar com a ingestão de dados com eficiência. Com essa abordagem, os clientes passaram a poder criar seus próprios segmentos, fatiar os dados livremente em quaisquer dimensões e realizar análises complexas da jornada do cliente que antes não eram possíveis. Principais resultados:
  • Segmentação dinâmica em quaisquer dimensões sem pré-computação
  • Análises complexas da jornada do cliente passaram a ser possíveis
  • Os clientes podiam criar seus próprios segmentos e fatiar os dados livremente
  • Fim dos gargalos de engenharia para novos requisitos analíticos

​
Vídeos

Essas histórias mostram como desafiar ideias convencionais sobre bancos de dados pode levar a soluções inovadoras que redefinem o que é possível com bancos de dados analíticos.
Última modificação em 3 de julho de 2026