indexation légère des documents pour gérer moins de 250 000 enregistrements potentiels

Récemment, je me suis retrouvé à me frotter aux limites des moteurs d'indexation de documents. Je développais un petit site Web qui avait besoin de capacités de recherche assez robustes, mais en raison de leurs contraintes matérielles, je ne pouvais pas déployer une solution Lucene-ish (comme Solr ou ElasticSearch, comme je le ferais normalement) pour répondre à ce besoin.

Et même alors, alors que je devais fournir des données et des calculs complexes qui nécessitaient beaucoup de bases de données, je n'avais pas besoin de gérer plus de 250 000 enregistrements potentiels. Déployer une instance Solr ou ES entière juste pour gérer cela semblait être un gaspillage.

Après y avoir réfléchi, cela semble être un problème assez important. La plupart des gens gèrent les exigences de recherche uniquement avec SQL. Ils exécutent simplement des requêtes SQL pour leurs données et c'est tout. Leurs capacités de recherche finissent également par être terribles.

• Faire une recherche générique de texte intégral sur une couverture peut être douloureusement lent sur certains systèmes (hôtes partagés en particulier) et embourber votre base de données, surtout si vous avez des requêtes compliquées et beaucoup de jointures.

• Vous finissez par faire plusieurs requêtes sur une seule demande de l'utilisateur. Vous pouvez contourner ce problème avec des requêtes de plus en plus compliquées, mais consultez le point précédent.

• Manque de fonctionnalités généralement présentes dans les moteurs de texte intégral.

Les bases de données avaient le même problème de devoir être déployées en tant que serveur, puis SQLite est arrivé et soudain, nous avons pu déployer une base de données qui est autonome dans un seul fichier. Mon Google n'a rien produit - je me demande s'il existe quelque chose comme ça pour l'indexation / recherche en texte intégral.

Quels facteurs prendre en compte pour décider d'implémenter une indexation légère des documents (par exemple, comme expliqué dans les réponses à une autre question ) ou de continuer à utiliser SQL dans ces situations?

Vous savez, je dois dire que vous devriez utiliser Redis.

• Utilisez l'idée de contexte . Il serait difficile d'aller en profondeur sans en savoir plus sur les documents. Souvent, vous pouvez discerner beaucoup de choses à partir des titres des documents. Le profilage de chaque document est la première étape de base, tout comme l'exploration Web.

• Faites un compte sur chaque document de mots dans un dictionnaire de mots-clés. Gardez une trace du nombre de popularité de chaque mot pour le projet total. Ajoutez plus de poids à l'itérateur pour ce compte si vous êtes en mesure de détecter une pertinence élevée dans un document ou un ensemble.
  
  La première chose que cela fait est de vous donner une liste de mots tout compris dans votre ensemble. Tout ce qui N'EST PAS trouvé dans cette liste, retour automatique de «aucun résultat». Je suggérerais un classement des résultats inférieur aux 5 à 20% de popularité les plus bas (lors de l'exécution d'une requête de recherche sur l'index).

• Si vous n'allez avec quelque chose comme Redis, ou même simplement faire votre propre structure de mémoire vous pouvez coupler des documents avec des fichiers de descripteur ou fichier mini-db et des objets de page qui décrivent chaque retour de document spécifique à la mémoire et - vient. Gardez les recherches courantes en mémoire en les faisant peut-être concourir pour des créneaux horaires ou en leur donnant un temps à vivre qui grandit à chaque recherche.

• Pour aller plus loin, commencez à enregistrer des données de référence qui regroupent un lien / ref / pointeur / index / quoi que ce soit de deux ou plusieurs documents et un pool de mots-clés ou de phrases. Fondamentalement, vous obtenez un nuage de tags gonflé.

• De plus, effectuez la détection de phrases en suivant lorsqu'un mot de votre dictionnaire est suivi ou précédé d'une chaîne exacte couramment dans les documents de métadonnées / titres similaires. Ceci est intensif mais ne nécessite qu'un seul passage pour restituer les données.

• Plus vous pouvez séparer vos données et conserver les groupes liés les uns aux autres dans l'utilisation réelle, mieux c'est.

• Connectez la probabilité d'exactitude en effectuant un suivi à chaque fois qu'un utilisateur clique sur un résultat qui ne fait pas partie des trois premiers. Améliorez la détection des phrases en regardant les recherches d'utilisateurs qui n'ont pas donné de résultats parfaits. Forcez vos requêtes à devenir relatives aux recherches des clients.

• Devez-vous surveiller les mises à jour des documents? Chronjobs / script shell ou tâches planifiées / script batch peut vous aider. Il existe bien entendu diverses options de planification et de script.

• Déchets disque, gagner en vitesse, perdre en complexité. Enregistrez plusieurs arborescences de vos documents et / ou arborescences de liens vers les documents. Recherchez uniquement les arbres pour lesquels les critères ont été remplis, ou du moins préférez-les pour obtenir des résultats plus rapidement dans la plupart des cas.

• Créez votre propre moteur de permutation léger ou trouvez-en un qui utilise la détection rapide des caractères et aucune expression régulière. Ou faites-en simplement un en utilisant regex en quelques heures, mais la différence de performances sera notable ici pour des recherches suffisantes.

• Tant de choses.

Il s'agit de solutions possibles pour mettre en œuvre une indexation et une recherche de documents robustes. Ce n'est pas tout compris. Et à cela, vous feriez probablement mieux de saisir une boîte de rechange, de jeter un réseau neuronal dessus et de passer quelques jours à créer une belle interface Web pour ce réseau neuronal.