ELASTICSEARCH GOTCHAS - PARTIE 1

Elasticsearch est un moteur de recherche basé sur une bibliothèque fiable et mature - Apache Lucene. Énorme activité dans git projet et la mise en œuvre dans des projets tels que GitHub, SoundCloud, Stack Overflow et LinkedIn témoignent de sa grande popularité. Le terme "Elastic" en dit long sur la nature du système, dont les capacités sont énormes : de la simple recherche de fichiers à petite échelle à l'analyse de données en temps réel, en passant par la découverte de connaissances. Ce qui rend Elastic plus puissant que la concurrence, c'est l'ensemble des configurations et des comportements par défaut, qui permettent de créer un cluster et de commencer à ajouter des documents à l'index en quelques minutes. Elastic configurera un cluster pour vous, définira un index et les types de champs pour le premier document obtenu, et lorsque vous ajouterez un autre serveur, il s'occupera automatiquement de diviser les données de l'index entre les serveurs.Malheureusement, l'automatisation mentionnée ci-dessus ne nous permet pas de comprendre clairement ce que les paramètres par défaut impliquent, et cela s'avère souvent trompeur. Cet article est le début d'une série dans laquelle je traiterai des problèmes les plus courants que vous pouvez rencontrer au cours du processus de création d'applications basées sur Elastic.

Le nombre de tessons ne peut pas être modifié

Indexons le premier document en utilisant index API:

 $ curl -XPUT 'http://localhost:9200/myindex/employee/1' -d '{
     "first_name" : "Jane",
     "last_name" : "Smith",
     "steet_number" :  12
   }'

A cet instant, Elastic crée un index pour nous, intitulé myindex. Ce qui n'est pas visible ici, c'est le nombre de shards assignés à l'index. Les shards peuvent être considérés comme des processus individuels responsables de l'indexation, du stockage et de la recherche d'une partie des documents d'un index entier. Au cours du processus d'indexation des documents, elastic décide dans quel shard un document doit être trouvé. Cette décision est basée sur la formule suivante :

fiche = hash(document_id) % nombre_de_fiches_primaires

Il est maintenant clair que le nombre de shards primaires ne peut pas être modifié pour un index qui contient des documents. Par conséquent, avant d'indexer le premier document, créez toujours un index manuellement, en indiquant le nombre de shards que vous estimez suffisant pour un volume de données indexées :

 $ curl -XPUT 'http://localhost:9200/myindex/' -d '{
     "settings" : {
       "number_of_shards" : 10
     }
   }'

Valeur par défaut pour nombre de tessons est de 5, ce qui signifie que l'index peut être étendu jusqu'à 5 serveurs, qui collectent les données pendant l'indexation. Pour l'environnement de production, la valeur des shards doit être fixée en fonction de la fréquence d'indexation prévue et de la taille des documents. Pour les environnements de développement et de test, je recommande de fixer la valeur à 1 - pourquoi ? La raison en est expliquée dans le prochain paragraphe de cet article.

Trier les résultats de la recherche de texte avec un nombre relativement faible de documents

Lorsque nous recherchons un document à l'aide d'une phrase :

 $ curl -XGET 'http://localhost:9200/myindex/my_type/_search' -d
   '{
     "query" : {
       "match" : {
         "title" : "Le renard brun rapide"
       }
     }
   }'

Elastic traite la recherche de texte en quelques étapes, tout simplement :

