Amazon SageMaker UpdateRecord eliminuje konieczność przepisywania całych rekordów przy częściowych zmianach cech

Amazon SageMaker UpdateRecord wprowadza zapisy na poziomie cech, znosząc od dawna istniejący wymóg odczytania i ponownego zapisania całego rekordu przy każdej częściowej zmianie. Jedno wywołanie API może teraz zaktualizować nawet 100 cech, zachowując każdą cechę pominiętą w żądaniu.

Zmiana ta dotyczy konkretnej słabości infrastruktury uczenia maszynowego działającej w czasie rzeczywistym. Rekordy cech często łączą wartości wytwarzane przez odrębne potoki, z których każdy działa według własnego harmonogramu. Procesor clickstream może aktualizować aktywność co kilka sekund, podczas gdy nocne zadanie odświeża segmenty klientów.

Dotąd takie potoki często opierały się na wzorcu odczyt-modyfikacja-zapis. Każdy producent pobierał bieżący rekord, zmieniał przypisane mu pola i ponownie przesyłał pełny rekord. Ten wzorzec zwiększał liczbę odczytów, przesyłał niezmienione dane i stwarzał możliwość wzajemnego nadpisywania zmian przez równoległych zapisujących.

AWS zastępuje ten model atomowym mechanizmem częściowej aktualizacji. Usługa scala wybrane wartości z istniejącym rekordem, egzekwując jednocześnie uprawnienia i opcjonalne porządkowanie według czasu zdarzenia. Sednem tej historii nie jest kolejny endpoint SageMaker. AWS przenosi logikę koordynacji z aplikacji klientów do zarządzanego magazynu cech.

Amazon SageMaker UpdateRecord zmienia ścieżkę zapisu

UpdateRecord przekształca częściową zmianę cech w jeden zarządzany zapis zamiast organizowanego przez klienta odczytu, scalania i pełnego ponownego zapisu.

AWS ogłosił zapisy na poziomie cech 8 września 2026 roku. Funkcja jest dostępna we wszystkich regionach AWS, w których działa SageMaker Feature Store.

Klient identyfikuje istniejący rekord i przesyła wyłącznie wartości cech wymagające zmiany. SageMaker Feature Store weryfikuje żądanie, atomowo scala te wartości i pozostawia każdą pominiętą cechę bez zmian.

To zachowanie ma znaczenie, ponieważ rekord cech może być rozbudowany. Profil klienta może obejmować historię konta, ostatnią aktywność, sygnały ryzyka, rekomendacje i metadane operacyjne. Aktualizacja jednego wyniku ryzyka nie powinna wymagać od aplikacji przesyłania i ponownego zapisywania wszystkich tych niepowiązanych wartości.

API akceptuje co najmniej jedną cechę i obsługuje do 100 cech w jednym wywołaniu. Po pomyślnej aktualizacji zwraca pustą odpowiedź HTTP 200, zgodnie z API UpdateRecord.

UpdateRecord nie jest operacją upsert. Docelowy rekord musi już istnieć w magazynie online, a brakujący lub logicznie usunięty rekord powoduje błąd ResourceNotFound. Aplikacje muszą nadal używać PutRecord podczas tworzenia rekordów.

Identyfikator rekordu również pozostaje niezmienny. Klienci mogą aktualizować zapisane cechy, w tym cechę czasu zdarzenia w określonych warunkach, lecz nie mogą zmieniać klucza głównego za pośrednictwem tego endpointu.

Nazwy cech muszą już istnieć w schemacie grupy cech. UpdateRecord zmienia wartości w tym schemacie; nie zapewnia alternatywnej ścieżki definiowania nowych cech.

Te granice utrzymują koncentrację API. Obsługuje ono częściowe zmiany istniejących rekordów online, podczas gdy tworzenie rekordów i zarządzanie schematem pozostają odrębnymi operacjami.

