特定の文字列について、多数のファイル (つまり、600 個のファイル、それぞれ 0.5 MB) を検索する必要があります。
私はJavaを使用しているので、答えはJavaライブラリにするか、最悪の場合、Javaから呼び出すことができる別の言語のライブラリにすることをお勧めします。
ファイル内で見つかった文字列の正確な位置を返すには、検索が必要です (したがって、たとえば Lucene は問題外のようです)。
検索をできるだけ速くする必要があります。
編集開始:
ファイルは異なる形式 (つまり、EDI、XML、CSV) を持ち、かなりランダムなデータ (つまり、数値 ID など) を含む場合があります。これが、索引ベースの検索エンジンを事前に除外した理由です。
ファイルは、類似しているが異なる文字列を複数回検索されます (つまり、長さと形式が類似している ID を検索しますが、通常は異なります)。
編集終了
何か案は？
それぞれ0.5 MBの 600 個のファイルは約 300 MBです。最近のコンピューターでの単純な文字列検索は、実際には CPU バウンドよりも I/O バウンドの方が多いはずです。私のシステムの 1 つのスレッドは、比較的単純な正規表現を 1.5 秒未満で 300MB 検索できます。 OS キャッシュにすでに存在します。
そのことを念頭に置いて、そのような検索を頻繁に実行しないことが目的である場合、何らかのインデックスを使用すると、過度に設計されたソリューションになる可能性があります。すべてのファイルを繰り返し処理し、各ブロックごとまたは行ごとに読み取り、検索することから始めます。これは、独自のライブラリのメリットがほとんどないほど単純です。
パフォーマンス要件を設定し、コードのプロファイルを作成し、実際の文字列検索がボトルネックであることを確認してから、より複雑なソリューションが必要かどうかを判断します。より高速なものが必要な場合は、最初に次の解決策を複雑さの順に検討する必要があります。
Lucene などの既存のインデックス作成エンジンを使用して、クエリごとに大量のファイルを除外し、残りの (できれば少数の) ファイルで文字列を明示的に検索します。
ファイルが実際にはテキストではなく、単語ベースのインデックスが機能する場合は、ファイルを前処理して各ファイルの用語リストを抽出し、DB を使用して独自のインデックス システムを作成します。何かを使用する FTS エンジンが見つかるとは思えません。索引付けのための単語以外。
検索時間を最小限に抑えたい場合は、ファイルから単語と位置のペアを抽出し、それらを DB に入力します。実際のファイルを見て確認する必要があるかもしれませんが、その方がはるかに高速です。
PS: あなたは、私たちが議論している弦の王様についてまったく言及していません。単語などの区切られた用語が含まれていますか、またはファイルにランダムな文字が含まれていますか? 検索文字列は意味のある部分文字列に分割できますか?それとも文字の集まりですか? 検索文字列は固定ですか、それとも正規表現ですか? これらの各質問に対する答えは、実際に実行可能なものと実行不可能なものを大幅に制限する可能性があります。たとえば、ランダムな文字列のインデックス作成はまったく不可能な場合があります。
編集：
質問の更新から、たとえばバイナリ ファイルで完全にランダムなシーケンスを検索するのではなく、用語/トークンの概念が一般的に適用できるようです。つまり、それらの用語にインデックスを付けることができます。検索文字列に存在するトークンをインデックスで検索することにより、実際のファイルを確認する必要があるケースを大幅に減らすことができます。
term->fileインデックスを保持できます。ほとんどの用語が各ファイルに固有である場合、このアプローチは複雑さとパフォーマンスの適切なトレードオフを提供する可能性があります。基本的に、検索を 1 つまたは 2 つのファイルに絞り込んでから、それらのファイルのみに対して完全検索を実行します。
term->file:positionインデックスを保持できます。たとえば、検索文字列が「Alan Turing」の場合。最初にトークン「Alan」と「Turing」のインデックスを検索します。相互参照できるファイルと位置の 2 つのリストが得られます。たとえば、トークン「Alan」の位置がトークン「Turing」の位置よりも最大で 30 文字先行するように要求することで、明示的に検証できるファイル内の候補位置のリストを取得できます。
既存のインデックス作成ライブラリがどの程度役立つかはわかりません。ほとんどはテキストのインデックス作成を対象としており、数字や日付などの他の種類のトークンを誤って処理する可能性があります。一方、あなたのケースも根本的に異なるわけではないので、必要に応じて、フィードするファイルを前処理してより美味しくすることで、それらを使用できる場合があります。ニーズに合わせて独自の索引付けシステムを構築することも、それほど難しくないように思えます。
検索文字列に何らかの柔軟性があるかどうかについてはまだ言及していません。正規表現を検索できると思いますか? 検索文字列は逐語的に見つかることが期待されていますか、それともその中の用語だけを見つける必要がありますか? 空白は重要ですか？用語の順序は重要ですか?
さらに重要なことは、検索中に考慮すべきファイルに何らかの構造があるかどうかについて言及していないことです。たとえば、検索を XML ファイルの特定の要素に限定したいですか?
SSD がない場合、主なボトルネックはすべてのファイル アクセスになります。Java の内容に関係なく、ファイルを読み取るのに約 10 秒かかります。
SSD を使用している場合、ファイルの読み取りは問題にならず、Java の CPU 速度がより重要になります。
ファイルのインデックスを作成できれば、これは非常に役立ちます。