Recherche anticipée sur les champs d'un document dans azure DocumentDb

Question

Nous souhaitons utiliser DocumentDb comme magasin de données pour un certain nombre de sources de données et, à ce titre, nous lançons un POC rapide pour déterminer s'il répond aux critères que nous recherchons.

L'un des domaines que nous souhaitons mettre en place est celui des capacités de recherche anticipée pour certains champs. Celles-ci sont traditionnellement fournies à l'aide de la syntaxe SQL LIKE, qui ne semble pas être prise en charge à l'heure actuelle.

Recherche en ligne J'ai vu des gens parler de l'intégration de la recherche Azure, mais cela semble être un mécanisme très coûteux pour un cas d'utilisation aussi simple.

J'ai également vu des personnes mentionner l'utilisation d'UDF, mais cela semble nécessiter une analyse de l'ensemble de la collection, ce qui n'est pas pratique du point de vue des performances.

Quelqu'un a-t-il d'autres suggestions ? J'ai envisagé d'utiliser simplement une table SQL et d'initier une mise à jour à chaque fois qu'un document était inséré. \updated\deleted ?

Answer 1

DocumentDB prend en charge STARTSWITH et des index de plage pour prendre en charge la recherche par préfixe ou par anticipation.

Vous pouvez progressivement effectuer des requêtes telles que les suivantes en fonction de ce que l'utilisateur tape dans une zone de texte :

SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "H")
SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "Hi") 
SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "Hil")
SELECT TOP 10 * FROM hotel H WHERE STARTSWITH(H.name, "Hilton") 

Notez que vous devez configurer la collection, ou le chemin/la propriété que vous utilisez pour ces requêtes avec un paramètre indice de gamme . Il est possible d'étendre cette approche à d'autres cas :

Pour effectuer une recherche insensible à la casse, vous devez enregistrer la forme minuscule de la propriété de recherche et l'utiliser pour la recherche.

Answer 2

J'ai été confronté à une situation similaire, où une recherche rapide était nécessaire, alors qu'un utilisateur tapait des termes de recherche.

Mon scénario était que des milliers d'utilisateurs simultanés effectueraient ces recherches ; en testant cela sous charge, pour éviter la saturation et l'étranglement, nous avons constaté que nous devrions augmenter le débit de DocumentDB Request Unit (RU) à un point qui n'était pas financièrement viable. pour nous, dans nos circonstances spécifiques .

Nous avons décidé que DocumentDB était le mieux à même d'assurer le stockage persistant et la récupération "complète" des données - rôle qu'il remplit exceptionnellement bien - tandis qu'un petit cluster ElasticSearch jouait le rôle d'interface entre les deux systèmes. il a été conçu pour - text search , faceted search , weighted search , stemming et la plus pertinente par rapport à votre question, autocomplete analyzers et completion suggesters .

Le sujet des requêtes en amont, de la création d'index, de l'analyseur d'autocomplétion et du temps de requête "search as you type" dans ElasticSearch peut être trouvé. aquí , aquí y aquí

Le fait que vous prévoyez d'avoir plusieurs sources de données pourrait également rendre l'approche ElasticSearch plus attrayante pour l'agrégation des données de recherche.

J'ai utilisé le modèle Bitnami disponible sur le marché Azure pour créer des instances relativement petites et, surtout, cela m'a permis de placer le cluster sur le même réseau virtuel que mes autres composants, ce qui a grandement amélioré les performances.

Le coût était inférieur à celui d'Azure Search (qui utilise ElasticSearch sous le capot).