2

私たちのアプリケーションでは、Lucene.Netと協力して、多数のデータにインデックスを付けています。フィールド自体は構成可能であるため、フィールドの名前とタイプは再構築のたびに変更できます。各ドキュメント内に、同じ名前の複数のフィールドと、さまざまな数の数値およびテキストフィールドを含めることができます。現在の開発には多くの労力を費やしているため、別の検索エンジンに変更することはできません。

実は、ほとんどの場合、それは魅力として機能していますが、私たちには回避できないように思われる1つの困難があります。

以下を含むドキュメント「X」にインデックスを付けたいとします。

行A-フィールド1：4 +フィールド2：a
行B-フィールド1：8 +フィールド2：b

作成するインデックスには、次の4つのフィールドが含まれます。

  • ドキュメントX：
    • フィールド1：4（数値）
    • フィールド2:a（テキスト）
    • フィールド1：8（数値）
    • フィールド2：b（テキスト）

（行IDは重要ではありません）

Field1：[3 TO 6] AND Field2：bを検索すると、このドキュメントがヒットします。
ただし、行で表されるフィールド間のリンク（4と「a」のリンク）はなくなります。

4_aのように値を連結することはできますが、数値検索が失敗し、適切な結果を得るためにどのフィールドが連結されているかをクライアントが知る必要があります。また、アナライザーの難易度も高くなります。各フィールドについて、異なるアナライザーを追加できます（主に言語の目的で）。

また、同じキーを使用して行ごとに個別のドキュメントを作成し、検索結果に個別のドキュメントを追加することもできますが、それは道のりのようには聞こえませんね。これにより、現在作成するドキュメントごとに20〜100のドキュメントを作成するため、ドキュメントの数が大幅に増加します。現在の実装ではこれを簡単に試すことができないため、パフォーマンスや使いやすさについてはテストしていません:-)

Lucene.Net内の特定のフィールド間のリンクを強制する方法を知っている人はいますが、それでも各フィールドを個別に検索する方法を維持していますか？

4

2 に答える 2

0

1つの手間は、リンケージ用の別のフィールドを追加することです:

  • 文書 X:

    • フィールド 1: 4 (数値)
    • Field2: a (テキスト)
    • フィールド 1: 8 (数値)
    • Field2: b (テキスト)
    • リンク: 4_a
    • リンク: 8_b

もう 1 つのコツは、次のようなフィールドを追加し、MyDocument:X各行に個別にインデックスを付けて、各行MyDocumentにそのドキュメントのフィールドを含めることです。これにより、プロセスの後半でドキュメントごとにフィルター処理できます。

于 2013-01-28T21:06:37.940 に答える
0

個人的には、ドキュメント数の増加がパフォーマンスに影響を与える理由がわかりません。少なくとも Java バージョンの Lucene では、メモリの大部分が用語キャッシュに使用されます。これは用語ごとであり、ドキュメント数とは関係ありません (用語数が変わらない場合)。これはアプリに固有のものであるため、使いやすさについて詳しく説明することはできません。

要点は、行をドキュメントにグループ化すると、行の関係情報が失われることです。rowInfoA:4_a追加のフィールド ( ,など) を追加することでこれを修正できますrowInfoB:8_bが、これは面倒すぎて、実際にははるかに多くのメモリが必要になります。はい、インデックスを作成せずにこれらの補助フィールドのみを保存することを選択できますが、(情報があれば) 1:1 の行:ドキュメント マッピングを優先します。

于 2013-01-28T10:38:31.407 に答える