descrição mariadb. Substituto do MariaDB para comparação do MySQL

O MySQL tornou-se propriedade da Oracle, existem alternativas e com que rapidez ele está avançando?... Mais ou menos como uma visão geral de "quem é quem?" ainda não estava lá. Então, um revisor para quem "não está no assunto"

Algumas pessoas, e muitas, simplesmente não estão felizes com o fato de o MySQL ter se tornado propriedade da Oracle. Felizmente, já vivemos em um mundo onde a informação se espalha na velocidade da impressão de pensamentos e as decisões são tomadas na velocidade da luz.

Michael Widenius, fundador da MySQL e fundador da MySQL AB (que foi adquirida pela Sun, que foi adquirida pela Oracle)
Petr Zaitsev - especialista em desempenho MySQL, ex-líder de equipe do grupo de alto desempenho da MySQL Inc, host do blog MySQLPerformanceBlog.com

Então quais são as alternativas?

O servidor Percona é uma compilação do MySQL (por Peter Zaitsev e companhia) com o mecanismo de armazenamento XtraDB ativado por padrão. Difere do plug-in MySQL+InnoDB em melhor desempenho/escalabilidade, especialmente em servidores multi-core modernos. A funcionalidade também foi aprimorada - mais estatísticas úteis para otimização, etc. É coletado em versões baseadas no MySQL 5.0 e 5.1. Totalmente compatível com tabelas innodb, ou seja, você pode alternar de innodb para xtradb e vice-versa sem problemas (se você não usar alguns recursos específicos do xtradb, como um tamanho de página menor).

O armazenamento XtraDB é baseado no código do plug-in InnoDB e é totalmente compatível com ele, mas tem um desempenho visivelmente melhor graças à integração de patches do Google e da Percona. Em particular, o XtraDB melhorou o mecanismo para trabalhar com memória, melhorou o trabalho do subsistema InnoDB I / O, adicionou suporte para vários fluxos de leitura e gravação, suporte para gerenciamento de largura de banda, implementação de pré-busca de dados (read-ahead), ponto de verificação adaptável (ponto de verificação adaptável), as opções de dimensionamento para grandes projetos foram expandidas, o sistema de organização de bloqueio foi adaptado para funcionar em sistemas com um grande número de CPUs, recursos adicionais foram adicionados para acumular e analisar estatísticas

MariaDB- montagem do Monty, sincronizada com a base de código MySQL e totalmente compatível com ela, ou seja, pode atuar como um substituto transparente para o MySQL 5.1, enquanto possui vários recursos avançados, incluindo otimizações de desempenho e vem com um conjunto de mecanismos de armazenamento adicionais:

  • Novos armazenamentos de dados:
    • Aria (anteriormente Maria) é um armazenamento de alta disponibilidade baseado em MyISAM que é altamente resiliente e mantém a integridade dos dados após uma falha, sendo totalmente compatível com MyISAM
    • OQGRAPH (repositório para organizar gráficos complexos)
    • Sphinx - repositório para construção de motores de busca
    • PrimeBase XT - descrição em russo
    • O mecanismo XtraDB é usado como substituto do InnoDB
    • FederatedX - permite organizar o acesso a tabelas remotas como local
  • Patches de mecanismo MyISAM - Cache segmentado (em altas cargas dá um aumento significativo)
  • Eliminação de tabelas - um novo tipo de otimização de consulta usando JOIN
  • Pool de threads - agora mais de um thread pode ser aberto por conexão
  • Melhorou

O que acontecerá agora, quando a Oracle, odiada e até profundamente oposta aos verdadeiros defensores do software de código aberto, comprou o sofredor Sun, e junto com nosso amado MySQL? O fim de um produto lendário? Talvez. Mas agora existem desenvolvimentos muito mais funcionais e totalmente compatíveis!

MySQL, é apenas "músculo". Aposto que este é o único DBMS que está disponível por padrão em sua hospedagem. Mecanismos favoritos para o fórum e blog trabalham nele. Na verdade, esse é o padrão de fato para qualquer produto da web. E em seus projetos, você provavelmente o usa. Existem milhões de sites na Web que consultam e armazenam dados em um banco de dados usando o MySQL. E tudo era simples e claro até que a Sun, junto com seu amado músculo, foi inesperadamente comprada pela Oracle Corporation. Dado que o principal produto deste último é o DBMS mais poderoso com o mesmo nome, a comunidade estava muito preocupada com o destino futuro do MySQL. E não em vão. A Oracle, é claro, emitiu um comunicado de que está tudo em ordem: o projeto continuará se desenvolvendo. Mas muitas pessoas acham isso difícil de acreditar. Afinal, mesmo o lançamento rápido da versão 5.5, que muitos esperavam, não deu resultados positivos: os bugs antigos permaneceram os mesmos. Isso é um problema? Mas, paralelamente ao MySQL original, há muito tempo são desenvolvidos projetos alternativos que são compatíveis com o DBMS original, mas até o superam em muitos aspectos. E vamos falar sobre isso agora.

Mecanismo de banco de dados - o que é?

