Architekt systemówArchitekt systemów

Zaprojektuj globalnie rozproszoną, rzeczywistą wyszukiwarkę podobieństwa wektorów, która indeksuje miliardy wielowymiarowych osadzeń z multimodalnych modeli AI w heterogenicznych środowiskach brzegowych i chmurowych, zapewniając pobieranie przybliżonych najbliższych sąsiadów w czasie poniżej 10 ms z regulowaną precyzją przywołania, implementując dynamiczne dzielenie indeksów w oparciu o wzorce lokalności zapytań oraz utrzymując końcową spójność między magazynem wektorów a bazami danych o źródle prawdy podczas aktualizacji osadzeń o wysokiej prędkości bez blokowania operacji wyszukiwania?

Zdaj rozmowy kwalifikacyjne z asystentem AI Hintsage

Odpowiedź na pytanie

Historia pytania

Przejście od wyszukiwania leksykalnego do wyszukiwania semantycznego fundamentalnie zmieniło potrzeby infrastrukturalne danych w ciągu ostatniej dekady. Wczesne wyszukiwanie informacji opierało się na indeksach odwróconych i ocenie TF-IDF, ale nowoczesne systemy AI multimodalnej wymagają wyszukiwania bliskości w wysokowymiarowych przestrzeniach wektorowych, które często przekraczają 1000 wymiarów. Ta zmiana nasiliła się wraz z proliferacją modeli opartych na transformatorach, generujących miliardy gęstych osadzeń, które tradycyjne bazy danych nie mogą efektywnie przeszukiwać. Wyzwanie przeszło od prostego przechowywania do utrzymywania przybliżonych najbliższych grafów sąsiadów w rozproszonych geograficznie węzłach, podczas gdy zachowanie spójności z systemami źródłowymi transakcji.

Problem

Bazy danych wektorowych stają przed unikalnymi ograniczeniami zgodnie z twierdzeniem CAP, ponieważ dokładne obliczenia k-najbliższych sąsiadów wymagają globalnej wiedzy o zbiorze danych, co sprawia, że tolerancja podziałów i niska latencja są wzajemnie wykluczające na skalę miliardów wektorów. Wysokowymiarowe osadzenia zużywają znaczną ilość pamięci — często 4KB na wektor przy 1024 wymiarach przy użyciu float32 — co stwarza problemy z grawitacją danych, które komplikują wdrożenie na brzegu. Ponadto „klątwa wymiarowości” sprawia, że indeksy przestrzenne oparte na drzewach stają się nieskuteczne, co wymusza algorytmy oparte na grafach, takie jak HNSW, które są kosztowne w aktualizacji inkrementalnej. Utrzymywanie spójności między zmiennymi danymi transakcyjnymi w PostgreSQL a niezmiennymi indeksami wektorowymi wprowadza anomalie podczas pisania dualnego, podczas gdy replikacja indeksów w różnych regionach pogarsza koszty przepustowości z powodu rozmiarów ładunków osadzeń.

Rozwiązanie

Architektura oparte na komórkach wykorzystująca hierarchiczne nawigowalne grafy małych światów z kompresją kwantyzacji produktu umożliwia zapytania poniżej 10 ms, jednocześnie zmniejszając ślad pamięci o 90%. Regionalne komórki wektorowe przyjmują osadzenia przez strumienie Apache Kafka z łącznikami CDC Debezium, zapewniając, że bazy danych będące źródłem prawdy pozostają izolowane od narzutu budowy indeksu. Dynamiczne dzielenie indeksów stosuje haszowanie wrażliwe na lokalność, aby kierować zapytania do konkretnych partycji, minimalizując przestrzeń wyszukiwania z miliardów do milionów kandydatów. Model ostatecznej spójności z wersjonowaniem wektorów i miękkimi usunięciami pozwala na aktualizacje indeksów bez blokowania, podczas gdy konsensus Raft koordynuje zmiany metadanych w komórkach bez centralizowania gorącej ścieżki zapytań.

