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 repository and the implementation in such projects as GitHub, SoundCloud, Stack Overflow and LinkedIn bear testimony to its great popularity. The part “Elastic” says it all about the nature of the system, whose capabilities are enormous: from a simple file search on a small scale, through knowledge discovery, to big data analysis in real time.What makes Elastic a more powerful than the competition is the set of default configurations and behaviors, which allow to create a cluster and start adding documents to the index in a couple of minutes. Elastic will configure a cluster for you, will define an index and define the types of fields for the first document obtained, and when you add another server, it will automatically deal with dividing index data between servers.Unfortunately, the above mentioned automation makes it unclear to us what the default settings implicate, and it often turns out to be misleading. This article starts a series where I will be dealing with the most popular gotchas, which you might encounter during the process of Elastic-based app creation.

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.