Szacowanie pojemności usługi wyszukiwania i zarządzanie nią

W usłudze Azure AI Search pojemność jest oparta na replikach i partycjach, które można skalować do obciążenia. Repliki to kopie aparatu wyszukiwania. Partycje to jednostki magazynu. Każda nowa usługa wyszukiwania rozpoczyna się od jednej z nich, ale można niezależnie dodawać lub usuwać repliki i partycje, aby uwzględnić zmienne obciążenia. Dodanie pojemności zwiększa koszt uruchamiania usługi wyszukiwania.

Cechy fizyczne replik i partycji, takie jak szybkość przetwarzania i operacje we/wy dysku, różnią się w zależności od warstwy usługi. W standardowej usłudze wyszukiwania repliki i partycje są szybsze i większe niż w przypadku usługi podstawowej.

Zmiana pojemności nie jest natychmiastowa. Uruchomienie lub zlikwidowanie partycji może potrwać do godziny, zwłaszcza w przypadku usług z dużą ilością danych.

Podczas skalowania usługi wyszukiwania można wybrać spośród następujących narzędzi i metod:

Pojęcia: jednostki wyszukiwania, repliki, partycje, fragmenty

Pojemność jest wyrażona w jednostkach wyszukiwania, które można przydzielić w kombinacjach partycji i replik przy użyciu podstawowego mechanizmu fragmentowania w celu obsługi elastycznych konfiguracji:

Pojęcie Definicja
Jednostka wyszukiwania Pojedyncza przyrost całkowitej dostępnej pojemności (36 jednostek). Jest to również jednostka rozliczeniowa dla usługa wyszukiwania usługi Azure AI. Do uruchomienia usługi jest wymagana co najmniej jedna jednostka.
Repliki Wystąpienia usługi wyszukiwania używane głównie do równoważenia obciążenia operacji zapytań. Każda replika hostuje jedną kopię indeksu. Jeśli przydzielasz trzy repliki, masz trzy kopie indeksu dostępne na potrzeby obsługi żądań zapytań.
Partycja Magazyn fizyczny i operacje we/wy na potrzeby operacji odczytu/zapisu (na przykład podczas ponownego kompilowania lub odświeżania indeksu). Każda partycja ma wycinek całkowitego indeksu. Jeśli przydzielasz trzy partycje, indeks jest podzielony na trzecie.
Shard Fragment indeksu. Usługa Azure AI Search dzieli każdy indeks na fragmenty, aby proces dodawania partycji był szybszy (dzięki przeniesieniu fragmentów do nowych jednostek wyszukiwania).

Na poniższym diagramie przedstawiono relację między replikami, partycjami, fragmentami i jednostkami wyszukiwania. Przedstawia przykład tego, jak pojedynczy indeks jest podzielony na cztery jednostki wyszukiwania w usłudze z dwiema replikami i dwiema partycjami. Każda z czterech jednostek wyszukiwania przechowuje tylko połowę fragmentów indeksu. Jednostki wyszukiwania w lewej kolumnie przechowują pierwszą połowę fragmentów składające się z pierwszej partycji, podczas gdy te w prawej kolumnie przechowują drugą połowę fragmentów składające się z drugiej partycji. Ponieważ istnieją dwie repliki, istnieją dwie kopie każdego fragmentu indeksu. Jednostki wyszukiwania w górnym wierszu przechowują jedną kopię składającą się z pierwszej repliki, podczas gdy te w dolnym wierszu przechowują inną kopię składającą się z drugiej repliki.

Search indexes are sharded across partitions.

Powyższy diagram jest tylko jednym przykładem. Istnieje możliwość wielu kombinacji partycji i replik, maksymalnie 36 całkowita liczba jednostek wyszukiwania.

