Pourrais-tu être plus précis sur les limitations que tu as rencontré en utilisant la recherche fulltext de postgres ?
Quand j'utilisais la recherche fulltext de postgres, j'avais besoin de chercher uniquement parmi les articles parus après la dernière récupération du flux RSS de l'utilisateur.
Du coup, j'avais à chercher parmi ~1% ou moins du total de mes articles, selon certains mots clés.
Donc PostgreSQL avait deux choix :
- chercher dans tous les articles avec son index FullText (ça retourne des tonnes d'articles), et garder uniquement ceux qui sont tout frais. Pas du tout efficace.
- récupérer les articles tout frais (il peut y en avoir beaucoup...), et rechercher parmis eux ceux qui contiennent les mots clés (impossible d'utiliser l'index). Ça peut être accéléré en rajoutant une colonne avec un index inverté (de type « tsvector »), mais ça reste très bof.
Du coup, c'était utilisable, mais relativement lent :/
Le pire était le buzzomètre : j'avais fait une requête SQL capable de le générer, mais ça prenait facilement une dizaine de secondes.
Et puis avec mon « radar à buzz », je ne voyais pas du tout comment j'aurais pu récupérer les mots clés qui montent (c'est un procédé assez lourd).
Alors que maintenant, j'ai un algo spécifique pour mon buzzomètre, qui parcourt mes index à toute vitesse en comptant le nombre de résultats (il n'a même pas besoin de regarder la pertinence des résultats, c'est purement booléen).
Et pour les flux RSS, j'ai aussi un algo spécifique qui fait une recherche, mais en commençant à lire les index uniquement quand on arrive aux résultats du mois précédent. C'est aussi ultra-rapide :)
Autre question : j'ai lu que tu utilisais des fichiers pour le stockage de tes données. As-tu essayé de continuer d'utiliser postgres, mais sans la recherche fulltext bien entendu, histoire de comparer les temps d'indexation et d'interrogation dans chacun des cas, ainsi que la taille requise pour le stockage ?
Je continue d'utiliser PostgreSQL pour tout ce qui est stockage, c'est juste que j'ai à côté mon petit moteur d'indexation (et il renvoie les ID des articles trouvés, quand je fais une recherche).
Actuellement, ma BDD pour Feedspot fait 11 Go, et contient plus de 7 millions d'articles récupérés dans des flux RSS.
À côté de ça, j'ai 30 Go d'utilisés sur ma partition qui contient l'index inversé (mais c'est du BTRFS et j'ai un snapshot qui traîne, en réalité ça doit être moins).
[^] # Re: Indexation
Posté par palkeo (site web personnel) . En réponse au journal Mon projet : Feedspot. Évalué à 6.
Quand j'utilisais la recherche fulltext de postgres, j'avais besoin de chercher uniquement parmi les articles parus après la dernière récupération du flux RSS de l'utilisateur.
Du coup, j'avais à chercher parmi ~1% ou moins du total de mes articles, selon certains mots clés.
Donc PostgreSQL avait deux choix :
- chercher dans tous les articles avec son index FullText (ça retourne des tonnes d'articles), et garder uniquement ceux qui sont tout frais. Pas du tout efficace.
- récupérer les articles tout frais (il peut y en avoir beaucoup...), et rechercher parmis eux ceux qui contiennent les mots clés (impossible d'utiliser l'index). Ça peut être accéléré en rajoutant une colonne avec un index inverté (de type « tsvector »), mais ça reste très bof.
Du coup, c'était utilisable, mais relativement lent :/
Le pire était le buzzomètre : j'avais fait une requête SQL capable de le générer, mais ça prenait facilement une dizaine de secondes.
Et puis avec mon « radar à buzz », je ne voyais pas du tout comment j'aurais pu récupérer les mots clés qui montent (c'est un procédé assez lourd).
Alors que maintenant, j'ai un algo spécifique pour mon buzzomètre, qui parcourt mes index à toute vitesse en comptant le nombre de résultats (il n'a même pas besoin de regarder la pertinence des résultats, c'est purement booléen).
Et pour les flux RSS, j'ai aussi un algo spécifique qui fait une recherche, mais en commençant à lire les index uniquement quand on arrive aux résultats du mois précédent. C'est aussi ultra-rapide :)
Je continue d'utiliser PostgreSQL pour tout ce qui est stockage, c'est juste que j'ai à côté mon petit moteur d'indexation (et il renvoie les ID des articles trouvés, quand je fais une recherche).
Actuellement, ma BDD pour Feedspot fait 11 Go, et contient plus de 7 millions d'articles récupérés dans des flux RSS.
À côté de ça, j'ai 30 Go d'utilisés sur ma partition qui contient l'index inversé (mais c'est du BTRFS et j'ai un snapshot qui traîne, en réalité ça doit être moins).