Se simplificarmos um pouco os conceitos, o banco de dados é um wrapper em torno do mecanismo de armazenamento de dados. Ele se encarrega de receber e gerenciar solicitações, cache e outras funções de serviço, fornecendo trabalho com a API de baixo nível do mecanismo. Este último, por sua vez, realmente armazena os dados (no disco ou na memória), trabalha com o sistema operacional e fornece a emissão das amostras necessárias mediante solicitação do servidor. Se anteriormente o DBMS (o pacote "servidor + mecanismo") era monolítico, agora todos os sistemas usam uma estrutura com plug-ins. O mecanismo dessa organização é apenas um módulo e o próprio servidor não depende do sistema de armazenamento. As edições mais recentes do MySQL clássico também usam uma arquitetura de plug-in. Portanto, o mecanismo interno do InnoDB (embora geralmente seja uma versão desatualizada) pode ser facilmente substituído por um módulo de outro projeto, que geralmente é melhor. Em desenvolvimentos de muscle-alternative, incluindo MariaDB ou Drizzle, todos os mecanismos são inicialmente implementados como plug-ins. Tentarei abordar brevemente os mecanismos modernos de armazenamento de dados em DBMS compatíveis com MySQL.

  • InnoDBGenericName- o motor principal do músculo, que finalmente se tornou padrão desde a versão 5.5. Suporta transações, replicação, bloqueio de linha. Bastante resistente a choques.
  • MyISAMGenericName- um mecanismo muito problemático que não tolera falhas no servidor. Ele não suporta transações, mas possui índices de texto completo e velocidade. Por muito tempo foi o padrão para todas as versões do MySQL e, portanto, ainda é o mais popular.
  • Ária- substituição para MyISAM com suporte a transações e melhor manuseio de memória. O mecanismo garante a integridade dos dados e, ao mesmo tempo, não é inferior em velocidade ao MyISAM.
  • CVS- um mecanismo especializado para o caso em que você precisa armazenar e processar grandes matrizes de dados de string separados por vírgula.
  • Federado/FederadoX- este mecanismo é especializado na distribuição transparente de dados em vários servidores (físicos) no nível da tabela.
  • PBXT- projetado para substituir o InnoDB por um novo mecanismo que implementa suporte total a transações, multiversão e processamento automático de bloqueios. O mecanismo é otimizado para um grande número de transações simultâneas.
  • buraco negro- mecanismo de serviço, que é, de fato, /dev/null para o DBMS e não produz nenhuma gravação de disco. Usado para replicação.
  • Arquivo- um mecanismo que funciona o mais rápido possível para gravação. É usado quando é necessário hospedar grandes arrays de dados. Para eficiência de armazenamento, a compactação é usada, resultando em lentidão durante as buscas. O mecanismo é adequado para armazenamento de longo prazo de logs e outras informações de serviço.
  • XtraDBGenericName- estendido e corrigido em algumas áreas problemáticas InnoDB de Percona.
  • MERGE- um mecanismo semelhante ao Federado para espalhar dados em uma tabela em várias tabelas diferentes.
  • MEMÓRIA- um mecanismo usado para armazenar dados não no disco, mas na memória. As informações do banco de dados estão disponíveis apenas enquanto o servidor está em execução, mas isso proporciona um grande aumento de desempenho.
  • BlitzDBName- outro substituto para o MyISAM com bom desempenho devido ao cache embutido linha por linha e recuperação automática de falhas. O mecanismo não suporta transações.
  • NDB- um mecanismo para um cluster, que, no entanto, tem muitos problemas e desempenho deprimente.
  • Falcão- o lendário mecanismo da MySQL AB, desenvolvido desde os tempos da Sun, quando foi decidido substituir o InnoDB da Oracle.
  • Sphinx SE- um mecanismo de texto completo do criador do servidor de pesquisa Sphinx. A melhor opção para pesquisa de texto completo e indexação de acordo com as regras do idioma russo. Manipula facilmente terabytes de dados enquanto fornece todos os recursos de um banco de dados moderno.

O importante é a compatibilidade

Assim, assumimos a difícil tarefa de encontrar um substituto para o MySQL. Mas se você mudar, então para quê? Apenas não saia gritando "Chupe seu músculo - pegue o elefante, isto é, PostgreSQL". Não funciona! Agora, tanto código é escrito com suporte ao MySQL que reescrever ou procurar uma substituição é mais caro para você. E no sentido literal - muitas vezes é impossível atender aos custos financeiros razoáveis. Bem, se estamos falando de um simples fórum ou blog (geralmente eles suportam vários sistemas ao mesmo tempo). Mas e se for algo auto-escrito ou customizado especificamente para o MySQL? Tudo aqui é tão difícil. Portanto, nossa tarefa é manter os músculos (ou seja, compatibilidade total com o MySQL), mas bombeá-los para não depender do treinador principal e de seus esteróides.

Os desenvolvedores e ideólogos do próprio MySQL estão longe de serem tolos e previram a situação de que após a aquisição seria difícil para todos. Alguns deles até decidiram deixar a empresa e estabelecer seus próprios projetos, levando os então ainda gratuitos muscle codes. Graças a isso, agora existem vários produtos interessantes baseados no código original do servidor, mas com grandes melhorias e mudanças em tudo o que os desenvolvedores conseguiram alcançar. Em primeiro lugar, os entusiastas se livraram do fardo do mecanismo InnoDB, cujos direitos há muito pertencem ao mesmo Oracle. Para substituí-lo, foram lançadas várias engines, que ficaram disponíveis no MariaDB.

Arquitetura MySQL - agora como um guia para o dispositivo do outrora grande DBMS

MariaDB

A história deste servidor remonta a 2008, quando um dos principais desenvolvedores do MySQL, percebendo que estava fortemente vinculado à estrutura definida pelo empregador, saiu e fundou sua própria empresa, que se dedicava à correção de lesões de nascimento do MySQL. Estou falando sobre o mecanismo MyISAM padrão que precisava ser alterado e bugs críticos que levaram um tempo inaceitável para serem corrigidos. O que aconteceu com os criadores do MariaDB? Um produto maravilhoso que é idêntico à versão original do MySQL no nível de protocolo, formato de arquivo e linguagem SQL. Isso fornece uma transição indolor: sem perda de dados ou alteração na lógica do código existente.

“Mas que bônus eu vou ganhar com a transição?” Você pergunta. Em troca, obtemos uma maior velocidade de trabalho e novos recursos, que, talvez, nunca estarão no músculo. Por exemplo, o mecanismo de pesquisa Sphinx integrado ao próprio servidor, que não precisa ser instalado separadamente, recursos avançados de backup e gerenciamento de dados e assim por diante.

Devo dizer que muitas empresas muito grandes (incluindo feras como Google e Facebook) usam o MariaDB há muito tempo. Um conjunto especial de patches está circulando pela rede, que, após serem aplicados aos códigos-fonte do músculo original, resolvem muitos problemas. No entanto, não espere que eles apareçam no servidor oficial - se eles não foram homenageados por tantos anos, é improvável que eles decidam na próxima versão. Os desenvolvedores do MariaDB ainda estão livres de regras corporativas e restrições de marketing, então novos patches e correções de bugs são aceitos rapidamente.