W usłudze Azure AI Search zarządzanie fragmentami to szczegóły implementacji i niekonfigurowalne, ale wiedząc, że indeks jest podzielony na fragmenty, pomaga zrozumieć okazjonalne anomalie w zachowaniach klasyfikacji i autouzupełniania:

  • Anomalie klasyfikacji: najpierw są obliczane wyniki wyszukiwania na poziomie fragmentu, a następnie agregowane w jeden zestaw wyników. W zależności od cech zawartości fragmentów dopasowania z jednego fragmentu mogą być klasyfikowane wyżej niż dopasowania w innej. Jeśli zauważysz intuicyjne rankingi w wynikach wyszukiwania, najprawdopodobniej jest to spowodowane skutkami fragmentowania, zwłaszcza jeśli indeksy są małe. Możesz uniknąć tych anomalii w rankingu, wybierając opcję obliczania wyników globalnie w całym indeksie, ale spowoduje to naliczenie kary za wydajność.

  • Anomalie autouzupełniania: zapytania autouzupełniania, gdzie dopasowania są wykonywane na pierwszych kilku znakach częściowo wprowadzonego terminu, akceptują parametr rozmyty, który wybacza małe odchylenia pisowni. W przypadku autouzupełniania dopasowywanie rozmyte jest ograniczone do terminów w ramach bieżącego fragmentu. Jeśli na przykład fragment zawiera wartość "Microsoft" i zostanie wprowadzony częściowy termin "mikro", wyszukiwarka będzie zgodna z wartością "Microsoft" w tym fragmentze, ale nie w innych fragmentach, które przechowują pozostałe części indeksu.

Cele szacowania

Planowanie pojemności musi obejmować limity obiektów (na przykład maksymalną liczbę indeksów dozwolonych w usłudze) i limity magazynu. Warstwa usługi określa limity obiektów i magazynu. Niezależnie od tego, który limit zostanie osiągnięty jako pierwszy, jest obowiązującą granicą.

Liczby indeksów i innych obiektów są zwykle podyktowane wymaganiami biznesowymi i inżynieryjnymi. Na przykład może istnieć wiele wersji tego samego indeksu na potrzeby aktywnego programowania, testowania i produkcji.

Potrzeby magazynu są określane przez rozmiar indeksów, które mają być tworzone. Nie ma solidnych heurystyki ani uogólnień, które pomagają oszacować. Jedynym sposobem określenia rozmiaru indeksu jest utworzenie jednego. Jego rozmiar będzie oparty na zaimportowanych danych, analizie tekstu i konfiguracji indeksu, takich jak włączenie sugestorów, filtrowanie i sortowanie.

W przypadku wyszukiwania pełnotekstowego podstawowa struktura danych jest odwróconą strukturą indeksu , która ma różne cechy niż dane źródłowe. W przypadku odwróconego indeksu rozmiar i złożoność są określane przez zawartość, a niekoniecznie przez ilość danych, które są do niego wprowadzane. Duże źródło danych o wysokiej nadmiarowości może spowodować mniejszy indeks niż mniejszy zestaw danych zawierający wysoce zmienną zawartość. Dlatego rzadko można wywnioskować rozmiar indeksu na podstawie rozmiaru oryginalnego zestawu danych.

Atrybuty indeksu, takie jak włączanie filtrów i sortowania, wpływają na wymagania dotyczące magazynu. Zastosowanie sugestorów ma również wpływ na magazyn. Aby uzyskać więcej informacji, zobacz Atrybuty i rozmiar indeksu.

Uwaga

Mimo że szacowanie przyszłych potrzeb indeksów i magazynu może wydawać się jak zgadywanie, warto to zrobić. Jeśli pojemność warstwy okaże się zbyt niska, musisz aprowizować nową usługę w wyższej warstwie, a następnie ponownie załadować indeksy. Nie ma uaktualnienia usługi w miejscu z jednej warstwy do innej.

Szacowanie za pomocą warstwy Bezpłatna

Jedną z metod szacowania pojemności jest rozpoczęcie od warstwy Bezpłatna. Pamiętaj, że usługa Bezpłatna oferuje maksymalnie trzy indeksy, 50 MB miejsca do magazynowania i 2 minuty czasu indeksowania. Szacowanie przewidywanego rozmiaru indeksu przy użyciu tych ograniczeń może być trudne, ale są to kroki:

  • Utwórz bezpłatną usługę.

  • Przygotuj mały, reprezentatywny zestaw danych.

  • Utwórz indeks i załaduj dane. Jeśli zestaw danych może być hostowany w źródle danych platformy Azure obsługiwanym przez indeksatory, możesz użyć kreatora importu danych w portalu , aby utworzyć i załadować indeks. W przeciwnym razie można użyć interfejsów API REST do utworzenia indeksu i wypchnięcia danych. Model wypychania wymaga, aby dane znajdowały się w postaci dokumentów JSON, gdzie pola w dokumencie odpowiadają polam w indeksie.

  • Zbierz informacje o indeksie, takie jak rozmiar. Funkcje i atrybuty wpływają na magazyn. Na przykład dodanie sugestorów (zapytania wyszukiwania zgodnie z rzeczywistym typem) zwiększy wymagania dotyczące magazynu.

    Korzystając z tego samego zestawu danych, możesz spróbować utworzyć wiele wersji indeksu z różnymi atrybutami w każdym polu, aby zobaczyć, jak różnią się wymagania dotyczące magazynu. Aby uzyskać więcej informacji, zobacz "Implikacje dotyczące magazynu" w temacie Tworzenie podstawowego indeksu.

