Databricks AI Search dodaje źródła tabel na żywo, eliminując pośredni etap danych

Databricks AI Search obsługuje teraz trzy dodatkowe typy źródeł, eliminując pośrednią warstwę danych, którą klienci wcześniej utrzymywali samodzielnie. Ogłoszenie z 26 października obejmuje Streaming Tables, które przetwarzają napływające rekordy; Materialized Views, które przechowują obliczone wyniki zapytań; oraz zarządzane tabele Apache Iceberg. Iceberg to otwarty format tabel służący do organizowania danych analitycznych. Bezpośrednia zmiana dotyczy ścieżki między danymi biznesowymi a wyszukiwaniem, a nie nowego modelu.

Kluczowe napięcie dotyczy synchronizacji zarządzanej przez platformę w porównaniu z kopiami utrzymywanymi przez klienta. Databricks twierdzi, że klienci wcześniej potrzebowali dla tych źródeł oddzielnej reprezentacji Delta, czyli dodatkowej tabeli w stosowanym przez firmę formacie analitycznym. Usunięcie tej reprezentacji zmniejsza liczbę miejsc, w których dane wyszukiwania mogą odbiegać od swojego źródła. Nie oznacza to jednak, że każda aplikacja natychmiast otrzyma aktualne wyniki.

Snowflake oferuje użyteczny punkt odniesienia poprzez Cortex Search, swoją zarządzaną usługę wyszukiwania. Oba podejścia przybliżają wyszukiwanie do danych przedsiębiorstwa. Dla programistów i kupujących pytanie brzmi: który system zarządza procesem aktualizacji, jak przejrzyście ujawnia opóźnienia i co dzieje się w razie awarii.

Databricks AI Search eliminuje tabelę pośrednią

Obsługa natywnych źródeł rozszerza dane wejściowe dostępne w dotychczasowym procesie wyszukiwania. Databricks podaje, że klienci mogą łączyć te źródła bezpośrednio, zamiast konwertować je do oddzielnej tabeli Delta.

Istotną zmianą jest usunięcie granicy synchronizacji utrzymywanej przez klienta.

Ta granica ma znaczenie, ponieważ dodatkowa kopia tworzy kolejną odpowiedzialność operacyjną. Ktoś musi zdecydować, kiedy jest aktualizowana, jak następuje odzyskiwanie po awariach i czy jej zawartość nadal odzwierciedla zamierzone źródło. Gdy wyszukiwanie zwraca nieaktualny rekord, inżynierowie muszą ustalić, na którym etapie przepływ został zatrzymany.

Rozważmy przykładowego sprzedawcę detalicznego, którego aplikacja wyszukiwania rekomenduje dostępne produkty. Aplikacja potrzebuje opisów produktów, bieżącej dostępności i wystarczającego kontekstu, aby zwracać użyteczne dopasowania. Oddzielna tabela przygotowująca dane do wyszukiwania tworzy kolejne miejsce, w którym informacje o dostępności mogą się zdezaktualizować. Usunięcie tej tabeli upraszcza drogę, którą musi pokonać korekta.

Ogłoszenie nie oznacza, że wyszukiwanie przestaje używać indeksu, czyli struktury przygotowanej do wydajnego pobierania danych. Zmienia sposób, w jaki źródło łączy się z tym indeksem. Kupujący powinni odróżniać usunięcie pośredniej kopii danych biznesowych od wyeliminowania każdej pochodnej reprezentacji.

To rozróżnienie pozwala również zachować właściwą skalę ogłoszenia. Databricks rozszerza zasięg istniejącej usługi na obiekty danych, których klienci już używają. Firma nie ogłasza, że wyszukiwanie może odpowiadać na każde pytanie bezpośrednio względem dowolnych systemów operacyjnych.

W przypadku istniejącego wdrożenia praktyczna decyzja dotyczy obecnego elementu infrastruktury. Czy oddzielna tabela przygotowawcza istnieje tylko dlatego, że usługa wyszukiwania wcześniej jej wymagała? Czy może egzekwuje też użyteczne reguły biznesowe, granice prywatności i przygotowanie treści?

Jeżeli tabela służy wyłącznie jako most zgodności, natywna obsługa stanowi wyraźną okazję do uproszczenia. Jeśli wykonuje istotne transformacje, jej usunięcie wymaga zachowania tych transformacji w innym miejscu. Krótszy diagram architektury nie daje automatycznie lepszej aplikacji.