Se o músculo original repousa sobre duas baleias - os mecanismos de armazenamento de dados InnoDB e MyISAM, o MariaDB usa o seu próprio, atuando como substitutos avançados. O mecanismo Aria substituiu o MyISAM e é realmente muito mais produtivo graças ao cache linha por linha e um formato de empacotamento de dados otimizado. Enquanto o MyISAM original era rápido ao custo de não transações, o que significava possível perda de dados, o Aria é eficiente e seguro. Devido aos formatos aprimorados para armazenar informações, o MariaDB se recupera de falhas muito mais rapidamente, sem exigir procedimentos separados para verificar os dados após uma falha. O mecanismo InnoDB da Oracle foi substituído pelo XtraDB, desenvolvimento de outra empresa de banco de dados, a Percona. Este último é conhecido por suas compilações de MySQL com patches integrados do Google e também por ferramentas de administração avançadas. A equipe tem uma história incomum (você pode ler mais na barra lateral) e agora está ativamente engajada na criação de um novo músculo. Para compatibilidade com versões anteriores do MySQL, o mecanismo XtraDB do MariaDB tem o mesmo nome, ou seja, InnoDB. Mas você precisa entender que, na verdade, apenas o nome foi preservado, para não confundir o software com identificadores incomuns.

O primeiro projeto da jovem empresa Oracle foi o desenvolvimento de um sistema de contabilidade por ordem de olheiros, para o qual outras empresas solicitaram $ 2.000.000 na competição, e o jovem Larry Alison arrogantemente indicou a quantia de apenas $ 300.000. Nem é preciso dizer que o projeto foi um fracasso, mas a empresa recebeu um capital inicial e iniciou sua ascensão.

Motores adicionais

Vale a pena falar sobre o XtraDB com mais detalhes: segundo muitos especialistas, é o mecanismo de banco de dados número um do mundo. Além disso, fornece o Oracle InnoDB como um pequeno :). A principal característica é o tão esperado suporte para sistemas multi-core e multi-processador, que o MySQL não quer (ou não pode?) se vangloriar. Os patches do Google resolveram esse problema há muito tempo, mas, como sempre, não se preocuparam em incluí-los no mecanismo original, então o MySQL fica muito atrás em termos de desempenho em qualquer benchmark. Os desenvolvedores do XtraDB melhoraram significativamente a estratégia de uso de I / O de disco, que anteriormente limitava o desempenho devido a freios com descarga de dados do cache para o disco. As opções correspondentes agora podem ser controladas com precisão nas configurações, o que permite que administradores especialmente avançados ajustem o desempenho do daemon sem recorrer a especialistas de banco de dados caros. Além disso, estatísticas detalhadas sobre a operação do mecanismo estão disponíveis imediatamente, o que elimina a necessidade de software comercial caro para analisar o desempenho do banco de dados. Apenas um comando SHOW ENGINE INNODB STATUS é necessário. E um ponto importante é a velocidade de recuperação após uma falha: se acontecer, a recuperação não será apenas rápida, mas quase reativa, muitas vezes até dez vezes mais rápida que no MySQL. Além de muitas outras pequenas coisas: buffers para registros, pontos de verificação adaptáveis ​​e um número maior de transações abertas. Tudo isso permitirá que o servidor se sinta bem em condições muito carregadas.

Se isso não for suficiente para você, e você acena com a cabeça para Firebird ou PosgreSQL, insinuando que há suporte total para o modelo transacional e até MVCC (Multiversion Concurrency Control é um modelo de dados competitivo baseado em versão que permite atualizar e ler sem bloquear a mesma linha de dados) - relaxe. O MariaDB tem o mecanismo PBXT disponível, que em algumas situações é ainda mais impressionante do que todos os anteriores. É verdade, vale dizer desde já que não é tão versátil e você precisa saber cozinhá-lo! O PBXT é adaptado principalmente para um grande número de transações que gravam ou alteram dados, suporta reversão rápida e é capaz de resolver situações complexas com bloqueios e impasses por conta própria. Por exemplo, se você deseja fazer um armazenamento de log, terá um grande número de operações de gravação na tabela, mas relativamente poucas leituras. Ao mesmo tempo, se alguém ainda quiser fazer uma seleção no banco de dados, receberá os dados mais recentes sem interferir no registro de novos. E para os realmente pervertidos, existe o mecanismo FederatedX, que pode distribuir uma tabela de dados para vários servidores físicos, além do OQGRAPH, que é otimizado para armazenar estruturas hierárquicas, gráficos e árvores. Uma abordagem ideal para criar um clone do Facebook e onde você precisa trabalhar com um grafo social de relacionamentos entre pessoas, o que não se encaixa bem com um modelo de banco de dados típico.

Computação em Nuvem

Os desenvolvedores de outro projeto - Drizzle - seguiram um caminho um pouco diferente e decidiram repensar completamente o lugar do banco de dados na infraestrutura de um projeto típico. Lembramos o que está na moda agora: computação em nuvem, Google Proto Buffers, escalabilidade, multi-core e assim por diante. E pensamos: o banco de dados também deve acompanhar as tecnologias modernas, e não ficar para trás, independentemente do que esteja girando nele - um mecanismo de blog ou um grande sistema corporativo de CRM. Às escondidas, foi decidido simplificar a funcionalidade do MySQL original, jogando fora os recursos que se estendem de lançamento para lançamento, que na realidade poucas pessoas precisam. O sistema perdeu o suporte para soquetes UNIX (embora esta seja uma solução controversa, mas bastante aceitável devido ao foco em ambientes de nuvem) e a versão para Windows. Em Garoa, não há bases de serviço e muitas outras coisas familiares. Mas o que há então?

O Drizzle, graças à sua arquitetura simples de microkernel e plug-in, pode fazer muito

