Zend: génération d'index et les avantages et les inconvénients de Zend_Search_Lucene

Question

Je ne suis jamais tombé sur une application / classe comme Zend Lucene Search avant, comme je l'ai toujours interrogé ma base de données.

  

Zend_Search_Lucene fonctionne avec   documents comme des objets atomiques pour   indexage. Un document est divisé en   champs nommés, et les champs ont un contenu   qui peuvent être recherchés.

     

Un document est représenté par la   classe Zend_Search_Lucene_Document et   Ces objets de cette classe contiennent   cas de Zend_Search_Lucene_Field   qui représentent les champs de la   document.

     

Il est important de noter que tout   informations peuvent être ajoutées à l'index.   informations spécifiques à l'application ou   métadonnées peuvent être stockées dans le document   champs, et retrouvées ensuite   document lors de la recherche.

Donc cela revient à dire que je peux appliquer à quoi que ce soit, y compris les bases de données, l'élément clé fait index pour la recherche ici.

Ce que je suis en train de saisir est exactement où dois-je stocker les index dans ma demande, nous allons prendre par exemple, nous avons des téléphones stockés dans une base de données, des fabricants, des modèles - comment dois-je classer les index

Si je fais des index des utilisateurs avec par exemple, des adresses que je ne voudrais pas évidemment qu'ils soient visibles publiquement, je suis juste confus sur la façon dont tout cela fonctionne ensemble, s'il y a des inconvénients connus, tout gotchas je devrais savoir pendant l'utilisation.

Answer 1

Un index Lucene est stockée en dehors de la base de données. Je stocker dans un répertoire « data » comme une soeur à vos contrôleurs, des modèles et des vues. Mais vous pouvez le stocker partout; il vous suffit de spécifier le chemin lorsque vous ouvrez l'index pour effectuer des requêtes.

Il est essentiellement une copie redondante des documents stockés dans votre base de données, et vous devez les garder en vous-même la synchronisation. C'est l'un des inconvénients: vous devez écrire du code pour remplir l'index Lucene en fonction des résultats d'une requête sur la base de données. Lorsque vous ajoutez des données à la base de données, vous devez mettre à jour votre index de Lucene ainsi.

L'avantage d'utiliser une solution d'index de texte intégral externe est que vous pouvez réduire la charge de travail sur votre SGBDR. Pour trouver un document, vous exécutez une recherche en utilisant l'API Lucene. Le résultat devrait inclure un champ contenant la valeur de clé primaire (dans le cadre du document, mais pas besoin de faire une analyse pour la recherche FT). Vous obtenez ce champ quand vous effectuez une recherche Lucene, de sorte que vous pouvez rechercher la ligne correspondante dans la base de données.

Est-ce que répondre à vos questions?

J'ai donné une présentation récemment pour l'Université MySQL comparer les solutions de recherche en texte intégral: http://forge.mysql.com/wiki/Practical_Full-Text_Search_in_MySQL

Je publie aussi mes diapositives http://www.SlideShare.net/billkarwin .