Capaciteit van een zoekservice schatten en beheren

Voordat u een zoekservice maakt en vergrendelt in een specifieke prijscategorie, neemt u een paar minuten de tijd om te begrijpen hoe capaciteit werkt en hoe u replica's en partities kunt aanpassen om schommelingen in de werkbelasting aan te kunnen.

In Azure Cognitive Search is capaciteit gebaseerd op replica's en partities. Replica's zijn kopieën van de zoekmachine. Partities zijn opslageenheden. Elke nieuwe zoekservice begint met één van beide, maar u kunt elke resource onafhankelijk opschalen om ruimte te bieden aan wisselende workloads. Het toevoegen van een van beide resources is factureerbaar.

De fysieke kenmerken van replica's en partities, zoals verwerkingssnelheid en schijf-I/O, variëren per servicelaag. Als u hebt ingericht op Standard, zijn replica's en partities sneller en groter dan die van Basic.

Het wijzigen van de capaciteit gebeurt niet onmiddellijk. Het kan tot een uur duren voordat partities in gebruik worden genomen of buiten gebruik worden gesteld, met name voor services met grote hoeveelheden gegevens.

Bij het schalen van een zoekservice kunt u kiezen uit de volgende hulpprogramma's en benaderingen:

• Azure-portal
• Azure PowerShell
• Azure-CLI
• REST-API voor beheer

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 sharding-mechanisme ter ondersteuning van flexibele configuraties:

In het volgende diagram ziet u de relatie tussen replica's, partities, shards en zoekeenheden. Het toont een voorbeeld van hoe één index is 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 de shards 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. De zoekeenheden in de bovenste rij slaan één kopie op, bestaande uit de eerste replica, terwijl in de onderste rij een andere kopie wordt opgeslagen, bestaande uit de tweede replica.

Het bovenstaande diagram is slechts één voorbeeld. Veel combinaties van partities en replica's zijn mogelijk, maximaal 36 totaal aantal zoekeenheden.

In Cognitive Search is shard-beheer een implementatiedetail en niet-configureerbaar, maar als u weet dat een index sharding heeft, helpt dit om de incidentele afwijkingen in het classificatie- en automatisch aanvullen-gedrag te begrijpen:

• Rangschikkingsafwijkingen: Zoekscores worden eerst op shardniveau berekend en vervolgens samengevoegd in één resultatenset. Afhankelijk van de kenmerken van shard-inhoud kunnen overeenkomsten van de ene shard hoger worden geclassificeerd dan overeenkomsten in een andere. Als u intuïtieve rangschikkingen van tellers in zoekresultaten ziet, is dit waarschijnlijk het gevolg van de effecten van sharding, met name als indexen klein zijn. U kunt deze rangschikkingsafwijkingen voorkomen door ervoor te kiezen om scores globaal te berekenen voor de hele index,maar als u dit doet, wordt er een prestatiestraf in de weg gerekend.

• Afwijkingen automatisch aanvullen: Query's automatisch aanvullen, waarbij overeenkomsten worden gemaakt op de eerste paar tekens van een gedeeltelijk ingevoerde term, accepteren een fuzzy parameter die kleine afwijkingen in spelling bevat. Voor automatisch aanvullen is fuzzy matching beperkt tot termen in de huidige shard. Als een shard bijvoorbeeld 'Microsoft' bevat en een gedeeltelijke term 'micor' wordt ingevoerd, komt de zoekmachine overeen op 'Microsoft' in die shard, maar niet in andere shards die de resterende onderdelen van de index bevatten.

Schatting benaderen

Capaciteit en de kosten voor het uitvoeren van de service gaan hand in hand. Lagen leggen limieten op twee niveaus op: inhoud (bijvoorbeeld het aantal indexen voor een service) en opslag. Het is belangrijk om beide te overwegen, omdat de limiet die u het eerst bereikt, de effectieve limiet is.

