Przyrostowa synchronizacja danych z punktami kontrolnymi — bezpieczne wyrównywanie systemów

Dlaczego pełne reimporty ciągle sprawiają problemy

Pełne reimporty wydają się bezpieczne, bo wyglądają prosto: usuń, załaduj, gotowe. W praktyce są jednym z najłatwiejszych sposobów na powolne synchronizacje, wyższe koszty i niechlujne dane.

Pierwszy problem to czas i koszty. Pobieranie całego zbioru danych przy każdym uruchomieniu oznacza wielokrotne ściąganie tych samych rekordów. Jeśli synchronizujesz 500 000 klientów co noc, płacisz za obliczenia, wywołania API i zapisy do bazy danych, nawet gdy zmieniło się tylko 200 rekordów.

Drugi problem to poprawność. Pełne reimporty często tworzą duplikaty (bo reguły dopasowania nie są idealne) lub nadpisują nowsze edycje starszymi danymi z eksportu. Wiele zespołów obserwuje też dryf sum, ponieważ „usuń i załaduj” może niepostrzeżenie zawieść w połowie procesu.

Typowe objawy wyglądają tak:

• Liczby nie zgadzają się między systemami po uruchomieniu
• Rekordy pojawiają się dwukrotnie z drobnymi różnicami (wielkość liter w emailu, format telefonu)
• Ostatnio zaktualizowane pola wracają do starszej wartości
• Synchronizacja czasem „kończy się”, ale pomija fragment danych
• Po każdym oknie importu rośnie liczba zgłoszeń do wsparcia

Punkt kontrolny to po prostu mały zapis mówiący: „przetworzyłem do tego miejsca”. Następnym razem zaczynasz od tego miejsca zamiast od początku. Marker może być znacznik czasu, ID rekordu, numer wersji lub token zwrócony przez API.

Jeśli Twoim prawdziwym celem jest utrzymanie dwóch systemów w zgodzie w czasie, przyrostowa synchronizacja danych z punktami kontrolnymi zwykle jest lepszym wyborem. Jest szczególnie przydatna, gdy dane zmieniają się często, eksporty są duże, API mają limity wywołań albo gdy synchronizacja musi się bezpiecznie wznowić po awarii (np. gdy zadanie zawiedzie w Twoim wewnętrznym narzędziu zbudowanym na platformie AppMaster).

Zdefiniuj cel synchronizacji zanim wybierzesz metodę

Przyrostowa synchronizacja z punktami kontrolnymi działa dobrze tylko wtedy, gdy wiesz, co oznacza „poprawnie”. Jeśli pominiesz to i od razu przejdziesz do cursorów lub hashy, zwykle będziesz później przebudowywać synchronizację, bo reguły nie zostały spisane.

Zacznij od nazwania systemów i ustalenia, kto ma prawdę. Na przykład CRM może być źródłem prawdy dla imion i numerów telefonów, a narzędzie billingowe — dla statusu subskrypcji. Jeśli oba systemy mogą edytować to samo pole, nie masz jednego źródła prawdy i musisz zaplanować rozwiązywanie konfliktów.

Następnie zdefiniuj, co znaczy „zsynchronizowane”. Czy potrzebujesz dokładnego dopasowania w każdym momencie, czy wystarczy, że aktualizacje pojawią się w ciągu kilku minut? Dokładne dopasowanie często oznacza surowsze wymogi kolejności, mocniejsze gwarancje wokół checkpointów i ostrożniejsze traktowanie usunięć. Spójność eventualna jest zwykle tańsza i bardziej tolerancyjna na chwilowe błędy.

Zdecyduj kierunek synchronizacji. Synchronizacja jednokierunkowa jest prostsza: System A zasila System B. Dwukierunkowa jest trudniejsza, bo każda aktualizacja może być konfliktem i musisz unikać pętli, w których obie strony ciągle „poprawiają” się nawzajem.

Pytania do odpowiedzenia przed budową