Właśnie dlatego aktualizacja zasługuje na uwagę wykraczającą poza listę obsługiwanych danych wejściowych. Zmienia założenie projektowe zespołów łączących utrzymywane zestawy danych przedsiębiorstwa z wyszukiwaniem. Najmocniejszy argument dotyczy zbędnego powielania danych, a nie automatycznej poprawy jakości odpowiedzi.

Ogłoszenie przedstawia kierunek produktu i przykładowe zastosowania. Nie zawiera niezależnych pomiarów potwierdzających, ile pracy inżynierskiej zaoszczędzą klienci. Każde ograniczenie nakładu pracy zależy od tego, co faktycznie robi ich obecny most integracyjny.

Zespoły wyszukiwania dziedziczą mniej kopii, lecz zachowują odpowiedzialność biznesową

Zespoły znajdujące się pod bezpośrednią presją to programiści i inżynierowie danych utrzymujący niestandardowe mosty między źródłowymi zestawami danych a wyszukiwaniem. Ich praca zmienia się, gdy platforma może przejąć podstawową funkcję synchronizacji tego mostu.

Transport zarządzany przez platformę ogranicza pracę nad infrastrukturą; zespoły aplikacyjne nadal odpowiadają za znaczenie danych dostępnych do wyszukiwania.

Semantyka przetwarzania tabel w Databricks rozróżnia przetwarzanie strumieniowe od przechowywanych wyników zapytań. Różnica ta ma znaczenie, ponieważ nowe zdarzenia i utrzymywany stan biznesowy odpowiadają na różne potrzeby aplikacji.

Zdarzenie rejestruje coś, co się wydarzyło. Utrzymywany wynik może reprezentować to, co firma obecnie uznaje za stan faktyczny po połączeniu istotnych informacji. Jakość wyszukiwania częściowo zależy od wybrania właściwej reprezentacji przed rozpoczęciem indeksowania.

Dla przykładowego asystenta wsparcia nowo otrzymana wiadomość klienta jest zdarzeniem. Bieżący status wsparcia klienta to stan pochodny. Wyszukiwanie wyłącznie najnowszej wiadomości nie musi ujawniać, czy problem został rozwiązany, eskalowany lub zastąpiony przez nowsze informacje.

W tym miejscu zmaterializowane widoki Databricks stają się istotne dla szerszego argumentu ogłoszenia. Zespoły mogą przygotować kontekst biznesowy możliwy do przeszukiwania wcześniej, zamiast zmuszać aplikację do odtwarzania go po pobraniu wyników. Korzyść zależy od tego, czy przygotowanie uchwyci właściwe zależności.

Istnieje też powód, by zachować pewien świadomy rozdział. Aplikacja wyszukiwania może potrzebować ograniczonego podzbioru szerszego zestawu danych. Może potrzebować starannie sformułowanego tekstu zamiast każdego dostępnego pola. Te wymagania pozostają aktualne mimo usunięcia kopii zgodności.

Zespoły produktowe muszą więc ponownie przeanalizować odpowiedzialność równolegle z architekturą. Kto zatwierdza reprezentację dostępną do wyszukiwania? Kto reaguje na zmianę nazwy pola? Kto decyduje, czy nieaktualny wynik powinien pozostać widoczny podczas awarii odświeżania?

Pytania te są szczególnie istotne, gdy prototyp staje się wspólną usługą produkcyjną. Programista może zrozumieć mały zestaw danych przez bezpośrednią inspekcję. Szersze wdrożenie wymaga jasno określonych odpowiedzialności, ponieważ zmiany źródeł mogą wpływać na aplikacje tworzone przez inne zespoły.

Ten sam problem odpowiedzialności pojawia się w bazie wiedzy z możliwością wyszukiwania. Zebranie dokumentów i umożliwienie ich wyszukiwania nie rozstrzyga, która wersja zasługuje na zaufanie. Infrastruktura wyszukiwania i utrzymanie wiedzy pozostają powiązanymi odpowiedzialnościami.

Dla kupujących implikacją handlową jest zmiana sposobu oceny. Dostawca demonstrujący mniejszą liczbę kroków integracyjnych powinien także wyjaśnić, jak zmienia się odpowiedzialność operacyjna. Ograniczenie utrzymania jest bardziej przekonujące, gdy klient potrafi wskazać konkretne zadanie, tabelę lub ścieżkę awarii, które znikają.