Tellingen van indexen en andere objecten worden doorgaans bepaald door zakelijke en technische vereisten. U kunt bijvoorbeeld meerdere versies van dezelfde index hebben voor actieve ontwikkeling, testen en productie.

Storage behoeften worden bepaald door de grootte van de indexen die u verwacht te bouwen. Er zijn geen solide heuristieken of algemeenheden die helpen bij schattingen. De enige manier om de grootte van een index te bepalen, is door er een te bouwen. De grootte wordt gebaseerd op geïmporteerde gegevens, tekstanalyse en indexconfiguratie, zoals of u suggesties, filteren en sorteren inschakelen.

Voor zoeken in volledige tekst is de primaire gegevensstructuur een omgekeerde indexstructuur die andere kenmerken heeft dan brongegevens. Voor een omgekeerde index worden de grootte en complexiteit bepaald door inhoud, niet noodzakelijkerwijs door de hoeveelheid gegevens die u er in invoert. Een grote gegevensbron met hoge redundantie kan leiden tot een kleinere index dan een kleinere gegevensset die zeer variabele inhoud bevat. Het is daarom zelden mogelijk om de indexgrootte af te afleiden 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.

Schatting maken met de gratis laag

Een benadering voor het schatten van de capaciteit is om te beginnen met de gratis laag. De gratis service biedt maximaal drie indexen, 50 MB opslag en 2 minuten indexering. Het kan lastig zijn om een geschatte indexgrootte te schatten met deze beperkingen, maar dit zijn de stappen:

• Maak een gratis service.

• 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 indexeerers, kunt u de wizard Gegevens importeren in de portal gebruiken om de index te maken en te laden. Anders moet u REST en Postman of Visual Studio Code gebruiken om de index te maken en de gegevens te pushen. Voor het pushmodel moeten gegevens de vorm hebben van JSON-documenten, waarbij velden in het document overeenkomen met velden in de index.