Zapisz proste reguły, na które wszyscy się zgadzają:

• Który system jest źródłem prawdy dla każdego pola (lub typu obiektu)?
• Jakie opóźnienie jest akceptowalne (sekundy, minuty, godziny)?
• Czy to jest jednokierunkowe czy dwukierunkowe i jakie zdarzenia płyną w każdą stronę?
• Jak obsługiwane są usunięcia (hard delete, soft delete, tombstones)?
• Co się dzieje, gdy obie strony zmieniły ten sam rekord?

Praktyczny zestaw reguł konfliktów może być prosty: „billing wygrywa dla pól subskrypcji, CRM wygrywa dla pól kontaktowych, w pozostałych przypadkach wygrywa najnowsza aktualizacja.” Jeśli budujesz integrację w narzędziu takim jak AppMaster, uchwyć te reguły w logice Business Process, żeby były widoczne i testowalne, a nie ukryte w czyjejś głowie.

Cursory, hashe i tokeny wznowienia: elementy budulcowe

Przyrostowa synchronizacja zwykle opiera się na jednym z trzech „pozycji”, które można bezpiecznie przechowywać i ponownie użyć. Właściwy wybór zależy od tego, co źródło jest w stanie zagwarantować i jakie awarie musisz przetrwać.

Checkpoint typu cursor jest najprostszy. Zapisujesz „ostatnią rzecz, którą przetworzyłem”, np. ostatnie ID, ostatni timestamp w updated_at albo numer sekwencji. Przy kolejnym uruchomieniu żądasz rekordów późniejszych niż ten punkt. Działa dobrze, gdy źródło sortuje konsekwentnie, a ID lub timestampy przesuwają się naprzód w przewidywalny sposób. Zawodzi, gdy aktualizacje przychodzą z opóźnieniem, zegary się różnią lub rekordy mogą zostać wstawione „w przeszłość” (np. backfill).

Hashe pomagają wykryć zmiany, gdy sam cursor nie wystarcza. Możesz zahashować każdy rekord (na podstawie pól, na których Ci zależy) i synchronizować tylko gdy hash się zmieni. Albo zahashować cały batch, by szybko wykryć dryf, a potem zawęzić sprawę. Hash per rekord jest dokładny, ale zwiększa koszty przechowywania i obliczeń. Hash batchowy jest tańszy, ale może ukryć, który element się zmienił.

Tokeny wznowienia to niejawne wartości wydawane przez źródło, często do paginacji lub strumieni zdarzeń. Nie interpretujesz ich, po prostu zapisujesz i przekazujesz z powrotem, by kontynuować. Tokeny są świetne, gdy API jest skomplikowane, ale mogą wygasać, stawać się nieważne po okresach retencji lub działać inaczej w różnych środowiskach.

Co użyć i co może pójść nie tak

• Cursor: szybki i prosty, ale uważaj na aktualizacje poza kolejnością.
• Hash per rekord: precyzyjne wykrywanie zmian, ale wyższe koszty.
• Hash batchowy: tani sygnał dryfu, ale mało szczegółowy.
• Token wznowienia: najbezpieczniejsza paginacja, ale może wygasnąć lub być jednorazowy.
• Hybryda (cursor + hash): powszechna, gdy updated_at nie jest w pełni wiarygodny.

Jeśli budujesz synchronizację w narzędziu takim jak AppMaster, te checkpointy zwykle przechowuje się w małej tabeli „sync state”, aby każde uruchomienie mogło wznowić bez zgadywania.

Projektowanie przechowywania checkpointów

Przechowywanie checkpointów to mały element, który sprawia, że przyrostowa synchronizacja jest niezawodna. Jeśli jest trudno dostępne, łatwe do nadpisania lub nie związane z konkretnym zadaniem, Twoja synchronizacja będzie działać dopóki nie zawiedzie raz — wtedy będziesz zgadywać.

