Desde que o Linux se tornou um sistema operacional viável para servidores, as organizações vêm buscando todos os tipos de software de código aberto (OSS) para economizar em custos de licenças e manutenção e aproveitar as vantagens de uma plataforma aberta que convide à inovação.

Os exemplos são muitos: o Apache e o Nginx impulsionam a maioria dos servidores Web, o WordPress executa cerca de 25% dos 100.000 principais sites em todo o mundo, o OpenStack está se tornando uma plataforma de nuvem mais viável a cada versão, e as melhores ferramentas de DevOps têm código aberto.

Mas o mais interessante é o espaço dos bancos de dados de código aberto.

Uma breve retrospectiva

No passado, muitos softwares eram executados em bancos de dados tecnicamente considerados NoSQL – a maioria dos aplicativos de cliente-servidor era desenvolvida com bTrieve (posteriormente PervasiveSQL), dBase ou Clarion. Depois disso, contudo, o SQL foi amplamente adotado. Em seguida, o Oracle entrou em cena, o DB2 e outros ganharam terreno, a Microsoft comprou seu mecanismo SQL da Sybase, e assim por diante. No entanto, foram poucos os projetos construídos sobre bancos de dados OSS, já que eles não tinham recursos essenciais.

MySQL e código aberto hoje

Alguns anos depois, vemos o MySQL evoluir e se tornar um mecanismo de banco de dados sério, atuando em vários sites e aplicativos comerciais. Como resultado, a Oracle comprou a empresa por trás do MySQL. Nos anos seguintes, testemunhamos o crescimento de diversos produtos interessantes e úteis derivados do MySQL, além do PostgreSQL.

Assim, o MySQL tornou-se capaz de lidar com operações de grande escala – desde que devidamente arquitetado e gerenciado. Mas para muitos – e talvez você se inclua nessa categoria – fazer a transição para o MySQL ou outro sistema de gerenciamento de banco de dados (DBMS) OSS para cargas de trabalho críticas é algo que ainda está sendo avaliado.

Sete considerações sobre DBMS OSS

Se você estiver considerando o MySQL ou outro DBMS OSS como seu banco de dados principal ou talvez, por um motivo ou outro, para operar em conjunto com seus sistemas comerciais, como Oracle ou Microsoft SQL Server, apresentamos sete aspectos importantes:

1. Código aberto pode significar muitas coisas: acesso para visualizar o código-fonte, capacidade de modificar e agregar código e software gratuito. É importante compreender verdadeiramente quais desses atributos são úteis para você. Se estiver apenas interessado em algo gratuito, você poderá encontrar bancos de dados comerciais (não OSS) grátis, como SQL Server Express, que podem ser viáveis para algumas cargas de trabalho.

2. Não parta da premissa de que softwares de código aberto não têm custos. Algumas plataformas de código aberto não se desenvolveram porque sua configuração, personalização e manutenção são mais dispendiosas do que os custos equivalentes somados ao licenciamento de um produto comercial.

3. Não use software de código aberto por uma questão de preferência pessoal. Não se trata de uma religião, mas de uma decisão de negócios e carreira. Há bons motivos comerciais para usar um DBMS OSS. Seu desejo de apoiar o movimento dos softwares gratuitos nem sempre é um deles. Se você o fizer, use a ferramenta certa para o trabalho.

4. Ser SQL ou NoSQL? Alguns dos mecanismos de banco de dados mais interessantes disponíveis são NoSQL OSS, como Cassandra, MongoDB e Couch. Fique esperto para detectar quando transações e ACIDity são necessários e quando um mecanismo de banco de dados mais novo representa um risco aceitável. Pense que, em um futuro próximo, a maioria dos bancos de dados SQL também oferecerá acesso NoSQL aos dados.

5. Ao avaliar qualquer tecnologia, considere e avalie todo o seu ecossistema – quais ferramentas, serviços, suporte e talentos estão disponíveis? Quando se trata de bancos de dados OSS, fornecedores como Percona e EnterpriseDB fornecem suporte, serviços gerenciados e consultoria. Também não subestime a importância da disponibilidade de ferramentas de ajuste, otimização e solução de problemas em suporte a bancos de dados OSS, como o MySQL.

6. Entenda as diferenças dos perfis arquitetônicos e de desempenho entre esses bancos de dados e como eles se adequam aos requisitos de suas cargas de trabalho. Pode haver importantes decisões de design a serem tomadas, bem como escolhas e limitações a serem levadas em conta, dependendo do mecanismo que você opte por usar. Preste bastante atenção a questões arquitetônicas relacionadas a clustering, alta disponibilidade e escalonamento.

7. Por que mexer no time que está ganhando? Considere os gastos, o esforço e o custo da oportunidade de migrar aplicativos para um novo mecanismo de banco de dados. Crie um plano e uma estratégia de banco de dados de longo prazo que abranja toda a empresa, com um plano para cada carga de trabalho baseado nos requisitos dos aplicativos e na vantagem potencial.

Mecanismos de banco de dados OSS, como o MySQL, podem ser uma boa alternativa aos seus semelhantes comerciais, mas como acontece com todas as tecnologias, sua adoção precisa ser cuidadosamente avaliada e planejada. Refletir sobre as sete considerações apresentadas neste artigo pode ser um bom começo.