Condividi tramite

Filiali

Importante

La scalabilità automatica di Lakebase si trova in Beta nelle aree seguenti: eastus2, westeurope, westus.

Lakebase Autoscaling è la versione più recente di Lakebase con calcolo autoscalante, riduzione a zero, ramificazione e ripristino istantaneo. Per il confronto delle funzionalità con Lakebase Provisioned, vedere scegliere tra le versioni.

La diramazione in Lakebase consente di creare versioni, testare ed evolvere in modo sicuro l'ambiente dati, in modo analogo al diramazione del codice in Git. È possibile creare immediatamente rami isolati e completamente funzionali per lo sviluppo, la sperimentazione o il test delle modifiche dello schema, senza influire sui carichi di lavoro di produzione.

Per impostazione predefinita, Lakebase crea un singolo production ramo quando si crea un nuovo progetto. Si tratta del ramo predefinito, destinato a ospitare i dati di produzione dell'applicazione.

È possibile creare rami aggiuntivi in base alle esigenze per adattare il flusso di lavoro. Ad esempio, aggiungere un ramo development per la compilazione e il test, un ramo staging per i test di pre-produzione o creare rami specifici per sviluppatore per l'isolamento completo. Ogni ramo opera in modo indipendente: le modifiche in un figlio non influiscono mai sul genitore. Con il reset del ramo, è possibile aggiornare qualsiasi ramo figlio dal relativo ramo padre per ottenere lo schema e i dati più recenti, senza script di inizializzazione o smantellamento dei dati.

Funzionamento dei rami

Relazioni padre-figlio

Ogni ramo (ad eccezione del ramo radice) ha un elemento padre. Verrà creata una gerarchia:

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

Questa gerarchia offre un isolamento importante: le modifiche apportate a un ramo figlio non influiscono sul relativo padre e le modifiche apportate a un padre non compaiono automaticamente nei rami figlio. Quando sono necessari dati aggiornati dal nodo principale, è possibile reimpostare il ramo figlio. È anche possibile creare rami da qualsiasi punto della cronologia dell'elemento padre, utile per il ripristino temporizzato, il test sui dati cronologici o gli scenari di conformità.

Quando si crea un ramo, si sceglie se inizializzarlo dai dati correnti o da un punto specifico nel tempo. Per istruzioni dettagliate e dettagli su ogni opzione, vedere Creare un ramo .

Archiviazione di copia su scrittura

Lakebase utilizza la tecnologia copy-on-write per rendere efficiente la ramificazione padre-figlio. Quando si crea un nuovo ramo, eredita sia lo schema che i dati dal relativo elemento padre, ma condivide lo spazio di archiviazione sottostante tramite puntatori agli stessi dati. Solo quando si modificano i dati, Lakebase scrive nuovi dati. Ciò significa:

  • I rami vengono visualizzati immediatamente; le dimensioni del database non hanno alcun impatto sul tempo di creazione del ramo
  • Si paga solo per i dati che cambiano effettivamente tra rami
  • La creazione di rami non ha alcun impatto sulle prestazioni del carico di lavoro di produzione
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

Uso dei rami

Reimpostazione del ramo

La reimpostazione del ramo aggiorna immediatamente un ramo figlio per farlo corrispondere allo stato corrente del ramo padre. Ciò è utile quando si vuole aggiornare il ramo di sviluppo o di gestione temporanea con i dati più recenti del relativo elemento padre. L'operazione viene completata immediatamente usando la tecnologia copy-on-write e i dettagli della connessione rimangono invariati.

La reimpostazione del ramo funziona solo in una direzione (padre → figlio). Per spostare le modifiche da figlio a padre, usare gli strumenti di migrazione standard per applicare le modifiche dello schema. Per informazioni dettagliate e scenari, vedere Reimpostare un ramo .

Recupero temporizzato