Najpierw wybierz miejsce na checkpointy. Tabela w bazie danych zwykle jest najbezpieczniejsza, bo wspiera transakcje, audyt i proste zapytania. Klucz-wartość może działać, jeśli już go używasz i obsługuje atomowe aktualizacje. Plik konfiguracyjny nadaje się tylko dla pojedynczego użytkownika i małego ryzyka, bo trudno go zablokować i łatwo zgubić.

Co przechowywać (i dlaczego)

Checkpoint to więcej niż sam cursor. Zapisz wystarczający kontekst, by zdebugować, wznowić i wykryć dryf:

• Tożsamość zadania: nazwa zadania, tenant lub account id, typ obiektu (np. customers)
• Postęp: wartość cursora lub token wznowienia oraz typ cursora (czas, id, token)
• Sygnały zdrowia: ostatni czas uruchomienia, status, liczba odczytanych i zapisanych rekordów
• Bezpieczeństwo: ostatni skuteczny cursor (nie tylko ostatni próbowany) oraz krótki komunikat o błędzie dla ostatniej awarii

Jeśli używasz hashów do wykrywania zmian, przechowaj też wersję metody hashującej. W przeciwnym razie możesz zmienić hash później i przypadkowo potraktować wszystko jako „zmienione”.

Wersjonowanie i wiele zadań sync

Gdy model danych się zmienia, wersjonuj checkpointy. Najprostsze podejście to dodanie pola schema_version i tworzenie nowych wierszy dla nowej wersji, zamiast modyfikować stare dane. Przechowuj stare wiersze przez jakiś czas, by móc się cofnąć.

Dla wielu zadań synchronizacji nazwij wszystko w przestrzeni nazw. Dobry klucz to (tenant_id, integration_id, object_name, job_version). To unika klasycznego błędu, gdy dwa zadania dzielą jeden cursor i cicho pomijają dane.

Konkretny przykład: jeśli budujesz synchronizację jako wewnętrzne narzędzie w AppMaster, przechowuj checkpointy w PostgreSQL po jednym wierszu na tenant i obiekt i aktualizuj je tylko po pomyślnym zatwierdzeniu batcha.

Krok po kroku: implementacja pętli przyrostowej

Przyrostowa synchronizacja działa najlepiej, gdy pętla jest nudna i przewidywalna. Cel jest prosty: czytaj zmiany w stabilnym porządku, zapisuj je bezpiecznie, a następnie przesuwaj checkpoint tylko wtedy, gdy wiesz, że zapis się powiódł.

Prosta pętla, której możesz zaufać

Najpierw wybierz porządek, który dla tego samego rekordu nigdy się nie zmienia. Timestamps mogą działać, ale tylko jeśli dołożysz tiebreaker (np. ID), żeby dwie aktualizacje w tym samym czasie nie zmieniały kolejności.

Potem wykonuj pętlę tak:

• Zdecyduj o cursorze (np. last_updated + id) i rozmiarze strony.
• Pobierz następną stronę rekordów nowszych niż przechowywany checkpoint.
• Upsertuj każdy rekord do docelowego systemu (create jeśli brak, update jeśli jest) i rejestruj błędy.
• Zatwierdź pomyślne zapisy, a następnie zapisz nowy checkpoint oparty na ostatnim przetworzonym rekordzie.
• Powtarzaj. Jeśli strona jest pusta, uśpij proces, a potem spróbuj ponownie.

Trzymaj zapis checkpointu oddzielnie od fetchu. Jeśli zapiszesz checkpoint za wcześnie, awaria może cicho pominąć dane.

Backoff i retry bez duplikatów

Zakładaj, że wywołania będą padać. Gdy fetch lub zapis zawiedzie, retryuj z krótkim backoffem (np. 1s, 2s, 5s) i maksymalną liczbą prób. Uczyń retry bezpiecznym przez użycie upsertów i idempotentnych zapisów (to samo wejście daje ten sam wynik).

