Servidores de banco de dados e bancos de dados incorporados
Servidor de Banco de Dados
Um servidor de banco de dados refere-se a um banco de dados que é executado como um processo de servidor independente e processa as solicitações de um aplicativo por meio de uma rede. A maioria dos RDBMSs com os quais estamos familiarizados, como MySQL, PostgreSQL e Oracle DB, se enquadra neste modelo. Um servidor de banco de dados possui as seguintes vantagens:
- Gerenciamento Centralizado: Os dados são gerenciados de forma integrada em um único local, facilitando a consistência, segurança, backup e recuperação.
- Independência de Recursos: Recebe CPU, memória e armazenamento próprios, garantindo desempenho estável independentemente do estado do aplicativo.
- Alta Concorrência e Escalabilidade: Otimizado para acesso simultâneo de muitos usuários, e a escalabilidade horizontal através de clustering ou replicação é relativamente fácil.
Devido a essas características, o servidor de banco de dados se estabeleceu como o padrão na infraestrutura de software nas últimas décadas. No entanto, com o avanço da tecnologia e as mudanças ambientais, as desvantagens dos servidores de banco de dados começaram a surgir em alguns ambientes, e os bancos de dados embarcados estão recebendo atenção novamente como uma alternativa.
Nova Tendência: Banco de Dados Embarcado
Um banco de dados embarcado é um mecanismo de banco de dados que é incluído como uma biblioteca em um aplicativo e executado dentro do mesmo processo, sem a necessidade de um processo de servidor separado. SQLite, LevelDB e RocksDB são exemplos representativos de bancos de dados embarcados. O contexto em que esses bancos de dados embarcados surgiram como uma alternativa poderosa no ambiente tecnológico mais recente é o seguinte:
Surgimento do SSD
No ambiente de sistema anterior, centrado em HDDs, o desempenho de acesso aleatório era significativamente inferior ao desempenho de leitura/escrita sequencial de dados. Portanto, a otimização do desempenho consistia em minimizar as operações de I/O de disco e maximizar o cache de memória. Os servidores de banco de dados superaram as limitações físicas dos HDDs operando caches em larga escala e processando operações de escrita em lotes.
No entanto, o surgimento dos SSDs mudou completamente essa premissa. Os SSDs são milhares de vezes mais rápidos em I/O aleatório do que os HDDs, e sua latência é drasticamente menor. Como resultado, a percepção anterior de que "o I/O de disco é o maior gargalo" desapareceu, e o atraso causado pelo acesso remoto ao servidor de banco de dados através da rede começou a se destacar como um novo gargalo.
MSA e Independência de Dados
No passado, a estrutura comum era um único aplicativo monolítico gigante que dependia de um único banco de dados centralizado. Embora essa abordagem fosse simples, à medida que a escala do serviço aumentava, tornava-se difícil alterar o esquema de dados, e todos os serviços compartilhavam o mesmo banco de dados, resultando em um acoplamento excessivamente forte.
Na arquitetura de microsserviços moderna, o princípio "Database per Service" é enfatizado para resolver esses problemas. Ao possuir e encapsular seu próprio armazenamento de dados dedicado, cada serviço garante a independência entre os serviços, e o isolamento de falhas e a escalabilidade tornam-se mais fáceis. Nesse processo, os bancos de dados embarcados tornam-se uma escolha ideal para o armazenamento de dados em nível de serviço. Eles são leves, rápidos e podem ser implantados com o código do serviço, o que os torna muito adequados para ambientes MSA.
Por exemplo, em ambientes Kubernetes, o padrão sidecar é amplamente utilizado para otimizar o processamento de dados local, colocando um banco de dados embarcado ao lado do contêiner do aplicativo. Isso reduz os gargalos de rede e minimiza a latência de acesso aos dados.
Simplificação do Ambiente Operacional
Os servidores de banco de dados exigem procedimentos operacionais complexos, como instalação, patch, backup, recuperação de desastres, replicação e monitoramento de desempenho, o que requer DBAs dedicados e pessoal de operações especializado. Especialmente em ambientes de grande escala, essa carga de gerenciamento é muito alta.
Os bancos de dados embarcados mitigam significativamente esses problemas. Quando o banco de dados é integrado ao aplicativo, o teste de unidade, a construção, o controle de versão e a implantação são realizados em conjunto, eliminando a necessidade de operação de servidor separada. Além disso, quando o aplicativo é dimensionado horizontalmente (Scale-out), o banco de dados embarcado também se expande, e o gerenciamento automatizado é possível por meio da cultura DevOps e do pipeline CI/CD. Especialmente em startups, serviços de pequena escala e ambientes de desenvolvimento de protótipos, os bancos de dados embarcados reduzem drasticamente a complexidade operacional e aceleram significativamente o desenvolvimento e a implantação.
Desenvolvimento de Linguagens de Sistema de Alto Desempenho e Ecossistemas
No passado, era comum que bancos de dados e aplicativos fossem escritos em linguagens diferentes. Por exemplo, mecanismos de banco de dados que exigiam alto desempenho eram principalmente escritos em C, C++, e os aplicativos eram desenvolvidos em linguagens como Java, Python, PHP. Embora essa abordagem fosse eficaz para a otimização do desempenho, ela tinha limitações como problemas de estabilidade de memória, processamento de concorrência complexo, latência e dificuldades de integração e implantação de bibliotecas.
No entanto, com o surgimento de linguagens de programação de sistemas modernas como Go e Rust, essas limitações foram significativamente mitigadas. Particularmente, Go é adequado para aplicativos de alto desempenho, bem como para a escrita de programas de baixo nível, como mecanismos de banco de dados, o que permitiu que bancos de dados e aplicativos fossem tratados juntos em um único ecossistema de linguagem.
Na verdade, no Golang, bancos de dados embarcados de alto desempenho como BadgerDB e PebbleDB são amplamente utilizados. Isso significa que os bancos de dados embarcados não são apenas uma alternativa leve aos servidores de banco de dados, mas se estabeleceram como uma opção importante com sua própria competitividade.
Conclusão
Para gerenciamento centralizado de grandes volumes de dados, transações complexas e alta concorrência, o servidor de banco de dados ainda é a solução mais robusta. No entanto, para serviços individuais em ambientes MSA, dispositivos de borda IoT, prototipagem rápida e projetos onde a eficiência operacional é crucial, um banco de dados embarcado pode ser uma escolha mais eficiente e razoável. No final, o importante é escolher a ferramenta ideal que melhor se adapte à situação e aos requisitos dados, e o avanço dos bancos de dados embarcados nos oferece uma gama mais ampla e diversificada de opções.