Só `perf` não basta

A cultura de obsessão por desempenho em bancos de dados

• A indústria de bancos de dados está focada em melhorar o desempenho, mas a experiência real do usuário muitas vezes é afetada por outros fatores.
• Para o usuário processar dados, o que realmente importa pode ser o formato dos dados ou a capacidade de formular perguntas em SQL, mais do que a otimização de consultas.
• O desempenho do banco de dados é importante, mas pode ser melhor escolher um banco com base em outros fatores, como facilidade de uso, ecossistema, velocidade de atualização e integração com o fluxo de trabalho.

O fim da guerra dos benchmarks

• Em 2019, a GigaOm publicou um benchmark comparando data warehouses em nuvem, mas o resultado real do mercado mostrou um cenário diferente.
• Quando os resultados de benchmark não coincidem com a experiência do usuário, isso sugere que o benchmark estava errado, testou a coisa errada ou que o desempenho pode não ser tão importante assim.

O significado de ser rápido

• No setor de bancos de dados em nuvem, há uma tendência de focar no tempo entre o usuário clicar no botão “executar” e o resultado ficar pronto.
• O que realmente afeta o usuário é o tempo necessário para concluir o trabalho, e isso não é o mesmo que o tempo do servidor de banco de dados.

Desempenho é subjetivo

• O desempenho deve ser medido do ponto de vista do usuário e, por ser uma questão de UX, não pode ser explicado por um único número.
• A subjetividade do desempenho significa que o que é mais rápido depende de como o banco de dados é usado.

A velocidade da mudança

• O DuckDB está melhorando em ritmo acelerado, o que torna os benchmarks atuais sem muito sentido.
• Ao escolher um banco de dados, não só o desempenho atual, mas também as mudanças futuras em desempenho e funcionalidades são variáveis importantes.

Não existe feijão mágico

• Se todos os bancos de dados estiverem sendo mantidos ativamente, o desempenho vai convergir com o tempo.
• É pouco provável que diferenças importantes de desempenho se mantenham ao longo do tempo.

O problema está entre a cadeira e o teclado, e entre o teclado e o banco de dados

• A métrica de desempenho que importa para o usuário é o tempo que leva para chegar com uma pergunta e obter uma resposta.
• A funcionalidade importante não é quanto tempo o banco leva para executar a consulta, mas sim a velocidade de ir da ideia à resposta.

Sobre uvas azedas

• O DuckDB atualmente está entre os líderes nos benchmarks ClickBench e h20.ai, e também apresenta um desempenho razoável em TPC-H e TPC-DS.
• Antes de assumir que um banco de dados é rápido, é importante testá-lo na carga de trabalho real.

Conclusão

• As empresas de banco de dados mais bem-sucedidas não tiveram sucesso por serem mais rápidas que as concorrentes.
• Bancos de dados que usaram desempenho como principal argumento de venda não tiveram sucesso no mercado.
• Ao escolher um banco de dados, a recomendação é decidir com base em outros fatores além da velocidade bruta.

Opinião do GN⁺

• Este artigo enfatiza que não basta focar apenas no desempenho do banco de dados; também é importante otimizar a experiência do usuário e o fluxo de trabalho. Isso traz uma lição importante até para engenheiros de software iniciantes: ao escolher um banco de dados, vale mais considerar uma abordagem centrada no usuário do que se guiar apenas por métricas simples de desempenho.
• O desempenho de bancos de dados tende a convergir com o tempo, porque os avanços tecnológicos acabam se espalhando por todas as plataformas. Isso sugere que, ao fazer escolhas tecnológicas, é melhor considerar suporte de longo prazo e potencial de melhoria do que desempenho de curto prazo.
• Projetos open source como o DuckDB podem evoluir rapidamente com base no ritmo de melhoria e no apoio da comunidade. Isso significa que, ao adotar uma nova tecnologia, é importante considerar o nível de atividade da comunidade e a velocidade de evolução do projeto.
• Ao escolher um banco de dados, é importante não depender apenas dos resultados de benchmarks de desempenho, mas também testar o desempenho na carga de trabalho real. Isso pode ajudar a selecionar um banco mais adequado aos casos de uso reais.
• A escolha de uma tecnologia de banco de dados deve considerar não apenas aspectos técnicos, mas também diversos fatores como necessidades de negócio, facilidade de manutenção e eficiência no processamento de dados.