Mały praktyczny przykład: jeśli synchronizujesz aktualizacje klientów co minutę, możesz pobierać po 200 zmian, upsertować je i dopiero potem zapisać jako nowy cursor last_updated, id na podstawie ostatniego rekordu.

Jeśli budujesz to w AppMaster, możesz zamodelować checkpoint w prostej tabeli (Data Designer) i uruchomić pętlę w Business Process, która pobiera, upsertuje i aktualizuje checkpoint w jednym kontrolowanym przepływie.

Spraw, by wznowienia były bezpieczne: idempotencja i atomowe checkpointy

Jeśli Twoja synchronizacja może być wznowiona, wznowi się w najgorszym możliwym momencie: po timeoutcie, awarii lub częściowym wdrożeniu. Cel jest prosty: ponowne uruchomienie tego samego batcha nie powinno tworzyć duplikatów ani tracić aktualizacji.

Idempotencja to sieć bezpieczeństwa. Osiągasz ją, zapisując w sposób powtarzalny bez wpływu na końcowy rezultat. W praktyce zwykle oznacza to upserty, a nie inserty: zapisz rekord używając stabilnego klucza (np. customer_id) i aktualizuj istniejące wiersze, gdy już są.

Dobry „write key” to coś, na czym możesz polegać przy retryach. Popularne opcje to naturalne ID ze źródła lub syntetyczny klucz zapisany za pierwszym razem, gdy zobaczysz rekord. Wspieraj go unikalnym ograniczeniem, żeby baza danych wymusiła regułę, nawet gdy dwóch workerów się ściga.

Atomowe checkpointy są równie ważne. Jeśli przesuniesz checkpoint przed zatwierdzeniem danych, awaria może sprawić, że rekordy zostaną pominięte na zawsze. Traktuj aktualizację checkpointu jako część tej samej jednostki pracy co zapisy.

Oto prosty wzorzec:

• Odczytaj zmiany od ostatniego checkpointu (cursor lub token).
• Upsertuj każdy rekord używając klucza deduplikacji.
• Zatwierdź transakcję.
• Dopiero potem zapisz nowy checkpoint.

Aktualizacje poza kolejnością i później przychodzące dane to kolejna pułapka. Rekord może być zmieniony o 10:01, ale przyjść później niż rekord z 10:02, albo API może dostarczyć starsze zmiany przy retry. Chroń się przez przechowywanie źródłowego last_modified i regułę „last write wins”: nadpisuj tylko gdy przychodzący rekord jest nowszy niż to, co już masz.

Jeśli potrzebujesz mocniejszej ochrony, trzymaj małe okno nakładki (np. ponowne odczytanie ostatnich kilku minut) i polegaj na idempotentnych upsertach, by zignorować powtórki. To dodaje trochę pracy, ale sprawia, że wznowienia są nudne — a o to chodzi.

W AppMaster ten sam pomysł mapuje się czysto na Business Process: najpierw logika upsertu, commit, a potem zapis cursora lub tokenu wznowienia jako ostatni krok.

Powszechne błędy, które psują przyrostową synchronizację

Większość błędów synchronizacji nie wynika z kodu. Pochodzą z kilku założeń, które wydają się bezpieczne, dopóki dane nie pokażą swojego prawdziwego oblicza. Jeśli chcesz, by przyrostowa synchronizacja z checkpointami pozostała niezawodna, wcześnie zwróć uwagę na te pułapki.

Typowe punkty awarii

Częsty błąd to zbyt duże zaufanie do updated_at. Niektóre systemy nadpisują timestampty podczas backfilli, poprawek stref czasowych, masowych edycji, a nawet read-repairów. Jeśli Twój cursor to tylko timestamp, możesz pominąć rekordy (timestamp skoczy wstecz) albo ponownie przetworzyć ogromny zakres (timestamp skoczy naprzód).