Wymagania dotyczące magazynowania zasługują na równie dużą uwagę. Standardowe magazyny online wymagają nowszego formatu Standard_V2, zanim będą mogły przyjmować częściowe aktualizacje. Grupy cech w pamięci obsługują UpdateRecord bez konieczności wdrażania innego formatu magazynowania w pamięci.

AWS opisuje Standard jako warstwę online opartą na DynamoDB, a In-Memory jako opcję opartą na ElastiCache i Redis OSS. Zaktualizowany przewodnik po magazynie online firmy wymienia Standard, Standard_V2 i InMemory jako odrębne opcje.

To rozróżnienie sprawia, że premiera jest czymś więcej niż udogodnieniem SDK. AWS musiał dodać reprezentację magazynowania zdolną do stosowania częściowych aktualizacji przy jednoczesnym zachowaniu pozostałej części rekordu.

Dla klientów Standard korzyść architektoniczna wiąże się zatem z decyzją dotyczącą formatu. Zespoły tworzące grupy cech mogą wybrać Standard_V2, natomiast istniejące wdrożenia Standard muszą ocenić udokumentowaną ścieżkę migracji i jej konsekwencje operacyjne.

Wzorzec odczyt-modyfikacja-zapis był prawdziwym przeciwnikiem

W tym wydaniu AWS konkuruje z wzorcem aplikacyjnym, a nie z innym dostawcą magazynu cech.

Rozważmy trzy potoki zapisujące dane do jednego rekordu klienta. Zadanie clickstream zarządza page_views, usługa transakcyjna zarządza purchase_total, a potok modelu zarządza risk_score.

W modelu odczyt-modyfikacja-zapis każdy potok zaczyna od pobrania całego rekordu. Zmienia przypisaną mu wartość, a następnie wysyła pełne zastąpienie rekordu z powrotem do magazynu.

Ta sekwencja wydaje się bezpieczna, gdy jest demonstrowana z jednym zapisującym. Staje się krucha, gdy kilka podmiotów zapisuje dane jednocześnie.

Załóżmy, że potok clickstream odczytuje wersję A. Potok scoringowy odczytuje tę samą wersję chwilę później. Potok clickstream zapisuje wersję B z nowszą liczbą aktywności.

Potok scoringowy może następnie przesłać zmodyfikowaną kopię wersji A. Jeśli aplikacja nie wykryje kolizji, pełny zapis rekordu może przywrócić starszą liczbę aktywności, aktualizując jednocześnie wynik ryzyka.

Programiści mogą rozwiązać ten problem za pomocą orkiestracji, blokad, logiki warunkowej, kolejek lub zasad własności. Każde rozwiązanie dodaje kod i stan operacyjny poza magazynem cech.

UpdateRecord zawęża powierzchnię zapisu. Potok scoringowy przesyła tylko risk_score, a potok clickstream — tylko swoje cechy aktywności. Żaden z nich nie musi odtwarzać wartości należących do drugiego.

AWS twierdzi, że scalanie zachodzi atomowo. Oznacza to, że pojedyncze częściowe żądanie nie powinno ujawnić częściowo zapisanego zestawu uwzględnionych w nim wartości.

Atomowość nie sprawia, że każdy projekt potoku staje się poprawny. Usuwa jednak najbardziej oczywiste źródło utraconych aktualizacji wynikających z zastępowania niepowiązanych pól.

Zmiana eliminuje także wstępne żądanie GetRecord, gdy aplikacja musi jedynie ustawić znane wartości. Mniejsza liczba odczytów oznacza mniej rund komunikacji sieciowej i niższe opłaty za pojemność odczytu w obciążeniach rozliczanych w warstwie Standard.

AWS nie opublikował niezależnego benchmarku pokazującego uniwersalne obniżenie opóźnień. Rzeczywiste oszczędności będą zależeć od szerokości rekordu, częstotliwości żądań, lokalizacji w sieci, zachowania przy ponownych próbach i projektu aplikacji.

