La version 1.6 de RediSearch ajoute des fonctionnalités et améliore les performances

La version 1.6 de RediSearch ajoute des fonctionnalités et améliore les performances

Le populaire Module RediSearch a été conçu pour étendre les capacités de Redis en ajoutant un index secondaire avec des capacités de recherche en texte intégral ultra-rapides. RediSearch a été extrêmement bien accueilli, rassemblant plus de 150 000 pulls Docker, 2 000 étoiles GitHub, 230 fourches et 10 pilotes dans une dizaine de langues différentes. Et les clients en profitent déjà—voir ceci vidéo sur la mise à l’échelle 100X de GAP à l’aide de Redis.

Aujourd’hui, nous sommes fiers d’annoncer RediSearch 1.6, qui refactorise le module d’origine pour améliorer les performances et ajoute de nouvelles fonctionnalités importantes, notamment l’aliasing, une API de bas niveau et une validation de requête améliorée, ainsi que faire de la récupération de place Fork le module. par défaut, tous conçus pour rendre le développement avec RediSearch encore plus puissant et pratique.

À l’origine, nous avons créé RediSearch pour prendre en charge un index secondaire unique (ou limité en quantité) qui évoluerait en mettant à l’échelle Redis. Au fil des ans, les utilisateurs de Redis se sont tournés vers RediSearch pour une grande variété de cas d’utilisation qui suppriment et recréent fréquemment le même index tout en l’interrogeant ou qui créent des milliers de petits index de courte durée. Dans RediSearch 1.6, nous avons refactorisé notre base de code pour mieux prendre en charge ces cas d’utilisation. Ce faisant, nous avons ajouté une meilleure validation des requêtes et performances améliorées jusqu’à 73 % ! Nous avons également ajouté deux nouvelles fonctionnalités majeures : Crénelage laisse Redis se référer à un index existant et basculer facilement vers un autre index, tandis qu’un nouveau API de bas niveau rend RediSearch disponible en tant que bibliothèque pouvant être utilisée par d’autres modules Redis écrits en C ou Rouiller. Cela signifie que les développeurs n’aurez pas à apprendre des langages de requête de recherche supplémentaires pour utiliser n’importe quel module Redis. Avec cette bibliothèque, les modules peuvent facilement ajouter des capacités d’indexation secondaires. RedisGraph 2.0 est le premier module Redis généralement disponible à exploiter cette fonctionnalité en offrant des capacités de recherche en texte intégral. La liste complète des fonctionnalités ajoutées dans RediSearch v.1.6 peut être trouvée sur GitHub.

Basé sur des tests avec notre référence de recherche en texte intégral (FTSB), RediSearch 1.6 apporte des avantages significatifs en termes de performances par rapport à la version 1.4. Plus précisément, RediSearch 1.6 a augmenté le débit de recherche en texte intégral simple jusqu’à 63 %, tout en réduisant la latence (q50) jusqu’à 64 %. Pour les requêtes agrégées, le débit est passé de 15 % à 64 %.

(Pour en savoir plus sur les améliorations de performances dans RediSearch 1.6, consultez notre article de blog sur RediSearch 1.6 améliore les performances jusqu’à 64 %.)

Le crénelage ajoute de la flexibilité

L’une des fonctionnalités les plus puissantes de RediSearch est que chaque mise à jour d’un document met à jour l’index de manière atomique. Contrairement aux autres moteurs de recherche basés sur Lucene, l’index RediSearch n’a pas à rattraper les données. En d’autres termes, vous lisez toujours vos propres écrits.

Dans certaines applications, cependant, il est plus efficace ou pratique de recharger un index entier plutôt que de suivre les différences entre deux chargements en bloc. La mise à jour de vos applications pour se connecter à l’index nouvellement chargé en cours d’exécution sans temps d’arrêt est presque impossible, nous avons donc introduit l’aliasing pour rendre RediSearch encore plus flexible et puissant. Significativement, Recherche élastique les utilisateurs trouveront que l’ajout d’alias à RediSearch facilitera leur chemin de migration vers Redis, comme illustré dans l’exemple ci-dessous.

La création d’alias vous permet de rediriger les requêtes d’application d’un nom d’index logique vers un index physique sous-jacent. La mise à jour d’un alias vous permet de rediriger en toute transparence vos requêtes applicatives vers un autre index physique, sans aucun temps d’arrêt!

