Cache em Queries do MySQL
Marcus Maciel (marcus at underlinux.com.br) enviou este link e acrescentou uma introdução em forma de diálogo: 'Chefe: Nosso novo website esta se arrastando!! Como isso pode estar acontecendo, se nos temos servidores novinhos - qual é o problema? Voce: Bem, nossos servidores estao blza - é o database q estah estrangulado. Chefe: O queeee? Voce me disse que o MySQL era rapido, que nos nao precisavamos d um Oracle, e agora voce diz que ele nao aguenta mais!! Como? Voce: Bem, nossos servidores estao se comportando bem, tao bem que eles estao passando um monte de queries ao mesmo tempo. Mas, soh temos um database, e temos um monte de servidores... Chefe: É muito tarde pra comprar um Oracle agora - O que vamos fazer?' Se voce tem este problema este artigo pode ser a solucao.
(postado por Augusto Campos)
Comentários dos leitores
Comentário de hamacker
01/04/05 12:47 - usuário registrado #168
Nos banco de dados, o cache n: Nos banco de dados, o cache não serve para guardar dados do database para a memória, eventualmente até pode fazer isso, pois arvores btrieve podem requerer trazer do disco páginas de dados inteiras com registros que foram pertinentes à pesquisa juntamente com aqueles que não foram pesquisados.
Mas o artigo em questão fala do cache apenas como consultar dados que foram repetidos em pesquisas anteriores, se o cache do MySQL for apenas isso, então tá anos luz de outros RDBMS.
O cache de banco de dados serve para guardar recursos que cujo preço de se fazer de novo é alto, é o caso por exemplo de otimização de queries(prepare), calcular que índices (com expressões ou não) serão usados num select complexo e determinar todos os nodes de cada join tem um preço, esse tempo de calculo é que deve ser guardado. Esse é apenas um exemplo do que é feito com o cache, que obviamente não é o único uso, cada banco de dados calcula o preço de uma operação, se uma operação é cara então o próprio banco determina o uso ou não do cache. O Tunning manual pode até aprimorar esse recurso, como num famoso banco de dados que termos por aí que por exemplo pode ser configurado para que se uma pesquisa abranger 75% da seletividade duma tabela então que carregue logo os 100% para a memória para não perder tempo em separar os outros 25%.
Se o que o MySQL faz é apenas guardar os dados repetidos (como o artigo dá a entender), ele duplica o esforço do cache de disco que serve para praticamente a mesma coisa.
Tenho o MySQL e ele não é ruim como repositório de dados, nada além disso.
Mas o artigo em questão fala do cache apenas como consultar dados que foram repetidos em pesquisas anteriores, se o cache do MySQL for apenas isso, então tá anos luz de outros RDBMS.
O cache de banco de dados serve para guardar recursos que cujo preço de se fazer de novo é alto, é o caso por exemplo de otimização de queries(prepare), calcular que índices (com expressões ou não) serão usados num select complexo e determinar todos os nodes de cada join tem um preço, esse tempo de calculo é que deve ser guardado. Esse é apenas um exemplo do que é feito com o cache, que obviamente não é o único uso, cada banco de dados calcula o preço de uma operação, se uma operação é cara então o próprio banco determina o uso ou não do cache. O Tunning manual pode até aprimorar esse recurso, como num famoso banco de dados que termos por aí que por exemplo pode ser configurado para que se uma pesquisa abranger 75% da seletividade duma tabela então que carregue logo os 100% para a memória para não perder tempo em separar os outros 25%.
Se o que o MySQL faz é apenas guardar os dados repetidos (como o artigo dá a entender), ele duplica o esforço do cache de disco que serve para praticamente a mesma coisa.
Tenho o MySQL e ele não é ruim como repositório de dados, nada além disso.
Comentário de dyego
01/04/05 13:37 - usuário registrado #225
sistema de cache do mysql: Até a versão 4.0 se chama Query Cache... o proprio nome já diz... nada a mais do que um cache dos resultados das querys executadas ( até um limite eh claro )
A versao 4.1 ou superior já armazena a otimização das querys (PREPARE) , e o JDBC 3.1 já explora essa funcionalidade com aplicativos J2EE, a versao 5.0 pretende fazer cache das stored procedures ( que ainda estao muito imaturas )
O MySQL tem avançado muito... hoje já conta com muitas coisas que a 3 anos não eram nem sonhadas para ele... sinceramente para banco medianos ( 58 a 80 milhoes de registros ) eu acho ele uma boa opção pois tem recursos suficientes para suprir 70% das aplicações deste porte...
é claro que nao vamos comparar laranjas com bananas... dizer que um banco é bom ou ruim pela quantidade de registros que ele vai armazenar é um tanto quanto imaturo... mas.... temos q generalizar as vezes... mas o certo é escolher o banco devido aos recursos e a tecnologia... por ex: se vc for usar J2EE vc nao tem prq optar pelo Oracle com a tradicional muleta "Mas tem stored procedures"... é tudo uma questao de visão...
e sinceramente isso não é coisa para ser feita neste post... estamos somente comentando o artigo...
----
Dyego Souza Dantas Leal
A versao 4.1 ou superior já armazena a otimização das querys (PREPARE) , e o JDBC 3.1 já explora essa funcionalidade com aplicativos J2EE, a versao 5.0 pretende fazer cache das stored procedures ( que ainda estao muito imaturas )
O MySQL tem avançado muito... hoje já conta com muitas coisas que a 3 anos não eram nem sonhadas para ele... sinceramente para banco medianos ( 58 a 80 milhoes de registros ) eu acho ele uma boa opção pois tem recursos suficientes para suprir 70% das aplicações deste porte...
é claro que nao vamos comparar laranjas com bananas... dizer que um banco é bom ou ruim pela quantidade de registros que ele vai armazenar é um tanto quanto imaturo... mas.... temos q generalizar as vezes... mas o certo é escolher o banco devido aos recursos e a tecnologia... por ex: se vc for usar J2EE vc nao tem prq optar pelo Oracle com a tradicional muleta "Mas tem stored procedures"... é tudo uma questao de visão...
e sinceramente isso não é coisa para ser feita neste post... estamos somente comentando o artigo...
----
Dyego Souza Dantas Leal
Comentário de sdvidal
01/04/05 18:46 - usuário registrado #39
exagerado: trabalho com oracle desde a versão 7 (já tem disponível o 10g) e opino que a frase :
Mas o artigo em questão fala do cache apenas como consultar dados que foram repetidos em pesquisas anteriores, se o cache do MySQL for apenas isso, então tá anos luz de outros RDBMS.
está exagerada, defendendo o Oracle, DB2, Sybase, etc.
Digo isto acredito que todos os RDBMS comerciais estejam equiparados com relação à funcionalidades; com relação aos abertos, tenho acompanhado mais o Postgresql e penso que está no mesmo nível - apenas recentemente o MySQL incorporou storage procedure e outros.
saudações.
Mas o artigo em questão fala do cache apenas como consultar dados que foram repetidos em pesquisas anteriores, se o cache do MySQL for apenas isso, então tá anos luz de outros RDBMS.
está exagerada, defendendo o Oracle, DB2, Sybase, etc.
Digo isto acredito que todos os RDBMS comerciais estejam equiparados com relação à funcionalidades; com relação aos abertos, tenho acompanhado mais o Postgresql e penso que está no mesmo nível - apenas recentemente o MySQL incorporou storage procedure e outros.
saudações.
Aproveitando a oportunidade , no 6 Forum Internacional do Software livre vai ter uma palestra que vai abordar o MySQl 4.x e 5.0 , novidades , casos de uso, numeros e recursos... aos interessados... nos vemos em junho ;)
----
Dyego Souza Dantas Leal