Elasticsearch 2.3.0新規:クエリー更新インタフェースupdate-by-query
5779 ワード
クエリー更新インタフェースは2.3.0で新しいインタフェースを追加し、このインタフェースは現在実験的である.このインタフェースは、将来のバージョンで変更される可能性があります.このインタフェースは、インデックス内で各ドキュメントを更新し、ドキュメントの内容が変更されていない場合に使用します.これは、新しいプロパティを追加したり、マッピングを変更したりするときに便利です.例:
リクエスト:POST/twitter/update_by_query?conflicts=proceed
結果は次のとおりです.
_update_by_Queryシステムが開始したり、内部バージョン番号でインデックスを作成したりしている間にインデックスのスナップショットが取得され、スナップショットが処理されたり、インデックスリクエストが処理されたりすると、ドキュメントが変更されるとバージョン競合が発生します.一致するバージョンのドキュメントが更新されると、ドキュメントのバージョン番号が増加します.更新とクエリーが失敗した場合、update_by_Queryが中止し、戻り値に失敗した理由を返します.実行された更新は保持されます.つまり、この過程はロールバックされず、中止するしかない.1つ目が失敗すると、プログラムが中止されます.これは、すべての更新が失敗したことを意味し、大量の失敗要素が返されます.
バージョンが競合している場合は、中止せずに簡単なカウントのみを行う場合は、urlでconflicts=proceedを設定するか、リクエスト内容で「conflicts」:「proceed」を設定します.apiでは、インデックスの1つのタイプのみを操作できます.たとえば、次のようにします.
リクエスト:POST/twitter/tweet/update_by_query?conflicts=proceed
DSL構文を使用してクエリを実行することもできます.たとえば、次のようになります.
リクエスト:POST/twitter/update_by_query?conflicts=proceed
ここでの検索は他の検索の構文と一致しています.
前に紹介したのはすべて文書の内容を変えていないので、実は_update_by_queryは、サポートスクリプトによるドキュメントコンテンツの更新です.例:
リクエスト:POST/twitter/update_by_query
このインタフェースは、複数のインデックスと複数のタイプで同時に操作できます.たとえば、次のようになります.
リクエスト:POST/twitter,blog/tweet,post/update_by_query
また、ルーティングクエリーを指定することもできます.たとえば、次のようにします.
リクエスト:POST/twitter/update_by_query?routing=1
デフォルトでは_update_by_queryは100ロットをスクロールします.URLパラメータでscroll_を使うことができますsizeは、次のようにロットのサイズを変更します.
リクエスト:POST/twitter/update_by_query?scroll_size=1000
寸法のパラメータに加えて、update_by_queryはrefresh,wait_もサポートしていますfor_completion, consistency, timeout.
リフレッシュ(refresh)操作は、リクエストが完了したときにインデックスが更新されたときのすべてのスライスにすぎず、インデックスが更新されたときのリフレッシュとは異なり、インデックスが受信されたときに現在のデータスライスのみがリフレッシュされます.リクエストにwait_が含まれている場合for_completion=false、Elasticsearchは実行前のチェックを行い、要求を開始し、タスクに戻ります.このタスクで操作をキャンセルしたり、タスクのステータスを取得したりすることができます.タスクの完了を要求すると終了します.唯一記録されているのはelasticsearchログファイルにタスクの実行結果があり、この問題は後で修正されます.コンシステンシ(consistency)は、リクエストごとにどれだけのスライスのコピーが応答されるかを制御し、リクエストごとに待機する時間をタイムアウト制御する.Bulk APIでは、彼らがどのように働いているかを正確に知ることができます.タイムアウト制御は、ターゲットフラグメントになるまでどのくらい待機しますか.
応答の紹介です.応答の内容は次のようになります.
took:開始から終了までの操作全体のミリ秒数.
updated:正常に更新されたドキュメントの数.
batches:スクロール応答の数.
version_conflicts:クエリーによって更新されたバージョン競合の数.
failures:すべてのインデックスに失敗した配列.これが空でない場合は、中止を要求します.
クエリーの更新操作が発生した場合、タスクインタフェースを使用してステータスを取得できます.たとえば、次のようになります.
要求:POST/tasks/?pretty&detailed=true&action=*byquery
応答:
オブジェクトには実際の状態が含まれます.中には重要なパラメータがtotalで、総操作数を再構築する予定です.この進捗状況は、更新、作成、削除フィールドを追加することで推定できます.合計がカラム全体に等しい場合、リクエストは完了します.
動的マッピングのないインデックスを作成すると、新しいデータコンテンツがある場合、データ内の複数のフィールドに一致する新しいマッピング値が追加されます.たとえば、次のようにします.
要求:PUT test、データ構造はtestのみ
データの挿入:
要求:POST test/test?refresh
次に、データ構造を取得します.
要求:PUT test/mapping/test
このときflagマッピングが自動的に追加されます.
しかし、この時点でデータが照会され、値は見つかりません.
要求:POST test/search?filter_path=hits.total
パラメータ:
戻り値:
この場合、更新されたクエリー・リクエストを使用してデータを取得できます.たとえば、次のようにします.
要求:POST test/update_by_query?refresh&conflicts=proceed
POST test/_search?filter_path=hits.total
パラメータ:
戻り値:
サイクランド(secisland)は、Elasticsearchの最新バージョンの各機能を徐々に分析していきますので、ご期待ください.ようこそ
secisland公衆番号に注目.
リクエスト:POST/twitter/update_by_query?conflicts=proceed
結果は次のとおりです.
{
"took" : 639,
"updated": 1235,
"batches": 13,
"version_conflicts": 2,
"failures" : [ ]
}
_update_by_Queryシステムが開始したり、内部バージョン番号でインデックスを作成したりしている間にインデックスのスナップショットが取得され、スナップショットが処理されたり、インデックスリクエストが処理されたりすると、ドキュメントが変更されるとバージョン競合が発生します.一致するバージョンのドキュメントが更新されると、ドキュメントのバージョン番号が増加します.更新とクエリーが失敗した場合、update_by_Queryが中止し、戻り値に失敗した理由を返します.実行された更新は保持されます.つまり、この過程はロールバックされず、中止するしかない.1つ目が失敗すると、プログラムが中止されます.これは、すべての更新が失敗したことを意味し、大量の失敗要素が返されます.
バージョンが競合している場合は、中止せずに簡単なカウントのみを行う場合は、urlでconflicts=proceedを設定するか、リクエスト内容で「conflicts」:「proceed」を設定します.apiでは、インデックスの1つのタイプのみを操作できます.たとえば、次のようにします.
リクエスト:POST/twitter/tweet/update_by_query?conflicts=proceed
DSL構文を使用してクエリを実行することもできます.たとえば、次のようになります.
リクエスト:POST/twitter/update_by_query?conflicts=proceed
{
"query": {
"term": {
"user": "kimchy"
}
}
}
ここでの検索は他の検索の構文と一致しています.
前に紹介したのはすべて文書の内容を変えていないので、実は_update_by_queryは、サポートスクリプトによるドキュメントコンテンツの更新です.例:
リクエスト:POST/twitter/update_by_query
{
"script": {
"inline": "ctx._source.likes++"
},
"query": {
"term": {
"user": "kimchy"
}
}
}
このインタフェースは、複数のインデックスと複数のタイプで同時に操作できます.たとえば、次のようになります.
リクエスト:POST/twitter,blog/tweet,post/update_by_query
また、ルーティングクエリーを指定することもできます.たとえば、次のようにします.
リクエスト:POST/twitter/update_by_query?routing=1
デフォルトでは_update_by_queryは100ロットをスクロールします.URLパラメータでscroll_を使うことができますsizeは、次のようにロットのサイズを変更します.
リクエスト:POST/twitter/update_by_query?scroll_size=1000
寸法のパラメータに加えて、update_by_queryはrefresh,wait_もサポートしていますfor_completion, consistency, timeout.
リフレッシュ(refresh)操作は、リクエストが完了したときにインデックスが更新されたときのすべてのスライスにすぎず、インデックスが更新されたときのリフレッシュとは異なり、インデックスが受信されたときに現在のデータスライスのみがリフレッシュされます.リクエストにwait_が含まれている場合for_completion=false、Elasticsearchは実行前のチェックを行い、要求を開始し、タスクに戻ります.このタスクで操作をキャンセルしたり、タスクのステータスを取得したりすることができます.タスクの完了を要求すると終了します.唯一記録されているのはelasticsearchログファイルにタスクの実行結果があり、この問題は後で修正されます.コンシステンシ(consistency)は、リクエストごとにどれだけのスライスのコピーが応答されるかを制御し、リクエストごとに待機する時間をタイムアウト制御する.Bulk APIでは、彼らがどのように働いているかを正確に知ることができます.タイムアウト制御は、ターゲットフラグメントになるまでどのくらい待機しますか.
応答の紹介です.応答の内容は次のようになります.
{
"took" : 639,
"updated": 0,
"batches": 1,
"version_conflicts": 2,
"failures" : [ ]
}
took:開始から終了までの操作全体のミリ秒数.
updated:正常に更新されたドキュメントの数.
batches:スクロール応答の数.
version_conflicts:クエリーによって更新されたバージョン競合の数.
failures:すべてのインデックスに失敗した配列.これが空でない場合は、中止を要求します.
クエリーの更新操作が発生した場合、タスクインタフェースを使用してステータスを取得できます.たとえば、次のようになります.
要求:POST/tasks/?pretty&detailed=true&action=*byquery
応答:
{
"nodes" : {
"r1A2WoRbTwKZ516z6NEs5A" : {
"name" : "Tyrannus",
"transport_address" : "127.0.0.1:9300",
"host" : "127.0.0.1",
"ip" : "127.0.0.1:9300",
"attributes" : {
"testattr" : "test",
"portsfile" : "true"
},
"tasks" : {
"r1A2WoRbTwKZ516z6NEs5A:36619" : {
"node" : "r1A2WoRbTwKZ516z6NEs5A",
"id" : 36619,
"type" : "transport",
"action" : "indices:data/write/update/byquery",
"status" : {
"total" : 6154,
"updated" : 3500,
"created" : 0,
"deleted" : 0,
"batches" : 36,
"version_conflicts" : 0,
"noops" : 0
},
"description" : ""
}
}
}
}
}
オブジェクトには実際の状態が含まれます.中には重要なパラメータがtotalで、総操作数を再構築する予定です.この進捗状況は、更新、作成、削除フィールドを追加することで推定できます.合計がカラム全体に等しい場合、リクエストは完了します.
動的マッピングのないインデックスを作成すると、新しいデータコンテンツがある場合、データ内の複数のフィールドに一致する新しいマッピング値が追加されます.たとえば、次のようにします.
要求:PUT test、データ構造はtestのみ
{
"mappings": {
"test": {
"dynamic": false,
"properties": {
"text": {"type": "string"}
}
}
}
}
データの挿入:
要求:POST test/test?refresh
{
"text": "words words",
"flag": "bar"
}
次に、データ構造を取得します.
要求:PUT test/mapping/test
{
"properties": {
"text": {"type": "string"},
"flag": {"type": "string", "analyzer": "keyword"}
}
}
このときflagマッピングが自動的に追加されます.
しかし、この時点でデータが照会され、値は見つかりません.
要求:POST test/search?filter_path=hits.total
パラメータ:
{
"query": {
"match": {
"flag": "bar"
}
}
}
戻り値:
{
"hits" : {
"total" : 0
}
}
この場合、更新されたクエリー・リクエストを使用してデータを取得できます.たとえば、次のようにします.
要求:POST test/update_by_query?refresh&conflicts=proceed
POST test/_search?filter_path=hits.total
パラメータ:
{
"query": {
"match": {
"flag": "foo"
}
}
}
戻り値:
{
"hits" : {
"total" : 1
}
}
サイクランド(secisland)は、Elasticsearchの最新バージョンの各機能を徐々に分析していきますので、ご期待ください.ようこそ
secisland公衆番号に注目.