Só desempenho não basta

• Ao escolher um banco de dados, olhar apenas para a velocidade bruta de consultas e para benchmarks genéricos pode fazer você perder o tempo total que o usuário leva para ir da pergunta até a resposta
• O benchmark da GigaOm de 2019 colocou Azure Data Warehouse e Redshift na frente, mas no mercado real Snowflake e BigQuery venderam melhor, mostrando o peso de fatores além do desempenho
• Mesmo reduzindo o tempo de execução no servidor, caminhos periféricos como driver JDBC, download de resultados, parsing de CSV e a dificuldade de escrever SQL podem ser gargalos maiores
• ClickBench, TPC-H e TPC-DS são úteis, mas as conclusões mudam conforme haja ou não JOINs, varredura de tabela única, ajuste de esquema e condições de garantia de exatidão e ACID
• O desempenho do mecanismo de banco de dados tende a convergir com o tempo, então o critério de escolha de longo prazo deve ser mais a velocidade da ideia até a resposta e a integração com o fluxo de trabalho do que o ranking atual

---

A latência real que os benchmarks deixam passar

• Em uma viagem de 4,5 horas da casa em Seattle até o escritório em San Francisco, mesmo que a velocidade de cruzeiro do avião aumente 10x, o tempo total pode cair só cerca de 20% por causa do deslocamento até o aeroporto, segurança, embarque, espera na pista, bagagem e deslocamento no destino
• Com bancos de dados é parecido
  • Mesmo que o motor fique mais rápido, o usuário ainda lida com arquivos CSV estranhos, problemas difíceis de expressar em SQL e dificuldades para conectar ferramentas
  • Um produto que vence a guerra dos benchmarks é fácil de divulgar, mas isso não significa que ele reduza diretamente o tempo de resolução do problema do usuário
• Na escolha de um banco de dados, facilidade de uso, ecossistema, velocidade de atualização e integração com o fluxo de trabalho podem ser critérios melhores
• Desempenho mostra apenas o tempo de uma tarefa específica em um momento específico e pode levar a otimizar com afinco o gargalo errado

Os resultados da GigaOm em 2019 e o desencontro com o mercado

• Em 2019, a GigaOm executou os benchmarks TPC-H e TPC-DS em data warehouses na nuvem
  • O alvo eram os três grandes fornecedores de nuvem e a Snowflake
  • O resultado colocou o Azure Data Warehouse como o mais rápido, seguido por Redshift, enquanto Snowflake e BigQuery ficaram bem atrás
• Nas avaliações de usuários do BigQuery na época, muitos clientes que comparavam diretamente com Azure acabavam escolhendo BigQuery
• O resultado do mercado foi quase o oposto do ranking do benchmark
  • Snowflake e BigQuery venderam mais do que Redshift
  • Redshift vendeu melhor do que Azure
• TPC-H e TPC-DS eram testes padrão da indústria e também usados para avaliar desempenho internamente, mas se os clientes compraram mais sistemas que ficaram mal colocados em bons benchmarks de desempenho, então havia fatores mais importantes que desempenho

O que o usuário percebe como rapidez não é o tempo de servidor

• Quem cria bancos de dados tende a focar no tempo de execução no servidor entre o momento em que o usuário aperta o botão “run” e o momento em que o resultado fica pronto
• O tempo importante para o usuário é o tempo total para concluir o trabalho, e isso é diferente do tempo que o servidor do banco leva para executar a consulta
• O caso do driver JDBC do BigQuery mostra bem essa diferença
  • JDBC era a interface genérica usada por programadores e ferramentas de BI para se conectar ao banco de dados
  • As consultas do BigQuery rodavam em 1 a 2 segundos, mas por causa do polling de conclusão e da forma de baixar resultados no driver, para o usuário isso parecia levar vários segundos ou até minutos a mais
  • Quando havia muitos resultados, o driver buscava em páginas até dados que o usuário não precisava, aumentando a latência e às vezes causando falhas por falta de memória