Inna pułapka to założenie, że ID są ciągłe lub ściśle rosnące. Importy, sharding, UUIDy i usunięte wiersze łamią to założenie. Jeśli używasz „ostatniego widzianego ID” jako checkpointu, luki i zapisy poza kolejnością mogą zostawić rekordy w tyle.

Najbardziej szkodliwy błąd to przesunięcie checkpointu przy częściowym sukcesie. Na przykład pobierasz 1000 rekordów, zapisujesz 700, potem crashujesz, ale mimo to zapisujesz „następny cursor” z fetchu. Przy wznowieniu pozostałe 300 nigdy nie zostanie ponownie przetworzone.

Usunięcia też łatwo zignorować. Źródło może soft-deleteować (flaga), hard-deleteować (usunięcie wiersza) lub „wycofać publikację” (zmiana statusu). Jeśli tylko upsertujesz aktywne rekordy, cel powoli się rozjedzie.

Wreszcie zmiany schematu mogą unieważnić stare hashe. Jeśli twoje hashe były zbudowane z zestawu pól, dodanie lub zmiana nazwy pola może sprawić, że „brak zmiany” wygląda jak „zmiana” (lub odwrotnie), chyba że wersjonujesz logikę hashującą.

Oto bezpieczniejsze domyślne ustawienia:

• Preferuj monotoniczny cursor (event ID, pozycja w logu) nad surowymi timestampami, gdy to możliwe.
• Traktuj zapisy checkpointu jako część tej samej granicy sukcesu co zapisy danych.
• Śledź usunięcia explicite (tombstones, przejścia statusów lub okresowe porównania).
• Wersjonuj wejścia do hashy i trzymaj stare wersje czytelne.
• Dodaj małe okno nakładki (ponowne odczytanie ostatnich N elementów), jeśli źródło może przestawiać kolejność.

Jeśli budujesz to w AppMaster, zamodeluj checkpoint jako własną tabelę w Data Designer i trzymaj krok „zapisz dane + zapisz checkpoint” razem w jednym uruchomieniu Business Process, by retry nie pomijały pracy.

Monitorowanie i wykrywanie dryfu bez nadmiernego hałasu

Dobre monitorowanie przyrostowej synchronizacji to mniej „więcej logów”, a bardziej kilka liczb, którym ufasz przy każdym uruchomieniu. Jeśli potrafisz odpowiedzieć na pytanie „co przetworzyliśmy, ile to zajęło i skąd wznowimy?”, większość problemów zdebugujesz w minutach.

Zacznij od zapisu jednego zwartego rekordu uruchomienia za każdym razem, gdy synchronizacja się wykona. Trzymaj go spójnym, żeby porównywać uruchomienia i wykrywać trendy.

• Start cursor (lub token wznowienia) i end cursor
• Liczba pobranych rekordów, zapisanych, pominiętych
• Czas wykonania i średni czas na rekord (lub na stronę)
• Liczba błędów z najczęstszą przyczyną
• Status zapisu checkpointu (sukces/porażka)

Wykrywanie dryfu to kolejna warstwa: mówi, kiedy systemy „pracują, ale powoli się rozjeżdżają”. Same sumy mogą mylić, więc połącz lekki check sum z małymi losowymi porównaniami. Na przykład raz dziennie porównaj liczbę aktywnych klientów w obu systemach, a potem losowo sprawdź 20 ID klientów i potwierdź kilka pól (status, updated_at, email). Jeśli sumy się różnią, ale próbki pasują, możesz tracić usunięcia lub filtry. Jeśli próbki się różnią, prawdopodobnie coś jest nie tak z detekcją zmian lub mapowaniem pól.

Alerty powinny być rzadkie i wymagające akcji. Prosta reguła: alarmuj tylko wtedy, gdy człowiek musi teraz zareagować.