1. La phrase de la requête est convertie dans la même forme identique que celle dans laquelle le document a été indexé, dans notre cas il s'agira d'un ensemble de termes : ["rapide", "brun", "renard"] ("le" est supprimé parce qu'il est insignifiant),
2. l'index est parcouru pour rechercher les documents qui contiennent au moins un des mots recherchés,
3. chaque document correspondant est évalué en termes de pertinence par rapport à la phrase de recherche,
4. les résultats sont triés en fonction de la pertinence calculée et la première page de résultats est renvoyée à l'utilisateur.

Dans la troisième étape, les valeurs suivantes (entre autres) sont prises en compte :

1. combien de mots de la phrase de recherche se trouvent dans le document
2. fréquence d'apparition d'un mot donné dans un document (TF - term frequency)
3. si et combien de fois les mots correspondants apparaissent dans d'autres documents (IDF - inverse document frequency) - plus le mot est populaire dans d'autres documents, moins il est important.
4. Quelle est la durée du document ?

Le fonctionnement de l'IDF est important pour nous. Pour des raisons de performance, Elastic ne calcule pas cette valeur pour chaque document de l'index - au lieu de cela, chaque groupe (travailleur de l'index) calcule son IDF local et l'utilise pour le tri. Par conséquent, lors de la recherche dans l'index avec un faible nombre de documents, nous pouvons obtenir des résultats sensiblement différents en fonction du nombre d'unités dans un index et de la distribution des documents.

Imaginons que nous disposions de deux répertoires dans un index ; dans le premier, il y a 8 documents indexés avec le mot "renard", et dans le second, seulement 2 documents avec le même mot. Par conséquent, le mot "renard" sera très différent dans les deux répertoires, ce qui risque de produire des résultats erronés. C'est pourquoi il convient de créer un index composé d'un seul groupe primaire à des fins de développement :

 $ curl -XPUT 'http://localhost:9200/myindex/' -d
   '{"settings" : { "number_of_shards" : 1 } }'

L'affichage des résultats des pages de recherche "lointaines" tue votre cluster

Comme je l'ai déjà écrit dans les paragraphes précédents, les documents d'un index sont partagés entre des processus d'indexation totalement individuels - les "shards". Chaque processus est totalement indépendant et ne traite que les documents qui lui sont attribués.

Lorsque nous effectuons une recherche dans un index contenant des millions de documents et que nous attendons d'obtenir les 10 premiers résultats, chaque groupe doit renvoyer ses 10 résultats les mieux adaptés à l'index de la grappe. nœudqui a lancé la recherche. Les réponses de chaque groupe sont ensuite regroupées et les dix premiers résultats de la recherche sont sélectionnés (dans l'ensemble de l'index). Cette approche permet de répartir efficacement le processus de recherche entre plusieurs serveurs.

Imaginons que notre application permette de visualiser 50 résultats par page, sans les restrictions concernant le nombre de pages pouvant être visualisées par un utilisateur. Rappelons que notre index est constitué de 10 shards primaires (1 par serveur).

Voyons à quoi ressemblera l'acquisition des résultats de recherche pour la première et la centième page :

Page n° 1 des résultats de la recherche :

1. Le nœud qui reçoit une requête (contrôleur) la transmet à 10 unités de stockage.
2. Chaque tesson renvoie les 50 documents les mieux assortis, classés par ordre de pertinence.
3. Une fois que les réponses ont été reçues de chaque groupe, le contrôleur fusionne les résultats (500 documents).
4. Nos résultats sont les 50 premiers documents de l'étape précédente.

Page n° 100 des résultats de la recherche :

1. Le nœud qui reçoit une requête (contrôleur) la transmet à 10 unités de stockage.
2. Chaque groupe renvoie ses 5000 documents les mieux adaptés, classés par ordre de pertinence.
3. Après avoir reçu les réponses de chaque groupe, le contrôleur fusionne les résultats (50000 documents).
4. Nos résultats sont les documents de l'étape précédente positionnés 4901 - 5000.

Si l'on part du principe qu'un document a une taille de 1 Ko, cela signifie que, dans le deuxième cas, environ 50 Mo de données doivent être envoyées et traitées dans le cluster, afin de visualiser 100 résultats pour un utilisateur.

Il n'est pas difficile de constater que le trafic réseau et la charge de l'index augmentent de manière significative avec chaque page de résultat successive. C'est pourquoi il n'est pas recommandé de mettre à la disposition de l'utilisateur les pages de recherche les plus éloignées. Si notre index est bien configuré, l'utilisateur devrait trouver le résultat qui l'intéresse dans les premières pages de recherche, ce qui nous évitera de charger inutilement notre cluster. Pour prouver cette règle, vérifiez jusqu'à quel nombre de pages de résultats de recherche les moteurs de recherche web les plus populaires permettent l'affichage.

Il est également intéressant d'observer le temps de réponse du navigateur pour des pages de résultats de recherche successives. Par exemple, vous trouverez ci-dessous les temps de réponse pour des pages de résultats de recherche individuelles dans Google Search (le terme de recherche était "moteur de recherche") :

| Page de résultats de recherche (10 documents par page) | Temps de réponse
|——————————————–|—————|
| 1 | 250ms |
| 10 | 290ms |
| 20 | 350ms |
| 30 | 380ms |
| 38 (dernier disponible) | |

Dans la partie suivante, j'examinerai de plus près les problèmes liés à l'indexation des documents.