Z przybliżonym oszacowaniem można podwoić ten budżet dla dwóch indeksów (programowanie i produkcja), a następnie wybrać odpowiednio warstwę.

Szacowanie przy użyciu warstwy rozliczanej

Zasoby dedykowane mogą pomieścić większe czasy próbkowania i przetwarzania w celu uzyskania bardziej realistycznych oszacowań ilości indeksu, rozmiaru i woluminów zapytań podczas opracowywania. Niektórzy klienci mogą przejść bezpośrednio do warstwy rozliczanej, a następnie ponownie ocenić w miarę dojrzewania projektu programistycznego.

  1. Przejrzyj limity usług w każdej warstwie , aby określić, czy niższe warstwy mogą obsługiwać wymaganą liczbę indeksów. W warstwach Podstawowa, S1 i S2 limity indeksów to odpowiednio 15, 50 i 200. Warstwa Zoptymalizowana pod kątem magazynu ma limit 10 indeksów, ponieważ jest przeznaczona do obsługi niskiej liczby bardzo dużych indeksów.

  2. Utwórz usługę w warstwie rozliczanej:

    • Zacznij od niskiego poziomu w warstwie Podstawowa lub S1, jeśli nie masz pewności co do przewidywanego obciążenia.
    • Rozpocznij od wysokiego poziomu, przy S2 lub nawet S3, jeśli testowanie obejmuje indeksowanie na dużą skalę i obciążenia zapytań.
    • Zacznij od zoptymalizowanego pod kątem magazynu w warstwie L1 lub L2, jeśli indeksujesz dużą ilość danych i obciążenie zapytań jest stosunkowo niskie, podobnie jak w przypadku wewnętrznej aplikacji biznesowej.
  3. Skompiluj początkowy indeks , aby określić, jak dane źródłowe przekładają się na indeks. Jest to jedyny sposób oszacowania rozmiaru indeksu.

  4. Monitorowanie magazynu, limitów usług, woluminu zapytań i opóźnień w portalu. W portalu są wyświetlane zapytania na sekundę, zapytania z ograniczeniami i opóźnienie wyszukiwania. Wszystkie te wartości mogą pomóc w podjęciu decyzji, czy wybrano odpowiednią warstwę.

  5. Dodaj repliki pod kątem wysokiej dostępności lub aby ograniczyć niską wydajność zapytań.

    Nie ma żadnych wytycznych dotyczących liczby replik potrzebnych do obsługi obciążeń zapytań. Wydajność zapytań zależy od złożoności zapytania i konkurencyjnych obciążeń. Chociaż dodawanie replik wyraźnie skutkuje lepszą wydajnością, wynik nie jest ściśle liniowy: dodanie trzech replik nie gwarantuje potrójnej przepływności. Aby uzyskać wskazówki dotyczące szacowania QPS dla rozwiązania, zobacz Analizowanie zapytań dotyczących wydajnościi monitorowania.

Uwaga

Wymagania dotyczące magazynu można zawyżać, jeśli uwzględnisz dane, które nigdy nie zostaną przeszukane. Najlepiej, aby dokumenty zawierały tylko dane potrzebne do wyszukiwania. Dane binarne nie można przeszukiwać i powinny być przechowywane oddzielnie (być może w usłudze Azure Table lub Blob Storage). Następnie należy dodać pole w indeksie w celu przechowywania odwołania adresu URL do danych zewnętrznych. Maksymalny rozmiar pojedynczego dokumentu wyszukiwania wynosi 16 MB (lub mniej, jeśli zbiorczo przekazujesz wiele dokumentów w jednym żądaniu). Aby uzyskać więcej informacji, zobacz Limity usług w usłudze Azure AI Search.

Zagadnienia dotyczące woluminu zapytań

Zapytania na sekundę (QPS) to ważna metryka podczas dostrajania wydajności, ale w przypadku planowania pojemności staje się kwestią tylko wtedy, gdy na początku spodziewasz się dużego woluminu zapytań.

Warstwy Standardowa mogą zapewnić równowagę replik i partycji. Można zwiększyć zwrot zapytań, dodając repliki do równoważenia obciążenia lub dodając partycje na potrzeby przetwarzania równoległego. Następnie można dostosować wydajność po aprowizowanej usłudze.

