Arquitetura Lakebase

O Lakebase separa o armazenamento do computo. O motor Postgres que executa as suas consultas é sem estado, e os seus dados vivem numa camada de armazenamento duradoura que persiste de forma independente. Esta separação é o que torna possível o autoescalonamento, escalabilidade a zero, branches instantâneas, réplicas de leitura e failover rápido.

Para mostrar o que o Lakebase altera, esta página começa com o design tradicional de base de dados de máquina única para contraste, depois explica como o Lakebase separa esse mesmo design em camadas independentes e o que cada peça faz.

Como é construída uma base de dados tradicional

Antes de olhar para o Lakebase, considere o modelo que ele substitui. Uma base de dados Postgres convencional é um monólito. Uma única máquina executa o motor de consulta e escreve tanto o registo de escrita antecipada (WAL) como os ficheiros de dados num disco ligado num ponto local de montagem. Tradicionalmente, estes discos eram verdadeiramente locais, parte da mesma máquina, mas à medida que a infraestrutura evoluiu, são frequentemente dispositivos de armazenamento ligados à rede.

O WAL e os ficheiros de dados desempenham dois papéis complementares:

  • O WAL acelera as escritas. O Postgres adiciona cada alteração ao registo sequencialmente antes de reconhecer um commit, o que é rápido e durável num único disco.
  • Os ficheiros de dados aceleram as leituras. O Postgres materializa a versão atual de cada página em ficheiros de dados, para que uma consulta possa ler uma linha sem repetir o registo.

Um monólito tradicional de base de dados numa única máquina, onde o motor de consulta escreve num registo de escrita antecipada e lê a partir de ficheiros de dados no disco local.

Aceder a todos os seus dados através de uma única máquina tem desvantagens:

  • A durabilidade está diretamente ligada à infraestrutura física dessa máquina. Também tens de pré-provisionar armazenamento e prever quanto a tua carga de trabalho vai crescer, o que complica tanto a gestão de custos como o planeamento de resiliência.
  • A alta disponibilidade e muitos tipos de escalonamento horizontal requerem clones físicos de toda a base de dados.
  • Se essa máquina falhar, pode perder dados. Técnicas como o armazenamento RAID reduzem este risco, mas a redundância adicional pode aumentar significativamente o custo de funcionamento do sistema.

A arquitetura Lakebase

A Lakebase mantém as mesmas responsabilidades, mas separa-as em duas camadas independentes:

  • Uma camada de computação que executa Postgres padrão e sem estado.
  • Uma camada de armazenamento composta por safekeepers, servidores de páginas e armazenamento de objetos na cloud.

Os dois papéis do monólito são mapeados diretamente para os novos componentes. O WAL, que acelerou as escritas, torna-se o guardião seguro, que escala as escritas. Os ficheiros de dados, que aceleravam as leituras, tornam-se os servidores de páginas, que escalam as leituras.

A arquitetura Lakebase com uma camada de computação Postgres sem estado acima de uma camada de armazenamento de safekeepers, servidores de páginas e armazenamento de objetos.

Como os dados vivem em armazenamento de objetos na cloud em vez de numa única máquina, o Lakebase oferece computação elástica, escalável e escritas duráveis replicadas entre zonas de disponibilidade. Não há armazenamento para provisionar: pagas apenas pelo armazenamento que consomes, e não tens de planear em torno de modos de falha como ficar sem disco.

Este modelo também melhora o desempenho. O Lakebase escreve cada alteração diretamente em múltiplos locais, evitando assim a sobrecarga da proteção tradicional contra escrita rasgada e do alinhamento de blocos. Como cada escrita já vai para múltiplos locais, o desempenho mantém-se consistente, quer a alta disponibilidade esteja ativada ou não.

A tabela seguinte mapeia cada parte do monólito para a sua contraparte de Lakebase.

Monólito tradicional Lakebase Role
Única máquina Computação sem estado Executa o motor de consultas Postgres
Disco WAL local Guardiões Regista de forma permanente cada alteração comprometida
Ficheiros de dados locais Servidores de paginação e armazenamento de objetos Materializa e armazena versões da página

Camada de computação

A camada de computação corre o Postgres. Mantém apenas o estado transitório: o Postgres partilhava buffers na memória e uma cache de computação local apoiada por disco local rápido. Não possui dados duráveis.

Como a computação não possui um estado duradouro:

  • Pode ser substituído, reiniciado, escalado automaticamente ou escalado até zero sem mover ou perder dados.
  • Em vez de escrever num sistema de ficheiros local, transmite o WAL para a camada de armazenamento.
  • Múltiplas instâncias de computação podem ser ligadas à mesma camada de armazenamento, que é como funcionam as réplicas de leitura e o failover rápido do Lakebase.

Camada de armazenamento

A camada de armazenamento é durável e opera independentemente do cálculo. Tem três componentes.

Guardiões

Os Safekeepers são os WAL, retirados da única máquina e disponibilizados em alta disponibilidade. À medida que a Postgres produz registos WAL, transmite-os para um grupo de guardiões que replicam o registo através de um quórum, usando um protocolo de consenso baseado na Paxos.

Uma transação compromete-se quando um quórum de guardiões de segurança reconhece o registo WAL, e não quando uma única máquina termina um registo local fsync. A durabilidade resulta da replicação entre nós e não de um único disco.

Servidores de páginas

