Udostępnij za pośrednictwem

Tworzenie indeksu w usłudze Azure AI Search

  • Artykuł

W tym artykule przedstawiono kroki definiowania schematu indeksu wyszukiwania i wypychania go do usługi wyszukiwania. Tworzenie indeksu ustanawia fizyczne struktury danych w usłudze wyszukiwania. Po utworzeniu indeksu załaduj indeks jako osobne zadanie.

Wymagania wstępne

  • Uprawnienia do zapisu jako współautor usługi wyszukiwania lub klucz interfejsu API administratora na potrzeby uwierzytelniania opartego na kluczach.

  • Znajomość danych, które chcesz indeksować. Indeks wyszukiwania jest oparty na zawartości zewnętrznej, która ma być wyszukiwana. Zawartość z możliwością wyszukiwania jest przechowywana jako pola w indeksie. Musisz mieć jasny pomysł, które pola źródłowe mają być wyszukiwalne, dostępne do pobrania, filtrowalne, aspektowe i sortowalne w usłudze Azure AI Search. Aby uzyskać wskazówki, zobacz listę kontrolną schematu.

  • Musisz również mieć unikatowe pole w danych źródłowych, które może być używane jako klucz dokumentu (lub identyfikator) w indeksie.

  • Stabilna lokalizacja indeksu. Przenoszenie istniejącego indeksu do innej usługi wyszukiwania nie jest obsługiwane w trybie out-of-box. Ponownie zapoznaj się z wymaganiami aplikacji i upewnij się, że istniejąca usługa wyszukiwania (pojemność i region) są wystarczające dla Twoich potrzeb. Jeśli korzystasz z zależności od usług Azure AI lub Azure OpenAI, wybierz region , który udostępnia wszystkie niezbędne zasoby.

  • Na koniec wszystkie warstwy usług mają limity indeksów dla liczby obiektów, które można utworzyć. Jeśli na przykład eksperymentujesz z warstwą Bezpłatna, w danym momencie możesz mieć tylko trzy indeksy. W samym indeksie istnieją ograniczenia dotyczące wektorów i limitów indeksów liczby prostych i złożonych pól.

Klucze dokumentów

Tworzenie indeksu wyszukiwania ma dwa wymagania: indeks musi mieć unikatową nazwę w usłudze wyszukiwania i musi mieć klucz dokumentu. Atrybut logiczny key w polu można ustawić na wartość true, aby wskazać, które pole zawiera klucz dokumentu.

Klucz dokumentu jest unikatowym identyfikatorem dokumentu wyszukiwania, a dokument wyszukiwania jest kolekcją pól, które całkowicie opisują coś. Jeśli na przykład indeksujesz zestaw danych filmów, dokument wyszukiwania zawiera tytuł, gatunek i czas trwania pojedynczego filmu. Nazwy filmów są unikatowe w tym zestawie danych, więc możesz użyć nazwy filmu jako klucza dokumentu.

W usłudze Azure AI Search klucz dokumentu jest ciągiem i musi pochodzić z unikatowych wartości w źródle danych, które udostępnia zawartość do indeksowania. Ogólnie rzecz biorąc, usługa wyszukiwania nie generuje wartości kluczy, ale w niektórych scenariuszach (takich jak indeksator tabel platformy Azure) syntetyzuje istniejące wartości w celu utworzenia unikatowego klucza dla indeksowanych dokumentów. Innym scenariuszem jest indeksowanie jeden do wielu dla fragmentowanych lub partycjonowanych danych, w tym przypadku klucze dokumentów są generowane dla każdego fragmentu.

Podczas indeksowania przyrostowego, gdzie indeksowana jest nowa i zaktualizowana zawartość, dodawane są dokumenty przychodzące z nowymi kluczami, podczas gdy dokumenty przychodzące z istniejącymi kluczami są scalane lub zastępowane, w zależności od tego, czy pola indeksu mają wartość null, czy wypełniane.

