Prototyp Databricks trafia do produkcji, ale wysokie QPS nadal wymaga planowania
Databricks zamknął lukę między prototypem a produkcją za pomocą jednego ustawienia, umożliwiając standardowym endpointom AI Search obsługę tysięcy zapytań na sekundę. Nowa funkcja wysokiego QPS stała się ogólnie dostępna 28 lipca 2026 r. Zmienia ona sposób, w jaki zespoły mogą wdrażać prototyp Databricks do produkcji bez przebudowy infrastruktury wyszukiwania wokół pierwotnego indeksu.
Ta obietnica wiąże się z ważnym zastrzeżeniem. Zespoły nadal wybierają cel, przygotowują się na skoki ruchu, testują jakość wyszukiwania i monitorują opóźnienia. Databricks udostępnia zasoby, ale nie eliminuje decyzji inżynieryjnych, które definiują niezawodne doświadczenie wyszukiwania.
Ten ruch stawia też Databricks w bardziej bezpośredniej rywalizacji z wyspecjalizowanymi platformami wyszukiwania i zarządzanymi przez dostawców chmury usługami wektorowymi. Google już promuje Vertex AI Vector Search dla dużych obciążeń o niskich opóźnieniach. Wyspecjalizowane bazy danych również konkurują pod względem przepustowości, filtrowania i prostoty operacyjnej.
Databricks stawia na to, że większe znaczenie ma ciągłość platformy. Te same zarządzane dane, indeks i ścieżka synchronizacji mogą pozostać na miejscu wraz ze wzrostem ruchu. Może to skrócić pracę wdrożeniową zespołów, które już tworzą rozwiązania w jego środowisku lakehouse.
Nie jest to po prostu zapowiedź szybszego wyszukiwania. To próba wykorzystania zarządzanej infrastruktury danych przedsiębiorstwa do obsługi aplikacji interaktywnych bez odrębnego stosu wyszukiwania. Prawdziwy test zaczyna się, gdy aplikacje te napotkają nieprzewidywalny ruch produkcyjny.
Prototyp Databricks ma teraz ustawienie produkcyjne
Databricks sprowadził złożone zadanie planowania przepustowości do zadeklarowanego celu QPS, zachowując istniejący indeks i model zarządzania.
QPS oznacza liczbę zapytań na sekundę, czyli liczbę żądań wyszukiwania przetwarzanych przez endpoint w ciągu jednej sekundy. Miara ta staje się kluczowa, gdy każde wyświetlenie strony, naciśnięcie klawisza lub panel rekomendacji generuje żądanie.
Databricks podaje, że standardowy endpoint AI Search może teraz skalować się do tysięcy QPS. Deweloper ustawia target_qps podczas tworzenia endpointu lub aktualizuje istniejący endpoint za pośrednictwem interfejsu, SDK albo REST API.
Usługa następnie oblicza i udostępnia wymaganą infrastrukturę. Według ogłoszenia dotyczącego wysokiego QPS firmy deweloperzy nie zarządzają liczbą replik, rozmiarami węzłów ani zewnętrznym mechanizmem równoważenia obciążenia.
To najważniejsza zmiana. Przed tym wydaniem udany prototyp Databricks mógł ujawnić nowy problem, gdy pojawiało się więcej użytkowników. Wyszukiwanie działało, lecz architektura obsługująca wymagała dodatkowego planowania przepustowości i rozdzielania ruchu.
Niektóre zespoły radziły sobie z tym przejściem, tworząc zduplikowane endpointy. Inne dodawały routowanie po stronie klienta lub budowały odrębną warstwę obsługującą. Te obejścia zwiększały nakład pracy operacyjnej i wprowadzały więcej miejsc, w których konfiguracja mogła się rozjechać.
Nowe ustawienie jest ukierunkowane na tę konkretną granicę. Pozwala istniejącemu standardowemu endpointowi otrzymać dodatkową przepustowość podczas następnego utworzenia lub synchronizacji jego indeksu. Zarządzanie Unity Catalog i Delta Sync pozostają częścią wdrożenia.
Unity Catalog to warstwa zarządzania Databricks dla zasobów danych i AI. Delta Sync utrzymuje indeks AI Search zgodny z jego tabelą źródłową. Zachowanie obu tych elementów ma znaczenie, ponieważ migracja często tworzy drugi problem związany z zarządzaniem obok problemu z wydajnością.
Endpoint udostępnia również postęp skalowania przez pole scaling_info. Zespół może obserwować zmianę stanu z SCALING_CHANGE_IN_PROGRESS na SCALING_CHANGE_APPLIED.
Databricks dodał widoczność na poziomie endpointu w zakresie liczby żądań, opóźnień i kondycji usługi. Sygnały te są dostępne w interfejsie AI Search i pomagają operatorom porównywać planowaną przepustowość z rzeczywistym zachowaniem.
Ogłoszenie obejmuje standardowe endpointy i jest ogólnie dostępne bez procesu opt-in. Zespoły mogą zastosować cel do nowego endpointu albo zaktualizować endpoint, który już obsługuje aplikację.
To sprawia, że historia prototypów Databricks jest wyjątkowo prosta. Sprzedawca detaliczny może rozwijać wyszukiwanie produktów na podstawie zarządzanych danych katalogowych, a następnie zwiększyć przepustowość obsługi bez kopiowania tego katalogu do innego systemu wyszukiwania.
Serwis streamingowy mógłby obrać tę samą drogę w przypadku rekomendacji treści. Aplikacja przedsiębiorstwa mogłaby wykorzystać ją do dopasowywania encji, gdzie każdy przychodzący rekord musi zostać porównany z istniejącym katalogiem.
Zmiana nie przekształca eksperymentu w notebooku w gotową aplikację konsumencką. Usuwa jednak jedno przejście infrastrukturalne, które często pojawia się między eksperymentem a taką aplikacją.
Databricks sprzedaje więc ciągłość, a nie tylko szybkość. Endpoint, który odpowiadał na zapytania testowe, może pozostać endpointem obsługującym ruch produkcyjny. Wartość rośnie, gdy zarządzanie, synchronizacja i obsługa w przeciwnym razie należałyby do różnych systemów.
Ta ciągłość podnosi również oczekiwania. Gdy skalowanie infrastruktury staje się ustawieniem konfiguracyjnym, zespoły aplikacyjne tracą łatwe wyjaśnienie dla powolnego lub zawodnego wyszukiwania. Projektowanie zapytań i testowanie obciążenia przesuwają się bliżej centrum uwagi.
Wysokie QPS umieszcza wyszukiwanie na ścieżce przychodów
Ta funkcja ma znaczenie, ponieważ ruch związany z interaktywnym wyszukiwaniem jest skokowy, widoczny dla użytkownika i często bezpośrednio powiązany z transakcją lub rekomendacją.
Tradycyjne zapytanie analityczne może czasem poczekać. Pole wyszukiwania produktów nie może. Użytkownicy zauważają opóźnione wyniki podpowiadania podczas wpisywania, niepełne rekomendacje i strony, które zatrzymują się, gdy wyszukiwanie się kończy.
Wyszukiwanie z podpowiadaniem podczas wpisywania tworzy nietypową presję, ponieważ jedno działanie użytkownika generuje kilka żądań. Każdy nowy znak może wywołać kolejne zapytanie, o ile aplikacja nie stosuje opóźniania lub grupowania danych wejściowych.
Systemy rekomendacji tworzą podobny wzorzec. Strona główna może podczas jednej wizyty zażądać kilku spersonalizowanych zestawów wyników. Ruch koncentruje się wokół premier, promocji, wydarzeń na żywo i regionalnych godzin oglądania.
Rozwiązywanie encji zapewnia inne doświadczenie użytkownika, ale stawia takie same wymagania operacyjne. System musi dopasowywać rekordy, konta, produkty lub tożsamości, podczas gdy inny proces biznesowy czeka na odpowiedź.
Aplikacje te umieszczają wyszukiwanie na ścieżce krytycznej, co oznacza, że późniejsza praca nie może być kontynuowana, dopóki wyszukiwanie nie odpowie. Przeciążony endpoint może zatem spowolnić cały proces skierowany do klienta.
Databricks wskazuje trzy sygnały ostrzegawcze: błędy HTTP 429, rosnące opóźnienie P95 oraz obejścia wykorzystujące zduplikowane endpointy. Opóźnienie P95 to czas odpowiedzi, który spełnia lub poprawia 95 procent żądań.
Wartość ogona ma znaczenie, ponieważ średnia może ukryć słabe doświadczenie. Większość zapytań może wracać szybko, podczas gdy istotna mniejszość staje się powolna wraz ze wzrostem ruchu.
Zespół może również napotkać problemy, gdy średnie wykorzystanie wygląda na umiarkowane. Krótkie skoki mogą wyczerpać dostępną przepustowość, zanim średnia godzinowa lub dzienna ujawni problem.
W tym miejscu pomaga zadeklarowany cel. Zespoły mogą dobrać zasoby do oczekiwanej liczby żądań i dodać zapas na znane szczyty. Obserwowalność następnie pokazuje, czy założenie odpowiada rzeczywistości.
Jednak cel jest użyteczny tylko na tyle, na ile użyteczny jest model ruchu stojący za nim. Średnia tygodniowa nie opisuje skoku w dniu premiery. Test z jednym użytkownikiem nie odtwarza tysięcy jednoczesnych sesji.
Pola wyszukiwania pokazują również, dlaczego wyszukiwanie wektorowe konkuruje dziś z ugruntowanym wyszukiwaniem słów kluczowych. Wyszukiwanie oparte na embeddingach reprezentuje elementy jako wektory numeryczne, co pozwala systemowi znajdować treści powiązane semantycznie.
Takie podejście może znajdować trafne produkty lub dokumenty nawet wtedy, gdy użytkownicy stosują inne sformułowania. Jednak dokładne nazwy, kody produktów i rzadko używane terminy często nadal sprzyjają dopasowaniu słów kluczowych.
Wyszukiwanie hybrydowe łączy wyszukiwanie semantyczne i słów kluczowych. Databricks zaleca je jako przydatny ogólny punkt wyjścia, ale jego wskazówki dotyczące wydajności mówią, że żądania hybrydowe zwykle zużywają około dwukrotnie więcej zasobów niż zapytania approximate nearest-neighbor.
Wyszukiwanie approximate nearest-neighbor, czyli ANN, znajduje bliskie wektory bez wyczerpującego porównywania każdego elementu. Poprawia efektywność obsługi, akceptując kontrolowane przybliżenie.
Wybór wpływa zarówno na trafność, jak i przepustowość. Obciążenie dobrane pod proste żądania ANN może zachowywać się inaczej po włączeniu przez zespół wyszukiwania hybrydowego, filtrowania lub rerankingu.
Reranking stosuje kolejny model po wyszukiwaniu, aby zmienić kolejność kandydatów. Może poprawić precyzję, ale Databricks podaje, że jego reranker cross-encoder może dodać opóźnienie, zwykle poniżej jednej dodatkowej sekundy na zapytanie.
Takie opóźnienie może być akceptowalne w wewnętrznym narzędziu badawczym. Może jednak wydawać się znacznie dłuższe w polu wyszukiwania produktów, które aktualizuje się po każdym naciśnięciu klawisza.
Pytanie produkcyjne nie brzmi więc tylko: „Czy endpoint może przetworzyć tysiące żądań?”. Brzmi: „Czy może przetworzyć dokładnie tę mieszankę zapytań w wymaganym czasie odpowiedzi?”.
To rozróżnienie jednocześnie wywiera presję na właścicieli aplikacji, inżynierów platformowych i zespoły danych. Właściciele aplikacji definiują doświadczenie. Zespoły platformowe zarządzają przepustowością, a zespoły danych chronią świeżość i jakość wyszukiwania.
W przypadku zespołów pracujących z dokumentami wewnętrznymi zachowanie wyszukiwania zależy także od tego, jak konsekwentnie informacje są gromadzone i organizowane. Przeszukiwalna baza wiedzy może poprawić dostęp, lecz szybkość obsługi nie naprawi brakującego kontekstu.
Wysokie QPS zwiększa liczbę użytkowników, którzy mogą dotrzeć do indeksu. Nie gwarantuje, że indeks zawiera właściwy materiał ani że zwraca właściwy wynik.
Prototyp Databricks kwestionuje odrębny stos wyszukiwania
Databricks kwestionuje założenie, że wyszukiwanie produkcyjne musi opuścić platformę danych i przenieść się do dedykowanej infrastruktury obsługującej.
Powszechna architektura oddziela przygotowanie danych od wyszukiwania w aplikacji. Zespoły przekształcają dane i zarządzają nimi na jednej platformie, a następnie eksportują rekordy lub embeddingi do innego systemu stworzonego do wyszukiwania online.
Taki podział ma zalety. Dedykowane produkty wyszukiwania mogą oferować wyspecjalizowane mechanizmy kontroli indeksowania, znane narzędzia trafności lub sprawdzoną wydajność dla konkretnego obciążenia.
Tworzy jednak również pracę związaną z synchronizacją i zarządzaniem. Zespoły muszą zdecydować, jak szybko aktualizacje są przenoszone, które uprawnienia są przekazywane oraz jak uzgadniać awarie między systemami.
Databricks chce, aby klienci uniknęli tego przekazania. AI Search utrzymuje dane źródłowe, proces synchronizacji, mechanizmy zarządzania i endpoint zapytań w ramach tej samej szerszej platformy.
Skalowanie wysokiego QPS czyni to twierdzenie bardziej wiarygodnym w przypadku aplikacji interaktywnych. Bez wystarczającej przepustowości jedność platformy pozostaje atrakcyjna tylko do chwili pojawienia się rzeczywistych użytkowników.
Głównym przeciwnikiem nie jest więc jedna wskazana baza danych. Jest nim odrębny stos obsługujący, obejmujący replikację, routowanie i warstwy operacyjne zbudowane wokół niego.
Google stanowi użyteczne porównanie, ponieważ Vertex AI Vector Search również traktuje przepustowość jako zagadnienie zarządzanej usługi. Google dokumentuje automatyczne skalowanie, wiele replik oraz mechanizmy dostrajania trafności i opóźnień.
Google przedstawił benchmarki wyszukiwania wektorowego, osiągające tysiące QPS w publicznych zbiorach danych. Liczby te wykorzystują konkretne zbiory danych, wymiary, repliki i cele trafności, więc nie stanowią bezpośredniego porównania z Databricks.
To zastrzeżenie jest kluczowe. Wartości przepustowości podawane przez dostawców opisują testowane konfiguracje, a nie uniwersalną wydajność. Rozmiar indeksu, wymiary wektorów, filtry, liczba wyników, typy zapytań i współbieżność mogą zmienić rezultat.
Databricks publikuje zakresy referencyjne zamiast jednego głównego wyniku benchmarku. Jego przewodnik wydajności podaje standardowe opóźnienie endpointów na poziomie około 20–50 milisekund oraz bazową przepustowość od 30 do ponad 200 QPS.
Wartości te opisują zwykłe konfiguracje, a nie nowo udostępnioną pojemność high-QPS. Firma twierdzi, że nowe ustawienie może zwiększyć wydajność standardowych endpointów do tysięcy QPS przez dodanie infrastruktury za wskazanym celem.
Rozmiar indeksu nadal ma znaczenie. Databricks podaje, że standardowa jednostka wyszukiwania wektorowego mieści około dwóch milionów wektorów, podczas gdy standardowy endpoint obsługuje do 320 milionów.
Gdy indeks obejmuje dodatkowe jednostki, bazowa liczba QPS może spadać, a ostatecznie ustabilizować się na poziomie bliskim 30 QPS dla zapytań ANN. Pojemność high-QPS odpowiada na zapotrzebowanie po stronie obsługi zapytań, ale zespoły nadal muszą rozumieć strukturę indeksu.
Endpointy zoptymalizowane pod kątem przechowywania mają inny profil. Databricks dokumentuje pojemność do miliarda wektorów, przy wyższym opóźnieniu i niższej bazowej przepustowości niż w przypadku standardowych endpointów.
Endpointy te stały się ogólnie dostępne w maju 2026 roku. Databricks poinformował, że mogą indeksować dane od 10 do 20 razy szybciej niż standardowe endpointy i obsługiwać znacznie większe zbiory.
Jednak lipcowa premiera high-QPS nie obejmuje jeszcze endpointów zoptymalizowanych pod kątem przechowywania. Databricks twierdzi, że wsparcie jest planowane na później w 2026 roku.
To ograniczenie wyznacza obecną granicę konkurencyjną. Zespoły wybierające między niskoopóźnieniową obsługą standardową a bardzo dużymi indeksami zoptymalizowanymi pod kątem przechowywania nie mogą zakładać, że nowy model skalowania działa identycznie w obu przypadkach.
Usługa Google oferuje inny zestaw mechanizmów sterowania. Programiści mogą dostosowywać repliki, typy maszyn, udział wyszukiwania i liczbę sąsiadów. Ta elastyczność może pomóc doświadczonym zespołom precyzyjnie dostroić wydajność.
Databricks wybiera dla tej funkcji bardziej deklaratywne podejście. Programista określa pożądaną liczbę żądań, a platforma wylicza potrzebną pojemność.
To znany kompromis w infrastrukturze zarządzanej. Większa abstrakcja ogranicza rutynową pracę, ale może też ukrywać mechanizmy potrzebne do nietypowej optymalizacji lub analizy kosztów.
Databricks udostępnia stan zastosowanego skalowania oraz metryki endpointu. Mimo to API usługi opisuje target_qps jako cel realizowany w miarę możliwości, a nie bezwzględną gwarancję.
Ma to znaczenie podczas wyboru platformy. Cel upraszcza provisioning, lecz założenie dotyczące poziomu usług w środowisku produkcyjnym nadal należy do zespołu aplikacyjnego.
Najmocniejszy argument za pozostaniem w ekosystemie Databricks pojawia się wtedy, gdy zarządzanie danymi i ich aktualność są równie ważne jak sama szybkość wyszukiwania. Uniknięcie kolejnej kopii danych może ograniczyć złożoność operacyjną i bezpieczeństwa.
Najmocniejszym argumentem za odrębnym stosem pozostaje specjalizacja pod kątem obciążenia. Zespół może potrzebować funkcji wyszukiwania, języka zapytań, topologii regionalnej lub kontroli strojenia, których jego platforma danych nie zapewnia.
High QPS zawęża ten wybór. Nie eliminuje go.
Parametr konfiguracji nie zastąpi testów obciążeniowych
Databricks automatyzuje provisioning pojemności, ale niezawodność produkcyjna nadal zależy od reprezentatywnych testów i zdyscyplinowanego projektowania zapytań.
Sama firma zaleca klientom testowanie endpointów pod obciążeniem. Przydatny test symuluje rzeczywisty wolumen ruchu, współbieżność, filtry, typy zapytań i rozmiary wyników.
Testowanie wyłącznie czystego zapytania ANN może stworzyć fałszywe poczucie pewności. Aplikacje produkcyjne często dodają filtry metadanych, wyszukiwanie hybrydowe i reranking po sukcesie pierwszego prototypu.
Każdy wybór zużywa inne zasoby. Databricks podaje, że wyszukiwanie hybrydowe może wykorzystywać około dwa razy więcej zasobów niż ANN, a zwracanie większej liczby wyników również zwiększa pracę skanowania.
Jego wytyczne wskazują, że dziesięciokrotne zwiększenie żądanej liczby wyników może podwoić opóźnienie i trzykrotnie obniżyć pojemność QPS. Dokładny efekt zależy od indeksu i konfiguracji.
Wymiary wektorów dodają kolejną zmienną. Wymiar embeddingu to liczba cech numerycznych używanych do reprezentowania elementu.
Większe embeddingi mogą zachowywać więcej informacji, ale wymagają większych obliczeń. Databricks podaje, że zmniejszenie liczby wymiarów z 768 do 384 zazwyczaj poprawia QPS około 1,5 raza i obniża opóźnienie o około 20 procent.
Nie jest to powód, by zmniejszać każdy embedding. Jakość wyszukiwania może spaść, jeśli reprezentacja utraci informacje istotne dla aplikacji.
Zespoły muszą mierzyć trafność równolegle z szybkością. Szybki endpoint zwracający słabych kandydatów nie jest gotowy do produkcji, nawet jeśli jego wykres przepustowości wygląda zdrowo.
Uwierzytelnianie również może stać się wąskim gardłem. Databricks zaleca dla aplikacji produkcyjnych service principals z OAuth zamiast personal access tokens.
Service principal to tożsamość niebędąca człowiekiem, używana przez oprogramowanie. Obsługuje zarządzane uprawnienia bez wiązania dostępu aplikacji z poświadczeniami pojedynczego pracownika.
Databricks podaje, że ruch service principal korzysta ze ścieżek sieciowych zoptymalizowanych pod kątem wydajności. Jego dokumentacja zapytań informuje, że takie podejście może zaoszczędzić do 100 milisekund na żądanie w porównaniu z innym routingiem.
Firma podaje również, że ruch z użyciem personal access token jest ograniczony do kilkudziesięciu QPS. Prototyp korzystający z tej ścieżki uwierzytelniania może więc zawieść, zanim endpoint osiągnie planowaną pojemność.
Zespoły powinny testować w rzeczywistym środowisku aplikacji. Notebook w tym samym workspace nie odtwarza publicznych ścieżek sieciowych, generowania tokenów, ponowień po stronie aplikacji ani odległości regionalnej.
Szczególnej uwagi wymaga zachowanie mechanizmu ponawiania. Gdy aplikacja otrzymuje odpowiedź 429, natychmiastowe ponowienia mogą wzmocnić pierwotny skok ruchu.
Backoff i jitter rozkładają ponowienia w czasie. Bez nich tymczasowy problem z pojemnością może przerodzić się w samonapędzającą się burzę żądań.
Sam cel potrzebuje zapasu. Ustawienie go na poziomie średniego ruchu daje niewielką ochronę przed skokami, zsynchronizowanymi klientami lub wydarzeniami specjalnymi.
Ustawienie go znacznie powyżej oczekiwanego zapotrzebowania rodzi inną obawę. Databricks zauważa, że dodatkowa pojemność generuje dodatkowy koszt po skonfigurowaniu celu.
Ogłoszenie nie przedstawia uniwersalnego porównania kosztów. Potrzeby dotyczące pojemności różnią się zależnie od indeksu, obciążenia zapytaniami i celu wydajnościowego, dlatego kupujący potrzebują własnych pomiarów.
Automatyczne skalowanie nie jest częścią obecnej wersji. Zespoły deklarują pojemność przed nadejściem ruchu, zamiast pozwalać systemowi stale reagować bez ręcznego dobierania rozmiaru.
Tworzy to operacyjne rozróżnienie między skalą planowaną a skalą elastyczną. Zaplanowany cel może obsłużyć znane uruchomienie, lecz nieoczekiwany wzrost może przekroczyć pierwotne oszacowanie.
Databricks podaje, że automatyczna reakcja na skoki ruchu jest planowana na później w 2026 roku. Do tego czasu obserwowalność i aktualizowanie celu pozostają częścią obsługi usługi.
API również określa cel jako realizowany w miarę możliwości. To sformułowanie oznacza, że programiści nie powinni interpretować target_qps jako kontraktowej gwarancji dla każdej kombinacji zapytań.
Duże indeksy wprowadzają kolejne ryzyko. Endpointy Databricks zoptymalizowane pod kątem przechowywania oferują większą pojemność, ale obecnie targetowanie high-QPS dotyczy wyłącznie standardowych endpointów.
Zespół zbliżający się do limitów standardowego endpointu może stanąć przed wyborem architektonicznym. Może podzielić dane na partycje, replikować indeksy lub poczekać na wsparcie high-QPS dla opcji zoptymalizowanej pod kątem przechowywania.
Databricks zaleca równoległe endpointy, gdy jeden endpoint nie jest w stanie zapewnić skrajnie wysokiej przepustowości. Zespoły mogą rozdzielić oddzielne indeksy między endpointy albo zreplikować popularny indeks i rozdzielać ruch.
Te zalecenia brzmią bardzo podobnie do pracy infrastrukturalnej, którą ta wersja ma ograniczyć. Pokazują, że model konfiguracji ma praktyczną granicę.
Funkcja eliminuje rutynowe dobieranie liczby replik dla obsługiwanych obciążeń. Nie znosi ograniczeń systemów rozproszonych.
Wiarygodny plan wdrożenia powinien przetestować trzy warunki: normalny ruch, oczekiwany szczyt oraz wzrost ponowień wywołany awarią. Powinien rejestrować zarówno opóźnienie, jak i trafność w każdym z tych warunków.
Zespoły powinny również ocenić synchronizację indeksu pod obciążeniem. Świeże dane są częścią jakości wyszukiwania, a endpoint, który szybko obsługuje nieaktualne informacje, nadal może szkodzić użytkownikom.
Prototyp Databricks staje się gotowy do produkcji dopiero po pomyślnym przejściu tych testów. Nowe ustawienie skraca drogę, ale dowody muszą pochodzić z rzeczywistego obciążenia.
Trzy sygnały pokażą, czy High QPS zmieni wyszukiwanie produkcyjne
Kolejny etap zależy od elastycznego skalowania, wsparcia dla endpointów zoptymalizowanych pod kątem przechowywania oraz niezależnych dowodów z obciążeń klientów.
Pierwszym sygnałem jest automatyczne skalowanie przy skokach ruchu. Databricks podaje, że ta funkcja jest planowana na później w 2026 roku, bez konieczności ręcznego planowania lub dobierania pojemności.
Jeśli zostanie wdrożona i utrzyma stabilne opóźnienie ogonowe, argument firmy dotyczący produkcji stanie się mocniejszy. Zespoły nie będą już musiały szacować każdego szczytu przed skonfigurowaniem pojemności.
Jeśli automatyczne skalowanie będzie reagować zbyt wolno, klienci nadal mogą provisionować znaczny zapas. Osłabiłoby to twierdzenie, że platforma usunęła większość operacji związanych z obsługą zapytań.
Termin ma także znaczenie dla środowisk regulowanych. Databricks podaje, że high QPS powinno stać się domyślnie dostępne dla workspace'ów korzystających z jego compliance security profile pod koniec sierpnia 2026 roku.
To rozszerzenie pokaże, czy funkcja może wyjść poza zwykłe wdrożenia bez tworzenia odrębnej ścieżki operacyjnej. Kupujący z przedsiębiorstw często potrzebują współistnienia wydajności i kontroli zgodności.
Drugim sygnałem jest wsparcie dla endpointów zoptymalizowanych pod kątem przechowywania. Endpointy te obsługują znacznie większe indeksy, ale obecnie mają wyższe opóźnienie i nie oferują nowej konfiguracji high-QPS.
Dodanie tej funkcji połączyłoby dwa elementy historii produktu: pojemność w skali miliarda i wysoką przepustowość żądań. Do tego czasu klienci muszą ostrożnie wybierać profil endpointu.
Sukces oznaczałby, że duże katalogi mogą przyjąć ten sam deklaratywny model obsługi. Opóźnienia lub ścisłe ograniczenia pozostawiłyby przestrzeń dla wyspecjalizowanych baz danych wektorowych i usług chmurowych.
Trzecim sygnałem są dowody od klientów. Databricks ogłosił mechanizm pojemności, ale nie opublikował jeszcze wystarczającej liczby niezależnych wyników produkcyjnych, aby określić wydajność dla zróżnicowanych obciążeń.
Przydatne dowody powinny obejmować rozmiar indeksu, wymiary wektorów, miks zapytań, filtry, żądaną liczbę wyników, współbieżność, opóźnienie P95 i osiągnięte QPS. Główna liczba bez tych szczegółów daje niewiele wskazówek.
Raporty klientów powinny również opisywać pracę operacyjną. Najważniejsze pytanie brzmi, czy zespoły usunęły infrastrukturę, a nie po prostu, czy Databricks dodał pojemność.
Sprzedawca detaliczny, który wycofał zduplikowane indeksy i routing po stronie klienta, potwierdzałby tezę o ciągłości platformy. Zespół, który zachował te warstwy dla bezpieczeństwa, stanowiłby jej zastrzeżenie.
Programiści powinni także obserwować zachowanie usługi podczas synchronizacji. Nowa pojemność zaczyna obowiązywać po utworzeniu lub zsynchronizowaniu indeksu, co może wpływać na harmonogram pilnych zmian skalowania.
Takie zachowanie może być rozsądne w przypadku planowanych wydarzeń. Jest mniej odpowiednie dla nagłego, nieprzewidzianego popytu, chyba że endpoint ma już wystarczający zapas.
Odpowiedź konkurencji będzie wymowna. Zarządzane usługi wektorowe już oferują automatyczne skalowanie lub kontrolę replik, a wyspecjalizowane systemy nadal udoskonalają wyszukiwanie hybrydowe i filtrowanie.
Databricks nie musi wygrywać każdego benchmarku. Musi sprawić, aby odrębna platforma obsługi zapytań była niepotrzebna dla wystarczającej liczby klientów już korzystających z zarządzanych danych lakehouse.
Ta propozycja wartości wykracza poza wyszukiwanie produktów. Korporacyjni asystenci AI również zależą od szybkiego wyszukiwania w dokumentach, rekordach i uprawnieniach.
Gdy zespoły projektują takie systemy, potrzebują zarówno pojemności obsługi zapytań, jak i niezawodnej warstwy informacyjnej. Osobisty system wiedzy obsługuje indywidualny kontekst, podczas gdy wyszukiwanie korporacyjne dodaje wymagania dotyczące zarządzania i wspólnej skali.
Lipiec przynosi wyraźniejszą ścieżkę produkcyjną dla tego drugiego zastosowania. Daje zespołom inżynieryjnym prostą kontrolę nad problemem, który wcześniej wymagał dodatkowej infrastruktury.
Mimo to zapowiedź należy odczytywać jako zmianę modelu operacyjnego, a nie uniwersalną gwarancję wydajności. Databricks automatyzuje obliczanie pojemności w ramach określonych granic endpointów.
Najlepszy kolejny krok jest konkretny. Weź istniejący prototyp Databricks, odtwórz pełny zestaw zapytań produkcyjnych i zmierz jego działanie przy normalnym oraz szczytowym ruchu.
Śledź opóźnienie P95, wskaźniki błędów, trafność, zachowanie synchronizacji oraz koszt pojemności. Przetestuj uwierzytelnianie za pomocą service principal i mechanizmy ponawiania prób w rzeczywistym środowisku aplikacji.
Następnie zadaj decydujące pytanie: czy target_qps wyeliminował warstwę obsługi, czy jedynie przeniósł jej planowanie do nowego ustawienia? Odpowiedź określi, czy Databricks AI Search pokonał lukę między prototypem a produkcją w przypadku Twojego obciążenia.
