L'approche la plus simple serait :
- Créez deux nouvelles tables :
keywords
(identifiant, mot) etkeywords_comments
(keyword_id, comment_id, count)keywords
enregistre un identifiant unique et le mot-clé que vous avez trouvé dans un textekeywords_comments
stocke une ligne pour chaque connexion entre chaque commentaire contenant ce mot-clé. Encount
vous enregistrerez le nombre de fois où ce mot-clé est apparu dans le commentaire. Les deux colonnes keyword_id + comment_id forment ensemble une clé unique ou directement la clé primaire.
- Récupérer tous les commentaires de la base de données
- Analyser tous les commentaires et diviser par non-caractères (ou autres limites)
- Écrivez ces entrées dans vos tables
Exemple
Vous avez les deux commentaires suivants :
Maintenant, vous allez parcourir les deux et les diviser en non-caractères. Cela se traduirait par les mots suivants en minuscules pour chaque texte :- Premier texte :bonjour, comment, êtes-vous- Deuxième texte :wow, bonjour, mon, nom, est, stefan
Dès que vous avez analysé l'un de ces textes, vous pouvez déjà l'insérer à nouveau dans la base de données. Je suppose que vous ne voulez pas charger 100 000 commentaires dans la RAM.
Donc ça donnerait ça :
- Analyser le premier texte et obtenir les mots-clés ci-dessus
- Écrivez chaque mot-clé dans le tableau
keywords
s'il n'y est pas encore - Définir une référence du mot-clé au commentaire (
keywords_comments
) et définissez le compte correctement (dans notre exemple, chaque mot n'apparaît qu'une seule fois dans chaque texte, vous devez compter cela). - Analyser le deuxième texte
- …
Amélioration mineure
Une amélioration très simple que vous devrez probablement utiliser pour 100 000 commentaires consiste à utiliser une variable de comptage ou ajouter un nouveau champ has_been_analyzed à chaque commentaire. Ensuite, vous pouvez les lire commentaire par commentaire depuis la base de données.
J'utilise généralement des variables de comptage lorsque je lis des données par blocs et je sais que les données ne peuvent pas changer par rapport à la direction dans laquelle je commence (c'est-à-dire qu'elles resteront cohérentes jusqu'au point où je suis actuellement). Ensuite, je fais quelque chose comme :
SELECT * FROM table ORDER BY created ASC LIMIT 0, 100
SELECT * FROM table ORDER BY created ASC LIMIT 100, 100
SELECT * FROM table ORDER BY created ASC LIMIT 200, 100
…
Considérez que cela ne fonctionne que si nous savons avec certitude qu'il n'y a pas de dates à ajouter à un endroit que nous pensons avoir déjà lu. Par exemple. en utilisant DESC
ne fonctionnerait pas, car il pourrait y avoir des données insérées. Ensuite, tout le décalage serait rompu et nous lisions un article deux fois et ne lisions jamais le nouvel article.
Si vous ne pouvez pas vous assurer que la variable de comptage externe reste cohérente, vous pouvez ajouter un nouveau champ analysé que vous définissez sur vrai dès que vous avez lu le commentaire. Ensuite, vous pouvez toujours voir quels commentaires ont déjà été lus et lesquels ne l'ont pas été. Une requête SQL ressemblerait alors à ceci :
SELECT * FROM table WHERE analyzed = 0 LIMIT 100 /* Reading chunks of 100 */
Cela fonctionne tant que vous ne parallélisez pas la charge de travail (avec plusieurs clients ou threads). Sinon, vous devrez vous assurer que lecture + réglage true est atomar (synchronisé).