Arquitetura Lakebase

O Lakebase separa o armazenamento da computação. O motor Postgres que executa suas consultas é sem estado, e seus dados vivem em uma camada de armazenamento durável que persiste de forma independente. Essa separação é o que torna possível o autoscaling, escala até zero, desvios instantâneos, réplicas de leitura e failover rápido.

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

Como um banco de dados tradicional é construído

Antes de olhar para o Lakebase, considere o modelo que ele substitui. Um banco de dados Postgres convencional é um monólito. Uma única máquina executa o mecanismo de consulta e grava tanto o log-ahead (WAL) quanto os arquivos de dados em um disco conectado em um ponto de montagem local. Tradicionalmente, esses discos eram verdadeiramente locais, parte da mesma máquina, mas à medida que a infraestrutura evoluiu, muitas vezes são dispositivos de armazenamento conectados à rede.

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

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

Um monólito tradicional de banco de dados em uma única máquina, onde o motor de consulta escreve em um log de escrita antecipada e lê a partir de arquivos de dados no disco local.

Acessar todos os seus dados por uma única máquina tem desvantagens:

  • A durabilidade está diretamente ligada à infraestrutura física dessa máquina. Você também precisa pré-provisionar o armazenamento e prever quanto sua carga de trabalho vai crescer, o que complica tanto a gestão de custos quanto o planejamento de resiliência.
  • Alta disponibilidade e muitos tipos de escalabilidade horizontal exigem clones físicos de todo o banco de dados.
  • Se essa máquina falhar, você pode perder dados. Técnicas como armazenamento RAID reduzem esse risco, mas a redundância adicional pode aumentar significativamente o custo de operação do sistema.

A arquitetura Lakebase

Lakebase mantém as mesmas responsabilidades, mas as separa 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 paginação e armazenamento de objetos em nuvem.

Os dois papéis do monólito são mapeados diretamente para os novos componentes. O WAL, que acelerava as escritas, tornava-se o protetor, que escalava as escritas em escala. Os arquivos de dados, que aceleravam as leituras, tornam-se os servidores de página, 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 paginação e armazenamento de objetos.

Como os dados vivem em armazenamento de objetos na nuvem e não em uma única máquina, o Lakebase oferece computação elástica, escalável e gravações duráveis replicadas entre zonas de disponibilidade. Não há armazenamento para provisionar: você paga apenas pelo armazenamento que consome, e não precisa se planejar em torno de falhas como ficar sem disco.

Esse 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 alinhamento de blocos. Como toda escrita já vai para múltiplos locais, o desempenho permanece consistente, esteja ou não habilitada alta disponibilidade.

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

Monólito tradicional Lakebase Função
Única máquina Computação sem estado Executa o motor de consultas Postgres
Disco WAL local Guardiões Registra de forma permanente cada mudança comprometida
Arquivos 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 roda o Postgres. Ele mantém apenas o estado transitório: o Postgres compartilha buffers na memória e um cache de computação local respaldado por disco local rápido. Não possui dados duráveis.

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

  • Ele pode ser substituído, reiniciado, escalado automaticamente ou escalado até zero sem mover ou perder dados.
  • Em vez de gravar em um sistema de arquivos local, ele transmite o WAL para a camada de armazenamento.
  • Múltiplas instâncias de computação podem se conectar à mesma camada de armazenamento, que é como funcionam as réplicas de leitura do Lakebase e o failover rápido .

Camada de armazenamento

A camada de armazenamento é durável e opera independentemente do cálculo. Ele 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 registros WAL, ela os transmite para um grupo de guardiões que replicam o registro através de um quórum usando um protocolo de consenso baseado em Paxos.

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

Servidores de paginação

Pageservers são os arquivos de dados, extraídos e reconstruídos a partir do WAL. Um servidor de páginas consome o fluxo WAL dos safekeepers e materializa versões de página sob demanda. Quando o compute solicita uma página em um número de sequência de log (LSN) específico, o servidor de páginas a reconstrói e retorna.

Os servidores de página atuam como um cache de escrita acima do armazenamento de objetos. Eles persistem assíncronamente páginas materializadas para armazenamento em nuvem, e a reconstrução de páginas não bloqueia um commit de transação.

Armazenamento de objetos de nuvem

O armazenamento de objetos na nuvem é a base de durabilidade de toda a camada de armazenamento. Ele mantém os dados de página que os servidores de página persistem.

