L'aide d'ElasticSearch et/ou Solr comme un magasin de données pour MS Office et PDF
Je suis actuellement en train de concevoir une recherche en texte intégral système qui permet aux utilisateurs d'effectuer des requêtes de texte à l'encontre de MS Office et PDF, et le résultat sera de retour une liste de documents qui correspondent le mieux à la requête. L'utilisateur sera alors de sélectionner tout le document retourné et voir ce document dans MS Word, Excel, ou une visionneuse de PDF.
Puis-je utiliser ElasticSearch ou Solr pour importer les données binaires brutes documents (ie. .docx, .xlsx, .les fichiers pdf) dans sa "banque de données", puis exporter le document de l'appareil de l'utilisateur sur commande pour l'affichage.
Précédemment, j'ai utilisé MongoDB 2.6.6 pour importer les fichiers raw dans GridFS et l'extrait du texte dans une autre collection (la collection contenait un index de texte) et qui fonctionnait bien. Cependant, MongoDB la recherche plein texte est assez basique et donc je suis maintenant à la recherche à Solr ou ElasticSearch pour effectuer plus complexe la recherche de texte.
Nick
- Vous pourriez envisager de elasticwarehouse.org pour cela. Il lit le fichier, extrait des métadonnées à l'aide de Tika et stocke le contenu binaire à l'intérieur de ES (comme élément binaire) ou en externe système de fichiers. Vous pouvez également l'utiliser pour tester votre cas d'utilisation (stockage énorme de fichiers binaires ou un lot de fichiers binaires peut provoquer ES problèmes de cluster)
- Salut, pouvez-vous donner de la rétroaction au sujet de la solution utilisée pour répondre à vos besoins, et les concers que vous avez rencontrées en essayant de mettre en œuvre les moteurs de recherche? Merci à l'avance.
- Comment êtes-vous d'extraire du texte à partir du PDF? Avez-vous des outils personnalisés pour le faire ou est-élastique de traitement de la recherche que de trop?
Vous devez vous connecter pour publier un commentaire.
Les deux Solr et Elasticsearch sera l'indice de la contenu du document. Solr a intégré, Elasticsearch a besoin d'un plugin. Facile de toute façon et les deux utilisent Tika sous les couvertures.
Aucun d'eux va stocker le document lui-même. Vous pouvez essayer de faire le faire, mais ils ne sont pas conçus pour cela et vous allez souffrir.
En outre, ni Solr, ni Elasticsearch sont actuellement recommandé comme stockage principal. Ils peuvent le faire, mais il n'est pas essentiel à la mission pour eux - dire pour un système de fichiers de mise en œuvre.
Donc, je vous recommande d'avoir les fichiers quelque part et l'utilisation de Solr/Elasticsearch pour la recherche uniquement. C'est là qu'ils brillent.
Je voudrais essayer le Elasticsearch attachement plugin. Les détails peuvent être trouvés ici:
https://www.elastic.co/guide/en/elasticsearch/plugins/2.2/mapper-attachments.html
https://github.com/elasticsearch/elasticsearch-mapper-attachments
Il est construit au-dessus de Apache Tika:
http://tika.apache.org/1.7/formats.html
Type De Pièce Jointe
De Document Pris En Charge Les Formats De
Concernant solr:
Si les docs doivent être retournés sur les métadonnées des recherches, Solr dispose d'un BinaryField fieldtype, à laquelle vous pouvez envoyer des données binaires codées en base64.Gardez à l'esprit qu'en général les gens recommandent contre cela, car cela peut augmenter votre indice (RAM)/performance), et si possible un set-up où vous stockez les fichiers de l'extérieur (et le chemin d'accès au fichier dans solr) pourrait bea meilleur choix.
Si vous voulez solr pour indexer automatiquement le texte à l'intérieur du fichier pdf/doc -- c'est possible avec le extractingrequesthandler: https://wiki.apache.org/solr/ExtractingRequestHandler
Elasticsearch ne stocker des documents (.pdf, des .docs par exemple) dans la
_source
champ. Il peut être utilisé comme un magasin de données NoSQL (comme MongoDB).Un peu en retard à la fête, mais cela peut aider quelqu'un 🙂
J'ai eu un problème similaire, et certaines recherches m'a conduit à fscrawler. Description:
Caractéristiques principales:
de l'analyse.