Partitionnement d'agrégats avec des groupes

Question

Je tente de partitionner un agrégat similaire à the example dans la documentation ElasticSearch, mais je ne parviens pas à faire fonctionner l'exemple.

L'indice est renseigné avec l'événement types:

public class Event 
{ 
    public int EventId { get; set; } 
    public string SegmentId { get; set; } 
    public DateTime Timestamp { get; set; } 
} 

Le EventId est unique, et chaque événement appartient à un SegmentId spécifique. Chaque SegmentId peut être associé à zéro à plusieurs événements.

La question est: Comment puis-je obtenir la dernière EventId pour chaque SegmentId?

Je m'attends à ce que le nombre de segments uniques soit de l'ordre de 10 millions, et le nombre d'événements uniques d'une ou deux fois supérieurs. C'est pourquoi je ne pense pas en utilisant top_hits par lui-même est approprié, comme suggested here. Par conséquent, le partitionnement.

Exemple:

avoir établi une démonstration d'indice peuplé de 1313 documents uniques (EventId), appartenant à 101 SegmentId distinctes (à savoir 13 événements par segment). Je m'attendrais à ce que la requête ci-dessous fonctionne, mais les mêmes résultats sont renvoyés quel que soit le numéro partition que je spécifie.

POST /demo/_search 
{ 
    "size": 0, 
    "aggs": { 
    "segments": { 
     "terms": { 
     "field": "segmentId", 
     "size": 15,     <-- I want 15 segments from each query 
     "include": { 
      "partition": 0,   <-- Trying to retrieve the first partition 
      "num_partitions": 7  <-- Expecting 7 partitions (7*15 > 101 segments) 
     } 
     }, 
     "aggs": { 
     "latest": { 
      "top_hits": { 
      "size": 1, 
      "_source": [ 
       "timestamp", 
       "eventId", 
       "segmentId" 
      ], 
      "sort": { 
       "timestamp": "desc" 
      } 
      } 
     } 
     } 
    } 
    } 
} 

Si je supprime le include et mis size à une valeur supérieure à 101, je reçois le dernier événement pour chaque segment. Cependant, je doute que c'est une bonne approche avec un million de compartiments ...

Answer 1

Il s'avère que j'étudiais la mauvaise question ... Mon exemple fonctionne réellement parfaitement.

Le problème était mon noeud local ElasticSearch. Je ne sais pas ce qui ne va pas, mais en répétant l'exemple sur une autre machine, ça a marché. Cependant, je n'ai pas réussi à faire fonctionner le partitionnement sur mon installation ES actuelle. J'ai donc désinstallé et réinstallé ElasticSearch à nouveau, puis l'exemple a fonctionné.

Pour répondre à ma question initiale, l'exemple que j'ai fourni est le chemin à suivre. J'ai résolu mon problème en utilisant le cardinality aggregate pour obtenir une estimation sur le nombre total de produits, à partir de laquelle j'ai dérivé un nombre approprié de partitions. Ensuite, j'ai bouclé la requête ci-dessus pour chaque partition, et ajouté les documents à une liste finale.

Answer 2

Vous essayez d'effectuer un Scroll de l'agrégation.

L'API Scroll est prise en charge uniquement pour les requêtes de recherche et non pour les agrégations. Si vous ne voulez pas utiliser le Top Hits, comme vous l'avez dit, en raison d'un grand nombre de documents, vous pouvez essayer:

1. Parent/Child approche - où vous créez des segments en tant que document parent et les événements dans le document enfant. Et chaque fois que vous ajoutez un enfant, vous pouvez mettre à jour le champ d'horodatage dans le document parent. Ce faisant, vous pouvez simplement interroger les documents parents et vous aurez votre identifiant de segment + l'horodatage du dernier événement

2. Une autre approche consisterait à essayer d'obtenir les meilleurs résultats seulement pour les dernières 24 heures. Vous pouvez donc ajouter une requête pour filtrer les 24 dernières heures, puis essayer d'obtenir les aggs en utilisant top_hit.