はい、おそらくSolrがこのニーズを処理できるでしょう。

私の理解では、Nutchは実際には検索を行わないようです。Nutchはウェブサイトをクロールし、そこに含まれるすべてのデータを収集するのに非常に優れていますが、収集したデータを検索するために他のソフトウェアに依存しています。多くの人々から、Nutchのインデックス処理をSolrに任せるという声を聞いています。

これは確実に正しい答えを出すのが難しい質問です。一般的に、Solrはおそらくあらゆる種類の検索ニーズを満たすことができますが、時々、Solrが適切な解決策でない場合もあります。

ここにあるあまり情報がないため、あなたのニーズについては慎重にSolrが適していると言えると思います。この答えが正しいかどうかを確認するには、さらに情報が必要です。具体的にどのような情報が必要かは一概には言えませんが、データ検索に関する高レベルな情報から始めれば、次にどんな質問をすれば良いかがわかるでしょう。

まず最初に明確にすることは...検索の結果として何を得たいのか？ Solrに結果グリッドのすべての情報を提供してもらう必要がありますか、それともSolrが一意のIDを返し、そのIDを使ってソフトウェアが別のシステムで詳細をユーザーに提供するのが十分でしょうか？ これがSolrの「ドキュメント」を定義するスタート地点です。私が設計した大規模なシステムでは、Solrのドキュメントは基本的にデータベーステーブルの行でした。そのテーブルには1億6千万の行がありました... MySQLのテーブルファイル全体が1テラバイトを超えていました。Solrには実際にそれらのドキュメントごとに多くの情報が保存されており、検索結果グリッドは完全にSolrから表示されました。ユーザーがその中から結果をクリックした場合、検索結果の一意の識別子を使用して、詳細情報を提供するためにデータベースが参照されました。

ありがとうございます。
Shawn

Dockerコンテナを起動できますか？最近では、何かを試すためにインスタンスを立ち上げるのはそれほど難しくありません。

Dima

いくつかのチュートリアルを見て、必要な情報が得られるか確認するつもりです。まだSolrは私の必要以上に多機能なように感じますが、まあ、新しいことを学ぶことは悪いことではありません。少し調査してみます。もしもっと助けが必要になったら、また質問します。返信してくれた皆さん、ありがとうございます。

j.

Solrが正しく理解しているのであれば、あなたが求めていることは簡単に実現できます。重要な用語としては、「ドキュメント」があります。これは検索結果として返される予定のアイテムを指し、あなたの場合はテキストファイルが含まれるフォルダに相当します。また、「フィールド」は各ドキュメントのメタデータポイントを示し、あなたの場合は生のテキスト、ISSN/ISBN、そしてタイトルが該当するでしょう。そして「ID」はあなたの「ドキュメント」を識別する一意のフィールドであり、あなたの場合は単純にフォルダ名であるかもしれません。これが基本的な概念の説明に少しでも役立つことを願っています。

Solrには、ほとんどのユーザーが必要としない多くの機能が含まれています。

その全てが少し圧倒的です。私たちのプロジェクトには必要なものがありません―とてもシンプルなユースケースの設定がありません。キッチンシンクが含まれていないものです。

よろしくお願いします。
Shawn

サンプルの設定ファイルをベースにして、不要だと思われる部分をコメントアウトしました。つまり、実際に使用していない機能についての方が、私が使用している機能よりも詳しく調査を行っています。

Thomas