SQL Distribuído: Uma Alternativa ao Sharding de Banco de Dados

O sharding de banco de dados é o processo de divisão de dados em pequenas partes chamadas de “fragmentos”. Sharding geralmente é introduzido quando há necessidade de escalar as operações de escrita. Ao longo do ciclo de vida de um aplicativo bem-sucedido, o servidor do banco de dados atingirá o número máximo de gravações que pode realizar, seja em nível de processamento ou de capacidade. Dividir os dados em vários fragmentos—cada um em seu próprio servidor de banco de dados—reduz a pressão em cada nó individual, efetivamente aumentando a capacidade de gravação do banco de dados como um todo. Isso é o que o sharding de banco de dados representa.

SQL distribuído é a nova maneira de escalar bancos de dados relacionais com uma estratégia semelhante ao sharding, que é totalmente automatizada e transparente para os aplicativos. Bancos de dados SQL distribuídos são projetados desde o início para escalar quase linearmente. Neste artigo, você aprenderá os fundamentos do SQL distribuído e como começar.

Desvantagens do Sharding de Banco de Dados

O sharding traz uma série de desafios:

• Particionamento de dados: Decidir como particionar os dados em vários fragmentos pode ser um desafio, pois requer encontrar um equilíbrio entre a proximidade dos dados e uma distribuição uniforme dos dados para evitar pontos quentes.
• Gerenciamento de falhas: Se um nó chave falhar e não houver fragmentos suficientes para suportar a carga, como você transfere os dados para um novo nó sem tempo de inatividade?
• Complexidade das consultas: O código de aplicação está acoplado à lógica de particionamento de dados e consultas que exigem dados de vários nós precisam ser reagrupadas.
• Consistência de dados: Garantir a consistência de dados em várias partições pode ser um desafio, pois requer coordenação de atualizações em dados em várias partições. Isso pode ser particularmente difícil quando atualizações são feitas de forma concorrente, pois pode ser necessário resolver conflitos entre diferentes escritas.
• Escalabilidade elástica: À medida que o volume de dados ou o número de consultas aumenta, pode ser necessário adicionar novas partições ao banco de dados. Esse processo pode ser complexo, com tempo de inatividade inevitável, exigindo processos manuais para realocar dados uniformemente em todas as partições.

Alguns desses inconvenientes podem ser aliviados adotando persistência poliglota (usando bancos de dados diferentes para diferentes cargas de trabalho), motores de armazenamento de banco de dados com capacidades nativas de particionamento, ou proxies de banco de dados. No entanto, enquanto ajudam com alguns dos desafios no particionamento de banco de dados, essas ferramentas têm limitações e introduzem complexidade que requer gerenciamento constante.

O que é SQL Distribuído?

Banco de Dados SQL Distribuído refere-se a uma nova geração de bancos de dados relacionais. Em termos simples, um banco de dados SQL distribuído é um banco de dados relacional com fragmentação transparente que se apresenta como um único banco de dados lógico para as aplicações. Os bancos de dados SQL distribuídos são implementados como uma arquitetura compartilhada-nada e um mecanismo de armazenamento que amplia tanto leituras quanto escritas, mantendo a conformidade verdadeira com os princípios ACID e alta disponibilidade. Os bancos de dados SQL distribuídos possuem os recursos de escalabilidade dos bancos de dados NoSQL—que ganharam popularidade na década de 2000—mas não sacrificam a consistência. Eles mantêm as vantagens dos bancos de dados relacionais e adicionam compatibilidade com a nuvem, com resiliência em várias regiões.

A different but related term is NewSQL (coined by Matthew Aslett in 2011). This term also describes scalable and performant relational databases. However, NewSQL databases don’t necessarily include horizontal scalability.

Como Funciona o SQL Distribuído?

Para entender como o SQL distribuído funciona, vamos considerar o caso do MariaDB Xpand—um banco de dados SQL distribuído compatível com o banco de dados de código aberto MariaDB. O Xpand funciona dividindo os dados e índices entre os nós e executando automaticamente tarefas como rebalanceamento de dados e execução de consultas distribuídas. As consultas são executadas em paralelo para minimizar o atraso. Os dados são replicados automaticamente para garantir que não haja um único ponto de falha. Quando um nó falha, o Xpand rebalanceia os dados entre os nós sobreviventes. O mesmo acontece quando um novo nó é adicionado. Um componente chamado rebalancer garante que não haja pontos quentes—um desafio com particionamento manual de banco de dados—que ocorre quando um nó tem que lidar de forma desproporcional com muitas transações em comparação com outros nós que podem ficar ociosos às vezes.

Vamos estudar um exemplo. Suponha que temos uma instância de banco de dados com some_table e um número de linhas:

Podemos dividir os dados em três pedaços (fragmentos):

E então mover cada pedaço de dados para uma instância de banco de dados separada:

Isso é o que parece o compartilhamento manual de banco de dados. O SQL distribuído faz isso automaticamente para você. No caso do Xpand, cada fragmento é chamado de fatia. As linhas são fatiadas usando um hash de um subconjunto das colunas da tabela. Não apenas os dados são fatiados, mas também os índices são fatiados e distribuídos entre os nós (instâncias de banco de dados). Além disso, para manter alta disponibilidade, as fatias são replicadas em outros nós (o número de réplicas por nó é configurável). Isso também acontece automaticamente:

Quando um novo nó é adicionado ao cluster ou quando um nó falha, o Xpand reequilibra automaticamente os dados sem a necessidade de intervenção manual. Veja o que acontece quando um nó é adicionado ao cluster anterior:

