Storage copy-on-write

Sklonuj całą bazę danych w kilka sekund

Utwórz pełną kopię PostgreSQL z prawdziwymi danymi w mniej niż 30 sekund. Bez dumpa, bez restore i prawie bez dodatkowego storage na starcie.

Wypróbuj Vela Sandbox za darmo Zobacz branching

Dlaczego tradycyjne klonowanie baz boli

Standardowy proces to nadal pg_dump i pg_restore. Dla małych baz to działa, ale przy produkcyjnych wolumenach zaczyna blokować zespoły.

Typowa rzeczywistość pg_dump / pg_restore dla bazy 100 GB

  • → Dump trwa 30-60 minut i tworzy duże archiwum.
  • → Restore zajmuje kolejne 30-60 minut i wymaga pełnej dodatkowej kopii na dysku.
  • → Dziesięć równoległych kopii to nawet około 1 TB dodatkowego storage.
  • → Zespoły wracają do współdzielonego stagingu, bo klonowanie jest zbyt wolne.

Restore ze snapshotu jest lepszy niż dump/restore, ale nadal trwa wiele minut i dalej tworzy pełną kopię danych.

Jak działa klonowanie copy-on-write

Vela klonuje na poziomie storage. Źródło i klon początkowo współdzielą te same bloki, więc nie ma kosztownego kopiowania.

Dopiero po zapisie zmienione bloki są odkładane osobno. Dzięki temu czas utworzenia jest stały, a koszty storage rosną tylko wraz z rzeczywistymi zmianami.

  • Czas utworzenia klona prawie nie rośnie wraz z rozmiarem bazy.
  • Klon tylko do odczytu zużywa niemal zero dodatkowego storage.
  • Zapisy są odizolowane i nie wpływają na źródło.
  • Usunięcie klona jest natychmiastowe.

Co umożliwia natychmiastowe klonowanie

Workflowy, które stają się praktyczne, gdy klonowanie jest szybkie i tanie.

Testy przed migracją

Uruchamiaj zmiany schematu na klonie produkcji przed dotknięciem realnej bazy.

  • Testuj ALTER TABLE na prawdziwych danych
  • Wykrywaj błędy ograniczeń wcześniej
  • Mierz wydajność po migracji

Testy obciążeniowe i wydajnościowe

Benchmarkuj na danych produkcyjnych zamiast na sztucznych fixture.

  • Zachowaj prawdziwą kardynalność danych
  • Bezpiecznie uruchamiaj EXPLAIN ANALYZE
  • Usuń klon po zakończeniu testu

Środowiska deweloperskie

Daj każdemu inżynierowi pełną kopię bazy zamiast jednej współdzielonej instancji dev.

  • Lokalne środowiska jak produkcja
  • Brak konfliktów zapisów
  • Szybkie tworzenie i sprzątanie

Pipeline maskowania danych

Sklonuj produkcję, zamaskuj dane i bezpiecznie udostępnij zanonimizowaną kopię.

  • Start z pełnych danych produkcyjnych
  • Maskowanie PII na klonie
  • Źródłowa baza pozostaje bezpieczna

Porównanie podejść do klonowania

Cecha pg_dump / restore Restore ze snapshotu Klon Vela CoW
Czas utworzenia klona (100 GB) 45-90 minut 10-30 minut < 30 sekund
Dodatkowy storage na klon 100 GB pełnej kopii 100 GB pełnej kopii Prawie zero na starcie
Dziesięć równoległych klonów ~1 TB dodatkowego storage ~1 TB dodatkowego storage Prawie zero do czasu zmian
Automatyzacja przez API Tylko CLI API dostawcy REST API i UI

Powiązane

Przegląd database branchingu Środowiska stagingowe Postgresa Migracja do Vela

Najczęstsze pytania

Jak Vela klonuje PostgreSQL tak szybko?

Vela używa copy-on-write na poziomie storage. Klon współdzieli niezmienione bloki ze źródłem, więc podczas tworzenia nie ma pełnego transferu danych.

Jaka jest różnica między klonem a branchem?

Klon to odizolowana kopia. Branch korzysta z tego samego mechanizmu, ale jest zarządzany jako część workflow branchingu.

Ile storage zużywa klon?

Na starcie prawie zero. Dodatkowy storage rośnie dopiero wtedy, gdy klon albo źródło modyfikują własne bloki danych.

Czy mogę klonować aktywną bazę produkcyjną?

Tak. Vela tworzy spójny snapshot bez zatrzymywania ruchu produkcyjnego.

Klonuj bazę w kilka sekund

Wypróbuj copy-on-write cloning w sandboxie bez przygotowywania infrastruktury.

Wypróbuj Vela Sandbox za darmo Workflow branch per PR