Schätzen und Verwalten der Kapazität eines Suchdiensts

Azure KI-Suche bietet zwei Preismodelle, die die Kapazität unterschiedlich verarbeiten:

  • Dediziert: Planen Sie die Kapazität, indem Sie Replikate und Partitionen skalieren und eine Dienstebene auswählen.

    • Stellen Sie die Kapazität direkt im Voraus mithilfe von Replikaten und Partitionen bereit.
    • Schätzen Sie den erforderlichen Speicher (Partitionen) und den erforderlichen Durchsatz (Replikate).
    • Wählen Sie eine Dienstebene aus, um die erforderliche Kapazität basierend auf der erwarteten Spitzennachfrage bereitzustellen.
    • Nachdem Sie die Kapazität vorab konfiguriert haben, zahlen Sie unabhängig von der Nutzung eine stündliche Rate, die von Sucheinheiten (SUs) gemessen wird.

  • Serverless (Vorschau):Der Dienst verwaltet die Kapazität automatisch basierend auf Nutzungs- und Dienstgrenzwerten. Sie müssen keine Kapazität vorab bereitstellen. Optimieren Sie stattdessen Ihre Arbeitsauslastungseffizienz, um Kosten zu verwalten.

    • Die Kapazität skaliert automatisch mit Bedarf (kann beim Leerlauf auf Null skaliert werden).
    • Sie werden basierend auf der tatsächlichen Nutzung berechnet, die von Compute Units (CUs) und Speicher gemessen wird.
    • Anstelle der Infrastruktur konzentriert sich die Planung auf diese Kostentreiber: Abfragemuster, Indexgröße und -wachstum sowie Datenaufnahmemuster. Siehe Optimieren der Kosten für das Serverless-Modell.
Dimension Dedicated Serverlos
Kapazitätsmodell Bereitgestellt (Replikate × Partitionen) Verbrauchsbasiert
Scaling Manuell Automatisch
Benutzersteuerung Explizit (Konfigurieren von Replikaten und Partitionen) Indirekt (beeinflusst durch Arbeitsauslastungsmerkmale)
Abrechnung Fester Stundensatz je Sucheinheit (SU) Verbrauchsbasierte Zahlungen für Compute Units (CUs) und Speicher
Leerlaufkosten Fallen immer an (mindestens bereitgestellte Kapazität) Skaliert beim Leerlauf auf Null
Optimierungsfokus Infrastrukturgröße Arbeitsauslastungseffizienz
Am besten geeignet für: Vorhersehbare, stabile Workloads Variable, spitzenlastige oder mandantenfähige Workloads, einschließlich agentengesteuerter Szenarien
Kapazitätsplanungsansatz Größe und Skalierungsinfrastruktur (Replikate und Partitionen) Optimieren der Arbeitsauslastungseffizienz und Nutzungsmuster
Auswirkungen auf die Ineffizienz Latenz und Skalierungsdruck Direkte Kostenerhöhung

Important

Der serverlose Entwicklertarif ist derzeit als Vorschau verfügbar. Diese Vorschau wird ohne Vereinbarung auf Serviceebene bereitgestellt und wird für Produktionsworkloads nicht empfohlen. Manche Features werden möglicherweise nicht unterstützt oder sind nur eingeschränkt verwendbar. Weitere Informationen finden Sie unter Supplementale Nutzungsbedingungen für Microsoft Azure Previews.

Die Abrechnung für die Serverless Developer-Stufe ist während der Vorschau noch nicht aktiviert. Geschätzte Kosten für Ihre Nutzung sind im Azure Portal und telemetrie verfügbar, diese Nutzung wird jedoch während dieses anfänglichen Zeitraums nicht auf Ihrer Azure Rechnung angezeigt. Microsoft stellen mindestens 30 Tage vor Beginn der Abrechnung eine Benachrichtigung zur Verfügung. Die Verzögerung der Abrechnung während dieser Vorschau ist temporär. Serverless Developer ist eine kostenpflichtige Stufe, und Sie sind für alle Gebühren verantwortlich, die nach Beginn der Abrechnung anfallen.