Cet exemple simple explique comment fonctionne l’aliasing avec les commandes RediSearch :

redis:6379> FT.CREATE idxA SCHEMA title TEXT
OK
redis:6379> FT.ADD idxA a:doc1 1.0 FIELDS title "plump fiction"
OK
redis:6379>
FT.ALIASADD films idxA
OK
redis:6379> FT.SEARCH movies "@title:fiction"
1) (integer) 1
2) "a:doc1"
3) 1) "title"
2) "
dodu fiction"
redis:6379> FT.CREATE idxB SCHEMA title TEXT
OK
redis:6379> FT.ADD idxB b:doc1 1.0 FIELDS title "pulp fiction"
OK
redis:6379>
Films FT.ALIASUPDATE idxB
OK
redis:6379> FT.SEARCH movies "@title:fiction"
1) (integer) 1
2) "b:doc1"
3) 1) "title"
2) "
pulpe fiction"

image1
Visualisation du fonctionnement des alias.

À l’avenir, il est possible d’améliorer cette fonctionnalité avec la possibilité d’aliaser plus d’un index, par exemple, pour répondre à l’interrogation de deux index responsables d’un ensemble distinct de documents.

Une nouvelle API de bas niveau

Depuis la création de l’API de module de Redis, Redis et la communauté Redis ont créé un large ensemble de modules. Certains ajoutent un tout nouveau modèle de base de données à Redis, certains vous permettent d’exécuter du code avec les données, et d’autres ajoutent de nouvelles structures de données à Redis. Nous avons remarqué, cependant, que plusieurs modules ont commencé à construire leur propre façon propriétaire d’indexer les données. Dans RedisGraphpar exemple, les index sur les propriétés des nœuds du graphe sont conservés dans une ziplist et RedisTimeSeriesRedisTimeSeries utilise des ensembles triés pour interroger les données de séries chronologiques qui ont certaines conditions d’étiquette.

Screen Shot 2020 03 10 at 3.04.43 PM
Certains modules Redis ont actuellement leur propre façon d’indexer les données.

Ces implémentations fournissent des fonctionnalités de recherche de base, mais pour RediSearch 1.6, nous voulions supprimer la duplication de code et améliorer la fonctionnalité de recherche dans les cas d’utilisation clés. avec un langage de requête commun. Dans les bases de données de graphes, par exemple, il est courant d’effectuer une recherche floue sur les propriétés des nœuds pour permettre une recherche assistée par un graphe. Les cas d’utilisation de séries chronologiques, quant à eux, impliquent souvent toutes les séries chronologiques où une étiquette correspond à un certain préfixe. D’autres modules Redis pourraient bénéficier de la prise en charge de l’indexation secondaire. Imaginez ce que vous pourriez faire si RedisJSON avait des capacités de recherche en texte intégral !

Ainsi, pour RedisSearch 1.6, nous avons créé une API de bas niveau qui peut être consommée par d’autres modules Redis. RedisGraph v2.0 est le premier module Redis généralement disponible qui utilise ce module. La recherche assistée par graphique vous permet de trouver des nœuds dans un graphique pour lesquels les propriétés correspondent à une requête de recherche en texte intégral et de les classer en fonction des connexions que ces nœuds ont dans le graphique.

La fonctionnalité de recherche de LinkedIn est un excellent exemple de recherche assistée par graphique : les personnes et les entreprises les plus proches de vous dans votre réseau apparaissent plus haut dans vos résultats de recherche. Nous continuons à travailler sur développement d’API de bas niveau pour RedisTimeSerieset vous pouvez déjà essayer le version d’aperçu de RedisJSON 2.0 avec RediSearch intégré.

Le ramasse-miettes fork devient la valeur par défaut

Comme la plupart des moteurs de recherche basés sur un index inversé, lorsque vous supprimez ou mettez à jour un document, RediSearch marque efficacement le document comme devant être supprimé. Un processus de récupération de place s’exécute régulièrement pour récupérer la mémoire utilisée pour stocker les documents supprimés. Marquer le document comme supprimé et rendre la suppression physique asynchrone réduit le temps d’exécution de la commande tout en préservant l’exactitude des requêtes.