• Os engenheiros gastavam muito tempo reduzindo frações de segundo no tempo de consulta, mas o conector mais usado pelos usuários gerava uma latência maior
• Os benchmarks internos rodavam todos os dias, mas o desempenho ponta a ponta e o tempo percebido pelo usuário não apareciam

Desempenho não é um único número fixo

• O desempenho deve ser medido da perspectiva do usuário, não da perspectiva do banco de dados, e como UX é difícil explicá-lo totalmente com um único número
• Qual banco de dados é mais rápido depende da carga de trabalho real
  • Mesmo que uma Lamborghini seja mais rápida que um Prius, no trânsito o tempo de deslocamento para o trabalho pode não mudar
  • A diferença de desempenho entre ClickHouse e Redshift também varia conforme a forma de uso
• O ClickBench do ClickHouse mostrou resultados em que o ClickHouse era mais rápido que vários bancos de dados
  • O benchmark funcionava em uma única tabela, sem JOIN, e dependia muito de contagens distintas
  • Isso pode ser um bom indicador para análise de logs ou cálculo de usuários únicos de um site
  • Mas pode induzir ao erro em cargas de trabalho de esquema estrela típicas de data warehouses tradicionais
• Benchmarks de fornecedores normalmente focam nos pontos em que o fornecedor é forte
• O BigQuery pode parecer fraco em benchmarks, mas como quase não tem knobs e em geral se autoajusta, a experiência real do usuário pode ser boa
• Uma instância do SingleStore altamente ajustada pode superar o BigQuery em muitas tarefas, mas isso exige tempo de tuning de esquema e adaptação quando novas cargas de trabalho são adicionadas
• Também é possível aumentar o desempenho reduzindo proteções ou exatidão
  • remover verificações de overflow
  • pular flush de escrita
  • fornecer resultados aproximados em algumas operações
  • não oferecer garantias ACID
• Fora de ambientes controlados, esses atalhos podem não ser escolhas desejáveis

Mais importante que o ranking atual é a velocidade de melhoria

• Ao criar uma empresa baseada em DuckDB, houve quem apontasse que o DuckDB ficava muito atrás no benchmark da h2o.ai
• Havia dois motivos para não se preocupar
  • desempenho era um fator secundário
  • o DuckDB estava melhorando em ritmo muito rápido
• Essa melhora acelerada do DuckDB foi influenciada por algumas decisões de arquitetura, por uma base de código relativamente nova e limpa e por engenheiros excelentes
• Nos resultados públicos mais recentes do mesmo benchmark para releases novos do DuckDB, ele saiu do meio do pelotão para a liderança com ampla vantagem
• Escolher um banco de dados é uma decisão que dura vários anos, então importa não apenas o desempenho e os recursos atuais, mas também a capacidade possível daqui a um ano
• Se dois bancos de dados evoluem em velocidades diferentes, há grande chance de ser melhor escolher o que se move mais rápido

As diferenças de desempenho diminuem com o tempo

• Quando vários bancos de dados mantidos ativamente passam por anos de melhorias repetidas, o desempenho tende a convergir
• Técnicas de desempenho de um produto podem com o tempo ser implementadas em outros
  • Se o ClickHouse usa técnicas vantajosas para velocidade de varredura, a Snowflake pode ter recursos parecidos em 1 ou 2 anos
  • Se a Snowflake adiciona materialized views incrementais, o BigQuery pode acompanhar logo depois
• Cada banco de dados usa técnicas diferentes para obter desempenho
  • compilar consultas em código de máquina
  • manter dados em cache em SSD local
  • tratar shuffle com hardware de rede especializado
• Dadas tempo suficiente, técnicas eficazes podem ser implementadas por qualquer um e, se funcionarem bem, tendem a se espalhar por vários sistemas
• Na comparação de desempenho de data warehouses de George Fraser, CEO da Fivetran, em 2020 o tempo mais rápido era 8 segundos e o mais lento 18 segundos, mas em 2022 três fornecedores estavam em cerca de 7 segundos e o mais lento em 9 segundos
• Ainda assim, diferenças de arquitetura são difíceis de superar
  • bancos de dados shared nothing podem ficar em desvantagem frente a shared disk
  • o Redshift levou vários anos para migrar principalmente para uma arquitetura shared disk
  • lakehouses que armazenam metadados em object storage podem ter dificuldade com atualizações rápidas