• Verzamel informatie over de index, zoals grootte. Functies en kenmerken hebben invloed op de opslag. Door bijvoorbeeld suggesties toe te voegen (zoek-naar-u-type-query's) worden de opslagvereisten hoger.

  Met dezelfde gegevensset kunt u proberen meerdere versies van een index te maken, met verschillende kenmerken voor elk veld, om te zien hoe de opslagvereisten variëren. Zie 'Gevolgen Storage' in Een basisindex maken voor meer informatie.

Als u een ruwe schatting hebt, kunt u dat bedrag verdubbelen naar het budget voor twee indexen (ontwikkeling en productie) en vervolgens uw laag dienovereenkomstig kiezen.

Schatten met een factureerbare laag

Toegewezen resources kunnen grotere steekproeven en verwerkingstijden verwerken voor meer realistische schattingen van de indexhoeveelheid, grootte en queryvolumes tijdens de ontwikkeling. Sommige klanten gaan meteen aan de start met een factureerbare laag en evalueren vervolgens opnieuw wanneer het ontwikkelproject zich verder ontwikkelen.

1. Bekijk de servicelimieten voor elke laag om te bepalen of lagere lagen ondersteuning kunnen bieden voor het aantal indexen dat u nodig hebt. In de lagen Basic, S1 en S2 zijn de indexlimieten respectievelijk 15, 50 en 200. De Storage geoptimaliseerde laag heeft een limiet van 10 indexen omdat deze is ontworpen ter ondersteuning van een laag aantal zeer grote indexen.

2. Een service maken op een factureerbare laag:

   • Begin laag bij Basic of S1 als u niet zeker weet wat de verwachte belasting is.
   • Begin hoog, bij S2 of zelfs S3, als testen grootschalige indexering en querybelastingen omvat.
   • Begin met Storage geoptimaliseerd, op L1 of L2, als u een grote hoeveelheid gegevens indexeert en het laden van query's relatief laag is, net als bij een interne zakelijke toepassing.

3. Bouw een eerste index om te bepalen hoe brongegevens worden omgezet in een index. Dit is de enige manier om de indexgrootte te schatten.

4. Controleer opslag, servicelimieten, queryvolume en latentie in de portal. In de portal ziet u query's per seconde, beperkt aantal query's en zoeklatentie. Al deze waarden kunnen u helpen te bepalen of u de juiste laag hebt geselecteerd.

5. Voeg replica's toe als u hoge beschikbaarheid nodig hebt of als u trage queryprestaties ervaart.

   Er zijn geen richtlijnen voor het aantal replica's dat nodig is voor het laden van query's. De 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 Schalen voor prestaties en Query's bewaken voor hulp bij het schatten van QPS voor uw oplossing.

Overwegingen voor queryvolume

Query's per seconde (QPS) is een belangrijke metriek tijdens het afstemmen van de prestaties, maar het is doorgaans alleen een overweging als u vanaf het begin een hoog queryvolume verwacht.

De Standard-lagen kunnen een balans tussen replica's en partities bieden. U kunt de doorlooptijd van query's verhogen 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, langdurige queryvolumes verwacht, moet u hogere Standard-lagen overwegen, met meer krachtige hardware. U kunt vervolgens partities en replica's offline zetten of zelfs overschakelen naar een service met een lagere laag, als deze queryvolumes niet optreden. Zie prestaties en optimalisatie voor meer informatie over het berekenen Azure Cognitive Search querydoorvoer.

De Storage geoptimaliseerde lagen zijn handig voor grote gegevensworkloads, en ondersteunen meer algemeen beschikbare indexopslag voor 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 service level agreements (SLA's). Voor alle factureerbare lagen worden SLA's van kracht wanneer u voldoende redundantie voor uw service inrichten. U moet twee of meer replica's hebben voor query-SLA's (lezen). U moet drie of meer replica's hebben voor de SLA's voor query's en indexering (lezen/schrijven). Het aantal partities heeft geen invloed op SLA's.

Tips voor capaciteitsplanning

• Laat metrische gegevens bouwen rond query's en verzamel gegevens rond gebruikspatronen (query's tijdens bedrijfsuren, indexering buiten piekuren). Gebruik deze gegevens om beslissingen voor service-inrichting te nemen. Hoewel het niet praktisch is op elk uur of per dag, kunt u partities en resources dynamisch aanpassen om geplande wijzigingen in queryvolumes mogelijk te maken. U kunt ook ruimte bieden aan niet-geplande maar langdurige wijzigingen als niveaus lang genoeg zijn om actie te ondernemen.

• 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 wordt deze naast elkaar uitgevoerd totdat alle apps en aanvragen zijn gericht op het nieuwe eindpunt.

Wanneer 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 is geoptimaliseerd op basis van een set kenmerken die geschikt zijn voor verschillende scenario's. Als u een hogere endlaag kiest, hebt u mogelijk minder partities nodig dan bij S1. Een van de vragen die u moet beantwoorden via zelfgestuurde tests is of een grotere en duurdere partitie betere prestaties levert 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) te kunnen verwerken. Geen van beide workloads wordt op de achtergrond uitgevoerd. U kunt indexering plannen voor tijden waarin queryaanvragen van nature minder vaak voorkomen, maar de service zal anders geen prioriteit geven aan een taak boven een andere. Bovendien worden de queryprestaties door een bepaalde hoeveelheid redundantie soepeler wanneer services of knooppunten intern worden bijgewerkt.

Enkele richtlijnen om te bepalen of u capaciteit wilt toevoegen, zijn onder andere:

• Voldoen aan de criteria voor hoge beschikbaarheid voor een service level agreement
• De frequentie van HTTP 503-fouten neemt toe
• Er worden grote queryvolumes verwacht

Als algemene regel hebben zoektoepassingen vaak meer replica's nodig dan partities, met name wanneer de servicebewerkingen zijn gericht op querywerkbelastingen. Elke replica is een kopie van uw index, zodat de service aanvragen over meerdere kopieën kan laden. Alle taakverdeling en replicatie van een index wordt beheerd door Azure Cognitive Search en u kunt het aantal replica's dat voor uw service is toegewezen op elk moment wijzigen. U kunt maximaal 12 replica's toewijzen in een Standard-zoekservice en 3 replica's in een Basic-zoekservice. Replicatoewijzing kan worden gemaakt vanuit de Azure Portal of een van de programmatische opties.

Voor zoektoepassingen waarvoor gegevens bijna in realtime moeten worden vernieuwd, zijn proportioneel meer partities nodig dan replica's. Het toevoegen van partities verspreidt lees-/schrijfbewerkingen over een groter aantal rekenbronnen. Het biedt u ook meer schijfruimte voor het opslaan van aanvullende indexen en documenten.

Tot slot duurt het langer om een query uit te voeren op grotere indexen. Als zodanig kan het zijn dat elke incrementele toename van partities een kleinere maar evenredige toename van replica's vereist. De complexiteit van uw query's en queryvolume zal rekening houden met de manier waarop query's snel kunnen worden uitgevoerd.

Replica's en partities toevoegen of verminderen

1. Meld u aan bij Azure Portal en selecteer de zoekservice.

2. Open Instellingen pagina Schalen 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 er worden gebruikt (1). Als de eenheidsprijs $ 100 is (geen werkelijke prijs), zouden de maandelijkse kosten voor het uitvoeren van deze service gemiddeld $ 100 zijn.

   

3. Gebruik de schuifregelaar om het aantal partities te vergroten of te verlagen. Selecteer Opslaan.

   In dit voorbeeld worden een tweede replica en partitie toegevoegd. Let op het aantal zoekeenheden; Het is nu vier omdat de factureringsformule replica's is vermenigvuldigd met partities (2 x 2). Het verdubbelen van de capaciteit is meer dan het dubbele van de kosten van het uitvoeren van de service. Als de kosten voor de zoekeenheid $ 100 zouden zijn, zou de nieuwe maandelijkse factuur nu $ 400 zijn.

   Ga naar de pagina Prijzen voor de huidige kosten per eenheid van elke laag.

   

4. Na het opslaan kunt u 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 zodra het proces is gestart en er geen realtime bewaking is voor replica- en partitieaanpassingen. Het volgende bericht blijft echter zichtbaar terwijl wijzigingen worden doorgevoerd.

   

Hoe schaalaanvragen worden verwerkt

Na ontvangst van een schaalaanvraag, de zoekservice:

1. Controleert of de aanvraag geldig is.
2. Begint met het maken van een back-up van gegevens en systeemgegevens.
3. Controleert of de service zich al in een inrichtingstoestand (momenteel replica's of partities toevoegt of elimineert).
4. Begint met inrichten.

Het schalen van een service kan maar 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 opeenvolgende. Het systeem begint bijvoorbeeld met het inrichten wanneer dit veilig kan, wat kan tijdens het terugzetten van de back-up.

Fouten tijdens het schalen

Het foutbericht 'Service-updatebewerkingen zijn op dit moment niet toegestaan omdat we een eerdere 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:

1. Gebruik de REST API, Azure PowerShellof Azure CLI om de servicestatus op te halen.
2. Service get aanroepen
3. Controleer het antwoord op 'provisioningState': 'provisioning'

Als de status 'Inrichten' is, wacht u tot 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 dit een factor is bij een onderbreking van een schaaloefening.

Partitie- en replicacombinaties

Een Basic-service kan precies één partitie en maximaal drie replica's hebben voor een maximumlimiet van drie SUS's. De enige aanpasbare resource is replica's. U hebt minimaal twee replica's nodig voor hoge beschikbaarheid van query's.

Alle Standard- en Storage Geoptimaliseerde zoekservices kunnen uitgaan van de volgende combinaties van replica's en partities, afhankelijk van de limiet van 36 SU die is toegestaan voor deze lagen.

SE's, prijzen en capaciteit worden uitgebreid beschreven op de Azure-website. Zie Prijsinformatie voor meer informatie.

Volgende stappen