Ważne kwestie dotyczące kluczy dokumentów obejmują:

  • Maksymalna długość wartości w polu klucza wynosi 1024 znaki.
  • Należy wybrać dokładnie jedno pole najwyższego poziomu w każdym indeksie jako pole klucza i musi mieć typ Edm.String.
  • Wartość domyślna atrybutu key to false dla prostych pól i wartości null dla pól złożonych.

Pola klucza mogą służyć do bezpośredniego wyszukiwania dokumentów i aktualizowania lub usuwania określonych dokumentów. Wartości pól kluczy są obsługiwane w sposób uwzględniający wielkość liter podczas wyszukiwania lub indeksowania dokumentów. Aby uzyskać szczegółowe informacje, zobacz GET Document (REST) i Index Documents (REST).

Lista kontrolna schematu

Ta lista kontrolna ułatwia podejmowanie decyzji projektowych dotyczących indeksu wyszukiwania.

  1. Przejrzyj konwencje nazewnictwa, aby nazwy indeksów i pól były zgodne z regułami nazewnictwa.

  2. Zobacz obsługiwane typy danych. Typ danych wpływa na sposób użycia pola. Na przykład zawartość liczbowa jest dostępna do filtrowania, ale nie nadaje się do wyszukiwania pełnotekstowego. Najczęściej używanym typem danych jest Edm.String w przypadku tekstu z możliwością wyszukiwania, który jest tokenizowany i odpytywany przy użyciu aparatu do wyszukiwania pełnotekstowego. Najczęstszym typem danych dla pola wektora jest Edm.Single użycie również innych typów.

  3. Identyfikowanie klucza dokumentu. Klucz dokumentu jest wymaganiem dotyczącym indeksu. Jest to jedno pole ciągu wypełnione z pola danych źródłowych, które zawiera unikatowe wartości. Jeśli na przykład indeksujesz z usługi Blob Storage, ścieżka magazynu metadanych jest często używana jako klucz dokumentu, ponieważ identyfikuje w sposób unikatowy każdy obiekt blob w kontenerze.

  4. Zidentyfikuj pola w źródle danych, które współtworzą zawartość z możliwością wyszukiwania w indeksie.

    Zawartość niewektorowalna do wyszukiwania zawiera krótkie lub długie ciągi, których dotyczy zapytanie przy użyciu wyszukiwarki pełnotekstowej. Jeśli zawartość jest szczegółowa (małe frazy lub większe fragmenty), poeksperymentuj z różnymi analizatorami, aby zobaczyć, jak tekst jest tokenizowany.

    Zawartość wektorowa z możliwością wyszukiwania może być obrazami lub tekstem (w dowolnym języku), które istnieją jako reprezentacja matematyczna. Możesz użyć wąskich typów danych lub kompresji wektorów, aby zmniejszyć pola wektorów.

    Atrybuty ustawione dla pól, takich jak lub filterable, określają zarówno zachowania wyszukiwania, jak retrievable i fizyczną reprezentację indeksu w usłudze wyszukiwania. Określanie sposobu przypisywanie pól jest procesem iteracyjnym dla wielu deweloperów. Aby przyspieszyć iteracje, zacznij od przykładowych danych, które można łatwo upuszczać i ponownie kompilować.

  5. Określ, które pola źródłowe mogą być używane jako filtry. Zawartość liczbowa i krótkie pola tekstowe, szczególnie te z powtarzającymi się wartościami, są dobrymi wyborami. Podczas pracy z filtrami pamiętaj, że:

    • Filtry mogą być używane w zapytaniach wektorowych i niewektorowych, ale sam filtr jest stosowany do pól czytelnych dla człowieka (niewektorów) w indeksie.

    • Pola z możliwością filtrowania mogą być opcjonalnie używane w nawigacji aspektowej.

    • Pola z możliwością filtrowania są zwracane w dowolnej kolejności i nie są poddawane ocenianiu istotności, dlatego warto rozważyć ich sortowanie.

  6. W przypadku pól wektorowych określ konfigurację wyszukiwania wektorowego i algorytmy używane do tworzenia ścieżek nawigacji i wypełniania miejsca osadzania. Aby uzyskać więcej informacji, zobacz Dodawanie pól wektorów.

    Pola wektorowe mają dodatkowe właściwości, których nie mają pola niewektorowe, takie jak algorytmy do użycia i kompresja wektorów.

    Pola wektorowe pomijają atrybuty, które nie są przydatne w danych wektorowych, takich jak sortowanie, filtrowanie i tworzenie aspektów.

  7. W przypadku pól niewektorowych określ, czy używać analizatora domyślnego ("analyzer": null) czy innego analizatora. Analizatory są używane do tokenizowania pól tekstowych podczas indeksowania i wykonywania zapytań.

    W przypadku ciągów wielojęzycznych należy rozważyć używanie analizatora języka.

    W przypadku ciągów z łącznikami lub znakami specjalnymi należy wziąć pod uwagę wyspecjalizowane analizatory. Jednym z przykładów jest słowo kluczowe , które traktuje całą zawartość pola jako pojedynczy token. To zachowanie jest przydatne w przypadku danych, takich jak kody pocztowe, identyfikatory i niektóre nazwy produktów. Aby uzyskać więcej informacji, zobacz temat Częściowe wyszukiwanie terminów i wzorce ze znakami specjalnymi.

