A distribuição transparente do PolarDB-X 2.0 oferece quatro modos de operação. Escolha o modo que melhor se adequa à escala do seu banco de dados, à complexidade das consultas SQL e aos requisitos de desempenho.
Identifique seu cenário
Negócio existente de grande porte
Seu sistema se enquadra nesta categoria se:
Você possui 10 ou mais bancos de dados, ou 100 ou mais tabelas, com operações JOIN complexas entre bancos de dados e tabelas.
As instruções SQL existentes são complexas e não podem ser modificadas.
Um banco de dados independente está atingindo limites de CPU ou I/O, causando aumento no tempo de resposta (RT) das consultas.
Exemplo típico: um hospital ou empresa da área médica executando um sistema de negócios há mais de dez anos.
Mix de negócios existentes e novos
Seu sistema se enquadra nesta categoria se:
Você possui 2 ou mais bancos de dados, ou 10 ou mais tabelas para cargas de trabalho existentes, com operações JOIN complexas entre bancos de dados e tabelas.
A maioria das instruções SQL existentes não pode ser modificada.
Novos recursos exigem tabelas grandes, e um banco de dados independente não consegue acompanhar o crescimento dos dados devido a limites de CPU, I/O ou disco.
Exemplo típico: um sistema de gerenciamento de pedidos expandindo para novos recursos após anos de operação.
Novo negócio baseado em MySQL independente
Seu sistema se enquadra nesta categoria se:
Você tem menos de 2 bancos de dados ou menos de 10 tabelas.
O negócio será lançado em breve e a velocidade de iteração é fundamental.
Você prevê um crescimento significativo de dados e precisa de escalabilidade desde o início.
Os bancos de dados e as instruções SQL do novo negócio podem ser modificados e otimizados.
Exemplo típico: uma empresa de fotografia lançando um novo sistema de negócios.
Negócio de alto desempenho e alto throughput
Seu sistema se enquadra nesta categoria se:
A quantidade de bancos de dados e tabelas é pequena, mas o volume de dados é grande e a concorrência é alta.
Seu negócio é sensível ao RT das consultas.
É necessária escalabilidade linear para lidar com dezenas ou até centenas de milhares de consultas por segundo (QPS).
Exemplo típico: o sistema central de transações de uma grande empresa de e-commerce.
Escolha um modo de operação
A tabela a seguir mapeia cada cenário para seu modo de operação recomendado e os resultados esperados.
|
Cenário |
Modo de operação recomendado |
Benefícios |
|
Negócio existente de grande porte |
Fragmentação de tabela não particionada |
Tabelas não particionadas são distribuídas entre nós de dados (DNs), superando os limites de recursos de um banco de dados independente e permitindo balanceamento de carga com melhoria de desempenho. A compatibilidade SQL com instruções existentes é maximizada, mantendo o desempenho das consultas praticamente inalterado. |
|
Mix de negócios existentes e novos |
Fragmentação de tabela não particionada + particionamento manual |
Oferece a mesma compatibilidade SQL descrita acima para cargas de trabalho existentes, superando limites de recursos de bancos de dados independentes por meio de balanceamento de carga e melhor desempenho. Para tabelas grandes em novas cargas de trabalho, aplique particionamento manual para resolver a escalabilidade de armazenamento, mantendo o desempenho de leitura e gravação. |
|
Novo negócio baseado em MySQL independente |
Particionamento automático |
Todas as tabelas são particionadas automaticamente, superando os limites de bancos de dados independentes. Todos os índices são globais por padrão, garantindo desempenho básico de consulta em colunas que não são chave primária. |
|
Negócio de alto desempenho e alto throughput |
Particionamento manual |
Selecione manualmente a estratégia de particionamento ideal para cada tabela com base nos seus padrões de consulta. Modifique instruções SQL para alcançar escalabilidade linear em cenários de alta concorrência. |
Aplique particionamento manual a tabelas específicas
Após definir o modo de operação como fragmentação de tabela não particionada, execute a seguinte instrução para particionar manualmente uma tabela grande:
ALTER TABLE <table_name> PARTITION BY KEY(<column_name>) locality='';
Para obter detalhes sobre o parâmetro locality, consulte Localidade.