Stockage de données dans eZ Find !!!
J'ai découvert sur le désormais célèbre site de partage de connaissances de eZ Publish share.ez.no, l'annonce de la sortie Alpha 2 d'eZ Publish 4.4. Une des fonctionnalitées proposé m'a fait froid dans le dos :
eZ Find optionally supports serializing and storage of content which can be used to display it without hitting the database.
Le risque de voir eZ Find se transformer en base de données est grand et n'est pas sans risque.
Pour rappel, Lucene est un moteur de recherche libre écrit en Java qui permet d'indexer et de rechercher du texte, et Solr est un service web qui permet de profiter de toute la puissance de Lucene. eZ Find est une couche d'intégration de Solr au sein du CMS eZ Publish.
eZ Find prend beaucoup de place dans l'écosystème eZ Publish. L'implémentation du modèle stockage des objets (Modèle Entity Attribute Value) donne une souplesse impressionnante dans le stockage des données dans différents types. Le revers de la médaille est que le moteur s'avère lourd, et souffre de quelques lenteurs (si on veut être gentil) dès lors que l'on fait une recherche. eZ Find est donc le complément idéal pour ce modèle de données, il fournit un composant très rapide pour la recherche mais n'est pas du tout adapté au stockage de données.
Il est de bon ton dans les moteurs d'indexation de ne stocker dans l'index que quelques informations élémentaires (titre, mots-clés, ...) et les informations permettant de retrouver les données dans un moteur de stockage lourd (la base de données eZ Publish, des tables externes, des fichiers à plat, ...).
Une amélioration que j'aurais espéré voir aurait été d'indiquer à Solr de ne pas stocker les informations dans l'index dans la mesure où les noeuds sont fetchés automatiquement. Il y a doublon dans les données. Cette amélioration est simple à mettre en place, a minima pour le champ texte (généralement le type contenant le plus de données). J'aurai bien aimé voir apparaître dans le schéma Solr, l'attribut stored positionné à false :
Ce ci étant dit, j'en profite pour ajouter les liens vers les excellents tutoriaux de Gandbox sur eZ Find :
- DÉVELOPPEMENT AVANCÉ AVEC EZ FIND (PARTIE 1 : LA GESTION DES DATATYPES ENTRE EZ FIND & SOLR)
- DÉVELOPPEMENT AVANCÉ AVEC EZ FIND (PARTIE 2 : INDEXER DES CHAMPS SUPPLÉMENTAIRES DANS SOLR)
- DÉVELOPPEMENT AVANCÉ AVEC EZ FIND (PARTIE 3 : TIRER PROFIT DE LA SYNTAXE SOLR)
Commentaires
gandbox
Voir la classe ezfsolrstorage.php et le commentaire de Paul B. j'imagine :
@todo: see if we need to make this an abstract class to accomodate CouchDB, MongoDB, so API is not frozen also, perhaps better use dependency injection instead for class attribute specific handlers to facilitate custom overrides
truffo
Utiliser eZ Find comme composant central dans la recherche de document (objet eZ ou données tierces) est la solution (d'ailleurs n'est ce pas le but d'un moteur d'indexation ?).
Par contre, je sais bien qu'il n'est pas possible techniquement de ne pas détourner l'usage de Solr en "base de données". Il reste que la communication pour en limiter l'usage.
Roland Benedetti
Bonjour Sylvain,
Merci pour ce commentaire, comme quoi publier nos nouvelles alpha intermédiaire est apprécié ! Quelques petites précisions: cette fonctionnalité particulière fait partie d'un autre sujet plus vaste. Notre objectif n'est pas de se substituer au moteur de stockage d'eZ Publish mais nous travaillons sur une solution d'archivage ou eZ Find sera le lien vers la donnée archivée (potentiellement nous parlons ici de très gros volumes). Au final, la donnée ne sera certainement pas dans eZ Find, sans doute dans un stockage de type base orientée document non relationnelle. Une étape intermédiaire dans ce dossier consiste en ces travaux que tu commentes sur ce billet.
En espérant apporter un éclairage !
Cordialement, Roland / product manager eZ
Ajouter un commentaire