palkeo a écrit 138 commentaires

Et sauter au dessus des lignes de bouées qui séparent les lignes, comme des dauphins !

Ça rendrait la compétition bien plus intéressante à voir, pour les spectateurs.

Cela devrait servir en e-réputation si on met son nom ou celui de son entreprise non ?

En effet :)

Sinon sur github je n'ai pas vu de licence et en France par défaut c'est non libre ça ne passe pas encore automatiquement en WTFPL

Voilà, j'ai ajouté une licence dans mon code (licence BSD).

Dans ma grande mansuétude, je te passe aussi un script d'indexation de wikipédia :
http://pastebin.archlinux.fr/467782
Et un pour faire des recherches dans le wikipédia indexé :
http://pastebin.archlinux.fr/467781

Bon, c'est surtout pour que tu aie un exemple d'utilisation complète (fait un peu à l'arrache :/). Si tu veux le faire tourner ça te demandera quelques modifs.

Et si jamais tu arrivais à te servir de mon indexd, je serais curieux de voir ce que tu fais :)

Hop, je l'ai ajouté, et j'ai même modifié les sections spécifiques à feedspot : il devrait être fonctionnel !

Tu as le code sur GitHub.

Ah, et si tu veux utiliser la fonction pour ajouter des documents, sache que j'ai aussi libéré la bibliothèque qui se charge de parser des texte ou du HTML pour en faire une liste de mots :
http://repo.palkeo.com/scripts/html_parser/.
(tu notera la présence d'une fonction pour récupérer tous les flux d'une page web dans htmldocument.py, ça sent bon le Feedspot là-aussi :D)

Si ça t'intéresse, je peux publier la bibliothèque que j'utilise (un petit module python).

Par contre, tu devra recoder des petits bouts, puisque celle-là est faite pour mon indexd modifié pour feedspot, qui n'a pas exactement les mêmes commandes pour la recherche.

Elle contient aussi un parseur fait maison qui est plutôt puissant, mais particulièrement inmaintenable :/

Ah ok, je t'avais mal compris en effet.

La liste des buzz est déjà stockée en BDD (par contre, c'est mon indexd qui remonte les mots clés qui buzzent dans la BDD).
Et pour tout le reste, il y a mastercard mon index inversé est vraiment performant, mais il est clairement moins flexible (et il y a des choses qu'il ne pourra jamais faire). Après, ta requête « python -serpent » est déjà gérée par mon indexd, avec de super performances :)

Il y a longtemps, j'avais justement codé un petit moteur de recherche jouet, qui utilisait la BDD pour tout stocker (testé avec du MySQL puis du Postgres), et il s'est avéré que c'était très efficace. MAIS, quand j'avais beaucoup de résultats, les performances s'écroulaient :/

Justement, qu'en serait-il si tu persistais tes informations d'indexation avec postgres ? Je pense que pour des recherches simples, la méthode actuellement utilisée est plus rapide. Utiliser postgres te permettrait de faire des requêtes plus complexe simplement directement en SQL. Je pense qu'il serait intéressant de voir la différence entre les deux modes de stockage.

Franchement, je pense que même si PostgreSQL est très bien fait niveau recherche plein-texte, les BDD SQL sont loin d'être idéales pour faire ça.
Des projets comme lucene sont tellement plus puissants…
Et puis je ne vois pas de choses que je ne peux pas faire avec mon petit index inversé, en fait :)

Ensuite, au niveau des données d'indexation, les 30 Go correspondent à la taille des fichiers ou la taille occupée sur le disque ? Car avec 50 millions de fichiers, cela peut avoir une grande influence. 30Go divisé par 50 millions, ça fait des fichiers d'une taille moyenne de 650 octets. Avec un système de fichiers ayant une taille de blocs de 4ko par exemple, les 30 Go de données occuperont facilement plus 100 Go sur le disque !

En effet, c'est la taille totale sur le disque. C'est pour ça que j'ai choisi BTRFS, qui est basé sur un arbre et semble gérer très bien les petits fichiers (après un début sous ReiserFS qui semblait fonctionner à merveille également).

Par contre oui, ma méthode actuelle est ultra-simple, mais bon, c'est clairement pas idéal de stocker tout dans plein de petits fichiers.

Après, ça me semble très dur d'arriver à trouver un système pour stocker mes index dans un ou quelques fichiers (j'ai l'impression que je vais devoir ré-implémenter un genre de système de fichier, et que je vais avoir plein de problème de fragmentation, etc…). Et je ne sais pas trop comment les BDD ou les autres systèmes font ça :(

Je ne connaissait pas, et il a l'air bien intéressant, merci !

Intéressant en effet !
Par contre, j'ai décidé de faire un truc à grande échelle (150 000 flux RSS), et je vois vraiment pas comment je pourrais catégoriser chaque flux :/
À plus petite échelle, avec quelques centaines de flux récupérés à la main, ça pourrait clairement se faire, par contre !

Si vous avez d'autres idées dans le genre, ça m'intéresse :)

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).

Merci :)

Le moteur d'indexation travaille uniquement avec des mots, oui.

Donc il est juste capable de remonter à mon « radar à buzz » les mots (simples) qui montent.

