Os Bancos de Dados Colunares São Incrivelmente Rápidos. Eis o Motivo.

PortuguêsالعربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어Русский中文
BBetter Stack
Computing/Software

Transcript

00:00:00embora eu adore o postgres, ele não é o melhor para tudo. existe um tipo diferente de
00:00:04banco de dados chamado banco de dados colunar, que consegue executar certas consultas até 40 vezes mais rápido. esses
00:00:10bancos funcionam armazenando colunas juntas em vez de linhas, o que traz enormes benefícios
00:00:15para casos de uso específicos, como plataformas de análise. agora, é claro que tudo tem um custo e
00:00:20hoje veremos exatamente o que são os bancos de dados colunares e compararemos algumas consultas com
00:00:25o postgres para ver os prós e os contras. vamos comparar o postgres com o clickhouse e o duckdb,
00:00:31então fique por aqui e, no final, você terá uma sólida compreensão dos bancos baseados em colunas
00:00:36e de quando escolher a tecnologia certa.
00:00:43então, no início eu disse que você pode executar certas consultas 40 vezes mais rápido, e isso é verdade. se pegarmos uma
00:00:49tabela de banco de dados aqui — carreguei cem milhões de linhas — e executarmos uma consulta group by com
00:00:55o postgres, isso leva cerca de 9,7 segundos para ser concluído, porque estamos agregando a receita de cada
00:01:00única linha. se executarmos a mesma consulta no mesmo conjunto de dados usando um banco de dados colunar — e estamos
00:01:06rodando literalmente o mesmo sql, pois tanto o clickhouse quanto o duckdb têm sintaxe sql parecida com a do postgres, então
00:01:13você vai se sentir em casa —, o clickhouse leva 0,28 segundos e o duckdb, 0,24 segundos. isso é mais de 40 vezes mais rápido!
00:01:22como isso é possível? parece inacreditável, né? os mesmos cem milhões de linhas processados em apenas 0,24 segundo.
00:01:30bem, os bancos de dados colunares fazem ordens de magnitude menos trabalho para nos dar os mesmos resultados.
00:01:36vamos ver outra consulta em ação. e um aviso rápido, pessoal: lançamos conteúdo de ia e tecnologia o tempo todo,
00:01:42então se você curte isso, por que não se inscrever no better stack? desta vez, estamos contando o número
00:01:47de eventos entre dois carimbos de data/hora em que o código do país é gb. no nosso caso, estamos olhando os dados de
00:01:53março. os resultados: postgres com 5,9 segundos, clickhouse com 0,06 segundo e duckdb com 0,03 segundo. março contém
00:02:02cerca de 13% do total de eventos aqui, então o postgres ainda precisa analisar milhões de linhas. poderíamos
00:02:09adicionar indexação agressiva aqui para ajudar, mas isso nem chegaria perto do clickhouse e do duckdb. então por que
00:02:15os armazenamentos colunares são muito mais rápidos aqui? bem, o clickhouse não indexa linhas individuais de jeito nenhum. quando você cria
00:02:20uma tabela, você define uma chave de ordenação e, como ela é ordenada por data/hora, os dados ordenados são divididos em blocos de
00:02:32e ele apenas guarda uma nota da primeira data/hora de cada um. para cem milhões de linhas, são cerca de 12.000 notas,
00:02:39o que é pequeno o suficiente para caber na memória. então, quando pedimos março, ele faz uma busca rápida por essas
00:02:44notas, acha os blocos que podem conter março e lê apenas esses. no nosso caso, são 1.633 blocos de
00:02:52um total de 12.208, e todo o resto no disco é ignorado. o duckdb faz algo parecido, pois mantém um valor
00:03:00mínimo e máximo para cada pedaço de uma coluna. assim, podemos olhar um pedaço, ver que as datas vão de janeiro a
00:03:06fevereiro e pular tudo sem precisar ler. adicione a isso o truque de antes, em que ele só
00:03:10abre as colunas necessárias, e você obtém 0,03 segundo. mas a situação muda completamente quando você quer
00:03:17selecionar uma única linha por id. essa consulta simples revela muito: o postgres leva dois milissegundos, o clickhouse, 168
00:03:26milissegundos, e o duckdb, curiosamente, ainda fica em dois milissegundos. o postgres tem um índice de árvore binária no
00:03:32id, então ele desce pela árvore, chega na única página que guarda a linha e termina em apenas dois
00:03:37milissegundos. mas com o clickhouse temos um problema: o único índice dele é aquela chave de ordenação, e esta tabela é
00:03:43ordenada por data/hora primeiro e por id segundo. então, quando pedimos um id específico, ele faz a menor ideia de qual bloco esse id
00:03:51habita, acabando por verificar cada um dos 12.208 blocos. e, assim que encontra a linha, ele ainda
00:03:57precisa abrir todos os oito arquivos de coluna e juntar essa linha de novo, o que dá muito trabalho para uma
00:04:03consulta tão simples. então, como o duckdb se safa dessa? ele deu sorte com os nossos dados: os ids foram inseridos em
00:04:09ordem, então o mínimo e o máximo de cada pedaço batem certinho com o id, permitindo que o duckdb pule direto para o bloco
00:04:16certo. se os ids estivessem embaralhados, ele estaria varrendo a coluna inteira, exatamente como o clickhouse. vamos ver agora
00:04:21como atualizar uma linha. temos uma consulta para o postgres e o duckdb, e uma versão ligeiramente diferente para
00:04:26o clickhouse. o postgres levou cinco milissegundos, o clickhouse, 5,8 segundos, e o duckdb, de novo, apenas dezenas
00:04:34de milissegundos. o postgres apenas reescreve uma linha e atualiza uma entrada de índice; no clickhouse, os arquivos de dados
00:04:40são imutáveis e nunca são editados no lugar. portanto, para alterar um valor de receita, ele precisa reescrever o
00:04:46arquivo inteiro da coluna de receita para aquele pedaço da tabela. o clickhouse até obriga você a escrever isso como um
00:04:51alter table, pois ele trata como uma mutação da tabela inteira. há uma atualização mais leve em
00:04:56fases de teste, mas ela serve apenas para um número pequeno de linhas — cerca de 10% da tabela no máximo. o duckdb fica no meio
00:05:03termo entre os dois, já que seu arquivo pode ser alterado no próprio local, fazendo com que a atualização de uma única linha leve algumas dezenas de
00:05:08milissegundos. por fim, vamos contar o número de usuários distintos na nossa tabela, usando mais uma vez uma pequena
00:05:14variação da consulta para o clickhouse. os resultados foram: postgres com 38,4 segundos, clickhouse com 0,78 segundo
00:05:22e duckdb em menos de um segundo. de novo, o postgres sofre: fazer agregações em uma tabela tão grande
00:05:28exige uma quantidade enorme de trabalho. agora, você geralmente vai querer usar bancos colunares para coisas como análise,
00:05:34onde agregar dados em várias colunas é uma tarefa comum. aqui vimos duas opções: o clickhouse
00:05:41é um servidor hospedado, de código aberto e disponível na maioria das principais plataformas. para rodá-lo localmente, você precisa executar
00:05:47um servidor clickhouse na sua máquina, o que é bem mais próximo de como o postgres funciona. o duckdb, no entanto, se parece mais com o sqlite:
00:05:54é uma biblioteca que roda dentro do seu próprio processo e o banco de dados inteiro fica em um único arquivo no disco, o que significa
00:06:00que esse arquivo pode ser bloqueado enquanto uma atualização está em andamento, matando a concorrência. ambos são bancos de dados
00:06:06colunares, mas adotam abordagens bem diferentes. portanto, a escolha do banco de dados depende de muito mais
00:06:12do que eu poderia presumir aqui; não se trata apenas da velocidade bruta de consulta ao rodar demonstrações na sua máquina local,
00:06:17mas sim de escalabilidade, redundância e extensibilidade. claro que o postgres tem um rico ecossistema de plugins para
00:06:24expandir seus recursos de várias maneiras, o que você pode conferir neste próximo vídeo.