E existe uma arquitetura com um microkernel, que contém todas as operações básicas e suporte de protocolo, além de um sistema de plug-in que permite expandir o sistema em qualquer direção e em qualquer profundidade. Como um dos principais componentes do sistema, é usado um protocolo binário do Google - Protocol Buffer. Com sua ajuda, as tabelas e os dados são descritos e também são usados ​​\u200b\u200bpara replicação. A principal ênfase no desenvolvimento está no suporte máximo para multithreading e multiprocessamento, portanto, a escalabilidade é a principal conquista dos desenvolvedores. Suporte implementado para o protocolo MySQL padrão e sua própria versão - através da biblioteca libdrizzle e drivers para as linguagens mais populares, incluindo Perl, PHP, Python e Lua. Se desejar, você pode usar a biblioteca do cliente sem o próprio servidor: neste caso, você obterá acesso assíncrono eficiente ao seu MySQL favorito. Como a mesma empresa também desenvolveu o sistema Gearman, o Drizzle tem suporte integrado para registro distribuído, cache de memcache nativo e até mesmo recursos avançados, como replicação por meio de sistemas de mensagens como RabbitMQ (incluindo a nova tecnologia WebSocket). Como o principal mecanismo de armazenamento de dados no Drizzle, uma versão especial do InnoDB é usada, significativamente redesenhada e complementada com um conjunto de patches de terceiros. Os mecanismos XtraDB e PBXT também estão disponíveis. Se as primeiras versões do Drizzle eram baseadas no MySQL 5.0, agora pouco resta do banco de dados original. Este é um código quase totalmente reescrito com o mínimo de consideração por ex-parentes. No momento, o desenvolvimento do Drizzle está em estado ativo e o primeiro lançamento estável está planejado para a primavera.

Tendência NoSQL

Você provavelmente conhece o newfangled. Na verdade, este é o abandono do servidor de banco de dados tradicional com suas tabelas e consultas SQL e a saída para o esquema de armazenamento de dados chave-valor mais simples (chave-valor). Para implementar este último, tipos de dados avançados são frequentemente usados, como listas / hashes (no Redis) ou, por exemplo, o formato JSON (no MongoDB). Mas o que o impede de cruzar uma jiboia e um ouriço, usando, por um lado, todo o poder e anos de tecnologia comprovada de bancos de dados e seus mecanismos e, por outro lado, um protocolo simplificado e a rejeição de uma camada pesada na forma de processamento de consulta SQL? Nada impediu os severos herdeiros do samurai: os japoneses de Yoshinori Matsunobu criaram um plug-in HandlerSocket que transforma o mecanismo InnoDB padrão em um armazenamento NoSQL avançado sem interferir no SQL regular. A velocidade de trabalho é impressionante: até 750.000 operações por segundo! Não é de surpreender que a Percona imediatamente tenha adotado esse plug-in, incluindo-o em suas compilações de servidor. Legal! Mas, por outro lado, de que outra forma, senão uma muleta, você pode chamar uma solução que imita o que um banco de dados normal como o Drizzle implementou imediatamente devido à arquitetura interna?

Tirar conclusões

Se você está preocupado com o desenvolvimento do MySQL, não gosta da política da Oracle e teme, com razão, que amanhã seja forçado a pagar pela funcionalidade que era gratuita ontem, dê uma olhada. A comunidade reagiu à compra do MySQL como o início do declínio de uma tecnologia que já levou a web moderna a alturas inatingíveis graças à pilha LAMP (Linux-Apache-MySQL-PHP). Os principais desenvolvedores começaram a desenvolver seus próprios garfos, alguns dos quais já estão muito acima do antigo MySQL. Atrás deles estão muitas figuras icônicas e uma comunidade aberta. Tendo feito tudo com sabedoria, os desenvolvedores conseguiram deixar 100% de compatibilidade externa com aplicativos e protocolos. Portanto, todos que desejam instalar um novo servidor não terão problemas: os dados serão salvos e os aplicativos não precisarão ser reescritos. Muitos não notarão a diferença, exceto pelo aumento da velocidade e confiabilidade.

Já agora você pode substituir seu servidor de banco de dados, para que os aplicativos existentes nem sintam a diferença, enquanto recebem muito mais velocidade, confiabilidade e muitos chips que não estão disponíveis no músculo original. O MariaDB com um conjunto de engines é um ótimo lugar para começar. Bem, se você tem um grande projeto em mente com muitos servidores e gigabytes de dados, veja o Drizzle. Como um produto de software e como um servidor de banco de dados, é um desenvolvimento muito promissor que definitivamente será lançado este ano. Se você deseja estabilidade e suporte dos melhores especialistas em banco de dados, não tenha medo de virar as costas para a Oracle e ir para a Percon. Os caras distribuem sua versão do DBMS gratuitamente - corrigindo bugs o máximo possível e adicionando recursos para aumentar o desempenho do MySQL original sem violar a compatibilidade. Você ainda está sentado no velho músculo? Então vamos até você!

A versão original do MySQL foi desenvolvida pela empresa sueco-finlandesa MySQL AB, fundada por Jvid Achmark, Allan Larsson e Michael Monty. A primeira versão do MySQL apareceu em 1995. Inicialmente, era destinado ao uso pessoal, mas depois de alguns anos se transformou em um banco de dados de nível empresarial.

Em janeiro de 2008, a Sun Microsystems adquiriu a MySQL AB por US$ 1 bilhão. Pouco tempo depois, a Oracle comprou a Sun Microsystems com a permissão da Comissão Européia, que inicialmente temia que tal decisão prejudicasse o projeto MySQL gratuito, já que era um concorrente direto do banco de dados Oracle. Devido à desconfiança da estratégia de desenvolvimento do MySQL, um fork chamado MariaDB foi criado.

Os anos se passaram e durante esse tempo o MariaDB começou a ser usado em muitas distribuições Linux por padrão. Ele é usado para garantir o funcionamento da maioria dos sites da Internet. Neste artigo, tentaremos comparar MySQL vs MariaDB e descobrir por que o segundo é melhor que o primeiro e quando o MySQL original é necessário.