• Essas diferenças aparecem sobretudo em condições-limite, e no longo prazo não há razão essencial para que o Redshift tenha de ser intrinsecamente mais rápido ou mais lento que o Snowflake

Funcionalidades que reduzem o tempo da pergunta até a resposta

• O desempenho que importa para o usuário é o tempo desde o surgimento da pergunta até a obtenção da resposta
• Há várias formas de reduzir esse tempo além de melhorar o plano de consulta
  • tornar mais fácil expressar a pergunta
  • tornar o resultado da consulta mais fácil de entender
  • fornecer feedback quando a pergunta estiver errada
  • ajudar a entender problemas nos dados
  • preparar os dados necessários no lugar e no formato corretos
• A Snowflake se destacava em fazer com que, quando o usuário digitava SQL, “simplesmente funcionasse”
  • ao calcular diferença entre datas, era possível usar tanto DATEDIFF quanto TIMEDIFF
  • se os tipos fossem razoáveis, ambos funcionavam
  • era possível especificar ou omitir a granularidade
  • funcionava com ou sem aspas na granularidade
• O DuckDB também adicionou recursos de Friendlier SQL para facilitar escrita e manutenção de consultas
  • GROUP BY ALL reduz omissões de campos na cláusula GROUP BY em consultas agregadas
  • como basta alterar a lista do SELECT, reduz a necessidade de mexer em vários pontos conforme a consulta evolui
  • quando esse recurso se mostrou útil, vários fornecedores de banco de dados adicionaram algo semelhante
• Arquivos CSV armazenam muitos dados do mundo, mas muitos deles são mal formados e fazer parsing é realmente difícil
  • o splitter de CSV inicial do BigQuery não fazia inferência e se confundia quando o esquema variava um pouco entre arquivos
  • fazer parsing de CSV é um problema mais complicado do que parece
• Se dois engenheiros precisarem ler dados em CSV e calcular o mesmo resultado, quem conseguir fazer o ingest do CSV de forma correta com mais facilidade pode chegar primeiro à resposta, independentemente da velocidade do motor de consulta
• A forma de tratar resultados também afeta fortemente a experiência do usuário
  • se SELECT * retornar a primeira página e um cursor, como no MySQL, algo pode aparecer imediatamente
  • se for necessário criar uma cópia da tabela no servidor, como no BigQuery, isso pode levar horas em tabelas grandes
  • se o cliente tentar baixar todos os dados, pode faltar memória
  • conexões longas são vulneráveis a problemas de rede, e polling pode fazer uma consulta parecer mais lenta quando ela termina entre dois intervalos de verificação

Observações ao olhar benchmarks do DuckDB

• O DuckDB é rápido e está entre os melhores em alguns tamanhos de máquina do ClickBench
  • como exemplo, é citado o resultado em c6a.4xlarge
• O DuckDB também mostra bom desempenho na maior parte dos benchmarks da h2o.ai, além de não ir mal em TPC-H e TPC-DS
• Antes de presumir que algum banco de dados é rápido, é preciso testá-lo diretamente na sua carga de trabalho

Resolver o problema mais rápido importa mais que consultas mais rápidas

• As empresas de banco de dados mais bem-sucedidas não venceram só por serem mais rápidas que a concorrência
• O Redshift foi forte por um tempo, mas a Snowflake conseguiu entrar não por desempenho de benchmark, e sim por manutenibilidade
• Bancos de dados que usaram desempenho como principal argumento de venda não tiveram bom resultado no mercado, enquanto os que ajudaram a concluir o trabalho com facilidade foram mais duradouros
• Os eixos a observar ao escolher um banco de dados são mais amplos
  • não existe técnica secreta mágica e, exceto por diferenças de arquitetura, o desempenho tende a convergir com o tempo
  • a velocidade de evolução do mecanismo varia muito entre bancos, e quem se move mais rápido tende a ter vantagem no longo prazo
  • o fornecedor de banco de dados mais obcecado por desempenho pode ficar mais lento no longo prazo
  • não existe uma métrica única de desempenho, e mesmo um banco rápido pode ir mal em certas cargas de trabalho
  • o recurso importante não é quão rápido se vai da consulta ao resultado, mas da ideia até a resposta