Kierunek pozostaje jasny nawet bez takiego benchmarku. Jedno żądanie wykonuje mniej pracy po stronie aplikacji niż odczyt, po którym następuje pełny zapis.

Ruch sieciowy może również się zmniejszyć, gdy rekordy zawierają wiele cech, lecz każde zdarzenie zmienia tylko jedną lub dwie. Klient wysyła identyfikator rekordu i zmienione wartości zamiast serializować każde zapisane pole.

Rozliczanie zapisów wymaga większego niuansowania. AWS podaje, że pojemność zapisu w warstwie Standard nadal opiera się na rozmiarze elementu po aktualizacji, a nie wyłącznie na przesłanym ładunku cech. Najbardziej bezpośrednia oszczędność wynika z usunięcia poprzedzającego odczytu.

Model cenowy SageMaker osobno uwzględnia odczyty, zapisy i magazynowanie w feature store. Zespoły powinny modelować własne wzorce dostępu, zanim przypiszą konkretny procent oszczędności.

Wydanie przenosi więc odpowiedzialność na dwóch poziomach. SageMaker odpowiada teraz za atomowe scalanie cech, podczas gdy klienci nadal odpowiadają za pomiar obciążenia i planowanie pojemności.

Niezależne potoki zyskują czytelniejszy model własności

Zapisy na poziomie cech pozwalają producentom zarządzać wybranymi polami bez wymogu, by każdy z nich rozumiał kompletny rekord.

Systemy cech strumieniowych rzadko aktualizują każdą wartość z taką samą częstotliwością. Aktywność sesji może zmieniać się stale, sumy finansowe mogą podążać za transakcjami, a atrybuty demograficzne mogą być odświeżane znacznie rzadziej.

Pojedynczy kontrakt pełnego rekordu zmusza te potoki do niepotrzebnej koordynacji. Każdy producent musi albo znać najnowszy stan każdego pola, albo ufać innemu komponentowi, że scali jego zmiany.

UpdateRecord tworzy prostszą granicę. Producent może przesłać wartości, za które odpowiada, i pominąć wszystko inne. Magazyn cech zachowuje pominięte wartości.

Takie podejście pasuje do strumieniowego uzupełniania cech, w którym kilka źródeł zdarzeń stopniowo buduje aktualną reprezentację online. Zdarzenie kliknięcia może aktualizować statystyki sesji bez naruszania segmentu przypisanego przez potok wsadowy.

Backfill to kolejny praktyczny przypadek. Po dodaniu cechy zdefiniowanej w schemacie zespół może wypełnić tę wartość we wszystkich istniejących rekordach bez ponownego wysyłania każdej wcześniej zapisanej cechy.

Korekty danych podlegają tej samej logice. AWS opisuje scenariusz obejmujący 50 000 błędnie sklasyfikowanych rekordów klientów. Zadanie korygujące może zmienić customer_segment bez ryzyka dla niepowiązanych pól w tych rekordach.

Przykłady te ujawniają szerszy efekt architektoniczny. Częściowe aktualizacje zmniejszają ilość wspólnego kontekstu, którego każdy producent potrzebuje, zanim będzie mógł bezpiecznie zapisać dane.

Obsługują również węższe uprawnienia. AWS dodał klucze warunkowe IAM sagemaker:IsUpdateRecord i sagemaker:UpdatableFeatures do kontrolowania częściowych zapisów.

Administrator może zezwolić usłudze na wywoływanie UpdateRecord wyłącznie dla wybranych cech. Usługa scoringowa może aktualizować score i last_activity, pozostając jednocześnie bez możliwości zmiany salary lub innego wrażliwego pola.

UpdateRecord nadal używa akcji IAM sagemaker:PutRecord podczas oceny polityki. Zgodnie z AWS istniejące polityki odmawiające PutRecord blokują również częściowe aktualizacje.