Die Serverless Developer-Stufe unterstützt keine Migration zu oder von anderen Preisstufen, und einige Features, die auf anderen Ebenen verfügbar sind, werden während der öffentlichen Vorschau nicht unterstützt. Servicelimits, unterstützte Features und Preisdetails können sich vor der allgemeinen Verfügbarkeit ändern.

Die Vorschau ist derzeit nur im westlichen Zentralteil der USA, in der Schweiz Nord und in Japan Ost verfügbar.

Weitere Informationen finden Sie unter:

Planen der Kapazität für das dedizierte Modell

Im dedizierten Modell stellen Sie Kapazität mithilfe von Sucheinheiten (SU) bereit:

  • Sucheinheit (SU) = Replikate × Partitionen
  • Replikat: Kopien der Suchmaschine. Stellt den Abfragedurchsatz und hohe Verfügbarkeit bereit.
  • Partition: Speichereinheiten. Stellt Speicher- und Indizierungsdurchsatz bereit.

Jeder Dienst beginnt mit 1 Replikat × 1 Partition (1 SU). Sie können Replikate und Partitionen unabhängig voneinander hinzufügen oder entfernen, um schwankende Workloads zu berücksichtigen. Durch das Hinzufügen von Kapazität wird die Kosten für die Ausführung eines Suchdienstserhöht.

Konzept Definition
Sucheinheit Eine einzige Inkrementierung der gesamt verfügbaren Kapazität. Mindestens eine Sucheinheit ist erforderlich, um den Dienst auszuführen. Je nach Preisniveau reichen die maximalen Bereiche von 1 bis 36 Einheiten.

Die Anzahl der Sucheinheiten entspricht der Anzahl der Replikate, die mit der Anzahl der Partitionen multipliziert werden: R × P = SU. Jeder Dienst beginnt mit einem Replikat und einer Partition, die eine Einheit verbraucht: 1 × 1 = 1. Das Hinzufügen eines zweiten Replikats verbraucht zwei Einheiten: 2 × 1 = 2.

Eine Sucheinheit ist auch die Abrechnungseinheit für einen Suchdienst.
Replikat Replikate sind Instanzen des Suchdiensts und dienen in erster Linie zum Lastenausgleich bei Abfragevorgängen. Jedes Replikat hostet eine Kopie eines Indexes. Wenn Sie drei Replikate zuordnen, stehen Ihnen drei Kopien eines Indexes für die Bearbeitung von Abfrageanforderungen zur Verfügung.
Partition Physischer Speicher und E/A für Lese-/Schreibvorgänge (z. B. bei der Neuerstellung oder Aktualisierung eines Index). Jede Partition hat einen Anteil am Gesamtindex. Wenn Sie drei Partitionen zuordnen, wird Ihr Index in Drittel aufgeteilt.

In der Tabelle Partitions- und Replikatskombinationen finden Sie mögliche Kombinationen, die unter der Grenze von 36 Einheiten bleiben.

Die physischen Merkmale von Replikaten und Partitionen, z. B. Verarbeitungsgeschwindigkeit und Datenträger-E/A, variieren je nach Dienstebene. Bei einem standardmäßigen Suchdienst sind die Replikate und Partitionen schneller und größer als die eines grundlegenden Diensts.

Zeitpunkt für das Hinzufügen von Kapazität für das dedizierte Modell

Erwägen Sie, Replikate oder Partitionen hinzuzufügen, wenn:

  • Die Abfragelatenz steigt, oder die Kriterien des Service-Level-Agreements werden nicht erfüllt.
  • Die Häufigkeit von HTTP 503 -Fehlern (Dienst nicht verfügbar) erhöht sich.
  • Die Häufigkeit von HTTP-429-Fehlern („Zu viele Anfragen“) nimmt zu, was auf eine Drosselung von Anfragen hindeutet.
  • Es werden große Abfragevolumina erwartet.
  • Indizierungsaufträge sind langsam oder geraten in Verzug.
  • Der Speicher- oder Indizierungsdurchsatz ist nicht ausreichend.

Skalierungsleitfaden:

  • Fügen Sie Replikate hinzu, um den Abfragedurchsatz und die Verfügbarkeit zu erhöhen.
  • Fügen Sie Partitionen hinzu, um die Speicher- und Indizierungsleistung zu erhöhen.
  • Abfragelasten erfordern in der Regel mehr Replikate.
  • Große Indizes erfordern möglicherweise zusätzliche Replikate, um die Leistung aufrechtzuerhalten.

