作成する前に、複雑なネストされた集計を使用した検索クエリについて、 Elasticsearch Spring Dataと Elasticsearch HighLevelClientのパフォーマンスを比較するベンチマークを見つけようとしていました。
しかし、私が見つけた唯一のことは、CRUD 操作が必要な場合は、Spring データやその他の機能を自動構成として使用する方が簡単だということでした。しかし、どれもパフォーマンスに関連していませんでした。
両方を使用してパフォーマンスをテストした人がいるかどうか知りたいですか? そのようなクエリでそれらの1つが高速であるという技術的な理由はありますか?
ここで最も重要な部分は、基礎となる正しいクエリを確実に取得することです。最近、間違った設定によりパフォーマンスが 10 倍近く低下するケースがありました。Spring Data は High Level Rest Client を使用するため、通常、オーバーヘッドはまったくないか、わずかであると予想されます。基になるクエリが同じ場合。フレームワークの違いはおそらく小さいので、開発速度と親しみやすさを優先します。
私たちの間違いは、集計で基礎となるドキュメントを返すことでした。これは、送信/(デ)シリアライズするデータが多く、キャッシュも使用しません。これにより、集計で 400 ミリ秒と 40 ミリ秒の差が生じました (ヒットしたとき)。キャッシュ)。
PJMeischを編集してください（@xeraaを気にしないでください）、追加の回答は必要ありません：
既に述べたように、Spring Data Elasticsearch は Elasticsearch RestHighLevelClient を使用し (後で新しい Elasticsearch クライアントを使用します)、集約クエリを作成するために、NativeSearchQueryElasticsearch のクエリ ビルダーを使用してクエリを作成する場所を使用する必要があります。したがって、RestHighLevelClient を直接使用する場合も、クエリの作成は同じです。
@xeraa で既に述べたように、クエリ データではなく aggs のみが必要な場合は、ソース ドキュメントを返さないようにしてください。Spring Data Elasticsearch では、NativeSearchQueryBuilder.withMaxResults(0). 次に、通常どおりクエリをメソッドに渡しますElasticsearchOperations.search()。
Spring Data Elasticsearch は、返された集計に対して解析を行いません。クライアントを直接使用する場合と同じように、そこで同じことを行う必要があります。
したがって、Spring Data Elasticsearch がパフォーマンスの問題に寄与するポイントはわかりません。