Forum général.cherche-logiciel Moteur de recherche avec interface web

Posté par  . Licence CC By‑SA.
Étiquettes :
3
16
avr.
2016

Bonjour,
j'ai un petit blog en local, je note pas mal de choses, et l'idée c'est de pouvoir récupérer et retrouver des anciennes infos/article assez facilement. Je me suis basé sur un blog en mode texte (qui n'utilise aucune base de donnée), et donc met tout nouveau post dans un répertoire, et à chaque fois dans un fichier.

L'idée serait d'avoir un moteur de recherche qui me faciliterait pour retrouver des articles basé sur le full-text (et de continuer avec le système de blog que j'ai, toujours sans base de donnée). Je pensais à Elasticsearch + Logstash. Sur logstash j'indique en input mon repertoire, je crée mon filtre propre au contenu et sa syntaxe. Et ainsi ça me fait l'indexation.

Je pense que ça peut être cool, mais pour ce qui est d'ajouter du code (page web ou service) qui se baserait sur elasticsearch pour retrouver l'article… je ne vois pas trop comment faire - et en plus quelque chose de modulable, histoire que je puisse l'adapter à mes besoins (genre ajout de lien facile vers l'article après la recherche). Ça sert à rien de me proposer Kibana, voir graylog. Clairement ça fait beaucoup trop pour ce que je veux. Moi je veux juste la barre de recherche, avec un résultat que je puisse adapter pour mes besoins.

Soit y a déjà un truc assez cool, soit l'autre solution c'est de la développer - biensûr (mais ce n'est normalement pas ce que je recherche en postant dans le forum).

Voilà merci d'avance pour cell-eux qui auraient quelques infos à me laisser sur le sujet.

  • # Xapian

    Posté par  (site web personnel) . Évalué à 2.

    Je pense que Xapian peut faire ce que tu as besoin :

    • Omega pour l'indexation
    • le frontend CGI pour l'outil de recherche.

    • [^] # Re: Xapian

      Posté par  . Évalué à 1.

      Connaissant plutôt Elasticsearch, quels sont les avantages - ou différences - de se baser plutôt sur xapian?

      • [^] # Re: Xapian

        Posté par  (site web personnel) . Évalué à 2.

        Je ne connais pas suffisamment Elasticsearch pour faire un comparatif.

        Moi j'utilise Xapian parce :

        • léger (oui C++ pas java) ;
        • très facile à mettre en place (pas de base de donnée externe, … tout est inclut)
        • oméga est léger, facile à prendre en main et a étendre ;
        • rapide et flexible ;
        • il a une interface web de recherche (qui ressemble à ca : http://xapian.org/search ).

        • [^] # Re: Xapian

          Posté par  . Évalué à 2.

          . Que ça soit pas du java, c'est vrai que je préfère.
          . Pour la bdd c'est comme pour Elasticsearch dans ce cas

          . interface web : ouais cool, pas mal.

          Faut que je réfléchisse, et que je tatte entre le déploiement de chacun et de ce que ça va me demander comme boulot.
          Merci.

  • # ht://dig

    Posté par  (Mastodon) . Évalué à 5.

    Dans le temps (~2001), j'ai utilisé Htdig pour indexer le contenu d'une dizaine de serveurs web, pour environ 50000 pages, et ça marchait très bien. Mais le projet semble à l'abandon, hélas…

    https://en.wikipedia.org/wiki/Ht-//Dig

    • [^] # Re: ht://dig

      Posté par  . Évalué à 0.

      ouais pourquoi pas, mais je dirai pas non à un outil plus récent :D

  • # grep

    Posté par  . Évalué à 3.

    Un bon vieux grep récursif pourrait faire l'affaire non ?
    Il faudrait avoir énormément d'énormes articles (ou une machine très lente) pour que ce ne soit pas efficace.
    Plus qu'à le lancer à travers un formulaire et afficher les résultats à ta guise, rien de très compliqué.

    • [^] # Re: grep

      Posté par  . Évalué à 2.

      time ls /…/articles/ | wc -l
      50127

      real 0m2.013s

      J'ai oublié de mettre time la première fois, et donc ça a du prendre facile 1min.
      J'ai des articles persos, mais pas mal d'autres choses enregistrés pour avoir en local.

      • [^] # Re: grep

        Posté par  . Évalué à 2.

        essaie :
        time grep -ri CEQUETUCHERCHES ../articles

        l'avantage c'est que ca va te dire dans quel fichier il trouve le motif "CEQUETUCHERCHES"

        • [^] # Re: grep

          Posté par  . Évalué à 0. 

          $ time grep -ri voiture /.../path/ | wc -l
4845

real    8m12.210s
user    0m37.848s
sys 0m11.668s

          Pas une machine récente (~7ans), mais ça va quand même:
          lscpu
          ...
          Nom de modèle : Intel(R) Core(TM) i5 CPU M 430 @ 2.27GHz
          ...

  • # Plus bas niveau

    Posté par  . Évalué à 2. Dernière modification le 16 avril 2016 à 16:57.

    Salut,

    Ce que tu cherche à faire/utiliser repose sur le projet Lucène.

    C'est exactement son job.

    Il te reste à faire l'interface web quivabien ;)

    Matricule 23415

    • [^] # Re: Plus bas niveau

      Posté par  . Évalué à 1.

      Ouais mais sur le coups, ça veut dire que je dois vraiment tout développer à partir de la biblio Lucène, alors qu'au final, y a déjà des outils créés… J'ai pas forcément non plus le temps de faire qqchose de propre.

  • # lunr ?

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 17 avril 2016 à 21:14.

    Je pense que lunr peut répondre à ton besoin. Il s'agit de ce que j'en ai compris d'une bibliothèque JS qui permet de faire des recherches full-text en utilisant les mécanismes de Lucene. Cela permet d'implémenter un moteur de recherche sans base de données.

    Il faut créer un index avec tous les articles existants et mettre à jour cet index à chaque ajout d'article. Cet index est chargé par lunr pour les recherches.

    C'est beaucoup utilisé par ceux qui veulent un blog statique (jekyll) pour ajouter un moteur de recherche.

    http://lunrjs.com/

    • [^] # Re: lunr ?

      Posté par  . Évalué à 1. Dernière modification le 19 avril 2016 à 00:25.

      Merci, mais je pense que ça va être sincèrement pas assez performant pour mes besoins. J'ai tout de même énormément de contenu.

      $ du -sh /…/path
      8.1G

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.