Besoin d'aide pour appréhender le mapping

Elastic In Your Native Tongue Discussions en français
1

Bonjour a tous,
je suis nouveau et je cherche a me former sur Elasticsearch et toute sa stack.
J'ai vu que pour un moteur de recherche, c'est tres performant, du coup je voudrais passer mon forum sur ce modele.

Je rencontre un probleme de compréhension de mapping. Je vais avoir des Threads qui contiendrons des commentaires et sous commentaires. jusque la rien d'anormal, mais j'arrive pas a comprendre comment gerer les documents parent/enfants.
Voici le mapping que je prévois

{
"settings" : {
"number_of_shards" : 5,
"number_of_replicas": 3
},
"mappings" : {
"thread" : {
"properties" : {
"Account" : {
"properties": {
"id" : { "type" : "text" }
}
},
"label" : { "type" : "text" },
"status" : { "type" : "integer" },
"created_at" : { "type" : "date", "format" : "yyyy-MM-dd HH:mm:ss" },
"updated_at" : { "type" : "date", "format" : "yyyy-MM-dd HH:mm:ss" },
"deleted_at" : { "type" : "date", "format" : "yyyy-MM-dd HH:mm:ss" }
}
},
"comment" : {
"properties": {
"_parent": { "type": "comment" },
"child": {
"_parent": {
"type": "comment"
}
},
"body" : { "type" : "text" },
"status" : { "type" : "integer" },
"created_at" : { "type" : "date", "format" : "yyyy-MM-dd HH:mm:ss" },
"updated_at" : { "type" : "date", "format" : "yyyy-MM-dd HH:mm:ss" },
"deleted_at" : { "type" : "date", "format" : "yyyy-MM-dd HH:mm:ss" },
"Account" : {
"properties": {
"id" : { "type" : "text" }
}
},
"Thread" : {
"properties": {
"id" : { "type" : "text" }
}
}
}
}
}
}

Comment faire pour ne pas avoir a chaque envoie de sous commentaire, la réindexation du commentaire principale?
Idem pour lier les commentaires au Thread, afin de par exemple avoir une requête qui me remonte un Trhead avec ses 10 derniers commentaires ou sous commentaires.

J'ai beau chercher sur internet le principe parent enfant, mais ils n'en parlent jamais pour un meme Type de document...
Si une personne peux me mettre sur la piste.
Cordialement
Thibaut

2

Personnellement, je réserve la fonction parent/child (P/C) uniquement si cela est absolument nécessaire. Par exemple, j'ai 1 milliard de lignes de logs et je veux lier chaque log à une personne avec son numéro de bureau. J'ai pas envie dans ce cas très précis de mettre à jour un milliard de logs parce que le gars déménage.

Dans ton cas, c'est un forum et finalement le volume (sauf si il est hyper hyper populaire) restera "faible" pour chaque thread.

Du coup, je conseillerai plutôt une approche simple.

Les questions à se poser sont les suivantes.

  • Qu'est-ce que je cherche ?
  • De quoi ai-je besoin pour chercher ?

Tu as répondu. A priori, tu cherches des threads et non des commentaires. Si c'est le cas, alors indexe un objet thread avec tous ses commentaires associés dans le document. Genre:

POST thread/_doc
{
  "topic": "foo bar baz",
  "user": "dadoonet",
  "comments": [ {
    "date": "2018-09-26",
    "content": "foo bar baz 2"
  },{
    "date": "2018-09-25",
    "content": "foo bar baz 1"
  }   ]
}

Si tu cherches des commentaires et non des threads, alors indexe chaque commentaire individuellement. Mais dans ce cas, tu perds la notion de connection entre les threads:

POST comment/_doc
{
    "thread": {
      "topic":  "foo bar baz",
      "user": "dadoonet"
    },
    "date": "2018-09-26",
    "content": "foo bar baz 2"
}
POST comment/_doc
{
    "thread": {
      "topic":  "foo bar baz",
      "user": "dadoonet"
    },
    "date": "2018-09-25",
    "content": "foo bar baz 1"
}

Voici mon avis. Après, si tu veux vraiment faire du P/C, tu as un exemple ici: https://www.elastic.co/guide/en/elasticsearch/reference/6.4/parent-join.html

1 Like
3

Merci Dadoonet de ta réponse,
Effectivement ta réponse au Thread qui contient tous les comments c'est réellement ce que je cherche a faire, mais du coup comment cela va se passer pour ajouter un comment?
Je dois récupérer tous le Thread en json et ajouter un comment?
et du coup pour le mapping, je passe sur un nested au niveau du thread?

En tout cas merci, tu me confirme que parent/child n’était pas vraiment pour ce que je voulais faire.

4

Oui. Tu dois regénérer l'objet Thread entier.

A propos de nested, ben ça dépend du besoin. Si tu as plusieurs champs dans l'objet commentaire et que ta recherche sur ces champs est un AND sur le sous-objet, alors oui, il te faut du nested. Sinon, si c'est une simple recherche un peu fourre-tout (ce que j'espère pour toi car plus simple à mettre en oeuvre et plus performante), alors pas besoin de nested. Les objets commentaires seront tous mis à plat.

Genre:

{
  "topic": "foo bar baz",
  "user": "dadoonet",
  "comments": [ {
    "date": "2018-09-26",
    "content": "foo bar baz 2"
  },{
    "date": "2018-09-25",
    "content": "foo bar baz 1"
  } ]
}

Sera en fait indexé:

{
  "topic": "foo bar baz",
  "user": "dadoonet",
  "comments.date": [ "2018-09-26", "2018-09-25" ],
  "comments.content": [ "foo bar baz 2", "foo bar baz 1" ]
}
1 Like
5

Ok merci pour la réponse sur la régénération.
Par contre oui mon comment contient plusieurs champs:
body
user
sub-comment (j'ai la possibilité d'ajouter des sous commentaires, mais je souhaite me limiter a 3 niveau dans mon arbre.)

Pour mes recherches, je vais rechercher principalement sur le body ou avoir une requête qui me récupère tous les commentaires d'un user.

6

Pour mes recherches, je vais rechercher principalement sur le body ou avoir une requête qui me récupère tous les commentaires d'un user.

Donc pour ce use case là, c'est plutôt des commentaires qu'il faut indexer et pas des Threads.

Ce qui veut dire indexer deux fois:

  • Le Thread avec tous les commentaires
  • Chaque commentaire avec son Thread

Ce qui fait un peu doublon. Mais il faut vraiment se poser la question du besoin utilisateur.

Si ton but est d'être capable d'ouvrir un Thread qui correspond à un ou N commentaires, tu peux indexer juste les commentaires. Chaque commentaire qui matche te donne accès à l'ID du Thread que tu peux ensuite ouvrir normalement avec ton application en lisant la base de données.

Encore une fois, suivant ton besoin (c'est vraiment ce qui guide le choix technique), c'est une solution parmi d'autres. Le P/C est une autre solution peut-être adaptée si tu veux chercher les 2: commentaires et Threads...

7

Merci encore pour ses réponses,
N'aurais tu pas un livre a me conseiller? j'ai regardé pas mal de vidéos et de tutoriel, mais j'ai l'impression que le savoir est assez disparate.

8

Je te recommande https://www.elastic.co/guide/en/elasticsearch/guide/current/index.html

C'est vieux. Les exemples sont outdated mais les principes restent applicables. Pour moi, c'est la bible !

9

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.