Partilhar via

Ramos

Importante

A Lakebase Autoscaling está em Beta nas seguintes regiões: eastus2, westeurope, westus.

O Autoscaling do Lakebase é a versão mais recente do Lakebase com computação automática, escala até zero, ramificação e restauração instantânea. Para comparação de funcionalidades com o Lakebase Provisioned, veja a escolha entre versões.

O ramificar no Lakebase permite-te versionar, testar e evoluir o teu ambiente de dados de forma segura, semelhante a ramificar o teu código no Git. Pode criar instantaneamente ramificações isoladas e totalmente funcionais para desenvolvimento, experimentação ou teste de alterações de esquema, sem afetar as cargas de trabalho de produção.

Por defeito, o Lakebase cria um único production ramo quando crias um novo projeto. Esta é a sua branch predefinida, destinada a armazenar os dados de produção da sua aplicação.

Pode criar ramificações adicionais conforme necessário para se adaptar ao seu fluxo de trabalho. Por exemplo, adicionar um development ramo para construção e teste, um staging ramo para testes pré-produção, ou criar ramos por desenvolvedor para isolamento completo. Cada ramo opera de forma independente — as mudanças numa criança nunca afetam o seu progenitor. Com a redefinição do ramo, podes atualizar qualquer ramo filho a partir do seu ramo parente para obteres o esquema e os dados mais recentes, sem criar semente de dados ou scripts de desmontagem.

Como funcionam as filiais

Relações entre pais e filhos

Cada ramo (exceto o ramo raiz) tem um pai. Isto cria uma hierarquia:

production (root branch)
├── staging (child of production)
│   └── feature-test (child of staging)
└── development (child of production)
    └── bugfix-branch (child of development)

Esta hierarquia dá-te um isolamento importante: as alterações que fazes a um ramo filho não afetam o seu pai, e as alterações a um ramo pai não aparecem automaticamente nos filhos. Quando precisar de dados atualizados do pai, pode reiniciar o ramo filho. Também pode criar ramificações a partir de qualquer ponto do histórico principal, o que é útil para recuperação a um ponto específico no tempo, testar com dados históricos ou cenários de conformidade.

Quando crias um branch, escolhes se o inicializas a partir de dados atuais ou a partir de um ponto específico no tempo. Consulte Criar um ramo para instruções passo a passo e detalhes sobre cada opção.

Armazenamento de cópia na escrita

O Lakebase utiliza a tecnologia de cópia em escrita para tornar a ramificação pai-filho eficiente. Quando crias uma nova ramificação, ela herda tanto o esquema como os dados do pai, mas partilha o armazenamento subjacente através de ponteiros para os mesmos dados. Só quando modificas dados é que o Lakebase escreve novos dados. Isto significa:

  • Os teus ramos aparecem instantaneamente; o tamanho da tua base de dados não tem impacto no tempo de criação de ramificações
  • Só pagas por dados que realmente mudam entre agências
  • Criar ramos não tem impacto de desempenho na carga de trabalho de produção
production branch                child branch (at creation)
┌─────────────────┐       ┌─────────────────┐
│  [Data A]       │◄──────│  → Data A       │  (shared)
│  [Data B]       │◄──────│  → Data B       │  (shared)
│  [Data C]       │◄──────│  → Data C       │  (shared)
└─────────────────┘       └─────────────────┘