Em Azure, Lakebase persiste os dados em Armazenamento de Blobs do Azure.

O armazenamento de objetos fica fora do caminho de consulta quente. Apenas servidores de paginação lêem dele. Para detalhes sobre como funciona a redundância de armazenamento e por que ela é independente da configuração de alta disponibilidade de computação, veja Arquitetura de armazenamento.

Como funciona uma escrita

Uma escrita flui do computo através da camada de armazenamento:

  1. O Postgres modifica as páginas afetadas na memória e produz registros WALL.
  2. Compute transmite os registros WAL para os guardiões seguros.
  3. Quando um quórum de guardiões reconhece os registros, a transação é comprometida 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 o armazenamento de objetos.

O caminho de escrita Lakebase, onde o Postgres transmite WAL para safekeepers cujo reconhecimento de quórum confirma a transação antes que os servidores de paginação a apliquem.

Uma transação é durável assim que um quórum de guardiões de segurança possui o registro WALL, porque o log sozinho já é suficiente para reconstruir os dados. Os servidores de paginas reconstroem e armazenam as páginas de dados depois, fora do caminho de commit, para que as escritas permaneçam rápidas sem colocar nenhuma alteração comprometida em risco.

Como funciona uma leitura

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

  1. Pool de buffer (memória): O Postgres compartilhava buffers na RAM de computação.
  2. Cache de computação local: Um cache de suporte em disco no nó de computação, dimensionado em relação à memória do computo.
  3. Servidor de Páginas: Em caso de erro de cache, o compute solicita a página de um servidor de páginas, que a reconstrói no LSN solicitado.
  4. Armazenamento de objetos: O servidor de páginas lê internamente do armazenamento de objetos quando necessário. Consultas não chegam diretamente ao armazenamento de objetos.

A hierarquia de cache de leitura do Lakebase do mais rápido ao mais lento: pool de buffer, cache de computação local, servidor de paginas e armazenamento de objetos.

O que essa arquitetura possibilita

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

Característica O que ele possibilita
Escala automática Como o processamento é sem estado, o Lakebase escala o tamanho do cálculo para cima ou para baixo em resposta à carga de trabalho sem mover dados.
Escalonamento até zero A computação pode pausar completamente enquanto o armazenamento persiste, e os dados ficam imediatamente disponíveis quando a computação recomeça.
Ramificações instantâneas Crie uma cópia isolada e gravável do seu banco de dados em segundos. Como o ramificação é uma operação de cópia ao escrever metadados contra armazenamento compartilhado, não duplica dados.
Ler réplicas Múltiplas instâncias de computação são lidas da mesma camada de armazenamento, então 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 mantém histórico, o compute pode se conectar a um ponto passado no tempo e ler o banco de dados como ele existia naquela época, sem copiar os dados de volta ao lugar.
Failover rápido O failover promove uma instância de computação secundária que se conecta ao armazenamento existente, sem dados para mover.
RPO = 0 (sem perda de dados comprometida) O Lakebase grava duramente todas as transações comprometidas antes de reconhecê-las, então você não perde dados comprometidos quando o processamento falha, reinicia ou escala para zero.

Como essa arquitetura suporta LTAP

Como o Lakebase armazena de forma permanente cada alteração comprometida no armazenamento de objetos na nuvem, os mesmos dados podem servir cargas de trabalho analíticas junto com transações sem um pipeline de replicação separado. Essa é a base para o Processamento Transacional e Analítico (LTAP) do Lago, onde uma única cópia dos seus dados suporta tanto motores transacionais quanto analíticos. Para entender como o LTAP se baseia nessa arquitetura, veja Arquitetura LTAP.

Próximas Etapas 

  • Arquitetura de armazenamento: Aprenda como funciona a redundância de armazenamento e por que ela é independente da configuração de alta disponibilidade de computação. Consulte a arquitetura de armazenamento.
  • Ramificações de banco de dados: Veja como os ramos usam armazenamento copy-on-write para criar ambientes instantâneos e isolados. Consulte Branches.
  • Leia réplicas: Adicione instâncias de computação somente leitura que compartilhem a mesma camada de armazenamento. Consulte réplicas de leitura.
  • Conceitos centrais: Revise o conjunto completo de conceitos que tornam Lakebase único. Veja Conceitos Centrais.
  • Last updated on