問題タブ [full-text-indexing]

全文検索の基本的な側面が逆索引の使用であることを理解しています。そのため、転置インデックスを使用すると、1 語のクエリに答えるのが簡単になります。インデックスが次のように構成されていると仮定します。

some-word -> [doc385, doc211, doc39977, ...] (ランク順、降順)

その単語のクエリに答えるには、インデックスで正しいエントリを見つけ (O(log n) 時間かかります)、インデックスで指定されたリストから特定の数のドキュメント (たとえば、最初の 10) を提示するだけです。

しかし、たとえば 2 つの単語に一致するドキュメントを返すクエリについてはどうでしょうか。最も簡単な実装は次のとおりです。

1. A を単語 1 を持つドキュメントのセットに設定します (インデックスを検索することにより)。
2. B を単語 2 (同上) を持つドキュメントのセットに設定します。
3. A と B の交点を計算します。

さて、ステップ 3 の実行にはおそらく O(n log n) の時間がかかります。非常に大きな A と B の場合、クエリの応答が遅くなる可能性があります。しかし、Google のような検索エンジンは、常に数ミリ秒で回答を返します。したがって、それは完全な答えではありません。

明らかな最適化の 1 つは、Google のような検索エンジンは一致するすべてのドキュメントを返すわけではないため、交差全体を計算する必要がないことです。最小のセット (例: B) から始めて、他のセット (例: A) にも属する十分なエントリを見つけることができます。

しかし、次の最悪のケースはまだあり得ませんか? A を一般的な単語に一致するドキュメントのセットに設定し、B を別の一般的な単語に一致するドキュメントのセットに設定した場合でも、A ∩ B が非常に小さい (つまり、組み合わせがまれである) 場合があります。つまり、検索エンジンは B のすべての要素 x メンバーを直線的に調べ、それらが A の要素でもあるかどうかをチェックして、両方の条件に一致する少数を見つける必要があります。

線形は速くありません。また、検索する単語が 3 つ以上ある場合もあるため、並列処理を採用するだけでは完全な解決策にはなりません。では、これらのケースはどのように最適化されるのでしょうか? 大規模な全文検索エンジンはある種の複合インデックスを使用しますか? ブルームフィルター？何か案は？

インデックス MySQL の作成

FULLTEXT インデックスを追加した後、それを最新の状態に保つにはどうすればよいですか?

このように追加しました：ALTER TABLE search_index ADD FULLTEXT(si_fulltext)

次のように更新しようとしました：

ありがとう、ジョー

SQL Compact Edition 4 データベースに対して実行されている小さなブログ用の全文検索機能を作成しようとしています。

これに関する情報はほとんどないようですが (誰かが私が間違っていることを証明できれば幸いです)、私が収集できる限り、SQL CE は通常の SQL Server のフルテキスト インデックス作成をサポートしていません。

Lucene.Netの使用について簡単に調べましたが、一見すると非常に複雑に思えます。これが私の最良の選択肢でしょうか、それとも私が見逃しているより簡単な解決策はありますか?

sphinx や Clucene のような他のインデックス作成/検索エンジンはありますか?

ドキュメントをいくつかの部分に分割し、後で検索できるように各部分に個別にインデックスを付けたいと考えています。

より軽い (スケーラブルな) エンジンはありますか?

乾杯

行が category_id によってカテゴリ テーブルの 1 つまたは複数の行に接続されている製品テーブルがあります。これらのカテゴリ名を検索可能にしたい場合、製品テーブルの行のカテゴリ列の ID に対応するカテゴリ テーブルの名前のフルテキスト インデックスを作成するように指定する解決策はありますか?

私は電子図書館（アラビア語の本）のプロジェクトに取り組んでいます。ユーザーが自分の本をシステム ライブラリにインポートし、自分のライブラリに対して検索を実行できるようにするプログラム。システムは、ユーザーが後で更新できる基本ライブラリー (書籍セット) とともにユーザーに提供されます。

検索の問題を処理するために、システムが基本的な検索キーワード用の初期テーブルを DB に持つことを考えました。すべての検索キーワードは、図書館の本の場所を指しています。

ユーザーが新しい本をライブラリにインポートすると、問題が発生します。二段あります。最初に、新しい本に対してシステムに既に含まれているキーワードを検索して、それらのいずれかが本に表示されているかどうかを確認し、その場所をシステムに追加します。2 番目の主な障害は、新しい本で新しい検索キーワードを特定することです。

私が持っているアイデアは、かなり悪くて素朴だと思いますが、新しい本をトークンに分割し、ライブラリで以前に見つかったすべての本に対して各トークンを検索することです。

要約すると、2番目の問題を解決するためのヘルプ（ツール、ライブラリ、またはDBオプション）またはアイデア、またはシステム全体の別のアイデアがあれば、感謝します。多くの解決策を実際に読んで検索しようとしましたが、無駄でした。

どうもありがとう、

現在、php または mysql を使用して、大きな辞書に対してテキスト検索を実行しようとしています。今まで、私はそれを行うための最良の方法を見つけていません。たとえば、Perl で書かれた Text:Scan モジュールがあります。

http://search.cpan.org/~iwoodhead/Text-Scan-0.28/Scan.pm

これはまさにphpに必要なものです。PHPでそれを行う方法を知っている場合は、この知識を私と共有してください! :)

ご協力いただきありがとうございます！

私はdjangoを使用していますが、すべてのクエリはdjangoによって作成されているため、手書きのクエリはありません...

のテーブルがBillRecordsあり、フィールドがありますsubscriberno。私のdjangoフィルターでは、次のようなフィルタークエリを使用します。

subscriberno顧客が実数のかなり短縮されたバージョンであるかもしれないと言ったので...

そのフィルターは次のようなクエリを出力します。

subscriberno一部の数値にはアルファと一部の特殊文字が含まれているため、は文字フィールドです。

私のデータベースには、同僚によって作成された、その列の2つのインデックスがあります。

このようなクエリに2つのインデックスを使用するのは論理的だと思います。私たちのすべてのdjangoフィルターはicontains、上記のようなクエリを作成するために使用します。

クエリのPostgres分析は次のとおりです。

したがって、私が見る限り、インデックスは使用されていません。インデックスusegaはデータの挿入と更新にコストがかかるため、（この分析からわかる限り）使用されていない2つのインデックスを持つことは論理的ではないように思われました。

djangoが同様のicontanisフィルターに対して異なるクエリを出力する可能性はありますか？または、私のインデックスはまったく役に立たないのですか？

数十億の文字列から一般的な部分文字列検索を行いたい。「ubst」というクエリでも「substr」にヒットできるようにしたいので、一般的な全文検索とは少し要件が異なります。

Lucene または Sphinx はこれを行うことができますか? そうでない場合、これを行うための最良の方法は何だと思いますか?

SQL Server テーブルに多数のバイナリ ファイルを格納しました。そのテーブルにフルテキスト インデックスを作成し、ドキュメントを含むバイナリ フィールドのインデックスも作成しました。SQL Server が .doc、.docx、および .pdf ファイルも読み取れるように、適切な iFilter をインストールしました。

関数 DATALENGTH を使用すると、ドキュメント全体の長さ/サイズを取得できますが、これにはレイアウトやその他の役に立たない情報も含まれます。ドキュメントのテキストの長さを知りたいです。

iFilters を使用すると、SQL Server はそのような「複雑な」ドキュメントのテキストのみを取得できますが、テキストだけの長さを決定するためにも使用できますか?