Udostępnij za pośrednictwem

Indeksowanie dużych zestawów danych w usłudze Azure AI Search

  • Artykuł

Jeśli musisz indeksować duże lub złożone zestawy danych w rozwiązaniu wyszukiwania, w tym artykule omówiono strategie uwzględnienia długotrwałych procesów w usłudze Azure AI Search.

Te strategie zakładają znajomość dwóch podstawowych metod importowania danych: wypychania danych do indeksu lub ściągania danych z obsługiwanego źródła danych przy użyciu indeksatora wyszukiwania. Jeśli scenariusz obejmuje wzbogacenie sztucznej inteligencji intensywnie wykorzystujące obliczenia, indeksatory są wymagane, biorąc pod uwagę zależność zestawu umiejętności od indeksatorów.

Ten artykuł uzupełnia porady dotyczące lepszej wydajności, która oferuje najlepsze rozwiązania dotyczące projektowania indeksów i zapytań. Dobrze zaprojektowany indeks zawierający tylko wymagane pola i atrybuty jest ważnym wymaganiem wstępnym dla indeksowania na dużą skalę.

Zalecamy użycie nowszej usługi wyszukiwania utworzonej po 3 kwietnia 2024 r., aby uzyskać wyższy magazyn na partycję.

Uwaga

Strategie opisane w tym artykule zakładają pojedyncze duże źródło danych. Jeśli rozwiązanie wymaga indeksowania z wielu źródeł danych, zobacz Indeksowanie wielu źródeł danych w usłudze Azure AI Search , aby zapoznać się z zalecanym podejściem.

Indeksowanie danych przy użyciu interfejsów API wypychania

Interfejsy API wypychania , takie jak interfejs API REST indeksu dokumentów lub metoda IndexDocuments (Zestaw Azure SDK dla platformy .NET), są najbardziej rozpowszechnianą formą indeksowania w usłudze Azure AI Search. W przypadku rozwiązań korzystających z interfejsu API wypychania strategia długotrwałego indeksowania ma jeden lub oba następujące składniki:

  • Przetwarzanie wsadowe dokumentów
  • Zarządzanie wątkami

Wsadowe wiele dokumentów na żądanie

Prostym mechanizmem indeksowania dużej ilości danych jest przesłanie wielu dokumentów lub rekordów w jednym żądaniu. Jeśli cały ładunek wynosi poniżej 16 MB, żądanie może obsłużyć maksymalnie 1000 dokumentów w operacji przekazywania zbiorczego. Te limity mają zastosowanie niezależnie od tego, czy używasz interfejsu API REST indeksu dokumentów, czy metody IndexDocuments w zestawie SDK platformy .NET. Przy użyciu dowolnego interfejsu API można spakować 1000 dokumentów w treści każdego żądania.

Przetwarzanie wsadowe dokumentów znacznie skraca czas potrzebny do pracy z dużą ilością danych. Określenie optymalnego rozmiaru partii danych jest kluczowym składnikiem optymalizacji szybkości indeksowania. Dwa podstawowe czynniki wpływające na optymalny rozmiar partii to:

  • Schemat indeksu
  • Rozmiar danych

Ponieważ optymalny rozmiar partii zależy od indeksu i danych, najlepszym rozwiązaniem jest przetestowanie różnych rozmiarów partii w celu określenia, która z nich daje najszybszą szybkość indeksowania dla danego scenariusza. Aby uzyskać przykładowy kod do testowania rozmiarów partii przy użyciu zestawu .NET SDK, zobacz Samouczek: optymalizowanie indeksowania przy użyciu interfejsu API wypychania.

Zarządzanie wątkami i strategią ponawiania prób

Indeksatory mają wbudowane zarządzanie wątkami, ale w przypadku korzystania z interfejsów API wypychania kod aplikacji musi zarządzać wątkami. Upewnij się, że istnieją wystarczające wątki, aby w pełni korzystać z dostępnej pojemności, zwłaszcza jeśli ostatnio zwiększono partycje lub uaktualniono do usługi wyszukiwania w wyższej warstwie.

  1. Zwiększ liczbę współbieżnych wątków w kodzie klienta.

  2. Podczas zwiększania liczby żądań osiąganych przez usługę wyszukiwania mogą wystąpić kody stanu HTTP wskazujące, że żądanie nie powiodło się w pełni. Podczas indeksowania dwa typowe kody stanu HTTP to:

    • 503 Usługa niedostępna: ten błąd oznacza, że system jest obciążony dużym obciążeniem i nie można w tej chwili przetworzyć żądania.

    • 207 Stan wielokrotny: ten błąd oznacza, że niektóre dokumenty zakończyły się pomyślnie, ale co najmniej jeden błąd.

  3. Aby obsłużyć błędy, żądania powinny zostać ponowione przy użyciu strategii ponawiania prób wykładniczego wycofywania.