Important

Skalierungsvorgänge können einige Zeit in Anspruch nehmen und die Kosten erhöhen. Überprüfen Sie Immer Änderungen mithilfe von Leistungstests und Preisschätzungen.

Die von Ihnen ausgewählte Dienstebene bestimmt die Partitionsgröße und -geschwindigkeit. Jede Ebene ist um eine Reihe von Merkmalen optimiert, die verschiedenen Szenarien entsprechen. Wenn Sie sich für einen höherwertigen Tarif entscheiden, benötigen Sie möglicherweise weniger Partitionen als bei S1. Eine der Fragen, die Sie durch selbstgesteuerte Tests beantworten müssen, lautet: Bringt eine größere und teurere Partition eine bessere Leistung als zwei billigere Partitionen bei einem Dienst, der in einem niedrigeren Tarif bereitgestellt wird?

Ein einzelner Dienst muss über genügend Ressourcen verfügen, um sämtliche Workloads (Indizierung und Abfragen) bewältigen zu können. Beide Workloads laufen nicht im Hintergrund. Sie können die Indizierung für Zeiten planen, in denen Abfrageanforderungen naturgemäß weniger häufig sind, aber der Dienst priorisiert ansonsten keine Aufgabe gegenüber einer anderen. Zusätzlich gleicht ein gewisses Maß an Redundanz die Abfrageleistung aus, wenn Dienste oder Knoten intern aktualisiert werden.

Allgemein gilt: Suchanwendungen benötigen in der Regel mehr Replikate als Partitionen – insbesondere, wenn die Dienstvorgänge auf Abfrageworkloads ausgerichtet sind. Jedes Replikat ist eine Kopie Ihres Indexes, sodass der Dienst Lastenausgleichsanforderungen für mehrere Kopien ausführen kann. Azure KI-Suche verwaltet den gesamten Lastenausgleich und die Replikation eines Indexes. Sie können die Anzahl der für Ihren Dienst zugewiesenen Replikate jederzeit ändern. In einem Suchdienst mit Tarif „Standard“ können Sie bis zu 12 Replikate zuordnen, im Tarif „Basic“ bis zu drei. Sie können die Replikatzuordnung entweder über das Azure-Portal oder über eine der programmgesteuerten Optionen vornehmen.

Zusätzliche Partitionen sind hilfreich für intensive Indizierungsworkloads. Zusätzliche Partitionen verteilen Lese- und Schreibvorgänge über eine größere Anzahl von Computeressourcen.

Schließlich erfordern größere Indizes eine längere Abfragezeit. Daher werden Sie feststellen, dass jede inkrementelle Zunahme an Partitionen einen kleineren, aber proportionalen Anstieg der Replikate erforderlich macht. Die Komplexität Ihrer Abfragen und das Abfragevolumen haben darauf Einfluss, wie schnell die Abfrage ausgeführt wird.

Informationen zu Dienstgrenzwerten und gültigen Skalierungsbereichen finden Sie unter:

Hinweis

Wenn Sie weitere Replikate oder Partitionen hinzufügen, erhöhen sich die Kosten für die Ausführung des Diensts. Außerdem kann die Sortierung der Ergebnisse leicht variieren. Sie sollten daher den Preisrechner verwenden, um die Auswirkungen des Hinzufügens weiterer Knoten auf die Abrechnung zu verstehen. Mithilfe der Tabelle mit Partitions- und Replikatkombinationen können Sie die Anzahl der Sucheinheiten nachschlagen, die für eine bestimmte Konfiguration erforderlich ist. Weitere Informationen dazu, wie sich zusätzliche Replikate auf die Abfrageverarbeitung auswirken, finden Sie unter Sortieren von Ergebnissen.

So verwalten und passen Sie die Kapazität an

Wenn die Kapazität geändert wird, ist dies nicht sofort wirksam. Je nach Datenvolumen und Vorgangstyp kann die Skalierung zwischen Minuten und mehreren Stunden dauern.

Beim Skalieren eines Suchdiensts können Sie zwischen den folgenden Tools und Ansätzen wählen:

