Il y a déjà beaucoup de réponses, je voulais juste ajouter mon grain de sel :
- Avoir autant de données volumineuses (1 To) avec seulement 8 Go de mémoire ne sera pas suffisant pour n'importe quelle approche, que ce soit en utilisant Lucene ou Elasticsearch (utilise Lucene en interne) ou une commande grep si vous voulez une recherche plus rapide, le la raison étant très simple, tous ces systèmes conservent les données dans la mémoire la plus rapide pour pouvoir servir plus rapidement et sur 8 Go (25% que vous devez réserver pour le système d'exploitation et 25 à 50% au moins pour une autre application), il vous reste très quelques Go de RAM.
- La mise à niveau du SSD, l'augmentation de la RAM sur votre système vous aideront, mais c'est assez lourd et encore une fois, si vous rencontrez des problèmes de performances, il sera difficile de faire une mise à l'échelle verticale de votre système.
Suggestion
- Je sais que vous avez déjà mentionné que vous vouliez le faire sur votre système, mais comme je l'ai dit, cela ne donnerait aucun avantage réel et vous pourriez finir par perdre tellement de temps (infra et code-sage (tant d'approches comme mentionné dans diverses réponses)), je vous suggère donc de suivre l'approche descendante comme mentionné dans mon autre réponse pour déterminer la bonne capacité. Cela vous aiderait à identifier rapidement la capacité correcte de l'approche que vous choisissez.
-
En ce qui concerne la mise en œuvre, je suggérerais de le faire avec Elasticsearch (ES), car il est très facile à configurer et à mettre à l'échelle, vous pouvez même utiliser AWS Elasticsearch qui est également disponible en version gratuite et plus tard à l'échelle rapide, bien que je Je ne suis pas un grand fan d'AWS ES, cela fait gagner beaucoup de temps de configuration et vous pouvez rapidement démarrer si vous connaissez bien ES.
-
Afin d'accélérer la recherche, vous pouvez diviser le fichier en plusieurs champs (titre, corps, balises, auteur, etc.) et indexer uniquement le champ important, ce qui réduirait la taille de l'index inversé et si vous recherchez uniquement une correspondance exacte de la chaîne ( pas de recherche partielle ou plein texte), alors vous pouvez simplement utiliser le
keywordchamp qui est encore plus rapide à indexer et à rechercher. - Je peux continuer à expliquer pourquoi Elasticsearch est bon et comment l'optimiser, mais ce n'est pas le point crucial et le résultat est que toute recherche nécessitera une quantité importante de mémoire, de processeur et de disque et que tout risque de devenir un goulot d'étranglement entraverait la recherche de votre système local et d'autres applications, vous conseillant donc de vraiment envisager de le faire sur un système externe et Elasticsearch se démarque vraiment comme son moyen pour le système distribué et le système de recherche open source le plus populaire aujourd'hui.
Vous avez clairement besoin d'un index, comme presque toutes les réponses l'ont suggéré. Vous pourriez totalement améliorer votre matériel, mais puisque vous avez dit qu'il était réparé, je ne m'étendrai pas là-dessus.
J'ai quelques conseils pertinents pour vous :
- Indexer uniquement les champs dans lesquels vous souhaitez trouver le terme de recherche plutôt que d'indexer l'intégralité de l'ensemble de données ;
- Créez un index à plusieurs niveaux (c'est-à-dire index sur index) afin que vos recherches dans l'index soient plus rapides. Cela sera particulièrement pertinent si votre index dépasse 8 Go ;
- Je voulais recommander la mise en cache de vos recherches comme alternative, mais cela entraînera une nouvelle recherche qui prendra à nouveau une demi-journée. Il est donc préférable de prétraiter vos données pour créer un index que de traiter les données au fur et à mesure que la requête arrive.
Mise à jour mineure :
Beaucoup de réponses ici vous suggèrent de mettre les données dans le Cloud. Je vous recommande fortement, même pour les données médicales anonymisées, de confirmer auprès de la source (à moins que vous n'ayez récupéré les données sur le Web) que vous pouvez le faire.
Pour accélérer vos recherches, vous avez besoin d'un index inversé. Pour pouvoir ajouter de nouveaux documents sans avoir à réindexer tous les fichiers existants, l'index doit être incrémentiel.
L'un des premiers projets open source à avoir introduit l'indexation incrémentielle est Apache Lucense. C'est toujours le moteur d'indexation et de recherche le plus utilisé, bien que d'autres outils qui étendent ses fonctionnalités soient plus populaires de nos jours. Elasiticsearch et Solr sont tous deux basés sur Lucense. Mais tant que vous n'avez pas besoin d'une interface Web, d'une prise en charge des requêtes analytiques, du filtrage, du regroupement, de la prise en charge de l'indexation de fichiers non textuels ou d'une infrastructure pour une configuration en cluster sur plusieurs hôtes, Lucene reste le meilleur choix.
Apache Lucense est une bibliothèque Java, mais elle est livrée avec une application de démonstration entièrement fonctionnelle basée sur la ligne de commande. Cette démo de base devrait déjà fournir toutes les fonctionnalités dont vous avez besoin.
Avec quelques connaissances en Java, il serait également facile d'adapter l'application à vos besoins. Vous serez surpris de la simplicité du code source de l'application de démonstration. Si Java ne doit pas être le langage de votre choix, son wrapper pour Pyhton, PyLucene peut également être une alternative. L'indexation de l'application de démonstration est déjà réduite presque au minimum. Par défaut, aucune fonctionnalité avancée n'est utilisée comme le stemming ou l'optimisation pour les requêtes complexes - des fonctionnalités dont vous n'aurez probablement pas besoin pour votre cas d'utilisation mais qui augmenteraient la taille de l'index et le temps d'indexation.