Scroll et recherche "enregistrée"

Elastic In Your Native Tongue Discussions en français
1

Bonjour,

Je reprends ce qui a été dit précédemment dans l'autre topic (en anglais), ça me permettra sûrement d'être un peu plus clair :).

Alors en fait, notre utilisateur disposera d'une interface dans laquelle il va pouvoir renseigner différents critères. Au fur et à mesure que les critères sont définis, nous faisons une recherche pour afficher le nombre total de documents impactés.

Suite à ça, l'utilisateur peut cliquer ou pas sur "payer". C'est à ce moment là qu'il faut que je traite les documents de la dernière recherche effectuée. Du moins, c'est l'idée que j'avais en tête jusqu'à présent.

Or, mon problème à l'heure actuelle c'est que les recherches vont me dire le nombre de résultat, mais vont générer des scrolls tout en me retournant une partie des documents qui du coup, ne seront plus traités plus tard.

Je sais pas si j'ai été clair ..? Est-ce que je me complique la vie?

Merci en tout cas pour votre aide.

2

C'était clair. Pas de pb.

Ben disons que dans Elasticsearch ce que tu veux faire exactement n'est pas possible réellement.
Mais il y a un compromis à mon avis à faire niveau IHM.

Peut-être donner une valeur indicative à tes utilisateurs sur le nombre de documents pendant qu'il affine et fait sa recherche en utilisant l'API _count par exemple.

Lorsqu'il a sa requête idéale, lui proposer un devis avec exactitude. Là, tu déclenches le scroll.

Autre solution. Tu déclenches un scroll systématique dès qu'il cherche la première fois. Puis à chaque fois qu'il affine, tu fais un DELETE du scroll_id et lances un nouveau scroll.
Avec un timeout qui lui laisse le temps de cliquer sur l'extraction.
Eventuellement avec un message dans l'IHM qui lui propose de relancer la recherche après 1 minutes par exemple (pour refaire le scroll)...

3

Ok, c'est bien ce que je pensais. "Nativement", on ne peut pas dire à un scroll "ne prend pas les premiers résultats lors de la recherche". Pour qu'il puisse eventuellement juste générer le set de document sans forcement les retourner.

Aussi :

Autre solution. Tu déclenches un scroll systématique dès qu'il cherche la première fois. Puis à chaque fois qu'il affine, tu fais un DELETE du scroll_id et lances un nouveau scroll.
Avec un timeout qui lui laisse le temps de cliquer sur l'extraction.
Eventuellement avec un message dans l'IHM qui lui propose de relancer la recherche après 1 minutes par exemple (pour refaire le scroll)...

C'est exactement ce à quoi je pensais, mais comme je l'ai dit plus haut, ceci va me "crop" certains résultats puisque lors de la recherche, je vais retourner des résultats qui ne seront plus dans le scroll lorsque le job sera effectué.

Bon, je vais continuer de réfléchir. Eventuellement, ce que je peux faire, c'est stocker les résultats initiaux ET le scroll ID que je passerai à mon job. C'est pas très pratique mais si c'est la seule solution que je vois là comme ça.

Merci en tout cas pour l'aide !

4

Je ne comprends pas pourquoi mais sans doute est-ce parce que je ne "vois" pas l'interface ou le workflow de l'utilisateur...

5

Ok, je pense qu'il est bon de préciser que c'est la première fois que j'utilise ES pour faire de la "vraie" recherche.

Du coup, peut-être que j'ai une "missconception" de ce qu'est le Scroll dans mon cas. Il me semble, si vous pouviez me confirmer, que lorsqu'on utilise l'API Search et que l'on renseigne le Scroll, la recherche se fait, retourne la première page de résultat, puis le reste est dans le scroll. Mais du coup, dans le scroll en soit, il n'y a pas la première page de résultat... C'est vraiment la seule chose qui me pause problème ^^.

Parce que sinon oui, à chaque critère je fais une recheche, j'enregistre le scroll id, et lors du clic sur le bouton paiement, j'envoie le scroll_id à mon job.

