PolarDB:Cloud-native database PolarDB

Centralizado (Enterprise e Standard Editions)

• Proxy de banco de dados (Proxy)

  Um proxy de rede entre as aplicações e o banco de dados. Fornece autenticação de segurança, divisão automática de leitura e escrita, balanceamento de carga, níveis de consistência, pools de conexões, conexões persistentes e proteção contra sobrecarga.

• Nós de computação do banco de dados

  • O PolarDB utiliza uma arquitetura de cluster com múltiplos nós. Um cluster da Cluster Edition contém um nó de leitura/escrita e vários nós somente leitura.

  • Os nós de leitura/escrita e os nós somente leitura utilizam failover ativo-ativo para fornecer alta disponibilidade ao banco de dados.

  • Os nós de computação fornecem o recurso de motor SQL e estão disponíveis nas especificações de uso geral e dedicada.

• Armazenamento distribuído compartilhado

  Vários nós de computação compartilham uma única cópia dos dados, reduzindo os custos de armazenamento. Baseado em armazenamento em bloco distribuído e sistema de arquivos, permite dimensionar a capacidade online para centenas de terabytes.

Distribuído

• Nós do banco de dados

  • Composto por nós de computação (CNs) e nós de dados (DNs). Os CNs são nós de computação responsáveis pelo gerenciamento de metadados do cluster e pela geração de planos distribuídos. Os DNs são nós de dados responsáveis por armazenar os shards de dados reais.

  • Cada CN e DN utiliza uma arquitetura centralizada com desacoplamento de armazenamento e computação. Suporta um proxy de banco de dados e um modo com um nó primário e vários nós somente leitura. Fornece failover de alta disponibilidade para nós de computação dentro de um CN ou DN e suporta a adição de nós somente leitura (RO) para dimensionar a capacidade de leitura de um único CN ou DN.

• Recursos distribuídos

  • Suporta sharding manual e dimensionamento horizontal para cenários de negócios em nível de petabytes.

  • Garante consistência para transações distribuídas.

  • Suporta implantação em zona dupla. A zona primária é o cluster de trabalho, e a zona secundária é o Hot Standby Cluster.

  • Oferece recursos de atualização, downgrade e manutenção sem interrupções 24/7. Permite também a adição de nós CN e DN heterogêneos ao cluster.

Centralizado (Standard Edition)

• Nó de armazenamento (DN)

  Gerencia a persistência de dados com o protocolo de consenso Paxos para garantir alta confiabilidade e forte consistência. O Lizard distributed transaction engine system, desenvolvido internamente, oferece alta disponibilidade mais confiável e desempenho cerca de 35% superior ao motor distribuído nativo do MySQL.

• Arquitetura de dados com múltiplas réplicas

  O protocolo de consenso Paxos garante forte consistência (RPO = 0) entre as réplicas — cada escrita exige a confirmação da maioria. Se um nó falhar, o cluster continua operando. Funções das réplicas:

  • Leader

    Processa solicitações de clientes, toma decisões e mantém logs para garantir a consistência e a recuperabilidade dos dados.

  • Follower

    Executa instruções do Leader. Pode ser eleito como o novo Leader se o Leader atual falhar.

  • Logger

    Fornece apenas service para o protocolo Paxos (sem service de dados). Participa das eleições de Leader e pode assumir temporariamente a função de Leader até que os Followers se atualizem, e então cede a função.

  • Learner

    Recebe passivamente o status do sistema sem direitos de voto ou tomada de decisão.

Distribuído (Enterprise Edition)

• Global meta service (GMS)

  Mantém metadados globalmente consistentes (tabelas, schemas, estatísticas), informações de segurança (contas, permissões) e o global timestamp service (TSO).

• Nó de computação (CN)

  Ponto de entrada sem estado com analisador, otimizador e executor SQL. Lida com roteamento distribuído, computação, coordenação 2PC, DDL distribuído e manutenção de índices globais.

• Nó de armazenamento (DN)

  Persiste dados de row store com Paxos para forte consistência e MVCC para visibilidade de transações distribuídas. Suporta pushdown de computação (Project, Filter, Join, Aggregation).

• Nó de column store (Columnar)

  Persiste índices de columnstore no OSS, consumindo logs binários de transações distribuídas em tempo real. Em combinação com os nós de computação, fornece consultas de column store consistentes com snapshot.

• Nó de change data capture (CDC)

  Fornece inscrições incrementais compatíveis com o formato de log binário do MySQL e replicação primária/secundária compatível com o protocolo de replicação do MySQL.