È possibile creare un ramo da un punto specifico nel tempo all'interno della finestra di ripristino, utile per il ripristino da errori di dati come eliminazioni accidentali, analisi dei problemi precedenti o accesso ai dati cronologici per scopi di controllo e conformità. Ad esempio, se una tabella critica è stata eliminata ieri alle 10:23, è possibile creare un ramo impostato su 10:22 am per estrarre i dati mancanti. Analogamente, è possibile creare rami che riflettono lo stato del database in date specifiche per riconciliazione finanziarie, controlli normativi o analisi forensi. A differenza della reimpostazione del ramo (che aggiorna un ramo esistente), il ripristino temporizzato crea un nuovo ramo dai dati cronologici. Per informazioni dettagliate, vedere Ripristino temporizzato .

Tipi di rami speciali

Ramo predefinito

Quando si crea un progetto Lakebase, si ottiene automaticamente un singolo production ramo come ramo predefinito. Inizia vuoto, pronto per i tuoi dati. È possibile creare rami figli per lo sviluppo e il test: testare le modifiche dello schema in un ramo figlio, quindi eseguire le stesse migrazioni su production quando siete certi del loro funzionamento.

Il tuo ramo predefinito non viene mai ridotto a zero, garantendo che rimanga disponibile anche quando altri rami vengono ridotti durante i periodi di inattività.

Rami protetti

I rami protetti hanno misure di sicurezza per evitare modifiche accidentali. Non possono essere eliminati o reimpostati dal padre e sono esenti dall'archiviazione automatica a causa dell'inattività. I rami protetti bloccano anche l'eliminazione del progetto mentre esistono, assicurandosi che non sia possibile rimuovere accidentalmente l'infrastruttura critica. Usare rami protetti per dati critici come la produzione. Per informazioni dettagliate, vedere Rami protetti .

Impatto del ramo sull'utilizzo delle risorse

Con i rami, si paga solo per ciò che si usa effettivamente.

Archiviazione: si paga solo per i dati modificati. Se si crea un ramo di sviluppo e si modificano 1 GB di dati in un database da 100 GB, si paga per circa 1 GB di spazio di archiviazione, non 200 GB. I 99 GB non modificati sono condivisi tra rami.

Calcolo: ogni ramo ha un proprio calcolo che è possibile ridimensionare in modo indipendente. Si paga solo per le ore di calcolo attive. Calcola la scalabilità su zero quando è inattiva. Ciò significa che un ramo di sviluppo usato a volte costa molto meno rispetto all'esecuzione di un server di sviluppo dedicato 24/7.

Ramo predefinito: il calcolo predefinito del ramo non viene mai ridimensionato a zero, assicurando che il carico di lavoro di produzione rimanga disponibile.

Strategie di ramo

Ecco alcuni modi comuni in cui i team organizzano i rami:

Semplice (singoli utenti e piccoli team)

Usare il ramo predefinito con un singolo ramo di sviluppo:

production
└── development

Il vostro development ramo è dove costruire nuove funzionalità in modo sicuro. È possibile apportare modifiche allo schema, aggiungere dati di test e sperimentare senza alcun rischio per il ramo di produzione. Quando si è pronti, eseguire le migrazioni dello schema testate su production (usando lo strumento di migrazione), quindi reimpostare development per avviare la funzionalità successiva con i dati aggiornati.

Con preparazione

Aggiungere un ramo di staging per i test di pre-produzione:

production
├── staging
└── development

Se sono necessari test di pre-produzione, gestisci un staging ramo che rispecchia i dati del ramo di produzione. Deplora l'applicazione lì, esegui test di integrazione e prestazioni su dati realistici e acquisisci fiducia prima di andare in produzione. Reimpostare periodicamente staging da production per aggiornare i dati di test.

Rami per sviluppatori

Ogni sviluppatore funziona in isolamento completo:

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

Questo modello impedisce agli sviluppatori di interferire tra loro e consente a tutti di testare le modifiche dello schema in modo indipendente. Ogni sviluppatore può sperimentare le modifiche dello schema e ai dati senza influire sugli altri, quindi applicare le migrazioni testate al ramo condiviso development o production quando è pronto.

Passaggi successivi

  • Last updated on