0

ElasticSearch の基本的な実装をセットアップし、ドキュメントにいくつかのフィールドを保存して、クエリを実行できるようにしました。

var searchResult = client.Search<SearchTest>(s =>
    s
    .Size(1000)
    .Fields(f => f.ID)
    .Query(q => q.QueryString(d => d.Query(query)))
    )
    .Documents.Select(item =>
        item.ID
        )
    .ToList();

var products = this.DbContext.Products
    .Where(item =>
        searchResult.Contains(item.ProductId)
        && ...
        )
    .Select(item => ...);

// subsequent queries here

現時点では、データベース クエリで大量の情報を取得するために使用するインデックスを返すだけです。ドキュメントに保存されている情報も取得されます。これをデータベースから取得するのをスキップして、ドキュメント ストアのデータを使用する必要があるのでしょうか。それとも、検索以外の目的で使用する必要がありますか?

一部のコンテキスト: 製品データベースでの検索では、一部の情報は常に同じであり、一部の情報 (価格計算など) は、検索している顧客によって異なります。

4

2 に答える 2

1

この質問に対する厳密で迅速な答えは実際にはありません。検索結果のリストを作成するのに十分な情報をインデックスから取得するのが好きですが、他の外部ソース (データベースなど) からドキュメントの完全なコンテンツを取得します。完全に主観的に、これは私が見たものから、Lucene のより一般的な使用法のようです。

私の知る限り、ストレージ戦略は検索パフォーマンスに直接影響を与えるべきではありませんが、各ドキュメントに保存されるデータを最小限に抑えることで、インデックスからドキュメントを取得するパフォーマンスが向上します (つまり、前述の結果のリスト)。

また、Lucene を記録システムにすることを躊躇することもあります。データベースよりも壊れた/破損したインデックスを見つける方がはるかに簡単なようです. 廃棄して再構築するオプションを利用できるようにするのが好きです。

于 2013-07-02T16:25:24.477 に答える
1

すでに回答を受け入れているようですが、2 番目のアプローチを提供したいと思います。

Elasticsearch はドキュメント (json) の保存に優れているため、完全なオブジェクト グラフを取得することは、インピーダンスの不一致と N+1 センシティブなデータベース クエリを克服するための非常に高速で強力なアプローチとなります。

私にとって最善のアプローチは、後で N 個のデータベースクエリを実行することなくsearchResults、すでに決定的なリストになっていることです。IEnumerable<Product>

Elasticsearch には (生の lucene や Solr とは異なり) と呼ばれる元の json グラフを格納する特別なフィールドがある_sourceため、ドキュメント全体を読み込むオーバーヘッドは非常に最小限に抑えられます。

これには基本的に、データベースに 1 回、ミューテーションごとに Elasticsearch に 1 回、合計 2 回データを書き込まなければならないという代償が伴います。アーキテクチャによっては、これが達成できる場合とできない場合があります。

@femtoRgon の意見では、外部データソースからインデックスを再作成できるのは良い考えであることに同意しますが、Elasticsearch の開発者は 1.0 に向けて適切なバックアップと復元を行うために懸命に取り組んでいます。これにより、2 番目のデータストレージの必要性が大幅に削減されます。

ところで、気づいているかどうかはわかりませんが、指定する.Fields()と、特別なフィールドからグラフ全体ではなく、Elasticsearch が指定されたフィールドのみをロードするように強制されます_source。

于 2013-07-03T18:00:25.403 に答える