Nos dias em que alguém dizia MySQL, existia apenas o MySQL. Você pode escolher versões diferentes (4.0, 4.1), mas o fornecedor é o mesmo. Isso mudou em torno do MySQL 5.0/5.1 quando a Percona decidiu lançar sua própria versão do MySQL - Percona Server. Um pouco mais tarde, o MariaDB juntou-se ao MariaDB 5.1 e a diversão (ou confusão) aumentou. Qual versão devo usar? Qual é a diferença entre MySQL 5.1, Percona Server 5.1 e MariaDB 5.1? Qual deles é mais rápido? Qual deles é mais estável? Qual deles tem funcionalidade superior? Com o tempo, isso piorou à medida que mais e mais mudanças foram introduzidas em cada um dos sabores. Esta postagem do blog será nossa tentativa de resumir os principais recursos que os diferenciam. Também tentaremos dar algumas sugestões sobre qual sabor pode ser o melhor para um determinado tipo de projeto. Vamos começar.
Oracle MySQL
Costumava ser o MySQL, agora é o upstream. A maior parte do desenvolvimento começa aqui, cada versão a partir de 5.6 resolve algumas contenções internas e traz melhor desempenho. Novos recursos também estão sendo adicionados regularmente. O MySQL 5.6 nos trouxe (entre outros) GTID e uma implementação inicial de replicação paralela. Também nos deu a capacidade de executar a maioria dos ALTERs de maneira online. Vamos dar uma olhada nos recursos da versão mais recente do MySQL - MySQL 5.7
Recursos do MySQL 5.7
Uma das principais mudanças são as mudanças no processo de implantação - em vez de scripts diferentes, você pode simplesmente executar mysqld --initialize para configurar o MySQL do zero. Outra mudança muito importante - replicação paralela baseada no relógio lógico. Finalmente, podemos usar a replicação paralela em todos os casos - não importa se você usa vários esquemas ou não. Outra melhoria de replicação é a replicação de várias fontes - um escravo 5.7 pode ter vários mestres - é um ótimo recurso se você deseja criar um escravo de agregação e, digamos, combinar dados de vários clusters separados.
O InnoDB começou a oferecer suporte a tipos espaciais, o buffer pool do InnoDB pode finalmente ser redimensionado em tempo de execução, os ALTERs online foram aprimorados para suportar mais casos como particionamento e ALTERs sem operação.
O MySQL começou a oferecer suporte a tipos de dados JSON nativamente, juntamente com várias novas funções focadas em adicionar funcionalidade ao JSON. A segurança de seus dados é muito importante nos dias de hoje, o MySQL 5.7 suporta criptografia de dados em repouso para tablespaces de arquivo por tabela. Algumas melhorias também foram adicionadas ao suporte SSL (o SSL será configurado se as chaves estiverem em vigor, um script incluído que pode ser usado para criar certificados). Do ponto de vista do gerenciamento de usuários, a configuração do tempo de vida da senha foi adicionada, o que deve facilitar um pouco o design das políticas de expiração de senha.
Outro recurso destinado a auxiliar os DBAs é o esquema 'sys', um conjunto de visualizações projetado para facilitar o uso do Performance Schema. Foi incluído por padrão no MySQL 5.7.
Finalmente, MySQL Group Replication (e eventualmente MySQL InnoDB Cluster) foi adicionado ao MySQL 5.7. Funciona como um plugin e está incluído nas versões recentes da ramificação 5.7, mas isso é um tópico à parte. Resumindo, a Replicação de Grupo permite que você crie um cluster “virtualmente” síncrono.
Esta definitivamente não é uma lista completa de recursos - se você estiver interessado em todos eles, você pode consultar a documentação do MySQL 5.7.
Servidor Percona
No início, havia um conjunto de patches para aplicar ao código-fonte do MySQL que adicionava algumas melhorias de desempenho e funcionalidade. Em algum momento, a Percona decidiu lançar sua própria versão do MySQL que incluía esses patches. Com o tempo, mais recursos de desenvolvimento ficaram disponíveis, então mais e mais recursos foram adicionados.
Em geral, você pode ver o Percona Server como a versão mais recente do MySQL com vários patches/melhorias. Com o tempo, algumas das melhorias de recursos do Percona Server são substituídas por recursos do upstream - sempre que a Oracle desenvolve um recurso que substitui uma das funcionalidades adicionadas no Percona Server. Contanto que a implementação esteja no mesmo nível, Percona remove seu próprio código em favor do código do upstream. Isso torna o Percona Server basicamente um substituto para o MySQL da Oracle. Uma das áreas em que foram feitas grandes melhorias de desempenho é o InnoDB. Ele foi modificado significativamente o suficiente para marcá-lo como XtraDB. Atualmente é totalmente compatível com o InnoDB, mas nem sempre foi assim. Por exemplo, alguns recursos do Percona Server 5.5 não eram compatíveis com o MySQL 5.5. Isso também vale para as versões mais recentes do Percona Server. O importante é que, por padrão, o Percona Server vem com todos os recursos incompatíveis desabilitados - facilita testá-lo e reverter para o MySQL da Oracle, se necessário. Levando em consideração tudo acima, você ainda deve ter cuidado ao planejar migrar do Percona Server para o MySQL - alguém pode ter ativado um dos recursos incompatíveis.
O que vale destacar é que a Percona se esforça para reimplementar os recursos corporativos do upstream. No caso do MySQL, os exemplos são a implementação de um pool de threads ou um plug-in de autenticação PAM. Vamos dar uma olhada rápida em alguns dos recursos do Servidor Percona.
Recursos do Percona Server 5.7
Um dos principais recursos do XtraDB é a escalabilidade aprimorada do pool de buffers - embora haja cada vez menos contenção devido ao trabalho que a Oracle faz em todas as versões do MySQL, a equipe de engenharia da Percona se esforça para aumentar ainda mais o desempenho e remover mutexes adicionais que podem limitar o desempenho. Além disso, mais dados são gravados no monitor InnoDB (acessível via SHOW ENGINE INNODB STATUS) em relação às contenções no InnoDB - por exemplo, uma seção sobre semáforos foi adicionada.
Outro conjunto de melhorias foi feito na área de E/S. No InnoDB, você pode definir um método flush apenas para espaços de tabela do InnoDB e isso causa buffer duplo para logs de redo do InnoDB. O XtraDB torna possível usar O_DIRECT também para esses arquivos. Ele também adiciona mais dados sobre pontos de verificação à saída de SHOW ENGINE INNODB STATUS. Além disso, o buffer de escrita dupla paralela e o flusher LRU multi-thread foram implementados para reduzir a contenção em operações de E/S dentro do InnoDB.
O pool de threads é outro recurso disponibilizado pelo Percona Server. No Oracle MySQL está disponível apenas na edição Enterprise. Aqui você pode usar a implementação do Percona gratuitamente. Em geral, o pool de encadeamentos reduz as contenções enquanto atende um alto número de conexões do aplicativo reutilizando as conexões existentes com o banco de dados.
Mais dois recursos são substituições diretas de recursos da versão Enterprise do MySQL. Um deles é o plugin de autenticação PAM que foi desenvolvido pela Percona e foi projetado para permitir o uso de várias opções de autenticação diferentes, como LDAP, RSA SecurID ou quaisquer outros métodos suportados pelo PAM. O segundo recurso também está relacionado à segurança - plug-in de log de auditoria. Ele criará um arquivo com um registro das ações realizadas no servidor de banco de dados.
De tempos em tempos, o Percona introduz melhorias significativas em outros mecanismos de armazenamento, como as alterações feitas no mecanismo MEMORY, que permitem o uso de dados do tipo VARCHAR ou BLOB.
A introdução de bloqueios de backup também foi uma melhoria bastante significativa. No Oracle e no MariaDB, o único método de travar a tabela para obter um backup consistente era usar FLUSH TABLES WITH READ LOCK (FTWRL). É bastante pesado e força o MySQL a fechar todas as tabelas abertas. Os bloqueios de backup, por outro lado, usam uma abordagem mais leve de bloqueios de metadados. Em muitos casos de servidor muito carregado executando FTWRL demora muito (e bloqueia o servidor por muito tempo) para ser considerado viável, enquanto os bloqueios de backup tornam possível fazer um backup usando mysqldump ou xtrabackup.
O Percona também está aberto para portar recursos de outros fornecedores. Um exemplo é a porta de START TRANSACTION WITH CONSISTENT SNAPSHOTS do MariaDB. Esse recurso também está relacionado a backups - com sua ajuda, você pode fazer um backup lógico consistente (usando mysqldump) sem executar FLUSH TABLE WITH READ LOCK.
Finalmente, três recursos que melhoram a observabilidade - primeiro:estatísticas do usuário. Este é um recurso bastante leve que coleta dados sobre usuários, índices, tabelas e threads. Ele permite que você encontre índices não utilizados ou determine qual usuário é responsável pela carga no servidor. Atualmente é parcialmente redundante para performance_schema, mas é um pouco mais leve e foi criado nos dias do MySQL 5.0 - 5.1, onde ninguém nem sonhava com o performance_schema.
Segundo - log de consulta lenta aprimorado. Novamente, foi adicionado em momentos em que a granularidade mais alta de long_query_time era de 1 segundo. Com essa adição, você teve granularidade de microssegundos e vários dados adicionais sobre as estatísticas do InnoDB por consulta ou suas características gerais de desempenho. Ele criou uma tabela temporária? Ele usou um índice? Foi armazenado em cache no cache de consulta do MySQL?
Terceiro recurso que mencionamos algumas vezes acima - o Percona Server expõe significativamente mais dados no SHOW ENGINE INNODB STATUS do que no upstream. Definitivamente, ajuda a entender melhor a carga de trabalho e detectar mais problemas antes que eles se manifestem.
Obviamente, esta não é uma lista completa - se você estiver interessado em mais detalhes, verifique a documentação do Percona Server.
MariaDB
O MariaDB começou como um fork do MySQL, mas, com parte da equipe de desenvolvimento original do MySQL se juntando ao MariaDB, rapidamente se concentrou em adicionar recursos. No MariaDB 5.3, muitos recursos foram adicionados ao otimizador:Batch Key Access, MultiRange Read, Index Condition Pushdown, para citar alguns. Isso permitiu que o MariaDB se destacasse em algumas cargas de trabalho em que o MySQL ou o Percona Server teriam dificuldades. Até agora, alguns desses recursos foram adicionados ao MySQL (principalmente no MySQL 5.6), mas alguns ainda são exclusivos do MariaDB.
Outro recurso importante que foi introduzido pelo MariaDB foi o Global Transaction ID. Não muito depois, a Oracle lançou sua própria implementação, mas MariaDB foi a primeira a tê-la. História semelhante é com outro recurso de replicação - replicação multisource:MariaDB tinha isso antes do Oracle. Agora, o recém-lançado MariaDB 10.2 também contém recursos que serão disponibilizados no MySQL 8.0, que ainda está em desenvolvimento. Estamos falando, por exemplo, de expressões de tabela comuns recursivas ou funções de janela.
Recursos do MariaDB 10.2
Como mencionamos, o MariaDB 10.2 apresenta funções de janela e expressões de tabela comuns recursivas - aprimoramentos no SQL que devem ajudar os desenvolvedores a escrever consultas SQL mais eficientes.
Uma mudança muito importante é que o MariaDB 10.2 usa o InnoDB. Até a versão 10.1, o XtraDB era usado como armazenamento padrão. Isso, infelizmente, torna os recursos adicionados no XtraDB mais recente indisponíveis para usuários do MariaDB 10.2.
Melhorias foram feitas nas colunas virtuais - mais limitações foram levantadas na versão 10.2.
Finalmente, foi adicionado suporte para vários gatilhos para o mesmo evento - agora você pode criar vários, por exemplo, gatilhos ON UPDATE na mesma tabela.
Os desenvolvedores devem se beneficiar do suporte JSON, juntamente com algumas funções relacionadas a ele. Eles também devem gostar de novas funções que lhes permitam exportar dados espaciais para o formato GeoJSON. Falando sobre JSON, foram feitas melhorias na saída EXPLAIN FORMAT=JSON - mais dados são mostrados.
Na frente de segurança, foi adicionado suporte para OpenSSL 1.1 e LibreSSL.
Claro, esta lista não está completa e se você estiver interessado no que foi adicionado ao MySQL 10.2, você pode querer consultar a documentação.
Além dos novos recursos, o MariaDB 10.2 se beneficia de recursos implementados em versões anteriores. Passaremos pelos mais importantes.
Os recursos mais importantes do MariaDB 10.1
Em primeiro lugar, o MariaDB desde 10.1 vem empacotado com o cluster Galera - não há necessidade de instalar bibliotecas adicionais, tudo está pronto para uso.
O MariaDB 10.1 trouxe a implementação da criptografia de dados em repouso. Comparado com o recurso implementado no MySQL da Oracle, o MariaDB o tem mais estendido. Não apenas criptografa tablespaces, mas também criptografa logs redo, arquivos temporários e logs binários. Isso vem com alguns problemas - ferramentas CLI como mysqldump ou xtrabackup não podem acessar logs binários e podem ter problemas ao fazer backup de instâncias criptografadas (isso é especialmente verdadeiro para xtrabackup - recentemente o MariaDB criou o fork xtrabackup chamado MariaDB Backup que suporta dados em repouso criptografia).
Ok, então qual sabor devo usar?
Como costuma ser, a resposta correta seria:“Depende” :-) . Compartilharemos algumas de nossas observações que podem ou não ajudá-lo a decidir, mas, no final, cabe a você executar benchmarks e encontrar a opção que funcionará melhor para seu ambiente e aplicativo.
Em primeiro lugar, vamos falar sobre o fluxo. Oracle lança nova versão - digamos MySQL 5.7. Em termos de desempenho, naquele momento, esse é o sabor MySQL mais rápido do mercado. Isso ocorre porque apenas a Oracle tem recursos suficientes para trabalhar na melhoria do InnoDB nessa medida. Dentro de alguns meses (no caso de 5.7, foram 4 meses) Percona lança o Percona Server 5.7 com seu conjunto de melhorias - dependendo do tipo de carga de trabalho, pode entregar um desempenho ainda melhor do que o upstream. Finalmente, MariaDB adota a nova versão upstream e constrói sua nova versão em cima dela.
É assim que se parece em um calendário (ainda estamos falando sobre o MySQL 5.7).
MySQL 5.7 GA:21 de outubro de 2015
Servidor Percona 5.7 GA:23 de fevereiro de 2016
MariaDB 10.2 GA:23 de maio de 2017
Observe quanto tempo o MariaDB levou para lançar uma versão baseada no MySQL 5.7 - todas as versões anteriores foram baseadas no MySQL 5.6 e, obviamente, apresentaram desempenho inferior ao MySQL 5.7. Por outro lado, o MariaDB 10.2 foi lançado com o InnoDB substituindo o XtraDB. Embora seja verdade que a Oracle praticamente fechou a lacuna de desempenho entre o MySQL e o Percona Server, ainda é apenas “principalmente”. Como resultado, o MariaDB 10.2 pode oferecer desempenho inferior ao do Percona Server em alguns casos (e melhor em outros casos - devido ao trabalho de otimização feito no MariaDB 5.3, alguns dos quais ainda não foram recriados no MySQL).
Em termos de recursos, é mais complexo. O MariaDB tem adicionado muitos recursos, então se você estiver interessado em alguns deles, você pode definitivamente considerar usar o MariaDB. Há uma desvantagem disso também. O Percona Server tinha muitos recursos que o diferenciavam do MySQL upstream, mas quando a Oracle começou a implementá-los no MySQL, a Percona decidiu depreciar suas implementações em favor de usar a implementação do upstream. Isso reduziu a quantidade de código que é diferente entre o MySQL e o Percona Server, facilita a manutenção do código do Percona Server e, o que é mais importante, torna o Percona Server 100% compatível com o MySQL.
Infelizmente, isso não é verdade para o MariaDB. O MariaDB introduziu o GTID primeiro, é verdade, mas depois que a Oracle desenvolveu sua versão do GTID, o MariaDB decidiu manter sua própria implementação. Este blog não é o lugar para decidir qual implementação é melhor, mas, como resultado, temos que gerenciar dois sistemas GTID diferentes e incompatíveis - ele sobrecarrega qualquer ferramenta que gerencie a replicação e reduz a interoperabilidade. Aderindo à replicação - confirmação de grupo e replicação paralela:tanto o Oracle quanto o MariaDB têm sua própria implementação e, se você trabalha com os dois, precisa aprender os dois para aplicar o ajuste necessário - os botões são diferentes e funcionam de maneira diferente. Caso semelhante é com suporte a colunas virtuais - duas implementações diferentes, não 100% compatíveis, o que, como resultado, tornou impossível despejar facilmente dados do MariaDB e carregar no MySQL da Oracle (e vice-versa) porque a sintaxe é um pouco diferente. Portanto, se você decidir usar uma versão do MariaDB para algum novo recurso, poderá acabar ficando preso a ele, mesmo que queira migrar de volta para o MySQL para usar a implementação do Oracle. Na melhor das hipóteses, a migração exigiria muito mais esforço para ser executada. Claro, se você ficar em um ambiente o tempo todo, isso pode não afetá-lo severamente. Mas mesmo assim, a falta de compatibilidade será perceptível para você, mesmo que apenas enquanto você lê blogs na internet e encontra soluções que não são realmente aplicáveis ao seu sabor de MySQL.
Então, para resumir - se você estiver interessado em manter a compatibilidade com o MySQL, o Percona Server (ou o próprio MySQL, é claro) provavelmente seria o caminho a seguir. Se você estiver interessado em desempenho, desde que haja o Percona Server construído sobre o MySQL mais recente, pode ser o caminho a seguir. Claro, você pode querer comparar o MariaDB e ver se sua carga de trabalho não pode se beneficiar de algumas otimizações que ainda são exclusivas do MariaDB. Em termos operacionais, provavelmente é bom manter um dos ambientes (Oracle/Percona ou MariaDB), o que funcionar melhor para você. MySQL ou Percona Server têm a vantagem de serem mais comumente usados e é um pouco mais fácil integrá-los com ferramentas externas (porque nem todas as ferramentas suportam todos os recursos do MariaDB). Se você se beneficiaria de um recurso novo e brilhante que acabou de ser implementado no MariaDB, você deve considerá-lo, tendo em mente quaisquer possíveis problemas de compatibilidade e possível desempenho inferior.
Esperamos que este post do blog tenha lhe dado algumas ideias sobre as diferentes escolhas que temos no mundo MySQL e os diferentes ângulos a partir dos quais você pode compará-las. No final do dia, será sua tarefa decidir o que é melhor para sua configuração. Pode não ser fácil, mas ainda assim devemos ser gratos por termos uma escolha e podermos escolher o que funciona melhor para nós.