Wywiera to presję na niestandardowe prace integracyjne, których głównym celem było obejście ograniczenia produktu. Nie sprawia jednak, że każda dedykowana architektura wyszukiwania staje się zbędna. Specjalistyczne wymagania dotyczące wyszukiwania nadal wymagają oceny na własnych warunkach.

Natywna synchronizacja zmienia trasę, lecz nie każdy zegar odświeżania

Mechanizm stojący za aktualizacją jest znany obecnym użytkownikom. Indeks Delta Sync, czyli typ indeksu Databricks synchronizowany ze źródłem, akceptuje teraz dodatkowe obsługiwane źródła.

Opcje synchronizacji indeksu zawierają istotne zastrzeżenie. Standardowe endpointy obsługują aktualizacje ciągłe i wyzwalane. Endpointy zoptymalizowane pod kątem pamięci masowej obsługują synchronizację wyzwalaną, a każda synchronizacja częściowo przebudowuje indeks.

Obsługiwane źródło na żywo nie sprawia, że każda konfiguracja niższego poziomu jest stale aktualna.

Endpoint to zasób usługi obsługujący indeksy wyszukiwania. Wybór jego konfiguracji wpływa na to, jak aktualizacje docierają do aplikacji. Zgodność źródła i zachowanie aktualizacji są powiązanymi decyzjami, ale nie są zamienne.

Databricks opisuje ciągłą synchronizację jako utrzymującą zgodność indeksu z opóźnieniem liczonym w sekundach. Dokumentacja wiąże ten tryb również z dodatkowym zużyciem zasobów obliczeniowych. Jest to opis zależny od konfiguracji, a nie uniwersalna gwarancja czasu od zdarzenia do odpowiedzi.

Synchronizacja wyzwalana rozpoczyna się po otrzymaniu instrukcji za pośrednictwem obsługiwanego interfejsu. W przypadku wolno zmieniającego się zbioru referencyjnego takie podejście może odpowiadać potrzebom aplikacji. W przypadku doświadczenia wrażliwego na dostępność odstęp między wyzwoleniami staje się częścią zachowania produktu pod względem aktualności.

Koncepcyjnie należy uwzględnić kilka zegarów. Zdarzenie biznesowe musi dotrzeć do źródła. Każde przygotowanie musi się zakończyć. Indeks musi uwzględnić wynikającą z niego zmianę. Następnie aplikacja musi zażądać i wykorzystać zaktualizowany wynik.

Usunięcie pośredniej kopii skraca ten łańcuch odpowiedzialności. Nie określa jednak, jak długo trwa każdy pozostały etap przy konkretnym obciążeniu. Wymaga to obserwacji kompletnej ścieżki aplikacji.

Załóżmy, że przykładowe doświadczenie wyszukiwania rekomenduje nowo dostępne terminy wizyt. Istotnym pomiarem jest moment, w którym termin staje się możliwy do znalezienia po zmianie jego dostępności. Szybka odpowiedź wyszukiwania niewiele mówi o tym opóźnieniu, jeśli indeks nadal zawiera wcześniejsze informacje.

To samo rozróżnienie dotyczy tabel strumieniowych Databricks. Ich obecność w architekturze mówi odbiorcom coś o przetwarzaniu źródła. Nie określa jednak niezależnie zachowania każdej usługi wykorzystującej ich wyniki.

Dla kierowników inżynierii zmienia to, co powinna wykazać udana migracja. Zastąpienie powinno zachować wymagane wyniki przy jednoczesnym ograniczeniu utrzymania. Powinno także ułatwiać identyfikowanie opóźnionych aktualizacji, zamiast jedynie przenosić opóźnienie do zarządzanej usługi.

Przydatna ocena porównywałaby równoważne zmiany biznesowe przed i po migracji. Inżynierowie sprawdzaliby, kiedy zmiana staje się możliwa do wyszukania, czy zwracana treść jest poprawna oraz jak wyraźnie ujawniają się awarie. Są to proponowane kryteria oceny, a nie wyniki przedstawione w ogłoszeniu.

Wartość platformy rośnie, gdy jej zarządzana ścieżka zastępuje niestandardową pracę, nie zaciemniając zachowania systemu. To operacyjna obietnica stojąca za tym wydaniem: mniej połączeń między utrzymywanymi danymi a wyszukiwaniem należących do klienta.

