Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Azure AI Zoeken biedt twee prijsmodellen die de capaciteit anders verwerken:
Toegewezen: Plan capaciteit door de grootte van replica's en partities te wijzigen en een servicelaag te selecteren.
- Richt capaciteit vooraf rechtstreeks in met behulp van replica's en partities.
- Schat de vereiste opslag (partities) en de vereiste doorvoercapaciteit (replica’s).
- Kies een servicelaag om de benodigde capaciteit in te richten op basis van de verwachte piekvraag.
- Zodra u de capaciteit vooraf hebt geconfigureerd, betaalt u een uurtarief dat wordt gemeten door zoekeenheden (RU's), ongeacht het gebruik.
Serverloos (preview): de service beheert automatisch capaciteit op basis van gebruiks- en servicelimieten. U hoeft geen capaciteit vooraf in te richten. Optimaliseer in plaats daarvan de efficiëntie van uw workload om kosten te beheren.
- De capaciteit schaalt automatisch mee met de vraag (kan naar nul schalen wanneer er geen activiteit is).
- U wordt gefactureerd op basis van het werkelijke gebruik, zoals gemeten door rekeneenheden (RU's) en opslag.
- In plaats van infrastructuur richt planning zich op deze kostenfactoren: querypatronen, indexgrootte en groei en gegevensopnamepatronen. Zie Kosten optimaliseren voor het serverloze model.
| Dimensie | Dedicated | Serverloze architectuur |
|---|---|---|
| Capaciteitsmodel | Geprovisioneerd (replica's × partities) | Op basis van verbruik |
| Scaling | Handleiding | Automatic |
| Gebruikersbeheer | Expliciet (replica’s en partities configureren) | Indirect (beïnvloed door kenmerken van de workload) |
| Billing | Vast uurtarief per Search Unit (SU) | Op verbruik gebaseerde betalingen voor rekeneenheden (RU's) en opslag |
| Niet-actieve kosten | Altijd in rekening gebracht (minimaal geprovisioneerde capaciteit) | Schaalt naar nul wanneer deze niet actief is |
| Focus op optimalisatie | Grootte van infrastructuur | Efficiëntie van de werklast |
| Ideaal voor | Voorspelbare, stabiele workloads | Variabele, piekbelastings- of multitenantworkloads, waaronder scenario's die worden aangestuurd door agents |
| Benadering van capaciteitsplanning | Grootte en schaal van infrastructuur (replica's en partities) | Efficiëntie en gebruikspatronen van workloads optimaliseren |
| Impact op inefficiëntie | Latentie en druk op de schaalbaarheid | Directe kostenverhoging |
Important
De serverloze ontwikkelaarslaag is momenteel beschikbaar als preview-versie. Deze preview wordt geleverd zonder service level agreement en wordt niet aanbevolen voor productieworkloads. Bepaalde functies worden mogelijk niet ondersteund of hebben mogelijk beperkte mogelijkheden. Zie Aanvullende gebruiksvoorwaarden voor Microsoft Azure Previews voor meer informatie.
Facturering voor de serverloze ontwikkelaarslaag is nog niet ingeschakeld tijdens de preview. Geschatte kosten voor uw gebruik zijn beschikbaar in de Azure portal en telemetrie, maar dat gebruik wordt niet weergegeven op uw Azure factuur tijdens deze initiële periode. Microsoft ontvangt ten minste 30 dagen kennisgeving voordat de facturering begint. Het uitstel van facturering tijdens deze preview is tijdelijk. Serverless Developer is een betaald abonnement en u bent verantwoordelijk voor eventuele kosten die in rekening worden gebracht zodra de facturering start.
De serverloze ontwikkelaarslaag biedt geen ondersteuning voor migratie naar of van andere prijscategorieën en sommige functies die beschikbaar zijn in andere lagen, worden niet ondersteund tijdens openbare preview. Servicelimieten, ondersteunde functies en prijsgegevens kunnen vóór algemene beschikbaarheid veranderen.
De preview is momenteel alleen beschikbaar in VS - west-centraal, Zwitserland - noord en Japan - oost.
Zie voor meer informatie hoe u het volgende kunt doen:
- Kosten voorspellen en beheren
- Een prijsmodel en servicelaag kiezen
- Kosten optimaliseren met het serverloze prijsmodel
Capaciteit plannen voor het dedicated model
In het toegewezen model richt u capaciteit in met behulp van Zoekeenheden (SU):
- Zoekeenheid (SU) = replica's × partities
- Replica: Kopieën van de zoekmachine. Biedt querydoorvoer en hoge beschikbaarheid.
- Partitie: opslageenheden. Biedt doorvoercapaciteit voor opslag en indexering.
Elke service begint met 1 replica × 1 partitie (1 SU). U kunt onafhankelijk van elkaar replica's en partities toevoegen of verwijderen om te voorzien in wisselende workloads. Door capaciteit toe te voegen, worden de kosten voor het uitvoeren van een zoekservice verhoogd.
| Begrip | Definitie |
|---|---|
| Zoekeenheid | Eén verhoging van de totale beschikbare capaciteit. Er is minimaal één zoekeenheid vereist om de service uit te voeren. Afhankelijk van uw prijscategorie varieert het maximum van één tot 36 eenheden. Het aantal zoekeenheden is gelijk aan het aantal replica's vermenigvuldigd met het aantal partities: R × P = SU. Elke service begint met één replica en één partitie, die één eenheid verbruikt: 1 × 1 = 1. Het toevoegen van een tweede replica verbruikt twee eenheden: 2 × 1 = 2. Een zoekeenheid is ook de factureringseenheid voor een zoekservice. |
| Replica | Exemplaren van de zoekservice, die voornamelijk worden gebruikt voor het verdelen van de belasting bij querybewerkingen. Elke replica fungeert als host voor één exemplaar van een index. Als u drie replica's toewijst, hebt u drie kopieën van een index beschikbaar voor het afhandelen van queryverzoeken. |
| Partitie | Fysieke opslag en I/O voor lees-/schrijfbewerkingen (bijvoorbeeld bij het herbouwen of vernieuwen van een index). Elke partitie heeft een segment van de totale index. Als u drie partities toewijst, wordt uw index onderverdeeld in drie gelijke delen. |
Controleer de partities en replicatabel voor mogelijke combinaties die onder de limiet van 36 eenheden blijven.
De fysieke kenmerken van replica's en partities, zoals verwerkingssnelheid en schijf-IO, variëren per servicelaag. In een standaard zoekdienst zijn de replica's en partities sneller en groter dan die van een basisdienst.
Wanneer moet u capaciteit toevoegen voor het toegewezen model
Overweeg om replica's of partities toe te voegen wanneer:
- De querylatentie neemt toe of er wordt niet voldaan aan de criteria van de service level agreement.
- De frequentie van HTTP 503-fouten (service niet beschikbaar) neemt toe.
- De frequentie van HTTP 429-fouten (te veel aanvragen) neemt toe, wat aangeeft dat aanvragen worden beperkt.
- Grote queryvolumes worden verwacht.
- Indexeringstaken zijn traag of raken achterop.
- Opslag- of indexeringsdoorvoer is onvoldoende.
Richtlijnen voor opschalen:
- Voeg replica's toe om de doorvoer en beschikbaarheid van query's te verhogen.
- Voeg partities toe om de opslag- en indexeringsprestaties te verbeteren.
- Workloads met veel query's vereisen doorgaans meer replica's.
- Voor grote indexen zijn mogelijk extra replica's vereist om de prestaties te behouden.
Important
Schaalbewerkingen kunnen enige tijd in beslag nemen en de kosten verhogen. Valideer altijd wijzigingen met behulp van prestatietests en prijsramingen.
De servicelaag die u kiest , bepaalt de partitiegrootte en -snelheid. Elke laag is geoptimaliseerd rond een set kenmerken die passen bij verschillende scenario's. Als u een hogere laag kiest, hebt u mogelijk minder partities nodig dan als u met S1 gaat. Een van de vragen die u moet beantwoorden via zelfgestuurd testen, is of een grotere en duurdere partitie betere prestaties oplevert dan twee goedkopere partities op een service die is ingericht in een lagere laag.
Eén service moet voldoende resources hebben om alle workloads (indexering en query's) af te handelen. Geen van beide werkbelastingen wordt op de achtergrond uitgevoerd. U kunt indexering plannen voor tijden waarin queryaanvragen natuurlijk minder frequent zijn, maar de service geeft anders geen prioriteit aan een andere taak. Bovendien zorgt een bepaalde mate van redundantie ervoor dat de queryprestaties worden verzacht wanneer services of knooppunten intern worden bijgewerkt.
In de regel hebben zoektoepassingen meestal meer replica's nodig dan partities, met name wanneer de servicebewerkingen worden bevooroordeeld voor queryworkloads. Elke replica is een kopie van uw index, zodat de service aanvragen kan verdelen over meerdere exemplaren. Azure AI Zoeken beheert alle taakverdeling en replicatie van een index. U kunt het aantal replica's dat is toegewezen voor uw service op elk gewenst moment wijzigen. U kunt maximaal 12 replica's toewijzen in een standaardzoekservice en 3 replica's in een Basic-zoekservice. U kunt replicatoewijzing maken vanuit de Azure portal of een van de programmatische opties.
Extra partities zijn handig voor intensieve indexeringsworkloads. Extra partities verspreiden lees- en schrijfbewerkingen over een groter aantal rekenresources.
Ten slotte duurt het langer om query's uit te voeren op grotere indexen. Als zodanig kan het zijn dat elke incrementele toename van partities een kleinere maar proportionele toename van replica's vereist. De complexiteit en het volume van uw query's beïnvloeden hoe snel de uitvoering van een query plaatsvindt.
Zie voor servicelimieten en geldige schaalbereiken:
Notitie
Het toevoegen van meer replica's of partities verhoogt de kosten van het uitvoeren van de service en kan kleine variaties veroorzaken in de volgorde van resultaten. Controleer de prijscalculator om inzicht te krijgen in de gevolgen voor de facturering van het toevoegen van meer knooppunten. Met de tabel partitie- en replicacombinaties kunt u kruislings verwijzen naar het aantal zoekeenheden dat is vereist voor een specifieke configuratie. Zie Orderresultaten voor meer informatie over hoe extra replica's van invloed zijn op queryverwerking.
Capaciteit beheren en aanpassen
Het wijzigen van de capaciteit is niet onmiddellijk. Afhankelijk van het gegevensvolume en het bewerkingstype kan het schalen van minuten tot enkele uren duren.
Wanneer u een zoekservice schaalt, kunt u kiezen uit de volgende hulpprogramma's en benaderingen:
Notitie
Als uw zoekservice vóór april of mei 2024 is gemaakt, komt deze mogelijk in aanmerking voor een eenmalige upgrade naar een nieuwere infrastructuur met grotere partitiegrootten zonder extra kosten. Deze upgrade kan de beschikbare opslag per partitie verhogen en het aantal vereiste partities voor uw workload verminderen. Zie Uw zoekservice upgraden voor meer informatie.
Als u de capaciteit van uw service wilt vergroten of verlagen, hebt u twee opties:
Partities en replica's toevoegen of verwijderen
Ga naar uw zoekservice in de Azure portal.
Selecteer Instellingen>Schalen in het linkerdeelvenster.
In de volgende schermopname ziet u een Standard-service die is ingericht met één replica en partitie. De formule onderaan geeft aan hoeveel zoekeenheden worden gebruikt (1). Als de eenheidsprijs $ 100 was (geen echte prijs), zou de maandelijkse kosten voor het uitvoeren van deze service gemiddeld $ 100 zijn.
Gebruik de schuifregelaar om het aantal partities te vergroten of verkleinen en selecteer Opslaan.
In dit voorbeeld wordt een tweede replica en partitie toegevoegd. Let op de hoeveelheid zoekeenheden; deze is nu vier omdat de factureringsformule bestaat uit het vermenigvuldigen van replica's met partities (2 x 2). Verdubbeling van capaciteit meer dan verdubbelt de kosten voor het uitvoeren van de service. Als de kosten van de zoekeenheid $ 100 waren, zou de nieuwe maandelijkse factuur nu $ 400 zijn.
Ga naar de pagina met prijzen voor de huidige kosten per eenheid van elke laag.
Controleer uw meldingen om te bevestigen dat de bewerking is gestart.
Het kan enkele uren duren voordat deze bewerking is voltooid. Dit gebeurt op de achtergrond, zodat uw zoekservice volledig operationeel blijft en beschikbaar blijft voor lees- en schrijfbewerkingen.
U kunt de bewerking niet annuleren of de voortgang ervan controleren. Het volgende bericht wordt echter weergegeven terwijl er wijzigingen worden uitgevoerd.
Uw prijscategorie wijzigen
Notitie
De Azure-portal en Services - Update (REST API) bieden ondersteuning voor wijzigingen tussen de lagen Basic en Standard (S1, S2 en S3). U kunt lagen upgraden of downgraden, mits de huidige serviceconfiguratie de limieten van de doellaag niet overschrijdt. Uw regio kan ook geen capaciteitsbeperkingen hebben voor de doellaag.
Uw prijscategorie bepaalt de maximale opslag van uw zoekservice voor het dedicated-prijsmodel. Als u meer of minder capaciteit nodig hebt, kunt u overschakelen naar een andere prijscategorie die aan uw opslagbehoeften voldoet. (Dit geldt alleen voor de prijscategorieën dedicated. De serverloze modelontwikkelaarslaag kan niet worden gewijzigd nadat deze is geselecteerd).
Naast capaciteit bepalen prijscategorieën limieten voor indexen, indexeerfuncties en andere zoekobjecten. Vergelijk de servicelimieten van uw huidige laag en de gewenste laag voordat u verdergaat. Over het algemeen verhoogt het overschakelen naar een hogere laag uw opslaglimiet en vectorlimiet, verhoogt de doorvoer van aanvragen en verlaagt de latentie, terwijl het overschakelen naar een lagere laag het tegenovergestelde effect heeft.
Als u overschakelt naar een hogere prijscategorie, worden ook de kosten voor het uitvoeren van uw zoekservice verhoogd. Zie voor meer informatie de pagina met prijzen.
Ga als volgende te werk om uw prijscategorie te wijzigen:
Ga naar uw zoekservice in de Azure portal.
Selecteer Instellingen>Schalen in het linkerdeelvenster.
Selecteer Onder uw huidige laag de optie Prijscategorie wijzigen.
Kies op de Selecteer Prijscategorie pagina een ander niveau uit de lijst.
U kunt schakelen tussen Basic, S1, S2 en S3, maar u kunt niet overschakelen naar of van Gratis, S3HD, L1 of L2. Deze lagen kunnen niet worden geselecteerd en worden grijs weergegeven.
Selecteer Opslaan om de schaalbewerking te starten.
Het kan enkele uren duren voordat deze bewerking is voltooid. Dit gebeurt op de achtergrond, zodat uw zoekservice volledig operationeel blijft en beschikbaar blijft voor lees- en schrijfbewerkingen.
U kunt de bewerking niet annuleren of de voortgang ervan controleren. Het volgende bericht wordt echter weergegeven terwijl er wijzigingen worden uitgevoerd.
Hoe schaalaanvragen worden verwerkt voor het toegewezen model
Wanneer de zoekservice een schaalaanvraag ontvangt, doet u het volgende:
- Controleert of de aanvraag geldig is.
- Hiermee wordt een back-up gemaakt van gegevens en systeeminformatie.
- Controleert of de service al een inrichtingsstatus heeft (momenteel replica's of partities toevoegen of elimineren).
- Begint met provisioneren.
Het schalen van een service kan enkele minuten tot enkele uren duren, afhankelijk van de grootte van de service en het bereik van de aanvraag. De back-upduur varieert ook op basis van de hoeveelheid gegevens en het aantal partities en replica's.
De voorgaande stappen zijn niet volledig opeenvolgend. Het systeem wordt bijvoorbeeld ingericht wanneer dit veilig kan, wat mogelijk is wanneer de back-up bijna voltooid is.
Fouten tijdens het schalen
De volgende tabel bevat oorzaken en oplossingen voor fouten die kunnen optreden tijdens schaalbewerkingen.
| Foutmelding | Oorzaak | Solution |
|---|---|---|
| 'Bewerkingen voor service-updates zijn op dit moment niet toegestaan omdat we een vorige aanvraag verwerken.' | Er wordt een andere schaalbewerking uitgevoerd. | Controleer de pagina Overview in de Azure-portal of gebruik de Search Management REST API, Azure PowerShell of Azure CLI om de status van uw zoekservice op te halen. Als de status 'Inrichten' is, wacht u totdat deze 'Geslaagd' of 'Mislukt' wordt voordat u het opnieuw probeert. 1, 2 |
| Kan de zoekservice servicenaam niet schalen. Fout: Het aantal werkelijke aantallen objecten overschrijdt de toegestane limiet: MaximumCount. | De huidige serviceconfiguratie overschrijdt de limieten van de doelprijscategorie. | Controleer of uw opslaggebruik, vectorgebruik, indexen, indexeerfuncties en andere objecten binnen de servicelimieten van de lagere laag passen. De Basic-laag ondersteunt bijvoorbeeld maximaal 15 indexen, zodat u niet kunt overschakelen van S1 naar Basic als u 16 indexen hebt. Pas uw resources aan voordat u het opnieuw probeert. |
1 Er is geen status voor back-ups, die interne bewerkingen zijn die waarschijnlijk geen schaaloefening zullen verstoren.
2 Als uw zoekservice in een inrichtingsstatus is vastgelopen, controleert u op zwevende indexen die onbruikbaar zijn, met nul queryvolumes en geen indexupdates. Een onbruikbare index kan wijzigingen in de servicecapaciteit blokkeren. Zoek met name naar met CMK versleutelde indexen waarvan de sleutels niet meer geldig zijn. Verwijder de index of herstel de sleutels om de index weer online te zetten en de schaalbewerking te deblokkeren.
Partitie- en replicacombinaties
De volgende grafiek is van toepassing op de Standard-laag en hoger. Het toont alle mogelijke combinaties van partities en replica's, afhankelijk van het maximum van 36 zoekeenheden per service.
| 1 partitie | 2 partities | 3 partities | 4 partities | 6 partities | 12 partities | |
|---|---|---|---|---|---|---|
| 1 kopie | 1 SU | 2 SU | 3 SU | 4 SU | 6 SU | 12 SU |
| 2 replica's | 2 SU | 4 SU | 6 SU | 8 SU | 12 SU | 24 SU |
| 3 replica's | 3 SU | 6 SU | 9 SU | 12 SU | 18 SU | 36 SU |
| 4 replica's | 4 SU | 8 SU | 12 SU | 16 SU | 24 SU | N.v.t. |
| 5 replica's | 5 Standby Units | 10 SU | 15 SU | 20 SU | 30 SU | N.v.t. |
| 6 replica's | 6 SU | 12 SU | 18 SU | 24 SU | 36 SU | N.v.t. |
| 12 replica's | 12 SU | 24 SU | 36 SU | N.v.t. | N.v.t. | N.v.t. |
Basiszoekservices hebben lagere aantallen zoekeenheden.
Bij zoekservices die vóór 3 april 2024 zijn gemaakt, kunnen basisservices exact één partitie en maximaal drie replica's hebben voor een maximumlimiet van drie SUs. De enige aanpasbare hulpbron is replicas. Het is echter mogelijk dat u het aantal partities kunt verhogen door uw service te upgraden.
Bij zoekservices die zijn gemaakt na 3 april 2024 in ondersteunde regio's, kunnen Basic-services maximaal drie partities en drie replica's hebben. De maximale SU-limiet is negen ter ondersteuning van een volledige set partities en replica's.
Voor zoekservices op een factureerbare laag, ongeacht de aanmaakdatum, hebt u minimaal twee replica's nodig voor hoge beschikbaarheid voor query's.
Zie de Azure AI Zoeken pagina met prijzen voor factureringstarieven per laag en valuta.
Capaciteit schatten met behulp van een dedicated prijsmodelcategorie
Uw opslagbehoeften zijn afhankelijk van de grootte van de indexen die u verwacht te bouwen. Er zijn geen solide heuristieken of algemene richtlijnen die helpen bij schattingen. De enige manier om de grootte van een index te bepalen, is door er een te bouwen. De grootte is afhankelijk van tokenisatie en insluitingen, en of u suggesties, filteren en sorteren inschakelt of gebruik kunt maken van vectorcompressie.
Maak een schatting van de capaciteit voor een factureerbare laag, Basic of hoger. De gratis laag wordt uitgevoerd op fysieke resources die door meerdere klanten worden gedeeld en is onderhevig aan factoren die buiten uw beheer vallen. Alleen de toegewezen resources van een factureerbare zoekservice kunnen tijdens de ontwikkeling grotere steekproeven en verwerkingstijden bieden voor realistischere schattingen van de indexhoeveelheid, grootte en queryvolumes.
Controleer servicelimieten op elke laag om te bepalen of lagere lagen het aantal indexen kunnen ondersteunen dat u nodig hebt. Overweeg of u meerdere kopieën van een index nodig hebt voor actieve ontwikkeling, testen en productie.
Een zoekservice is onderhevig aan objectlimieten (maximaal aantal indexen, indexeerfuncties, vaardighedensets, enzovoort) en opslaglimieten. Welke limiet het eerst wordt bereikt, is de effectieve limiet.
Maak een service op een factureerbaar niveau. Lagen zijn geoptimaliseerd voor bepaalde workloads. De laag Geoptimaliseerd voor opslag heeft bijvoorbeeld een limiet van 10 indexen, omdat deze is ontworpen om een laag aantal grote indexen te ondersteunen.
Begin laag, bij Basic of S1, als u niet zeker weet wat de verwachte belasting is.
Start hoog, bij S2 of zelfs S3, als het testen grootschalige indexering en querybelastingen omvat.
Begin met Geoptimaliseerd voor opslag, bij L1 of L2, als u een grote hoeveelheid gegevens indexeert en querybelasting relatief laag is, net als bij een interne bedrijfstoepassing.
Bouw een initiële index om te bepalen hoe brongegevens worden omgezet in een index. Dit is de enige manier om de indexgrootte te schatten. Kenmerken van de velddefinities zijn van invloed op fysieke opslagvereisten:
Voor trefwoorden zoeken vergroot het markeren van velden als filterbaar en sorteerbaar de indexgrootte.
Voor vectorzoekopdrachten kunt u parameters instellen om de vectorgrootte te verkleinen.
Bewaken opslag, service-limieten, queryvolume en latentie in de Azure-portal. In de Azure-portal worden query's per seconde, beperkte query's en zoeklatentie weergegeven. Met deze waarden kunt u bepalen of u de juiste laag hebt geselecteerd.
Voeg replica's toe voor hoge beschikbaarheid of om trage queryprestaties te beperken.
Er zijn geen richtlijnen voor het aantal replica's dat nodig is voor het laden van query's. Queryprestaties zijn afhankelijk van de complexiteit van de query en concurrerende workloads. Hoewel het toevoegen van replica's duidelijk resulteert in betere prestaties, is het resultaat niet strikt lineair: het toevoegen van drie replica's garandeert geen drievoudige doorvoer. Zie Prestaties analyseren enquery's bewaken voor hulp bij het schatten van QPS voor uw oplossing.
Voor een omgekeerde index wordt de grootte en complexiteit bepaald door inhoud, niet noodzakelijkerwijs door de hoeveelheid gegevens die u erin invoert. Een grote gegevensbron met hoge redundantie kan leiden tot een kleinere index dan een kleinere gegevensset die zeer variabele inhoud bevat. Het is dus zelden mogelijk om de indexgrootte af te stellen op basis van de grootte van de oorspronkelijke gegevensset.
Opslagvereisten kunnen worden vergroot als u gegevens opneemt die u nooit doorzoekt. In het ideale voorbeeld bevatten documenten alleen de gegevens die u nodig hebt voor de zoekervaring.
Overwegingen voor serviceovereenkomsten
Service level agreements (SLA's) hebben geen betrekking op de gratis laag en preview-functies. Voor alle factureerbare lagen worden SLA's van kracht wanneer u voldoende redundantie voor uw service inricht.
Twee of meer replica's voldoen aan query-SLA's (lezen).
Drie of meer replica's voldoen aan query- en indexerings-SLA's (read-write).
Het aantal partities heeft geen invloed op SLA's.
Kosten optimaliseren voor het serverloze model
In het serverloze prijsmodel:
- De service beheert automatisch capaciteit.
- U hoeft geen replica's, partities of zoekeenheden te configureren.
- Rekencapaciteit wordt dynamisch aangepast op basis van de workload (de vraag naar query’s en indexering) en kan naar nul worden teruggeschaald wanneer deze inactief is.
Zie Servicelimieten voor meer informatie over beperkingen voor het serverloze model.
Facturering is gebaseerd op twee dimensies:
- Rekengebruik (CU's): Er worden kosten in rekening gebracht op basis van query- en indexeringsbewerkingen.
- Geïndexeerde opslag: Kosten per GB per maand.
Omdat facturering is gebaseerd op verbruik, zijn kosten rechtstreeks gekoppeld aan gebruik:
- Complexe query's verbruiken meer rekenkracht.
- Inefficiënt schemaontwerp verhoogt zowel indexering als querykosten.
- Slechte querypatronen met grote of regelmatig bijgewerkte indexen verhogen het opslag- en rekengebruik.
Efficiëntie van workloads optimaliseren
Omdat inefficiëntie wordt weergegeven als kosten in het serverloze model, betaalt u meer voor hetzelfde werk als u geen workloadbewust ontwerp oefent. De beste manier om serverloze uitgaven te beheren, is door vanaf het begin uw indexen en query's efficiënt te ontwerpen.
Als u workloads wilt ontwerpen voor efficiëntie bij het gebruik van het serverloze prijsmodel, kunt u het volgende overwegen:
Indexontwerp
- Alleen velden opnemen die worden gebruikt in query's.
- Verminder waar mogelijk vectordimensies.
- Vermijd onnodige attributen die filterbaar, sorteerbaar of geschikt voor facettering zijn.
Querypatronen
- Gebruik
$selectdit om geretourneerde velden te beperken. - Pas filters vroeg toe om de resultatenset te verkleinen.
- Vermijd diep pagineren (
$skip). - Geef de voorkeur aan gerichte query's boven brede query's voor volledige tekst.
- Gebruik hybride zoekopdrachten zorgvuldig vanwege hogere rekenkosten.
Monitoring
- Controleer CU-verbruik om dure query's te identificeren.
- Houd de opslaggroei bij en verwijder ongebruikte gegevens.
Bij serverless verlaagt het verbeteren van de prestaties (snellere, gerichtere query’s) doorgaans de kosten.
Zie Kosten optimaliseren met het serverloze prijsmodel in Azure AI Zoeken voor meer informatie.
Overwegingen voor regionale capaciteit
Capaciteit en beschikbaarheid kunnen per ondersteunde regio verschillen. Sommige regio's hebben mogelijk beperkingen voor het inrichten van nieuwe services of het schalen van bestaande services.
Notitie
Tijdens de openbare preview is het serverloze prijsmodel alleen beschikbaar in een beperkt aantal regio's. Zie de preview-kennisgeving aan het begin van dit artikel.
Als de regio van uw voorkeur Azure AI Zoeken niet beschikbaar is vanwege capaciteitsbeperkingen, raadpleegt u