jesterj

道化師J

検索用に設計された、柔軟性、スケーラブル、フォールトトレラント性の高いドキュメント取り込みシステム。

ビルドは、以下から寄付されたインフラストラクチャ上で実行されます。

問題

多くの場合、検索プロジェクトは、SolrCell や post.jar などの Solr の「テスト専用」組み込み処理機能を介して、いくつかのドキュメントを検索エンジンに手動でフィードすることから始まります。これらの機能は、最小限の面倒なセットアップで Solr を使用して何ができるかをユーザーが理解できるように文書化され、組み込まれています。

これは良いことであり、最初の探索ではそうあるべきです。残念ながら、これは潜在的な罠でもあります。

よくわからないユーザーが、これらのインターフェースがリファレンス マニュアルに文書化されているという事実に誤解されて (文書化されたものはすべて「正しい方法」であるに違いないと思い込み)、検索システムの開発を続けることがよくあります。同じインターフェイスの使用を自動化することによって。これらのユーザーに公平を期すために、Solr Ref ガイドの一部の古いバージョンでは、インターフェイスの「テスト専用」の性質を特定できませんでした。これは、コミュニティがインターフェイスに関連する落とし穴に気づくまでに時間がかかったことが原因である場合がありました。

残念ながら、検索のためのドキュメントの大規模な取り込みは簡単ではなく、それらのインデックス作成インターフェイスは運用環境での使用を目的としていません。通常の結果は、小規模なテスト コーパスでは「正常」に動作しますが、大規模な本番コーパスでは不安定になります。このようなインターフェイスに入力するために記述されたコードは、多くの場合、複数の種類のドキュメントまたはさまざまなドキュメント形式に対して繰り返す必要があり、共通の機能の重複やカット アンド ペーストによるコピーが容易に発生する可能性があります。また、このようなソリューションを大規模なコーパスで動作させるために多額のエンジニアリングを投資した後、次に発見するのは、インデックス付けが途中で失敗した場合に回復する方法がないということです。最悪の場合、障害はコーパスのサイズに関連しており、コーパスが大きくなるにつれて障害はますます一般的になり、最終的には問題が許容されると、完了およびインデックス作成の実行の可能性が低くなり、最終的にはシステムのインデックス作成やアップグレードがまったくできなくなります。化膿する。その結果、ひどく、痛みを伴う、場合によっては高額な費用がかかる一連の成長痛が生じます。

JesterJ のソリューション

JesterJ は、車輪を再発明する必要がないように、堅牢なフル機能のインデックス作成インフラストラクチャを簡単に始められるように努めています。 JesterJ は、非常に大量のドキュメントを扱うようになるまでは放棄する必要のないシステムであることを目的としています (そして、その時点までに、大規模なカスタム ソリューションの費用に見合った十分な利益をすでに得ていることを願っています!)。再利用可能なさまざまな処理コンポーネントが提供されており、独自のカスタム プロセッサの作成は、いくつかの簡単なガイドラインに従って 4 メソッド インターフェイスを実装するのと同じくらい簡単です。

多くの場合、Solr またはその他の検索エンジンにドキュメントのインデックスを作成するためのシステムの最初のバージョンはかなり直線的で単純ですが、時間が経つにつれて機能や拡張機能が追加され、複雑さが増すことがよくあります。また、既存のシステムに検索機能が追加されるため、システムが最初から複雑になる場合もあります。 JesterJ は、複雑なインデックス作成シナリオを処理できるように設計されています。次の仮想的なインデックス作成ワークフローを考えてみましょう。

JesterJ は、このようなシナリオを単一の集中処理プランで処理し、システムの電源が切断された場合でも、注文の受信に関する 2 番目のメッセージが表示されないようにします。 JesterJ のデフォルト モードでは、安全または冪等としてマークされていないステップについては、最大 1 回の配信が保証されます。安全なステップには外部影響はなく、べき等ステップは最終処理エンドポイントに向かう途中で繰り返される可能性があります。

詳細については、Web サイトとドキュメントを参照してください

はじめる

Wiki のドキュメントを参照してください

プロジェクトのステータス

