Je suis en train d'essayer de mettre en place un moteur de recherche en Python. Pour l'enregistrement de l'index, ma base se compose de 3 tables :
mots (idMot, mot)
page (idPage, url)
index (idMot, idPage, nbOccurences)
Le problème est que en prenant 100 mots par page, et 200 000 pages indexes on se retrouve avec plus de 200 000 enregistrements dans la table page ainsi que 20 000 000 (200 000*100) dans la table index.
Sans compter le nombre d'enregistrement dans mots.
Est-ce que quelqu'un aurait des retours d'expérience sur un nombre d'enregistrements aussi _gros_ ? Est-ce que MySQL ou PostgreSQL tiendrait le coût ?
Existe-t-il un autre moyen d'établir un index d'un nombre x de page ?
Merci
# Re
Posté par Gregplus . Évalué à 4.
n'importe quelle base gère ça sans problème.
As-tu pensé à utiliser l'indexation texte de mysql (>= 4.0 je crois) ? ça marche très bien
Sur ce sujet : un article sur Kuro5hin : http://www.kuro5hin.org/story/2004/5/1/154819/1324(...) (l'article lui-même est un troll mais la discussion qui suit est très intéressante et on y trouve des liens intéressants)
[^] # Re: Re
Posté par Damien Pobel (site web personnel) . Évalué à 5.
(http://www.nexen.net/docs/mysql/annotee/features.php(...))
Charges supportées et limites
Gère les très grandes bases de données. Nous utilisons le serveur MySQL avec des bases qui contiennent 50 millions de lignes et nous connaissons des utilisateurs qui utilisent le serveur MySQL avec plus de 60 000 tables and et 5 000 000 000 (milliards) de lignes.
Jusqu'à 32 index sont permis par table. Chaque index est constitué de 1 à 16 colonnes ou parties de colonnes. La taille maximale d'un index est de 500 octets (ce qui peut être configuré à la compilation du serveur MySQL . Un index peut utiliser un préfixe issu d'un champs CHAR ou VARCHAR .
https://damien.pobel.fr
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# Me parait pas enorme
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
Sinon ta table index: peut tenir sur 3 entiers de 32 bits, donc 12octets. Ca fait donc ~ 230Mio
, la table page sur ~10Mio et la table mot sur - de 457Mio.
Mouais ca fait pas loin d'1Gio d'informations (dans le pire des cas).
Je conseillerai une base PostgreSQL
a en croire http://www.postgresql.org/survey.php?View=1&SurveyID=26(...) ca va pas le gener il peut gerer jusqu'a 4Tio.
# L'effet d'échelle
Posté par Anonyme . Évalué à 0.
Si ça peut t'avancer un peu au niveau des valeurs que l'on peut atteindre avec ce type d'outil... ;)
Dans tous les cas, la question n'est plus d'utiliser une base, mais de la répartir largement et de l'accéder rapidement, et là tu devrais parlerà un dba !
Si tes ambitions sont plus légères, alors Mysql te séduira par sa rapidité, et tu pourras au besoin mettre en place une répartition des bases si la quantité de données augmentait trop... Sinon si tu as besoin de traitements puissants à un moment, alors tu préfèreras PostgreSQL.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
# no sgbd passaran
Posté par Roger Rabbit . Évalué à 3.
Construite un moteur de recherche utilisant un sgbd pour l'indexation c'est hérétique. Tu vas aboutir à un machin ayant des performances minables.
La solution au problème c'est d'établir ta propre structure de stockage pour maitriser completement les optimisations possibles. ( Algo de compression, Acces sequentiel, Hachage, Reorganisation des index, Acces disques ... etc ). Avec un sgbd tu perds tout controle sur ces paramètres.
Je te conseille la lecture de "Modern Information Retrieval" de Baeza-Yasst Ribeiro-Neto chez addison wesley qui te mettra au fait des différentes techniques employées dans les moteurs modernes. Je conseille ce livre à tout un chacun ...
L'indexation reste un domaine très pointu et si tu cherches un peu tu verras que c'est très dur d'obtenir des infos de qualités à ce sujet.
Bon courage :)
[^] # Re: no sgbd passaran
Posté par Fabien (site web personnel) . Évalué à 1.
Parce que mes compétences en programmation de _bas niveau_ (dans le sens travail sur les structures de données, la programmation système c'est pas trop mon point fort pour le moment..
[^] # Re: no sgbd passaran
Posté par Roger Rabbit . Évalué à 2.
Oui c'est en java :). Mais néanmoins ses performances sont plus qu'impressionantes et l'architecture logicielle est bien pensée. C'est un projet libre, tu peux t'y instruire et t'en inspirer.
Je vais me repeter mais le livre que j'ai référencé ci dessus est vraimment excellent. Si tu peux le trouver et le lire tu auras un bon bagage dans le domaine et de quoi te faire une opinion par toi même.
Du coté du libre, le seul qui trouve grace à mes yeux est lucene. Les autres moteurs d'indexation sont tres en deça, tant au niveau performance qu'architectural.
Pour répondre à ta question, tout dépend de ce que tu veux faire. Si c'est pour t'instruire lis le livre. Si c'est pour coder un proto, lis le livre :) Si c'est pour coder un soft qui aura une application en entreprise, envisage d'autres solutions éprouvés car c'est un domaine assez complexe. Dans ta modélisation d'un moteur d'indexation, tu oublies de nombreux cas pratiques assez épineux...
Bref lis le livre :)
Sinon tu me mailer j'ai un forward sur mon mail dlfp et je serais ravi d'y répondre.
[^] # Re: no sgbd passaran
Posté par Fabien (site web personnel) . Évalué à 1.
[^] # Re: no sgbd passaran
Posté par Roger Rabbit . Évalué à 0.
[^] # Re: no sgbd passaran
Posté par Fabien (site web personnel) . Évalué à 1.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<rabbit@dlfp.org>:
212.27.33.224 does not like recipient.
Remote host said: 550 <rabbit@dlfp.org>: User unknown in virtual alias table
Giving up on 212.27.33.224.
[^] # Re: no sgbd passaran
Posté par Roger Rabbit . Évalué à 1.
essaie de joindre rabbit sur irc.freenode.net ....
[^] # Re: Lupy...ou lucene mais en python
Posté par dge77 . Évalué à 1.
http://www.divmod.org/Home/Projects/Lupy/index.html(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.