Bancos de dados de benchmarking


14

Vejo muitas discussões sobre o desempenho do db 'x' ou que a mudança de 'x' para 'y' melhorou o desempenho do site.

Ainda estou para ver o benchmarking adequado que funciona em diferentes tipos de bancos de dados.

  1. É possível escrever uma referência significativa que possa ser usada em vários tipos de banco de dados, como Relacional, Orientado a Documentos, etc.

  2. Como você projetaria essa referência?


Como exemplo do nível de detalhe que eu precisaria para levar a sério qualquer referência de banco de dados, dê uma olhada neste artigo , da Yahoo Research. Na verdade, não tenho uma boa resposta para você, além de suspeitar que os compromissos e as assimetrias da PAC sejam a principal razão pela qual a comparação de bancos de dados é tão difícil.
yannis

Respostas:


19

Resposta curta

Sim , você pode escrever uma referência significativa de um caso estudado, se o fizer com cuidado, e entender que, se for relevante para o caso específico, pode não ser para outros casos. Isso é igualmente verdade ao comparar os bancos de dados do mesmo tipo (banco de dados relacional versus outro banco de dados relacional) ou os bancos de dados de tipos diferentes.

Não , você não pode escrever um benchmark que prove magicamente que um banco de dados específico é muito melhor do que outro em todos os casos, para cada aplicativo.

Resposta longa

Definitivamente, é possível dizer que "mudar de um banco de dados para outro melhorou o desempenho do site".

  1. Você mede o desempenho do banco de dados anterior por meio de estatísticas ou estatísticas de tempo de execução, reunindo informações suficientes sobre as consultas e com que rapidez elas são.

  2. Você move o aplicativo para o novo banco de dados.

  3. Você faz as mesmas medidas.

  4. Você compara.

Por exemplo, se a lista completa de 3 182 432 produtos carregados em 2.834 s. em um banco de dados antigo e carrega em 0,920 s. em um novo banco de dados, já que nos dois casos o aplicativo possui um cache vazio, é uma vitória: o novo banco de dados melhorou o desempenho do site em relação a essa consulta.

Agora, como qualquer métrica de desempenho, é tendenciosa:

  • Concordado, a nova consulta é mais rápida. Mas espere, seu DBA não sabia como usar o banco de dados que você tinha antes , portanto, a consulta que carrega todos os produtos não é otimizada . Se você reescrever dessa maneira, poderá carregar esses produtos em 0,855 s. em vez de 2.834.

  • Ok, você tem um resultado melhor. Mas você não acha injusto comparar um banco de dados com dados atualizados, apenas liberados para um banco de dados de 10 anos para o qual o último plano de manutenção foi executado três anos atrás? A propósito, você não acha que deveria ter atualizado o produto de banco de dados pelo menos uma vez durante os últimos quatro anos?

  • Algumas consultas são mais rápidas. Alguns são mais lentos. Como você calcula o resultado médio para saber que você obteve desempenho geral ao passar para o novo banco de dados? Ok, o tempo de carregamento de todos os 3 182 432 produtos é mais rápido. Mas isso importa, enquanto a consulta é executada no site apenas em casos raros, quando um administrador está executando alguma tarefa específica que ele executou apenas duas vezes nos últimos dez anos? Por outro lado, a execução de todas as consultas na página inicial para um novo usuário desperdiça 0,281 s. com o novo banco de dados, quando eram 0,207 s. com o banco de dados antigo. Esse resultado é muito mais importante, especialmente porque essas consultas não podem ser armazenadas em cache por um longo período de tempo e são executadas dezenas de milhares de vezes por dia.

  • Ambos os bancos de dados devem ser testados nos mesmos servidores , mesmo hardware, mesma estrutura. Por exemplo, você não pode testar um banco de dados em um único disco rígido e o outro em um RAID1 de dois SSDs. Ao migrar um projeto grande para um novo banco de dados, há chances de você apenas hospedar o novo banco de dados em centenas de outros servidores em rack recém-implantados, quando o banco de dados anterior ainda permanecerá nas máquinas anteriores.

Para resumir, você pode comparar as consultas de banco de dados de um aplicativo e obter métricas precisas . Mas então, você deve dar um significado aos números. Nesse estado, é tentador dizer que você ganhou o desempenho do site: caso contrário, a gerência ficaria brava ao saber que você gastou milhares de dólares e meses de trabalho apenas para tornar as coisas mais lentas.

O erro mais terrível é tirar essas conclusões dos benchmarks e concluir alguma estupidez como "Microsoft SQL Server é três vezes mais rápido que o Oracle": dizer isso é como dizer que "Java é melhor que PHP". Defina melhor. Melhor em que casos? Para que tipo de aplicativos? Para qual equipe de desenvolvedores?

Quanto mais você interpreta e generaliza, mais a coisa se torna irrelevante e sem sentido.

