Jointures & Elasticsearch

[Fadel Chafai]

Bonjour,

j'ai deux types sur mon index Annonces et produits.

Produits:

• _index: fadel
• _type: products
• _id: 103|2
• _version: 1
• _score: 1
• _source: {
  • code: 35569058
  • manufacturer: Packard Bell
  • tax_class_id: [ ]
  • visibility: 4
  • price: [ ]
  • in_stock: 1
  • .....
  • ....

Annonces

• _index: fadel
• _type: ads
• _id: 92
• _version: 1
• _score: 1
• _source: {
  • customer_id: 2
  • ads_id: 92
  • product_id: 28
  • price_current: 1200.0000
  • is_pro_customer: 0
  • state: 13
  • qty_current: 19
  }
• fields: {
  • _parent: 28|2
  }

Comment je peux recuuperer toutes les annonces d'un produits x,  et comment je peux avoir les infos du produit associer à une annonce ?

PS : 1 produit à une ou plusieurs annonces, une annonce est associer à un produit.

Merci

[David Pilato]

Bonjour,

 

Il me semble avoir vu passer ta question en anglais ? ;-)

 

A titre perso, si je peux, j'évite au maximum de me servir des parent/child et des nested.

Je raisonne ainsi :

Si tu cherches un produit, indexe un produit avec tous les champs dont tu as besoin pour la recherche.

Si tu cherches une annonce, indexe une annonce avec tous les champs dont tu as besoin pour la recherche, y compris ceux du produit auquel cela correspond.

 

Du coup, la recherche devient simple puisque le produit est un simple champ de l'annonce.

Donc, chercher les annonces d'un produit X, c'est en fait faire une recherche d'annonce sur le champ annonce.produit.nom=X

 

Sinon, tu peux essayer de passer par le has_parent ou le has_child (je n'ai jamais utilisé).

 

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/

 

--
David Pilato
http://www.scrutmydocs.org/
http://dev.david.pilato.fr/
Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

[Fadel Chafai]

donc j'aurai une duplication de mes données, 1000 annonces du mm produit = une duplication de 1000 fois les mm infos produit O_o je pense que ca va etre tres coûteux au niveau de l'espace de stockage Elasticsearch.

concernant mon cas comment je peux exécuter une requête avec hasparent sachant que j'ai deja le champ _parent: 28|2  ( parent = id produit ) sur mes annonces ?

merci

[David Pilato]

Oui. La question à mon sens est : "veut-on de la performance vs quel est le coût de l'espace disque aujourd'hui ?"

Ce que je dis sans cesse dans mes talks : "La plus grande difficulté quand tu fais du NoSQL est d'arriver à arrêter de penser SQL !"

Donc, la notion même de jointure est à éviter autant que possible.

On raisonne "Document" dans son ensemble et non pas Document splitté en plusieurs "tables".

 

Il y a des cas fonctionnels où évidemment, tu ne peux pas faire autrement, sauf au prix d'une réindexation.

Je prends souvent en exemple la notion de "facture" qui a un lien vers une "entreprise".

 

En SQL, tu fais une table facture avec une jointure avec entreprise.

 

Use case courant : tu génères ta facture en Avril 2012. 

Comment faire (simplement), lorsque ton entreprise déménage en Décembre 2012 et qu'elle souhaite consulter la facture d'Avril 2012 ?

 

Si tu as fait une simple jointure, son adresse de Décembre 2012 va apparaître sur la facture d'Avril 2012.

 

Je raisonne le NoSQL comme la prise d'une photographie à un instant T d'un document complet. La facture d'Avril 2012 prend la photo de l'entreprise (donc de son adresse) au moment de la génération.

Evidemment, tu peux gérer ça en SQL en gérant les versions (voir Hibernate Envers par exemple)...

 

Tout ça pour te dire que tu dois te poser simplement la question pour ton use case : Est-ce que le produit peut changer ("muter") après la génération de l'annonce pour ce produit ?

Si la réponse est OUI, alors tu es sans doute dans la bonne voie.

Si la réponse est NON, je reconsidérerais à ta place la modélisation avant d'aller plus loin dans les queries.

  

Pour ta demande particulière, n'ayant pas encore fait de parent /child, je préfère que quelqu'un d'autre sur la liste te réponde.

 

 

David.

[Fadel Chafai]

comme je vous ai expliqué dans mon message précédent, si je stock les infos du produit avec les infos d'annonce une simple recherche par produit sera très coûteuse  vu que le produit sera présent plusieurs fois ( dépend du nombre d'annonces associées à ce dernier )  donc j'aurai une duplication dans les résultats de recherche 

concernant l'espace disque j'ai 2 node chacun a 50G de HD et 16G de RAM,

PS :  elasticsearch ne gère pas le group by  :) 

Merci

[David Pilato]

Disons que le Group By peut être vu avec les facettes... 

--

David ;-)

Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

[Jérôme Mainaud]

Le 28/12/12 18:16, Fadel Chafai a �crit :
> comme je vous ai expliqu� dans mon message pr�c�dent, si je stock les

> infos du produit avec les infos d'annonce une simple recherche par

> produit sera tr�s co�teuse vu que le produit
> sera pr�sent plusieurs fois ( d�pend du nombre d'annonces associ�es �
> ce dernier ) donc j'aurai une duplication dans les r�sultats de
> recherche
Non, puisque tu chercheras sur l'index des produits. Puisque comme l'as
dit David dans son premier message, tu indexes ce que tu cherches.
> PS : elasticsearch ne g�re pas le group by :)
Pour �a, il y a les bases de donn�es relationnelles qui g�rent aussi les
jointures.
Le group by n'a pas de sens pour un moteur de recherche documentaire.
Les facettes permettent d'avoir une vision d'ensemble et peuvent
ressembler au group by.
Mais comme on indexe les documents qu'on veut trouver, on n'a pas besoin
du group by.

Sinon, tu peux aussi utiliser has_parent et has_child. Personnellement,
j'ai abandonn� leur utilisation qui est compliqu�e et ne donne pas le
r�sultat que j'attendais. La double indexation est bien plus simple et
fonctionne � merveille.

J�r�me Mainaud
jer...@mainaud.com