Uwaga

Wyszukiwanie pełnotekstowe jest przeprowadzane na terminach, które są tokenizowane podczas indeksowania. Jeśli zapytania nie zwracają oczekiwanych wyników, przetestuj tokenizację, aby sprawdzić ciąg, którego szukasz, rzeczywiście istnieje. Możesz wypróbować różne analizatory w ciągach, aby zobaczyć, jak tokeny są tworzone dla różnych analizatorów.

Konfigurowanie definicji pól

Kolekcja pól definiuje strukturę dokumentu wyszukiwania. Wszystkie pola mają nazwę, typ danych i atrybuty.

Ustawienie pola jako możliwego do wyszukiwania, filtrowania, sortowania lub tworzenia aspektów ma wpływ na rozmiar indeksu i wydajność zapytań. Nie ustawiaj tych atrybutów w polach, do których nie należy odwoływać się w wyrażeniach zapytania.

Jeśli pole nie jest ustawione na wyszukiwanie, filtrowanie, sortowanie lub tworzenie aspektów, nie można odwoływać się do pola w żadnym wyrażeniu zapytania. Jest to pożądane w przypadku pól, które nie są używane w zapytaniach, ale są potrzebne w wynikach wyszukiwania.

Interfejsy API REST mają domyślne przypisanie na podstawie typów danych, które są również używane przez kreatorów importu w witrynie Azure Portal. Zestawy SDK platformy Azure nie mają wartości domyślnych, ale mają podklasy pól, które zawierają właściwości i zachowania, takie jak SearchableField dla ciągów i SimpleField dla elementów pierwotnych.

Domyślne przypisania pól dla interfejsów API REST zostały podsumowane w poniższej tabeli.

Typ danych Z możliwością wyszukiwania Z możliwością pobierania Filtrowanie Tworzenie aspektów Z możliwością sortowania Przechowywane
Edm.String ✅ ✅ ✅ ✅ ✅ ✅
Collection(Edm.String) ✅ ✅ ✅ ✅ ❌ ✅
Edm.Boolean ❌ ✅ ✅ ✅ ✅ ✅
Edm.Int32, , Edm.Int64Edm.Double ❌ ✅ ✅ ✅ ✅ ✅
Edm.DateTimeOffset ❌ ✅ ✅ ✅ ✅ ✅
Edm.GeographyPoint ✅ ✅ ✅ ❌ ✅ ✅
Edm.ComplexType ✅ ✅ ✅ ✅ ✅ ✅
Collection(Edm.Single) i wszystkie inne typy pól wektorów ✅ ✅ lub ❌ ❌ ❌ ❌ ✅

