Todos os produtos
Search
Central de documentação

PolarDB:Transparent distribution

Última atualização: Aug 13, 2026

Este tópico descreve o conceito de distribuição transparente no PolarDB-X e explica seu funcionamento.

Informações básicas

Quando uma aplicação baseada em um banco de dados MySQL tradicional standalone atinge um gargalo de recursos ou desempenho, a migração para um banco de dados distribuído é uma solução comprovada para atender aos requisitos de negócio.

No entanto, após essa migração, os usuários frequentemente enfrentam os seguintes desafios ao utilizar o banco de dados distribuído:

  • Como os dados são distribuídos pelo banco de dados?

  • Quais tabelas precisam de particionamento horizontal? Como definir o particionamento e quais chaves utilizar? Qual é o número ideal de partições para uma tabela?

  • Em quais nós de dados minhas informações estão armazenadas? Como corrigir desequilíbrios de recursos?

Para resolver essas questões, é necessário compreender o funcionamento dos bancos de dados distribuídos e seus cenários de aplicação adequados. Utilizar corretamente essa tecnologia não é uma tarefa simples.

Para facilitar o uso e a transição de bancos de dados standalone para distribuídos, a Alibaba Cloud oferece o recurso de distribuição transparente no kernel do PolarDB-X 2.0.

Nota

Esse recurso suporta apenas bancos de dados no modo AUTO.

O que é distribuição transparente?

O recurso de distribuição transparente do PolarDB-X 2.0 fornece políticas padrão de particionamento e distribuição de dados. Isso permite conectar aplicações a bancos de dados distribuídos para obter ganhos de desempenho sem modificar o código da aplicação.

A capacidade central dessa funcionalidade consiste em auxiliar na definição do esquema de particionamento das tabelas e na distribuição dos dados entre os nós de dados (DNs) do PolarDB-X.

Para usuários que migram de um banco de dados MySQL tradicional standalone para um banco de dados distribuído PolarDB-X, as instruções SQL para criar tabelas de negócio dividem-se em duas categorias:

  • Categoria 1: As instruções SQL não utilizam explicitamente a sintaxe de particionamento do MySQL. As tabelas criadas com essas instruções podem ser chamadas de tabelas MySQL não particionadas.

  • Categoria 2: As instruções SQL utilizam explicitamente a sintaxe de particionamento do MySQL, por exemplo, instruções que contêm Partition By Hash(id). As tabelas criadas com essas instruções podem ser chamadas de tabelas MySQL particionadas.

Se você criar tabelas usando uma instrução da Categoria 2, considera-se que escolheu um esquema de particionamento para seu negócio, pois a instrução utiliza explicitamente a sintaxe de particionamento do MySQL. O PolarDB-X também trata essas tabelas como particionadas manualmente. As partições nessas tabelas são distribuídas uniformemente entre os DNs para equilibrar a carga.

As tabelas criadas a partir de instruções da Categoria 1 existem em grande quantidade e são o foco da distribuição transparente do PolarDB-X, cujo objetivo é ajudar você a escolher um esquema de particionamento e de distribuição de dados.

O recurso de distribuição transparente do PolarDB-X oferece três esquemas de particionamento e distribuição de dados para tabelas criadas a partir de instruções da Categoria 1:

  • Tabela não particionada: Neste esquema, as tabelas MySQL permanecem não particionadas no PolarDB-X, que atribui DNs fixos a elas. Dessa forma, você utiliza as tabelas da mesma maneira que usaria tabelas MySQL tradicionais standalone.

  • Tabela com sharding: Neste esquema, as tabelas MySQL permanecem não particionadas no PolarDB-X. No entanto, o sistema aplica automaticamente o sharding e distribui as tabelas entre os DNs.

  • Tabela particionada: Neste esquema, o PolarDB-X particiona automaticamente as tabelas MySQL não particionadas.

    • As tabelas primárias recebem particionamento HASH horizontal com base nas chaves primárias.

    • Índices globais são usados por padrão, e o particionamento horizontal ocorre com base nas colunas de índice.

Portanto, o recurso de distribuição transparente opera em três modos, conforme o esquema de particionamento de tabela e distribuição de dados:

  • Sharding de tabela

  • Particionamento automático

  • Particionamento manual (padrão)

Modos de operação da distribuição transparente

Escolha um modo de operação adequado aos seus requisitos de negócio com base no esquema de particionamento ou distribuição de dados desejado ao conectar sua aplicação a um banco de dados distribuído, especialmente durante a primeira conexão.

A tabela a seguir descreve os modos de operação, bem como suas vantagens e desvantagens:

Modo de operação

Descrição

Vantagens e desvantagens

Table sharding

Para todas as tabelas em um banco de dados lógico:

  • Se uma tabela lógica não usar explicitamente a sintaxe de particionamento do MySQL, ela não será particionada e será distribuída aleatoriamente entre os DNs do PolarDB-X para balanceamento de carga.

  • Se uma tabela lógica usar explicitamente a sintaxe de particionamento do MySQL, ela será particionada e cada partição será distribuída uniformemente entre os DNs.

Vantagens:

  • Fácil de usar, sem necessidade de modificar a aplicação.

  • Melhor compatibilidade com SQL.

  • Desempenho de consulta SQL muito próximo ao do MySQL.

Desvantagens:

  • Carga desequilibrada entre os DNs devido à variação na frequência de acesso às tabelas e no número de linhas verificadas.

Automatic partitioning

Se as tabelas em um banco de dados lógico não usarem explicitamente a sintaxe de particionamento do MySQL:

  • O sistema particiona automaticamente as tabelas na horizontal com base em suas chaves primárias.

  • Índices globais são usados automaticamente, e o particionamento horizontal ocorre com base nas colunas de índice.

Vantagens:

  • Fácil de usar, quase sem necessidade de modificar a aplicação.

  • Escalabilidade horizontal.

Desvantagens:

  • Throughput de escrita reduzido devido à necessidade de manter múltiplos índices globais.

  • Carga desequilibrada entre os DNs e baixa escalabilidade devido à variação nos hot spots dos índices globais.

Manual partitioning (padrão)

Para todas as tabelas em um banco de dados lógico:

  • Se uma tabela lógica não usar explicitamente a sintaxe de particionamento do MySQL, ela será tratada como não particionada e atribuída ao mesmo DN.

  • Se uma tabela lógica usar explicitamente a sintaxe de particionamento do MySQL, ela será particionada e cada partição será distribuída uniformemente entre os DNs.

Vantagens:

  • Adaptabilidade a diferentes cenários de negócio.

  • Oferece desempenho ideal, balanceamento de carga e escalabilidade linear.

Desvantagens:

  • Mais difícil de entender e utilizar.

  • Requer modificação na aplicação.

Nota

É possível combinar os três modos de operação. Por exemplo, utilize o particionamento manual junto com sharding de tabela ou particionamento automático para atender a múltiplos requisitos.

Para mais informações sobre os cenários adequados para cada modo, consulte Best Practices.