大量のテキスト ファイル (1 TB) の検索を高速化する方法

すでに多くの回答がありますが、2 セント追加したかっただけです:

<オール>

わずか 8 GB のメモリでこれだけの膨大なデータ (1 TB) を保持することは、Lucene や Elasticsearch (内部的に Lucene を使用) を使用するか、より高速な検索が必要な場合は grep コマンドを使用するかに関係なく、どのアプローチにも十分ではありません。理由は非常に単純です。これらのシステムはすべて、より高速にサービスを提供できるように最速のメモリにデータを保持し、8 GB (OS 用に 25%、少なくとも他のアプリケーション用に 25 ～ 50% を確保する必要があります) を保持します。数 GB の RAM。

SSD をアップグレードしてシステムの RAM を増やすと効果的ですが、これは非常に面倒です。また、パフォーマンスの問題が発生すると、システムの垂直方向のスケーリングが難しくなります。

提案

<オール>

システムでこれを実行したいとおっしゃっていたのは知っていますが、私が言ったように、実際のメリットはなく、多くの時間を浪費することになるかもしれません (インフラとコードに関して (前述のように非常に多くのアプローチ)さまざまな回答で））、したがって、適切な容量を決定するための別の回答で述べたように、トップダウンアプローチを行うことをお勧めします。どのようなアプローチを選択しても、適切なキャパシティをすばやく特定するのに役立ちます。

実装に関しては、Elasticsearch(ES) を使用することをお勧めします。セットアップとスケーリングが非常に簡単なので、AWS Elasticsearch を使用することもできます。私は AWS ES の大ファンではありませんが、セットアップに多くの時間を節約でき、ES に精通していればすぐに使い始めることができます。

検索を高速化するために、ファイルを複数のフィールド (タイトル、本文、タグ、作成者など) に分割し、重要なフィールドのみにインデックスを付けることができます。これにより、逆インデックスのサイズが小さくなり、正確な文字列の一致 (部分的または全文検索なし)、単に keyword を使用できます 索引付けと検索がさらに高速です。

Elasticsearch が優れている理由と最適化の方法について説明できますが、それは重要ではありません。要点は、検索には大量のメモリ、CPU、ディスクが必要であり、いずれかがボトルネックになるということです。ローカル システムの検索やその他のアプリケーションを妨げる可能性があるため、外部システムでこれを行うことを真剣に検討することをお勧めします。Elasticsearch は、分散システムと今日最も人気のあるオープンソース検索システムの手段として際立っています。

ほとんどすべての回答が示唆しているように、明らかにインデックスが必要です。ハードウェアを完全に改善することはできますが、修正済みとのことなので、詳しく説明しません。

関連するヒントがいくつかあります:

<オール>

データセット全体をインデックス化するのではなく、検索用語を見つけたいフィールドのみをインデックス化します。

マルチレベル インデックス (インデックス オーバー インデックス) を作成して、インデックス検索を高速化します。これは、インデックスが 8 GB を超える場合に特に重要です。

代わりに検索結果をキャッシュすることをお勧めしたかったのですが、そうすると新しい検索に再び半日かかることになります。したがって、データを前処理してインデックスを作成する方が、クエリが来たときにデータを処理するよりも明らかに優れています。

マイナー アップデート:

ここでの多くの回答は、データをクラウドに置くことを提案しています。匿名化された医療データであっても、(Web からデータをスクレイピングした場合を除き) ソースに問題がないことを確認することを強くお勧めします。

検索を高速化するには、逆索引が必要です。既存のすべてのファイルのインデックスを再作成する必要なく新しいドキュメントを追加できるようにするには、インデックスをインクリメンタルにする必要があります。

インクリメンタル インデックス作成を導入した最初のオープン ソース プロジェクトの 1 つは Apache Lucense です。現在でも最も広く使用されているインデックス作成および検索エンジンですが、その機能を拡張する他のツールが最近普及しています。 Elasticsearch と Solr はどちらも Lucense に基づいています。ただし、Web フロントエンド、分析クエリ、フィルタリング、グループ化のサポート、テキスト以外のファイルのインデックス作成のサポート、または複数のホストにわたるクラスター セットアップのインフラストラクチャが必要ない限り、Lucene は依然として最良の選択です。

Apache Lucense は Java ライブラリですが、完全に機能するコマンドライン ベースのデモ アプリケーションが付属しています。 この基本的なデモでは、必要な機能がすべて提供されています。

ある程度の Java の知識があれば、アプリケーションをニーズに合わせることも簡単です。デモ アプリケーションのソース コードがいかに単純であるかに驚かれることでしょう。 Java を選択したくない場合は、Pyhton のラッパーである PyLucene も代替言語になる可能性があります。デモ アプリケーションのインデックス作成は、すでにほぼ最小限に抑えられています。デフォルトでは、ステミングや複雑なクエリの最適化などの高度な機能は使用されません。これらの機能は、ほとんどの場合、ユースケースには必要ありませんが、インデックスのサイズとインデックス作成時間が増加します。