Discussion :

[samfra]

Bonjour à tous,

je développe depuis des années, et notamment le framework de mon entreprise qui a servi a développer de nombreux projets SAV et type PIM.

Imaginez la chose suivante :
- Vous avez des produits qui sont composés de composants eux-même composés de sous-composants et ainsi de suite (on a donc ici un arbre de composants, appelé la nomenclature produit)
- Chacun de ses produits peut avoir de 0 à N attributs, que le client peut ajouter dynamiquement
- Ces attributs sont soit un simple texte (ex: une référence secondaire), un numérique (ex: le poids) ou une valeur
- Une valeur d'attribut est un objet qui a au moins un CODE et un titre qui se traduit (la couleur "rouge" ou la matière "or gris"). Ces valeurs d'attributs peuvent également être des attributs (une matière peut avoir un nombre de carats, une densité, etc. la valeur elle-même peut être activée/désactivée, etc.)

Je vous laisse donc imaginer ce modèle de données.

A partir de là, il faut pouvoir faire des recherches dans tous les sens.... "Tous les produits de couleur rouge et de matière "argent", qui un composant de type "vis" en or, etc.." (l'utilisateur peut composer sa propre recherche avec l'interface utilisateur).

Ma question est la suivante :
Chez nous, toutes les données ont été chargées en mémoire sous forme d'objets Java et la recherche consiste simplement à se promener dans le graphe (donc de sauter d'objet en objet par des méthodes Java).

Et vous ? Comment auriez-vous architecturé ça ? Avec des EJB et effectuez des tonnes de requêtes SQL ?

Bref, je cherche une méthode standard... bien sûr une recherche complexe ne doit pas prendre une plombe...

[Laurent.B]

Bonjour,

C'est quoi la vraie question ? Performance, fiabilité, évolutivité, souplesse, organisation........ ?

L'accès mémoire est évidemment ce qu'il y a de plus rapide, donc si tout peut être chargé en mémoire, c'est tant mieux.

[Cafeinoman]

Le tout mémoire sera effectivement le plus rapide. Après concrètement et vue la structure en arbre, j'irai vers un stockage avec l'API JCR. C'est vraiment prévu pour ce type de structure, et utilisé avec infinispan pour le cache, les perfs sont vraiment bonnes je trouve... Sur un modèle de données similaire, avec un million de "feuilles" environ, j'ai rarement des requêtes à plus de 700ms.

[Logan Mauzaize]

Cas typique des bases orientées document, graphe ou bigtable ...

Quelques exemples de produit : MongoDB, CouchDB (ou Couchbase pour rester dans le in-memory), Neo4j, Cassandra.

Après ce sera surtout une question de modèle. Le mieux est d'avoir une bonne idée du modèle idéal et ensuite de choisir la solution technique qui apportera le meilleur compromis (stockage, volatilité, scalabilité, transaction, sauvegarde, reprise sur erreur, etc.)