Hinweis

Wenn Ihr Suchdienst vor April oder Mai 2024 erstellt wurde, ist er möglicherweise für ein einmaliges Upgrade auf eine neuere Infrastruktur mit größeren Partitionsgrößen ohne zusätzliche Kosten berechtigt. Dieses Upgrade kann den verfügbaren Speicher pro Partition erhöhen und die Anzahl der Partitionen verringern, die für Ihre Workload erforderlich sind. Weitere Informationen finden Sie unter Upgrade Ihres Suchdiensts.

Um die Kapazität Ihres Diensts zu erhöhen oder zu verringern, haben Sie zwei Möglichkeiten:

Hinzufügen oder Entfernen von Partitionen und Replikaten

  1. Wechseln Sie zum Suchdienst im Azure-Portal.

  2. Wählen Sie im linken Bereich Einstellungen>Skalieren aus.

    Der folgende Screenshot zeigt einen Standarddienst, der mit einem Replikat und einer Partition bereitgestellt wurde. Die Formel im unteren Bereich gibt an, wie viele Sucheinheiten verwendet werden (1). Wenn der Preis pro Einheit 100 US-Dollar wäre (kein echter Preis), würden die monatlichen Kosten für die Ausführung dieses Diensts durchschnittlich 100 US-Dollar betragen.

    Screenshot: Die Seite „Skalierung“ mit den aktuellen Replikat- und Partitionswerten

  3. Verwenden Sie den Schieberegler, um die Anzahl der Partitionen zu erhöhen oder zu verringern, und wählen Sie dann Speichern aus.

    In diesem Beispiel werden ein zweites Replikat und eine zweite Partition hinzugefügt. Beachten Sie die Anzahl der Sucheinheiten. Sie beträgt jetzt vier, weil die Formel für die Abrechnung lautet: Replikate multipliziert mit Partitionen (2 x 2). Bei einer Verdopplung der Kapazität fallen mehr als doppelt so hohe Kosten für die Ausführung des Diensts an. Wenn die Kosten für die Sucheinheit 100 US-Dollar wären, würde die neue Monatsrechnung jetzt 400 US-Dollar betragen.

    Wenn Sie die aktuellen Kosten pro Einheit für die einzelnen Tarife erfahren möchten, besuchen Sie die Seite mit der Preisübersicht.

    Screenshot der Seite „Skalieren“ mit hinzugefügten Replikaten und Partitionen.

  4. Überprüfen Sie Ihre Benachrichtigungen, um zu bestätigen, dass der Vorgang gestartet wurde.

    Screenshot der Benachrichtigung über den Skalierungsvorgang im Azure portal.

    Dieser Vorgang kann mehrere Stunden dauern. Sie tritt im Hintergrund auf, sodass Ihr Suchdienst vollständig betriebsbereit bleibt und für Lese- und Schreibvorgänge verfügbar ist.

    Sie können den Vorgang nicht abbrechen oder den Fortschritt überwachen. Die folgende Meldung wird jedoch angezeigt, während Änderungen ausgeführt werden.

    Screenshot der Aktualisierungsnachricht im Azure portal.

Ändern des Tarifs

Hinweis

Das Azure Portal und Services - Update (REST API) unterstützen Änderungen zwischen den Ebenen "Basic" und "Standard" (S1, S2 und S3). Sie können Tarife hoch- oder herabstufen, vorausgesetzt, Ihre aktuelle Dienstkonfiguration überschreitet nicht die Grenzwerte des Zieltarifs. Ihre Region darf auch keine Kapazitätsbeschränkungen auf dem Zieltarif haben.

Ihr Preisniveau bestimmt den maximalen Speicher Ihres Suchdiensts für das dedizierte Preismodell. Wenn Sie mehr oder weniger Kapazität benötigen, können Sie zu einem anderen Tarif wechseln, der Ihren Speicheranforderungen entspricht. (Dies gilt nur für die Stufen des dedizierten Preismodells. Die Entwicklerebene des Serverless-Modells kann nicht mehr geändert werden, nachdem sie ausgewählt wurde).