Ao contrário de muitos outros projetos de código aberto recebidos da Sun Microsystems, a Oracle ainda está desenvolvendo o MySQL. Depois que muitos desenvolvedores se demitiram, novas pessoas foram contratadas. Mas o desenvolvimento de novas versões do MySQL está fechado. O código-fonte está disponível apenas para a equipe de desenvolvimento e é carregado no repositório público somente após a conclusão do trabalho. Todas as decisões são discutidas dentro da empresa

O MariaDB é desenvolvido de forma totalmente aberta, todas as decisões e novas ideias relacionadas ao desenvolvimento podem ser discutidas livremente no boletim informativo por e-mail, bem como no sistema de relatórios de bugs. É muito fácil contribuir com o desenvolvimento do MariaDB, patches de usuários são aceitos e também de desenvolvedores. Em geral, o MariaDB está se desenvolvendo mais ativamente.

Por causa da marca, o MySQL ainda tem uma grande comunidade, mas cada vez mais projetos estão migrando para o MariaDB. Distribuições corporativas conhecidas, como REHL 7 e SLES 12, já usam o MariaDB, o que significa que na batalha do MySQL ou do MariaDB, o último vencerá.

2. Frequência de lançamentos

A política da Oracle é lançar atualizações de segurança para todos os seus produtos a cada três meses. Mas uma nova versão do MySQL está programada para ser lançada a cada dois meses. Isso geralmente resulta em atualizações de produtos e atualizações de segurança não sendo sincronizadas.

Os desenvolvedores não têm tempo para fechar todas as mensagens de erro e vulnerabilidades, pelo que o banco de dados pode permanecer vulnerável por vários meses. Outro problema com o MySQL é que as atualizações de segurança são muito vagas. Se o administrador não puder simplesmente atualizar o programa para uma nova versão, criar um backport será difícil.

O MariaDB lança atualizações de programa e atualizações de segurança em sincronia para que quaisquer bugs sejam corrigidos. Todos os CVEs corrigidos são documentados e qualquer usuário pode saber o que mudou na nova versão.

4. Recursos e funcionalidades

Em geral, o MariaDB está se desenvolvendo mais rápido e possui mais recursos. Esses recursos estão relacionados à otimização, gerenciamento de memória aprimorado e muito mais. Normalmente, com o tempo, esses recursos são transferidos para o MySQL. Por exemplo, o mesmo suporte GIS apareceu no MariaDB antes do MySQL. Entre outras coisas, o MariaDB tem muitas melhorias de desempenho para Inodb, MyISAM e o mecanismo de processamento de consultas, suporta GIS, eliminação de tabelas, colunas virtuais e dinâmicas, replicação de várias origens, funções e muito mais.

Mas o MariaDB tem suas desvantagens, não suporta alguns dos recursos que o MySQL possui. Ou seja, MariaDB não é compatível com a sintaxe JSON do MySQL, plug-ins ngram, MeCab, MySQL X não são suportados, bem como tablespaces que permitem atribuir dados a várias tabelas ao mesmo tempo. Mas os desenvolvedores estão trabalhando ativamente para corrigir as deficiências.

Para quem se interessa por clusters MySQL, será interessante que o MariaDB utilize o novo sistema de replicação do Galera, o funcionamento dele é diferente do master-salve padrão. O Galera está em desenvolvimento desde 2007, mas nunca foi incluído no lançamento oficial do MySQL.

5. Suporte para mecanismos de armazenamento

O sistema de gerenciamento de banco de dados MariaDB oferece suporte a muitos outros mecanismos para armazenar dados. A maioria desses mecanismos está disponível como plug-ins para MySQL, mas no MariaDB eles estão incluídos no lançamento oficial. Isso significa que os motores estão devidamente integrados e funcionarão bem. Aqui está uma lista de motores suportados:

  • Ária;
  • XtraDB é uma versão melhorada do InnoDB;
  • FederatedX é uma versão aprimorada do Federated;
  • OQGRAPH;
  • SphinxSE;
  • IBMDB2I;
  • TokuDB;
  • Cassandra;
  • CONECTAR;
  • SEQÜÊNCIA;
  • Aranha;
  • ColunaStore;
  • MySIAM.

Deixe-me lembrá-lo de que o MySQL original suporta apenas três tipos de tabelas por padrão - Aria, MySIAM e InnoDB. Este é um aspecto importante na escolha de MySQL ou MariaDB.

6. Nome e numeração das versões

Essas diferenças entre MariaDB e MySQL não são tão importantes, mas talvez sejam do interesse de alguém. O nome MySQL foi dado em homenagem à primeira filha de um dos desenvolvedores - Michael Monty, o nome dela é My. O desenvolvimento do MariaDB foi continuado pela mesma pessoa, e desta vez o programa recebeu o nome de sua filha mais nova, Maria.

Quanto às versões, originalmente, antes da versão 5.6, as versões do MariaDB eram numeradas de forma sincronizada com as versões do MySQL nas quais eram baseadas. Mas quando mudanças suficientes se acumularam e o código MariaDB começou a ser tomado como base, era costume alterar os números da versão para 10. A partir desse momento, a numeração do MariaDB é feita da única maneira.

conclusões

Neste artigo, fizemos uma comparação entre MySQL e MariaDB. Em muitos aspectos, o MariaDB é muito melhor do que o MySQL, e é por isso que a maioria das distribuições do Linux agora o usa por padrão em seus repositórios. A versão original pode ser necessária apenas em casos muito raros.

Do autor: o sistema de gerenciamento de banco de dados tornou-se parte integrante do desenvolvimento de um produto web dinâmico. Com sua ajuda, você pode sistematizar todo o conjunto de arquivos necessários. Tudo isso é necessário para acesso rápido e otimização do aplicativo ou site. Mas levará décadas para dominar tudo, mesmo os mais populares. Deve ser determinado qual você usará, estudará e aumentará sua habilidade. A comparação mais popular é MariaDB vs MySQL. Vamos nos concentrar neles hoje. Não vamos esquecer os produtos que estão apenas ganhando popularidade, mas já possuem uma vantagem competitiva significativa.

