Você sabia que existem alternativas? Um banco de dados NoSQL é um deles, e tem seus casos de uso, mas que vai precisar de alguma consideração, e certamente algum reescrita da sua aplicação, para tirar vantagem. Em vez disso, deixe-me falar com você sobre alguns bancos de dados que falam a sua língua aplicações, nomeadamente protocolo do MySQL do servidor do cliente .
Uma rápida recapitulação
MySQL AB foi fundada por Michael Widenius (Monty), David Axmark e Allan Larsson em 1995. Após o lançamento da série 3.xe 4.x, MySQL 5.0 chegou em nossos servidores, em 2005, trazendo grandes mudanças com novas funcionalidades e melhor desempenho ao longo dos lançamentos 4.x. Em 2008, Sun Microsystems adquiriu a MySQL AB. Depois de ser crítico do processo de lançamento para 5,1, Monty deixou a Sun em 2009 para formar Monty Program AB . Também em 2009, a Oracle fez uma oferta para adquirir a Sun , que alcançou a aprovação final em 2010. Desde então, a Oracle ter lançado MySQL escalabilidade 5,5 trazendo melhorias e monitoramento.
Essas mudanças de propriedade e de mudanças de pessoal, em meio a preocupações com a direção de desenvolvimento do MySQL, que desencadeou uma próspera comunidade de bancos de dados baseado no código-fonte aberto MySQL, desenvolvido por pessoas que têm idéias fortes da direção que "gostaria de ver MySQL tomar.
As Alternativas
Percona Server com XtraDB
Percona foi fundada por Peter Zaitsev, um dos peritos foremost em mundos de alta performance MySQL, depois de ter executado o "High Performance MySQL" grupo dentro do grupo MySQL AB de apoio de 2002 a 2006. Percona Server é um patch de compilação do MySQL com armazenamento Percona do XtraDB motor , que por sua vez é baseada no armazenamento do MySQL InnoDB motor. Os remendos aplicados têm sido desenvolvidos para resolver os problemas do mundo real encontradas pela equipa Percona. Essas manchas são facilmente disponíveis e muitas vezes são integrados de volta em versões do MySQL. O mecanismo de armazenamento XtraDB visa melhorar o desempenho ea escalabilidade que acima do motor de armazenamento InnoDB, aproveitando recursos de hardware que não estavam disponíveis ou eram relativamente incomum quando InnoDB foi inicialmente concebido, como múltiplos núcleos de processamento.
MariaDB
Monty formado Monty Program AB para, entre outras coisas, continuar a desenvolver MySQL na direção que ele achou que deveria ir. Para conseguir isso, ele bifurcou MySQL e nomeou o MariaDB garfo. Os principais objectivos do projecto são MariaDB para criar um modelo de desenvolvimento mais aberto para incentivar a participação da comunidade e proporcionar um drop-in completo substituto para o MySQL. Características da base de código do MySQL são regularmente fundiram-se para trazer correções e ajudar a manter a compatibilidade, embora tenha havido algumas críticas sobre a rapidez com que isso acontece. No topo desta MariaDB olha para melhorar o desempenho e adicionar novas funcionalidades e melhor.
Garoa
Em 2008, Brian Aker, que anteriormente era diretor do MySQL de Arquitetura, bifurcado MySQL para criar o projeto garoa. O projeto Regue segue um processo semelhante ao processo de desenvolvimento do Kernel Linux, promovendo o controle da comunidade sobre o controle de uma empresa, tanto ao nível do código e ao nível de desenvolvimento. Ele foi projetado como um pluggable micro-kernel extensão promovendo fácil. Enquanto Regue foi inicialmente uma ramificação do código-base MySQL 6.0, os esforços foram feitos para favorecer o desempenho ao longo compatibilidade com MySQL, particularmente com referência à performance para múltiplos núcleos e implantações em nuvem.
Qual deles devo usar?
Depois de ler este artigo, resistir à tentação de sair correndo e instalar uma das alternativas em seu hardware de produção! Se depois de ler este artigo você decidir investigar a migração, eu recomendaria altamente aferir o desempenho, estabilidade e compatibilidade das alternativas contra a sua aplicação. Na verdade, é menos de uma recomendação e mais de uma exigência. Se você tirar nada do presente artigo, deve ser que cada uma das equipes se concentraram em áreas diferentes do MySQL. Qual delas funciona melhor para você depende de sua carga de trabalho do aplicativo. O que funciona melhor para transferência sustentada de curto execução de consultas simples não é necessariamente vai funcionar melhor para os lotes de longa execução de consultas complexas. Se eles continuam a divergir para satisfazer as necessidades diferentes ou se um dos projetos consegue integrar com sucesso as melhores características de todos os projetos para criar um banco de dados über-continua a ser visto. Se isso acontecer, então você começa a ter tudo, mas para agora para encontrar o melhor banco de dados para você, você vai precisar de referência, benchmark, benchmark!
Compatibilidade
Percona Server e MariaDB
Ambos Percona e MariaDB são binários compatíveis. Você pode pegar um pacote com qualquer um, extraí-lo parar MySQL, início Percona / MariaDB, carregar o seu cliente e iniciar a execução de consultas como se tivesse acabado de MySQL reiniciado. Este é um excelente ponto de partida para testar a sua aplicação e ver o que as melhorias que você sair da caixa, também é muito bom para o benchmarking, pois significa que você não tem que migrar seus dados para fazer comparações.
Compatibilidade garoa
O Regue bolota caiu mais distante do carvalho que é MySQL. Enquanto eles compartilham um ancestral comum, Drizzle já não é binário compatível com o MySQL e, portanto, mais cuidado deve ser tomado durante a migração. Aqui está o que a maioria das pessoas precisa saber:
Regue suporte InnoDB, mas os formatos de arquivo do InnoDB são diferentes . Isto significa que você tem que transformar os seus dados, você não pode simplesmente começar a garoa e apontá-lo para seus arquivos de MySQL.
MyISAM é suportada apenas para explicitamente criadas tabelas temporárias, e se espera que seja completamente indisponível em uma versão futura.
MERGE, FEDERATED, ARCHIVE e mecanismos de armazenamento de CSV foram todos removidos.
Triggers e pontos de vista não são suportados nativamente, ganchos no entanto apropriados são fornecidos para permitir que estes sejam adicionados como plugins
MySQL armazenados procedimentos de implementação foi considerado abaixo do ideal e foi removido . Não há nenhuma indicação de que este irá ser reimplementados, eles estão favorecendo lotes melhorado de comandos sobre o fio para reduzir o tempo de bloqueios de linha são realizadas, que é a principal vantagem de procedimentos armazenados em decisão MySQL.This também se encaixa com o objectivo de reduzir Drizzle banco de dados complexidade.
Algumas funções e comandos e palavras-chave foram removidos
Alguns objectos foram removidos. Uma regra de ouro, como o que foi removido é o lugar onde havia previosuly TINY- , PEQUENA e MÉDIO tipos, existe agora um tipo otimizado. Aliases também têm sido removido, por exemplo, SET foi removido deixando ENUM . A lista completa de objetos removidos está disponível.
A maioria dessas alterações são susceptíveis de afectar a sua administração de banco de dados mais do que a sua execução, à aplicação aderindo à idéia de que você ainda deve ser capaz de largar Regue com pouca ou nenhuma mudança para a sua aplicação.
Para simplificar a migração de dados do MySQL a chuviscar, Drizzle fornecer a ferramenta drizzledump . Embora concebido para backup Regue, ele pode se conectar a um servidor MySQL e produzir uma exportação Regue-compatível. Ele gerencia os problemas de compatibilidade acima para você, por exemplo, conversão de tipos de dados nas definições de tabela. Se você tem dois servidores viver, drizzledump pode até importar a partir do MySQL em linha reta em Regue sem um arquivo intermediário.
Características
Não só as alternativas oferecem melhor desempenho para alguns casos de uso, mas eles também oferecem recursos adicionais que não estão presentes no MySQL. Decidido a tirar proveito desses recursos significa que você se afaste da MySQL compatibilidade e portabilidade, mas se há uma característica do assassino que pretende utilizar na sua aplicação, então, adotar a alternativa, mas esteja ciente deste trade-off. Enquanto você ainda está decidindo sobre o melhor servidor de banco de dados para você, que você precisa para rastrear e isolar estas mudanças para que você possa alternar entre as alternativas. Eu sugiro a criação de uma sucursal, ou equivalente, em seu sistema de controle de versão para a mudança de aplicação. É a versão vale controlar o seu banco de dados de configuração, bem como, se você ainda não estiver (você pode ler mais sobre isso no pós Harrie sobre controle de versão de banco de dados ). Mesmo melhor, você poderia usar uma ferramenta DevOps como cozinheiro ou fantoche para criar implementações de banco de dados reprodutíveis, mas isso é assunto para outro artigo.
Percona Server com XtraDB
XtraDB
Percona Server vem com XtraDB, um substituto para o mecanismo de armazenamento InnoDB. Oferece compatibilidade com InnoDB, então tudo que você pode fazer com InnoDB trabalha com XtraDB. As diferenças são melhorou o desempenho, o que nós vamos cobrir em breve, diagnóstico e confiabilidade. Se você já teve problemas devido a corromper tabelas InnoDB você ficará contente em saber que XtraDB lhe dá um erro de tabela corrompida em vez de um crash.
HandlerSocket
HandlerSocket é um plugin daemon MySQL que lhe dá uma interface NoSQL para mecanismos de armazenamento do MySQL. É rápido! Benchmarks têm mostrado que apoio quase o dobro do número de consultas por segundo como memcached. É isso mesmo, não duas vezes mais rápido que o acesso do cliente MySQL (que é quase 7 vezes mais rápido, na verdade), mas quase duas vezes mais rápido que o memcached.
Percona Server vem com o plugin HandlerSocket construído e pronto para ser executado com apenas um par de linhas de config. O plugin HandlerSocket pode ser construída para MySQL, bem como, mas os navios Servidor Percona com ele pronto para ir, e inclui documentação sobre sua configuração de modo, para esse esforço, ele vai para baixo como um recurso para o servidor Percona.
Diagnósticos e Monitoramento
Negócio Percona está analisando instalações do MySQL com problemas de desempenho e fornecer soluções. Isto não seria possível sem ser capaz de identificar primeiro o problema. Embora o MySQL fornece alguns indicadores de status e desempenho, Percona descobriram que ficou aquém assim, durante o curso do seu trabalho, eles escreveram muitas melhorias e adições à comunicação de Percona status do servidor e de desempenho. Percona Server agora oferece mais de 20 mesas mais em INFORMATION_SCHEMA estado e 60 mais e os contadores de desempenho, juntamente com falhas de desempenho por tabela, por índice, por cliente e por segmento, e isso ainda não é uma lista completa de recursos de diagnóstico adicionados no Percona Servidor ! Uma característica do MySQL que você pode estar familiarizado com o log de consultas lentas, também teve alguns acréscimos, trazendo a precisão de microssegundo para consultar os tempos de execução, estatísticas de consulta adicionais ea capacidade de ativar e desativá-lo em tempo de execução. Com esta informação mais facilmente acessível, a aplicação e otimização de banco de dados se torna mais simples, os gargalos se tornam mais fáceis de identificar e os problemas são resolvidos mais rapidamente, todos os quais são tão importantes para o desenvolvimento de aplicativos, como apertar um melhor desempenho de MySQL fora da caixa.
MariaDB
Outros mecanismos de armazenamento
MariaDB oferece mecanismos de armazenamento adicionais que podem oferecer otimizações para modelos de dados específicos.
Aria: Destinado a ser um mecanismo de armazenamento transacional totalmente comparáveis com InnoDB e planejado para ser o motor de armazenamento padrão para MariaDB
XtraDB: Este é o mesmo motor, como discutido acima e desenvolvido por Percona
PBXT: Um mecanismo de armazenamento transacional originalmente desenvolvido pela Primebase, agora incorporada pela árvore de desenvolvimento MariaDB e mantido lá
FederatedX: Um substituto para o mecanismo de armazenamento federada
OQGRAPH: Um mecanismo de consulta projetado para lidar com heirarchies e gráficos complexos. Mais informações podem ser encontradas em http://openquery.com/graph/doc .
SphinxSE: Enquanto implementado como um mecanismo de armazenamento, este plugin realmente oferece uma conexão com um servidor de pesquisa esfinge.
IBMDB2I: O MySQL motor de armazenamento IBMDB2I que foi removido no MySQL 5.1.55
Declaração HandlerSocket e HANDLER
MariaDB também vem com HandlerSocket como eu mencionei acima para o servidor Percona. Ele também tem acesso ao armazenamento direto um passo adiante, adicionando uma instrução HANDLER permitindo direto lê a partir de mecanismos de armazenamento através de pesquisa de chave, permitindo o acesso de baixo nível que ultrapassa o otimizador de consulta. Isso pode oferecer a um aumento de desempenho de 50%, mas cuidado que ele não oferece consistência. Há também alguns casos em que pode acabar mal , como sempre com grande poder vem grande responsabilidade.
Colunas virtuais e colunas dinâmicas
Se você já usou Oracle ou MSSQL você pode já estar familiarizado com colunas virtuais. Para aqueles que não tê-los visto antes, elas permitem que uma coluna derivada em sua mesa. Eles operam em dois modos, VIRTUAIS e PERSISTENTE . A se comportam da mesma, mas são implementadas de forma ligeiramente diferente. PERSISTENTES colunas virtuais são calculados e escrita em linha escreve, enquanto VIRTUAL colunas virtuais são calculados quando a linha é ler. Que você usa depende se você precisa melhorar o desempenho em leitura ou escrita.
Colunas dinâmicos permitem que você armazene colunas diferentes para cada linha em uma tabela. Um caso de uso para isso é uma tabela de produtos segurando vários tipos de produtos, cada um com atributos diferentes. Muitas vezes isso é feito através da criação de uma estrutura EAV mantido por um aplicativo, no entanto, linhas dinâmicas pode fornecer uma solução mais simples (eu sei que parece NoSQL, mas não é, a promessa ;)). Ele é implementado por armazenar os colunas dinâmicas em uma bolha e fornecer funções nativas para acessar esses dados. Embora a implementação atual é estável e utilizável, existem algumas limitações e melhorias estão planejadas para resolver essas limitações. O objetivo é permitir colunas dinâmicas para ser quase indistinguível de colunas normais.
Regue foco no desempenho e simplificação levou a equipe Regue projetar uma arquitetura microkernel, suportando plugins para fornecer recursos ao invés de implementá-las no núcleo. Isto simplifica o processo de adição de funcionalidades que esperamos cultivar um ecossistema de plugins garoa e desenvolvedores de plugins garoa. É claro que o desenvolvimento de uma próspera comunidade de desenvolvimento em torno Regue é a intenção, como tem sido feito o mais simples possível para desenvolver e construir plugins. Como observado por Padraig O'Sullivan, este é "pânico awesome ' .
Até o momento existem 75 plugins Regue oficiais que cobrem tudo, desde a autenticação (Esquema, LDAP, HTML, arquivo, Permitir tudo) para protocolos de servidor (MySQL, Chuvisco) para mecanismos de armazenamento (InnoDB, MyISAM, Memória). Há algumas críticas a esta abordagem, como as pessoas são usadas para aplicações monolíticas e esperam recursos para estar disponível sem a necessidade de decidir quais plugins estão ativados, com a autenticação é o exemplo normalmente citado. Pessoalmente, eu gosto da abordagem plugin, mas não é para todos. Como quase tudo o que é um plugin, a maioria dos plugins fornecer funcionalidade que está presente no núcleo do MySQL, por isso não vou entrar em aqueles. Aqui é o melhor do resto:
Plugins de autenticação
Autenticação não está mais vinculado a uma tabela no esquema MySQL. Um dos plugins de autenticação mais interessantes é o plugin LDAP, permitindo que você use o seu servidor central LDAP para autenticação ao invés de manter uma lista separada de credenciais dentro de seu servidor de banco de dados, porém este pode ser complexo, se você ainda não usa LDAP em seu organização. Para o desenvolvimento você pode querer usar o plugin PAM para que você possa fazer login com suas credenciais usuais linux. Se você está feliz com a maneira como o MySQL de fazer as coisas, o plugin de autenticação esquema permite autenticar as credenciais armazenadas no banco de dados. Qualquer que seja o esquema de autenticação que você escolher, você provavelmente vai querer desabilitar a opção "Permitir Tudo" plugin que permite acesso irrestrito.
Plugin Console
Com o plugin do console ativada, você pode se conectar diretamente ao banco de dados, nenhum cliente exigido. Como este é como a maioria dos programas de outros * nix, basta conectar STDIN e STDOUT, isso permite a tubulação de entrada e saída diretamente de e para Regue sem um cliente intermediário.
JS Plugin
Este plugin adiciona a função JS usuário que irá executar um trecho de javascript dentro de uma instrução SQL. Tem construído em um analisador JSON para que você possa armazenar e operar em cordas JSON no banco de dados. Tanto o analisador JSON e intérprete JS são implementadas pelo mecanismo do Google javascript v8. No momento, não é uma linguagem de primeira classe dentro Regue, mas há planos para permitir que ele seja usado como uma linguagem para escrever procedimentos armazenados.
Memcached
Para a maioria das aplicações, o cache é uma boa idéia (TM). Memcached é comumente usado na mesma pilha como MySQL, e Chuvisco tem alguns truques na manga para tornar isso mais fácil. O padrão de acesso normal é:
Se uma chave não estiver presente no cache, consultar o banco de dados
uma vez que temos as informações do banco de dados, empurre-o de volta para o cache
Regue com o memcached_functions plugin, podemos enviar os dados para fora memcached na mesma instrução SQL que usamos para recuperar os dados. Isto dá-nos algumas possibilidades interessantes. Como cerca de um gatilho para preparar o cache quando dados são inseridos Regue, ou invalidar cache quando as linhas são deletadas? O único problema ligeiro com isso é que não existe um plugin que implementa dispara, mas eu tenho certeza que um não demorará a chegar.
Filas de mensagens
Regue oferece plugins para publicar transações tanto RabbitMQ e ZeroMQ . Se você está atualmente pesquisa o banco de dados para dados novos, o que permitirá que você mova a carga de seu banco de dados para uma fila de mensagens, proporcionando uma melhor escalabilidade. Também poderia ser usado como uma base para a replicação de Drizzle para outras lojas de dados.
O log de consultas
Se o plug-in log de consultas é carregado, por padrão ele registra nada. Isto pode ser controlado em tempo de execução que permite o registro de consultas específicas ou globalmente em momentos ou eventos específicos. Isso significa que ele só registra na demanda, e mais importante, não requer a reinicialização do servidor para ativá-lo ou desligado. Também é possível registrar as consultas para um servidor Gearman para processamento. Há pelo menos uma pessoa lá fora, usando Gearman para integrar Regue com o MySQL Enterprise Monitor.
Replicação
Replicação teve uma revisão completa de suas origens MySQL. A replicação é implementada por eventos de replicação armazenamento como Google buffer Protocolo mensagens em uma tabela InnoDB. Armazenar os eventos de replicação em um formato padronizado em uma tabela de fácil acesso significa que escrever plugins de replicação e clientes se torna muito mais fácil, simplificando a replicação de dados entre diferentes formatos e tecnologias.
Execução
Como já mencionado, cada variante tem seus pontos fortes e fracos. Atualmente, nenhum dos contendores, incluindo MySQL, oferecem uma melhor completa, ou pior perfil de desempenho, para todos os casos de uso. Se eu aferido todos os quatro bancos de dados em hardware idêntico para diversas cargas de trabalho com vários níveis de simultaneidade eu poderia facilmente estar aqui durante semanas. Então, para fazer tudo que eu escrevi sobre os recursos e compatibilidade relevante no momento em que você ler isso, eu estou indo dar-lhe os destaques destiladas e objetivos de cada projeto. Eu também não posso enfatizar o suficiente que o desempenho é extremamente dependente da carga de trabalho , o que significa que a única maneira de ter certeza de qual servidor de banco de dados irá funcionar melhor para você é a referência contra a sua aplicação. Então vamos dar uma olhada nos concorrentes:
Percona
A maior parte das melhorias de desempenho do servidor Percona vêm de seu mecanismo de armazenamento XtraDB. Percona identificada uma situação em MySQL InnoDB e onde rendimento aumentariam constantemente e depois despencar, parando brevemente, antes de construir para cima, continuamente repetindo este ciclo de acumulação e parar. XtraDB fez grandes avanços na resolução deste problema e agora vai sustentar a alta taxa de transferência, muitas vezes com desempenho superior de pico, sem sofrer a mesma parada. Se o seu trabalho exige uma alta taxa de transferência sustentada, Percona Server é provável que seja uma boa escolha. Se a sua atividade de banco de dados é rajadas de transações, você é menos provável que assistamos a uma melhoria tão pronunciada.
Outra melhoria importante é a sua capacidade de escalar verticalmente (mais CPUs e memória dentro de um servidor). Servidor Percona será ampliado consistentemente a 48 núcleos permitindo que todos, mas as maiores aplicações para evitar completamente a necessidade de escalar horizontalmente (mais servidores usando replicação e / ou sharding), reduzindo a complexidade de aplicação e administração.
MariaDB
Enquanto MariaDB tem portado alguns MySQL 6.0 recursos e melhorias, a versão atual é baseada em MySQL 5.1, de forma que há alguns avanços que o MySQL e Percona servidor têm que ainda não estão integrados em MariaDB. No momento da escrita existe uma versão alfa de 5,5 MariaDB disponível, que é baseado em MySQL 5,5 que irá resolver esta questão. Há críticas sobre o tempo que leva para a MariaDB rebase em uma nova versão do MySQL, embora eu me pergunto se o projeto seria fazer suas próprias melhorias, como rapidamente se mais tempo foi gasto em fusão nas mudanças.
MariaDB não foi em marcha lenta no departamento de desempenho no entanto, as maiores melhorias são o otimizador de consulta . O papel do otimizador de consultas é tentar executar a consulta da maneira mais eficiente através do cálculo da mais eficiente junta e fazer o melhor uso de índices para reduzir a quantidade de leituras e cálculos necessários para retornar o resultado. Alguma vez você já teve que reescrever uma subconsulta em uma menos legível, mais complexo se juntar, para torná-lo um melhor desempenho? Otimizador de consultas MariaDB vai fazer um bom trabalho sob o capô. Isto ajuda em alguns casos com a escrita de SQL mais legíveis e também protege a sua aplicação a partir de uma certa classe de desempenho matar-consultas que poderia esgueirar-se de um desenvolvedor de incautos. Bem como a otimização subconsulta, junte-se a otimização também foi melhorado. Somados, um aplicativo que usa lotes de consultas complexas deve ver boas melhorias a partir deste. Se, no entanto, sua aplicação está executando muitas consultas simples, é improvável que você vai ver o benefício da melhor otimizador.
Em vez de usar InnoDB, MariaDB faz uso do motor Percona de armazenamento XtraDB, por isso recebe benefícios de desempenho similares aos Percona Servidor nesta área.
Garoa
Regue tem uma abordagem diferente para o desempenho. Ao invés de concentrar em performance bruta, por exemplo, como Regue rápido pode processar uma transação ou número de transações, eles estão focados em escala. Regue tem como alvo as cargas de trabalho onde os aplicativos precisam ser capazes de executar 1024 conexões simultâneas. Sweet spot MySQL era tradicionalmente cerca de 16 tópicos, embora as versões recentes parecem lidar melhor com maior concorrência e, como de costume, tudo isso depende da carga de trabalho. De uma perspectiva de arquitetura, isso significa sistematicamente removendo pontos de contenção dentro Drizzle que historicamente impediram o MySQL a partir de escala. Este suporte para cargas de trabalho de alta concorrência, por vezes, resultou em decisões de design que causaram o pior desempenho com menor concorrência por isso, se seu aplicativo não exige altos níveis de concorrência você pode não ver qualquer melhoria de desempenho em relação ao MySQL e, em alguns casos, pode realmente ter um desempenho pior . Se você precisa de alta concorrência, no entanto, a garoa é uma excelente escolha para você.
Fonte: TechPortal
Nenhum comentário :
Postar um comentário