2016-08-03 11 views
0

私は、複数のフィールドを持つ〜50Kのドキュメントを含むインデックスを持っています。フィールドの1つは、テキストを含む「コンテンツ」(わずかな単語または非常に大きな記事であり得る)である。 文書全体には、「内容」フィールドに関して多くの重複があります。 「コンテンツ」のどのグループに属するかを示すgroup_idフィールドを追加したいと思います。elasticsearchで正確な全文検索を見つけよう

私は "match"と "more_like_this"を使ってみましたが、正確な重複を返すようには見えませんでしたが、ほぼ重複したものを返すようです。

例:私は取得したいと思い

{ "author": "name1", "content": "text1" }, { "author": "name2", "content": "text2" } { "author": "name3", "content": "text1" } { "author": "name4", "content": "text2" } { "author": "name5", "content": "text3" }

: は、次のインデックスを指定する

{ "author": "name1", "content": "text1", "group_id: 0 }, { "author": "name2", "content": "text2", "group_id: 1 } { "author": "name3", "content": "text1", "group_id: 0 } { "author": "name4", "content": "text2", "group_id: 1 } { "author": "name5", "content": "text3", "group_id: 2 }

感謝を!

答えて

0

私はあなたのケースの内容が分析されたフィールドだと推測します。これはデフォルトであり、フルテキスト検索クエリを実行するためには必要です。しかし、それは実際に完全な生の形式でインデックスされていないので、Elasticsearchはそのフィールドの正確な文字列一致を見つけることができません。次のタイプマッピングを使用すると、解析されていないフィールドに対して正確な文字列一致のみが見つかります。

{ 
    "content": { 
     "type":  "string", 
     "index": "not_analyzed" 
    } 
} 

ただし、これは実際には2つの理由からあなたのケースでは非常に悪い考えです:まず、このフィールドでフルテキスト検索を行うことができなくなるので、分析の有無にかかわらず、2回索引付けする必要があります。第2に、かなり大きな値を持つ可能性があるため、インデックス全体を検索するのに非効率的です。

実際の要件は、Elasticsearchとの大きな文字列マッチングを行うことではなく、コンテンツの値で文書をグループ化することです。これを行うより良い方法は、コンテンツフィールドのダイジェスト(ハッシュ)を保持し、そのフィールドでグループ化するフィールドをドキュメントに追加することです。ダイジェストは文字列フィールドにする必要はありませんが、実際には数値にしておくのが理にかなっています。一意性と速度を目的とした、32ビットまたは128ビットのハッシュを生成できるMurmurHash3のようなハッシングアルゴリズムを調べてみましょう。その後、すべての文書を繰り返して更新します。

+0

良いアイデアのように見えますが、試してみます。ところで、なぜダイジェストを文字列ではなく数値(例えばmd5)にするのが理にかなっていますか? – Eitan

+0

すべてのダイジェストは数値から始まります。ビット(md5の場合は128)の束です。文字列表現にエンコードして、読みやすく/印刷可能にします。したがって数値を維持することは、値を表現するためのよりコンパクトな方法です。格納、索引および検索の効率が向上します。 Murmur3の32ビット版を例に取ってみましょう。数値的に格納するには、32ビット(すなわち4バイトまたは1つの長さ)が必要です。最もコンパクトな*印刷可能な表現が可能な文字列にエンコードするには、base85(40ビット、5バイト) base64(44ビットは6バイトであるため48にパディングされます)。 –

+0

お返事ありがとうございました! (アップカウントはまだカウントされていません) – Eitan

関連する問題