Nas últimas semanas eu venho falando muito do PostgreSQL, um banco de dados que eu adoro! Mas o combinado é que conversaríamos sobre os três bancos de dados open source e relacionais do Azure (PostgreSQL, MySQL e MariaDB). Por isso, hoje é dia de falar sobre o MySQL.
Todas as vezes que eu o utilizei foi com ressalvas, mas preciso confessar que é um banco de dados extremamente poderoso e com uma história fantástica!
Antes que alguém me questione, ou faça uma piada: ele pode ser usado sem o PHP. Aliás, acho esse casamento perfeito, e me arrisco a dizer que o MySQL faz parte do “ecossistema do PHP”. Acreditem em mim – ele é muito poderoso e seu uso vai muito além de páginas web.
Um pouco da história
A MySQL AB (empresa dona do MySQL) foi vendida para a Sun por um 1 bilhão de dólares, um valor impensado naquela época! Posteriormente, a Sun foi vendida para a Oracle e sendo assim, hoje o MySQL é um produto da Oracle.
A Oracle mantém duas versões do MySQL: uma gratuita e uma paga (que inclui serviços como suporte e ferramentas extras).
Se você optar por instalar a versão gratuita do MySQL nos seus servidores, é indispensável estar atento às condições de uso explicadas na licença GPL.
Quanto à versão gratuita, ela é chamada de community, e pode ser baixada neste link.
Esse artigo nasceu porque (na minha opinião) o que mais diferencia o MySQL dos outros SGBDs, é a possibilidade de escolher a Storage Engine. Essa liberdade nos dá a responsabilidade de escolher a opção certa para cada necessidade de negócio.
A flexibilidade do MySQL permite que ele seja uma opção interessante para trabalhar bem em ambientes muito diferentes e complexos. Ao mesmo tempo, ele pode potencializar aplicações embarcadas, DW, indexação de conteúdo e software de prateleira, sistemas redundantes e altamente disponíveis, processamento de transação on-line (OLTP) e muito mais. Ou seja, a utilização do MySQL vai muito além do PHP (repetindo para fixar).
Storage Engine
Para acabar o mistério, as Storage Engines são componentes do MySQL que manipulam as operações SQL para diferentes tipos de tabelas – simples assim!
Achei essa definição das Storge Engine na web e curti. Por isso, resolvi transcrevê-la com o objetivo de deixar o conceito o mais claro possível:
“Como os diversos sistemas de arquivo disponíveis para GNU/ Linux, cada storage engine possui seus próprios benefícios e desvantagens. O servidor comunica-se com elas através da API da storage engine. Essa interface esconde diferenças entre as SE e as tornam amplamente transparentes na camada de consulta. A API contém várias funções de baixo nível que realiza operações como “iniciar uma transação” ou “trazer a linha”. As storage engines não interpretam SQL nem se comunicam umas com as outras; elas simplesmente respondem às requisições do servidor.”
Ao criar uma tabela, o DBA ou desenvolvedor pode escolher qual a storage engine mais adequada. A possibilidade de escolha da storage engine nos permite extrair o melhor do MySQL, desde que escolhamos a opção certa para a necessidade da aplicação – como armazenamento de dados, processamento de transações ou situações de alta disponibilidade – enquanto aproveitam a vantagem de utilizar um conjunto de interfaces e serviços independentes de qualquer storage engine.
Se as alterações nos aplicativos ocasionarem alteração da storage engine, não serão necessárias alterações significativas no seu código para que as coisas funcionem. A arquitetura do servidor MySQL protege o aplicativo da complexidade da storage engine, apresentando uma API consistente e fácil de usar.
Quais Storage Engines tenho disponíveis?
Para começar, você pode verificar quais SE (= Storage Engine) seu servidor suporta, usando o comando SHOW ENGINES. O valor da coluna Support indica se a SE pode ser usada.
Atualmente, a InnoDB é um SE padrão do MySQL, pois equilibra alta confiabilidade e alto desempenho. Se você criar uma tabela no MySQL sem especificar a SE, a InnoDB será usada.
As características legais da InnoDB, são:
- Suas operações DML possuem suporte para as propriedades ACID, com transações que incluem recursos de confirmação, reversão e recuperação de falhas para proteger os dados.
- Bloqueio em nível de linha e leituras consistentes (no estilo Oracle) aumentam a simultaneidade e o desempenho para uma quantidade grande de usuários.
- As tabelas organizam seus dados no disco para otimizar as consultas com base nas chaves primárias. Cada tabela possui um índice cluster na chave primária que organiza os dados para minimizar o I/O em algumas consultas.
- Para manter a integridade referencial, o InnoDB suporta FOREIGN KEY. Ou seja, inserções, atualizações e exclusões são verificadas para garantir que não resultem em inconsistências em diferentes tabelas.
Existem diversas SE e eu não tenho a pretensão de abordar todas, mas abaixo segue um breve resumo daquelas que eu acho bem importantes:
- MyISAM: esta SE tem bloqueio no nível de tabela, bom desempenho para cargas em batch e posteriores leituras.
- Memory: armazena todos os dados na memória para acesso rápido em ambientes que exigem pesquisas rápidas de dados não críticos. Ou seja, use para cache.
- CSV: suas tabelas são realmente arquivos de texto com valores separados por vírgula. Esta SE permite importar ou baixar dados no formato CSV para trocar dados com scripts e aplicativos que leem e escrevem no mesmo formato. Cuidado com o fato das tabelas criadas com esta SE não serem indexadas, por isso, você normalmente manterá os dados nas tabelas criadas com InnoDB durante a operação normal, e só usará tabelas CSV durante o estágio de importação ou exportação.
- Archive: tabelas criadas com esta SE são compactas e não indexadas e destinam-se a armazenar e recuperar grandes quantidades de informações históricas, arquivadas ou de auditoria de segurança raramente referenciadas.
Para resumir, adorei a tabela que existe na documentação oficial do MySQL, por isso trouxe ela para o artigo, de modo que vocês a utilizem para decidir qual a melhor SE de acordo com suas necessidades:
E no Azure?
Falamos bastante das SE, mas quais estão disponíveis no serviço MySQL do Azure? Esse é um aspecto que você precisa levar em consideração. E eu fiquei bem feliz de testar as SE e descobrir que temos algumas opções. Não estão disponíveis a Archive e MyISAM (se você precisar desta storage engine, use MRG_MYISAM).
Conclusão
O MySQL é um dos bancos de dados mais usados no mundo. Pioneiro, flexível e com uma comunidade apaixonada!
Vale a pena conhecê-lo e utilizá-lo – sempre respeitando a versão e suas limitações de uso. Se você irá instalar o MySQL no seu servidor, ou vai criar uma VM no Azure, você tem diversas possibilidades de escolha de SE.
Analise seus requisitos e escolha a SE correta (tanto se optou instalar o MySQL, ou mesmo o Azure).
Aguardem e não percam! No próximo artigo mostrarei como criar um Servidor MySQL no Azure e conversaremos sobre as características, preços, utilização, administração e outros itens importantes.
Treinamentos
Para quem se interessa em fazer treinamentos de MySQL, eu indico os treinamentos da Nerv Informática. O instrutor é o Ricardo Portilho, que é a minha referência em MySQL e MariaDB.
Referências
De 0 a 10, o quanto você recomendaria este artigo para um amigo?