jesterj
1.0.0
Ein äußerst flexibles, skalierbares und fehlertolerantes Dokumentenerfassungssystem, das für die Suche entwickelt wurde.
Builds werden auf einer Infrastruktur ausgeführt, die freundlicherweise von gespendet wurde
Häufig beginnen Suchprojekte mit der manuellen Eingabe einiger Dokumente in eine Suchmaschine, oft über die „nur zum Testen“ integrierten Verarbeitungsfunktionen von Solr wie SolrCell oder post.jar. Diese Funktionen sind dokumentiert und enthalten, um dem Benutzer ein Gefühl dafür zu vermitteln, was er mit Solr mit einem Minimum an mühsamem Setup tun kann.
Das ist gut und so soll es auch für erste Erkundungen sein. Leider ist es auch eine potenzielle Falle.
Allzu oft entwickeln Benutzer, die es nicht besser wissen und möglicherweise durch die Tatsache, dass diese Schnittstellen im Referenzhandbuch dokumentiert sind, in die Irre geführt werden (und davon ausgehen, dass alles, was dokumentiert ist, „die richtige Vorgehensweise“ sein muss), ihr Suchsystem weiter durch die Automatisierung der Nutzung derselben Schnittstellen. Um diesen Benutzern gegenüber fair zu sein, muss man sagen, dass einige ältere Versionen des Solr Ref-Leitfadens den „nur zum Testen dienenden“ Charakter der Schnittstelle nicht erkennen konnten, manchmal weil es eine Weile dauerte, bis die Community die damit verbundenen Fallstricke erkannte.
Leider ist die Aufnahme von Dokumenten in großem Maßstab für die Suche nicht trivial und diese Indexierungsschnittstellen sind nicht für den Produktionseinsatz gedacht. Das übliche Ergebnis ist, dass es bei einem kleinen Testkorpus „gut“ funktioniert und dann bei einem größeren Produktionskorpus instabil wird. Der für die Eingabe in solche Schnittstellen geschriebene Code muss oft für mehrere Dokumenttypen oder für verschiedene Dokumentformate wiederholt werden und kann leicht zu Duplikaten und zum Ausschneiden und Einfügen gemeinsamer Funktionen führen. Nachdem sie erhebliche technische Investitionen getätigt haben, um solche Lösungen auf einem großen Korpus zum Laufen zu bringen, stellen sie als Nächstes fest, dass sie keine Möglichkeit zur Wiederherstellung haben, wenn die Indizierung mittendrin fehlschlägt. In den schlimmsten Fällen hängt der Fehler mit der Größe des Korpus zusammen und die Fehler treten mit zunehmendem Korpus immer häufiger auf, bis die Chance auf Abschluss und Indexierung gering ist und das System schließlich überhaupt nicht mehr indiziert oder aktualisiert werden kann, wenn das Problem zulässig ist eitern. Das Ergebnis sind schreckliche, schmerzhafte und möglicherweise kostspielige Wachstumsschmerzen.
JesterJ ist bestrebt, den Einstieg mit einer robusten Indizierungsinfrastruktur mit vollem Funktionsumfang zu erleichtern, sodass Sie das Rad nicht neu erfinden müssen. JesterJ soll ein System sein, das Sie nicht aufgeben müssen, bis Sie mit einer extrem großen Anzahl von Dokumenten arbeiten (und hoffentlich zu diesem Zeitpunkt bereits gute Gewinne erzielen, die eine große kundenspezifische Lösung finanzieren können!). Es stehen zahlreiche wiederverwendbare Verarbeitungskomponenten zur Verfügung und das Schreiben eigener benutzerdefinierter Prozessoren ist so einfach wie die Implementierung einer 4-Methoden-Schnittstelle unter Einhaltung einiger einfacher Richtlinien.
Oftmals ist die erste Version eines Systems zur Indizierung von Dokumenten in Solr oder einer anderen Suchmaschine recht linear und unkompliziert, aber mit der Zeit erhöhen Funktionen und Verbesserungen oft die Komplexität. In anderen Fällen ist das System von Anfang an komplex, möglicherweise weil die Suche zu einem bestehenden System hinzugefügt wird. JesterJ ist für die Handhabung komplexer Indizierungsszenarien konzipiert. Betrachten Sie den folgenden hypothetischen Indexierungsworkflow:
JesterJ behandelt solche Szenarien mit einem einzigen zentralen Verarbeitungsplan und stellt sicher, dass Sie keine zweite Nachricht über eine eingegangene Bestellung erhalten, wenn das System vom Stromnetz getrennt wird. Der Standardmodus für JesterJ besteht darin, die Zustellung von Schritten, die nicht als sicher oder idempotent markiert sind, höchstens einmal sicherzustellen. Sichere Schritte haben keine externen Auswirkungen und idempotente Schritte können auf dem Weg zum endgültigen Endpunkt der Verarbeitung wiederholt werden.
Weitere Informationen finden Sie auf der Website und in der Dokumentation
Bitte beachten Sie die Dokumentation im Wiki
Aktuelle Version : 1.0-Beta3. Dies ist die am besten zu verwendende Version und sollte größtenteils funktionsfähig sein. (bekanntes Problem: #189)
Nächste Veröffentlichung: 1.0-Beta4 wird bald veröffentlicht, wenn innerhalb von zwei Wochen keine schwerwiegenden Probleme festgestellt werden. 1.0 wird veröffentlicht.
HINWEIS: Der aktuelle Code und die kommende Version 1.0 zielen auf alle Designs und Lasten ab, die von einer einzelnen Maschine bedient werden können. JesterJ ist explizit darauf ausgelegt, die Vorteile von Maschinen mit vielen Prozessoren zu nutzen. Sie können Ihren Plan mit Duplikaten Ihres langsamsten Schritts entwerfen, um Engpässe zu vermeiden. Jedes Duplikat impliziert einen zusätzlichen Thread, der an diesem Schritt arbeitet. Die automatische Skalierung von Threads ist für 1.1 geplant und die Skalierung über viele Maschinen hinweg ist eine Schlüsselpriorität für die 2.x-Releases. Wie immer gilt: Wenn Sie diese Funktionen früher wünschen, starten Sie bitte eine Diskussion und tragen Sie, wenn möglich, eine PR bei!
Derzeit wurde nur JDK 11 regelmäßig getestet. Jede Distribution von JDK 11 sollte funktionieren. Für zukünftige Versionen ist die Unterstützung von Java 17 und zukünftigen LTS-Versionen geplant.
Besprechen Sie Funktionen, stellen Sie Fragen usw. auf Discord: https://discord.gg/RmdTYvpXr9
In dieser Version verfügen wir über die folgenden Funktionen
~/.jj/cassandraRelease 1.0 soll für Single-Node-Systeme geeignet sein und eignet sich daher für den Einsatz in kleinen bis mittelgroßen Projekten (zig Millionen oder möglicherweise einige hundert Millionen Dokumente).
Mithilfe der Meilensteinfilter auf unserer Problemseite können Sie jederzeit am besten einschätzen, was in künftigen Veröffentlichungen enthalten sein wird