Neben der Kapazität bestimmen Tarife auch Grenzwerte für Indizes, Indexer und andere Suchobjekte. Vergleichen Sie die Dienstgrenzwerte Ihres aktuellen Tarifs und dem gewünschten Tarif, bevor Sie fortfahren. Im Allgemeinen erhöht der Wechsel zu einem höheren Tarif das Speicherlimit und die Vektorgrenze sowie den Anforderungsdurchsatz und verringert die Latenz, während der Wechsel zu einem niedrigeren Tarif den gegenteiligen Effekt hat.

Der Wechsel zu einem höheren Tarif erhöht auch die Kosten für die Ausführung Ihres Suchdiensts. Weitere Informationen hierzu finden Sie in der Preisübersicht.

So ändern Sie Ihren Tarif:

  1. Wechseln Sie zum Suchdienst im Azure-Portal.

  2. Wählen Sie im linken Bereich Einstellungen>Skalieren aus.

  3. Wählen Sie unter Ihrem aktuellen Tarif Tarif ändern aus.

    Screenshot der Schaltfläche

  4. Wählen Sie auf der Seite Tarif auswählen einen anderen Tarif aus der Liste aus.

    Sie können zwischen Basic, S1, S2 und S3 wechseln, aber Sie können nicht zu "Free", "S3HD", "L1" oder "L2" wechseln. Diese Ebenen sind nicht auswählbar und werden abgeblendet angezeigt.

    Screenshot der Seite

  5. Um den Skalierungsvorgang zu starten, wählen Sie Speichern aus.

    Screenshot der Schaltfläche

    Dieser Vorgang kann mehrere Stunden dauern. Sie tritt im Hintergrund auf, sodass Ihr Suchdienst vollständig betriebsbereit bleibt und für Lese- und Schreibvorgänge verfügbar ist.

    Sie können den Vorgang nicht abbrechen oder den Fortschritt überwachen. Die folgende Meldung wird jedoch angezeigt, während Änderungen ausgeführt werden.

    Screenshot der Aktualisierungsnachricht im Azure portal.

Wie Skalierungsanforderungen für das dedizierte Modell behandelt werden

Wenn der Suchdienst eine Skalierungsanforderung empfängt, lautet dies:

  1. Er überprüft, ob die Anforderung gültig ist.
  2. Er beginnt mit der Sicherung von Daten und Systeminformationen.
  3. Er überprüft, ob sich der Dienst bereits in einem Bereitstellungsstatus befindet (aktive Vorgänge zum Hinzufügen oder Entfernen von Replikaten oder Partitionen).
  4. Er startet den Bereitstellungsvorgang.

Die Skalierung eines Diensts kann mehrere Minuten bis zu mehreren Stunden dauern, je nach Größe des Diensts und Umfang der Anforderung. Die Sicherungsdauer variiert auch je nach Datenmenge und Anzahl von Partitionen und Replikaten.

Die vorstehenden Schritte sind nicht vollständig aufeinander folgenden. Das System beginnt beispielsweise erst mit der Bereitstellung, wenn dieser Vorgang auf sichere Weise möglich ist, und dies kann auch gegen Ende des Sicherungsvorgangs der Fall sein.

Fehler während der Skalierung

In der folgenden Tabelle sind Ursachen und Lösungen für Fehler aufgeführt, die bei Skalierungsvorgängen auftreten können.

Fehlermeldung Ursache Lösung
„Dienstaktualisierungsvorgänge sind derzeit nicht zulässig, da wir eine vorherige Anforderung verarbeiten.“ Ein weiterer Skalierungsvorgang wird ausgeführt. Überprüfen Sie die Seite Overview im Azure-Portal, oder verwenden Sie die REST-API Search Management REST API, Azure PowerShell oder Azure CLI um den Status Ihres Suchdiensts zu erhalten. Wenn der Status „Wird bereitgestellt“ lautet, warten Sie, bis der Status „Erfolgreich“ oder „Fehlgeschlagen“ wird, bevor Sie den Vorgang erneut versuchen. 1, 2
„Der Suchdienstname konnte nicht skaliert werden. Fehler: Die Objektanzahl ActualCount überschreitet den zulässigen Grenzwert von MaximumCount.“ Ihre aktuelle Dienstkonfiguration überschreitet die Grenzwerte des Zieltarifs. Überprüfen Sie, ob Ihre Speichernutzung, Vektornutzung, Indizes, Indexer und andere Objekte in die Dienstgrenzwerte der niedrigeren Tarife passen. Die Stufe „Basic“ unterstützt beispielsweise bis zu 15 Indizes, sodass Sie nicht von „S1“ zu „Basic“ wechseln können, wenn Sie über 16 Indizes verfügen. Passen Sie Ihre Ressourcen an, bevor Sie es erneut versuchen.