To wstecznie zgodne zachowanie ogranicza ryzyko przypadkowego otwarcia nowej ścieżki zapisu. Administratorzy muszą wyraźnie przyznać odpowiedni dostęp, zanim obciążenie będzie mogło korzystać z tej operacji.

Autoryzacja na poziomie cech dodatkowo wzmacnia model własności producenta. Granica nie zależy już wyłącznie od dyscypliny aplikacji. IAM może odrzucić potok, który próbuje zmodyfikować pola innego producenta.

Własność cech wymaga jednak ciągłego zarządzania. Zespoły muszą utrzymywać polityki w miarę ewolucji schematów, zmiany odpowiedzialności usług lub pojawiania się w nowo dodanych cechach informacji wrażliwych.

Szeroka polityka z symbolem wieloznacznym może zniwelować znaczną część korzyści. Nowe klucze warunkowe zapewniają mechanizm kontroli, lecz AWS nie projektuje automatycznie zasad najmniejszych uprawnień dla każdego obciążenia.

Częściowe zapisy uzupełniają również niedawne prace AWS nad szerszymi operacjami ingestii. BatchWriteRecord obsługuje do 25 rekordów w grupach cech w jednym żądaniu, podczas gdy UpdateRecord zmienia wybrane wartości w jednym istniejącym rekordzie.

Te API rozwiązują różne wąskie gardła. Zapisy wsadowe zmniejszają narzut żądań między rekordami. Zapisy na poziomie cech ograniczają niepotrzebną pracę wewnątrz rekordu.

Żadna z operacji nie zastępuje drugiej. Duże zadanie korygujące może nadal wykonywać wiele wywołań UpdateRecord, ponieważ w tym wydaniu udokumentowano limit liczby cech, a nie wielorekordową partię częściowych aktualizacji.

To rozróżnienie ma znaczenie dla zespołów planujących backfill o dużej skali. Zyskują bezpieczniejsze zmiany na poziomie pól, lecz nadal potrzebują limitów współbieżności, obsługi ponownych prób, śledzenia postępu i odzyskiwania po błędach.

EventTime zapobiega nieaktualnym zapisom, pod pewnymi warunkami

UpdateRecord ogranicza przypadkowe nadpisania, ale bezpieczne porządkowanie nadal zależy od sposobu, w jaki producenci używają EventTime.

Każda grupa cech ma cechę czasu zdarzenia, która określa, kiedy wystąpił rekord lub zdarzenie. UpdateRecord może zawierać nowszą wartość tej cechy wraz z polami, które są zmieniane.

Gdy przesłany EventTime jest równy zapisanej wartości lub późniejszy od niej, SageMaker stosuje aktualizację. Jeśli jest wcześniejszy, usługa odrzuca całe żądanie, zwracając ConflictException i odpowiedź HTTP 409.

Ta kontrola zapobiega zastąpieniu przez opóźnione zdarzenie wartości powiązanych z nowszym czasem rekordu. Zapewnia potokom danych zarządzaną ochronę przed dostarczaniem zdarzeń w niewłaściwej kolejności.

Mechanizm jest szczególnie przydatny, gdy kilka komunikatów reprezentuje kolejne stany jednego logicznego strumienia zdarzeń. Spóźniona wiadomość nie może po cichu cofnąć rekordu do wcześniejszego czasu zdarzenia.

EventTime jest jednak metadanymi na poziomie rekordu. Oddzielni producenci mogą nie współdzielić jednego sensownego zegara, zwłaszcza gdy aktualizują niepowiązane cechy z różnych źródeł.

AWS uwzględnia ten przypadek, umożliwiając klientom pominięcie EventTime. Usługa stosuje wtedy zmiany cech, zachowując dotychczasowy czas zdarzenia rekordu.

