facetting et besoin mémoire

[Benoît]

Bonjour à tous,

J'aimerais confirmer avec vous cette question qui revient souvent sur la ML anglaise.

On a rapidement des problèmes de mémoire lorsqu'on cherche à faire du facetting sur un champs qui est peu normalisé. Exemple:

[2012-07-06 14:47:23,302][WARN ][index.cache.field.data.resident] [hyperion] [mediaindex] loading field [theme] caused out of memory failure

Au départ je pensais qu'en filtrant par exemple les documents d'une seule journée, le nombre de valeur unique soit suffisamment faible pour permettre le facetting,
mais il semble que dans tous les cas ES charge l'index complet des termes de ce champs. Même avec un filtre qui ne match qu'une centaine de documents le problème se produit.

Quel est votre avis ?

Pour info mon index de test contient 90 millions de document de type article de presse avec, entre autres, des champs auteurs et thème sur lesquels j'aurais aimé faire du facetting. 24 Go sont dédié à la JVM.

Merci.

Benoît

P.S.: des liens vers des discutions sur ce sujet sur la ML principale

- https://groups.google.com/d/topic/elasticsearch/-CV_j0zXmu0/discussion
- https://groups.google.com/d/topic/elasticsearch/SbmPgw8lCYI/discussion

[David Pilato]

Oui la facette n'est pas filtrée par défaut. Si tu veux restreindre sa portée, il faut filtrer la facette.

http://www.elasticsearch.org/guide/reference/api/search/facets/index.html

Shay a annoncé il y a quelques mois qu'une des prochaines versions consiste à optimiser la mémoire pour les facettes.

David

--

--
---
Vous pouvez également poster et consulter les réponses en anglais sur le groupe Elasticsearch https://groups.google.com/group/elasticsearch
 
Si vous avez également posté votre question sur la mailing list elasti...@googlegroups.com, merci d'indiquer ici le lien vers cette discussion pour faciliter le suivi.
 
Twitter : @ElasticsearchFR https://twitter.com/#!/ElasticsearchFR
Site web (English) : http://www.elasticsearch.org/

[Benoît LAURENT]

Salut,

Le 6 juillet 2012 19:06, David Pilato <da...@pilato.fr> a écrit :
> Oui la facette n'est pas filtrée par défaut. Si tu veux restreindre sa
> portée, il faut filtrer la facette.
> http://www.elasticsearch.org/guide/reference/api/search/facets/index.html

Ce n'est pas si simple. La page
https://karussell.wordpress.com/2012/01/19/birds-eye-view-on-elasticsearch-its-query-dsl/
explique bien le QSL et notamment les trois possibilitées de filtrage
et leurs liens avec le facetting.

Par defaut le facetting s'applique au résultat de la query.
typiquement j'utilise une "filtered" query et les comptages se font
bien sur les données filtrées. Si on veux que le comptage s'applique à
un sous ensemble du résultat on peut ajouter à la définition de chaque
facet un "facet_filter". Le dernier cas est celui du "filter" à la
racine du QSL il n'a pas d'impact sur les comptages. J'imagine son
utilisation après une première requête pour filtrer par facet en
cliquant sur celles-ci sans changer les comptages.

J'ai donc refait un tests complet ce matin (d'ou mon délai de réponse)
avec un jeu d' 1.5 million de document et des filtres ramenant 1 jour
(245 docs), 1 mois (4329 docs), 1 an (124541 docs) et tout
(1502872docs).

Entre les différentes méthodes de filtrage décrit et les différents
cas (1 jour, 1 mois, etc.) je ne vois pas de différence dans l'usage
du HEAP, toujours autour de 600 Mo.

Je pense donc qu'ES charge l'index complet des termes du champs sur
lequel on fait le facetting.

> Shay a annoncé il y a quelques mois qu'une des prochaines versions consiste
> à optimiser la mémoire pour les facettes.

Oui je crois (j'espère) que ça devrait être dans la 0.20 car c'est
quelque chose de très demandé.

Benoît