Key Takeaway

Bancos de dados colunares como clickhouse e duckdb executam consultas analíticas e de agregação até 40 vezes mais rápido que o postgres, mas perdem em eficiência ao buscar ou atualizar linhas individuais.

Highlights

  • Consultas group by em cem milhões de linhas levam 9,7 segundos no postgres, 0,28 segundo no clickhouse e 0,24 segundo no duckdb.

  • O clickhouse armazena dados em blocos ordenados e guarda apenas a primeira data/hora de cada bloco, permitindo ignorar dados irrelevantes no disco.

  • O postgres conclui a busca de uma única linha por id em dois milissegundos usando um índice de árvore binária.

  • O clickhouse trata atualizações como mutações de tabela inteira, exigindo a reescrita do arquivo de coluna inteiro.

  • O duckdb opera como uma biblioteca em processo com o banco inteiro em um único arquivo, enquanto o clickhouse roda como um servidor dedicado.

Timeline

Desempenho em consultas analíticas em grande escala

  • Consultas group by em cem milhões de linhas executam em 9,7 segundos no postgres contra menos de 0,3 segundo no clickhouse e duckdb.
  • Bancos colunares processam ordens de magnitude menos dados ao agrupar colunas específicas em vez de linhas inteiras.

O postgres avalia cada linha individualmente durante agregações de grande volume. Os bancos de dados colunares utilizam a mesma sintaxe sql, mas obtêm ganhos drásticos de velocidade ao ler apenas os dados estritamente necessários para a consulta.