sistema relacional

Antes de tais soluções serem inventadas, estava fora de questão criar produtos massivos. Mesmo aquelas máquinas que tinham uma boa quantidade de memória física e RAM não poderiam processar Big Data se fossem armazenados em uma ordem relativamente caótica - na forma de arquivos. No início dos anos oitenta, foi lançado o primeiro RDBMS, cujos desenvolvedores eram a IBM.

À primeira vista, criar um banco de dados parece uma tarefa muito trivial. Externamente, tudo parece simples, como uma grande mesa na qual diferentes tipos de informações são colocados em suas colunas. Na verdade, esta invenção foi precedida por uma série de discussões matemáticas e tentativas de desenvolvimento. O objetivo não era fazer um banco de dados simples, mas um em que as variáveis ​​dependessem umas das outras. A descrição mais precisa do futuro banco de dados foi dada pelo Dr. Codd, que formou as 12 regras do banco de dados relacional. A propósito, são 13 deles. Eles ainda são usados ​​hoje para desenvolver um banco de dados relacional.

Um sistema de gerenciamento de banco de dados relacional não deve usar nenhum método de gerenciamento diferente do relacional. Tudo isso pode parecer simples apenas para quem entende de termos matemáticos, pelo menos no nível ideológico. Deve haver um relacionamento relacional entre cada unidade atômica de dados, o que é muito melhor do que apenas arquivos espalhados pelo armazenamento físico.

JavaScript. Início rápido

Como dissemos, o SGBD é uma tabela, e o sistema não pode ter uma estrutura diferente. Mas os dados na tabela podem ser de tipos muito diferentes. Alguns DBMS não suportam tantos tipos, alguns até introduzem novos para tecnologia da informação. Estes são booleanos, strings, dados de ponto flutuante e muitos outros. E todos esses dados estão interligados de acordo com o modelo relacional.

No entanto, para gravar dados em uma string, ela deve receber um tipo de dados. Você faz um procedimento muito semelhante com células no Excel e programas semelhantes. É claro que existem exceções a essas regras, mas esse é um tópico para um livro inteiro, não nossa comparação de bancos de dados.

Quando se trata de sites e aplicativos, as células contêm dados sobre os usuários do recurso, o próprio conteúdo, produtos e qualquer outra coisa. O objetivo do banco de dados aqui é fornecer prontamente essas informações a pedido do usuário: um script de servidor, em troca de um script de cliente.

Vantagens e Desvantagens do SGBD

Concordo, se o DBMS tivesse mais desvantagens do que vantagens, ninguém os usaria tão ativamente. Se você comparar o sistema de arquivos e o site criado nele, verá como o sistema de gerenciamento de banco de dados funciona de maneira muito mais suave e eficiente. É por isso que vamos começar com aqueles pontos em que todos os sistemas, sem exceção, terão que trabalhar, seja MariaDB ou MySQL.

Entre as deficiências frequentemente discutidas dos sistemas de gerenciamento de banco de dados modernos estão:

não é fácil de dominar. Para trabalhar com o Photoshop, você precisa estar familiarizado com as ferramentas básicas deste software e aprender a usá-las. Não é necessário entender como o programa em si funciona. Isso não pode ser dito sobre o DBMS. Entender como o MySQL funciona significa entender bancos de dados. Se você está tentando seguir um padrão, provavelmente o desenvolvimento falhará. Não se sabe o que é melhor: não entender o SGBD em princípio, ou entendê-lo incorretamente;

preço. O próprio sistema de gerenciamento de banco de dados pode não custar muito, mas manter o banco de dados, adquirir software de terceiros e outros. Até mesmo hospedar um extenso banco de dados em um bom host custa dinheiro.

peso. Os arquivos sozinhos para um aplicativo altamente funcional vão pesar muito. E se você envolvê-los em um banco de dados, o volume aumentará significativamente, porque agora os arquivos têm algumas funções, estão em uma conexão lógica e são chamados por scripts. Tudo isso custa não apenas dinheiro, mas também memória no servidor. Isso é especialmente perceptível se o computador pessoal do desenvolvedor servir como servidor.

colocação centralizada. Somente nos últimos anos os desenvolvedores começaram a usar um registro distribuído para armazenamento de arquivos. Quando os arquivos estão no mesmo banco de dados, eles são vulneráveis.

Felizmente, a maioria dessas deficiências é coberta pelas vantagens do DBMS. Se você perguntar aos programadores da web o que é melhor: arquivos ou DBMS, a resposta será óbvia. O sistema abre muitas possibilidades que não estão disponíveis para nenhum sistema de arquivos.

Primeiro, é economia de memória. Embora o próprio SGBD ocupe um determinado lugar, ele não permite que informações desnecessárias se multipliquem. Sem redundância, sem arquivos duplicados. Ao mesmo tempo, as informações que deveriam ser armazenadas em excesso são armazenadas dessa maneira. Como dissemos, este é um modelo matemático complexo e difícil de entender para um desenvolvedor comum.

É importante que o SGBD evite verdades duplas. O sistema seleciona independentemente elementos que fornecem informações do mesmo tipo e garante que eles não se contradigam. Acontece que com o mesmo volume, o produto recebe uma quantidade muito maior de informações.

Os sistemas de gerenciamento de banco de dados desempenham um papel importante no desenvolvimento conjunto. É bastante difícil fornecer acesso de grupo a uma árvore de arquivos, observando todas as precauções. Porém, você pode fornecer acesso autorizado ao DBMS a um círculo limitado de pessoas, sem prejuízo para o sistema de segurança.

JavaScript. Início rápido

Aprenda o básico de JavaScript com um exemplo prático de construção de uma aplicação web

