Algumas dicas se vai fazer testes: 1) Vai ter suporte a transações? O MySQL usa MyISAM como padrão, que não tem suporte a transações. Se for usar isso no MySQL, use unlogged tables no PostgreSQL para ter uma comparação mais justa. Não é a mesma coisa, mas é mais justo. 2) Crie uma massa de dados com tabelas com pelo menos 4x o tamanho da RAM disponível no servidor. 3) Use um servidor dedicado, se for usar windows, deixe ele descansar uns 30 minutos após subir o SGDB e inicie o teste. 4) Zere o cache da memória antes de cada bateria de testes. Se possível reinicie o SGDB também. 5) Refaça cada teste 3x para ver se o número é consistente. 6) Cada teste deve rodar por pelo menos uns 30 minutos, para o efeito do checkpoint ser levado em consideração. 60 minutos é o recomendado. 7) Faça um tuning no SO e no SGDB para não usar as configurações padrão. Senão fica difícil de comparar, uma vez que você não está utilizando o melhor de cada um. 8) Faça um crash teste no meio também: no meio do teste puxe o servidor da tomada e veja se a base sobreviveu... não adianta nada ser velocidade e não ter segurança, né? 9) Atualize as estatísticas das tabelas antes de cada teste.... isso parece óbvio, mas tem muita gente que esquece desse detalhe e trabalha com planos de execução terríveis. 10) Não adianta testar apenas uma ou outra consulta e ver quanto tempo leva, tem de simular uma operação real, com volume de dados factíveis e concorrência também. Um dos maiores desafios de uma aplicação é lidar com alta concorrência, com centenas de pessoas querendo transacionar (INSERT, UPDATE, DELETE) nas mesmas tabelas ao mesmo tempo.
11 Em 31 de março de 2014 09:38, Eduardo Alexandre <[email protected]>escreveu: > > Em 31 de março de 2014 09:30, Guimarães Faria Corcete DUTRA, Leandro < > [email protected]> escreveu: > > 2014-03-30 18:16 GMT-03:00 Guimarães Faria Corcete DUTRA, Leandro >> <[email protected]>: >> > 2014-03-30 13:16 GMT-03:00 Eduardo Alexandre <[email protected]>: >> >> >> >> Estou precisando muito de comparação e, de preferência benchmarks >> sérios >> >> entre MySQL e PostgreSQL para definição de qual utilizar para um >> projeto. >> > >> > Difícil, porque o MySQL não é sério. É mais uma brincadeira que saiu >> > de controle. Nem roda código ISO SQL, então as comparações >> > necessariamente já têm de ser ajustadas para favorecer o MySQL. >> >> Não fiquei satisfeito com minha própria resposta, então vai um >> complemento. >> >> Comparativos sérios são difíceis, porque SGBDs são extremamente >> complexos e seus usos, muito variados. Os comparativos publicados >> geralmente são, portanto e naturalmente, geralmente incompletos. >> >> Quanto a desempenho, há alguns comparativos padronizados, mas há >> várias ressalvas. Primeiro, organizações como a Oracle (atual >> proprietária do MySQL) costumam probir a divulgação; segundo, os >> comparativos padronizados costumam colocar exigências bem oneroras, e >> aí o povo do PostgreSQL costuma achar que não vale muito a pena, até >> porque quem sabe pouco costuma não entender esses testes, suas >> condições e resultados, e quem sabe mais costuma olhar outras maneiras >> de comparar; terceiro, um comparativo padronizado costuma ser >> irrelevante para as situações específicas. >> >> O certo seria uma comparação bem focada na tua situação. Mas isso >> exigiria que já houvesse código aplicativo, uma massa de dados de >> testes representativa (mesmo que artificialmente gerada) e código de >> testes para carga. Além de ser um custo razoável para investir na >> decisão, há o problema de que o MySQL é tão ruim em termos de >> linguagem ISO SQL que ou dará mais trabalho que o razoável para criar >> o código aplicativo, ou acabará conduzindo a criar programas num >> mínimo denominador comum, um subconjunto do ISO SQL que favorece o >> MySQL ao deixar de explorar as capacidades de um SGBD robusto como o >> PostgreSQL. > > > > Olá, > > Agradeço pelos comentários e posso dizer que concordo com sua opinião. > No final de semana pensei a respeito disso e estou pretendendo fazer > aproximadamente o que mencionou: criar uma massa de dados de teste > representativa para a necessidade. > Claro que não é possível cobrir e garantir sem sombra de dúvida qual é o > melhor mas, dá para se ter uma ideia de como é o comportamento e tempo de > resposta de ambos em uma determinada situação. > Se tiver novidades, aviso na lista. > > > Abraços, > ___________________ > Eduardo Alexandre > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > -- Atenciosamente, Fábio Telles Rodriguez blog: http:// <http://www.midstorm.org/~telles/>s<http://tellesr.wordpress.com/> avepoint.blog.br e-mail / gtalk / MSN: [email protected] Skype: fabio_telles Timbira - A empresa brasileira de Postgres http://www.timbira.com.br
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