Jeśli od samego początku spodziewasz się dużych trwałych woluminów zapytań, rozważ wyższą warstwę Standardowa, wspieraną przez bardziej zaawansowany sprzęt. Następnie można przełączyć partycje i repliki do trybu offline, a nawet przełączyć się do usługi niższej warstwy, jeśli te woluminy zapytań nie wystąpią. Aby uzyskać więcej informacji na temat obliczania przepływności zapytań, zobacz Monitorowanie zapytań.

Warstwy Zoptymalizowane pod kątem magazynu są przydatne w przypadku dużych obciążeń danych, obsługując bardziej ogólny dostępny magazyn indeksów, gdy wymagania dotyczące opóźnień zapytań są mniej ważne. Nadal należy używać dodatkowych replik do równoważenia obciążenia i dodatkowych partycji do przetwarzania równoległego. Następnie można dostosować wydajność po aprowizowanej usłudze.

Umowy dotyczące poziomu usług

Funkcje w warstwie Bezpłatna i wersja zapoznawcza nie są objęte umowami dotyczącymi poziomu usług (SLA). W przypadku wszystkich warstw rozliczanych umowy SLA obowiązują podczas aprowizowania wystarczającej nadmiarowości dla usługi. Musisz mieć co najmniej dwie repliki dla umów SLA zapytań (odczyt). Musisz mieć co najmniej trzy repliki na potrzeby umów SLA dotyczących zapytań i indeksowania (odczytu i zapisu). Liczba partycji nie ma wpływu na umowy SLA.

Wskazówki planowania pojemności

  • Zezwalaj na tworzenie metryk wokół zapytań i zbieranie danych dotyczących wzorców użycia (zapytania w godzinach pracy, indeksowanie poza godzinami szczytu). Te dane służą do informowania o decyzjach dotyczących aprowizacji usług. Chociaż nie jest to praktyczne co godzinę lub codziennie, można dynamicznie dostosowywać partycje i zasoby, aby uwzględnić planowane zmiany w woluminach zapytań. Można również pomieścić nieplanowane, ale trwałe zmiany, jeśli poziomy trzymają się wystarczająco długo, aby uzasadnić podjęcie działań.

  • Pamiętaj, że jedyną wadą aprowizacji jest to, że może być konieczne usunięcie usługi, jeśli rzeczywiste wymagania są większe niż przewidywania. Aby uniknąć przerw w działaniu usługi, należy utworzyć nową usługę w wyższej warstwie i uruchomić ją obok siebie, dopóki wszystkie aplikacje i żądania nie będą kierowane do nowego punktu końcowego.

Kiedy dodać pojemność

Początkowo usługa jest przydzielana minimalny poziom zasobów składających się z jednej partycji i jednej repliki. Wybrana warstwa określa rozmiar partycji i szybkość, a każda warstwa jest zoptymalizowana pod kątem zestawu cech pasujących do różnych scenariuszy. Jeśli wybierzesz warstwę wyższej klasy, może być potrzebna mniejsza liczba partycji niż w przypadku korzystania z warstwy S1. Jednym z pytań, na które należy odpowiedzieć za pomocą samodzielnego testowania, jest to, czy większa i droższa partycja daje lepszą wydajność niż dwie tańsze partycje w usłudze aprowizowanej w niższej warstwie.

Pojedyncza usługa musi mieć wystarczające zasoby do obsługi wszystkich obciążeń (indeksowania i zapytań). Żadne obciążenie nie jest uruchamiane w tle. Indeksowanie można zaplanować w czasie, gdy żądania zapytań są naturalnie rzadziej spotykane, ale usługa nie będzie określać priorytetu jednego zadania na innym. Ponadto pewna ilość nadmiarowości zapewnia wydajność zapytań, gdy usługi lub węzły są aktualizowane wewnętrznie.

Niektóre wskazówki dotyczące określania, czy dodać pojemność, obejmują:

  • Spełnianie kryteriów wysokiej dostępności dla umowy dotyczącej poziomu usług
  • Częstotliwość błędów HTTP 503 rośnie
  • Duże woluminy zapytań są oczekiwane