Sytuacja z życia

Opis problemu

Globalna platforma wizualnej sprzedaży „LuxeSearch” utrzymuje 400 milionów SKU produktów w kategoriach mody i mebli, wymagając wyszukiwania podobieństwa wizualnego, gdzie użytkownicy przesyłają zdjęcia, aby znaleźć identyczne lub komplementarne przedmioty. Dziedziczna infrastruktura Elasticsearch załamała się pod obciążeniem obliczeniowym obliczeń podobieństwa kosinusowego w osadzeniach CLIP o wymiarach 768, powodując szczyty latencji 800 ms podczas szczytowego ruchu. Ponadto aktualizacje metadanych produktów występują z prędkością 50 000 transakcji na sekundę podczas wyprzedaży, co powoduje uszkodzenie indeksu, gdy równoczesne aktualizacje kolidowały z operacjami wyszukiwania, co skutkowało utratą przychodu przekraczającą 2 miliony dolarów na godzinę degradacji.

Rozwiązanie 1: Monolityczny globalny klaster

Początkowa propozycja wdrożyła pojedynczy klaster Milvus w us-east-1 z globalnym buforowaniem CDN dla zestawów wyników zapytań. To podejście oferowało silne gwarancje spójności i uprościło narzut operacyjny przez utrzymywanie jednego stanu indeksu. Jednak latencja międzyregionowa dla użytkowników APAC przekroczyła 180 ms, naruszając wymagania aplikacji mobilnej poniżej 50 ms, a ryzyko pojedynczego punktu awarii stało się nieakceptowalne w okresie zakupów świątecznych, gdy koszty przestojów rosną wykładniczo.

Rozwiązanie 2: Regionalne indeksy wsadowe nocne

Alternatywna architektura zaproponowała regionalne indeksy FAISS rekonstruowane poprzez nocne zadania wsadowe z migawki S3. To zapewniło latencję zapytań poniżej 5 ms dzięki lokalnej inferencji CPU i wyeliminowało okrążenia sieciowe podczas wyszukiwań. Niestety, 24-godzinna przestarzałość danych spowodowała skargi klientów dotyczące „duchowych produktów” pojawiających się w wynikach wyszukiwania wizualnego po wyprzedaniu przedmiotów, a sześciogodzinne okna konserwacyjne wymagane do rekonstrukcji indeksu naruszyły SLA 99,99% dostępności.

Wybrane rozwiązanie

Zespół wdrożył autonomiczne komórki wektorowe z użyciem Redis z modułem RedisSearch dla gorących indeksów zawierających 10% najlepszych produktów wg wolumenu zapytań, wspieranym przez graficzne grafy HNSW przechowywane w S3 dla zimnych danych. Debezium przechwytuje zmiany PostgreSQL do Kafka, zasilając lokalnych budowniczych indeksów regionalnych, którzy implementują inkrementalne aktualizacje HNSW za pomocą wzorca outbox. Kwantyzacja produktu redukuje osadzenia wektorów o wymiarach 768 float32 do 96-bajtowych kodów z 98% precyzji recall@10. To rozwiązanie zostało wybrane, ponieważ zapewnia regulowaną spójność z semantyką read-your-writes w ciągu 500 ms, obsługuje 100K aktualizacji osadzeń na sekundę bez blokowania zapytań i utrzymuje latencję 8 ms p99 we wszystkich 12 globalnych regionach.

Wynik

Po sześciu miesiącach wdrożenia produkcyjnego architektura osiągnęła 99,97% dostępności, wspierała 50 milionów codziennych wyszukiwań wizualnych i zmniejszyła koszty infrastruktury o 40% w porównaniu do propozycji monolitycznej dzięki inteligentnemu zarządzaniu. Wskaźnik recall@10 ustabilizował się na poziomie 99,2%, przekraczając wymagania biznesowe, a system skutecznie zaabsorbował 300% wzrostu ruchu podczas Black Friday bez interwencji ręcznej lub szturmów na pamięć podręczną.

