Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Von Bedeutung
Lakebase Autoscaling ist in Beta in den folgenden Regionen: eastus2, westeurope, westus.
Lakebase Autoscaling ist die neueste Version von Lakebase mit automatischer Berechnung, Skalierung bis Null, Verzweigung und sofortiger Wiederherstellung. Einen Featurevergleich mit Lakebase Provisioned finden Sie unter Auswahl zwischen Versionen.
Mit der Verzweigung in Lakebase können Sie Ihre Datenumgebung sicher versionieren, testen und weiterentwickeln, ähnlich wie die Verzweigung Ihres Codes in Git. Sie können sofort isolierte, voll funktionsfähige Verzweigungen für Entwicklungs-, Experiment- oder Testschemaänderungen erstellen, ohne dass sich dies auf Produktionsworkloads auswirkt.
Standardmäßig erstellt Lakebase beim Erstellen eines neuen Projekts eine einzelne production Verzweigung. Dies ist Ihre Standardverzweigung, die dazu gedacht ist, die Produktionsdaten Ihrer Anwendung zu speichern.
Sie können nach Bedarf zusätzliche Verzweigungen erstellen, um ihren Workflow anzupassen. Fügen Sie z. B. eine development Verzweigung zum Erstellen und Testen, eine staging Verzweigung für Vorproduktionstests hinzu, oder erstellen Sie entwicklerspezifische Verzweigungen zur vollständigen Isolation. Jeder Branch funktioniert unabhängig – Änderungen in einem Kind wirken sich niemals auf das Eltern aus. Mit dem Branch-Reset können Sie jede untergeordnete Verzweigung von der übergeordneten Verzweigung aktualisieren, um das neueste Schema und die neuesten Daten abzurufen, ohne Daten-Seeding oder Teardown-Skripten.
Funktionsweise von Zweigniederlassungen
Eltern-Kind-Beziehungen
Jeder Zweig (mit Ausnahme des Stammzweigs) hat einen Elternknoten. Dadurch wird eine Hierarchie erstellt:
production (root branch)
├── staging (child of production)
│ └── feature-test (child of staging)
└── development (child of production)
└── bugfix-branch (child of development)
Diese Hierarchie bietet Ihnen wichtige Isolation: Änderungen, die Sie an einer untergeordneten Verzweigung vornehmen, wirken sich nicht auf das übergeordnete Element aus, und Änderungen an einem übergeordneten Element werden nicht automatisch in untergeordneten Elementen angezeigt. Wenn Sie aktualisierte Daten vom übergeordneten Element benötigen, können Sie die untergeordnete Verzweigung zurücksetzen. Sie können auch Verzweigungen aus jedem Punkt im Verlauf des übergeordneten Elements erstellen, was für die zeitpunktbezogene Wiederherstellung, das Testen gegen historische Daten oder Compliance-Szenarien nützlich ist.
Wenn Sie eine Verzweigung erstellen, wählen Sie aus, ob sie aus aktuellen Daten oder aus einem bestimmten Zeitpunkt initialisiert werden soll. Schrittweise Anleitungen und Details zu den einzelnen Optionen finden Sie unter "Erstellen einer Verzweigung ".
Kopier-on-Write-Speicher
Lakebase verwendet Copy-on-Write-Technologie, um die Eltern-Kind-Verzweigung effizient zu gestalten. Wenn Sie eine neue Verzweigung erstellen, erbt sie sowohl das Schema als auch die Daten vom übergeordneten Element, teilt jedoch den zugrunde liegenden Speicher über Zeiger auf dieselben Daten. Nur wenn Sie Daten ändern, schreibt Lakebase neue Daten. Dies bedeutet:
- Ihre Filialen werden sofort angezeigt; die Größe der Datenbank hat keine Auswirkungen auf die Erstellungszeit für Zweigstellen
- Sie zahlen nur für Daten, die sich tatsächlich zwischen Zweigniederlassungen ändern
- Das Erstellen von Filialen hat keine Auswirkungen auf die Leistung Ihrer Produktionsauslastung.
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
Arbeiten mit Zweigniederlassungen
Branch zurücksetzen
Die Aktualisierung eines Zweigs passt diesen sofort dem aktuellen Stand seines übergeordneten Zweigs an. Dies ist nützlich, wenn Sie Ihre Entwicklungs- oder Staging-Verzweigung mit den neuesten Daten des übergeordneten Elements aktualisieren möchten. Der Vorgang wird sofort mit der Copy-on-Write-Technologie abgeschlossen, und Ihre Verbindungsinformationen bleiben gleich.
Die Verzweigungszurücksetzung funktioniert nur in einer Richtung (übergeordnetes → untergeordnetes Element). Um Änderungen von untergeordneten zu übergeordneten Elementen zu verschieben, verwenden Sie Ihre Standardmigrationstools, um Änderungen am Schema anzuwenden. Detaillierte Schritte und Szenarien finden Sie unter "Zurücksetzen einer Verzweigung ".
Zeitpunktwiederherstellung
Sie können einen Branch von einem bestimmten Zeitpunkt innerhalb Ihres Wiederherstellungszeitfensters erstellen, was nützlich ist, um Datenfehler wie versehentliche Löschungen zu beheben, frühere Probleme zu untersuchen oder für Überwachungs- und Compliancezwecke auf historische Daten zuzugreifen. Wenn beispielsweise eine kritische Tabelle gestern um 10:23 Uhr gelöscht wurde, können Sie einen Branch erstellen, der auf 10:22 Uhr festgelegt ist, um die fehlenden Daten zu extrahieren. Ebenso können Sie Filialen erstellen, die Ihren Datenbankstatus zu bestimmten Zeitpunkten für finanzbezogene Abstimmungen, regulatorische Prüfungen oder forensische Analysen widerspiegeln. Im Gegensatz zur Verzweigungszurücksetzung (die eine vorhandene Verzweigung aktualisiert) erstellt die Point-in-Time-Wiederherstellung eine neue Verzweigung aus historischen Daten. Ausführliche Informationen finden Sie unter Zeitpunktwiederherstellung.
Spezielle Verzweigungstypen
Default-Branch
Wenn Sie ein Lakebase-Projekt erstellen, erhalten Sie automatisch eine einzelne production Verzweigung als Standardverzweigung. Sie beginnt leer, bereit für Ihre Daten. Sie können untergeordnete Branches für Entwicklung und Tests erstellen – testen Sie Ihre Schemaänderungen in einem untergeordneten Branch und führen Sie dann dieselben Migrationen mit production aus, wenn Sie sicher sind, dass sie funktionieren.
Ihre Standardverzweigung wird niemals auf Null skaliert, um sicherzustellen, dass sie auch dann verfügbar bleibt, wenn andere Verzweigungen im Leerlauf nach unten berechnet werden.
Geschützte Branches
Geschützte Filialen verfügen über Sicherheitsvorkehrungen, um versehentliche Änderungen zu verhindern. Sie können nicht gelöscht oder von ihrem übergeordneten Element zurückgesetzt werden, und sie sind aufgrund von Inaktivität von der automatischen Archivierung ausgenommen. Geschützte Verzweigungen blockieren auch das Löschen von Projekten, während sie vorhanden sind, und stellen Sie sicher, dass Sie die kritische Infrastruktur nicht versehentlich entfernen können. Verwenden Sie geschützte Branches für kritische Daten wie Produktionsdaten. Details finden Sie unter "Geschützte Verzweigungen ".
Auswirkungen der Verzweigung auf den Ressourcenverbrauch
Mit Filialen bezahlen Sie nur für das, was Sie tatsächlich nutzen.
Speicher: Sie zahlen nur für Daten, die sich ändern. Wenn Sie einen Entwicklungszweig erstellen und 1 GB Daten in einer 100 GB-Datenbank ändern, zahlen Sie ungefähr 1 GB Speicherplatz, nicht 200 GB. Die unveränderten 99 GB werden zwischen Zweigniederlassungen geteilt.
Compute: Jede Verzweigung verfügt über ein eigenes Compute, das Sie unabhängig skalieren können. Sie zahlen nur für aktive Computestunden. Berechnet die Skalierung bei Leerlauf auf Null. Dies bedeutet, dass ein Entwicklungszweig, der nur gelegentlich verwendet wird, viel weniger kostet als das Ausführen eines dedizierten Entwicklungsservers rund um die Uhr.
Standardbranch: Die Standardbranch wird niemals auf Null skaliert, sodass Ihre Produktionslast immer verfügbar bleibt.
Zweigstrategien
Im Folgenden finden Sie einige gängige Möglichkeiten, wie Teams ihre Zweigstellen organisieren:
Einfach (Einzelpersonen und kleine Teams)
Verwenden Sie Ihre Standardverzweigung mit einem einzelnen Entwicklungszweig:
production
└── development
Ihre development Branch ist der Ort, an dem Sie sicher neue Features entwickeln. Sie können Schemaänderungen vornehmen, Testdaten hinzufügen und ohne Risiko für Ihre Produktionszweige experimentieren. Wenn Sie bereit sind, führen Sie Ihre getesteten Schemamigrationen mit production unter Einsatz Ihres Migrationstools durch und setzen Sie development zurück, um das nächste Feature mit frischen Daten zu starten.
Mit Testumgebung
Fügen Sie einen Staging-Branch für Vorabproduktionstests hinzu:
production
├── staging
└── development
Wenn Sie Vorproduktionstests benötigen, verwalten Sie eine staging Verzweigung, die Ihre Produktionszweigdaten widerspiegelt. Stellen Sie Ihre Anwendung dort bereit, führen Sie Integrations- und Leistungstests mit realistischen Daten aus, und gewinnen Sie Vertrauen, bevor Sie live gehen. Setzen Sie staging regelmäßig von production zurück, um Ihre Testdaten zu aktualisieren.
Filialen pro Entwickler
Jeder Entwickler arbeitet vollständig isoliert:
production
└── development
├── dev-alice
├── dev-bob
└── dev-charlie
Dieses Muster verhindert, dass Entwickler die Arbeit der anderen beeinträchtigen und jedem das Testen von Schemaänderungen unabhängig ermöglichen. Jeder Entwickler kann mit seinen eigenen Schemaänderungen und Datenänderungen experimentieren, ohne andere zu beeinträchtigen, und dann getestete Migrationen auf den freigegebenen development oder production Branch anwenden, wenn er bereit ist.
Nächste Schritte
- Zweige verwalten, um zu lernen, wie man Zweige erstellt, zurücksetzt und löscht.
- Geschützte Filialen zum Schutz kritischer Filialen