A propósito, sobre armazenamento seguro. Hoje é difícil implementar melhor o armazenamento de dados do que com um DBMS moderno. A implementação do DBA permite determinar as medidas de segurança necessárias: o que poderia ser melhor? Além disso, novas ferramentas de proteção de banco de dados são lançadas diariamente. O acesso geralmente é feito por meio de uma forma de varredura, mas com habilidade suficiente, você pode implementar tudo, desde antropometria até autenticação de dois fatores. Isso se aplica especialmente ao DBMS de código aberto, que é o MariaDB (falaremos mais sobre isso posteriormente).

É difícil imaginar algo melhor em termos de backup do que sistemas de gerenciamento de banco de dados. Se você armazenar o aplicativo em arquivos, a segurança dos dados estará em suas mãos. Você é forçado a criar backups e as cópias necessárias a tempo. O DBMS pode fazer isso em intervalos definidos e transferir informações para uma mídia externa ou para a nuvem.

MySQL: sucesso merecido

Definitivamente, este é o mais popular de todos os DBMS existentes. Não apenas aplicativos da web e softwares complexos são construídos sobre ele: a contabilidade de materiais na biblioteca de sua cidade provavelmente é implementada usando MySQL ou MSSQL. A funcionalidade deste sistema obriga os concorrentes a apresentar cada vez mais novas soluções. Mas os próprios desenvolvedores não estão muito atrás: a versão mais recente do software foi lançada recentemente. Eles não interrompem sua periodicidade há mais de vinte anos.

Anteriormente, esse desenvolvimento era propriedade da Sun Microsystems, que nos forneceu o Java e muitas outras ferramentas de desenvolvimento. Em 2010, todos os produtos, juntamente com o MySQL, foram transferidos para a Oracle. Ele mantém o DBMS até hoje.

vO sistema foi originalmente desenvolvido pela empresa de mesmo nome em 1995. Os criadores usaram as linguagens de programação mais rápidas: C, C++ e HTML. Assim, os desenvolvedores têm à sua disposição um SGBD estável e rápido com suporte constante. Hoje, o MySQL faz parte das chamadas "suítes de cavalheiros", que consistem em um servidor, um banco de dados e uma linguagem de programação de script.

A usabilidade pode ser considerada uma clara vantagem do MySQL sobre seus concorrentes. Como sempre, quanto mais popular o software, mais fácil é trabalhar com ele. Todos os bugs são encontrados rapidamente, com a mesma rapidez e correção. Não se esqueça que este é um software para programadores e desenvolvedores, que está se desenvolvendo rapidamente graças à comunidade. Novos plugins e várias extensões para MySQL estão aparecendo constantemente.

Instalar o MySQL é extremamente fácil. Graças à presença de uma GUI - uma interface gráfica do usuário, isso se transforma em uma instalação de software regular. O mesmo se aplica à instalação de adições ao DBMS.

É impossível não mencionar que o MySQL é um dos SGBDs mais multiplataforma. Sente-se a mão da Sun, para a qual o lançamento do software "pelo menos na calculadora" foi uma prioridade. O que dizer sobre escalabilidade: quase todos os maiores recursos com os quais você trabalha na rede são construídos sobre o MySQL. Embora existam opções mais profissionais, por exemplo, PostgreSQL, das quais não nos esquecemos.

"Maria" como a melhor em SGBD

Como todos os projetos de código aberto, o MySQL teve um fork bem-sucedido, chamado MariaDB. Tanto o DBMS pai quanto sua ramificação levam os nomes das filhas do criador: Mu e Maria. Este sistema é usado para ser chamado de uma alternativa ao MySQL, mas esta é uma afirmação fundamentalmente errada. Embora o debate sobre qual é o melhor, Maria ou My ainda esteja em andamento.

O objetivo dos desenvolvedores de Maria era criar um produto totalmente compatível com o MySQL, mas muito aprimorado. Por exemplo, o mecanismo de armazenamento de dados do MySQL era o MyISAM. Em Maria, este é o Aria, que deu ao SGBD maior desempenho em relação ao projeto principal. E, embora o MariaDB seja baseado no MySQL, as versões mais recentes não contêm mais de 25% do código original.

Maria apresenta melhor desempenho geral. Isso é especialmente verdadeiro para a conversão de caracteres. Em grandes volumes de informação, o coeficiente chega a mais de 2%. O código de depuração também é otimizado em comparação com o MySQL. Em geral, os desenvolvedores observam a maior velocidade de desenvolvimento do que o "pai" poderia fornecer. A comunidade por trás do MariaDB promete ainda mais melhorias.

Além disso, o próprio usuário pode melhorar e otimizar o trabalho de Maria. O que distingue este DBMS de todos os outros é um código-fonte aberto completo: sem elementos ou módulos fechados, tudo está disponível. Você pode brincar com o código indefinidamente, bem como fazer sugestões de mudanças para a comunidade que desenvolve o MariaDB.

Reivindicação de vitória do Postgres

O PostgreSQL é outro sistema de gerenciamento de banco de dados, não apenas relacional, mas relacional a objetos. Isso significa que o próprio usuário pode criar objetos para operações, que podem incluir vários dados. É totalmente gratuito e o mais flexível. Alguns desenvolvedores consideram o PostgreSQL a solução mais profissional do mercado. Este DBMS veio de um projeto universitário sem fins lucrativos criado em Berkeley chamado Postgres. Este sistema foi desenvolvido por longos oito anos e é suportado até hoje.

Como acontece com esses produtos, acabou "de programadores para programadores" - incrivelmente funcional, mas muito difícil de dominar para o desenvolvedor médio. Inicialmente, o SGBD tinha até uma linguagem de consulta própria, mas depois essa ideia foi abandonada, deixando uma "sequência" trivial. Apesar do entusiasmo dos desenvolvedores independentes, o PostgreSQL não é tão bom quanto eles gostam de chamá-lo. Até agora, as áreas problemáticas são encontradas no código-fonte.

Em termos de escalabilidade, PostgreSQL não é inferior quando comparado com MySQL e MariaDB. Projetos massivos de processamento de Big Data são construídos com base neste software, pois sua estabilidade é confiável para os desenvolvedores. Diversas opções de interface disponibilizam o produto para personalização.

