ESページングクエリ
6030 ワード
from+sizeページング
一般的なクエリー・プロセスでは、最初の10のデータをクエリーしたい場合は、次のようになります.クライアントは、あるノード への送信を要求する.ノードは各スライスに転送され、各スライス上の最初の10個の を問い合わせる.結果はノードに戻り、データを統合し、上位10本の を抽出する.は、要求クライアント に戻る.
このページング方式はfrom+size方式で実現できる.fromはターゲットデータのオフセット値を定義し、sizeは現在返されるイベントの数を定義します.
このページング方式は、fromが大きくなるにつれてクエリーの時間が大きくなり、データ量が大きくなるほどクエリーの効率指数が低下するため、少量のデータにのみ適しています.
利点:from+sizeデータ量が少ない場合、効率が高いという欠点:データ量が非常に大きい場合、from+sizeページングはすべての記録をメモリにロードし、実行速達が特に遅いだけでなく、esにメモリ不足が発生しやすく、削除しやすい
例えば、5001ページ目のデータを取得するには、ページング時にelasticsearchは、まず各ノードから50020のデータを取り出し、その後、各ノードのすべてのデータと並べ替え、並べ替え後の50010から50020のデータを取り出し、戻ってくる必要があります.これにより、データ量が増加するにつれて、ページごとにソートするコストが増加します.
2つの方法、1.スクロールAPIを使用する.2.[index.max_result_window]パラメータを直接設定します.
my_indexはデフォルトパラメータ値を変更するインデックスに変更され、データ量が2万以上で大きな数の変化が起こらないなど、後の数値も自分で設定できます.値を30000に設定できます.Kibanaコントロールパネルであれば、次のセクションを実行します.
ElasticSearchは実際には検索エンジンとして適しており、このようなページングクエリーはクエリーを遍歴しているが、実際には適切ではない.また、数値設定が大きすぎると、機器に圧力がかかり、メモリオーバーフローなどのエラーが発生する可能性があります.
scroll深さページング
ES深さのページングを避けるために、ページング(from&size)を使用して10000以降のデータをクエリーすることはできません.したがって、10000以降のデータをクエリーする場合は、ESが提供するscroll(カーソル)を使用してクエリーします.
scrollはリレーショナル・データベースのcursorとして理解できます.そのため、scrollはリアルタイム検索には適していません.群発などのバックグラウンド・バッチ・タスクに適しています.
scrollは具体的に初期化と遍歴の2つのステップに分けられます
1、初期化時に検索条件に合致するすべての検索結果をキャッシュし、スナップショットとして想像することができる.
初期化時は通常のsearchのようにscroll=3 mが現在のクエリを表すデータキャッシュ3分Size:3が現在のクエリを表す3つのデータ
2、遍歴して、このスナップショットからデータを取ります.遍歴中に前回遍歴中のscroll_idは、scrollパラメータを使用して、前回のループステップを繰り返し、返されたデータが空になるまでループが完了したことを示します.毎回パラメータscrollを転送し、検索結果のキャッシュ時間をリフレッシュし、indexとtypeを指定する必要はありません(キャッシュ時間を長く設定せず、メモリを消費しないでください).
カーソルがパフォーマンスを上げる理由は、深いページを作ると検索のたびに並べ替え直さなければならないため、無駄です.scrollを使うと、使用するデータを一度に並べてバッチで取り出すので、from+sizeを使うよりもいいです.
具体例
1、初期化
リクエスト
注意URLのsearchにscroll=1 mを付けるにはrequest bodyに書くことはできません.1 mはこのカーソルが1分間開いていることを示しています
sizeサイズを指定できます.つまり、数回のデータが返されるたびに、データがないまで返されると、200が成功します.hitsのhitsは空のlistになります.
初期化時に返信を除くscroll_idは、上位100件(size=100と仮定)のデータも返信されます
request bodyは一般検索と同様であるため,初期化の過程でscroll設定カーソルオン時間を加える以外は一般検索と変わらないといえる(クエリー条件を設定するには,前sizeペンのデータも返信する).
結果を返す
2、遍歴データ
リクエスト
初期化を使用して返された_scroll_idはリクエストを行い、リクエストごとに初期化中の未読データを返し続け、1つの_を返します.scroll_id,これ_scroll_idは変更される可能性があるので、リクエストごとに前回のリクエストを持って帰るべきです.scroll_id
戻ってくるのは_scroll_id、でもリクエストに入れたのはscroll_id、両者のスペルが違います
また、scrollリクエストを送信するたびに、このscrollのオープン時間を再リフレッシュし、うっかりタイムアウトしてデータが不完全になることを防止します.
結果を返す
データがないと空のhitsが返ってきて、これでデータが遍歴したかどうかを判断できます
scrollクエリーの最適化
一般的なシーンでは、scrollは通常、ソートが必要な大きなデータを取得するために使用されますが、データ間のソート性は私たちにとって関係なく、すべてのデータが取り出せば良い場合があります.この場合、scrollを最適化することができます.
初期化
使用_docがsortに行って得た結果、この実行の効率は最も速いが、データはソートされず、すべてのデータを取得したいシーンに適している.
scrollのクリア
scrollをオンに設定すると、1つのscrollの生存時間を設定しますが、使い終わったら手で閉じることができれば、リソースを早めに解放し、ESの負担を減らすことができます.
一般的なクエリー・プロセスでは、最初の10のデータをクエリーしたい場合は、次のようになります.
このページング方式はfrom+size方式で実現できる.fromはターゲットデータのオフセット値を定義し、sizeは現在返されるイベントの数を定義します.
このページング方式は、fromが大きくなるにつれてクエリーの時間が大きくなり、データ量が大きくなるほどクエリーの効率指数が低下するため、少量のデータにのみ適しています.
利点:from+sizeデータ量が少ない場合、効率が高いという欠点:データ量が非常に大きい場合、from+sizeページングはすべての記録をメモリにロードし、実行速達が特に遅いだけでなく、esにメモリ不足が発生しやすく、削除しやすい
例えば、5001ページ目のデータを取得するには、ページング時にelasticsearchは、まず各ノードから50020のデータを取り出し、その後、各ノードのすべてのデータと並べ替え、並べ替え後の50010から50020のデータを取り出し、戻ってくる必要があります.これにより、データ量が増加するにつれて、ページごとにソートするコストが増加します.
2つの方法、1.スクロールAPIを使用する.2.[index.max_result_window]パラメータを直接設定します.
curl -XPUT http://127.0.0.1:9200/my_index/_settings -d '{ "index" : { "max_result_window" : 500000}}'my_indexはデフォルトパラメータ値を変更するインデックスに変更され、データ量が2万以上で大きな数の変化が起こらないなど、後の数値も自分で設定できます.値を30000に設定できます.Kibanaコントロールパネルであれば、次のセクションを実行します.
PUT my_index/_settings
{
"index":{
"max_result_window":500000
}
}ElasticSearchは実際には検索エンジンとして適しており、このようなページングクエリーはクエリーを遍歴しているが、実際には適切ではない.また、数値設定が大きすぎると、機器に圧力がかかり、メモリオーバーフローなどのエラーが発生する可能性があります.
scroll深さページング
ES深さのページングを避けるために、ページング(from&size)を使用して10000以降のデータをクエリーすることはできません.したがって、10000以降のデータをクエリーする場合は、ESが提供するscroll(カーソル)を使用してクエリーします.
scrollはリレーショナル・データベースのcursorとして理解できます.そのため、scrollはリアルタイム検索には適していません.群発などのバックグラウンド・バッチ・タスクに適しています.
scrollは具体的に初期化と遍歴の2つのステップに分けられます
1、初期化時に検索条件に合致するすべての検索結果をキャッシュし、スナップショットとして想像することができる.
GET fs/_search?scroll=3m
{
"query": {"match_all": {}},
"size": 3
}初期化時は通常のsearchのようにscroll=3 mが現在のクエリを表すデータキャッシュ3分Size:3が現在のクエリを表す3つのデータ
2、遍歴して、このスナップショットからデータを取ります.遍歴中に前回遍歴中のscroll_idは、scrollパラメータを使用して、前回のループステップを繰り返し、返されたデータが空になるまでループが完了したことを示します.毎回パラメータscrollを転送し、検索結果のキャッシュ時間をリフレッシュし、indexとtypeを指定する必要はありません(キャッシュ時間を長く設定せず、メモリを消費しないでください).
カーソルがパフォーマンスを上げる理由は、深いページを作ると検索のたびに並べ替え直さなければならないため、無駄です.scrollを使うと、使用するデータを一度に並べてバッチで取り出すので、from+sizeを使うよりもいいです.
具体例
1、初期化
リクエスト
注意URLのsearchにscroll=1 mを付けるにはrequest bodyに書くことはできません.1 mはこのカーソルが1分間開いていることを示しています
sizeサイズを指定できます.つまり、数回のデータが返されるたびに、データがないまで返されると、200が成功します.hitsのhitsは空のlistになります.
初期化時に返信を除くscroll_idは、上位100件(size=100と仮定)のデータも返信されます
request bodyは一般検索と同様であるため,初期化の過程でscroll設定カーソルオン時間を加える以外は一般検索と変わらないといえる(クエリー条件を設定するには,前sizeペンのデータも返信する).
POST 127.0.0.1:9200/my_index/_search?scroll=1m
{
"query":{
"range":{
"createTime": {
"gte": 1522229999999
}
}
},
"size": 1000
}結果を返す
{
"_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAfv5-FjNOamF0Mk1aUUhpUnU5ZWNMaHJocWcAAAAAAH7-gBYzTmphdDJNWlFIaVJ1OWVjTGhyaHFnAAAAAAB-_n8WM05qYXQyTVpRSGlSdTllY0xocmhxZwAAAAAAdsJxFmVkZTBJalJWUmp5UmI3V0FYc2lQbVEAAAAAAHbCcBZlZGUwSWpSVlJqeVJiN1dBWHNpUG1R",
"took": 2,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 84,
"max_score": 1,
"hits": [
{
"_index": "video1522821719",
"_type": "doc",
"_id": "84056",
"_score": 1,
"_source": {
"title": " ",
"createTime": 1522239744000
}
}
....99 data
]
}
}2、遍歴データ
リクエスト
初期化を使用して返された_scroll_idはリクエストを行い、リクエストごとに初期化中の未読データを返し続け、1つの_を返します.scroll_id,これ_scroll_idは変更される可能性があるので、リクエストごとに前回のリクエストを持って帰るべきです.scroll_id
戻ってくるのは_scroll_id、でもリクエストに入れたのはscroll_id、両者のスペルが違います
また、scrollリクエストを送信するたびに、このscrollのオープン時間を再リフレッシュし、うっかりタイムアウトしてデータが不完全になることを防止します.
POST 127.0.0.1:9200/_search/scroll?scroll=1m
{
"scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAdsMqFmVkZTBJalJWUmp5UmI3V0FYc2lQbVEAAAAAAHbDKRZlZGUwSWpSVlJqeVJiN1dBWHNpUG1RAAAAAABpX2sWclBEekhiRVpSRktHWXFudnVaQ3dIQQAAAAAAaV9qFnJQRHpIYkVaUkZLR1lxbnZ1WkN3SEEAAAAAAGlfaRZyUER6SGJFWlJGS0dZcW52dVpDd0hB"
}結果を返す
データがないと空のhitsが返ってきて、これでデータが遍歴したかどうかを判断できます
{
"_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAdsMqFmVkZTBJalJWUmp5UmI3V0FYc2lQbVEAAAAAAHbDKRZlZGUwSWpSVlJqeVJiN1dBWHNpUG1RAAAAAABpX2sWclBEekhiRVpSRktHWXFudnVaQ3dIQQAAAAAAaV9qFnJQRHpIYkVaUkZLR1lxbnZ1WkN3SEEAAAAAAGlfaRZyUER6SGJFWlJGS0dZcW52dVpDd0hB",
"took": 2,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 84,
"max_score": null,
"hits": []
}
}scrollクエリーの最適化
一般的なシーンでは、scrollは通常、ソートが必要な大きなデータを取得するために使用されますが、データ間のソート性は私たちにとって関係なく、すべてのデータが取り出せば良い場合があります.この場合、scrollを最適化することができます.
初期化
使用_docがsortに行って得た結果、この実行の効率は最も速いが、データはソートされず、すべてのデータを取得したいシーンに適している.
POST 127.0.0.1:9200/my_index/_search?scroll=1m
{
"query": {
"match_all" : {}
},
"sort": [
"_doc"
]
}
}scrollのクリア
scrollをオンに設定すると、1つのscrollの生存時間を設定しますが、使い終わったら手で閉じることができれば、リソースを早めに解放し、ESの負担を減らすことができます.
DELETE 127.0.0.1:9200/_search/scroll
{
"scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAdsMqFmVkZTBJalJWUmp5UmI3V0FYc2lQbVEAAAAAAHbDKRZlZGUwSWpSVlJqeVJiN1dBWHNpUG1RAAAAAABpX2sWclBEekhiRVpSRktHWXFudnVaQ3dIQQAAAAAAaV9qFnJQRHpIYkVaUkZLR1lxbnZ1WkN3SEEAAAAAAGlfaRZyUER6SGJFWlJGS0dZcW52dVpDd0hB"
}