After modifying data in child branch:
┌─────────────────┐       ┌─────────────────┐
│  [Data A]       │◄──────│  → Data A       │  (shared)
│  [Data B]       │       │  [Data B']      │  (changed)
│  [Data C]       │◄──────│  → Data C       │  (shared)
└─────────────────┘       └─────────────────┘
                          Only changed data is stored separately

Colaboração com filiais

Reinício da ramificação

A reinicialização de branch atualiza instantaneamente um branch filho para corresponder ao estado presente do pai. Isto é útil quando pretende atualizar o seu ramo de desenvolvimento ou de preparação com os dados mais recentes do ramo principal. A operação é concluída instantaneamente usando tecnologia de copiar e escrever, e os seus dados de ligação mantêm-se iguais.

A ressetagem do branch só funciona numa direção (pai → filho). Para transferir alterações do filho para o pai, use as suas ferramentas padrão de migração para aplicar alterações de esquema. Consulte Reiniciar uma ramificação para passos e cenários detalhados.

Recuperação de ponto no tempo

Pode criar uma ramificação a partir de um ponto específico dentro da sua janela de restauro, o que é útil para recuperar de erros de dados como eliminações acidentais, investigar problemas passados ou aceder a dados históricos para fins de auditoria e conformidade. Por exemplo, se uma tabela crítica foi abandonada ontem às 10:23 da manhã, pode criar um branch definido para as 10:22 da manhã para extrair os dados em falta. Da mesma forma, pode criar ramos que reflitam o estado da sua base de dados em datas específicas para conciliações financeiras, auditorias regulamentares ou análise forense. Ao contrário do reset de ramo (que atualiza um ramo existente), a recuperação pontual cria um novo ramo a partir de dados históricos. Consulte a seção Restauração pontual para mais detalhes.

Tipos de ramos especiais

Ramificação padrão

Quando crias um projeto Lakebase, recebes automaticamente um único production branch como o teu branch predefinido. Começa vazio, pronto para os teus dados. Pode criar ramificações filhas para desenvolvimento e teste — testar as alterações de esquema numa ramificação filha, e depois executar as mesmas migrações em production depois de confirmar que funcionam.

O seu ramo padrão nunca escala até zero, garantindo que permanece disponível mesmo quando outros cálculos de ramo reduzem durante os períodos de inatividade.

Ramos protegidos

Os ramos protegidos têm salvaguardas para evitar alterações acidentais. Não podem ser eliminados ou redefinidos a partir do seu elemento principal, e estão isentos de arquivamento automático por inatividade. As ramificações protegidas também bloqueiam a eliminação de projetos enquanto estiverem presentes, garantindo que não poderá remover acidentalmente a infraestrutura crítica. Utilize branches protegidas para dados críticos, como produção. Consulte Ramos Protegidos para mais detalhes.

Como a ramificação impacta o consumo de recursos

Com as agências, só pagas pelo que realmente usas.

Armazenamento: Paga apenas pelos dados que sofrem alterações. Se criares uma ramificação de desenvolvimento e modificares 1GB de dados numa base de dados de 100GB, pagas por aproximadamente 1GB de armazenamento, não por 200GB. Os 99GB inalterados são partilhados entre ramos.

Processamento: Cada instância tem a sua própria capacidade de processamento que pode ser escalada de forma independente. Pagas apenas por horas de computação ativas. Os cálculos escalam até zero quando estão inativos. Isto significa que um ramo de desenvolvimento que usas por vezes custa muito menos do que gerir um servidor dedicado 24/7.

Ramo predefinido: A sua computação de ramo predefinido nunca reduz a zero, garantindo que a carga de trabalho de produção permaneça disponível.

Estratégias de ramificação

Aqui estão algumas formas comuns como as equipas organizam as suas filiais:

Simples (individuais e equipas pequenas)

Use o seu ramo predefinido com um único ramo de desenvolvimento:

production
└── development

A tua development filial é onde constroem novas funcionalidades de forma segura. Pode fazer alterações de esquema, adicionar dados de teste e experimentar sem qualquer risco para o seu ramo de produção. Quando estiveres pronto, executa as migrações de esquemas testadas no production usando a tua ferramenta de migração e, em seguida, restaura development para iniciar o próximo recurso com dados novos.

Com encenação

Adicione um ramo de staging para testes pré-produção:

production
├── staging
└── development

Se precisares de testes pré-produção, mantém um staging ramo que espelhe os dados do ramo de produção. Implemente a sua aplicação lá, execute testes de integração e desempenho com dados realistas, e ganhe confiança antes de lançar. Reinicia periodicamente staging a partir de production para atualizar os teus dados de teste.

Ramos por programador

Cada programador trabalha em completo isolamento:

production
└── development
    ├── dev-alice
    ├── dev-bob
    └── dev-charlie

Este padrão impede que os programadores interfiram no trabalho uns dos outros e permite que todos testem alterações de esquema de forma independente. Cada programador pode experimentar as suas próprias alterações de esquema e modificações de dados sem afetar os outros, e depois aplicar migrações testadas ao shared development ou production branch quando estiver pronto.

Próximos passos

  • Last updated on