Mechanizm jest wiarygodny jako uproszczenie architektoniczne. Korzyść na poziomie aplikacji nadal zależy od zachowania źródła, konfiguracji endpointu i obsługiwanego obciążenia.

Obsługa zarządzanego Iceberg poszerza dopasowanie, lecz nie każdą deklarację zgodności

Databricks określa zarządzane tabele Iceberg jako korzystające z wersji 3 lub nowszej. To sformułowanie definiuje zakres obsługi. Nie powinno przekształcać się w twierdzenie, że każda tabela Iceberg w dowolnym katalogu może natychmiast zasilać usługę.

Formaty open source poszerzają wybór architektoniczny, podczas gdy granice usług zarządzanych nadal kształtują implementację.

Architektura AI Search opisuje wyszukiwanie z użyciem embeddingów, czyli numerycznych reprezentacji treści wykorzystywanych do identyfikowania podobieństwa semantycznego. Rozróżnia również indeksy synchronizowane automatycznie od bezpośredniego dostępu do wektorów, w którym klienci samodzielnie zarządzają aktualizacjami.

To rozróżnienie wzmacnia główną tezę. Wydanie rozszerza ścieżkę zarządzaną przez platformę. Nie usuwa alternatyw zarządzanych przez klienta ani nie sprawia, że każda architektura wyszukiwania musi podlegać temu samemu cyklowi życia.

Obsługa Iceberg w Databricks ma największe znaczenie dla organizacji, które już mają powód, by zachować ten format. Wymaganie innego formatu wyłącznie po to, by połączyć dane z wyszukiwaniem, wprowadza dodatkowy obowiązek projektowy. Natywna akceptacja eliminuje ten konkretny powód do konwersji w udokumentowanym zakresie.

Zgodność formatów jest jednak tylko częścią przenośności. Zespół oceniający przyszłą elastyczność powinien również rozważyć, jak odtworzyłby transformacje, reguły dostępu, ustawienia indeksu i zachowanie aplikacji w innym środowisku. Te kwestie wykraczają poza bazowe pliki tabel.

To wniosek architektoniczny, a nie krytyka potwierdzona benchmarkiem klientów. Otwarty format może ograniczać zależność na poziomie przechowywania danych, podczas gdy aplikacja nadal zależy od zarządzanych usług znajdujących się wyżej w stosie.

Praktyczne pytanie jest więc bardziej precyzyjne niż to, czy system jest otwarty. Które zasoby można przenieść, które zachowania wymagają przebudowy i które obowiązki operacyjne zmienią się podczas takiego przeniesienia?

W przypadku przykładowego przedsiębiorstwa łączącego informacje o produktach z kilku analitycznych przepływów pracy zachowanie obsługiwanego formatu tabel może uprościć koordynację. Zespoły unikają wprowadzania kroku konwersji wyłącznie po to, by spełnić wymagania wyszukiwania. Nadal muszą uzgodnić identyfikatory i znaczenie współdzielonych pól.

Wydanie daje również Databricks bardziej jednoznaczną odpowiedź, gdy klienci pytają, czy wyszukiwanie musi dyktować reprezentację źródłową. W ramach obsługiwanego zestawu firma może teraz wskazać szerszy zakres istniejących danych wejściowych.

To wywiera presję na niepotrzebne przygotowania specyficzne dla formatu. Przygotowanie mające rzeczywisty cel aplikacyjny nadal pozostaje jednak użyteczne. Normalizowanie opisów, usuwanie pól wrażliwych czy ustanowienie kanonicznego rekordu produktu różni się od utrzymywania kopii wyłącznie dla zgodności.

To rozróżnienie powinno kierować oceną wdrożeń Databricks Iceberg. Nabywcy powinni dokładnie określić, który etap konwersji znika. Powinni unikać przypisywania temu usunięciu niezwiązanych z nim ulepszeń trafności, przenośności lub ładu danych.

Szersze znaczenie polega na lepszym dopasowaniu między architekturą danych przedsiębiorstwa a infrastrukturą wyszukiwania. Jest to wartościowe, bez traktowania obsługi formatów jako pełnej odpowiedzi na kwestię interoperacyjności.

Snowflake pokazuje, dlaczego zarządzane wyszukiwanie nadal wymaga wnikliwej oceny

