Fórum SqlServer x Firebird x MySql #367509
04/01/2009
0
Pessoal. Estou fazendo uns testes para ver qual o banco de dados MAIS RÁPIDO 1. localmente e 2. remotamente via internet.
Pessoal, fiz o segunte teste numa mesma máquina.
Fiz uma aplicaçãozinha(D2007) onde mandei popular (inserts) uma tabela com 3 campos.
O resultado foi o segunite entre esses 3 SGBDs.
Banco : SQLServer
Acesso : Local
Registros : 100.000
Engine : ADO
Tempo : 4:51 min
Banco : SQLServer
Acesso : Remoto pela internet
Registros : 2.000
Engine : ADO
Tempo : 11:15 min
Banco : SQLServer
Acesso : Local
Registros : 100.000
Engine : DBX
Tempo : 3:18 min
Banco : SQLServer
Acesso : Remoto pela internet
Registros : 2.000
Engine : DBX
Tempo : 6:18 min
_______________________________
Banco : Firebird 2.0
Acesso : Local
Registros : 100.000
Engine : DBX c/ driver da TBOSystems
Tempo : 00:55 min :shock:
Banco : Firebird 2.0
Acesso : Remoto pela internet
Registros : 2.000
Engine : DBX c/ driver da TBOSystems
Tempo : 20:21 min :(
_______________________________
Banco : MySql 5.1
Acesso : Local
Registros : 100.000
Engine : DBX
Tempo : 50:00 min
Banco : MySql 5.1
Acesso : Local
Registros : 2.000
Engine : DBX
Tempo : 01:05 min :shock:
CONCLUSÃO (pelos testes acima):
O Firebird é mais rápido localmente.
O Mysql é mais rápido remotamente pela internet.
A rotina usada foi a seguinte :
Coloquei num form um SQLConnection, SQLQuery, tres Edits e um button.
(para uso do ADO, troquei os componentes de conexão.)
procedure TForm1.Button1Click(Sender: TObject);
var
i:integer;
begin
Edit1.Text := timeToStr(now);
edit1.Refresh;
for I := 1 to 100000 do
begin
SQLQuery1.Sql.Clear;
SQLQuery1.SQL.Add(´Insert into teste (nome,idade) values (´+#39+´Teste de inserção de dados pelo comando insert e um componente query´+intToStr(i)+39+´,123456)´);
SQLQuery1.ExecSQL;
Edit3.Text := intToStr(i);
Edit3.Refresh;
end;
Edit2.Text := timeToStr(now);
end;
AGORA AS QUESTÕES:
Pq o Firebird é tão rápido localmente, mas qdo acessando um server pela internet é mto mais lento que o MySql?
Pq o MySql é tão lento localmente e mais rápido que todos remotamente?
Alguma sugestão?
Pessoal, fiz o segunte teste numa mesma máquina.
Fiz uma aplicaçãozinha(D2007) onde mandei popular (inserts) uma tabela com 3 campos.
O resultado foi o segunite entre esses 3 SGBDs.
Banco : SQLServer
Acesso : Local
Registros : 100.000
Engine : ADO
Tempo : 4:51 min
Banco : SQLServer
Acesso : Remoto pela internet
Registros : 2.000
Engine : ADO
Tempo : 11:15 min
Banco : SQLServer
Acesso : Local
Registros : 100.000
Engine : DBX
Tempo : 3:18 min
Banco : SQLServer
Acesso : Remoto pela internet
Registros : 2.000
Engine : DBX
Tempo : 6:18 min
_______________________________
Banco : Firebird 2.0
Acesso : Local
Registros : 100.000
Engine : DBX c/ driver da TBOSystems
Tempo : 00:55 min :shock:
Banco : Firebird 2.0
Acesso : Remoto pela internet
Registros : 2.000
Engine : DBX c/ driver da TBOSystems
Tempo : 20:21 min :(
_______________________________
Banco : MySql 5.1
Acesso : Local
Registros : 100.000
Engine : DBX
Tempo : 50:00 min
Banco : MySql 5.1
Acesso : Local
Registros : 2.000
Engine : DBX
Tempo : 01:05 min :shock:
CONCLUSÃO (pelos testes acima):
O Firebird é mais rápido localmente.
O Mysql é mais rápido remotamente pela internet.
A rotina usada foi a seguinte :
Coloquei num form um SQLConnection, SQLQuery, tres Edits e um button.
(para uso do ADO, troquei os componentes de conexão.)
procedure TForm1.Button1Click(Sender: TObject);
var
i:integer;
begin
Edit1.Text := timeToStr(now);
edit1.Refresh;
for I := 1 to 100000 do
begin
SQLQuery1.Sql.Clear;
SQLQuery1.SQL.Add(´Insert into teste (nome,idade) values (´+#39+´Teste de inserção de dados pelo comando insert e um componente query´+intToStr(i)+39+´,123456)´);
SQLQuery1.ExecSQL;
Edit3.Text := intToStr(i);
Edit3.Refresh;
end;
Edit2.Text := timeToStr(now);
end;
AGORA AS QUESTÕES:
Pq o Firebird é tão rápido localmente, mas qdo acessando um server pela internet é mto mais lento que o MySql?
Pq o MySql é tão lento localmente e mais rápido que todos remotamente?
Alguma sugestão?
Bressa
Curtir tópico
+ 0
Responder
Posts
04/01/2009
Dbergkamps10
Olá.
Meu ´voto´ vai pro MySQL Versão 4.0 ou 4.1.
A perda localmente é mto pequena.
Mto bom ele. Recomendo 100¬
Att
Dalton
Meu ´voto´ vai pro MySQL Versão 4.0 ou 4.1.
A perda localmente é mto pequena.
Mto bom ele. Recomendo 100¬
Att
Dalton
Responder
Gostei + 0
04/01/2009
Dbergkamps10
Olá.
Meu ´voto´ vai pro MySQL Versão 4.0 ou 4.1.
A perda localmente é mto pequena.
Mto bom ele. Recomendo 100¬
Att
Dalton
Meu ´voto´ vai pro MySQL Versão 4.0 ou 4.1.
A perda localmente é mto pequena.
Mto bom ele. Recomendo 100¬
Att
Dalton
Responder
Gostei + 0
05/01/2009
Paulo
Não sou especialista em banco de dados, mas esse tipo de teste está fora de cogitação, quanto à escolha de um banco. Se colocasse aí um ORACLE talvez tivesse resultado piorr que o MySql e nem por isso o MySql seria melhor que o ORACLE. Como seria usando Joins(Com tabelas Indexadas e não Indexadas). Imagine uma pesquisa em tabelas com mais de 100.000.000 de registros. Qual a diferença em usar LEFT´s e INNER´s. Enfim, tem muita coisa para se comparar, além de Insert. Eu fico com o MsSql Sever entre os citados, apesar que no seu teste ele ficou em terceiro lugar. Banco é muito mais que velocidade. Não estou aqui dizendo que não valeu seu teste, mas para se escolher um banco, é muito mais que isso. Exemplo:
O ORACLE pra mim é a maravilha dos DB´s, porem se fosse construir um DW e se tivesse grana optaria pelo TERADATA e não pelo ORACLE, pois o TERADATA foi projetado especialmente para DW e nada mais. Se tivesse um software on demand com grande fluxo de informação, MF e etc..., usaria um DB2 e não ORACLE, então deve-se escolher o DB se acordo com aquilo que será trabalhado por ele e não somente pela velocidade.
O ORACLE pra mim é a maravilha dos DB´s, porem se fosse construir um DW e se tivesse grana optaria pelo TERADATA e não pelo ORACLE, pois o TERADATA foi projetado especialmente para DW e nada mais. Se tivesse um software on demand com grande fluxo de informação, MF e etc..., usaria um DB2 e não ORACLE, então deve-se escolher o DB se acordo com aquilo que será trabalhado por ele e não somente pela velocidade.
Responder
Gostei + 0
05/01/2009
Builder
quinel, seus testes são interessantes, mas afirmar que banco A ou B é mais rápido é questionável. Por exemplo:
- Teria que ter utilizado o mesmo engine para os testes (dbexpress por exemplo), mudando somente o driver (e ainda assim o driver seria questionado se foi bem escrito/otimizado).
- O servidor deveria estar dedicado exclusivamente para os testes, sem nenhum outra conexão/atividade que gere trabalho adicional que possa interferir no desempenho/resultados (você incluindo e outro usuário transferindo/gravando 60 gb de dados no servidor).
- O mesmo vale para a conexão Web, com exclusividade total na hora dos testes (imagina você testando e outro usuário saturando a banda com um download cavalar, antivírus se atualizando, sistema operacional se atualizando...).
- Não citou detalhes do servidor (sistema operacional, processador, memória, tipo do hd, ...), detalhes da estação, detalhes da rede (switch, velocidade da conexão, ...)
- Ainda sobre a questão do engine para ressaltar a importância, uso o utilitário Interbase DataPump para ler registros de arquivos xbase e incluir no Firebird 2.1.1 leve em torno de 10 minutos para importar quase um milhão de registros de tabelas que tem de 5 a 144 campos, dos mais variados tipos e tamanhos.
Foi excelente a sua iniciativa de fazer os testes, mas falta elaborar melhor os critérios e recursos/ferramentas utilizadas afim de manter equilibrado os testes para cada banco.
E mesmo assim, no final, vamos ter que concordar com o Paulo, pois vai descobrir que o resultado será válido somente para aplicações muito similares aos testes realizados. Para outras situações com outros tipos de dados, store procedures, triggers, recursos se segurança e volumes de dados com vários gb/tera os resultados podem ser bem diferentes.
- Teria que ter utilizado o mesmo engine para os testes (dbexpress por exemplo), mudando somente o driver (e ainda assim o driver seria questionado se foi bem escrito/otimizado).
- O servidor deveria estar dedicado exclusivamente para os testes, sem nenhum outra conexão/atividade que gere trabalho adicional que possa interferir no desempenho/resultados (você incluindo e outro usuário transferindo/gravando 60 gb de dados no servidor).
- O mesmo vale para a conexão Web, com exclusividade total na hora dos testes (imagina você testando e outro usuário saturando a banda com um download cavalar, antivírus se atualizando, sistema operacional se atualizando...).
- Não citou detalhes do servidor (sistema operacional, processador, memória, tipo do hd, ...), detalhes da estação, detalhes da rede (switch, velocidade da conexão, ...)
- Ainda sobre a questão do engine para ressaltar a importância, uso o utilitário Interbase DataPump para ler registros de arquivos xbase e incluir no Firebird 2.1.1 leve em torno de 10 minutos para importar quase um milhão de registros de tabelas que tem de 5 a 144 campos, dos mais variados tipos e tamanhos.
Foi excelente a sua iniciativa de fazer os testes, mas falta elaborar melhor os critérios e recursos/ferramentas utilizadas afim de manter equilibrado os testes para cada banco.
E mesmo assim, no final, vamos ter que concordar com o Paulo, pois vai descobrir que o resultado será válido somente para aplicações muito similares aos testes realizados. Para outras situações com outros tipos de dados, store procedures, triggers, recursos se segurança e volumes de dados com vários gb/tera os resultados podem ser bem diferentes.
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)