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".
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.
Você move o aplicativo para o novo banco de dados.
Você faz as mesmas medidas.
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.