1 Es gibt keinen Status für Sicherungen, bei denen es sich um interne Vorgänge handelt, die eine Skalierungsübung wahrscheinlich nicht stören.

2 Wenn Ihr Suchdienst in einem Bereitstellungsstatus angehalten wird, überprüfen Sie, ob es verwaiste Indizes gibt, die nicht verwendet werden können, mit null Abfragevolumes und ohne Indexaktualisierungen. Ein nicht verwendbarer Index kann Änderungen an der Dienstkapazität blockieren. Suchen Sie insbesondere nach CMK-verschlüsselten Indizes, deren Schlüssel nicht mehr gültig sind. Löschen Sie entweder den Index, oder stellen Sie die Schlüssel wieder her, um den Index wieder online zu schalten und die Blockierung des Skalierungsvorgangs aufzuheben.

Partitions- und Replikatskombinationen

Das folgende Diagramm gilt für die Standardebene und höher. Es zeigt alle möglichen Kombinationen von Partitionen und Replikaten, vorbehaltlich der Höchstzahl von 36 Sucheinheiten pro Dienst.

1 Partition 2 Partitionen 3 Partitionen 4 Partitionen 6 Partitionen 12 Partitionen
1 Replikat: 1 SU 2 SU 3 SU 4 SU 6 SU 12 SU
2 Replikate 2 SU 4 SU 6 SU 8 SU 12 SU 24 SU
3 Replikate 3 SU 6 SU 9 SU 12 SU 18 SU 36 SU
4 Replikate 4 SU 8 SU 12 SU 16 SU 24 SU –
5 Replikate 5 SU 10 SU 15 SU 20 SU 30 SU –
6 Replikate 6 SU 12 SU 18 SU 24 SU 36 SU –
12 Replikate 12 SU 24 SU 36 SU – – –

Bei Suchdiensten im Basic-Tarif gelten niedrigere Anzahlen für Sucheinheiten.

  • Bei Suchdiensten, die vor dem 3. April 2024 erstellt wurden, können Basic-Dienste genau eine Partition und bis zu drei Replikate aufweisen, um einen maximalen Grenzwert von drei SUs einzuhalten. Nur die Replikate können angepasst werden. Möglicherweise können Sie die Partitionsanzahl jedoch erhöhen, indem Sie Ihren Dienst aktualisieren.

  • Bei Suchdiensten, die nach dem 3. April 2024 in unterstützten Regionen erstellt wurden, können Basic-Dienste bis zu drei Partitionen und drei Replikate aufweisen. Der maximale SU-Grenzwert beträgt neun, um eine vollständige Ergänzung von Partitionen und Replikaten zu unterstützen.

Für Suchdienste auf einer beliebigen abrechnenden Ebene benötigen Sie unabhängig vom Erstellungsdatum mindestens zwei Replikate für hohe Verfügbarkeit bei Abfragen.

Die Abrechnungsraten pro Stufe und Währung finden Sie auf der Seite Azure KI-Suche Preise.

Kapazität anhand einer dedizierten Tarifstufe des Preismodells schätzen

Ihre Speicheranforderungen hängen von der Größe der Indizes ab, die Sie erstellen möchten. Es gibt keine soliden Heuristiken oder allgemeinen Richtlinien, die bei Schätzungen helfen. Die einzige Möglichkeit, die Größe eines Indexes zu ermitteln, besteht darin, einen zu erstellen. Die Größe hängt von der Tokenisierung und Einbettung ab und unabhängig davon, ob Sie Suggester, Filter und Sortierung aktivieren oder die Vektorkomprimierung nutzen können.