A consulta que select [...]você pode encontrar na revisão # 832 do arquivo ProductFactory.cs, linha 117, é executada em 0,5 s. com o novo banco de dados quando testado nas condições especificadas no requisito não-funcional do anexo M, caso 3. Isso permite passar o requisito não-funcional 527 (na página 80, revisão 9). O mesmo requisito não foi satisfeito com o banco de dados anterior, quando os resultados do teste estavam na faixa de 0,9 a 1,3 s. nas mesmas condições.

é significativo para um desenvolvedor e preciso o suficiente para saber o que foi testado, como e quais foram os resultados. Isso responde à sua pergunta número 2.

Infelizmente, isso não faz sentido para a gerência. Em vez de:

A migração de nosso produto do MySQL para a versão mais recente do Microsoft SQL Server melhorou em cinco o desempenho geral do produto, reduzindo ao mesmo tempo os custos em dois e a pegada ambiental em três. Acreditamos que a migração de todos os nossos aplicativos para o Microsoft SQL Server no próximo ano trará resultados ainda melhores e aumentará nossa competitividade no mercado.

é uma pura tagarelice de marketing e, tecnicamente, não significa nada, mas surpreendentemente tem um valor para os departamentos de gerenciamento e marketing.

Finalmente, podemos comparar diferentes tipos de bancos de dados? Eu diria que é totalmente possível. Digamos que eu tenha um site que hospede fotos grandes. Essas fotos são armazenadas no varbinary(max)Microsoft SQL Server 2005 (então não posso usar filestream). Estou preocupado com o desempenho ao carregar essas fotos, por isso decido armazenar as fotos como arquivos, usando o sistema de arquivos como meu novo banco de dados. Primeiro, esses arquivos são armazenados na mesma máquina que o banco de dados. Eu perfil a nova solução e obtenho o resultado que mostra que, no meu caso, os arquivos são carregados 4% mais rápido no sistema de arquivos do que no Microsoft SQL Server. A referência é muito clara. Agora, posso pensar em implantar um servidor dedicado otimizado para armazenamento direto de arquivos, em vez de usar o servidor otimizado para o Microsoft SQL Server.


2
  1. Com todo o dinheiro em jogo com as principais empresas de banco de dados e o grande grupo de desenvolvedores em aplicativos de banco de dados de código aberto, se houvesse uma maneira de fazê-lo, eles já teriam descoberto (e divulgaram os resultados em toda a Internet). )

  2. Eu não. Em vez disso, crie benchmarks específicos para necessidades e ambientes específicos.

Em algum momento, a quantidade de dinheiro disponível e a experiência do designer em um banco de dados específico podem determinar as limitações mais do que qualquer coisa. Um bom dba Oracle irá executar a maioria dos desenvolvedores juniores, independentemente da plataforma escolhida.


1

Não, as diferenças entre elas são de tal ordem que qualquer referência seria tendenciosa.

Dito isso, desenvolver um site como o Computer Language Benchmarks Game , que inclui uma ampla gama de testes e facilita a comparação de testes (testes específicos de idioma para idioma ou compostos de vários idiomas), seria de algum benefício (em menos aos meus olhos), especialmente se ele foi configurado para que a comunidade pudesse enviar soluções e melhorar as deficiências em esquemas ou consultas.

No caso do site de benchmark do banco de dados, em vez de implementar algoritmos (como no caso do tiroteio de idiomas), os testes podem consistir em dados brutos que precisam ser armazenados e recuperados de acordo com restrições específicas. Por exemplo, talvez haja um conjunto de dados brutos que contenham informações representando um esquema simples representativo do que uma biblioteca comunitária pode usar para rastrear clientes e livros. Cada banco de dados deve armazenar todos os 1 milhão de registros e recuperar alguns subconjuntos de dados que atendem às restrições. Além disso, também pode haver um conjunto de dados que represente uma estrutura / relacionamento muito simples (talvez um sistema de comentários normalmente usado para sites como ESPN etc.) que contenha 100 milhões de registros e que tenha seu próprio conjunto de consultas que devem ser executadas . Etc.

Testar bancos de dados em um amplo conjunto de dados (variando de relacionamentos complexos a simples, pequenos conjuntos a enormes) pode ser muito útil, pois você poderá pelo menos ver tendências gerais de dados que possuem qualidades semelhantes ao projeto que você está atualmente avaliando.


0

Gostaria de acrescentar mais algumas razões, porque você não pode comparar todos os tipos de bancos de dados.

  1. Existem duas direções principais para os sistemas de banco de dados: OLAP e OLTP (veja comparação ).

  2. Como você disse, também existem sistemas de banco de dados relacionais e orientados a documentos. Enquanto o RDBS segue rigorosamente o princípio do ACID , na maioria dos DBS orientados a documentos, você pode decidir que dados fracos são suficientes para o seu aplicativo. Isso facilita o bloqueio e a programação.

Em resumo: você não argumentaria que um Lamborghini é o melhor carro do mundo . Pense no volume do porta-malas, no número de assentos ou na quilometragem.

Como uma observação lateral: Aqui está uma referência para os sistemas de bancos de dados OLTP.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.