Arquitetura Lakebase

info

Beta

A partir de 15 de junho, o Lakebase está disponível em Beta no GCP. Consulte Disponibilidade de região para regiões compatíveis.

O Lakebase separa o armazenamento do compute. O mecanismo Postgres que executa suas queries é stateless, e seus dados residem em uma camada de armazenamento durável que persiste de forma independente. Essa separação é o que torna possível o autoscale, o scale-to-zero, os Branch instantâneos, as réplicas de leitura e o failover rápido.

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

Como se constrói um banco de dados tradicional

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

O WAL e os arquivos de dados desempenham duas funções complementares:

• O WAL acelera as gravações. O Postgres anexa cada alteração ao log sequencialmente antes de confirmar 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, de modo que uma consulta pode ler uma linha sem reproduzir o log.

O acesso a todos os seus dados através de uma única máquina apresenta desvantagens:

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

A arquitetura Lakebase

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

• Uma camada de compute que executa o Postgres padrão e stateless.
• Uma camada de armazenamento composta por safekeepers, pageservers e armazenamento de objetos na cloud.

As duas funções do monolito mapeiam diretamente os novos componentes. O WAL, que acelerou as escritas, torna-se o guardião , que escala as escritas. Os arquivos de dados, que aceleraram as leituras, tornam-se os servidores de páginas , que escalam as leituras.

Como os dados residem no armazenamento de objetos em nuvem, em vez de em uma única máquina, o Lakebase oferece computação elástica e escalável, além de gravações duráveis replicadas em zonas de disponibilidade. Não há necessidade de provisionar armazenamento: você paga apenas pelo armazenamento que consome e não precisa se preocupar com falhas, como a falta de espaço em disco.

Este modelo também melhora o desempenho. O Lakebase grava cada alteração diretamente em vários locais, evitando assim a sobrecarga da proteção tradicional contra gravação interrompida e alinhamento de blocos. Como cada gravação já vai para vários locais, o desempenho permanece consistente, independentemente de a alta disponibilidade estar habilitada ou não.

A tabela a seguir mapeia cada parte do monolito para sua contraparte no Lakebase.

Monólito tradicional	Lakebase	Função
Máquina única	Compute sem estado	Executa o mecanismo de query Postgres
Disco WAL local	Safekeepers	Registra de forma durável cada alteração consolidada
Arquivos de dados locais	Servidores de páginas e armazenamento de objetos	Materializa e armazena versões de página

Monólito tradicional	Lakebase	Função
Máquina única	Compute sem estado	Executa o mecanismo de query Postgres
Disco WAL local	Safekeepers	Registra de forma durável cada alteração consolidada
Arquivos de dados locais	Servidores de páginas e armazenamento de objetos	Materializa e armazena versões de página

Camada de compute

A camada de compute executa o Postgres. Ele mantém apenas o estado transitório: os buffers compartilhados do Postgres na memória e um cache de compute local suportado por disco local rápido. Ele não possui dados duráveis.

Como o compute não possui estado durável:

• Ele pode ser substituído, reiniciado, ter o autoscale aplicado ou ser reduzido a 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.
• Várias instâncias de computação podem se conectar à mesma camada de armazenamento, e é assim que 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 compute. Ele tem três componentes.

Safekeepers

Os safekeepers são o WAL, extraídos da máquina única e tornados altamente disponíveis. À medida que o Postgres produz registros WAL, ele os transmite para um grupo de safekeepers que replicam o log em um quórum usando um protocolo de consenso baseado em Paxos.

Uma transação commit quando um quórum de safekeepers reconhece o registro WAL, não quando uma única máquina termina um fsync local. A durabilidade vem da replicação entre nós, em vez de um único disco.

Servidores de páginas

Os pageservers são os arquivos de dados, extraídos e reconstruídos a partir do WAL. Um pageserver consome a transmissão de 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 pageserver a reconstrói e a retorna.

Os Pageservers atuam como um cache write-through acima do armazenamento de objetos. Eles persistem de forma assíncrona as páginas materializadas no armazenamento de objetos na cloud, e a reconstrução da página não bloqueia um commit de transação.

Armazenamento de objetos na cloud

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

No GCP, o Lakebase persiste dados no Google Cloud Storage.

O armazenamento de objetos permanece fora do caminho de query quente. Somente os pageservers leem a partir dele. Para obter detalhes sobre como a redundância de armazenamento funciona e por que ela é independente da configuração de alta disponibilidade do compute, consulte Arquitetura de armazenamento.

Como funciona uma gravação

Uma gravação flui do compute através da camada de armazenamento:

