Udostępnij przez

Odgałęzienia

Ważne

Skalowanie automatyczne bazy danych Lakebase znajduje się w wersji beta w następujących regionach: eastus2, westeurope, westus.

Autoskalowanie bazy danych Lakebase to najnowsza wersja bazy danych Lakebase z automatycznym skalowaniem obliczeniowym, skalowaniem do zera, rozgałęzianiem i natychmiastowym przywracaniem. Aby porównać funkcje z zarezerwowaną wersją Lakebase, zobacz wybór pomiędzy wersjami.

Rozgałęzianie w usłudze Lakebase umożliwia bezpieczne przechowywanie wersji, testowanie i rozwijanie środowiska danych, podobnie jak rozgałęzianie kodu w usłudze Git. Można natychmiast tworzyć izolowane, w pełni funkcjonalne gałęzie na potrzeby programowania, eksperymentowania lub testowania zmian schematu bez wpływu na obciążenia produkcyjne.

Domyślnie usługa Lakebase tworzy pojedynczą production gałąź podczas tworzenia nowego projektu. Jest to domyślna gałąź przeznaczona do przechowywania danych produkcyjnych aplikacji.

Możesz utworzyć dodatkowe gałęzie zgodnie z potrzebami, aby dopasować przepływ pracy. Na przykład dodaj development gałąź do budowania i testowania, staging gałąź do testowania przedprodukcyjnego lub utwórz gałęzie dla poszczególnych deweloperów w celu całkowitej izolacji. Każda gałąź działa niezależnie — zmiany w gałęzi podrzędnej nigdy nie wpływają na gałąź nadrzędną. Za pomocą resetowania gałęzi można odświeżyć dowolną gałąź podrzędną z nadrzędnej, aby uzyskać najnowszy schemat i dane, bez inicjacji danych ani skryptów usuwających.

Jak działają gałęzie

Relacje rodzic-dziecko

Każda gałąź (z wyjątkiem gałęzi korzeniowej) ma element nadrzędny. Spowoduje to utworzenie hierarchii:

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

Ta hierarchia zapewnia ważną izolację: zmiany wprowadzone w gałęzi podrzędnej nie wpływają na jej gałąź nadrzędną, a zmiany w gałęzi nadrzędnej nie są automatycznie wyświetlane w gałęziach podrzędnych. Gdy potrzebujesz zaktualizowanych danych z elementu nadrzędnego, możesz zresetować gałąź podrzędną. Można również tworzyć gałęzie z dowolnego punktu w historii repozytorium nadrzędnego, co jest przydatne w przypadku przywracania do określonego momentu w czasie, testowania względem danych historycznych lub scenariuszy zgodności.

Podczas tworzenia gałęzi należy wybrać, czy zainicjować ją z bieżących danych, czy z określonego punktu w czasie. Zobacz Tworzenie gałęzi, aby uzyskać instrukcje krok po kroku i szczegółowe informacje na temat każdej opcji.

Przechowywanie z kopiowaniem przy zapisie

Usługa Lakebase używa technologii kopiowania na zapis, aby wydajnie realizować rozgałęzianie typu rodzic-dziecko. Podczas tworzenia nowej gałęzi dziedziczy zarówno schemat, jak i dane od swojego rodzica, ale dzieli ten sam magazyn pamięci poprzez wskaźniki do tych samych danych. Tylko podczas modyfikowania danych usługa Lakebase zapisuje nowe dane. Oznacza to:

  • Twoje gałęzie są wyświetlane natychmiast; rozmiar bazy danych nie ma wpływu na czas tworzenia gałęzi
  • Płacisz tylko za dane, które rzeczywiście zmieniają się między gałęziami
  • Tworzenie gałęzi nie ma wpływu na wydajność obciążenia produkcyjnego
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

Praca z gałęziami

Resetowanie gałęzi

Resetowanie gałęzi natychmiast aktualizuje gałąź podrzędną, aby dopasować ją do obecnego stanu gałęzi nadrzędnej. Jest to przydatne, gdy chcesz odświeżyć gałąź deweloperską lub testową przy użyciu najnowszych danych od gałęzi nadrzędnej. Operacja jest wykonywana natychmiast przy użyciu technologii kopiowania na zapis, a szczegóły połączenia pozostają takie same.

Resetowanie gałęzi działa tylko w jednym kierunku (nadrzędny → podrzędny). Aby przenieść zmiany z elementu podrzędnego do elementu nadrzędnego, użyj standardowych narzędzi migracji, aby zastosować zmiany schematu. Zobacz Resetowanie gałęzi w celu uzyskania szczegółowych instrukcji i scenariuszy.

Odzyskiwanie punktu w czasie