Co często pomijają kandydaci

Dlaczego odległość euklidesowa staje się nieskuteczna w przestrzeniach wysokowymiarowych i jak wpływa to na wybór indeksu?

W przestrzeniach wysokowymiarowych przekraczających 100 wymiarów stosunek między najbliższymi a najdalszymi sąsiadami zbliża się do 1 z powodu koncentracji objętości na powierzchni hipersfery, co sprawia, że odległości euklidesowe stają się statystycznie nieodróżnialne i przestrzennie nieinformacyjne. Zjawisko to unieważnia przestrzenne podział drzew, takie jak drzewa kd lub drzewa R, które polegają na istotnym różnicowaniu odległości, aby skutecznie przycinać gałęzie wyszukiwania. W związku z tym metody oparte na grafach, takie jak HNSW lub indeksy FAISS IVF stają się konieczne, ponieważ poruszają się w bliskości przez względną łączność sąsiedzką, a nie absolutne odległości współrzędnych, chociaż wymagają znacznie więcej pamięci oraz skomplikowanych procedur inkrementalnego utrzymania.

Jak radzisz sobie z problemem "dual-write", gdy zarówno baza danych transakcyjnych, jak i indeks wektorowy muszą być aktualizowane atomowo?

Problem dual-write występuje, gdy rozproszone transakcje nie udają się między magazynem OLTP a bazą danych wektorową, co powoduje, że wyniki wyszukiwania zwracają usunięte przedmioty lub przegapiają nowe osadzenia z powodu częściowych stanów zatwierdzenia. Zamiast wdrażać protokoły dwufazowego zatwierdzania, które podważyłyby wymagania dotyczące latencji poniżej 10 ms, architekci powinni zastosować wzorzec outbox transakcyjnego, w którym PostgreSQL zapisuje do tabeli outbox w tym samym tranzakcji ACID, co zmiana danych biznesowych. Debezium odczytuje tę skrzynkę odbiorczą i asynchronicznie publikuje do Kafka, zapewniając dostawę exactly-once do budowniczych indeksów wektorowych; wpisy wektorowe zawierają monotoniczne numery wersji, a API wyszukiwania filtruje wyniki, weryfikując w stosunku do magazynu metadanych OLTP, aby wykluczyć przestarzałe wersje, skutecznie maskując niespójności bez blokowania zapytań.

Jakie są implikacje pamięciowe indeksów ANN opartych na grafach podczas inkrementalnych aktualizacji i jak łagodzisz amplifikację zapisów?

HNSW i podobne struktury grafowe wymagają blokowania lub mechanizmów copy-on-write podczas wstawiania krawędzi, co powoduje znaczne amplifikacje zapisów, ponieważ dodanie jednego wektora może spowodować ponowne połączenie setek krawędzi w celu utrzymania właściwości nawigowalności hierarchicznej. W środowiskach o ograniczonej pamięci prowadzi to do błędów strony oraz nacisku na zbieranie śmieci, które nieprzewidywalnie pogarszają latencję zapytań, gdy zestaw roboczy przekracza pojemność DRAM. Strategie łagodzenia obejmują stosowanie magazynowania wielopoziomowego, gdzie gorące warstwy grafowe mieszczą się w pamięci, a zimne w trwałej pamięci lub szybkich dyskach NVMe SSD; pakowanie aktualizacji w mikrosegmenty, które łączą się asynchronicznie w czasie niskiego ruchu za pomocą technik łączenia struktury logu; oraz wdrażanie budowy grafu dostosowanej do kwantyzacji, gdzie skompresowane wektory określają topologię grafu, a surowe wektory są pobierane tylko podczas ostatecznego ponownego rankingu, redukując zmiany pamięci o 70% przy jednoczesnym utrzymaniu docelowych metryk recall.