Schätzen Sie die Kapazität einer abrechnungsfähigen Ebene, "Einfach" oder höher. Der Free-Tarif wird auf physischen Ressourcen ausgeführt, die von mehreren Kunden gemeinsam genutzt werden, und unterliegt Faktoren, die sich Ihrer Kontrolle entziehen. Nur die dedizierten Ressourcen eines abrechenbaren Suchdiensts ermöglichen längere Sampling- und Verarbeitungszeiten und eignen sich besser für realistische Schätzungen bezüglich Indexmenge, Größe und Abfragevolumen während der Entwicklung.

  1. Überprüfen Sie die Dienstgrenzwerte in jedem Tarif, um festzustellen, ob niedrigere Tarife die Anzahl der benötigten Indizes unterstützen können. Überlegen Sie, ob Sie mehrere Kopien eines Indexes für aktive Entwicklung, Tests und Produktion benötigen.

    Ein Suchdienst unterliegt Objektgrenzwerten (maximale Anzahl von Indizes, Indexern, Skillsets usw.) und Speichergrenzwerten. Der Grenzwert, der zuerst erreicht wird, ist jeweils der effektive Grenzwert.

  2. Erstellen Sie einen Dienst unter einem kostenpflichtigen Tarif. Dienstebenen sind für bestimmte Workloads optimiert. Beispielsweise ist der Tarif „Datenspeicheroptimiert“ auf zehn Indizes beschränkt, da er für eine geringe Anzahl sehr großer Indizes ausgelegt ist.

    • Beginnen Sie mit einem niedrigen Tarif, z. B. „Basic“ oder „S1“, wenn Sie sich über die projizierte Last nicht sicher sind.

    • Starten Sie hoch, mit „S2“ oder sogar „S3“, wenn Tests umfangreiche Indizierungs- und Abfrageworkloads enthalten.

    • Beginnen Sie mit einem Tarif vom Typ „Speicheroptimiert“ („L1“ oder „L2“), wenn Sie sehr viele Daten indizieren möchten und die Abfragelast relativ gering ist (etwa im Fall einer internen Geschäftsanwendung).

  3. Erstellen Sie einen anfänglichen Index, um zu bestimmen, wie Quelldaten in einen Index übersetzt werden. Dies ist die einzige Möglichkeit, die Größe des Indexes zu schätzen. Attribute für die Felddefinitionen wirken sich auf Anforderungen an den physischen Speicher aus:

  4. Monitor-Speicher, Dienstbeschränkungen, Abfragevolume und Latenz im Azure-Portal. Das Azure-Portal zeigt Abfragen pro Sekunde, gedrosselte Abfragen und Suchlatenz an. Anhand dieser Werte können Sie entscheiden, ob Sie die richtige Stufe ausgewählt haben.

  5. Fügen Sie Replikate für hohe Verfügbarkeit hinzu, oder verringern Sie die Abfrageleistung.

    Es gibt keine Richtlinien zur Anzahl der Replikate, die für bestimmte Abfragelasten benötigt werden. Die Abfrageleistung hängt von der Komplexität der Abfrage und den konkurrierenden Workloads ab. Obwohl das Hinzufügen von Replikaten die Leistung deutlich erhöht, ist das Endergebnis nicht streng linear: Das Hinzufügen von 3 Replikaten garantiert keinen dreifachen Durchsatz. Anleitungen zur Schätzung von QPS für Ihre Lösung finden Sie unter Analysieren von Leistungs - und Überwachungsabfragen.

Bei einem invertierten Index werden Größe und Komplexität vom Inhalt bestimmt, nicht notwendigerweise von der Menge der Daten, die Sie eingeben. Eine große Datenquelle mit hoher Redundanz könnte einen kleineren Index ergeben als ein kleineres Dataset mit stark variierendem Inhalt. Daher ist es kaum möglich, die Indexgröße aus der Größe des ursprünglichen Datasets abzuleiten.

Speicheranforderungen können aufgeblasen werden, wenn Sie Daten einschließen, die Sie nie durchsuchen. Im Idealfall enthalten Dokumente nur die Daten, die Sie für die Suche benötigen.

Überlegungen zur Vereinbarung zum Servicelevel