Snowflake stanowi istotne porównanie, ponieważ Cortex Search również łączy wyszukiwanie z zarządzanym utrzymaniem blisko danych przedsiębiorstwa. Jego zarządzana usługa wyszukiwania obsługuje wyszukiwanie hybrydowe, łączące dopasowanie semantyczne z wyszukiwaniem po słowach kluczowych.

Snowflake dokumentuje docelowe opóźnienie, czyli skonfigurowany cel świeżości zawartości usługi względem aktualizacji źródłowych. Opisuje także zoptymalizowaną ścieżkę odświeżania z wykorzystaniem kluczy głównych, czyli identyfikatorów jednoznacznie rozróżniających wiersze źródłowe.

Pytanie konkurencyjne brzmi, która zarządzana ścieżka aktualizacji lepiej pasuje do obciążenia i modelu operacyjnego klienta.

Te udokumentowane możliwości wskazują na wspólny kierunek produktów. Obie firmy proszą klientów o powierzenie większej części utrzymania wyszukiwania platformie danych. Nie ustanawiają one równoważnej latencji, trafności, niezawodności ani całkowitego nakładu pracy operacyjnej.

Neutralne porównanie powinno zacząć się od tego, gdzie już znajdują się użyteczne dane klienta. Przeniesienie zbioru danych w celu uzyskania funkcji wyszukiwania może wprowadzić pracę przewyższającą korzyści z prostszego interfejsu indeksowania. Na decyzję wpływają również istniejące transformacje i własność organizacyjna.

Kolejne pytanie dotyczy widoczności. Gdy wyszukiwanie zwraca nieaktualne informacje, czy klient może ustalić, czy opóźnienie spowodowało pozyskanie danych, transformacja czy utrzymanie indeksu? Zarządzana usługa staje się trudniejsza do oceny, jeśli te etapy są traktowane jako nieprzejrzysta całość.

Tu znajduje się miejsce na najmocniejszy sceptyczny punkt widzenia. Mniejsza liczba niestandardowych potoków nie musi oznaczać świeższych odpowiedzi. Dokumentacja odświeżania widoków zmaterializowanych Databricks podaje, że odświeżanie może wykorzystywać przetwarzanie przyrostowe lub pełne przeliczenie, zależnie od obsługi i kosztów.

Przetwarzanie przyrostowe obsługuje istotne zmiany zamiast przeliczać pełny wynik. Pełne przeliczenie ponownie wykonuje zapytanie na wszystkich jego danych wejściowych. Indeks wyszukiwania znajdujący się dalej w potoku nadal zależy od tego, kiedy wynikowe dane staną się dostępne.

W przypadku aplikacji korzystających z widoków zmaterializowanych Databricks zależność ta zasługuje na wyraźną uwagę. Indeks może dokładnie odzwierciedlać najnowszy ukończony widok, podczas gdy sam widok pozostaje w tyle za bazowymi zdarzeniami biznesowymi. Sama świeżość indeksu nie uchwyciłaby tej sytuacji.

Ta obserwacja nie wskazuje na wadę nowej obsługi. Określa granicę obietnicy zawartej w ogłoszeniu. Integracja ze źródłem usuwa objazd wynikający ze zgodności, lecz nie eliminuje decyzji dotyczących przetwarzania wcześniejszych etapów.

Tę samą wnikliwość należy stosować wobec Snowflake. Skonfigurowany cel świeżości jest użyteczną kontrolą, ale klienci nadal muszą obserwować rzeczywiste zachowanie przy własnych zmianach i awariach. Terminologia dostawcy nie powinna zastępować dowodów na poziomie aplikacji.

Trafność wyszukiwania także wymaga odrębnej oceny. Nowo zaindeksowany rekord może nadal słabo odpowiadać pytaniu użytkownika. Prawidłowo dopasowany rekord może zawierać informacje, które nie powinny już kierować decyzją.

Nabywcy powinni więc unikać łączenia utrzymania, świeżości i użyteczności odpowiedzi w jedno twierdzenie. Każde z nich dotyczy innego trybu awarii. Wiarygodna ocena zapewnia każdemu własne dowody.

Wydanie wzmacnia historię integracyjną Databricks. Nie dostarcza jednak testów porównawczych potrzebnych do wskazania zwycięzcy nad Cortex Search lub dedykowanym systemem wyszukiwania.

Obserwuj dowody świeżości, wycofywane potoki i granice zgodności

