O Dyego Souza do Carmo (http://www.escriba.com.br), não satisfeito em mandar a notícia sobre o lançamento do MySQL 4 estável (que 5 outros leitores também avisaram, obrigado!), enviou ainda o tutorial que você pode conferir clicando em DETALHES no final desta nota.
Eis a notícia: Sai como estável a versão 4.0 do banco de dados MySQL , agora adotando o handler InnoDB (http://www.innodb.com ) como padrão na distribuição , possibilitando assim que o mesmo possa ter Integridade referencial ( Incluindo CASCADE DELETE/UPDATE ) e transação já de fábrica ;). Disponível tambem para download a versão 4.1 do MySQL ( oficialmente anunciada como beta ) que traz 'derived tables', 'sub-querys' e suporte até 64GB de RAM na arquitetura I386.
MySQL - Como utilizar todo o poder da versão 4.x
O MySQL é um banco de dados conhecido e utilizado pelo mundo todo, agora em sua versão 4.x vem agregar alguns recursos que não eram disponíveis em sua versão estável ( 3.23 ) e que são de extrema importância, como transações , cache de querys mais utilizadas , integridade referencial e muito mais. Neste tutorial eu pretendo explicar como funciona e como habilitar transações e integridade referencial.
O MySQL trabalha de uma maneira diferente de outros bancos de dados , ele possue "Tipo de tabela" ou "Table handler" que é onde se esconde os segredos , para utilizar o total poder do MySQL 4.x voce deverá utilizar o "Tipo de tabela" InnoDB. O InnoDB oferece suporte a transação e a integridade referencial ( com CASCADE REFERS ) bem como suporte a "crash recovery" no caso de uma queda de luz ou falha fisica, a maneira de gravação e manipulação dos dados é semelhante ao Oracle , ele trabalha com um tablespace ou seja , um tamanho pre-defenido ( que pode ser alterado a qualquer momento ) de espaco em disco onde vão ser armazenados os dados e indices de suas tabelas, também possue um sistema transacional baseado em logs onde se por qualquer motivo o banco de dados for "interrompido" o mesmo recupera o ultimo estado íntegro do banco. O tablespace pode ser definido por um arquivo, ou uma partição diretamente , caso voce queira maior performance a partição é a melhor escolha pois o MySQL não vai depender do sistema de arquivos para agilizar a procura e gravação. A versão 4.x traz consigo suporte a UNION e também a MULTI-TABLE DELETE. Talvez uma das maiores implementações da versão 4.x seja o "Query Cache" que armazena o resultado de querys repetitivas, para portais no estilo do PHPNuke e PostNUKE isso é muito comum tendo em vista que quase nada se altera, e a informação é sempre a mesma, o "Query Cache" pode ser utilizado automaticamente ou somente naquelas querys que o programador decidir. Outra facilidade da versão 4.x é o "Embedded MySQL Server Library" , que nada mais é do que o MySQL linkado diretamente com a sua aplicação , ou seja... nao precisa instalar o banco de dados , ele vai dentro da sua aplicação. Ainda em fase beta , o "Embedded MySQL Server Library"* se demonstra estáel e funcional.
A transação proporcionada pelo subsistema InnoDB do MySQL 4.x é funcional desde casos pequenos a grandes transações onde muitos registros são alterados, com o suporte a integridade referencial bem maduro a dupla MySQL+InnoDB tem conquistado muitos fans adeptos de tal funcionalidade. O funcionamento é bastante simples, toda vez que o mysql inicia ele tambem inicia o InnoDB , o mesmo entra no ar fazendo uma verificação de integridade do banco de dados. Abaixo vemos uma situação que o "servidor foi desligado da tomada" e o InnoDB ao retornar fez as alterações necessárias para que o banco voltasse a posição que ele estava antes de sair repentinamente:
021111 11:53:08 InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 8 613915027
InnoDB: Doing recovery: scanned up to log sequence number 8 613945266
021111 11:53:08 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
021111 11:53:09 InnoDB: Flushing modified pages from the buffer pool...
021111 11:53:09 InnoDB: Started
/usr/local/mysql/libexec/mysqld: ready for connections
Como visto acima , o InnoDB detectou que algo teria acontecido de errado , verificou seus logs , constatou que o banco de dados estava em situação "irregular" , voltou as transações em aberto e iniciou normalmente. Esta funcionalidade de "crash recovery" faltava no mysql para consolidar ele como um banco de dados confiavel para operações de risco como por ex: transações financeiras , sistemas de controle de caixa, etc...
As aplicações que hoje funcionam com MyISAM ( Tipo de tabela oficial do MySQL ) podem ser convertidos para utilizar InnoDB com um simples "ALTER TABLE nome_da_tabela Type = InnoDB;" , mas para isso voce precisa habilitar o InnoDB no seu MySQL , siga os passos a seguir:
Vamos pelo inicio de tudo , baixe a versão 4.x no site http://www.mysql.com/downloads/mysql-pro-4.0.html , no site de download voce tera uma infinidade de plataformas , desde Linux até Windows , baixe e instale. Após a instalação edite o seu arquivo my.cfg e descomente as seguintes linhas:
innodb_data_file_path = ibdata1:300M
Este parâmetro serve para definir o tamanho do tablespace que o seu banco de dados vai utilizar , no caso trabalharemos com arquivos pelo fato de ser mais facil de explicar. O arquivo deve conter a seguinte sintaxe: nomedoarquivo:TAMANHO , no caso estamos criando um arquivo chamado ibdata1 que vai armazenar em si 300M para tabelaspace, no caso de precisar ampliar o tamanho do seu tablespace voce deve separar os arquivos por ; ex: ibdata1:300M;ibdata2:2G .
innodb_data_home_dir = c:\mysql\data
Este parâmetro serve para definir aonde vão ficar armazenados os arquivos que vão formar o tablespace , neste caso vamos armazenar dentro do diretório data do mysql
innodb_log_group_home_dir = c:\mysql\data\
innodb_log_arch_dir = c:\mysql\data\
Este parâmetro serve para definir aonde vão ficar armazenados os arquivos de logs que serão gerados para o sistema de transação.
set-variable = innodb_mirrored_log_groups=1
set-variable = innodb_log_files_in_group=3
Estes dois parâmetros definem se os logs do InnoDB vão ser duplicados e quantos arquivos de logs ele vai gerar respectivamente. Normalmente são valores padrão e não devem ser alterados
set-variable = innodb_log_file_size=30M
Este parâmetro define o tamanho do arquivo de LOG, este arquivo vai ser utilizado para realizar as transações do banco de dados , normalmente o tamanho dele é de 30M , se voce tiver transações mais robustas , aumente este valor.
set-variable = innodb_log_buffer_size=8M
Este parâmetro indica a quantidade de BUFFER DE MEMORIA que o InnoDB vai utilizar para gravar suas transações antes de recorrer aos arquivos fisicos, este valor varia de 1M até 8M , normalmente eu sugiro deixar em 8M , pois quanto menor for a dependencia do disco maior vai ser a velocidade.
innodb_flush_log_at_trx_commit=2
innodb_log_archive=0
Este dois parâmetros definem a maneira de gravação da transação no banco de dados.Normalmente são valores padrão e não devem ser alterados.
set-variable = innodb_buffer_pool_size=80M
Este parâmetro é um dos mais importantes , ele diz ao InnoDB o quanto ele pode utilizar de memoria para guardar indices , referencias e fazer cache de tabelas , quanto maior este valor melhor. Mas atenção, este valor nunca deve ultrapassar 80% da memoria fisica do computador , isso ocasiona lentidão extrema.
set-variable = innodb_additional_mem_pool_size=2M
Este parâmetro define o quanto o InnoDB vai poder utilizar de memoria para a estrutura interna do sistema , normalmente um valor bom é 2M , se caso o InnoDB detectar que precisa de mais memoria ele vai avisar pelo do log MySQL e alocara automaticamente.
set-variable = innodb_file_io_threads=4
Este parâmetro define quantas threads o InnoDB vai utilizar para ler/gravar simultaneamente, normalmente um valor muito bom é 4 , se vc estiver utilizando o MySQL para Windows incremente este valor para 9.
set-variable = innodb_lock_wait_timeout=50
Este parâmetro define o quanto o InnoDB vai esperar antes de voltar uma transação automaticamente, ex: Se vc iniciar uma transacao , alterar uma tabela e deixar parado e outra conexao tenta alterar o mesmo dado , o innodb espera 50 segundos a primeira transação se concretizar , se isso não ocorrer o mesmo volta a transação corrente para o primeiro estado. O valor de 50 segundos normalmente é suficiente.
Pronto , apos setar estes valores é só iniciar o mysql , o log vai conter linhas parecidas com estas:
InnoDB: The first specified data file c:\mysql\data\ibdata1 did not exist:
InnoDB: a new database to be created!
021113 9:16:18 InnoDB: Setting file c:\mysql\data\ibdata1 size to 300 MB
InnoDB: Database physically writes the file full: wait...
021113 9:16:38 InnoDB: Log file c:\mysql\data\ib_logfile0 did not exist: new to be created
InnoDB: Setting log file c:\mysql\data\ib_logfile0 size to 30 MB
InnoDB: Database physically writes the file full: wait...
021113 9:16:41 InnoDB: Log file c:\mysql\data\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file c:\mysql\data\ib_logfile1 size to 30 MB
InnoDB: Database physically writes the file full: wait...
021113 9:16:43 InnoDB: Log file c:\mysql\data\ib_logfile2 did not exist: new to be created
InnoDB: Setting log file c:\mysql\data\ib_logfile2 size to 30 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
021113 9:16:46 InnoDB: Started
mysqld: ready for connections
Pronto , você está com o innodb instalado e funcionando, agora já pode criar suas tabelas e usufruir de transações , integridade referencial e mais uma porção de coisas que esse "Table Handler" pode oferecer. Contudo lembre-se de especificar o tipo da tabela na hora da criação , ex: CREATE TABLE TESTE ( cod Integer(4) ) Type = InnoDB . Qualquer referência a mais pode ser obtida na pagina do MySQL ( http://www.mysql.com ) , na página do InnoDB ( http://www.innodb.com ) ou atravéz do meu email dyego@escriba.com.br. Agradeço pelo espaço cedido e espero ter exclarecido um grande mito no mundo do MySQL , a tal da "transação".
Postado por brain em 03 de abril de 2003, 11:02 AM
Até o mysql ter suporte à stored procedures e trigguers eu continuo falando : mysql é simples demais pra ser usado em algo sério.
isso sem falar em stored procedures, left/right join ser usar inner/on, etc ... é leve e rapido ? sim ! mas não passa de uma abstração simples do sistema de arquivos ... eu estou optando por usar xml ao inves do mysql quando preciso, pois ambos oferecem a mesma funcionalidade.
Discordo totalmente da sua opinião. O MySQL é muito bom sim para ser usado em algo sério, desde que NÃO haja a exigencia de recursos que ele não tem, como os que você citou. Quer exemplos? Sites web dinâmicos. Porque a grande maioria dos hostings pelo mundo usa MySQL? Porque os sites dinâmicos _em geral_ precisam muito mais de velocidade do que de recursos como stored procedures. Quer dizer que a grande maioria dos sites por aí não é "algo sério"??
Não seja radical... extremos não levam a nada...
E veja pelo lado bom: o MySQL continua evoluindo SEM perder o seu principal diferencial: a performance. A versão 4 já suporta transações. Quem sabe a versão 5 não terá o tão sonhado suporte à stored procedures?
É um exagero de sua parte comparar o MySQL à XML (que também é uma ótima tecnologia).
Não uso o MySQL exatamente por ele ainda não possuir algumas funções que desejo. Esta prometido SP para versão 5 e Views para a versão 5.1. Outro aspecto que levo em consideração é o fato do MySQL ser GPL apenas para projetos GPL, o que em certos casos pode não ser a melhor opção (Licenças como o PostgreSQL, Firebird e SAP DB são mais flexíveis).
De resto, fica sempre naquela de um tem uma vantagem aqui e outra tem uma ali. A escolha vai depender de cada caso e não pode ser generalizada.
Eu uso mysql a dois anos em uma aplicaçao empresarial de medio porte e estou muito satisfeito com a sua estabilidade e leveza , mas eu tive um trabalho maior para desenvolver a aplicaçao em php, pois tive que fazer muita coisa na mão.
hoje eu estou usando a dupla Postgresql/java para projetos grandes e mysql/php para projetos pequenos.
Postado por: Wilton Lazary em abril 4, 2003 01:23 AMSinceramente asdf ? pelo que voce escreveu vc realmente não tem a minima nocao do que está falando :) , aproposito... tenho uma base de dados de 90 milhoes de registro toda com integridade referencial e transacao rodando no maior cartório do brasil... mais de 400 mil titulos registrados por dia... o MySQL é bem rapido e o InnoDB dá a seguranca. Sério... comece a ler mais.... se interar mais do assunto... q tal programar comercialmente pra valer ? talvez assim voce comece a ter dimensão da besteira que voce falou.
Lembre-se , estou falando de MySQL+InnoDB e nao do MySQL comum... pois tendo em vista que o formato MyISAM do mysql não é o mais interessante em muitos casos, ainda mais quando é aplicação de massa crítica.
Acredito que você nunca leu nada a respeito do InnoDB , pois ele tem coisas que até hoje o PostgreSQL sonho só.... leia... www.innodb.com
Abraços,
Dyego, pelo visto você não aceita questionamentos de sua opinião do MySQL. Você acha que por ter um bom banco rodando, tem a atribuição de questionar seus colegas de profissão como se fosse um sabe-tudo. Parabens pela sua incrível capacidade, acho que todos gostariam de ser que nem vc....
Postado por: Marcelo em abril 4, 2003 10:41 AMMarcelo, não tenho dificuldade em aceitar criticas , desde que elas tenhao embasamento ténico e vivemciem a realidade , o que nao foi seguido por nosso amigo asdf , que em um impeto de "expressar sua opiniao" nao se deu ao trabalho de verificar se algumas limitações existem ou se jah foram superadas. Não sou sabe tudo... mas nao costumo criticar algo que eu não sei como funciona ou se eu "OUVI FALAR QUE EH RUIM". Já com sua critica voce mostra como um lado da moeda eh suficiente para voce... procure ler BEM o que eu disse no meu outro comentario... e veja se vc encontra em algum lugar eu dizendo que sou "sabe-tudo"...
Postado por: Dyego Souza do Carmo em abril 4, 2003 11:59 AMTá bom mestre...
Postado por: Marcelo em abril 4, 2003 06:05 PMDiego pelo link, observei que o seu sistema é o escriba. Sou sócio de uma empresa e dentre os sistemas que a empresa confecciona, existe um destinado à área de cartórios. Graças ao seu sistema minha empresa adquiri mais clientes "todos insatisfeitos c/ o sistema de sua empresa", que por questão de sigilo não vou revelar.
Em todos os artigos comparando banco de dados "utilizo o firebird", o mysql não é nem classificado ou considerado como banco de dados. Mas... a melhor vitória é adquirindo clientes de concorrentes...
Robert
Postado por: Robert em abril 6, 2003 08:04 PMBom, eu concorco que pra fazer sites de notícias e outras coisas menos exigentes que não usa transações, o Mysql é excelente. A discussão em torno do Mysql por oferecer velocidade incomparável a outros bancos de dados é relativa, vem sempre a discussão velocidade vs segurança, por fim eu prefiro a segurança e a velocidade desde que não seja impraticável é mensurável que isso também seja importante.
Das opções Open Source nesta área, tem-se evoluido muito os banco de dados, como Firebird que é um Fork do InterBase, o PostGresql e agora recentemente o poderoso SAPDB, que apesar de não ser simples de instalar e configurar, oferece excelentes ferramentas e recursos. Já tem comprovação certa de que rodas em grandes centros empresariais.
Eu torço pro Mysql evoluir mais e mais para chegar ao mesmo patamar que outros databases já chegaram, é por isso que é open source, sempre evoluindo, vamos esperar mais surpresas nestas áreas, é o que faltava para os desenvolvedores que não dispunham de grandes recursos para bancar o custo de um Oracle ou Db2 da IBM, agora temos alternativas que logo irão igualar ou superar estes databases tão poderosos e conhecidos no mundo empresarial.
Postado por: CarlosMS em abril 7, 2003 11:48 AM
O Arquivo Histórico do BR-Linux.org mantém no ar (sem alteração, exceto quanto à formatação) notícias, artigos e outros textos publicados originalmente no site na segunda metade da década de 1990 e na primeira década do século XXI, que contam parte considerável a história do Linux e do Open Source no Brasil. Exceto quando indicado em contrário, a autoria dos textos é de Augusto Campos, e os termos de uso podem ser consultados na capa do BR-Linux.org. Considerando seu caráter histórico, é provável que boa parte dos links estejam quebrados, e que as informações deste texto estejam desatualizadas.