• Cursor utknął (end cursor nie przesuwa się przez N uruchomień)
• Wskaźnik błędów rośnie (np. z 1% -> 5% w ciągu godziny)
• Uruchomienia zwalniają (czas powyżej normalnego progu)
• Backlog rośnie (nowe zmiany pojawiają się szybciej niż synchronizujesz)
• Dryf potwierdzony (niezgodność sum w dwóch kolejnych sprawdzeniach)

Po awarii wznowienie powinno być bez ręcznego sprzątania. Najprostsze podejście to wznowienie od ostatniego zatwierdzonego checkpointu, nie od ostatniego „widocznego” rekordu. Jeśli używasz małego okna nakładki (ponowne odczytanie ostatniej strony), rób zapisy idempotentne: upsert według stabilnego ID i przesuwaj checkpoint dopiero po pomyśślnym zapisie. W AppMaster zespoły często implementują te kontrole w Business Process i wysyłają alerty przez moduły email/SMS lub Telegram, żeby awarie były widoczne bez ciągłego patrzenia na dashboard.

Szybka lista kontrolna przed uruchomieniem synchronizacji

Zanim uruchomisz przyrostową synchronizację z checkpointami w produkcji, przejrzyj kilka detali, które zwykle powodują późne niespodzianki. Te kontrole zajmują minuty, ale zapobiegają dniom debugowania „dlaczego pominęliśmy rekordy?”.

Oto praktyczna lista przed wdrożeniem:

• Upewnij się, że pole używane do porządkowania (timestamp, sekwencja, ID) jest naprawdę stabilne i ma indeks po stronie źródła. Jeśli może się zmieniać po fakcie, cursor będzie dryfował.
• Potwierdź, że klucz upsertu jest gwarantowanie unikalny i że oba systemy traktują go tak samo (wielkość liter, trimowanie, formatowanie). Jeśli jeden system przechowuje "ABC", a drugi "abc", powstaną duplikaty.
• Przechowuj checkpointy oddzielnie dla każdego zadania i każdego zbioru danych. "Globalny ostatni cursor" brzmi prosto, ale psuje się jak tylko zaczniesz synchronizować dwie tabele, dwóch tenantów lub dwa filtry.
• Jeśli źródło jest eventualnie spójne, dodaj małe okno nakładki. Na przykład wznowienie od "last_updated = 10:00:00" zacznij od 09:59:30 i polegaj na idempotentnych upsertach, by zignorować powtórki.
• Zaplanuj lekką rekonsyliację: cyklicznie wylosuj niewielką próbkę (np. 100 rekordów) i porównaj kluczowe pola, by wychwycić cichy dryf.

Krótki test rzeczywistości: zatrzymaj synchronizację w połowie, wznow ją i sprawdź, czy wynik jest taki sam. Jeśli restart zmienia liczby lub tworzy dodatkowe wiersze, napraw to przed startem.

Jeśli budujesz synchronizację w AppMaster, trzymaj dane checkpointów powiązane z konkretnym procesem i zestawem danych, a nie współdzielone między niepowiązanymi automacjami.

Przykład: synchronizacja rekordów klientów między dwoma aplikacjami

Wyobraź sobie prostą konfigurację: Twój CRM jest źródłem prawdy dla kontaktów i chcesz, żeby te same osoby istniały w narzędziu wsparcia (żeby zgłoszenia mapowały się na prawdziwych klientów) lub w portalu klienta (żeby użytkownicy mogli się zalogować i zobaczyć swoje konto).

Przy pierwszym uruchomieniu wykonaj jednorazowy import. Pobieraj kontakty w stabilnym porządku, np. po updated_at z id jako tiebreaker. Po zapisaniu każdej paczki do miejsca docelowego, zapisz checkpoint taki jak: last_updated_at i last_id. Ten checkpoint jest linią startu dla przyszłych uruchomień.