[GN⁺]

Comentários do Hacker News

• Depois de alguns anos com muitas reclamações de clientes, perceberam que um bug no driver JDBC estava degradando o desempenho. Muito tempo de engenharia foi investido para acelerar as consultas, mas o conector usado pela maioria dos usuários adicionava muito mais latência do que o tempo economizado. Além disso, eles não tinham nenhuma percepção disso. Como ninguém dentro do Google usava o driver JDBC, não conseguiam ver o tempo de consulta que os usuários experimentavam e tratavam isso como um problema dos outros.

  • Este comentário expressa decepção com o fato de o Google estar “completamente cego” às reclamações dos clientes e não usar o próprio produto. A parte sobre o JDBC é especialmente marcante.
• O Google construiu internamente um banco de dados que funcionava bem, mas terceirizou a criação da camada adaptadora para o mundo externo, e ela não funcionou direito, fazendo com que o mundo externo acabasse usando um banco de dados ruim. O núcleo sofisticado que o Google usa está cercado por adaptadores imperfeitos, resultando, no conjunto, em algo desnecessariamente bagunçado. Internamente, eles não percebem isso, e para quem está de fora é difícil identificar.
  • Este comentário avalia que isso se aplica muito bem à estratégia de código aberto do Google.
• Acho estranho que o blog afirme que “desempenho é subjetivo”. Medir desempenho por si só não basta, mas no único exemplo dado, o desempenho é importante e objetivo. Eles apenas mediram a coisa errada.
  • Este comentário questiona a afirmação do blog sobre medição de desempenho.
• Isso parece um problema de organização da empresa. Se o objetivo final é fazer os clientes usarem a nuvem e entregar valor, não se pode trabalhar com métricas diferentes daquelas que importam para os clientes. Dentro do Google, deveria haver alguém ouvindo ativamente os problemas dos clientes e levando isso aos engenheiros para indicar o que precisa ser melhorado.
  • Este comentário enfatiza a necessidade de uma estrutura organizacional que entenda as demandas dos clientes e trabalhe para melhorá-las.
• Da minha casa em Seattle até o escritório de San Francisco leva cerca de 4,5 horas de porta a porta.
  • Este comentário aponta que os fundadores já não se movem tão rápido quanto antes e menciona em tom de piada que isso pode ser porque o Federal Reserve elevou os juros.
• Não acho que desempenho seja secundário da forma como está sendo dito aqui. Primeiro é preciso garantir que o desempenho seja bom o suficiente, e só depois avaliar todo o resto. O próprio autor menciona que “DuckDB é rápido”. Se não fosse, teria que entrar na competição de desempenho.
  • Este comentário não concorda com a ideia de que desempenho é secundário e argumenta que o prioritário é verificar se ele é bom o suficiente.
• Desempenho não é “subjetivo”, e sim “relativo”. Seu significado depende da tarefa que está sendo executada.
  • Este comentário explica a relatividade do desempenho e distingue isso da sensação de desempenho relacionada ao design de interface do usuário.
• Meu primeiro web app popular armazenava todo o estado em um dict do Python e despejava isso em disco a cada poucos minutos. A API era muito rápida, mas quando migrei para o MongoDB o desempenho nunca se recuperou. Ainda assim, hoje eu não escolheria pickledb para criar um site.
  • Este comentário compartilha uma experiência sobre o desempenho de um web app inicial e a queda de desempenho após a troca de banco de dados.
• Quis construir meu próprio sistema de banco de dados e compará-lo em benchmarks de desempenho com outros bancos populares (Postgres, Sqlite, MySQL, SQL Server).
  • Este comentário explica que não ficou satisfeito até que seu banco de dados fosse mais rápido em várias consultas, medindo até o tempo entre o usuário clicar no “botão de executar” e o resultado aparecer na tela.
• “É claro que há exceções a essa regra, e uma delas é que diferenças de arquitetura são difíceis de superar. Bancos de dados shared nothing estão em desvantagem em relação a shared disk, e o Redshift levou muitos anos para migrar em grande parte para uma arquitetura shared disk. Lakehouses que persistem metadados em object storage terão dificuldade com atualizações rápidas; isso é inerente ao modelo.”
  • Este comentário aponta problemas relacionados a diferenças de arquitetura de banco de dados e menciona que está procurando boa literatura sobre o tema.