Indexation du contenu d'un très gros champ texte (~20Mo) + search/API

Support
1

Request description

Bonjour, je suis confronté à un nouveau use case consistant à gérer un document (actuellement, un champ texte de 20Mo) que notre métier voudrait pouvoir indexer sous forme de mots-clé requêtables par API.

  • La partie accès aux recherches indexées par API ne pose a priori pas de soucis.
  • J’évalue une hypothèse consistant à mettre en place d’un champ texte “contenu indexé” qui serait en l’occurrence indexé via la solution d’index d’objet standard.

→ Cela est-il envisageable ?
→ Quelles seraient les limites ?

NB: nous essayons de ne pas en tenir compte pour ne pas nous coupler avec un SGBD particulier mais ce use case serait nativement déployé sur un socle avec une BD PostgreSQL.

2

m_index contient

  • l’objet + row_id de l’entité indéxée
  • sa clé fonctionnelle (qui sera mieux scorée)
  • et les champs indexables concaténés

Si on a un champ de 20Mo, Simplicité va copier 20Mo dans cette table, et surement qq Mo dans l’index de la SGBD. Pas terrible.

Si la liste des mots clés est connues, on peut imaginer qu’au preSave, on simplifie les 20Mo en liste des mots clés trouvés dans une colonne à part qui sera elle indexée fulltext (qq ko), et pas celle d’origine de 20Mo.

Si la liste des mots-clés change de “temps en temps”, il faudra tout réindexer (le code du preSave à faire en masse).

Si elle est non fixe (l’utilisateur saisie des mots clés “libres”), il faudra plutôt faire du code pour ne plus utiliser m_index) :

  • indexer directement la colonne “big_column” en fulltext sur pgsql

CREATE INDEX mybig_idx ON mytable USING GIN (to_tsvector(‘english’, big_column));

  • preSearch = récuperer le filtre utilisateur, le retirer, et préparer à la place un setAdditionnalSearchSpec(sql) sur le champ, pour pas faire un simple like du style :

to_tsvector(big_column) @@ to_tsquery(‘tag1 & tag2 & tag3’)

Par API, il faudra faire une recherche avec un filtre “tag1 & tag2 & tag3” / parsé par le preSearch.
à creuser si c’est le besoin.

1 Like
3

Bonsoir François,

merci beaucoup pour ton retour.

Les termes de recherches sont variables mais a priori tous dans des espaces sémantiques codifiés (termes de référence ou avec un dictionnaire ou un formalisme connu. Il seraient donc (toujours a priori) identifiables selon des patterns “regex like” (ou tirés d’un dictionnaire).

Je confirme que je pensais en effet “post-traiter” la big_column pour produire un big_column_summary (par code Java, en postSave (ou en preSave si le code est très efficace et que le coût au runtime n’est pas trop pénalisant pour les clients en post/put).

Je vais donc a priori tenter le coup en restant sur le standard (indexation dans m_index de big_column_summary qui resterait de taille très raisonnable).

Je bookmark pour la suite la solution basée sur un index fulltext pgsql ad-hoc car ce sera peut-être utile si la solution d’extraction de mot-clés n’est pas satisfaisante.

4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.