• Consulta rápida é melhor que consulta lenta, mas a escolha de um banco de dados deve se basear em fatores além da velocidade bruta

[GN⁺]

Opiniões no Hacker News

• É frustrante a parte em que eles “não tinham a menor ideia” de que um problema no driver JDBC estava arruinando o desempenho, apesar de haver muitas reclamações de clientes durante anos
  Ou seja: dentro do Google, eles nem usavam o próprio produto como clientes reais, e como o tempo de consulta visto pelos usuários não aparecia internamente, tratavam isso como problema dos outros

  • A lição aprendida aqui também parece um pouco desviada. Não é que “desempenho não basta”; é que o desempenho no caminho que o cliente realmente usa importa mais do que benchmarks de componentes isolados
    O problema não foi ter dedicado esforço demais à otimização, mas não ter partido da dor do cliente e rastreado até a causa raiz. A causa real, no fim, também era um problema de desempenho

• A história do JDBC foi muito boa. O Google criou um banco de dados que funcionava bem internamente, terceirizou a camada de adaptadores para o mundo externo, e ela não funcionava direito, então os usuários externos acabaram usando um banco de dados péssimo
  Foi como colocar uma embalagem quebrada em cima de um núcleo sofisticado usado pelo Google, fazendo o produto inteiro ficar desnecessariamente bagunçado; internamente ninguém percebeu, e para usuários externos também era difícil identificar a causa. Parece um exemplo muito preciso da estratégia de open source do Google

  • Do ponto de vista gerencial, até dá para entender. Algo como: “contratamos os melhores talentos de ciência da computação, então vamos colocá-los para resolver os problemas centrais de ciência da computação; o driver JDBC não é nossa competência central, então vamos terceirizar”
    O problema é que, se você estragar áreas não centrais o suficiente, não adianta ter uma competência central excelente. Terceirização não é almoço grátis
  • Os wrappers Python para APIs do Google eram todos essa mesma história
  • Isso vem da falta de integração vertical. O motivo pelo qual a Apple vence em vários aspectos é que ela faz integração vertical muito bem
  • Contratos empresariais como o Workspace seguem exatamente essa estrutura. Em cima de um excelente produto central, colocam-se contratos de “suporte” inúteis — mais que inúteis, prejudiciais — de algumas das piores consultorias do mundo, que ficam com uns 15%

• O texto diz que “desempenho é subjetivo” e que medições simples não bastam, mas os exemplos, na verdade, são casos em que o desempenho era realmente importante e objetivo. Só estavam medindo o alvo errado

  • Ele começa já no primeiro parágrafo com um exemplo que se encaixa perfeitamente na Lei de Amdahl, e é surpreendente que isso não seja mencionado nenhuma vez no texto

• Isso soa como um problema organizacional da empresa. Se o objetivo final é fazer as pessoas usarem a nuvem e entregar valor, não entendo por que eles têm métricas desalinhadas com o que os clientes consideram importante
  Deveria haver gente dentro do Google conversando diretamente com clientes, entendendo quais são os problemas e repassando isso aos engenheiros para que eles saibam o que melhorar. A organização deveria ser desenhada para que os engenheiros recebam as métricas de que precisam, ou para que criar essas métricas faça parte do próprio trabalho

  • “Quando anedotas e métricas divergem, normalmente descobri que as anedotas estão certas” — Jeff Bezos. Infelizmente, às vezes ele dizia coisas boas
  • O Google parece ter uma certa alergia a falar diretamente com clientes
  • https://en.wikipedia.org/wiki/Seeing_Like_a_State
  • Se nossa solução não resolve o problema do cliente, então o cliente precisa de outro problema, ou nós precisamos de outro cliente
  • Concordo totalmente. Parece um problema de escolher a métrica errada para mirar. Mas vai além de a equipe de engenharia ter medido apenas uma fatia estreita demais da latência
    Fico mais curioso sobre quais métricas o produto e a liderança organizacional estavam olhando para terem deixado passar esse feedback dos clientes

