興味深い問題があり、適切な解決策を探しています。さまざまなサイズの約 100,000 の PDF ドキュメントがあり、平均サイズは 150 ページです。現在、RAID6 サーバー上にあり、オフサイトでもバックアップされています。インデックスを作成する必要がある合計 6.5 TB 相当の PDF があります。
現在、PDF をテキスト ファイルに変換し、サーバー上の同様のフォルダー構造に保存しています。次に、これらをインデックス化し、元のフォルダーへのバック リンクを含めて検索可能にする必要があります。テキスト ファイルは、追加の命名規則が追加された PDF と同じ名前を使用します。私の見積もりが正しければ、インデックスを作成する必要がある単語数は 40 億近くになります。
これらのファイルをインデックス化するための適切なソリューションは何ですか?
計算を正しく行っていれば、1 ページあたり 400K のようになります。それは大きなページサイズです。
インデックスを何に使用する必要がありますか?
近接性とフレーズが必要な場合は、それらすべてと SOLR のような製品にインデックスを付ける必要があります。TIKI を通じて、PDF のインデックスを作成できると思います。
もう 1 つのオプションは、SQL フルテキストを使用することです。ただし、フロントエンド アプリを構築する必要があります。SOLR と app と engine はどこにありますか。
すべての単語をインデックス化する必要がありますか?それとも固有の単語だけをインデックス化する必要がありますか? 基本的な検索だけが必要な場合、英語には約 200,000 の一意の単語しかありません。ポーターステマーのようにそれらをステミングすると、その数は減少します。次に、「the」などのストップ ワードを捨てます。次に、辞書にない適切な名前の電子メールやその他の単語を指定する必要があります。私は手動で文書を索引付けし、非常に大きなコレクションでも 300,000 に達します (それが実際の単語である場合、ocr はその数を殺します)。ドキュメントに 2,000 の固有の単語がある場合、クロス インデックスはわずか 20,0000,000 です。REGEX を使用して単語を解析できます。見た目が悪いことはわかっていますが、SQL と .NET でこれを手動で行っています。近接検索やフレーズ検索はありませんが、フットプリントが小さく高速です。(SQL Azure には全文がありません)
SOLRを見てみましょう。現在、ドキュメントの全文検索エンジンとしての利用を検討しています。広く使用されており、十分にサポートされています。
これに SQL データベースを使用するやむを得ない理由がない場合は、専用の検索エンジンを検討します。
ほとんどの全文検索ソフトウェアは、テキスト ファイルに変換しなくても PDF ファイルを読み取ることができます。私は過去にdtSearchをうまく使いました。
Google 検索アプライアンスをご覧ください。なぜ車輪を再発明するのですか？