Os servidores de páginas são os ficheiros de dados, retirados e reconstruídos a partir do WAL. Um servidor de páginas consome o fluxo WAL dos guardiões de segurança e materializa versões de página a pedido. Quando o compute solicita uma página num número específico de sequência de log (LSN), o pageserver reconstrói e devolve-a.

Os servidores de páginas funcionam como uma cache de escrita acima do armazenamento de objetos. Persistem de forma assíncrona páginas materializadas para armazenamento de objetos na cloud, e a reconstrução de páginas não bloqueia um commit de transação.

Armazenamento de objetos na nuvem

O armazenamento de objetos na cloud é a base de durabilidade de toda a camada de armazenamento. Contém os dados de página que os servidores de páginas persistem.

No Azure, o Lakebase persiste os dados para Armazenamento de Blobs do Azure.

O armazenamento de objetos mantém-se fora do caminho de consulta quente. Só os servidores de páginas leem dele. Para detalhes sobre como funciona a redundância de armazenamento e porque é independente da definição de alta disponibilidade de computação, veja Arquitetura de armazenamento.

Como funciona uma escrita

Uma escrita flui da computação através da camada de armazenamento:

  1. O Postgres modifica as páginas afetadas na memória e produz registos WAL.
  2. Calcula os fluxos dos registos WAL para os guardiões seguros.
  3. Quando um quórum de guardiões reconhece os registos, a transação compromete-se e o cliente recebe sucesso.
  4. Os servidores de páginas aplicam o WAL de forma assíncrona e mantêm as páginas atualizadas para armazenamento de objetos.

O caminho de escrita Lakebase, onde o Postgres transmite WAL para os guardiões de segurança cujo reconhecimento de quórum confirma a transação antes de os servidores de páginas a aplicarem.

Uma transação é durável assim que um quórum de guardiões de segurança tiver o registo WAL, porque o registo por si só é suficiente para reconstruir os dados. Os servidores de páginas reconstroem e armazenam as páginas de dados depois, fora do caminho de commit, para que as escritas se mantenham rápidas sem colocar em risco qualquer alteração comprometida.

Como funciona uma leitura

As leituras verificam uma hierarquia de caches, do mais rápido para o mais lento, e param na primeira camada que contém a página:

  1. Pool de buffer (memória): O Postgres partilhava buffers na RAM de computação.
  2. Cache de computação local: Uma cache suportada por disco no nó de computação, dimensionada em relação à memória do computador.
  3. Servidor de páginas: Num erro de cache, o compute solicita a página a um servidor de páginas, que a reconstrói no LSN solicitado.
  4. Armazenamento de objetos: O pageserver lê internamente a partir do armazenamento de objetos quando necessário. As consultas não chegam diretamente ao armazenamento de objetos.

A hierarquia da cache de leitura do Lakebase do mais rápido para o mais lento: pool de buffers, cache de computação local, servidor de páginas e armazenamento de objetos.

O que esta arquitetura permite

Separar computação sem estado do armazenamento durável é o que torna várias funcionalidades do Lakebase possíveis:

Feature O que isso possibilita
Dimensionamento automático Como a computação é sem estado, o Lakebase escala o tamanho do cálculo para cima ou para baixo em resposta à carga de trabalho sem mover dados.
Redução a zero A computação pode pausar completamente enquanto o armazenamento persiste, e os dados estão imediatamente disponíveis quando a computação recomeça.
Ramificações instantâneas Crie uma cópia isolada e gravável da sua base de dados em segundos. Como a ramificação é uma operação de cópia ao escrever metadados contra armazenamento partilhado, não duplica dados.
Ler réplicas Múltiplas instâncias de computação são lidas da mesma camada de armazenamento, por isso as réplicas não precisam de cópias de dados e começam em segundos.
Consultas em ponto no tempo Como a camada de armazenamento retém o histórico, o compute pode ligar-se a um ponto passado no tempo e ler a base de dados como existia então, sem copiar os dados de volta para o seu lugar.
Failover rápido O failover promove uma instância de computação secundária que se liga ao armazenamento existente, sem dados para mover.
RPO = 0 (sem perda de dados comprometida) O Lakebase regista de forma permanente todas as transações comprometidas antes de as reconhecer, por isso não perdes dados comprometidos quando o cálculo falha, reinicia ou escala até zero.

Como esta arquitetura suporta LTAP

Como o Lakebase armazena de forma permanente todas as alterações comprometidas no armazenamento de objetos na cloud, os mesmos dados podem servir cargas de trabalho analíticas juntamente com transações sem um pipeline de replicação separado. Esta é a base do Lake Transactional and Analytical Processing (LTAP), onde uma única cópia dos seus dados suporta tanto motores transacionais como analíticos. Para saber como o LTAP se baseia nesta arquitetura, veja arquitetura LTAP.

Passos seguintes

  • Arquitetura de armazenamento: Aprenda como funciona a redundância de armazenamento e por que é independente da definição de alta disponibilidade de computação. Ver Arquitetura de armazenamento.
  • Ramos de bases de dados: Veja como as ramificações usam armazenamento copy-on-write para criar ambientes instantâneos e isolados. Ver Ramificações.
  • Leia réplicas: Adicione instâncias de computação só de leitura que partilhem a mesma camada de armazenamento. Ver Ler réplicas.
  • Conceitos centrais: Revise o conjunto completo de conceitos que tornam a Lakebase única. Ver conceitos centrais.