Vereinbarungen auf Serviceebene (SERVICE Level Agreements, SLAs) beziehen sich nicht auf die Features "Kostenlos" und "Vorschau". Für alle abrechenbaren Tarife gelten SLAs, wenn Sie genügend Redundanz für Ihren Dienst bereitstellen.

  • Mindestens zwei Replikate erfüllen Abfrage-SLAs (lesen).

  • Mindestens drei Replikate erfüllen Abfrage- und Indizierungs-SLAs (lesen/schreiben).

Die Anzahl der Partitionen hat keine Auswirkungen auf die SLAs.

Optimieren der Kosten für das Serverless-Modell

Im Serverless-Preismodell:

  • Der Dienst verwaltet die Kapazität automatisch.
  • Replikate, Partitionen oder Sucheinheiten müssen nicht konfiguriert werden.
  • Die Rechenressourcen skalieren dynamisch je nach Workload (Abfrage- und Indizierungsanforderungen) und können bei Inaktivität auf null herunterskaliert werden.

Weitere Informationen zu Einschränkungen für das Serverless-Modell finden Sie unter Dienstgrenzwerte.

Die Abrechnung basiert auf zwei Dimensionen:

  • Computeauslastung (CUs): Abgerechnet auf Grundlage von Abfrage- und Indizierungsvorgängen.
  • Indizierter Speicher: Pro GB pro Monat berechnet.

Da die Abrechnung verbrauchsbasiert ist, sind die Kosten direkt an die Nutzung gebunden:

  • Komplexe Abfragen verbrauchen mehr Compute.
  • Ineffizienter Schemaentwurf erhöht sowohl die Indizierung als auch die Abfragekosten.
  • Schlechte Abfragemuster mit großen oder häufig aktualisierten Indizes erhöhen die Speicher- und Computenutzung.

Optimieren der Arbeitsauslastungseffizienz

Da die Ineffizienz im Serverless-Modell als Kosten angezeigt wird, zahlen Sie mehr für dieselbe Arbeit, wenn Sie kein arbeitslastfähiges Design üben. Die beste Möglichkeit, serverlose Ausgaben zu steuern, besteht darin, Ihre Indizes und Abfragen effizient von Anfang an zu entwerfen.

Um Arbeitslasten für Effizienz bei Verwendung des Serverless-Preismodells zu entwerfen, sollten Sie Folgendes in Betracht ziehen:

Indexentwurf

  • Schließen Sie nur Felder ein, die in Abfragen verwendet werden.
  • Reduzieren Sie Vektorabmessungen nach Möglichkeit.
  • Vermeiden Sie unnötige filterbare, sortierbare oder facetable-Attribute.

Abfragemuster

  • Verwenden Sie $select, um die zurückgegebenen Felder einzuschränken.
  • Wenden Sie Filter früh an, um Ergebnismengen zu reduzieren.
  • Vermeiden Sie tiefe Paginierung ($skip).
  • Bevorzugen Sie gezielte Abfragen gegenüber umfassenden Volltextabfragen.
  • Verwenden Sie die Hybridsuche sorgfältig aufgrund höherer Berechnungskosten.

Monitoring

  • Überwachen Sie den CU-Verbrauch , um teure Abfragen zu identifizieren.
  • Verfolgen Sie das Speicherwachstum, und entfernen Sie nicht verwendete Daten.

In Serverless reduziert die Verbesserung der Leistung (schnellere, gezieltere Abfragen) in der Regel die Kosten.

Weitere Informationen finden Sie unter Kostenoptimierung mit dem serverlosen Preismodell in Azure KI-Suche.

Überlegungen zur regionalen Kapazität

Kapazität und Verfügbarkeit können je nach unterstützter Region variieren. Einige Regionen haben möglicherweise Einschränkungen bei der Bereitstellung neuer Dienste oder beim Skalieren vorhandener Dienste.

Hinweis

Während der öffentlichen Vorschau ist das Serverless-Preismodell nur in einer begrenzten Gruppe von Regionen verfügbar. Sehen Sie sich den Vorschauhinweis am Anfang dieses Artikels an.

Wenn Ihre bevorzugte Azure KI-Suche Region aufgrund von Kapazitätsbeschränkungen nicht verfügbar ist, lesen Sie Wie können Sie regionale Kapazitätsbeschränkungen in Azure KI-Suche behandeln.

Nächste Schritte

Planen und Verwalten von Kosten

  • Last updated on