Pola ciągów można również opcjonalnie skojarzyć z analizatorami i mapami synonimów. Pola typu Edm.String , które można filtrować, sortować lub aspektowe, mogą mieć długość co najwyżej 32 kilobajtów. Wynika to z faktu, że wartości takich pól są traktowane jako pojedynczy termin wyszukiwania, a maksymalna długość terminu w usłudze Azure AI Search wynosi 32 kilobajty. Jeśli musisz przechowywać więcej tekstu niż w jednym polu ciągu, należy jawnie ustawić filtrowanie, sortowanie i tworzenie aspektów w false definicji indeksu.

Pola wektorowe muszą być skojarzone z wymiarami i profilami wektorów. Wartość domyślna do pobrania ma wartość true, jeśli dodasz pole wektorowe przy użyciu kreatora Importuj i wektoryzuje w witrynie Azure Portal, w przeciwnym razie jest to fałsz, jeśli używasz interfejsu API REST.

Atrybuty pól zostały opisane w poniższej tabeli.

Atrybut Opis
name Wymagany. Ustawia nazwę pola, które musi być unikatowe w kolekcji pól indeksu lub pola nadrzędnego.
type Wymagany. Ustawia typ danych dla pola. Pola mogą być proste lub złożone. Proste pola są typami pierwotnymi, takimi jak Edm.String tekst lub Edm.Int32 liczba całkowita. Pola złożone mogą zawierać pola podrzędne, które same są proste lub złożone. Dzięki temu można modelować obiekty i tablice obiektów, co z kolei umożliwia przekazywanie większości struktur obiektów JSON do indeksu. Aby uzyskać pełną listę obsługiwanych typów, zobacz Obsługiwane typy danych.
key Wymagany. Ustaw ten atrybut na wartość true, aby wyznaczyć wartości pola unikatowo identyfikujące dokumenty w indeksie. Aby uzyskać szczegółowe informacje, zobacz Klucze dokumentów w tym artykule.
Pobieranie Wskazuje, czy pole może zostać zwrócone w wynikach wyszukiwania. Ustaw ten atrybut na false wartość , jeśli chcesz użyć pola jako mechanizmu filtrowania, sortowania lub oceniania, ale nie chcesz, aby pole było widoczne dla użytkownika końcowego. Ten atrybut musi być true przeznaczony dla pól klucza i musi być null przeznaczony dla pól złożonych. Ten atrybut można zmienić w istniejących polach. Ustawienie możliwości true pobierania nie powoduje zwiększenia wymagań magazynu indeksu. Wartość domyślna dotyczy true prostych pól i null pól złożonych.
Wyszukiwanie Wskazuje, czy pole jest wyszukiwaniem pełnotekstowym i może być przywoływalne w zapytaniach wyszukiwania. Oznacza to, że jest poddawana analizie leksykalnej, takiej jak łamanie wyrazów podczas indeksowania. Jeśli ustawisz pole z możliwością wyszukiwania na wartość podobną do "Słoneczny dzień", wewnętrznie jest znormalizowane do poszczególnych tokenów "sunny" i "day". Umożliwia to wyszukiwanie pełnotekstowe dla tych terminów. Pola typu Edm.String lub Collection(Edm.String) domyślnie można wyszukiwać. Ten atrybut musi być false przeznaczony dla prostych pól innych typów danych nieciągujących i musi być null przeznaczony dla pól złożonych.

