私たちは、システム内のさまざまなリソースにまたがる「統合された」検索を構築しています。当社のインデックス スキーマには、インデックスが作成された約 10 の一般的なフィールドと、結果が返されたときにシステム内の適切なリソースの場所を識別するために必要な 5 つのフィールドが含まれています。
インデックス化されたフィールドには機密データが含まれることが多いため、それらをまったく保存せず、照合のためにのみインデックス化するため、 を に設定_sourceしFALSEます。
ただし、5 つの ident フィールドを返したいので、ident フィールドをstore=に設定することは可能ですyesが、全体的なインデックス_sourceをに設定FALSEして、結果で探しているものを取得できますか?
この他の回答もご覧ください。そこで述べたように、ほとんどの場合、_sourceフィールドは大いに役立ちます。Elasticsearch は受信したドキュメント全体を効果的に保存するため無駄に思えるかもしれませんが、これは非常に便利です (たとえば、更新されたドキュメント全体を送信せずにドキュメントを更新する必要がある場合)。結局のところ、Lucene 実装の詳細が隠されています。ユーザーは通常、検索エンジンに送信したものが返されることを期待していますが、フィールドを取得したい場合はフィールドを明示的に保存する必要があるという事実です。驚くべきことに、_source複数の格納されたフィールドを取得することで発生する可能性のあるディスク シークが増えるのではなく、単一のディスク シークが必要になるため、パフォーマンスも向上します。一日の終わりには、_sourcefield は、json を含む大きな lucene 格納フィールドであり、解析して特定のフィールドにアクセスし、それらを個別に格納する必要なく何らかの作業を行うことができます。
とはいえ、ユースケース (取得するフィールドの数) によっては、 _source フィールド参照の下部にあるソースの include/exclude を確認すると便利な場合があります。これにより、部分 (ドキュメントの機密部分など) を防ぐことができます。 ) が保存されないようにします。に依存し続けたい_sourceが、入力ドキュメントの一部を返したくないが、それらのフィールドに対して検索を行いたい場合に役立ちます。基になるルセン インデックスで。
どちらの場合でも (_source完全に無効にするか、一部を除外するかのいずれか)、ドキュメントを更新する予定がある場合は、インデックス API を使用して更新されたドキュメント全体を送信する必要があることに注意してください。実際、変更を適用する必要がある、最初にインデックスを作成した完全なドキュメントがインデックスにないため、更新 API で提供される部分的な更新に依存することはできません。