Ensuite, j'ai un algo qui passe dessus :
- d'abord, il essaye d'éliminer le bruit (à l'échelle de la journée, j'ai pas mal de mots parasites qui apparaissent en masse dans un seul flux), en s'assurant que le mot apparaît dans suffisamment de flux RSS.
- ensuite, il groupe les mots qui vont ensemble : si dans la plupart des articles, on retrouve toujours deux mots ensemble, alors on les met dans le même groupe.
- et enfin, il essaie d'obtenir une expression compréhensible : à partir de juste la racine du mot, il effectue une recherche dans les articles, et trouve le plus grand dénominateur commun ou apparaît ce mot, dans tous les articles.

Ah, et sinon j'ai décidé de ne pas enlever les « stop words » comme « le », etc : je ne trouve pas ça génant qu'ils soient là, et ça facilite la recherche d'expressions exactes.

Merci :)
Concernant la protection XSS, il est possible que RequestPolicy te fournit une protection équivalente, en fait.
Si tu as un méchant qui met un dans une page, ça sera bloqué puisque tu as une requête qui est faite sur un site externe.

Ou, si il se met tout le code directement sur la page, il y a un moment ou il va devoir renvoyer les données qui l'intéressent sur son serveur ==> impossible.
Il peut toujours rediriger la page courante vers une URL sur son serveur ==> RequestPolicy va te prévenir que la page veut se rediriger, et tu devras accepter :)

Après, je ne sais pas exactement comment fonctionne NoScript sur ce point, mais ça à pas l'air si différent.

Toi qui utilise NoScript couramment, ça te casse pas un paquet de sites sur lesquels tu vas, qui ont besoin du JS ?
Le truc, c'est que j'ai envie que plus de 90% des sites soient consultables de base, sans devoir aller rajouter des règles.

Oui, en fait avec NoScript ou RequestPolicy, tu as plus besoin d'Adblock ou de Ghostery.

Vu que RequestPolicy bloque toutes les requêtes qui sont à destination d'un autre site que celui que tu visite, ça bloque d'entrée de jeu toute la pub puisque pour l'afficher il faut faire des requêtes sur le site de la régie :)

J'ai rajouté des liens vers les listes supplémentaires d'AdBlock, ainsi qu'une rubrique sur le fameux DoNotTrack, qui devrait répondre à ta question :)
(si tu la vois pas, fais essaye de rafraîchir la page)

WOT est clairement une super extension, mais j'ai décidé de ne pas en parler, car ça sort pas mal du champ de la vie privée / de l'anonymat : c'est juste pour dire si le site est digne de confiance.

Je crois bien que GhostRank est désactivé par défaut, non ?

Hop, j'ai rajouté Redirect Cleaner :)

Alors, le principe c'est que je parle déjà pas mal de AdBlock dans mon article. Idem, pour refcontrol, je présente « smart referer », qui me semble bien plus simple et puissante comme extension.

Par contre, je ne connaissait pas redirect cleaner, et je pense que je vais l'ajouter ! Surtout qu'il remplace mon extension pour google, en étant bien plus générique ! Merci.

Adsuck est sympa aussi. Après, un système comme RequestPolicy le rend inutile, mais ça peut être sympa pour le mettre sur tout un réseau.

Tu bluffes Martoni !

Je pense qu'il aurait pu être bon d'expliquer rapidement ce qu'est une certification LPI :)

Ces dessins, ce style d'écriture, cet ornithorynque…
Vivement la suite !

Même si google se protège dans ses conditions d'utilisation, ça n'empèche pas que dans la pratique quand tu t'auto-héberge, tes données sont beaucoup moins à l'abri de pertes en cas de crash du serveur. Et que ta disponibilité est forcément moins bonne que celle de google.

D'ailleurs, je ne suis pas sûr que ton serveur auto-hébergé te permette de faire de l'authentification forte avec ton téléphone portable. Google si.

AMHA, le seul point sur lequel on peut les critiquer, c'est qu'ils peuvent obéir aux injonction du gouvernement si il veut lire tes mails, et qu'il les analyse automatiquement à des fins mercantiles.

Il y a plein d'arguments pour l'auto-hébergement, mais je ne pense pas que ceux-là en fassent partie.

Je ne me crois pas meilleur, loin de là, mais j'aurais du mal à faire pire que rien garantir du tout comme eux.

Moi justement, comme je m'auto-héberge actuellement, je ne peux rien garantir non plus : Ma connexion ADSL peut lâcher n'importe quand.
Du coup, je sais que je ne peux pas héberger de site qui demande impérativement une forte disponibilité, je suis pas fou.

Là, si ils ne garantissent rien, c'est uniquement parce que c'est un service gratuit et qu'ils veulent se protéger.

Merci pour les liens, ce fut fort instructif !

Si tu maintiens ton système à jour, je suppose que les attaques connues sur le kernel doivent être impossibles (après forcément, ça dépend du niveau de parano :p )

Perso je fonctionne comme ça, avec comme tu le dis un blocage réseau avec de l'uid matching, plein de petites règles d'hygiène (/tmp non exécutable, un répertoire temporaire par utilisateur…), et une lecture des logs (dont certains générés par un système qui surveille les fichiers modifiés).
Je me considère comme plutôt parano aussi, et je pense que c'est suffisant.

Ah, et pourquoi LXC tout seul ne te semble pas suffisant en fait ?

J'ai une question : Pourquoi tu ne ferais pas tourner php simplement avec un utilisateur différent ?
Si ton système est bien configuré et que tes fichiers ont les bonnes permissions, ça devrait le faire, non ?

Idem, je suis chez ovh avec l'offre noBox et j'en suis très satisfait :)
IP fixe, port SMTP ouvert, pas de modem fourni… bref, j'aime beaucoup !
Vraiment dommage qu'elle n'existe plus.