W dalszych uruchomieniach pobieraj tylko rekordy nowsze niż checkpoint. Aktualizacje są proste: jeśli kontakt z CRM już istnieje, zaktualizuj rekord w docelowym miejscu; jeśli nie, utwórz go. Scalanie to trudniejsza część. CRM-y często scalają duplikaty i zachowują jeden „zwycięski” kontakt. Traktuj to jako aktualizację, która też „wycofuje” przegrywający kontakt przez oznaczenie go jako nieaktywnego (lub mapowanie na zwycięzcę), żeby nie skończyć z dwoma użytkownikami portalu dla tej samej osoby.

Usunięcia rzadko pojawiają się w zwykłych zapytaniach "updated since", więc zaplanuj ich obsługę. Częste opcje to flaga soft-delete w źródle, osobny feed "deleted contacts" albo okresowa, lekka rekonsyliacja sprawdzająca brakujące ID.

A teraz przypadek awarii: synchronizacja padła w połowie. Jeśli zapisujesz checkpoint tylko na końcu, przetworzysz ponownie dużą część. Zamiast tego użyj tokenu wznowienia dla każdej paczki.

• Rozpocznij uruchomienie i wygeneruj run_id (twój token wznowienia)
• Przetwórz paczkę, zapisz zmiany w docelowym systemie, a potem atomowo zapisz checkpoint powiązany z run_id
• Po restarcie wykryj ostatni zapisany checkpoint dla tego run_id i kontynuuj

Sukces wygląda nudno: liczby pozostają stabilne dzień do dnia, czasy działania są przewidywalne, a ponowne uruchomienie tego samego okna nie daje niespodzianek.

Kolejne kroki: wybierz wzorzec i buduj z mniejszą ilością poprawek

Gdy pierwsza przyrostowa pętla zadziała, najszybszy sposób, by uniknąć przeróbek, to spisanie reguł synchronizacji. Krótko: jakie rekordy są w zakresie, które pola wygrywają przy konflikcie i co znaczy „zrobione” po każdym uruchomieniu.

Zacznij od małego zakresu. Wybierz jeden zbiór danych (np. customers) i zrób pełny przebieg: import początkowy, aktualizacje przyrostowe, usunięcia i wznowienie po celowej awarii. Łatwiej poprawić założenia teraz niż po dodaniu pięciu kolejnych tabel.

Pełny rebuild czasem jest właściwy. Zrób go, gdy stan checkpointów jest uszkodzony, gdy zmieniasz identyfikatory albo gdy zmiana schematu łamie detekcję zmian (np. używałeś hasha, a znaczenie pól się zmieniło). Jeśli przebudowujesz, traktuj to jako kontrolowaną operację, a nie przycisk awaryjny.

Oto bezpieczny sposób na reimport bez przestojów:

• Importuj do tabeli-cienia lub równoległego zestawu danych, zostawiając obecny live.
• Zwaliduj liczby i sprawdź próbki, włączając przypadki brzegowe (null-e, scalone rekordy).
• Backfilluj relacje, potem w jednym zaplanowanym kroku przestaw czytniki na nowy zestaw danych.
• Przechowaj stary zestaw przez krótki czas jako możliwość rollback, potem posprzątaj.

Jeśli chcesz zbudować to bez pisania kodu, AppMaster może pomóc trzymając elementy w jednym miejscu: zamodeluj dane w PostgreSQL w Data Designer, zdefiniuj reguły synchronizacji w Business Process Editor i uruchom zaplanowane zadania, które pobierają, transformują i upsertują rekordy. Ponieważ AppMaster regeneruje czysty kod, gdy wymagania się zmieniają, doda to mniej ryzyka przy dodawaniu kolejnego pola.

Zanim rozszerzysz zakres na więcej datasetów, udokumentuj kontrakt synchronizacji, wybierz jeden wzorzec (cursor, token wznowienia lub hash) i doprowadź jedną synchronizację do pełnej niezawodności. Potem powtarzaj ten sam schemat dla kolejnego zbioru danych. Jeśli chcesz spróbować szybko, utwórz aplikację w AppMaster i uruchom małe, zaplanowane zadanie synchronizacji jako pierwszy krok.