Mecanismos de indexação e filtragem por blocos

  • O clickhouse divide os dados em blocos ordenados por data/hora e mantém apenas a nota do primeiro registro de cada bloco.
  • O duckdb armazena valores mínimos e máximos para cada pedaço de coluna para descartar blocos inteiros sem leitura em disco.

A indexação baseada em blocos elimina a necessidade de varrer tabelas inteiras. O clickhouse armazena cerca de 12.000 notas para cem milhões de linhas, o que cabe inteiramente na memória para consultas rápidas de intervalo.

Buscas por id e restrições de arquitetura

  • O postgres resolve buscas por id em dois milissegundos usando árvores binárias.
  • O clickhouse consome 168 milissegundos em buscas por id devido à necessidade de verificar todos os blocos e juntar os arquivos de coluna.

Arquiteturas colunares enfrentam desafios em consultas focadas em linhas únicas. O clickhouse precisa inspecionar todos os blocos quando a chave primária de ordenação não corresponde ao campo buscado, exigindo a junção de múltiplos arquivos de coluna.

Atualizações de dados e mutações

  • O postgres atualiza linhas e índices em cinco milissegundos com reescritas diretas.
  • O clickhouse exige um comando alter table para reescrever o arquivo inteiro da coluna devido à imutabilidade dos dados.

A imutabilidade dos arquivos no clickhouse impede edições pontuais no local. Alterações de valores exigem mutações pesadas na estrutura da tabela, enquanto o duckdb permite modificações diretas no arquivo local.

Contagem de valores distintos e escolha da tecnologia

  • Agregações de usuários distintos levam 38,4 segundos no postgres e menos de um segundo nos bancos colunares.
  • O clickhouse opera como um servidor de rede tradicional, enquanto o duckdb roda como biblioteca em processo com armazenamento em arquivo único.

A escolha entre postgres, clickhouse e duckdb depende de requisitos de escalabilidade, concorrência e o equilíbrio entre desempenho analítico e transacional. O modelo de arquivo único do duckdb restringe a concorrência de gravações, enquanto o clickhouse oferece arquitetura de servidor dedicada.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video