Zestaw Azure .NET SDK automatycznie ponawia próby 503 i inne żądania, które zakończyły się niepowodzeniem, ale musisz zaimplementować własną logikę, aby ponowić próbę 207s. Narzędzia typu open source, takie jak Polly , mogą również służyć do implementowania strategii ponawiania prób.

Korzystanie z indeksatorów i interfejsów API ściągania

Indeksatory mają kilka możliwości, które są przydatne w przypadku długotrwałych procesów:

  • Przetwarzanie wsadowe dokumentów
  • Równoległe indeksowanie danych partycjonowanych
  • Planowanie i wykrywanie zmian na potrzeby indeksowania tylko nowych i zmienionych dokumentów w czasie

Harmonogramy indeksatora mogą wznowić przetwarzanie w ostatnim znanym punkcie zatrzymania. Jeśli dane nie są w pełni indeksowane w oknie przetwarzania, indeksator pobiera wszędzie tam, gdzie po lewej stronie na następnym uruchomieniu, przy założeniu, że używasz źródła danych, które zapewnia wykrywanie zmian.

Partycjonowanie danych na mniejsze pojedyncze źródła danych umożliwia przetwarzanie równoległe. Możesz podzielić dane źródłowe, takie jak na wiele kontenerów w usłudze Azure Blob Storage, utworzyć źródło danych dla każdej partycji, a następnie uruchomić indeksatory równolegle, pod kątem liczby jednostek wyszukiwania usługi wyszukiwania.

Sprawdzanie rozmiaru partii indeksatora

Podobnie jak w przypadku interfejsu API wypychania indeksatory umożliwiają skonfigurowanie liczby elementów na partię. W przypadku indeksatorów opartych na interfejsie API REST tworzenia indeksatora można ustawić batchSize argument, aby dostosować to ustawienie, aby lepiej dopasować cechy danych.

Domyślne rozmiary partii są specyficzne dla źródła danych. Usługi Azure SQL Database i Azure Cosmos DB mają domyślny rozmiar partii 1000. Natomiast indeksowanie obiektów blob platformy Azure ustawia rozmiar partii na 10 dokumentów w rozpoznawaniu większego średniego rozmiaru dokumentu.

Planowanie indeksatorów dla długotrwałych procesów

Planowanie indeksatora to ważny mechanizm przetwarzania dużych zestawów danych i obsługi wolno działających procesów, takich jak analiza obrazu w potoku wzbogacania.

Zazwyczaj przetwarzanie indeksatora jest uruchamiane w ciągu dwóch godzin. Jeśli obciążenie indeksowania trwa kilka dni, a nie godzin, można umieścić indeksator na kolejnych, cyklicznych harmonogramach uruchamianych co dwie godziny. Zakładając, że źródło danych ma włączone śledzenie zmian, indeksator wznawia przetwarzanie, w którym ostatnio zostało przerwane. W tym tempie indeksator może przechodzić przez listę prac dokumentów w ciągu kilku dni do momentu przetworzenia wszystkich nieprzetworzonych dokumentów.

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Jeśli nie ma już żadnych nowych lub zaktualizowanych dokumentów w źródle danych, dokumenty historii wykonywania indeksatora są 0/0 przetwarzane i nie ma żadnego przetwarzania.

Aby uzyskać więcej informacji na temat ustawiania harmonogramów, zobacz Create Indexer REST API (Tworzenie interfejsu API REST indeksatora indeksatora) lub schedule indexers for Azure AI Search (Planowanie indeksatorów dla usługi Azure AI Search).

Uwaga