Pole z możliwością wyszukiwania zużywa dodatkowe miejsce w indeksie, ponieważ usługa Azure AI Search przetwarza zawartość tych pól i organizuje je w pomocniczych strukturach danych na potrzeby wydajnego wyszukiwania. Jeśli chcesz zaoszczędzić miejsce w indeksie i nie musisz uwzględniać pola w wyszukiwaniu, ustaw wartość .false Aby uzyskać szczegółowe informacje, zobacz Jak działa wyszukiwanie pełnotekstowe w usłudze Azure AI Search .
Filtrowanie Wskazuje, czy pole ma być przywołyne w $filter zapytaniach. Filtrowanie różni się od możliwości wyszukiwania w sposobie obsługi ciągów. Pola typu Edm.String lub Collection(Edm.String) , które można filtrować, nie są poddawane analizie leksykalnej, więc porównania są przeznaczone tylko dla dokładnych dopasowań. Jeśli na przykład ustawisz takie pole f na "Słoneczny dzień", $filter=f eq 'sunny' nie znajdzie żadnych dopasowań, ale $filter=f eq 'Sunny day' będzie. Ten atrybut musi być null przeznaczony dla pól złożonych. Wartość domyślna dotyczy true prostych pól i null pól złożonych. Aby zmniejszyć rozmiar indeksu, ustaw ten atrybut na false wartość w polach, dla których nie będziesz filtrować.
Sortowanie Wskazuje, czy pole ma być przywoływane w $orderby wyrażeniach. Domyślnie usługa Azure AI Search sortuje wyniki według wyniku, ale w wielu środowiskach użytkownicy chcą sortować według pól w dokumentach. Proste pole można sortować tylko wtedy, gdy jest jednowartościowe (ma pojedynczą wartość w zakresie dokumentu nadrzędnego).

Proste pola kolekcji nie mogą być sortowane, ponieważ są wielowartośćowe. Proste pola podrzędne złożonych kolekcji są również wielowartościowe i dlatego nie można sortować. Dotyczy to zarówno natychmiastowego pola nadrzędnego, jak i pola przodka, czyli kolekcji złożonej. Pola złożone nie mogą być sortowalne, a atrybut sortowania musi być null przeznaczony dla takich pól. Wartością domyślną dla sortowania są true pola proste z jedną wartością, false dla wielowartych prostych pól i null dla pól złożonych.
Tworzenie aspektów Wskazuje, czy pole ma być przywołyne w zapytaniach aspektowych. Zazwyczaj używane w prezentacji wyników wyszukiwania, które obejmują liczbę trafień według kategorii (na przykład wyszukiwanie aparatów cyfrowych i wyświetlanie trafień według marki, megapikseli, ceny itd.). Ten atrybut musi być null przeznaczony dla pól złożonych. Pola typu Edm.GeographyPoint lub Collection(Edm.GeographyPoint) nie mogą być aspektami. Wartość domyślna dotyczy true wszystkich innych prostych pól. Aby zmniejszyć rozmiar indeksu, ustaw ten atrybut na false wartość w polach, na których nie będziesz ustawiać aspektów.
analizator Ustawia analizator leksykalny na potrzeby tokenizowania ciągów podczas indeksowania i wykonywania operacji zapytań. Prawidłowe wartości tej właściwości obejmują analizatory języków, wbudowane analizatory i analizatory niestandardowe. Wartość domyślna to standard.lucene. Ten atrybut może być używany tylko z polami ciągów z możliwością wyszukiwania i nie można go ustawić razem z elementem searchAnalyzer lub indexAnalyzer. Po wybraniu analizatora i utworzeniu pola w indeksie nie można go zmienić dla pola. Musi być null przeznaczony dla pól złożonych.
searchAnalyzer Ustaw tę właściwość razem z indexAnalyzer, aby określić różne analizatory leksykalne na potrzeby indeksowania i zapytań. Jeśli używasz tej właściwości, ustaw analizator na null wartość i upewnij się, że właściwość indexAnalyzer jest ustawiona na dozwoloną wartość. Prawidłowe wartości tej właściwości obejmują wbudowane analizatory i analizatory niestandardowe. Ten atrybut może być używany tylko z polami z możliwością wyszukiwania. Analizator wyszukiwania można zaktualizować w istniejącym polu, ponieważ jest używany tylko w czasie wykonywania zapytań. Musi być null w przypadku pól złożonych].
indexAnalyzer Ustaw tę właściwość razem z funkcją searchAnalyzer, aby określić różne analizatory leksykalne na potrzeby indeksowania i zapytań. Jeśli używasz tej właściwości, ustaw analizator na null wartość i upewnij się, że właściwość searchAnalyzer jest ustawiona na dozwoloną wartość. Prawidłowe wartości tej właściwości obejmują wbudowane analizatory i analizatory niestandardowe. Ten atrybut może być używany tylko z polami z możliwością wyszukiwania. Po wybraniu analizatora indeksu nie można go zmienić dla pola. Musi być null przeznaczony dla pól złożonych.
synonimyMapy Lista nazw map synonimów do skojarzenia z tym polem. Ten atrybut może być używany tylko z polami z możliwością wyszukiwania. Obecnie obsługiwana jest tylko jedna mapa synonimów na pole. Przypisanie mapy synonimów do pola zapewnia, że terminy zapytania przeznaczone dla tego pola są rozszerzane w czasie wykonywania zapytań przy użyciu reguł w mapie synonimów. Ten atrybut można zmienić w istniejących polach. Musi być null lub pustą kolekcją dla pól złożonych.
pola Lista pól podrzędnych, jeśli jest to pole typu Edm.ComplexType lub Collection(Edm.ComplexType). Musi być null pusty lub pusty dla prostych pól. Zobacz How to model complex data types in Azure AI Search (Jak modelować złożone typy danych w usłudze Azure AI Search ), aby uzyskać więcej informacji na temat tego, jak i kiedy używać pól podrzędnych.