Ogólnie rzecz biorąc, aplikacje wyszukiwania zwykle potrzebują większej liczby replik niż partycji, szczególnie gdy operacje usługi są stronnicze w stosunku do obciążeń zapytań. Każda replika jest kopią indeksu, umożliwiając usłudze równoważenie obciążenia żądań względem wielu kopii. Wszystkie równoważenie obciążenia i replikacja indeksu są zarządzane przez usługę Azure AI Search i można zmienić liczbę replik przydzielonych dla usługi w dowolnym momencie. W usłudze wyszukiwania w warstwie Standardowa można przydzielić maksymalnie 12 replik i 3 repliki w usłudze wyszukiwania w warstwie Podstawowa. Alokację repliki można wykonać w witrynie Azure Portal lub w jednej z opcji programowych.

Aplikacje wyszukiwania, które wymagają odświeżania danych niemal w czasie rzeczywistym, będą potrzebować proporcjonalnie większej liczby partycji niż repliki. Dodawanie partycji rozkłada operacje odczytu/zapisu w większej liczbie zasobów obliczeniowych. Zapewnia również więcej miejsca na dysku do przechowywania dodatkowych indeksów i dokumentów.

Na koniec wykonywanie zapytań o większe indeksy trwa dłużej. W związku z tym może się okazać, że każdy przyrostowy wzrost partycji wymaga mniejszego, ale proporcjonalnego zwiększenia liczby replik. Złożoność zapytań i woluminu zapytań będzie uwzględniać szybkość wykonywania zapytań.

Uwaga

Dodanie większej liczby replik lub partycji zwiększa koszt działania usługi i może wprowadzać niewielkie różnice w sposobie porządkowenia wyników. Pamiętaj, aby sprawdzić kalkulator cen, aby zrozumieć implikacje dotyczące rozliczeń dodawania kolejnych węzłów. Na poniższym wykresie można odwoływać się krzyżowo do liczby jednostek wyszukiwania wymaganych do określonej konfiguracji. Aby uzyskać więcej informacji na temat wpływu dodatkowych replik na przetwarzanie zapytań, zobacz Porządkowanie wyników.

Dodawanie lub zmniejszanie replik i partycji

  1. Zaloguj się do witryny Azure Portal i wybierz usługę wyszukiwania.

  2. W obszarze Ustawienia otwórz stronę Skalowanie, aby zmodyfikować repliki i partycje.

    Poniższy zrzut ekranu przedstawia aprowizację w warstwie Podstawowa w warstwie Standardowa z jedną repliką i partycją. Formuła u dołu wskazuje liczbę używanych jednostek wyszukiwania (1). Jeśli cena jednostkowa wynosiła 100 USD (a nie rzeczywista cena), miesięczny koszt działania tej usługi wyniesie średnio 100 USD.

    Scale page showing current values

  3. Użyj suwaka, aby zwiększyć lub zmniejszyć liczbę partycji. Wybierz pozycję Zapisz.

    W tym przykładzie dodano drugą replikę i partycję. Zwróć uwagę na liczbę jednostek wyszukiwania; Jest to teraz cztery, ponieważ formuła rozliczeń jest replikami pomnożonymi przez partycje (2 x 2). Podwojenie pojemności ponad dwukrotnie zwiększa koszt działania usługi. Jeśli koszt jednostki wyszukiwania wynosił 100 USD, nowy miesięczny rachunek będzie teraz wynosić 400 USD.

    W przypadku bieżących kosztów jednostkowych każdej warstwy odwiedź stronę Cennik.

    Add replicas and partitions

  4. Po zapisaniu możesz sprawdzić powiadomienia, aby potwierdzić, że akcja zakończyła się pomyślnie.

    Save changes

    Zmiany pojemności mogą potrwać od 15 minut do kilku godzin. Nie można anulować po rozpoczęciu procesu i nie ma monitorowania w czasie rzeczywistym na potrzeby korekt repliki i partycji. Jednak następujący komunikat pozostaje widoczny, gdy zmiany są w toku.

    Status message in the portal

Uwaga

Po aprowizacji usługi nie można jej uaktualnić do wyższej warstwy. Musisz utworzyć usługę wyszukiwania w nowej warstwie i ponownie załadować indeksy. Aby uzyskać pomoc dotyczącą aprowizacji usług, zobacz Tworzenie usługa wyszukiwania usługi Azure AI w portalu.

Sposób obsługi żądań skalowania

Po otrzymaniu żądania skalowania usługa wyszukiwania:

  1. Sprawdza, czy żądanie jest prawidłowe.
  2. Rozpoczyna tworzenie kopii zapasowych danych i informacji systemowych.
  3. Sprawdza, czy usługa jest już w stanie aprowizacji (obecnie dodawanie lub eliminowanie replik lub partycji).
  4. Rozpoczyna aprowizację.

