2016-04-21 5 views
1

Je cours un site en tant qu'application Web Azure, en utilisant Azure SQL, Azure Search et Azure Blob Storage. Actuellement l'index Azure Search (pour la recherche documentaire) est actuellement construit à l'aide d'un indexeur dessinant des données à partir de plusieurs tables SQL (via une vue) pour associer les permissions et autres métadonnées indirectement associées aux documents, y compris l'URL au doc dans Azure Blob Storage. La nouvelle mise à jour d'Azure Search semble permettre une recherche plein texte de blobs, mais la source de données doit être remplacée par le conteneur de stockage blob, en ignorant la méta supplémentaire qui sera remplie par mon Vue SQLAjouter une recherche de texte intégral à l'aide de Azure SQL Azure, Azure Blob Storage

Un document d'index de recherche peut-il être rempli par plusieurs sources de données ou un deuxième indexeur peut-il mettre à jour un document de recherche existant (pour ajouter les données de texte intégral au document)? J'ai cherché à capturer les données et à créer le texte intégral dans la base de données SQL lors du téléchargement de documents, mais sur les applications Web Azure, il ne semble pas y avoir d'analyseur approprié, et l'index de texte intégral Azure SQL ne ne supporte pas les documents Word ou PDF qui sont principalement ce que je télécharge.

Est-il possible de modifier l'indexeur pour incorporer l'indexation de texte intégral Azure Blob Storage ou devrais-je rechercher une approche complètement différente?

Répondre

2

Azure Les index de recherche peuvent être remplis par plusieurs indexeurs, ou même par un mélange d'indexeur et de votre propre API d'indexation d'appel de code. (En particulier, les indexeurs utilisent l'action d'indexation mergeOrUpload.)

Vous devez juste vous assurer que les indexeurs SQL et blob sont d'accord sur la clé de document, afin qu'ils mettent à jour les mêmes documents. HTH!

+0

Merci pour votre réponse, cela m'a donné la confiance nécessaire pour continuer sur cette voie et j'ai maintenant un succès mitigé. – Ben

+0

Je crée un indexeur avec son propre index, donc je ne corromprais pas mon index de source SQL original, et une fois que j'ai eu ce travail, j'ai réalisé à quel point votre deuxième commentaire concernant la clé de document était important. Sauf indication contraire, je pense que la seule clé de document pouvant être utilisée est le nom de fichier. Cela doit être codé, donc j'ai utilisé le paramètre 'base64EncodeKeys': true, mais cela ne correspond pas toujours au nom de fichier codé généré par l'indexeur SQL (généralement s'il y a moins de caractères communs). Le champ "Title" généré par l'indexeur SQL est également remplacé par null par l'indexeur de blob. – Ben

+0

1. S'il vous plaît envoyez-moi des détails sur ce que les noms ne correspondent pas - peut-être il y a des différences dans les chaînes (comme une barre oblique)? eugenesh au domaine Microsoft habituel. 2. Pour éviter l'écrasement, l'ensemble des champs de votre source de données blob et de la source de données SQL doit être disjoint, sauf la clé. Si vos données contiennent un champ Titre avec une valeur nulle, nous l'interprétons comme si vous vouliez effacer ce champ de l'index, ce qui est un scénario légitime. –