Pomijanie tej wartości pozwala uniknąć sztucznej rywalizacji między niepowiązanymi potokami. Nocny proces segmentacji nie musi przesuwać zegara rekordu wyłącznie po to, aby zaktualizować jedno zarządzane przez siebie pole.

Ta elastyczność wiąże się z istotnym kompromisem. Aktualizacja bez EventTime nie może wykorzystać porównania czasowego rekordu, aby potwierdzić, że jej wartości są nowsze.

Każdy zespół musi zdecydować, czy producent uczestniczy we współdzielonym porządkowaniu rekordów, czy działa niezależnie. Decyzja ta zależy od znaczenia cechy, a nie tylko od wygody API.

Wynik ryzyka wyprowadzony ze strumienia transakcji opatrzonych datą może wymagać ścisłego porządkowania. Skorygowana preferencja językowa może natomiast wymagać oddzielnego znacznika czasu źródła przechowywanego jako kolejna cecha.

Ostrożności wymagają także ponowienia żądań przez aplikację. Odpowiedź 409 sygnalizuje nieaktualny EventTime, a nie tymczasową awarię usługi. Bezrefleksyjne ponowienie tego samego żądania nie sprawi, że jego znacznik czasu stanie się nowszy.

Klienci powinni klasyfikować konflikty oddzielnie od ograniczania przepustowości i błędów przejściowych. Mogą odrzucać nieaktualne aktualizacje, przeliczać je lub przekazywać do procedury obsługi wyjątków.

Obsługa czasu życia danych dodaje kolejny warunek. Jeśli żądanie zawiera TtlDuration, musi również zawierać EventTime. W przeciwnym razie SageMaker zwraca błąd walidacji.

Wygaśnięcie TTL jest obliczane na podstawie EventTime powiększonego o określony czas trwania. Wymaganie obu wartości zapobiega konstruowaniu przez usługę niejednoznacznego punktu wygaśnięcia.

Reguły te sprawiają, że UpdateRecord jest bezpieczniejszy niż nieograniczony endpoint typu patch. Nie eliminują jednak potrzeby udokumentowanego modelu czasowego dla wszystkich producentów.

Zespoły powinny określić, jaki zegar obowiązuje dla każdej cechy, czy aktualizacje mogą docierać z opóźnieniem oraz która usługa rozstrzyga konflikty. Bez tych decyzji API może odrzucać nieaktualne rekordy, ale nie potrafi określić prawdy biznesowej.

Standard_V2 stanowi główne pytanie dotyczące wdrożenia

Funkcja jest od razu dostępna dla grup In-Memory, natomiast klienci Standard muszą uwzględnić przejście formatu przechowywania.

AWS podaje, że zapisy na poziomie cechy działają w obu warstwach magazynu online, ale ścieżka aktywacji jest inna. Istniejące grupy cech In-Memory mogą korzystać z tej operacji bez wyboru innego formatu przechowywania.

Grupy cech Standard wymagają Standard_V2. Zaktualizowana dokumentacja wskazuje, że klienci mogą utworzyć grupę z tym typem przechowywania albo zmigrować istniejącą grupę Standard na miejscu.

Udokumentowana migracja wykorzystuje UpdateFeatureGroup do zmiany konfiguracji magazynu online. AWS podaje, że operacja zachowuje grupę cech i nie wymaga ponownego ingestowania jej danych.

Brzmi to prościej niż odbudowa produkcyjnego feature store, ale nie jest odwracalnym przełącznikiem. AWS ostrzega, że migracja ze Standard do Standard_V2 odbywa się tylko w jedną stronę.

Dokumentacja zaznacza również, że UpdateRecord może stać się dostępny dopiero kilka minut po zakończeniu migracji. Aplikacje potrzebują więc planu wdrożenia, który uwzględnia tę zmianę możliwości.

Zespoły produkcyjne powinny przetestować wersje SDK, szablony infrastruktury, polityki IAM, monitorowanie i zachowanie awaryjne. Migracji magazynu nie należy traktować wyłącznie jako edycji kodu źródłowego.

