Planifier un indexeur dans Recherche Azure AI

Définissez la schedule propriété pour configurer les indexeurs à exécuter selon une planification. La planification de l’indexeur est utile dans des situations telles que :

• Les données sources changent au fil du temps et vous souhaitez que l’indexeur traite automatiquement la différence.
• Les données sources sont très volumineuses et vous avez besoin d’une planification périodique pour indexer tout le contenu.
• Un index est rempli à partir de plusieurs sources à l’aide de plusieurs indexeurs et vous souhaitez décaler les travaux pour réduire les conflits.

Lorsque l’indexation ne peut pas se terminer dans la fenêtre de traitement standard de 2 heures, planifiez l’exécution de l’indexeur sur une cadence de 2 heures pour parcourir un grand volume de données. Tant que votre source de données prend en charge la logique de détection des modifications, les indexeurs peuvent récupérer automatiquement l’emplacement où ils se sont arrêtés à chaque exécution.

Une fois que vous avez configuré un indexeur selon une planification, il conserve cette planification jusqu’à ce que vous effaciez l’intervalle ou l’heure de début, ou que vous définissiez disabled sur true. Si un indexeur planifié cesse de déclencher de façon inattendue, consultez la FAQ sur le comportement de planification des étapes de récupération. Quitter l’indexeur selon une planification lorsqu’il n’y a rien à traiter n’a pas d’impact sur les performances du système. La vérification du contenu modifié est une opération relativement rapide.

Prérequis

• Indexeur valide configuré avec une source de données et un index.

• Détection des modifications dans la source de données. Stockage Azure et SharePoint intègrent la détection des modifications. Pour d’autres sources de données, telles que Azure SQL et Azure Cosmos DB, vous devez activer manuellement la détection des modifications.

Définition de planification

Une planification fait partie de la définition d’un indexeur. Si vous omettez la schedule propriété, l’indexeur s’exécute uniquement à la demande. La propriété comporte deux parties.

L’exemple suivant est une planification qui démarre le 1er janvier à minuit et s’exécute toutes les deux heures.

{
    "dataSourceName" : "hotels-ds",
    "targetIndexName" : "hotels-idx",
    "schedule" : { "interval" : "PT2H", "startTime" : "2024-01-01T00:00:00Z" }
}

Configurer une planification

Spécifiez des planifications dans une définition d’indexeur. Pour configurer une planification, utilisez le portail Azure, les API REST ou un Kit de développement logiciel (SDK) Azure.

var schedule = new IndexingSchedule(TimeSpan.FromDays(1))
{
    StartTime = DateTimeOffset.Now
};

var indexer = new SearchIndexer("demo-idxr", dataSource.Name, searchIndex.Name)
{
    Description = "Demo data indexer",
    Schedule = schedule
};

await indexerClient.CreateOrUpdateIndexerAsync(indexer);

FAQ sur le comportement de planification

Puis-je exécuter plusieurs travaux d’indexeur en parallèle ?

Vous pouvez exécuter plusieurs indexeurs simultanément, mais chaque indexeur est une seule instance. Vous ne pouvez pas exécuter deux copies du même indexeur simultanément.

Pour l’indexation basée sur le texte, le planificateur peut démarrer autant de travaux d’indexation que le service de recherche peut en prendre en charge, ce nombre étant déterminé par le nombre d’unités de recherche. Par exemple, si le service a trois réplicas et quatre partitions, vous pouvez avoir 12 travaux d’indexeur en exécution active, qu’ils soient lancés à la demande ou selon une planification.

Pour l’indexation basée sur les compétences, les indexeurs s’exécutent dans un environnement d’exécution spécifique. Pour cette raison, le nombre d’unités de service n’affecte pas le nombre de travaux d’indexeur basés sur des compétences que vous pouvez exécuter. Plusieurs indexeurs basés sur les compétences peuvent s’exécuter en parallèle, mais cela dépend de la disponibilité du processeur de contenu au sein de l’environnement d’exécution.

Les travaux planifiés commencent-ils toujours à l’heure désignée ?