Tworzenie indeksu

Gdy wszystko będzie gotowe do utworzenia indeksu, użyj klienta wyszukiwania, który może wysłać żądanie. Do wczesnego programowania i testowania koncepcji można użyć witryny Azure Portal lub interfejsów API REST. W przeciwnym razie często używa się zestawów SDK platformy Azure.

Podczas opracowywania zaplanuj częste ponowne kompilowanie. Ponieważ struktury fizyczne są tworzone w usłudze, usuwanie i ponowne tworzenie indeksów jest niezbędne w przypadku wielu modyfikacji. Możesz rozważyć pracę z podzbiorem danych, aby przyspieszyć ponowne kompilowanie.

Projektowanie indeksów w witrynie Azure Portal wymusza wymagania i reguły schematu dla określonych typów danych, takie jak brak możliwości wyszukiwania pełnotekstowego w polach liczbowych.

  1. Zaloguj się w witrynie Azure Portal.

  2. Sprawdź miejsce. usługa wyszukiwania podlegają maksymalnej liczbie indeksów, różniąc się w zależności od warstwy usług. Upewnij się, że masz miejsce na drugi indeks.

  3. Na stronie Przegląd usługi wyszukiwania wybierz jedną z opcji tworzenia indeksu wyszukiwania:

    • Dodawanie indeksu , osadzonego edytora do określania schematu indeksu
    • Kreatory importu

    Kreator to pełny przepływ pracy, który tworzy indeksator, źródło danych i gotowy indeks. Ładuje również dane. Jeśli jest to więcej niż to, co chcesz, użyj zamiast tego polecenia Dodaj indeks .

Na poniższym zrzucie ekranu wyróżniono pozycję Dodaj indeks, Importuj dane oraz Importuj i wektoryzuj dane na pasku poleceń.

Zrzut ekranu przedstawiający opcje dodawania indeksu.

Po utworzeniu indeksu można go znaleźć ponownie na stronie Indeksy w okienku nawigacji po lewej stronie.

Napiwek

Po utworzeniu indeksu w witrynie Azure Portal możesz skopiować reprezentację JSON i dodać ją do kodu aplikacji.

Ustawianie corsOptions dla zapytań między źródłami

Schematy indeksów zawierają sekcję ustawienia corsOptions. Domyślnie język JavaScript po stronie klienta nie może wywoływać żadnych interfejsów API, ponieważ przeglądarki uniemożliwiają wszystkie żądania między źródłami. Aby zezwolić na wykonywanie zapytań między źródłami do indeksu, włącz mechanizm CORS (współużytkowanie zasobów między źródłami), ustawiając atrybut corsOptions . Ze względów bezpieczeństwa tylko interfejsy API zapytań obsługują mechanizm CORS.