Możesz utworzyć gałąź z określonego punktu w czasie w ramach okna przywracania, co jest przydatne do odzyskiwania po błędach danych, takich jak przypadkowe usunięcie, badanie problemów z przeszłości lub uzyskiwanie dostępu do danych historycznych dla potrzeb audytu i zgodności. Jeśli na przykład tabela krytyczna została usunięta wczoraj o godzinie 10:23, możesz utworzyć gałąź ustawioną na 10:22, aby wyodrębnić brakujące dane. Podobnie można tworzyć gałęzie odzwierciedlające stan bazy danych w określonych datach uzgodnień finansowych, inspekcji regulacyjnych lub analizy kryminalistycznej. W przeciwieństwie do resetowania gałęzi (które aktualizuje istniejącą gałąź w miejscu), odzyskiwanie punktu w czasie tworzy nową główną gałąź na podstawie danych historycznych, pozostawiając oryginalną gałąź bez zmian i operacyjną. Aby uzyskać szczegółowe informacje, zobacz Przywracanie do punktu w czasie .

Specjalne typy gałęzi

Gałąź domyślna

Podczas tworzenia projektu Lakebase automatycznie otrzymujesz pojedynczą production gałąź jako gałąź domyślną. Jest pusty, gotowy na twoje dane. Możesz utworzyć gałęzie podrzędne na potrzeby rozwoju i testowania — przetestuj zmiany schematu w gałęzi podrzędnej, a następnie uruchom te same migracje w , gdy masz pewność, że działają.

Gałąź domyślna nigdy nie jest skalowana do zera, co zapewnia dostępność, nawet gdy inne gałęzie zmniejszają skalę w okresach bezczynności.

Chronione gałęzie

Chronione gałęzie mają zabezpieczenia, aby zapobiec przypadkowym zmianom. Nie można ich usunąć ani zresetować z poziomu elementu nadrzędnego i są one wykluczone z automatycznego archiwizowania z powodu braku aktywności. Chronione gałęzie blokują również usuwanie projektu, gdy istnieją, zapewniając, że nie można przypadkowo usunąć infrastruktury krytycznej. Używaj chronionych gałęzi dla danych krytycznych, takich jak produkcja. Aby uzyskać szczegółowe informacje, zobacz Chronione gałęzie .

Jak rozgałęzianie wpływa na zużycie zasobów

W przypadku gałęzi płacisz tylko za rzeczywiste użycie.

Przechowywanie: płacisz tylko za dane, które się zmieniają. Jeśli tworzysz gałąź programistyczne i modyfikujesz 1 GB danych w bazie danych o rozmiarze 100 GB, płacisz za około 1 GB miejsca do magazynowania, a nie 200 GB. Niezmienione 99 GB jest współdzielone między gałęziami.

Obliczenia: każda gałąź ma własne zasoby obliczeniowe, które można skalować niezależnie. Płacisz tylko za aktywne godziny obliczeniowe. Obliczenia są skalowane do zera w przypadku bezczynności. Oznacza to, że gałąź rozwojowa używana sporadycznie kosztuje znacznie mniej niż uruchomienie dedykowanego serwera rozwojowego 24/7.

Gałąź domyślna: Domyślne obliczenia gałęzi nigdy nie są skalowane do zera, dzięki czemu obciążenie produkcyjne pozostanie dostępne.

Strategie branży

Oto kilka z typowych sposobów, w jakie zespoły zarządzają swoimi gałęziami:

Proste (osoby i małe zespoły)

Użyj gałęzi domyślnej z pojedynczą gałęzią dewelopera:

production
└── development

Gałąź development umożliwia bezpieczne tworzenie nowych funkcji. Możesz wprowadzać zmiany schematu, dodawać dane testowe i eksperymentować bez ryzyka dla gałęzi produkcyjnej. Gdy wszystko będzie gotowe, uruchom przetestowane migracje production schematu (przy użyciu narzędzia do migracji), a następnie zresetuj development , aby uruchomić następną funkcję przy użyciu nowych danych.

Ze środowiskiem przejściowym

Dodaj gałąź tymczasową na potrzeby testowania przedprodukcyjnego:

production
├── staging
└── development

Jeśli potrzebujesz testów przedprodukcyjnych, utrzymuj gałąź staging, która odzwierciedla dane gałęzi produkcyjnej. Wdróż aplikację w tym miejscu, uruchom testy integracji i wydajności względem realistycznych danych i uzyskaj pewność, zanim przejdziesz na żywo. Okresowo resetuj staging z production aby odświeżyć dane testowe.

Osobne gałęzie dla każdego dewelopera

Każdy deweloper działa w pełnej izolacji:

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

Ten wzorzec uniemożliwia deweloperom zakłócanie pracy ze sobą i umożliwia wszystkim niezależne testowanie zmian schematu. Każdy deweloper może eksperymentować z własnymi zmianami schematu i modyfikacjami danych bez wpływu na inne osoby, a następnie stosować przetestowane migracje do udostępnionej development lub production gałęzi, gdy będą gotowe.

Dalsze kroki

  • Last updated on