Algumas linhas são movidas para o novo nó para aumentar a capacidade geral do sistema. Tenha em mente que, embora não seja mostrado no diagrama, os índices e as réplicas também são realocados e atualizados conforme necessário. Uma visão um pouco mais completa (com uma realocação um pouco diferente de dados) do cluster anterior é mostrada neste diagrama:

Essa arquitetura permite escalabilidade quase linear. Não é necessária intervenção manual no nível do aplicativo. Para o aplicativo, o cluster parece um único banco de dados lógico. O aplicativo simplesmente se conecta ao banco de dados por meio de um balanceador de carga (MariaDB MaxScale):

Quando o aplicativo envia uma operação de escrita (por exemplo, INSERT ou UPDATE), o hash é calculado e enviado para a fatia correta. Múltiplas operações de escrita são enviadas em paralelo a múltiplos nós.

Quando Não Usar SQL Distribuído

Dividir um banco de dados melhora o desempenho, mas também introduz sobrecarga adicional no nível de comunicação entre os nós. Isso pode levar a um desempenho mais lento se o banco de dados não estiver configurado corretamente ou se o roteador de consultas não for otimizado. O SQL distribuído pode não ser a melhor alternativa em aplicativos com menos de 10K consultas por segundo ou 5K transações por segundo. Além disso, se seu banco de dados consiste principalmente em muitas pequenas tabelas, um banco de dados monolítico pode ter um melhor desempenho.

Começando com SQL Distribuído

Como um banco de dados SQL distribuído se apresenta a um aplicativo como se fosse um único banco de dados lógico, começar é direto. Tudo o que você precisa é o seguinte:

• Um cliente SQL como DBeaver, DbGate, DataGrip, ou qualquer extensão de cliente SQL para seu IDE
• A distributed SQL database

Docker facilita a segunda parte. Por exemplo, o MariaDB publica a imagem Docker mariadb/xpand-single que permite criar um banco de dados Xpand de nó único para avaliação, teste e desenvolvimento.

Para iniciar um contêiner Xpand, execute o seguinte comando:

docker run --name xpand \
	-d \
	-p 3306:3306 \
	--ulimit memlock=-1 \
	mariadb/xpand-single \
	--user "user" \
	--passwd "password"

Consulte a documentação da imagem Docker para obter detalhes.

Nota: No momento de escrever este artigo, a imagem Docker mariadb/xpand-single não está disponível nas arquiteturas ARM. Nesses arquiteturas (por exemplo, máquinas Apple com processadores M1), use UTM para criar uma máquina virtual (VM) e instalar, por exemplo, Debian. Atribua um nome de host e use SSH para conectar-se à VM para instalar o Docker e criar o contêiner MariaDB Xpand.

Conectando ao Banco de Dados

Conectar-se a um banco de dados Xpand é o mesmo que conectar-se a um servidor MariaDB Comunidade ou Empresa. Se você tiver a ferramenta CLI mariadb instalada, simplesmente execute o seguinte:

mariadb -h 127.0.0.1 -u user -p

Você pode se conectar ao banco de dados usando uma GUI para bancos de dados SQL como DBeaver, DataGrip, ou uma extensão SQL para seu IDE (como esta aqui para o VS Code). Vamos utilizar um cliente SQL gratuito e de código aberto chamado DbGate. Você pode baixar o DbGate e executá-lo como uma aplicação desktop ou, já que está usando Docker, pode implantá-lo como uma aplicação web que você pode acessar de qualquer lugar através de um navegador (semelhante ao popular phpMyAdmin). Basta executar o seguinte comando:

docker run -d --name dbgate -p 3000:3000 dbgate/dbgate

Uma vez que o container inicia, aponte seu navegador para http://localhost:3000/. Preencha os detalhes de conexão:

Clique em Testar e confirme que a conexão foi bem-sucedida:

Clique em Salvar e crie um novo banco de dados clicando com o botão direito na conexão no painel esquerdo e selecionando Criar banco de dados. Tente criar tabelas ou importar um script SQL. Se você quer apenas experimentar algo, o Pais ou Sakila são bons bancos de dados de exemplo.

Conectando a partir de Java, JavaScript, Python e C++

Para se conectar ao Xpand a partir de aplicativos, você pode usar os Conectores MariaDB. Existem muitas combinações possíveis de linguagens de programação e frameworks de persistência. Abranger isso está fora do escopo deste artigo, mas se você apenas quer começar e ver algo em ação, dê uma olhada nesta página de início rápido com exemplos de código para Java, JavaScript, Python e C++.

O Verdadeiro Poder do SQL Distribuído

Neste artigo, aprendemos como iniciar um único nó Xpand para fins de desenvolvimento e teste, em oposição a cargas de trabalho de produção. No entanto, o verdadeiro poder de um banco de dados SQL distribuído está em sua capacidade de escalar não apenas leituras (como na fragmentação de banco de dados clássica) mas também gravações, simplesmente adicionando mais nós e deixando o balanceador de carga reconfigurar otimamente os dados. Embora seja possível implantar o Xpand em uma topologia de vários nós, a maneira mais fácil de usá-lo na produção é através do SkySQL.

Se você deseja saber mais sobre o SQL distribuído e o MariaDB Xpand, aqui está uma lista de recursos úteis:

• MariaDB Xpand para SQL distribuído (animação em vídeo)
• Documentação do MariaDB Xpand
• Levando o SQL Distribuído ao Nível Superior com Indexação Colunar (palestra)
• Começando com SQL Distribuído (refcard)