Niektóre indeksatory działające w starszej architekturze środowiska uruchomieniowego mają 24-godzinne, a nie 2-godzinne maksymalne okno przetwarzania. Limit dwugodzinny dotyczy nowszych procesorów zawartości, które działają w zarządzanym wewnętrznie środowisku wielodostępnym. Jeśli to możliwe, usługa Azure AI Search próbuje odciążyć indeksator i przetwarzanie zestawu umiejętności do środowiska wielodostępnego. Jeśli nie można zmigrować indeksatora, działa on w środowisku prywatnym i może działać tak długo, jak 24 godziny. Jeśli planujesz indeksator, który wykazuje te cechy, przyjmij 24-godzinne okno przetwarzania.

Równoległe uruchamianie indeksatorów

W przypadku partycjonowania danych można utworzyć wiele kombinacji indeksatora-źródła danych, które ściągają z każdego źródła danych i zapisują je w tym samym indeksie wyszukiwania. Ponieważ każdy indeksator jest odrębny, można uruchomić je w tym samym czasie, wypełnianie indeksu wyszukiwania szybciej niż w przypadku sekwencyjnie uruchomionych.

Upewnij się, że masz wystarczającą pojemność. Jedna jednostka wyszukiwania w usłudze może uruchamiać jeden indeksator w danym momencie. Tworzenie wielu indeksatorów jest przydatne tylko wtedy, gdy mogą działać równolegle.

Liczba zadań indeksowania, które mogą być uruchamiane jednocześnie, różni się w przypadku indeksowania opartego na tekście i umiejętnościach. Aby uzyskać więcej informacji, zobacz Wykonywanie indeksatora.

Jeśli źródło danych jest kontenerem usługi Azure Blob Storage lub usługą Azure Data Lake Storage Gen 2, wyliczanie dużej liczby obiektów blob może zająć dużo czasu (nawet godzin), dopóki ta operacja nie zostanie ukończona. W związku z tym liczba dokumentów indeksatora zakończonych powodzeniem nie zwiększa się w tym czasie i może się wydawać, że nie poczyni żadnych postępów, gdy tak jest. Jeśli chcesz, aby przetwarzanie dokumentów przebiegało szybciej w przypadku dużej liczby obiektów blob, rozważ podzielenie danych na wiele kontenerów i utworzenie równoległych indeksatorów wskazujących pojedynczy indeks.

  1. Zaloguj się do witryny Azure Portal i sprawdź liczbę jednostek wyszukiwania używanych przez usługę wyszukiwania. Wybierz pozycję Skala ustawień>, aby wyświetlić liczbę w górnej części strony. Liczba indeksatorów uruchamianych równolegle jest w przybliżeniu równa liczbie jednostek wyszukiwania.

  2. Partycjonowanie danych źródłowych między wieloma kontenerami lub wieloma folderami wirtualnymi wewnątrz tego samego kontenera.

  3. Utwórz wiele źródeł danych, po jednym dla każdej partycji, sparowanych z własnym indeksatorem.

  4. Określ ten sam docelowy indeks wyszukiwania w każdym indeksatorze.

  5. Zaplanuj indeksatory.

  6. Przejrzyj stan indeksatora i historię wykonywania w celu potwierdzenia.

Istnieje pewne ryzyko związane z indeksowaniem równoległym. Najpierw należy pamiętać, że indeksowanie nie działa w tle, zwiększając prawdopodobieństwo ograniczenia lub porzucenia zapytań.

Po drugie usługa Azure AI Search nie blokuje indeksu aktualizacji. Równoczesne zapisy są zarządzane, wywołując ponowienie próby, jeśli określony zapis nie powiedzie się podczas pierwszej próby, ale może wystąpić wzrost liczby błędów indeksowania.

Mimo że wiele zestawów indeksatora-źródła danych może być przeznaczonych dla tego samego indeksu, należy zachować ostrożność podczas uruchamiania indeksatora, który może zastąpić istniejące wartości w indeksie. Jeśli drugi indeksator-źródło danych jest przeznaczony dla tych samych dokumentów i pól, wszystkie wartości z pierwszego uruchomienia zostaną zastąpione. Wartości pól są zastępowane w całości; indeksator nie może scalić wartości z wielu przebiegów w tym samym polu.

Indeksowanie danych big data na platformie Spark

Jeśli masz architekturę danych big data i dane są w klastrze Spark, zalecamy użycie usługi SynapseML do ładowania i indeksowania danych. Ten samouczek zawiera kroki wywoływania usług Azure AI na potrzeby wzbogacania sztucznej inteligencji, ale można również użyć interfejsu API AzureSearchWriter do indeksowania tekstu.

Powiązana zawartość