W nadchodzących miesiącach najbardziej użyteczne sygnały połączą nową obsługę z obserwowalnym zachowaniem aplikacji. Dostępność produktu jest punktem wyjścia; dowody operacyjne określają, jak duże znaczenie ma ta zmiana.

Najmocniejsze dalsze potwierdzenie pokazałoby niezawodne wyszukiwanie przy mniejszej liczbie komponentów utrzymywanych przez klienta.

Po pierwsze, warto obserwować pomiary świeżości specyficzne dla obciążenia w nowo obsługiwanych źródłach. Użyteczne dowody śledziłyby zmianę biznesową od przetwarzania źródłowego aż do wyników wyszukiwania. Rozróżniałyby zwykłe aktualizacje od odzyskiwania po przerwaniu działania.

Takie pomiary wzmocniłyby argument, gdyby pokazały, że krótsza architektura zapewnia przewidywalne zachowanie. Osłabiłyby szerokie twierdzenia dotyczące świeżości, gdyby opóźnienia nadal były trudne do zlokalizowania lub istotnie się różniły bez wyjaśnienia.

Publikowane przykłady powinny również wskazywać istotne wybory konfiguracji. Wynik ciągłej synchronizacji nie powinien być przedstawiany jako reprezentatywny dla wdrożenia uruchamianego na żądanie. Obciążenie z prostymi aktualizacjami źródłowymi nie powinno zastępować każdego utrzymywanego widoku biznesowego.

Po drugie, warto obserwować relacje klientów wskazujące infrastrukturę, którą faktycznie wycofali. Przekonujący przykład wyjaśniałby, co robił wcześniejszy element pośredniczący, dlaczego natywna obsługa go zastąpiła i które obowiązki pozostały. Dzięki temu korzyść związana z utrzymaniem stałaby się konkretna.

Te dowody są ważne, ponieważ nowo dodana ścieżka nie gwarantuje wdrożenia. Niektóre istniejące warstwy przygotowania danych mogły zgromadzić logikę biznesową. Klienci mogą je zachować, dopóki ta logika nie zostanie zachowana i zweryfikowana w innym miejscu.

Historie wycofania wzmocniłyby centralny argument ogłoszenia, gdyby pokazały mniej ścieżek awarii bez utraty wymaganego zachowania. Relacje zachowujące tę samą infrastrukturę przygotowania wskazywałyby na węższą korzyść dla tych wdrożeń.

Po trzecie, warto obserwować udokumentowane granice zgodności i porównywalne aktualizacje innych platform. Istotne szczegóły obejmują obsługiwane konfiguracje źródeł i zachowanie odświeżania. W przypadku zarządzanego Iceberg precyzyjny zakres pozostaje bardziej użyteczny niż szerokie twierdzenie o niezależności od formatu.

Szersza obsługa wzmocniłaby zdolność Databricks do dopasowania się do istniejących architektur przedsiębiorstw. Utrzymujące się wyjątki pomogłyby nabywcom określić, gdzie nadal konieczna jest dodatkowa praca integracyjna. Ulepszenia konkurentów również zmieniłyby porównanie, nie unieważniając tego wydania.

Sygnały te dają czytelnikom ugruntowany sposób oceny ogłoszenia. Koncentrują się na tym, co staje się prostsze, co staje się obserwowalne oraz gdzie odpowiedzialność klienta nadal pozostaje. Unikają przewidywania wdrożenia wyłącznie na podstawie listy funkcji.

Dla zespołów oceniających Databricks AI Search punktem wyjścia powinno być pytanie biznesowe, którego odpowiedź zmienia się wraz ze zmianą danych źródłowych. Wybierz reprezentatywny zbiór danych i określ obecne kroki przygotowania. Zapisz, które kroki istnieją dla zgodności, a które chronią znaczenie aplikacji.

Następnie prześledź zwykłą aktualizację, korektę i odzyskiwanie w proponowanej architekturze. Porównaj odnalezione dowody ze stanem biznesowym oczekiwanym przez użytkowników. Zapytaj, czy zarządzana ścieżka usuwa pracę, jednocześnie zachowując zrozumiałość opóźnień. Użyteczna decyzja dotyczy tego, czy natywna obsługa źródeł poprawia model operacyjny Twojej aplikacji. Który komponent utrzymywany przez klienta możesz wycofać i jakie dowody pokażą później, że wyszukiwanie pozostaje godne zaufania?