Skalowanie usługi może potrwać nawet 15 minut lub nieco ponad godzinę, w zależności od rozmiaru usługi i zakresu żądania. Tworzenie kopii zapasowej może potrwać kilka minut, w zależności od ilości danych i liczby partycji i replik.

Powyższe kroki nie są całkowicie kolejne. Na przykład system rozpoczyna aprowizację, gdy można to bezpiecznie zrobić, co może być możliwe podczas tworzenia kopii zapasowej.

Błędy podczas skalowania

Komunikat o błędzie "Operacje aktualizacji usługi nie są obecnie dozwolone, ponieważ przetwarzamy poprzednie żądanie" jest spowodowane powtarzaniem żądania skalowania w dół lub w górę, gdy usługa przetwarza już poprzednie żądanie.

Rozwiąż ten błąd, sprawdzając stan usługi, aby zweryfikować stan aprowizacji:

  1. Aby uzyskać stan usługi, użyj interfejsu API REST zarządzania, programu Azure PowerShell lub interfejsu wiersza polecenia platformy Azure.
  2. Wywołaj metodę Get Service (REST) lub równoważną dla programu PowerShell lub interfejsu wiersza polecenia.
  3. Sprawdź odpowiedź na "provisioningState": "provisioning"

Jeśli stan to "Aprowizowanie", poczekaj na ukończenie żądania. Stan powinien mieć wartość "Powodzenie" lub "Niepowodzenie", zanim zostanie podjęta inna próba. Brak stanu kopii zapasowej. Kopia zapasowa jest operacją wewnętrzną i jest mało prawdopodobne, aby była czynnikiem w każdym ćwiczeniu skalowania.

Jeśli usługa wyszukiwania wydaje się być zatrzymana w stanie aprowizacji, sprawdź, czy indeksy oddzielone są bezużyteczne, z zerowymi woluminami zapytań i bez aktualizacji indeksu. Indeks bezużyteczny może blokować zmiany pojemności usługi. W szczególności poszukaj indeksów zaszyfrowanych za pomocą klucza cmK, których klucze nie są już prawidłowe. Należy usunąć indeks lub przywrócić klucze, aby przywrócić indeks w tryb online i odblokować operację skalowania.

Kombinacje partycji i repliki

Usługa Podstawowa może mieć dokładnie jedną partycję i maksymalnie trzy repliki dla maksymalnego limitu trzech jednostek jednostki SU. Jedynym regulowanym zasobem są repliki. Do zapewnienia wysokiej dostępności zapytań potrzebna jest co najmniej dwie repliki.

Wszystkie usługi wyszukiwania zoptymalizowane pod kątem warstwy Standardowa i magazynu mogą zakładać następujące kombinacje replik i partycji, z zastrzeżeniem limitu 36 jednostek SU dozwolonych dla tych warstw.

1 partycja 2 partycje 3 partycje 4 partycje 6 partycji 12 partycji
1 replika 1 SU 2 SU 3 SU 4 SU 6 SU 12 SU
2 repliki 2 SU 4 SU 6 SU 8 SU 12 SU 24 SU
3 repliki 3 SU 6 SU 9 SU 12 SU 18 SU 36 SU
4 repliki 4 SU 8 SU 12 SU 16 SU 24 SU Nie dotyczy
5 replik 5 SU 10 SU 15 jednostek jednostki organizacyjnej 20 SU 30 SU Nie dotyczy
6 replik 6 SU 12 SU 18 SU 24 SU 36 SU Nie dotyczy
12 replik 12 SU 24 SU 36 SU Brak NIE DOTYCZY Brak

Jednostki SU, ceny i pojemność zostały szczegółowo wyjaśnione w witrynie internetowej platformy Azure. Aby uzyskać więcej informacji, zobacz Szczegóły cennika.

Uwaga

Liczba replik i partycji dzieli się równomiernie na 12 (w szczególności 1, 2, 3, 4, 6, 12). Usługa Azure AI Search wstępnie dzieli każdy indeks na 12 fragmentów, dzięki czemu może być rozłożona w równych częściach we wszystkich partycjach. Jeśli na przykład usługa ma trzy partycje i tworzysz indeks, każda partycja będzie zawierać cztery fragmenty indeksu. Jak usługa Azure AI Search fragmentuje indeks, to szczegóły implementacji, które mogą ulec zmianie w przyszłych wersjach. Chociaż liczba wynosi 12 dzisiaj, nie należy oczekiwać, że ta liczba będzie zawsze wynosić 12 w przyszłości.

Następne kroki