Dans RediSearch 1.4, le comportement par défaut consistait à verrouiller le thread principal, ce qui introduisait des pics de latences de lecture lors de la récupération de place. Pour surmonter cela, RediSearch 1.4 offrait une option Fourchette GC qui s’exécute en parallèle avec le processus de requête principal, permettant une analyse ininterrompue de tous les documents supprimés. Cette approche offre des performances supérieures pour les environnements à fort trafic, où de nombreuses requêtes sont émises et/ou de nombreuses écritures sont effectuées. Nous avons donc fait de ce comportement la valeur par défaut dans RediSearch 1.6.

Vous pouvez voir les avantages de Fourchette GC dans ce test en deux phases. Dans la première phase, nous insérons 10 millions de nouveaux documents. Après cette phase, nous supprimons l’index. En phase deux, le trafic est mixte : insertion et mise à jour de 5 millions de documents. Cependant, pour chaque opération d’écriture, il y a aussi une opération de mise à jour (un taux de mise à jour de 50 %), donc cela totalise également 10 millions d’opérations.

image5
Capture d’écran du tableau de bord de surveillance Grafana surveillant le débit pendant le test Fork GC décrit ci-dessus pour RediSearch 1.4 et 1.6.

Le graphique montre clairement comment ancien ramassage des ordures les performances se dégradent rapidement lorsqu’il y a un taux de mise à jour de 50 %. En général, nous avons observé une amélioration de 8 % des taux de mise à jour faibles et jusqu’à 70 % d’amélioration des performances à des taux de mise à jour élevés avec le nouveau Ramassage des ordures à la fourche :

image7

Enfin, RediSearch 1.6 bénéficie également d’une meilleure validation des requêtes. S’il est déterminé qu’une requête contient des erreurs logiques ou de syntaxe, un message d’erreur approprié est renvoyé à l’utilisateur, plutôt que de laisser la requête s’exécuter sans résultat. RediSearch 1.6 renvoie également une erreur lorsqu’un mot-clé non reconnu est soumis. Cette validation de requête améliorera l’expérience du développeur et réduira la courbe d’apprentissage de RediSearch. Notez également que RediSearch 1.6 est pris en charge par RedisInsightnotre interface de gestion basée sur un navigateur récemment annoncée pour votre déploiement Redis.

Quelle est la prochaine étape pour RediSearch ?

Pour l’avenir, nous avons de nombreuses fonctionnalités intéressantes sur la feuille de route, telles que la prise en charge de la recherche de polygones et la création d’un parallélisme plus élevé pour les requêtes de lecture sur une seule partition. Cela nous aidera à atteindre un débit plus élevé pour les requêtes d’agrégation sans avoir à augmenter le nombre de partitions.

Le premier, cependant, est RediSearch basé sur un schéma. Dans la version actuelle de RediSearch, si vous souhaitez que l’index soit synchronisé avec les hachages représentant votre document, vous devez ajouter les documents en émettant soit un AJOUTER ou un ADDHASH commande. Si des mises à jour du hachage se produisent par la suite sans que ces commandes soient exécutées, elles ne seront pas reflétées dans l’index. Avec RediSearch basé sur un schéma, vous pourrez définir des règles pour lesquelles les hachages doivent être indexés automatiquement. À chaque écriture dans un hachage, RediSearch mettra à jour de manière synchrone ou asynchrone l’index des hachages qui correspondent aux règles.

Encore plus important que les nouvelles fonctionnalités, bien sûr, la version 1.6 est la RediSearch la plus rapide de tous les temps (en savoir plus sur les améliorations des performances de RediSearch 1.6 ici.) Vos applications connaîtront des latences plus cohérentes, avec moins de pics, pour tous les types de requêtes.

Enfin, nous tenons à remercier les membres de la communauté Redis qui ont contribué à rendre RediSearch 1.6 plus robuste en repérant des bogues dans les versions précédentes.

Development Source

Related Posts

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

RLEC 4.2.1 apporte des contrôles granulaires à la haute disponibilité et aux performances

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Comment HolidayMe utilise Redis Enterprise comme base de données principale

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Annonce de RedisGears 1.0 : un moteur sans serveur pour Redis

Clés Redis dans la RAM |  Redis

Clés Redis dans la RAM | Redis

No Comment

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *