jesterj

JesterJ

Un système d'ingestion de documents hautement flexible, évolutif et tolérant aux pannes, conçu pour la recherche.

Les builds sont exécutés sur une infrastructure gracieusement offerte par

Le problème

Fréquemment, les projets de recherche commencent par alimenter manuellement quelques documents dans un moteur de recherche, souvent via les fonctionnalités de traitement intégrées « juste pour tester » de Solr telles que SolrCell ou post.jar. Ces fonctionnalités sont documentées et incluses afin d'aider l'utilisateur à avoir une idée de ce qu'il peut faire avec Solr avec un minimum de configuration pénible.

C'est bien et c'est comme ça que ça devrait être pour les premières explorations. Malheureusement, c'est aussi un piège potentiel.

Trop souvent, les utilisateurs qui ne savent pas mieux, et qui sont peut-être induits en erreur par le fait que ces interfaces sont documentées dans le manuel de référence (et supposent que tout ce qui est documenté doit être « la bonne façon » de le faire) continuent de développer leur système de recherche. en automatisant l'utilisation de ces mêmes interfaces. Par souci d'équité envers ces utilisateurs, certaines anciennes versions du guide Solr Ref n'ont pas réussi à identifier la nature "juste pour tester" de l'interface, parfois parce qu'il a fallu un certain temps à la communauté pour se rendre compte des pièges qui y sont associés.

Malheureusement, l’ingestion à grande échelle de documents à des fins de recherche n’est pas triviale et ces interfaces d’indexation ne sont pas destinées à une utilisation en production. Le résultat habituel est que cela fonctionne "bien" pour un petit corpus de test puis devient instable sur un corpus de production plus grand. Le code écrit pour alimenter de telles interfaces doit souvent être répété pour plusieurs types de documents ou pour différents formats de documents, et peut facilement conduire à la duplication et à la copie copier-coller de fonctionnalités communes. De plus, après avoir investi des sommes considérables en ingénierie pour faire fonctionner de telles solutions sur un grand corpus, ils découvrent ensuite qu'ils n'ont aucun moyen de récupérer si l'indexation échoue en cours de route. Dans le pire des cas, l'échec est lié à la taille du corpus et les échecs deviennent de plus en plus fréquents à mesure que le corpus grandit jusqu'à ce que les chances de terminer et d'indexer l'exécution soient faibles et que le système ne puisse finalement pas être indexé ou mis à niveau du tout si le problème est résolu. s'envenimer. Le résultat est un ensemble de douleurs de croissance terribles, douloureuses et potentiellement coûteuses.

La solution de JesterJ

JesterJ s'efforce de faciliter le démarrage avec une infrastructure d'indexation robuste et complète, afin que vous n'ayez pas à réinventer la roue. JesterJ est censé être un système que vous n'aurez pas besoin d'abandonner tant que vous ne travaillerez pas avec un très grand nombre de documents (et j'espère qu'à ce stade, vous réaliserez déjà de bons bénéfices qui pourront vous permettre de payer une solution personnalisée importante !). Une variété de composants de traitement réutilisables sont fournis et écrire vos propres processeurs personnalisés est aussi simple que d'implémenter une interface à 4 méthodes en suivant quelques directives simples.

Souvent, la première version d'un système d'indexation de documents dans Solr ou un autre moteur de recherche est assez linéaire et simple, mais avec le temps, les fonctionnalités et les améliorations ajoutent souvent de la complexité. D’autres fois, le système est complexe dès le départ, peut-être parce que la recherche est ajoutée à un système existant. JesterJ est conçu pour gérer des scénarios d'indexation complexes. Considérez le workflow d'indexation hypothétique suivant :

JesterJ gère de tels scénarios avec un seul plan de traitement centralisé et veillera à ce que si le système est débranché, vous ne recevrez pas de deuxième message concernant une commande reçue. Le mode par défaut de JesterJ est d'assurer au plus une fois la livraison pour les étapes qui ne sont pas marquées comme sûres ou idempotentes. Les étapes sûres n'ont pas d'effets externes et les étapes idempotentes peuvent être répétées en cours de route jusqu'au point final du traitement.

Voir le site Web et la documentation pour plus d'informations

Commencer

Veuillez consulter la documentation sur le wiki

Statut du projet

Version actuelle : 1.0-Beta3. C'est la meilleure version à utiliser et devrait être principalement fonctionnelle. (problème connu : #189)

Prochaine version : 1.0-Beta4 sera bientôt publiée si aucun problème grave n'est détecté dans les deux semaines. La version 1.0 sera publiée.

REMARQUE : Le code actuel et la prochaine version 1.0 ciblent toute conception et toute charge pouvant être gérées par une seule machine. JesterJ est explicitement conçu pour tirer parti des machines dotées de nombreux processeurs. Vous pouvez concevoir votre plan avec des doublons de votre étape la plus lente pour atténuer les goulots d'étranglement. Chaque doublon implique un thread supplémentaire travaillant sur cette étape. La mise à l'échelle automatique des threads est prévue pour la version 1.1 et la mise à l'échelle sur de nombreuses machines est une priorité clé pour les versions 2.x. Comme toujours, si vous souhaitez bénéficier de ces fonctionnalités plus tôt, veuillez démarrer une discussion et contribuer à un PR si vous le pouvez !

Versions du JDK

Actuellement, seul le JDK 11 a été testé régulièrement. Toute distribution de JDK 11 devrait fonctionner. La prise en charge de Java 17 et des futures versions LTS est prévue pour les prochaines versions.

Serveur Discorde

Discutez des fonctionnalités, posez des questions, etc. sur Discord : https://discord.gg/RmdTYvpXr9

Caractéristiques:

Dans cette version, nous avons les fonctionnalités suivantes

• Possibilité de visualiser la structure de votre plan (format .dot ou .png : exemple de tests unitaires ici)
• Scanner de système de fichiers simple pour les lecteurs montés localement (remplacement de post.jar)
• Scanner JDBC (remplacement du gestionnaire d'importation de données !)
• Les scanners peuvent mémoriser les documents qu'ils ont vus (ou non, indicateur booléen)
• Les scanners peuvent reconnaître le contenu mis à jour (ou non, drapeau booléen)
• Envoyer au processeur Solr avec des tailles de lots réglables
• Processeur Tika pour extraire le contenu de Word/PDF/xml/html, etc (Remplacement de SolrCell !)
• Processeur d'extraction Stax pour disséquer directement les documents XML.
• Copiez le processeur de champ pour renommer les champs source en champ d'index souhaité
• Regexp remplace le processeur pour modifier le contenu du champ ou supprime les champs qui ne correspondent pas
• Processeur de champ divisé pour diviser les valeurs délimitées pour les champs à valeurs multiples
• Supprimez le processeur de champ pour vous débarrasser des champs excédentaires ennuyeux.
• Processeur de modèle de champ pour composer le contenu d'un champ à l'aide d'un modèle de vitesse
• Processeur d'encodage d'URL pour encoder la valeur d'un champ et sécuriser son utilisation dans les URL
• Récupérer le processeur d'URL pour acquérir ou améliorer le contenu en contactant d'autres systèmes
• Enregistrez et abandonnez le processeur lorsque vous identifiez un document invalide
• Processeur de reformatage de dates, car les dates, le formatage... toujours. ( soupir )
• Processeur de taille de fichier lisible par l'homme
• Expéditeur Solr pour envoyer des documents à Solr par lots.
• Processeur de pré-analyse pour déplacer la charge de travail d'analyse Solr hors de Solr (donnez-lui simplement votre schéma.xml !)
• Serveur Cassandra intégré (pas besoin d'installer Cassandra vous-même !)
• Configuration de Cassandra et emplacement des données configurables, par défaut ~/.jj/cassandra
• Prise en charge des événements de changement d'état d'écriture de tolérance aux pannes sur le serveur Cassandra intégré
• API/processus initial pour les processeurs de documents écrits par les utilisateurs. (voir documentation)
• Couverture des tests à 60 % (jacoco)
• Fichier Java simple et unique pour tout configurer, les programmeurs non Java n'ont qu'à suivre un exemple simple (pour les cas d'utilisation ne nécessitant pas de code personnalisé)
• Si vous avez besoin de code personnalisé, ce code peut être empaqueté sous forme de uno-jar pour fournir toutes les dépendances requises et échapper à toutes les versions de bibliothèque utilisées par JesterJ ! Vous n’avez qu’à vous occuper de votre PROPRE enfer de pots, pas du nôtre ! Bien entendu, vous pouvez également compter uniquement sur ce que nous proposons déjà. Les chargeurs de classe pour le code personnalisé préfèrent votre uno-jar, puis reviennent par défaut à tout ce que JesterJ a disponible sur son chemin de classe.
• Exemple exécutable pour exécuter un plan qui analyse un système de fichiers et indexe les documents dans solr.

TODO pour la version finale 1.0

• Problèmes restants
• Version bêta, tests.

La version 1.0 est destinée à être utilisable pour les systèmes à nœud unique, et donc adaptée à une utilisation sur des projets de petite à moyenne taille (des dizaines de millions, voire des centaines de millions de documents).

Carte routière

La meilleure estimation à tout moment de ce qui se passera dans les versions futures est donnée par les filtres de jalons sur notre page de problèmes.