1. O Postgres modifica as páginas afetadas na memória e produz registros WAL.
2. O compute transmite os registros WAL para os safekeepers.
3. Quando um quórum de custodiantes reconhece os registros, a transação commit e o cliente recebe a notificação de sucesso.
4. Os Pageservers aplicam o WAL de forma assíncrona e persistem as páginas atualizadas no armazenamento de objetos.

Uma transação é durável assim que um quórum de safekeepers possui o registro WAL, pois o log por si só é suficiente para reconstruir os dados. Os Pageservers reconstroem e armazenam as páginas de dados posteriormente, fora do caminho de commit, para que as gravações permaneçam rápidas sem colocar em risco qualquer alteração consolidada.

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. Buffer pool (memória): Os buffers compartilhados do Postgres na RAM do compute.
2. Cache de compute local: Um cache baseado em disco no nó de compute, dimensionado em relação à memória do compute.
3. Pageserver: Em caso de cache miss, o compute solicita a página de um pageserver, que a reconstrói no LSN solicitado.
4. Armazenamento de objetos: o pageserver lê do armazenamento de objetos internamente quando necessário. As queries não acessam o armazenamento de objetos diretamente.

O que esta arquitetura possibilita

Separar o compute stateless do armazenamento durável é o que torna possíveis vários recursos do Lakebase:

Recurso	O que ele viabiliza
Dimensionamento automático	Como o compute é stateless, o Lakebase aumenta ou diminui o tamanho do compute em resposta à carga de trabalho sem mover dados.
Dimensionamento para zero	O compute pode entrar em pausa completamente enquanto o armazenamento persiste, e os dados ficam imediatamente disponíveis quando o compute é retomado.
Instant Branch	Crie uma cópia isolada e gravável do seu banco de dados em segundos. Como a ramificação é uma operação de metadados copy-on-write no armazenamento compartilhado, ela não duplica dados.
Réplicas de leitura	Múltiplas instâncias de compute leem da mesma camada de armazenamento, portanto, as réplicas não precisam de cópias de dados e começam em segundos.
Consultas point-in-time	Como a camada de armazenamento retém o histórico, o compute pode se conectar a um ponto anterior no tempo e ler o banco de dados como ele existia na época, sem copiar dados de volta para o local.
Failover rápido	O failover promove uma instância de compute secundária que se anexa ao armazenamento existente, sem necessidade de mover dados.
RPO = 0 (nenhuma perda de dados confirmada)	O Lakebase registra de forma durável cada transação confirmada antes de reconhecê-la, para que você não perca dados confirmados quando o compute falha, reinicia ou é reduzido a zero.

Recurso	O que ele viabiliza
Dimensionamento automático	Como o compute é stateless, o Lakebase aumenta ou diminui o tamanho do compute em resposta à carga de trabalho sem mover dados.
Dimensionamento para zero	O compute pode entrar em pausa completamente enquanto o armazenamento persiste, e os dados ficam imediatamente disponíveis quando o compute é retomado.
Instant Branch	Crie uma cópia isolada e gravável do seu banco de dados em segundos. Como a ramificação é uma operação de metadados copy-on-write no armazenamento compartilhado, ela não duplica dados.
Réplicas de leitura	Múltiplas instâncias de compute leem da mesma camada de armazenamento, portanto, as réplicas não precisam de cópias de dados e começam em segundos.
Consultas point-in-time	Como a camada de armazenamento retém o histórico, o compute pode se conectar a um ponto anterior no tempo e ler o banco de dados como ele existia na época, sem copiar dados de volta para o local.
Failover rápido	O failover promove uma instância de compute secundária que se anexa ao armazenamento existente, sem necessidade de mover dados.
RPO = 0 (nenhuma perda de dados confirmada)	O Lakebase registra de forma durável cada transação confirmada antes de reconhecê-la, para que você não perca dados confirmados quando o compute falha, reinicia ou é reduzido a zero.

Como esta arquitetura suporta LTAP

Como o Lakebase armazena de forma durável cada alteração confirmada no armazenamento de objetos em 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 para o Lake Transactional and Analytical Processing (LTAP), onde uma única cópia dos seus dados suporta mecanismos transacionais e analíticos. Para saber como o LTAP se baseia nesta arquitetura, consulte Arquitetura LTAP.

Passos seguintes

• Arquitetura de armazenamento: saiba como a redundância de armazenamento funciona e por que ela é independente da configuração de alta disponibilidade do compute. Consulte Arquitetura de armazenamento.
• Branches de banco de dados: veja como as branches usam armazenamento copy-on-write para criar ambientes isolados e instantâneos. See Branch.
• Réplicas de leitura: Adicione instâncias de compute somente leitura que compartilham a mesma camada de armazenamento. Consulte Réplicas de leitura.
• Conceitos fundamentais: analise o conjunto completo de conceitos que tornam o Lakebase único. Consulte Conceitos fundamentais.