Środowiska mieszane mogą zwiększać złożoność. Nowe grupy cech mogą korzystać ze Standard_V2, podczas gdy starsze pozostają w Standard, przez co UpdateRecord będzie dostępny jedynie dla części środowiska.

Biblioteki klienckie nie powinny zakładać, że każda grupa cech SageMaker akceptuje częściowe aktualizacje. Dokumentacja API ogranicza tę operację do magazynu online Standard_V2 i InMemory.

Zespoły muszą również odróżniać zachowanie online od offline. UpdateRecord zawsze wymaga rekordu w magazynie online, nawet gdy grupa cech ma także magazyn offline.

W konfiguracjach z powiązanym magazynem offline AWS podaje, że częściowe zmiany trafiają do procesu replikacji jako kompletne migawki. Taka konstrukcja utrzymuje historyczne dane treningowe zgodne ze scalonym rekordem online.

Grupy cech In-Memory wymagają osobnego zastrzeżenia. Dokumentacja AWS wskazuje, że ta warstwa obecnie obsługuje wyłącznie grupy online i nie zapewnia odpowiadającej im replikacji do magazynu offline.

Dlatego premiery tej funkcji nie należy interpretować jako uniwersalnej synchronizacji online-to-offline dla każdego typu magazynu. Replikacja ma zastosowanie wtedy, gdy konfiguracja grupy cech obejmuje magazyn offline.

Kompletne migawki w historii offline wpływają także na interpretację danych przez systemy downstream. Wiele częściowych aktualizacji może tworzyć kolejne pełne wersje rekordu, mimo że każdy klient przesłał tylko wybrane cechy.

Odbiorcy danych treningowych muszą nadal uwzględniać czasy zdarzeń, wiersze historyczne i poprawność punktu w czasie. UpdateRecord zmienia ścieżkę ingestowania, a nie analityczne znaczenie historii offline.

Kolejną niewiadomą pozostaje brak publicznych, niezależnych benchmarków produkcyjnych. AWS opisuje niższe opóźnienia, ograniczony transfer danych i mniejszą liczbę odczytów, lecz nie przedstawiło wyników dla konkretnych obciążeń.

Opłaty za zapis w warstwie Standard zależą także od rozmiaru elementu po aktualizacji. Niewielkie żądanie dotyczące szerokiego rekordu nie oznacza automatycznie, że rozliczenie obejmie wyłącznie niewielkie żądanie.

To sprawia, że praktycznym kolejnym krokiem są pomiary. Przed migracją zespoły powinny porównać liczbę żądań, opóźnienia zapisu p95, wykorzystanie pojemności odczytu, wskaźniki konfliktów oraz wskaźniki błędów aplikacji.

Powinny też obserwować, czy częściowe aktualizacje upraszczają reagowanie na incydenty. Mniej komponentów koordynujących może zmniejszyć obciążenie operacyjne, ale nowe zasady IAM i obsługi konfliktów wprowadzają własne tryby awarii.

Na co deweloperzy powinni zwrócić uwagę dalej

Wartość Amazon SageMaker UpdateRecord zostanie określona przez dane dotyczące wdrożenia, niezawodność migracji i obsługę bardziej złożonych wzorców zapisu.

Pierwszym sygnałem będzie zachowanie migracji Standard_V2 w środowisku produkcyjnym. Zespoły powinny obserwować czas trwania migracji, błędy wdrożeń, planowanie wycofania oraz opóźnienie przed możliwością użycia UpdateRecord.

Stabilna ścieżka migracji wzmocni argument AWS, że obecni klienci Standard mogą wdrożyć częściowe zapisy bez odbudowy grup cech. Niespodzianki operacyjne spowolnią wdrażanie mimo bardziej przejrzystego API.

