Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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.
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.
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:
- O Postgres modifica as páginas afetadas na memória e produz registos WAL.
- Calcula os fluxos dos registos WAL para os guardiões seguros.
- Quando um quórum de guardiões reconhece os registos, a transação compromete-se e o cliente recebe sucesso.
- Os servidores de páginas aplicam o WAL de forma assíncrona e mantêm as páginas atualizadas para armazenamento de objetos.
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:
- Pool de buffer (memória): O Postgres partilhava buffers na RAM de computação.
- Cache de computação local: Uma cache suportada por disco no nó de computação, dimensionada em relação à memória do computador.
- 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.
- 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.
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.