Capaciteit van een zoekservice schatten en beheren
In Azure AI Search is capaciteit gebaseerd op replica's en partities die kunnen worden geschaald naar uw workload. Replica's zijn kopieën van de zoekmachine. Partities zijn opslageenheden. Elke nieuwe zoekservice begint met één service, maar u kunt onafhankelijk replica's en partities toevoegen of verwijderen om te voldoen aan fluctuerende workloads. Door capaciteit toe te voegen, worden de kosten voor het uitvoeren van een zoekservice verhoogd.
De fysieke kenmerken van replica's en partities, zoals verwerkingssnelheid en schijf-IO, variëren per servicelaag. In een standaardzoekservice zijn de replica's en partities sneller en groter dan die van een basisservice.
Het wijzigen van de capaciteit is niet onmiddellijk. Het kan een uur duren voordat partities in gebruik worden genomen of buiten gebruik worden gesteld, met name voor services met grote hoeveelheden gegevens.
Wanneer u een zoekservice schaalt, kunt u kiezen uit de volgende hulpprogramma's en benaderingen:
Concepten: zoekeenheden, replica's, partities, shards
Capaciteit wordt uitgedrukt in zoekeenheden die kunnen worden toegewezen in combinaties van partities en replica's, met behulp van een onderliggend shardingmechanisme ter ondersteuning van flexibele configuraties:
| Concept | Definitie |
|---|---|
| Zoekeenheid | Eén verhoging van de totale beschikbare capaciteit (36 eenheden). Het is ook de factureringseenheid voor een Azure AI-Search-service. Er is minimaal één eenheid vereist om de service uit te voeren. |
| Replica | Exemplaren van de zoekservice, die voornamelijk worden gebruikt om querybewerkingen te verdelen. 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 die beschikbaar is voor het uitvoeren van queryaanvragen. |
| 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 derde partities. |
| Shard | Een segment van een index. Azure AI Search verdeelt elke index in shards om het proces van het toevoegen van partities sneller te maken (door shards naar nieuwe zoekeenheden te verplaatsen). |
In het volgende diagram ziet u de relatie tussen replica's, partities, shards en zoekeenheden. Hier ziet u een voorbeeld van hoe één index wordt verdeeld over vier zoekeenheden in een service met twee replica's en twee partities. Elk van de vier zoekeenheden slaat slechts de helft van de shards van de index op. De zoekeenheden in de linkerkolom slaan de eerste helft van de shards op, bestaande uit de eerste partitie, terwijl die in de rechterkolom de tweede helft van de shards opslaan, bestaande uit de tweede partitie. Omdat er twee replica's zijn, zijn er twee kopieën van elke index-shard. In de zoekeenheden in de bovenste rij wordt één kopie opgeslagen, bestaande uit de eerste replica, terwijl die in de onderste rij een andere kopie opslaan, bestaande uit de tweede replica.
Het bovenstaande diagram is slechts één voorbeeld. Veel combinaties van partities en replica's zijn mogelijk, maximaal 36 zoekeenheden.
In Azure AI Search is shardbeheer een implementatiedetail en niet-configureerbaar, maar wetende dat een index is sharded helpt de incidentele afwijkingen in classificatie- en automatisch aanvullen-gedrag te begrijpen:
Classificatieafwijkingen: zoekscores worden eerst berekend op shardniveau en vervolgens samengevoegd in één resultatenset. Afhankelijk van de kenmerken van shard-inhoud, kunnen overeenkomsten van de ene shard hoger zijn dan overeenkomsten in een andere. Als u intuïtieve classificaties in zoekresultaten ziet, is dit waarschijnlijk het gevolg van de effecten van sharding, vooral als indexen klein zijn. U kunt deze classificatieafwijkingen vermijden door ervoor te kiezen om scores globaal te berekenen in de hele index, maar dit leidt wel tot een prestatiestraf.
Afwijkingen voor automatisch aanvullen: Query's voor automatisch aanvullen, waarbij overeenkomsten worden gemaakt op de eerste tekens van een gedeeltelijk ingevoerde term, accepteren een fuzzy parameter die kleine afwijkingen in de spelling vergeeft. Voor automatisch aanvullen is fuzzy matching beperkt tot termen in de huidige shard. Als een shard bijvoorbeeld 'Microsoft' bevat en een gedeeltelijke term 'micro' wordt ingevoerd, komt de zoekmachine overeen met 'Microsoft' in die shard, maar niet in andere shards die de resterende onderdelen van de index bevatten.
Schattingsdoelen
Capaciteitsplanning moet objectlimieten bevatten (bijvoorbeeld het maximum aantal indexen dat is toegestaan voor een service) en opslaglimieten. De servicelaag bepaalt object- en opslaglimieten. Welke limiet het eerst wordt bereikt, is de effectieve limiet.
Het aantal indexen en andere objecten wordt doorgaans bepaald door bedrijfs- en technische vereisten. U hebt bijvoorbeeld meerdere versies van dezelfde index voor actieve ontwikkeling, testen en productie.
Opslagbehoeften worden bepaald door de grootte van de indexen die u verwacht te bouwen. Er zijn geen solide heuristieken of generaliteiten die helpen bij schattingen. De enige manier om de grootte van een index te bepalen, is een index maken. De grootte wordt gebaseerd op geïmporteerde gegevens, tekstanalyse en indexconfiguratie, zoals het inschakelen van suggesties, filteren en sorteren.
Voor zoeken in volledige tekst is de primaire gegevensstructuur een omgekeerde indexstructuur , die verschillende kenmerken heeft dan brongegevens. 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.
Kenmerken in de index, zoals het inschakelen van filters en sorteren, zijn van invloed op de opslagvereisten. Het gebruik van suggesties heeft ook gevolgen voor de opslag. Zie Kenmerken en indexgrootte voor meer informatie.
Notitie
Hoewel het schatten van toekomstige behoeften voor indexen en opslag kan lijken op schattingen, is het de moeite waard om te doen. Als de capaciteit van een laag te laag blijkt te zijn, moet u een nieuwe service inrichten op een hogere laag en vervolgens uw indexen opnieuw laden. Er is geen in-place upgrade van een service van de ene naar de andere laag.
Schatting met de gratis laag
Een benadering voor het schatten van de capaciteit is om te beginnen met de gratis laag. Houd er rekening mee dat de gratis service maximaal drie indexen, 50 MB opslagruimte en 2 minuten indexeringstijd biedt. Het kan lastig zijn om een geschatte indexgrootte te schatten met deze beperkingen, maar dit zijn de stappen:
Bereid een kleine, representatieve gegevensset voor.
Maak een index en laad uw gegevens. Als de gegevensset kan worden gehost in een Azure-gegevensbron die wordt ondersteund door indexeerfuncties, kunt u de wizard Gegevens importeren in de portal gebruiken om de index te maken en te laden. Anders kunt u REST API's gebruiken om de index te maken en de gegevens te pushen. Voor het pushmodel moeten gegevens in de vorm van JSON-documenten staan, waarbij velden in het document overeenkomen met velden in de index.
Verzamel informatie over de index, zoals grootte. Functies en kenmerken zijn van invloed op de opslag. Als u bijvoorbeeld suggesties (query's op basis van zoeken naar typen) toevoegt, worden de opslagvereisten verhoogd.
Met dezelfde gegevensset kunt u proberen meerdere versies van een index te maken, met verschillende kenmerken in elk veld, om te zien hoe de opslagvereisten variëren. Zie 'Gevolgen voor opslag' in Een basisindex maken voor meer informatie.
Met een ruwe schatting kunt u dat bedrag verdubbelen voor twee indexen (ontwikkeling en productie) en vervolgens uw laag dienovereenkomstig kiezen.
Schatting met een factureerbare laag
Toegewezen resources kunnen tijdens de ontwikkeling grotere steekproeven en verwerkingstijden bieden voor realistischere schattingen van de indexhoeveelheid, grootte en queryvolumes. Sommige klanten springen meteen in met een factureerbare laag en evalueren vervolgens opnieuw naarmate het ontwikkelingsproject zich ontwikkelt.
Controleer servicelimieten op elke laag om te bepalen of lagere lagen het aantal indexen kunnen ondersteunen dat u nodig hebt. In de lagen Basic, S1 en S2 zijn de indexlimieten respectievelijk 15, 50 en 200. De laag Geoptimaliseerd voor opslag heeft een limiet van 10 indexen, omdat deze is ontworpen om een laag aantal zeer grote indexen te ondersteunen.
Maak een service op een factureerbare laag:
- 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.
Bewaak opslag, servicelimieten, queryvolume en latentie in de portal. In de portal ziet u query's per seconde, beperkte query's en zoeklatentie. Al deze waarden kunnen u helpen beslissen 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 en query's bewaken voor hulp bij het schatten van QPS voor uw oplossing.
Notitie
Opslagvereisten kunnen worden vergroot als u gegevens opneemt die nooit worden doorzocht. In het ideale voorbeeld bevatten documenten alleen de gegevens die u nodig hebt voor de zoekervaring. Binaire gegevens kunnen niet worden doorzocht en moeten afzonderlijk worden opgeslagen (mogelijk in een Azure-tabel of blobopslag). Vervolgens moet een veld in de index worden toegevoegd om een URL-verwijzing naar de externe gegevens te bewaren. De maximale grootte van een afzonderlijk zoekdocument is 16 MB (of minder als u meerdere documenten bulksgewijs uploadt in één aanvraag). Zie Servicelimieten in Azure AI Search voor meer informatie.
Overwegingen voor queryvolumes
Query's per seconde (QPS) is een belangrijke metrische waarde tijdens het afstemmen van de prestaties, maar voor capaciteitsplanning wordt het alleen een overweging als u verwacht dat het grote queryvolume van het begin is.
De Standard-lagen kunnen een balans bieden tussen replica's en partities. U kunt de querytijd vergroten door replica's toe te voegen voor taakverdeling of partities toe te voegen voor parallelle verwerking. U kunt vervolgens afstemmen op prestaties nadat de service is ingericht.
Als u vanaf het begin hoge queryvolumes verwacht, moet u hogere Standard-lagen overwegen, ondersteund door krachtigere hardware. U kunt vervolgens partities en replica's offline halen of zelfs overschakelen naar een service met een lagere laag, als deze queryvolumes niet voorkomen. Zie Query's bewaken voor meer informatie over het berekenen van querydoorvoer.
De lagen geoptimaliseerd voor opslag zijn handig voor grote gegevensworkloads, die meer algemene beschikbare indexopslag ondersteunen wanneer de vereisten voor querylatentie minder belangrijk zijn. U moet nog steeds extra replica's gebruiken voor taakverdeling en extra partities voor parallelle verwerking. U kunt vervolgens afstemmen op prestaties nadat de service is ingericht.
Serviceovereenkomsten
De gratis laag en preview-functies vallen niet onder serviceovereenkomsten (SLA's). Voor alle factureerbare lagen worden SLA's van kracht wanneer u voldoende redundantie voor uw service inricht. U moet twee of meer replica's hebben voor query-SLA's (lezen). U moet drie of meer replica's hebben voor sla's voor query's en indexering (lezen/schrijven). Het aantal partities heeft geen invloed op SLA's.
Tips voor capaciteitsplanning
Sta metrische gegevens toe om query's op te bouwen en gegevens over gebruikspatronen te verzamelen (query's tijdens kantooruren, indexering tijdens daluren). Gebruik deze gegevens om beslissingen over de inrichting van services te informeren. Hoewel het niet praktisch is in een uur of dagelijks tempo, kunt u partities en resources dynamisch aanpassen om geplande wijzigingen in queryvolumes mogelijk te maken. U kunt ook ongeplande maar aanhoudende wijzigingen opvangen als de niveaus lang genoeg zijn om actie te ondernemen.
Houd er rekening mee dat het enige nadeel van het inrichten is dat u een service mogelijk moet afbreken als de werkelijke vereisten groter zijn dan uw voorspellingen. Om serviceonderbreking te voorkomen, maakt u een nieuwe service op een hogere laag en voert u deze naast elkaar uit totdat alle apps en aanvragen het nieuwe eindpunt bereiken.
Wanneer moet u capaciteit toevoegen
In eerste instantie wordt aan een service een minimaal niveau van resources toegewezen dat bestaat uit één partitie en één replica. De laag die u kiest , bepaalt de partitiegrootte en -snelheid en elke laag wordt geoptimaliseerd rond een set kenmerken die geschikt zijn voor 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 op 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 vaak voorkomen, maar de service geeft anders geen prioriteit aan de ene taak boven de andere. Bovendien zorgt een bepaalde mate van redundantie ervoor dat de queryprestaties worden verzacht wanneer services of knooppunten intern worden bijgewerkt.
Enkele richtlijnen voor het bepalen of u capaciteit wilt toevoegen, zijn onder andere:
- Voldoen aan de criteria voor hoge beschikbaarheid voor service level agreement
- De frequentie van HTTP 503-fouten neemt toe
- Grote queryvolumes worden verwacht
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. Alle taakverdeling en replicatie van een index worden beheerd door Azure AI Search en 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. Replicatoewijzing kan worden gemaakt vanuit Azure Portal of een van de programmatische opties.
Zoektoepassingen waarvoor bijna realtime gegevensvernieuwing is vereist, hebben proportioneel meer partities nodig dan replica's. Het toevoegen van partities verspreidt lees-/schrijfbewerkingen over een groter aantal rekenresources. Het biedt u ook meer schijfruimte voor het opslaan van extra indexen en documenten.
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 van uw query's en queryvolumes zal bepalen hoe snel query's worden uitgevoerd.
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. In de onderstaande grafiek kunt u kruislings verwijzen naar het aantal zoekeenheden dat nodig is voor een specifieke configuratie. Zie Orderresultaten voor meer informatie over hoe extra replica's van invloed zijn op de verwerking van query's.
Replica's en partities toevoegen of verminderen
Meld u aan bij Azure Portal en selecteer de zoekservice.
Open onder Instellingen de pagina Schaal om replica's en partities te wijzigen.
In de volgende schermopname ziet u een Basic Standard 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. Selecteer Opslaan.
In dit voorbeeld wordt een tweede replica en partitie toegevoegd. Let op het aantal zoekeenheden; dit is nu vier omdat de factureringsformule replica's is vermenigvuldigd 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 Prijzen voor de huidige kosten per eenheid van elke laag.
Nadat u de bewerking hebt opgeslagen, kunt u de meldingen controleren om te bevestigen dat de actie is geslaagd.
Het kan 15 minuten tot enkele uren duren voordat wijzigingen in de capaciteit zijn voltooid. U kunt niet annuleren nadat het proces is gestart en er is geen realtime bewaking voor replica- en partitieaanpassingen. Het volgende bericht blijft echter zichtbaar terwijl er wijzigingen worden doorgevoerd.
Notitie
Nadat een service is ingericht, kan deze niet worden bijgewerkt naar een hogere laag. U moet een zoekservice maken in de nieuwe laag en uw indexen opnieuw laden. Zie Een Azure AI-Search-service maken in de portal voor hulp bij het inrichten van services.
Hoe schaalaanvragen worden verwerkt
Na ontvangst van een schaalaanvraag, de zoekservice:
- 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 inrichten.
Het schalen van een service kan maximaal 15 minuten of langer dan een uur duren, afhankelijk van de grootte van de service en het bereik van de aanvraag. Het maken van een back-up kan enkele minuten duren, afhankelijk van de hoeveelheid gegevens en het aantal partities en replica's.
De bovenstaande stappen zijn niet volledig opeenvolgend. Het systeem wordt bijvoorbeeld ingericht wanneer dit veilig kan, wat kan zijn wanneer de back-up afneemt.
Fouten tijdens het schalen
Het foutbericht 'Service-updatebewerkingen zijn op dit moment niet toegestaan omdat we een vorige aanvraag verwerken' wordt veroorzaakt door het herhalen van een aanvraag om omlaag of omhoog te schalen wanneer de service al een eerdere aanvraag verwerkt.
Los deze fout op door de servicestatus te controleren om de inrichtingsstatus te controleren:
- Gebruik de REST API voor beheer, Azure PowerShell of Azure CLI om de servicestatus op te halen.
- Roep Service ophalen (REST) of gelijkwaardig aan voor PowerShell of de CLI.
- Controleer het antwoord op 'provisioningState': 'provisioning'
Als de status Inrichten is, wacht u totdat de aanvraag is voltooid. De status moet 'Geslaagd' of 'Mislukt' zijn voordat een andere aanvraag wordt geprobeerd. Er is geen status voor back-up. Back-up is een interne bewerking en het is onwaarschijnlijk dat het een factor is bij elke onderbreking van een schaaloefening.
Als uw zoekservice in een inrichtingsstatus lijkt te zijn 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 indexen die CMK-versleuteld zijn, waarvan de sleutels niet meer geldig zijn. U moet de index verwijderen of de sleutels herstellen om de index weer online te brengen en de schaalbewerking te deblokkeren.
Partitie- en replicacombinaties
Bij zoekservices die vóór 3 april 2024 zijn gemaakt: Basic kan precies één partitie en maximaal drie replica's hebben, voor een maximumlimiet van drie RU's. De enige aanpasbare resource is replica's.
Op zoekservices die zijn gemaakt na 3 april 2024 in ondersteunde regio's: Basic kan maximaal drie partities en drie replica's hebben. De maximale SU-limiet is negen ter ondersteuning van een volledige aanvulling op 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.
Voor alle standaard- en opslag geoptimaliseerde zoekservices kunnen worden uitgegaan van de volgende combinaties van replica's en partities, afhankelijk van de limiet van 36 SU die is toegestaan voor deze lagen.
| 1 partitie | 2 partities | 3 partities | 4 partities | 6 partities | 12 partities | |
|---|---|---|---|---|---|---|
| 1 replica | 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 SU | 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. |
Ru's, prijzen en capaciteit worden uitgebreid beschreven op de Azure-website. Zie Prijsinformatie voor meer informatie.
Notitie
Het aantal replica's en partities wordt gelijkmatig verdeeld in 12 (met name 1, 2, 3, 4, 6, 12). Azure AI Search verdeelt elke index vooraf in 12 shards, zodat deze in gelijke delen over alle partities kan worden verdeeld. Als uw service bijvoorbeeld drie partities heeft en u een index maakt, bevat elke partitie vier shards van de index. Hoe Azure AI Search een index shards is, is een implementatiedetail, afhankelijk van wijzigingen in toekomstige releases. Hoewel het getal vandaag 12 is, moet u niet verwachten dat dat getal altijd 12 in de toekomst is.