Les processus d’indexation peuvent s’accumuler dans la file d’attente et peuvent ne pas démarrer exactement à l’heure indiquée, en fonction de la charge de traitement et d’autres facteurs. Par exemple, si un indexeur est toujours en cours d’exécution lorsque l’exécution planifiée suivante est définie pour démarrer, l’exécution en attente est reportée jusqu’à l’occurrence planifiée suivante, ce qui permet à la tâche actuelle de se terminer.

Pour rendre ce comportement plus concret, considérez l’exemple suivant. Supposons que vous configuriez une planification pour un indexeur avec un intervalle d’une heure et une heure de début fixée au 1er janvier 2024 à 08:00:00 UTC. Voici ce qui peut se produire lorsque l’exécution de l’indexeur prend plus d’une heure :

1. La première exécution de l’indexeur commence à ou autour du 1er janvier 2024 à 8h00 UTC. Supposons que cette exécution prend 20 minutes (ou une durée inférieure à 1 heure).

2. La deuxième exécution de l’indexeur commence le 1er janvier 2024 à 9h00 UTC ou autour de cette date. Supposons que cette exécution prend 70 minutes ( plus d’une heure) et qu’elle ne se termine pas jusqu’à 10:10 UTC.

3. La troisième exécution est planifiée pour démarrer à 10h00 UTC, mais à ce moment l’exécution précédente est toujours en cours. Cette exécution planifiée est donc ignorée. L’exécution suivante de l’indexeur ne démarre pas jusqu’à 11h00 UTC.

Dans de rares cas, par exemple pendant une opération de maintenance ou lors de la reprise après des conditions transitoires, le système place plusieurs exécutions de l’indexeur en file d’attente. Lorsque cette condition se produit, l’indexeur exécute des charges de travail en attente de manière séquentielle dans la fenêtre planifiée. Par exemple, si un indexeur est configuré pour s’exécuter toutes les heures et que plusieurs exécutions ont été retardées ou déclenchées à la demande, ces tâches en file d’attente s’exécutent les unes à la suite des autres jusqu’à ce que la file d’attente soit vidée. Ces exécutions ne sont pas des exécutions supplémentaires, mais représentent des exécutions planifiées ou demandées précédemment. Bien que ce comportement soit rare dans la plupart des scénarios, l’indexeur est conçu pour traiter finalement toutes les tâches mises en file d’attente afin de maintenir la cohérence et la fraîcheur des données.

Que se passe-t-il si l’indexation échoue à plusieurs reprises sur le même document ?

Si vous configurez un indexeur selon une planification donnée, mais qu’il échoue à plusieurs reprises sur le même document à chaque exécution, l’indexeur commence à s’exécuter à une fréquence moindre (jusqu’à atteindre l’intervalle maximal, à savoir une exécution au moins toutes les 2 heures ou toutes les 24 heures, selon divers facteurs d’implémentation), jusqu’à ce qu’il parvienne de nouveau à progresser. Si vous croyez que vous avez résolu le problème sous-jacent, exécutez l’indexeur manuellement. Si l’indexation réussit, l’indexeur retourne à sa planification régulière. Si l’indexeur ne revient pas à son calendrier habituel après une exécution manuelle réussie, consultez la question suivante.

Un indexeur programmé a cessé de se déclencher. Comment réinitialiser sa planification ?

Si un indexeur planifié s’arrête, désactivez-le, puis réactivez-le pour réinitialiser la programmation. Signe que cette récupération est nécessaire : aucune nouvelle exécution n’apparaît dans l’historique d’exécution, même si la planification est configurée et que la source de données a changé.

Définir disabled sur true suspend la planification. Le fait de la rétablir à false (ou d’omettre la propriété) relance la planification, en prenant l’heure actuelle comme nouveau point de départ pour l’intervalle configuré.

Étapes suivantes

Pour les indexeurs qui s’exécutent selon une planification, vous pouvez surveiller les opérations en récupérant l’état du service de recherche ou en obtenant des informations détaillées en activant la journalisation des ressources.

• Surveiller l’état de l’indexeur de recherche
• Collecter et analyser des données de journal
• Indexer de grands jeux de données