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

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 intensywne obliczeniowo wzbogacanie AI, indeksatory są wymagane, ze względu na zależność 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 usługi wyszukiwania utworzonej po 3 kwietnia 2024 r. dla większej pojemności na partycję. Starsze usługi można również uaktualnić, aby korzystać z większej pojemności partycji.

Indeksowanie danych za pomocą interfejsów API typu "push"

API typu push, takie jak Documents Index REST API lub metoda IndexDocuments (Azure SDK dla platformy .NET), są najbardziej rozpowszechnioną formą indeksowania w usłudze Azure AI Search. W przypadku rozwiązań korzystających z interfejsu API wypychania strategia długotrwałego indeksowania może składać się z jednego lub obu z następujących składników:

• Grupowanie dokumentów w partie
• Zarządzanie wątkami

Grupuj 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 Documents Index REST API, czy IndexDocuments method 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 twojego 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 .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 API typu push 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 niedawno uaktualniono usługę, przełączono się na wyższą warstwę cenową lub zwiększono partycje.

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

2. Podczas zwiększania liczby żądań wysyłanych do usługi wyszukiwania mogą wystąpić kody stanu HTTP wskazujące, że żądanie nie zostało w pełni zrealizowane. 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 Wielo-stan: ten błąd oznacza, że niektóre dokumenty zakończyły się sukcesem, ale przynajmniej jeden dokument nie powiódł się.

3. Aby obsłużyć błędy, żądania powinny być ponawiane z zastosowaniem strategii wykładniczego wycofywania.

Azure .NET SDK automatycznie ponawia próby dla kodów 503 i innych nieudanych żądań, ale musisz zaimplementować własną logikę, aby ponawiać próby dla kodów 207. Narzędzia typu open source, takie jak Polly , mogą również służyć do implementowania strategii ponawiania prób.

Użyj indeksatorów i interfejsów API pobierania

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

• Grupowanie dokumentów w partie
• 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 wznowi pracę w miejscu, w którym zakończył, podczas kolejnego uruchomienia, pod warunkiem użycia ź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.

Sprawdź rozmiar partii indeksatora

Podobnie jak w przypadku interfejsu API wypychania indeksatory umożliwiają skonfigurowanie liczby elementów na partię. W przypadku indeksatorów korzystających z Create Indexer REST API można skonfigurować argument batchSize, aby dostosować to ustawienie do cech 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 Blob platformy Azure oraz SharePoint (wersja zapoznawcza) ustawia rozmiar partii na 10 dokumentów ze względu na większy średni rozmiar 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 procesów wolno działających, takich jak analiza obrazu w potoku wzbogacania.

Zazwyczaj przetwarzanie indeksatora jest uruchamiane w ciągu dwóch godzin. Jeśli obciążenie pracą indeksowania zajmuje dni zamiast godzin, można ustawić indeksator na kolejny, cykliczny harmonogram, który będzie się rozpoczynał 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 zaległości dokumentów w ciągu kilku dni, aż wszystkie zaległe dokumenty zostaną przetworzone. Ten wzorzec jest szczególnie ważny podczas początkowego uruchomienia lub podczas indeksowania dużych kontenerów obiektów blob, w których sama faza wyświetlania listy obiektów blob może potrwać wiele godzin lub dni. W tym czasie indeksator nie będzie pokazywał żadnych przetworzonych blobów, chyba że zostanie zgłoszony błąd, prawdopodobnie nadal wykonuje iterację za pośrednictwem listy blobów. Przetwarzanie dokumentów i wzbogacanie zaczynają się dopiero po zakończeniu tej fazy, a to zachowanie jest oczekiwane.

{
    "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, raporty z historii wykonywania indeksatora wykazują 0/0 przetworzonych dokumentów, a przetwarzanie nie występuje.

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

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 je uruchomić w tym samym czasie, co pozwala na szybsze wypełnienie indeksu wyszukiwania niż w przypadku uruchamiania ich sekwencyjnie.

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 zakończonych powodzeniem w indeksatorze nie zwiększa się w tym czasie i może się wydawać, że nie poczynia żadnych postępów, podczas gdy w rzeczywistości tak się dzieje. 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 Ustawienia>Skala, 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, co zwiększa 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 do tego samego pola.

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. Samouczek zawiera kroki użycia narzędzi Foundry Tools for AI do wzbogacania danych, ale można również użyć interfejsu API AzureSearchWriter do indeksowania tekstu.

Powiązana zawartość

• Poradnik: Optymalizacja indeksowania przy użyciu interfejsu API wypychania
• Samouczek: indeksowanie dużych danych z platformy Apache Spark przy użyciu języka SynapseML i usługi Azure AI Search
• Porady dotyczące lepszej wydajności w usłudze Azure AI Search
• Analizowanie wydajności w usłudze Azure AI Search
• Indeksatory w usłudze Azure AI Search
• Monitorowanie stanu indeksatora i wyników w usłudze Azure AI Search