Indexeerfuncties in Azure Cognitive Search
Een indexer in Azure Cognitive Search is een crawler die doorzoekbare tekst en metagegevens uit een externe Azure-gegevensbron extraheert en een zoekindex vult met behulp van veld-naar-veld-toewijzingen tussen de brongegevens en uw index. Deze benadering wordt soms aangeduid als een 'pull-model' omdat de service gegevens op haalt zonder dat u code moet schrijven die gegevens aan een index toevoegt. Indexen zorgen ook voor de AI-verrijkingsmogelijkheden van Cognitive Search, waarbij externe verwerking van inhoud en route naar een index wordt geïntegreerd.
Indexeerders zijn alleen azure-indexen, met afzonderlijke indexeringen voor Azure SQL, Azure Cosmos DB, Azure Table Storage en Blob Storage. Wanneer u een indexeerder configureert, geeft u een gegevensbron (oorsprong) en een index (bestemming) op. Verschillende bronnen, zoals Blob Storage, hebben aanvullende configuratie-eigenschappen die specifiek zijn voor dat inhoudstype.
U kunt indexeren op aanvraag uitvoeren of volgens een terugkerend schema voor gegevensvernieuwing dat zo vaak als elke vijf minuten wordt uitgevoerd. Voor frequentere updates is een pushmodel vereist dat tegelijkertijd gegevens in zowel Azure Cognitive Search als uw externe gegevensbron bij werkt.
Gebruiksscenario's
U kunt een indexeermiddel gebruiken als enige manier voor gegevensingestie, of als onderdeel van een combinatie van technieken die inhoud laden en eventueel transformeren of verrijken. De volgende tabel bevat een overzicht van de belangrijkste scenario's.
| Scenario | Strategie |
|---|---|
| Eén gegevensbron | Dit patroon is het eenvoudigste: één gegevensbron is de enige inhoudsprovider voor een zoekindex. Vanuit de bron identificeert u één veld met unieke waarden dat als de documentsleutel in de zoekindex moet fungeren. De unieke waarde wordt gebruikt als een id. Alle andere bronvelden worden impliciet of expliciet aan bijbehorende velden in een index toewijst. Een belangrijk punt is dat de waarde van een documentsleutel afkomstig is uit brongegevens. Een zoekservice genereert geen sleutelwaarden. Bij volgende runs worden binnenkomende documenten met nieuwe sleutels toegevoegd, terwijl binnenkomende documenten met bestaande sleutels worden samengevoegd of overschreven, afhankelijk van of indexvelden null zijn of zijn ingevuld. |
| Meerdere gegevensbronnen | Een index kan inhoud uit meerdere bronnen accepteren, waarbij elke run nieuwe inhoud uit een andere bron haalt. Een resultaat kan een index zijn die documenten krijgt nadat elke indexer is uitgevoerd, met volledige documenten die volledig zijn gemaakt op basis van elke bron. Documenten 1-100 zijn bijvoorbeeld afkomstig uit Blob Storage, documenten 101-200 zijn afkomstig van Azure SQL, enzovoort. De uitdaging voor dit scenario ligt in het ontwerpen van een indexschema dat werkt voor alle binnenkomende gegevens en een documentsleutelstructuur die uniform is in de zoekindex. Systeemeigen worden de waarden die een document uniek identificeren, metadata_storage_path in een blobcontainer en een primaire sleutel in een SQL tabel. U kunt zich voorstellen dat een of beide bronnen moeten worden aangepast om sleutelwaarden in een gemeenschappelijke indeling op te geven, ongeacht de oorsprong van de inhoud. Voor dit scenario moet u een bepaalde mate van voorverwerking verwachten om de gegevens te homogeniseren, zodat deze in één index kunnen worden opgenomen. Een alternatief resultaat kunnen zoekdocumenten zijn die gedeeltelijk zijn ingevuld bij de eerste run en vervolgens verder worden ingevuld door volgende runs om waarden uit andere bronnen binnen te halen. Velden 1-10 zijn bijvoorbeeld afkomstig uit Blob Storage, 11-20 van Azure SQL, enzovoort. De uitdaging van dit patroon is ervoor te zorgen dat elke indexeringsuit voer is gericht op hetzelfde document. Voor het samenvoegen van velden in een bestaand document is een overeenkomst met de documentsleutel vereist. Zie Zelfstudie: Indexeren uit meerdere gegevensbronnen voor een demonstratie van dit scenario. |
| Meerdere indexeerders | Als u meerdere gegevensbronnen gebruikt, hebt u mogelijk ook meerdere indexeringen nodig als u de run time-parameters, de planning of veldtoewijzingen wilt variëren. Hoewel meerdere indexer-gegevensbronsets gericht kunnen zijn op dezelfde index, moet u voorzichtig zijn met indexer-runs die bestaande waarden in de index kunnen overschrijven. Als een tweede indexer-gegevensbron is gericht op dezelfde documenten en velden, worden alle waarden uit de eerste run overschreven. Veldwaarden worden volledig vervangen; een indexer kan geen waarden uit meerdere runs samenvoegen in hetzelfde veld.Een andere use-case voor multi-indexer is regiooverschrijdend uitschalen van Cognitive Search. Mogelijk hebt u kopieën van dezelfde zoekindex in verschillende regio's. Als u inhoud van de zoekindex wilt synchroniseren, kunt u meerdere indexeerfuncties laten ophalen uit dezelfde gegevensbron, waarbij elke indexeerfunctie gericht is op een andere zoekindex.Voor parallelle indexering van zeer grote gegevenssets is ook een strategie met meerdere indexeringen vereist. Elke indexer is gericht op een subset van de gegevens. |
| Inhoudstransformatie | Cognitive Search ondersteunt optioneel AI-verrijkingsgedrag dat afbeeldingsanalyse en verwerking van natuurlijke taal toevoegt om nieuwe doorzoekbare inhoud en structuur te maken. AI-verrijking is indexeringsgestuurd, via een gekoppelde vaardighedenset. Voor het uitvoeren van AI-verrijking heeft de indexer nog steeds een index en een Azure-gegevensbron nodig, maar voegt in dit scenario de verwerking van vaardighedensets toe aan de uitvoering van de indexer. |
Ondersteunde gegevensbronnen
Indexeerders crawlen gegevensopslag in Azure en buiten Azure.
- Amazon Redshift (in preview)
- Azure Blob Storage
- Azure Cosmos DB
- Azure Data Lake Storage Gen2
- Azure MySQL (in preview)
- Azure SQL Database
- Azure Table Storage
- Elasticsearch (in preview)
- PostgreSQL (in preview)
- Salesforce-objecten (in preview)
- Salesforce-rapporten (in preview)
- Smartsheet (in preview)
- Snowflake (in preview)
- SQL Managed Instance
- SQL Server op virtuele machines in Azure
Indexerverbindingen met externe gegevensbronnen kunnen worden gemaakt met behulp van standaard internetverbindingen (openbaar) of versleutelde privéverbindingen wanneer u virtuele Azure-netwerken voor client-apps gebruikt. U kunt ook verbindingen instellen om te verifiëren met behulp van een vertrouwde service-identiteit. Zie Granting access via private endpoints (Toegang verlenen via privé-eindpunten) en Verbinding maken aan een gegevensbron met behulp van een beheerde identiteit voor meer informatie over beveiligde verbindingen.
Fasen van indexeren
Bij een eerste run, wanneer de index leeg is, leest een indexer alle gegevens in die in de tabel of container zijn opgegeven. Bij volgende runs kan de indexer doorgaans alleen de gewijzigde gegevens detecteren en ophalen. Voor blobgegevens is wijzigingsdetectie automatisch. Voor andere gegevensbronnen, zoals Azure SQL of Cosmos DB, moet wijzigingsdetectie zijn ingeschakeld.
Voor elk document dat het ontvangt, implementeert of coördineert een indexer meerdere stappen, van het ophalen van documenten tot een laatste zoekmachine voor het indexeren. Optioneel stuurt een indexer ook de uitvoering en uitvoer van vaardighedensetsaan, ervan uitgaande dat er een vaardighedenset is gedefinieerd.
Fase 1: Document kraken
Documentbaring is het proces van het openen van bestanden en het extraheren van inhoud. Tekstinhoud kan worden geëxtraheerd uit bestanden in een service, rijen in een tabel of items in een container of verzameling. Als u vaardigheden en afbeeldingsvaardigheden aan een indexering toevoegt, kunnen met documentbaring ook afbeeldingen worden geëxtraheerd en in de wachtrij worden geplaatst voor verwerking.
Afhankelijk van de gegevensbron probeert de indexer verschillende bewerkingen uit te voeren om mogelijk indexeerbare inhoud te extraheren:
Wanneer het document een bestand is, zoals een PDF-bestand of een andere ondersteunde bestandsindeling in Azure Blob Storage,opent de indexer het bestand en extraheert deze tekst, afbeeldingen en metagegevens. Indexeerders kunnen ook bestanden openen vanuit SharePoint En Azure Data Lake Storage Gen2.
Wanneer het document een record in Azure SQL,extraheert de indexer niet-binaire inhoud uit elk veld in elke record.
Wanneer het document een record in Cosmos DB,extraheert de indexer niet-binaire inhoud uit velden en subvelden uit het Cosmos DB document.
Fase 2: Veldtoewijzingen
Een indexer extraheert tekst uit een bronveld en verzendt deze naar een doelveld in een index of kennisopslag. Wanneer veldnamen en -typen samenvallen, is het pad duidelijk. Mogelijk wilt u echter verschillende namen of typen in de uitvoer, in welk geval u de indexeringsmanager moet vertellen hoe het veld moet worden toe te geven.
Deze stap treedt op nadat het document is gekraakt, maar vóór transformaties, wanneer de indexer uit de brondocumenten leest. Wanneer u een veldtoewijzingdefinieert, wordt de waarde van het bronveld zonder wijzigingen naar het doelveld verzonden.
Fase 3: Uitvoering van vaardighedenset
Het uitvoeren van vaardighedensets is een optionele stap die ingebouwde of aangepaste AI-verwerking aanroept. Mogelijk hebt u deze nodig voor optische tekenherkenning (OCR) in de vorm van afbeeldingsanalyse als de brongegevens een binaire afbeelding zijn, of hebt u taalvertaling nodig als inhoud zich in verschillende talen.
Wat de transformatie ook is, de uitvoering van de vaardighedenset is waar verrijking plaatsvindt. Als een indexer een pijplijn is, kunt u een vaardighedenset zien als een 'pijplijn in de pijplijn'.
Fase 4: Toewijzingen van uitvoerveld
Als u een vaardighedenset op neemt, moet u waarschijnlijk uitvoerveldtoewijzingen opnemen. De uitvoer van een vaardighedenset is eigenlijk een informatiestructuur die het verrijkte document wordt genoemd. Met veldtoewijzingen voor uitvoer kunt u selecteren welke onderdelen van deze structuur u wilt toewijzen aan velden in uw index. Leer hoe u uitvoerveldtoewijzingen definieert.
Terwijl veldtoewijzingen verbatimwaarden uit de gegevensbron koppelen aan doelvelden, vertellen uitvoerveldtoewijzingen de indexeerster hoe de getransformeerde waarden in het verrijkte document moeten worden verbonden met doelvelden in de index. In tegenstelling tot veldtoewijzingen, die als optioneel worden beschouwd, moet u altijd een uitvoerveldtoewijzing definiëren voor elke getransformeerde inhoud die zich in een index moet bevinden.
In de volgende afbeelding ziet u een voorbeeld van een indexer voor foutopsporing in een sessieweergave van de indexerfasen: het kraken van documenten, veldtoewijzingen, het uitvoeren van vaardighedensets en toewijzingen van uitvoerveld.
Basiswerkstroom
Indexeerfuncties kunnen functies bieden die uniek voor de gegevensbron zijn. In dit opzicht variëren bepaalde aspecten van de configuratie van de indexeerfunctie of de gegevensbron al naar gelang het type indexeerfunctie. Alle indexeerfuncties hebben echter dezelfde basissamenstelling en voor alle indexeerfuncties gelden dezelfde vereisten. Hieronder vindt u de stappen die voor alle indexeerfuncties gemeenschappelijk zijn.
Stap 1: Een gegevensbron maken
Indexeren vereisen een gegevensbronobject dat een connection string en mogelijk referenties biedt. Roep de klasse Create Data Source (REST) of SearchIndexerDataSourceConnection aan om de resource te maken.
Gegevensbronnen worden geconfigureerd en onafhankelijk van de indexeerfuncties beheerd die gebruikmaken van de gegevensbronnen. Dit betekent dat een gegevensbron door meerdere indexeerfuncties kan worden gebruikt om tegelijkertijd meer dan één index te laden.
Stap 2: een index maken
Een indexeerfunctie automatiseert bepaalde taken met betrekking tot de opname van gegevens, maar het maken van een index behoort hier niet toe. Een vereiste is dat u een vooraf gedefinieerde index moet hebben met velden die overeenkomen met de velden in uw externe gegevensbron. Velden moeten overeenkomen op naam en gegevenstype. Zo niet, dan kunt u veldtoewijzingen definiëren om de koppeling tot stand te brengen. Zie Create an Index (REST) or SearchIndex class (Een index (REST) of SearchIndex-klasse maken) voor meer informatie over het structureren van een index.
Tip
Hoewel indexeerfuncties een index niet voor u kunnen genereren, kan de wizard Gegevens importeren in de portal helpen. In de meeste gevallen kan de wizard een indexschema afleiden uit bestaande metagegevens in de bron, met een voorlopig indexschema dat u kunt bewerken terwijl de wizard actief is. Als de index eenmaal is aangemaakt op de service, blijven verdere bewerkingen in de portal meestal beperkt tot het toevoegen van nieuwe velden. Overweeg de wizard voor het maken, maar niet voor het herzien van een index. Doorloop het Portaloverzicht om aan de slag te gaan.
Stap 3: de indexer maken en uitvoeren (of plannen)
Er wordt een indexeringsfunctie uitgevoerd wanneer u voor het eerst een indexeringsfunctie maakt in de zoekservice. Pas wanneer u de indexer maakt of uitvoeren, komt u erachter of de gegevensbron toegankelijk is of dat de vaardighedenset geldig is. Na de eerste run kunt u deze op aanvraag opnieuw uitvoeren met Behulp van Indexeruitvoeren, of u kunt een terugkerend schema definiëren.
U kunt de indexeringsstatus controleren in de portal of via get Indexer Status API. U moet ook query's uitvoeren op de index om te controleren of het resultaat is wat u verwacht.
Volgende stappen
Nu u bent geïntroduceerd, is een volgende stap het controleren van de eigenschappen en parameters van de indexer, planning en bewaking van de indexer. U kunt ook terugkeren naar de lijst met ondersteunde gegevensbronnen voor meer informatie over een specifieke bron.