Je le redis, merci de prendre du temps pour me répondre, c'est fort appréciable une réactivité pareille. Surtout en français !

EDIT : Après test, effectivement, lorsque je renseigne le Scroll dans ma recherche, il me retourne bien les premiers résultats.

// GET subscriptions/_doc/_search?scroll=1m

    {
  "status": "ok",
  "message": {
    "_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBAAAAAAAAAE9FnZoNHQ5SFJSU3pHcGI5YXhNenlRUlEAAAAAAAABPhZ2aDR0OUhSUlN6R3BiOWF4TXp5UVJRAAAAAAAAAUAWdmg0dDlIUlJTekdwYjlheE16eVFSUQAAAAAAAAE_FnZoNHQ5SFJSU3pHcGI5YXhNenlRUlE=",
    "took": 22,
    "timed_out": false,
    "_shards": {
      "total": 4,
      "successful": 4,
      "skipped": 0,
      "failed": 0
    },
    "hits": {
      "total": 10,
      "max_score": 1,
      "hits": [
        {
          "_index": "subscriptions",
          "_type": "_doc",
          "_id": "61",
          "_score": 1
        },
        {
          "_index": "subscriptions",
          "_type": "_doc",
          "_id": "149",
          "_score": 1
        },
        {
          "_index": "subscriptions",
          "_type": "_doc",
          "_id": "200",
          "_score": 1
        },
        {
          "_index": "subscriptions",
          "_type": "_doc",
          "_id": "221",
          "_score": 1
        },
        {
          "_index": "subscriptions",
          "_type": "_doc",
          "_id": "169",
          "_score": 1
        }
      ]
    }
  }
}

Du coup, même si je passe le _scroll_id à mon job qui traitera tout ça plus tard; il me manquera les 5 premiers résultats ^^. Sachant que je risque plutôt d'avoir dans les 1k de résultat par page, je me vois mal passer les 1k premiers résultats en paramètre puis le reste via le _scroll_id ...

6

Please format your code, logs or configuration files using </> icon as explained in this guide and not the citation button. It will make your post more readable.

Or use markdown style like:

```
CODE
```

This is the icon to use if you are not using markdown format:

image
image.jpg764×92 16.4 KB

There's a live preview panel for exactly this reasons.

Lots of people read these forums, and many of them will simply skip over a post that is difficult to read, because it's just too large an investment of their time to try and follow a wall of badly formatted text.
If your goal is to get an answer to your questions, it's in your interest to make it as easy to read and understand as possible.
Please update your post.

^^^^ c'est en anglais mais tu comprends :wink:

Pour le scroll je ne comprends pas le problème. Pourquoi il te manquerait 5 documents? Pourquoi il y a un problème à récupérer 1000 documents ?

7

Pardon, effectivement l'indentation était foireuse :). C'est édité.

En fait, il n'y a pas de problème à récupérer 1000 documents. Ce que je veux montrer par le code du dessus, c'est que lorsque l'utilisateur modifie un critère, je fais la recherche et génère le scroll_id. Cela me retourne automatiquement la première partie de la recherche (dans mon exemples les 5 premiers documents).
Or j'aimerais uniquement le COUNT et que le scroll soit généré pour plus tard, sans me retourner les premiers documents, que je ne traiterait de toute façon pas de suite.

Vu que ce n'est pas possible, je dois faire la recherche, récupérer les premiers elements et les envoyer à mon job (en serialisant les données) ainsi que mon scroll_id. Or, sérializer 5 éléments c'est pas un problème (comme dans l'exemple), et c'est pas trop pesant niveau réseau. Par contre, sérializer 1000 documents, et passer le scroll_id pour s'occuper du reste, c'est déjà plus encombrant...

Je suppose que je n'ai de toute façon pas le choix ? Va falloir que je fasse ça comme ça je pense.

8

Est-ce que size peut être égal à 0?

9

Bonjour,

Malheureusement, non, ce n'est pas possible :

Validation Failed: 1: [size] cannot be [0] in a scroll context;

Je continue de fouiller.

10

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