중요합니다
Lakebase 자동 크기 조정은 다음 지역의 베타에 있습니다. eastus2westeuropewestus
Lakebase 자동 크기 조정은 자동 크기 조정 컴퓨팅, 0으로 크기 조정, 분기 및 즉시 복원이 포함된 최신 버전의 Lakebase입니다. Lakebase 프로비저닝된 기능 비교는 버전 중에서 선택하는 것을 참조하세요.
Lakebase에서 분기하면 Git에서 코드를 분기하는 것과 유사하게 데이터 환경을 안전하게 버전 관리, 테스트 및 발전할 수 있습니다. 프로덕션 워크로드에 영향을 주지 않고 개발, 실험 또는 테스트 스키마 변경을 위해 격리되고 완벽하게 작동하는 분기를 즉시 만들 수 있습니다.
기본적으로 Lakebase는 새 프로젝트를 만들 때 단일 production 분기를 만듭니다. 애플리케이션의 프로덕션 데이터를 보관하기 위한 기본 분기입니다.
필요에 따라 워크플로에 맞게 추가 분기를 만들 수 있습니다. 예를 들어 빌드 및 테스트를 위한 development 분기, 사전 프로덕션 테스트를 위한 staging 분기를 추가하거나, 완전한 격리를 위해 개발자별 분기를 생성합니다. 각 브랜치는 독립적으로 운영됩니다. 자식의 변경 사항은 부모에 영향을 미치지 않습니다. 분기 재설정을 사용하면 부모에서 자식 분기를 새로 고쳐 데이터 시드 또는 해체 스크립트 없이 최신 스키마 및 데이터를 가져올 수 있습니다.
분기 작동 방식
부모-자식 관계
루트 분기를 제외한 모든 분기에는 부모가 있습니다. 이렇게 하면 계층이 만들어집니다.
production (root branch)
├── staging (child of production)
│ └── feature-test (child of staging)
└── development (child of production)
└── bugfix-branch (child of development)
이 계층 구조는 중요한 격리를 제공합니다. 자식 분기에 대한 변경 내용은 부모에 영향을 주지 않으며 부모에 대한 변경 내용은 자식에 자동으로 표시되지 않습니다. 부모로부터 업데이트된 데이터가 필요한 경우 자식 분기를 다시 설정할 수 있습니다. 또한 시점별 복구, 과거 데이터에 대한 테스트 또는 규정 준수 시나리오에 유용하게 부모 히스토리의 어느 지점에서든 분기를 생성할 수 있습니다.
분기를 만들 때 현재 데이터에서 초기화할지 특정 시점부터 초기화할지 여부를 선택합니다. 각 옵션에 대한 단계별 지침 및 세부 정보는 분기 만들기 를 참조하세요.
복사-후-쓰기 저장
Lakebase는 쓰기에 복사 기술을 사용하여 부모-자식 분기를 효율적으로 만듭니다. 새 분기를 만들 때 부모에서 스키마와 데이터를 모두 상속하지만 동일한 데이터에 대한 포인터를 통해 기본 스토리지를 공유합니다. 데이터를 수정할 때만 Lakebase는 새 데이터를 작성합니다. 즉, 다음을 의미합니다.
- 분기가 즉시 표시됩니다. 데이터베이스 크기는 분기 생성 시간에 영향을 주지 않습니다.
- 분기 간에 실제로 변경되는 데이터에 대해서만 요금을 지불합니다.
- 분기를 생성하는 것은 프로덕션 워크로드의 성능에 영향을 주지 않습니다.
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
분기 작업
브랜치 재설정
분기 재설정은 부모의 현재 상태와 일치하도록 자식 분기를 즉시 업데이트합니다. 이는 부모의 최신 데이터를 사용하여 개발 또는 준비 분기를 새로 고치려는 경우에 유용합니다. 쓰기 시 복사 기술을 사용하여 작업이 즉시 완료되며 연결 세부 정보는 동일하게 유지됩니다.
분기 재설정은 한 방향만 작동합니다(부모 → 자식). 변경 내용을 자식에서 부모로 이동하려면 표준 마이그레이션 도구를 사용하여 스키마 변경 내용을 적용합니다. 자세한 단계 및 시나리오는 분기 재설정을 참조하세요.
지정 시간 복구
복원 기간 내의 특정 시점부터 분기를 만들 수 있습니다. 이는 실수로 인한 삭제, 과거 문제 조사 또는 감사 및 규정 준수를 위해 기록 데이터에 액세스하는 것과 같은 데이터 오류로부터 복구하는 데 유용합니다. 예를 들어 중요한 테이블이 어제 오전 10시 23분에 삭제된 경우 오전 10시 22분으로 설정된 분기를 만들어 누락된 데이터를 추출할 수 있습니다. 마찬가지로 재무 조정, 규제 감사 또는 법의학 분석을 위해 특정 날짜에 데이터베이스 상태를 반영하는 분기를 만들 수 있습니다. 기존 분기를 현재 위치에서 업데이트하는 분기 재설정과 달리 지정 시간 복구는 원래 분기를 변경하지 않고 작동하면서 기록 데이터에서 새 루트 분기를 만듭니다. 자세한 내용은 지정 시간 복원 을 참조하세요.
특수 분기 유형
기본 분기
Lakebase 프로젝트를 만들 때 자동으로 단일 production 분기를 기본 분기로 가져옵니다. 데이터 입력 준비가 완료된 상태로 비어 있는 채로 시작합니다. 개발 및 테스트를 위한 자식 분기를 만들 수 있습니다. 자식 분기에서 스키마 변경 내용을 테스트한 다음, 그들이 확실히 작동한다고 확인되면 동일한 마이그레이션을 production에 대해 실행합니다.
기본 분기는 0으로 확장되지 않으므로 유휴 기간 동안 다른 분기 컴퓨팅이 축소된 경우에도 계속 사용할 수 있습니다.
보호된 브랜치들
보호된 브랜치에는 우발적인 변경을 방지하기 위한 안전장치가 있습니다. 부모에서 삭제하거나 재설정할 수 없으며 비활성으로 인해 자동 보관에서 제외됩니다. 또한 보호된 분기는 존재하는 동안 프로젝트 삭제를 차단하여 중요한 인프라를 실수로 제거할 수 없도록 합니다. 프로덕션과 같은 중요한 데이터에 보호된 분기를 사용합니다. 자세한 내용은 보호된 분기 를 참조하세요.
분기가 리소스 소비에 미치는 영향
브랜치를 사용하면 실제로 사용하는 항목에 대해서만 비용을 지불합니다.
스토리지: 변경되는 데이터에 대해서만 요금을 지불합니다. 개발 분기를 만들고 100GB 데이터베이스에서 1GB의 데이터를 수정하는 경우 200GB가 아닌 약 1GB의 스토리지 비용을 지불합니다. 변경되지 않은 99GB는 분기 간에 공유됩니다.
컴퓨팅: 각 분기에는 독립적으로 확장할 수 있는 고유한 컴퓨팅이 있습니다. 활성 컴퓨팅 시간에 대해서만 요금을 지불합니다. 유휴 상태일 때 컴퓨팅 크기가 0으로 조정됩니다. 즉, 가끔 사용하는 개발 분기는 전용 개발 서버 24/7을 실행하는 것보다 훨씬 적은 비용이 듭니다.
기본 분기: 기본 분기 컴퓨팅은 0으로 확장되지 않고 프로덕션 워크로드를 계속 사용할 수 있도록 합니다.
브랜치 전략
다음은 팀이 분기를 구성하는 몇 가지 일반적인 방법입니다.
단순(개인 및 소규모 팀)
단일 개발 분기에서 기본 분기를 사용합니다.
production
└── development
development 브랜치는 새 기능을 안전하게 개발하는 공간입니다. 스키마를 변경하고, 테스트 데이터를 추가하고, 프로덕션 분기에 위험 없이 실험할 수 있습니다. 준비가 되면 마이그레이션 도구를 사용하여 테스트된 스키마 마이그레이션을 production 실행한 다음 다시 설정 development 하여 새 데이터로 다음 기능을 시작합니다.
스테이징을 사용하여
사전 프로덕션 테스트를 위한 스테이징 브랜치를 추가합니다.
production
├── staging
└── development
사전 프로덕션 테스트가 필요한 경우, 프로덕션 브랜치를 미러링하는 staging 브랜치를 유지 관리합니다. 애플리케이션을 배포하고, 실제 데이터에 대한 통합 및 성능 테스트를 실행하고, 라이브로 전환하기 전에 자신감을 얻습니다.
staging에서 production을(를) 주기적으로 재설정하여 테스트 데이터를 새로 고치십시오.
개발자별 브랜치
각 개발자는 완전히 격리된 상태로 작동합니다.
production
└── development
├── dev-alice
├── dev-bob
└── dev-charlie
이 패턴은 개발자가 서로의 작업을 방해하지 않도록 하고 모든 사용자가 스키마 변경 내용을 독립적으로 테스트할 수 있도록 합니다. 각 개발자는 다른 사용자에게 영향을 주지 않고 자체 스키마 변경 및 데이터 수정을 실험한 다음, 준비가 되면 공유 development 또는 production 분기에 테스트된 마이그레이션을 적용할 수 있습니다.