Drugim sygnałem będzie zmierzona poprawa obciążenia. Przydatne dowody obejmowałyby mniejszy wolumen GetRecord, niższe zużycie pojemności odczytu, krótsze opóźnienie aktualizacji end-to-end oraz mniej incydentów utraty aktualizacji.

Pomiary te powinny pochodzić z porównywalnych obciążeń. Test musi zachować szerokość rekordu, częstotliwość aktualizacji, lokalizację sieciową i współbieżność, zanim różnicę będzie można przypisać UpdateRecord.

Wskaźniki konfliktów zasługują na osobny dashboard. Częste odpowiedzi HTTP 409 mogą wskazywać na opóźnione zdarzenia, niespójne zegary lub producenta używającego EventTime tam, gdzie bardziej odpowiednie byłoby porządkowanie na poziomie pola.

Trzecim sygnałem będzie to, czy AWS rozszerzy model częściowych zapisów. UpdateRecord obsługuje jeden istniejący rekord i do 100 cech, podczas gdy BatchWriteRecord obsługuje pełne zapisy dla wielu rekordów.

Klienci przeprowadzający duże korekty mogą oczekiwać wsadowej operacji na poziomie cech. Jej brak nie osłabia obecnej funkcji, ale określa obszar, w którym orkiestracja po stronie klienta nadal jest konieczna.

Deweloperzy powinni również obserwować wsparcie dla SDK, infrastruktury jako kodu i obserwowalności. Możliwość usługi staje się łatwiejsza w eksploatacji, gdy narzędzia do provisioningu udostępniają ją konsekwentnie, a monitoring pokazuje odrębne klasy błędów.

Dla zespołów oceniających tę premierę teraz najbezpieczniejszy jest wąski test. Wybierz grupę cech z częstymi, odizolowanymi aktualizacjami i kilkoma niezależnymi producentami.

Udokumentuj własność pól przed zmianą kodu. Dodaj warunki IAM odpowiadające tym granicom, a następnie określ, czy każdy producent powinien przesyłać EventTime.

Utwórz lub zmigruj niekrytyczną grupę Standard_V2 albo użyj istniejącej grupy In-Memory. Zmierz starą ścieżkę odczyt-modyfikacja-zapis oraz nową ścieżkę częściowego zapisu przy równoważnym obciążeniu.

Śledź więcej niż średnie opóźnienie. Porównaj opóźnienia p95 i p99, żądania odczytu, błędy zapisu, konflikty nieaktualnych zdarzeń, rozmiar ładunku oraz wysiłek potrzebny do odzyskania sprawności operacyjnej.

Zachowaj kontrolowaną ścieżkę awaryjną podczas wdrożenia. UpdateRecord nie może utworzyć brakującego rekordu, dlatego aplikacje nadal potrzebują celowej ścieżki początkowego ingestowania przez PutRecord.

Zespoły inżynieryjne powinny również dbać o to, by decyzje architektoniczne, własność pól i polityki czasu zdarzeń były łatwe do wyszukania. Utrzymywana techniczna baza wiedzy może zapobiec naruszaniu tych kontraktów przez późniejsze usługi.

Amazon SageMaker UpdateRecord usuwa rzeczywiste źródło powielonej pracy z potoków funkcji online. Zastępuje koordynację całych rekordów częściowymi atomowymi zapisami i węższymi kontrolami autoryzacji.

Pozostające pytanie ma charakter operacyjny, a nie koncepcyjny. Czy migracje Standard_V2 pozostaną przewidywalne i czy metryki produkcyjne potwierdzą, że mniejsza liczba odczytów przynosi znaczące oszczędności?

Zespoły pracujące z szerokimi rekordami i częstymi odizolowanymi zmianami mają teraz konkretny eksperyment do przeprowadzenia. Porównaj obie ścieżki, przeanalizuj konflikty i zdecyduj, czy scalanie po stronie aplikacji nadal zasługuje na swoje miejsce.