現在のリリース: 1.0-Beta3。これは使用するのに最適なバージョンであり、ほとんど機能するはずです。 (既知の問題: #189)

次のリリース: 2 週間以内に重大な問題が見つからなければ、1.0-Beta4 が間もなく公開されます。1.0 がリリースされます。

注: 現在のコードと今後の 1.0 リリースは、単一のマシンで処理できるあらゆる設計と負荷を対象としています。 JesterJ は、多くのプロセッサを搭載したマシンを活用するように明示的に設計されています。ボトルネックを軽減するために、最も遅いステップの複製を使用して計画を設計できます。それぞれの重複は、そのステップで動作する追加のスレッドを意味します。スレッドの自動スケーリングは 1.1 で計画されており、多くのマシンにわたるスケーリングは 2.x リリースの重要な優先事項です。いつものように、これらの機能をすぐに必要とする場合は、ディスカッションを開始し、可能であれば PR を投稿してください。

JDKのバージョン

現在、JDK 11 のみが定期的にテストされています。 JDK 11 のどのディストリビューションでも動作するはずです。 Java 17 および将来の LTS バージョンのサポートは、将来のリリースで計画されています。

ディスコードサーバー

Discord で機能について話し合ったり、質問したりできます: https://discord.gg/RmdTYvpXr9

特徴：

このリリースには次の機能があります

• 計画の構造を視覚化する機能 (.dot または .png 形式: 単体テストの例はこちら)
• ローカルにマウントされたドライブ用のシンプルなファイルシステム スキャナー (post.jar の代替)
• JDBC スキャナー (データ インポート ハンドラーの代替品!)
• スキャナーは、どの文書を見たのかを記憶できます (または、ブール値フラグ)。
• スキャナーは更新されたコンテンツを認識できます (または、ブール値フラグ)。
• 調整可能なバッチサイズで Solr プロセッサに送信
• Word/PDF/xml/html などからコンテンツを抽出する Tika プロセッサ (SolrCell の代替品!)
• XML ドキュメントを直接分析するための Stax 抽出プロセッサ。
• フィールド プロセッサをコピーして、ソース フィールドの名前を目的のインデックス フィールドに変更します。
• フィールド内容を編集するための正規表現置換プロセッサ、または一致しないフィールドの削除
• 複数値フィールドの区切り値を分割する分割フィールド プロセッサ
• フィールド プロセッサを削除して、煩わしい余分なフィールドを削除します。
• 速度テンプレートを使用してフィールドコンテンツを構成するためのフィールドテンプレートプロセッサ
• フィールドの値をエンコードし、URL で安全に使用できるようにする URL エンコード プロセッサ
• 他のシステムに接続してコンテンツを取得または拡張するためのフェッチ URL プロセッサ
• 無効なドキュメントを特定した場合のログおよびドロッププロセッサ
• Date Reformat プロセッサ。日付、書式設定は常に行われます。 (ため息)
• 人間が判読できるファイル サイズ プロセッサ
• Solr 送信者はドキュメントをバッチで solr に送信します。
• Solr 分析ワークロードを Solr から移動する Pre-Analyze プロセッサ (schema.xml を与えるだけです!)
• 組み込み Cassandra サーバー (cassandra を自分でインストールする必要はありません!)
• Cassandra 構成とデータの場所は構成可能、デフォルトは~/.jj/cassandra
• 組み込み cassandra サーバーへのステータス変更イベントの書き込みフォールト トレランスのサポート
• ユーザー作成のドキュメント プロセッサ用の初期 API/プロセス。 (ドキュメントを参照)
• 60% のテスト カバレッジ (jacoco)
• シンプルな 1 つの Java ファイルですべてを設定できるため、Java 以外のプログラマは簡単な例に従うだけで済みます (カスタム コードを必要としないユースケースの場合)
• カスタム コードが必要な場合は、そのコードを uno-jar としてパッケージ化して、必要な依存関係をすべて提供し、JesterJ が使用するライブラリ バージョンから逃れることができます。あなたは私たちの問題ではなく、あなた自身の瓶地獄に対処するだけで済みます。もちろん、私たちがすでに提供しているものをそのまま利用することもできます。カスタム コードのクラスローダーは、uno-jar を優先し、そのクラスパス上で JesterJ が利用可能なものをデフォルトに戻します。
• ファイルシステムをスキャンし、solr 内のドキュメントにインデックスを付けるプランを実行する実行可能な例。

1.0 最終リリースの TODO

• 残された課題
• ベータ版リリース、テスト中。

リリース 1.0 は、単一ノード システムで使用できるように設計されているため、小規模から中規模のプロジェクト (数千万、場合によっては数億未満のドキュメント) での使用に適しています。

ロードマップ

将来のリリースに何が含まれるかについては、いつでも問題ページのマイルストーン フィルターから最も正確に推測できます。