Mas o PostgreSQL ainda está longe de ser um produto de massa. O fato é que esse sistema é muito complicado para um simples desenvolvedor. Mesmo se você pegar a documentação, não obterá respostas para todas as perguntas, incluindo as mais lógicas. Além disso, a velocidade de execução da consulta no PostgreSQL confunde.

Este DBMS é ótimo para soluções corporativas. Por exemplo, um banco de dados para uma empresa de TI, onde cada um dos desenvolvedores pode cuidar do seu suporte. Além disso, o PostgreSQL é totalmente gratuito.

É tudo o que temos. Lembre-se que em decisões tão complexas como um DBMS, é difícil nomear um líder. Em termos de uso, é MySQL, em termos de extensibilidade, MariaDB e PostgreSQL. Assim que obtivermos um produto que se tornará uma panacéia para todos os casos, com certeza iremos informá-lo.

JavaScript. Início rápido

Aprenda o básico de JavaScript com um exemplo prático de construção de uma aplicação web

Desde outubro de 2011, estamos atualizando nossos servidores de banco de dados para substituir o MySQL por uma nova versão: MariaDB.

O que é o MariaDB?

MariaDB é um banco de dados alternativo ao MySQL desenvolvido pelo autor do MySQL Michael "Monty" Widenius. O principal objetivo do projeto MariaDB é criar uma versão do SGBD totalmente compatível com o binário do MySQL original, que ao mesmo tempo terá um número significativo de melhorias no código que afetam o desempenho. O MariaDB está sendo desenvolvido como um substituto para o MySQL, imitando completamente o comportamento do MySQL.

Por que Monty decidiu fazer um clone de sua própria ideia? O fato é que os direitos do MySQL pertencem à MySQL AB, que foi comprada primeiro pela Sun Microsystems e depois a Sun foi vendida para a Oracle Corporation. No final, Monty decidiu deixar a Oracle e fazer, de certa forma, o MySQL "com esteróides".

MariaDB: o que há de novo nele?

As versões 5.1, 5.2 e 5.3 (beta) do MariaDB são baseadas no código MySQL 5.1, mas com várias inovações e melhorias.

Primeiro, é uma série de novos mecanismos (mecanismo de banco de dados) para armazenamento de dados. A saber: Aria é uma alternativa às tabelas MyISAM, mais rápida e robusta. As tabelas Aria são usadas no MariaDB para necessidades internas, em particular, todas as tabelas temporárias funcionam no mecanismo Aria, devido ao qual, em alguns casos, foi possível obter um desempenho significativamente superior em consultas complexas. Além disso, as tabelas InnoDB foram substituídas por XtraDB (alternativa da Percona ao InnoDB), que também é mais rápida que a original e mais robusta.

Além disso, cerca de um terço do código MySQL original foi reescrito no MariaDB, graças ao qual foi possível eliminar muitos gargalos do MySQL, melhorar o desempenho em sistemas multiprocessadores e, claro, melhorar a estabilidade.

O MariaDB também possui uma nova maneira de acessar os dados do InnoDB - HandlerSocket. HandlerSocket é, de certa forma, uma alternativa ao memcached. Por meio da interface HandlerSocket, você pode trabalhar com dados em tabelas InnoDB (XtraDB) como com um conjunto de dados chave-valor, onde qualquer um dos índices criados em qualquer uma das tabelas InnoDB atua como uma chave. Em termos de velocidade, o HandlerSocket é quase tão bom quanto o memcached, e algumas fontes até relatam que conseguiram obter um desempenho melhor do que com o memcached.

Testes Comparativos

Para entender se o jogo vale a pena e se as otimizações feitas no MariaDB são realmente perceptíveis à vista, realizamos uma série de testes comparativos. Os testes foram realizados em um servidor configurado com HP ProLiant DL160 G6, 2x E5520 Xeon QC CPU (16 núcleos), 20 Gb RAM, H/W RAID 10: 4x 300 Gb SAS 15k RPM. O utilitário mysqlslap foi usado como teste da seguinte forma:

mysqlslap --auto-generate-sql --concurrency=$i --number-of-queries=$(($i*500)) --iterations=3

ou seja, mudamos a variável $i de 10 para 200 em um loop, emulando a operação simultânea de 10 a 200 clientes, cada um fazendo 500 consultas ao banco de dados. Em seguida, medimos o tempo total de execução do teste. Os testes foram realizados no MariaDB versão 5.1 versus MySQL versão 5.1

Tabelas MyISAM

Abaixo estão os gráficos das medições de desempenho do MySQL (gráfico superior) e MariaDB (gráfico inferior) em tabelas MyISAM. O eixo X mostra o número de clientes trabalhando simultaneamente, o eixo Y mostra o tempo em segundos gasto no teste.

Como interpretar os resultados: quanto mais baixo o ponto no gráfico, mais rápido o teste funcionou. A julgar pelo gráfico, já começando com 60 clientes simultâneos, o MariaDB completou os testes quase 1,5 vezes mais rápido que o MySQL.

tabelas InnoDB

Aqui a situação é semelhante: o MariaDB venceu, mas a vantagem aqui é muito mais significativa: o desempenho do InnoDB no MySQL é várias vezes pior do que o desempenho do XtraDB no MariaDB.

Deve-se notar também que este teste mediu o desempenho de trabalhar com apenas uma tabela, portanto, o crescimento do desempenho em JOIN "s, e principalmente em consultas que são executadas criando tabelas temporárias, não é visível nesses gráficos. Na realidade, quando ao mudar para MariaDB, mesmo para tabelas MyISAM, o desempenho do banco de dados pode aumentar várias vezes.

Observe que a versão 5.1 do MariaDB, na qual os testes acima foram realizados, é a versão inicial contendo um conjunto mínimo de melhorias. Na verdade, usamos o MariaDB 5.2 nos servidores e, com o tempo, planejamos mudar para o MariaDB 5.3, onde há ainda mais melhorias e otimizações.