• Ao ver a parte de “4,5 horas porta a porta de casa em Seattle até o escritório em San Francisco”, parece que os fundadores de hoje não se movem mais a 179 milhas por hora. Pelo jeito é isso que acontece quando o Fed sobe os juros

  • Quando li pela primeira vez, achei que ele estava dirigindo, mas provavelmente é o tempo incluindo avião + deslocamento até/de aeroportos + inspeção de segurança
  • Neste momento estou indo de casa em Seattle para o escritório em SF. Saí há 48 minutos; quando chegar, atualizo para adicionar eu mesmo mais um ponto de dados aqui

• Há pontos claramente bons, mas a conclusão parece um pouco desalinhada. Desempenho aqui não é tanto algo secundário, como o texto sugere; está mais para uma questão de ser suficiente ou não
  Você precisa passar no critério de ser rápido o bastante para então poder avaliar outros fatores. Antes disso, você nem se senta à mesa da competição. O próprio autor diz que “DuckDB é rápido”; se não fosse, ele teria que competir em desempenho pelo menos até marcar essa caixinha
  Além disso, a frase “o mecanismo de banco de dados que se move mais rápido acaba vencendo” pode estar correta em certa medida, mas não é muito prática. Quando você é um novo entrante, o progresso é rápido, mas ao chegar a uma posição como a da Snowflake, a velocidade inevitavelmente diminui. Do ponto de vista de quem escolhe um sistema hoje, não dá para extrapolar a aceleração atual diretamente para o futuro
  Ainda assim, a perspectiva de medir não “da consulta ao resultado”, mas da ideia à resposta, parece merecer uma investigação mais profunda por si só

• Desempenho não é “subjetivo”, é mais relativo. Seu significado está ligado à tarefa em questão
  Mas, se a ideia é falar de interfaces de usuário que fazem o usuário sentir que algo está mais rápido, como uma barra de progresso que se move rapidamente, aí é outra história. Isso é um problema de interface, não de banco de dados

  • “Subjetivo” é a palavra certa. Quais tarefas são relevantes depende do sujeito
    Para chamar de “relativo”, teria que não haver forma de atribuir um número ao desempenho fora de comparações entre sistemas, e isso não é verdade

• O primeiro web app que ganhou popularidade colocava todo o estado em um dict do Python e fazia dump para disco a cada poucos minutos. Foi a API mais rápida que vi na vida
  Depois que migramos para Mongo, o desempenho nunca mais se recuperou. Mesmo assim, hoje, ao criar um site, eu não pegaria “pickledb”

  • Como substituto para fopen, SQLite é um meio-termo
  • Acho que mais gente poderia considerar, desde o início, uma arquitetura de residência em memória + snapshots, em vez de uma estrutura de banco de dados transacional
    Ela se encaixa menos em interações de usuário do tipo requisição/resposta, mas, para grandes dados estáticos ou dados de streaming reproduzíveis processados incrementalmente ou em lote, acho que deveria ser mais comum do que é hoje

• Estou procurando bons materiais sobre o tema: “bancos de dados shared nothing ficam em desvantagem em relação a shared disk, e o Redshift levou anos para migrar principalmente para uma arquitetura shared disk. Lakehouses que armazenam metadados em object storage têm dificuldade com atualizações rápidas”

• Bom texto. Acho que esse também foi um dos motivos pelos quais o pandas foi forte nos últimos 10 anos
  O desempenho em uma única máquina era bom o suficiente, e ele conseguia ler 99% dos CSVs conhecidos pela humanidade