"corsOptions": {
  "allowedOrigins": [
    "*"
  ],
  "maxAgeInSeconds": 300

Dla mechanizmu CORS można ustawić następujące właściwości:

  • allowedOrigins (wymagane): jest to lista źródeł, które mogą uzyskiwać dostęp do indeksu. Kod JavaScript obsługiwany z tych źródeł może wykonywać zapytania względem indeksu (zakładając, że obiekt wywołujący udostępnia prawidłowy klucz lub ma uprawnienia). Każde źródło jest zazwyczaj postacią protocol://<fully-qualified-domain-name>:<port> , chociaż <port> często jest pomijane. Aby uzyskać więcej informacji, zobacz Współużytkowanie zasobów między źródłami (Wikipedia).

    Jeśli chcesz zezwolić na dostęp do wszystkich źródeł, dołącz * go jako pojedynczy element w tablicy allowedOrigins . Nie jest to zalecana praktyka w przypadku usług wyszukiwania w środowisku produkcyjnym, ale często jest przydatna do programowania i debugowania.

  • maxAgeInSeconds (opcjonalnie): przeglądarki używają tej wartości do określenia czasu trwania (w sekundach) w celu buforowania odpowiedzi wstępnych CORS. Musi to być nieujemna liczba całkowita. Dłuższy okres pamięci podręcznej zapewnia lepszą wydajność, ale wydłuża czas, przez jaki zasady CORS muszą obowiązywać. Jeśli ta wartość nie jest ustawiona, zostanie użyty domyślny czas trwania pięciu minut.

Dozwolone aktualizacje istniejących indeksów

Tworzenie indeksu tworzy fizyczne struktury danych (pliki i odwrócone indeksy) w usłudze wyszukiwania. Po utworzeniu indeksu możliwość wprowadzania zmian przy użyciu polecenia Utwórz lub Aktualizuj indeks zależy od tego, czy modyfikacje unieważniają te struktury fizyczne. Nie można zmienić większości atrybutów pól po utworzeniu pola w indeksie.

Aby zminimalizować współczynnik zmian w kodzie aplikacji, można utworzyć alias indeksu, który służy jako stabilne odwołanie do indeksu wyszukiwania. Zamiast aktualizować kod przy użyciu nazw indeksów, możesz zaktualizować alias indeksu, aby wskazywał nowsze wersje indeksów.

Aby zminimalizować współczynnik zmian w procesie projektowania, w poniższej tabeli opisano, które elementy są stałe i elastyczne w schemacie. Zmiana stałego elementu wymaga ponownego kompilowania indeksu, natomiast elastyczne elementy można zmieniać w dowolnym momencie bez wpływu na implementację fizyczną. Aby uzyskać więcej informacji, zobacz Aktualizowanie lub ponowne kompilowanie indeksu.

Element Czy można je zaktualizować?
Nazwisko Nie.
Klucz Nie.
Nazwy i typy pól Nie.
Atrybuty pól (z możliwością wyszukiwania, filtrowanie, tworzenie aspektów, sortowanie) Nie.
Atrybut pola (możliwy do pobrania) Tak
Przechowywane (dotyczy wektorów) Nie.
Analizator Analizatory niestandardowe można dodawać i modyfikować w indeksie. W odniesieniu do przypisań analizatora w polach ciągów można modyfikować searchAnalyzertylko . Wszystkie inne przypisania i modyfikacje wymagają ponownej kompilacji.
Profile oceniania Tak
Funkcje sugestii Nie.
współużytkowanie zasobów między źródłami (CORS) Tak
Szyfrowanie Tak
Mapy synonimów Tak
Konfiguracja semantyczna Tak

Następne kroki

Skorzystaj z poniższych linków, aby dowiedzieć się więcej o wyspecjalizowanych funkcjach, które można dodać do indeksu:

Użyj tych linków do ładowania lub aktualizowania indeksu: