Nas últimas semanas eu venho falando muito do PostgreSQL… Que é um banco de dados que eu adoro! Mas o combinado é que conversaríamos sobre os 3 bancos de dados Open Source e relacionais do Azure (PostgreSQL, MySQL e MariaDB), e por isso hoje é dia de conversar 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!
E antes que alguém me questione, ou faça uma daquelas piadinhas toscas, ele pode ser usado sem o PHP… Aliás eu acho esse casamento perfeito, e me arrisco a dizer que o MySQL faz parte do “ecossistema do PHP”. Mas 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 vendido 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 as condições de uso explicadas na licença GPL .
Quanto a versão gratuita, ela é chamada de community e pode ser baixada neste link.
Esse post 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…rsrs).
Storage Engine
Para acabar o mistério… Storage Engines são componentes do MySQL que manipulam as operações SQL para diferentes tipos de tabelas!!! Simples assim!
Eu achei esta definição das Storge Engine na web e curti, por isso resolvi transcrevê-la com o objetivo de deixar o conceito 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. Esta 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 engine 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 Engine tenho disponíveis?
Para começar, você pode Para 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 lêem e escrevem no mesmo formato. Cuidado com o fato das tabelas criadas com esta SE não serem indexadas, e por isso, você normalmente mantém os dados nas tabelas criadas com InnoDB durante a operação normal, e só usarás 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 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 post, de modo que você a utilize para decidir qual a melhor SE para a sua necessidade:
Feature | MyISAM | Memory | InnoDB | Archive |
B-tree indexes | Yes | Yes | Yes | No |
Backup/point-in-time recovery | Yes | Yes | Yes | Yes |
Cluster database support | No | No | No | No |
Clustered indexes | No | No | Yes | No |
Compressed data | Yes | No | Yes | Yes |
Data caches | No | N/A | Yes | No |
Encrypted data | Yes | Yes | Yes | Yes |
Foreign key support | No | No | Yes | No |
Full-text search indexes | Yes | No | Yes | No |
Geospatial data type support | Yes | No | Yes | Yes |
Geospatial indexing support | Yes | No | Yes | No |
Hash indexes | No | Yes | No | No |
Index caches | Yes | N/A | Yes | No |
Locking granularity | Table | Table | Row | Row |
Replication support | Yes | Limited | Yes | Yes |
Storage limits | 256TB | RAM | 64TB | None |
Transactions | No | No | Yes | No |
Update statistics for data dictionary | Yes | Yes | Yes | Yes |
Origem: https://dev.mysql.com/doc/refman/8.0/en/storage-engines.html
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 stora 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 conhece-lo e utiliza-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 da SE. Analise os seus requisitos e escolha a SE correta (tanto se você optou instalar o MySQL, quanto se você optar por usar o Azure).
Aguardem e não percam! No próximo post 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
http://www.altabooks.com.br/index.php?dispatch=attachments.getfile&attachment_id=155
https://dev.mysql.com/doc/refman/8.0/en/storage-engines.html
https://dev.mysql.com/doc/refman/8.0/en/innodb-introduction.html
https://docs.microsoft.com/pt-br/azure/mysql/concepts-limits
Agenda
Esta é uma semana super importante! Eu terei a oportunidade de palestrar no Microsoft Ignite – The Tour São Paulo, sobre Persistência Poliglota no Azure, e gostaria de convidar a todos para acompanhar minha palestra que acontecerá no dia 11/12 às 12:10h.
O código da sessão é BRK-6484, e o link para ver todas as sessões disponíveis é este.