Não muito tempo atrás, a indústria de banco de dados consistia em um punhado de fornecedores. Os bancos de dados eram principalmente relacionais e executados em máquinas únicas. A alta disponibilidade foi implementada por meio de 'clusters' de espera ativa. Com um modelo vertical 'scale-up', tratava-se principalmente de armazenamento compartilhado (SAN ou DRBD) ou replicação assíncrona de logs para sincronizar o estado com um nó em espera. Em 2001, quando comecei a trabalhar com o NDB Cluster (que mais tarde se tornaria o MySQL Cluster), o conceito de manter um banco de dados inteiro na memória principal era estranho - 'e se você desligar o servidor?'. Distribuir um banco de dados em vários servidores era preocupante - 'você tem dados aqui e ali'. E toda a ideia de um banco de dados de código aberto para cargas de trabalho de missão crítica era risível.
Avanço rápido de 15 anos e agora temos dezenas de fornecedores de banco de dados no mercado - principalmente de código aberto, modelos diferentes (valor-chave, documento, gráfico, …) e distribuídos por padrão. Os dados residentes na memória são praticamente a norma para obter alto desempenho e baixa latência. Três dos 5 principais bancos de dados mais populares (de acordo com o ranking db-engines) são de código aberto (MySQL, PostgreSQL e MongoDB). Atualmente, é mais provável que você gerencie uma frota de servidores de banco de dados distribuídos em diferentes datacenters. Você pode até ter alguns de seus bancos de dados gerenciados por um fornecedor de nuvem de terceiros.
Então, como é gerenciar bancos de dados em 2018?
AUTOMAÇÃO
Com tantas tarefas para gerenciar e apenas tantas horas em um dia, seria louco fazer as coisas manualmente.
A automação é uma ótima maneira de fazer as coisas. Quando tínhamos poucos bancos de dados para gerenciar, operar o banco de dados seria muito prático, com algumas tarefas escritas em algo como bash ou perl - por exemplo, um script para fazer backup do banco de dados, outro para mover arquivos de backup para algum local. Failover seria manual, e estaríamos até debatendo se deveria ser automatizado ou não.
Hoje em dia, a automação é um acéfalo. Há vários sistemas de automação de TI ou gerenciamento de configuração que podem ser aproveitados - Puppet, Chef, Ansible e Salt oferecem estruturas de uso geral que podem ser usadas para criar automação para diferentes topologias de banco de dados. O software de gerenciamento de cluster escrito especificamente para gerenciar configurações de banco de dados inclui MongoDB Ops Manager e ClusterControl. Eles permitem que as equipes de operações gerenciem seus clusters com algo que está prontamente disponível no mercado. Construir um sistema de gerenciamento de cluster do zero usando um sistema de gerenciamento de configuração não é tarefa fácil. Requer experiência significativa na ferramenta de automação, bem como compreensão das operações de gerenciamento, como agendamento e verificação de backup, failover automático com reconfiguração subsequente de sistemas, implementação de alterações de configuração, aplicação de patches, upgrade ou downgrade de versão, etc.
E, claro, há o surgimento de plataformas de serviços DBaaS, onde implantação, integridade, failover, backups, etc., são todos controlados por software. Os provedores de nuvem são realmente muito bons em automação. O Amazon RDS é um ótimo exemplo de automação de banco de dados em escala - ele automatiza a implantação, atualizações de patches, backups, restauração pontual, dimensionamento de réplicas e alta disponibilidade/failover.
ANIMAL DE ESTIMAÇÃO vs GADO
Nos anos 90 e até o boom e o fracasso das pontocom, a Sun Microsystems e a Oracle fizeram uma fortuna vendendo bancos de dados escaláveis em grandes hardwares SMTP. Adicione um pouco de armazenamento SAN e software de failover da Veritas e você terá um cluster de failover de espera ativa de última geração para alta disponibilidade. Os servidores de banco de dados eram relativamente poucos em número, mas poderosos, pois cresceriam verticalmente. Eles receberam nomes (assim como você nomeia seus animais de estimação!), e foram cuidados por DBAs.
Hoje em dia, os bancos de dados são baratos e funcionam bem em hardware comum. Há muitos deles, e nós lhes damos números - assim como o gado. Se um quebrar, podemos obter um novo.
É também uma nova raça de gado - gado de código aberto! Três dos cinco principais bancos de dados, de acordo com db-engines, são todos de código aberto - eles estão lenta mas seguramente corroendo a participação de mercado dos dois fornecedores proprietários. O código aberto é o novo padrão de datacenter, não apenas para sistema operacional, mas também para bancos de dados.
https://db-engines.com/en/ranking Então, o que isso significa para você? Bem, no futuro, é mais provável que você gerencie um banco de dados de código aberto - ou mesmo vários para aplicativos usando coletas de dados heterogêneas. Em um mundo de persistência poliglota e microsserviços, o armazenamento de dados subjacente agora é determinado pela natureza dos dados. Do ponto de vista da arquitetura, os bancos de dados de instância única com HA baseada em disco estão dando lugar a clusters que são potencialmente distribuídos em vários datacenters.
Precisamos de um DBA?
O papel do DBA é especializado - são necessários anos de experiência para se tornar um. No passado, quando havia apenas alguns fornecedores de banco de dados proprietários para escolher, você teria DBAs especializados com um conjunto específico de habilidades e experiência. Também era necessário - bancos de dados como Oracle ou SQL Server possuem enormes conjuntos de recursos, construídos ao longo de décadas. Eles não são fáceis de gerenciar. Normalmente, eles eram implantados como o único banco de dados de um aplicativo e precisavam ser monitorados, fazer backup dos dados e quaisquer problemas que se apresentassem precisavam ser tratados. Essas tarefas eram exatamente o que os DBAs estavam aqui para focar.
Na última década, porém, surgiu toda uma nova indústria de banco de dados - com dezenas e dezenas de bancos de dados de código aberto, bem como serviços de banco de dados em nuvem. Como vimos anteriormente, não é incomum que um aplicativo use dois datastores diferentes. Mas as empresas raramente têm um DBA para esses armazenamentos de dados que usam. Onde você encontra um MongoDB ou Cassandra ou
Gerenciá-los seria apenas mais uma tarefa adicionada à lista de tarefas da equipe SysAdmin ou DevOps ou Site Reliability Engineering (SRE). E vemos hoje que muitas empresas não possuem DBAs em tempo integral. A responsabilidade é distribuída entre as equipes, com ferramentas de automação sendo cada vez mais usadas para cuidar das tarefas rotineiras do dia-a-dia. Para bancos de dados que foram movidos para a nuvem, os aspectos operacionais de como os dados estão sendo armazenados são totalmente terceirizados para o provedor de nuvem. Então, em vez de trabalhar em como armazenar dados, a equipe de operações agora pode se concentrar no uso dos dados.
Ciclo de vida do banco de dados
O ciclo de vida médio de um banco de dados costumava ser muito mais longo do que é hoje. Uma vez que você escolheu uma plataforma de banco de dados, foi isso. A decisão seria tomada entre dois ou três bancos de dados relacionais, geralmente pelo DBA ou por alguém superior na organização. A empresa encontraria o dinheiro para comprar licenças perpétuas. Uma vez que a decisão foi tomada, você agora tinha que viver com ela pelos próximos 10 anos. Os bancos de dados eram monolíticos e os aplicativos normalmente usavam um único banco de dados compartilhado.
Hoje, em um mundo de contêineres, nuvem, microsserviços e pipelines de CI/CD, não é incomum que os desenvolvedores façam escolhas de tecnologia - especialmente se for um banco de dados de código aberto que pode ser facilmente baixado ou oferecido como um serviço, sem ter que falar com um representante de vendas, ou ter que buscar o orçamento da gerência. As organizações estão sendo desafiadas a criar valor mais rapidamente, de modo que a taxa de mudança na infraestrutura/aplicativos aumentou drasticamente. Bancos de dados monolíticos agora são divididos em vários bancos de dados pequenos, com cada banco de dados gerenciando dados de domínio para um microsserviço individual. Com a variedade de produtos de banco de dados disponíveis hoje no ecossistema de código aberto, as equipes têm a opção e a liberdade de migrar para um armazenamento de dados melhor. À medida que os serviços são comissionados e desativados, os bancos de dados também seguem - embora os próprios dados possam ser arquivados ou movidos para um data lake. Em um cenário de infraestrutura que é muito mais dinâmico hoje, descobrimos que nossos bancos de dados estão vivendo vidas mais curtas.
PAPEL DE DBA
O DBA, tradicionalmente guardião e guardião do banco de dados, atenderia às necessidades de banco de dados de diferentes equipes de aplicativos/infraestrutura na organização. Quaisquer alterações que exigissem acesso ou alterações no banco de dados exigiriam os serviços do DBA. No entanto, prioridades conflitantes e falta de disponibilidade do DBA podem significar que o projeto seria bloqueado/atrasado e o inevitável atrito se seguiria.
Alto custo de colaboração e inovação rápida/curto tempo de lançamento no mercado não combinam bem. Como vimos anteriormente, os microsserviços são um exemplo de como os serviços de infraestrutura e aplicativos agora são arquitetados para desacoplar o máximo possível. Os bancos de dados estão sendo cada vez mais automatizados e o controle do banco de dados está mudando para desenvolvedores ou equipes de projeto. Mesmo coisas como mudanças de esquema não são tão pesadas quanto costumavam ser. Eles eram muito mais difíceis no contexto de um banco de dados central para um aplicativo monolítico. Com os dados sendo compartilhados entre diferentes componentes, as alterações de esquema precisariam ser coordenadas e planejadas com cuidado - geralmente com meses de antecedência. Os DBAs tiveram um papel fundamental na compreensão e execução de mudanças. A dinâmica é diferente hoje, onde a taxa de mudança é muito mais rápida. Não é incomum que as equipes de desenvolvimento enviem alterações de código na produção semanalmente ou diariamente - ou várias vezes ao dia! Os bancos de dados precisam de atualizações constantes para acompanhar as mudanças nas aplicações, e estas são realizadas pelos desenvolvedores. Alguns dos bancos de dados mais recentes, como o MongoDB, tornam isso muito simples por ter um modelo sem esquema. O que isso significa efetivamente é que o esquema do banco de dados está se movendo para o código do aplicativo.
Portanto, se todas as tarefas principais comuns estiverem sendo automatizadas, o que acontecerá com a função de DBA no futuro? Em vez de se concentrar em tarefas administrativas, o DBA funcionará mais como um mentor para outras equipes da organização. As organizações precisam entender quais dados possuem e como esses dados podem ser usados. Afinal, os dados são mais valiosos quando compartilhados e combinados com outros recursos, não apenas armazenados. Schemaless parece ótimo, mas ainda precisamos acompanhar nossos dados - no banco de dados ou no código. A segurança é um desafio, e as violações de dados continuam piorando. Portanto, se quisermos tornar os dados ótimos novamente, o DBA precisa mudar para uma função de consultor/ativador horizontal que abrange todas as equipes. Do ponto de vista da competência, o DBA moderno precisa entender como projetar sistemas distribuídos de alta disponibilidade e implementar sistemas de automação eficientes para cuidar das tarefas mundanas. À medida que as empresas implantam infraestrutura em ambientes de nuvem ou até mesmo de contêiner, entender como construir bancos de dados altamente disponíveis e escaláveis nessas plataformas garantirá a sobrevivência do DBA.
Resumo
Estamos sentados em uma junção fascinante na história da indústria de banco de dados, que passou por uma grande transformação nas últimas duas décadas. A tabela abaixo tenta resumir.
| Modo antigo | Novo caminho | |
|---|---|---|
| Como? | Manual com ajuda de scripts e ferramentas/utilitários | Automação via software (puppet, chef, ClusterControl) ou plataformas DBaaS. |
| O quê? | Poucas instâncias de banco de dados importantes, animais de estimação em vez de gado | Frota de instâncias virtualizadas, ambiente de persistência poliglota |
| Quem | DBAs especializados | "Todos" - DBAs, SysAdmins, DevOps, Dev. |
| Função de DBA | Função vertical - DBA como guardião/guardião, concentre-se em tarefas administrativas tradicionais relacionadas à logística de dados. | Função horizontal - DBA como mentor com foco em dados. Mude para tarefas não operacionais, como arquitetura, segurança e estratégia de análise/consumo/ajuste de dados. |
| Ciclo de vida | Vida útil de longo prazo, com mudanças planejadas com antecedência | Vida útil de curto a médio prazo, com taxa de mudança muito mais rápida |
| Competência | DB, SO, armazenamento | DB, SO, armazenamento, sistemas distribuídos, rede e segurança, scripts de automação |
Eu estaria interessado em ouvir seus pensamentos sobre o gerenciamento de banco de dados de código aberto e se você viu as mesmas tendências? Como foram suas lutas ou sucessos com OSDBs nos últimos anos? E o que você prevê que aconteça no próximo ano?
Nós, da Multiplenines, continuaremos a lutar para ajudar a facilitar o gerenciamento e a automação de seus bancos de dados de código aberto no próximo ano e além. Portanto, fique atento às atualizações sobre isso a partir de janeiro próximo.
Mas enquanto isso, deixe-me saber seus pensamentos e nos vemos em 2019!
Fotos de SoRad (Shutterstock) e Os Simpsons; outras fotos são de seus respectivos donos.
