Index API

マッピングタイプの削除を参照してください。

指定されたデータストリームまたはインデックスにJSONドキュメントを追加し、検索可能にします。ターゲットがインデックスであり、ドキュメントがすでに存在する場合、リクエストはドキュメントを更新し、そのバージョンをインクリメントします。

データストリームに既存のドキュメントの更新リクエストを送信するためにインデックスAPIを使用することはできません。クエリによるデータストリーム内のドキュメントの更新およびバックインデックス内のドキュメントの更新または削除を参照してください。

Request

PUT /<target>/_doc/<_id>

POST /<target>/_doc/

PUT /<target>/_create/<_id>

POST /<target>/_create/<_id>

PUT /<target>/_doc/<_id>リクエスト形式を使用してデータストリームに新しいドキュメントを追加することはできません。ドキュメントIDを指定するには、PUT /<target>/_create/<_id>形式を代わりに使用してください。データストリームにドキュメントを追加するを参照してください。

Prerequisites

  • Elasticsearchのセキュリティ機能が有効になっている場合、ターゲットデータストリーム、インデックス、またはインデックスエイリアスに対して次のindex privilegesを持っている必要があります：
    • PUT /<target>/_doc/<_id>リクエスト形式を使用してドキュメントを追加または上書きするには、create、index、またはwriteインデックス権限が必要です。
    • POST /<target>/_doc/、PUT /<target>/_create/<_id>、またはPOST /<target>/_create/<_id>リクエスト形式を使用してドキュメントを追加するには、create_doc、create、index、またはwriteインデックス権限が必要です。
    • インデックスAPIリクエストでデータストリームまたはインデックスを自動的に作成するには、auto_configure、create_index、またはmanageインデックス権限が必要です。
  • 自動データストリーム作成には、データストリームが有効な一致するインデックステンプレートが必要です。データストリームの設定を参照してください。

Path parameters

  • <target>
  • (必須、文字列) ターゲットとするデータストリームまたはインデックスの名前。
    ターゲットが存在せず、*定義を持つインデックステンプレートの名前またはワイルドカード(*)パターンに一致する場合、このリクエストはデータストリームを作成します。データストリームの設定を参照してください。
    ターゲットが存在せず、データストリームテンプレートに一致しない場合、このリクエストはインデックスを作成します。
    既存のターゲットを確認するには、解決インデックスAPIを使用できます。
  • <_id>
  • (オプション、文字列) ドキュメントの一意の識別子。
    このパラメータは次のリクエスト形式に必要です：
    • PUT /<target>/_doc/<_id>
    • PUT /<target>/_create/<_id>
    • POST /<target>/_create/<_id>
      ドキュメントIDを自動的に生成するには、POST /<target>/_doc/リクエスト形式を使用し、このパラメータを省略します。

Query parameters

  • if_seq_no
  • (オプション、整数) ドキュメントがこのシーケンス番号を持つ場合のみ操作を実行します。楽観的同時実行制御を参照してください。
  • if_primary_term

  • (オプション、整数) ドキュメントがこのプライマリタームを持つ場合のみ操作を実行します。楽観的同時実行制御を参照してください。

  • op_type
  • (オプション、列挙型) ドキュメントがすでに存在しない場合のみインデックスするためにcreateに設定します（存在しない場合は配置）。指定された_idを持つドキュメントがすでに存在する場合、インデックス操作は失敗します。<index>/_createエンドポイントを使用するのと同じです。有効な値：index、create。ドキュメントIDが指定されている場合、デフォルトはindexです。そうでない場合、デフォルトはcreateです。
    リクエストがデータストリームをターゲットにしている場合、op_typeはcreateである必要があります。データストリームにドキュメントを追加するを参照してください。
  • pipeline
  • (オプション、文字列) 受信ドキュメントを前処理するために使用するパイプラインのID。インデックスにデフォルトのインジェストパイプラインが指定されている場合、この値を_noneに設定すると、このリクエストのデフォルトのインジェストパイプラインが無効になります。最終的なパイプラインが構成されている場合は、このパラメータの値に関係なく常に実行されます。
  • refresh
  • (オプション、列挙型) trueの場合、Elasticsearchは影響を受けるシャードを更新してこの操作を検索可能にします。wait_forの場合は、検索可能にするために更新を待ちます。falseの場合は、更新に対して何もしません。有効な値：true、false、wait_for。デフォルト：false。
  • routing
  • (オプション、文字列) 操作を特定のシャードにルーティングするために使用されるカスタム値。
  • timeout
  • (オプション、時間単位) リクエストが次の操作を待機する期間：
  • version
  • (オプション、整数) 同時実行制御のための明示的なバージョン番号。指定されたバージョンは、リクエストが成功するために現在のドキュメントのバージョンと一致する必要があります。
  • version_type
  • (オプション、列挙型) 特定のバージョンタイプ：external、external_gte。
  • wait_for_active_shards
  • (オプション、文字列) 操作を進める前にアクティブでなければならないシャードコピーの数。allまたはインデックス内のシャードの合計数(number_of_replicas+1)までの任意の正の整数に設定します。デフォルト：1、プライマリシャード。
    アクティブシャードを参照してください。
  • require_alias
  • (オプション、Boolean) trueの場合、宛先はindex aliasでなければなりません。デフォルトはfalseです。

Request body

  • <field>
  • (必須、文字列) リクエストボディにはドキュメントデータのJSONソースが含まれます。

Response body

  • _shards
  • インデックス操作のレプリケーションプロセスに関する情報を提供します。
  • _shards.total
  • インデックス操作が実行されるべきシャードコピーの数（プライマリおよびレプリカシャード）を示します。
  • _shards.successful
  • インデックス操作が成功したシャードコピーの数を示します。インデックス操作が成功した場合、successfulは少なくとも1です。
    レプリカシャードは、インデックス操作が成功したときにすべてが開始されているわけではありません。デフォルトでは、プライマリのみが必要です。このデフォルトの動作を変更するにはwait_for_active_shardsを設定します。アクティブシャードを参照してください。
  • _shards.failed
  • インデックス操作がレプリカシャードで失敗した場合のレプリケーション関連のエラーを含む配列。0は失敗がなかったことを示します。
  • _index
  • ドキュメントが追加されたインデックスの名前。
  • _type
  • ドキュメントタイプ。Elasticsearchインデックスは現在、単一のドキュメントタイプ_docをサポートしています。
  • _id
  • 追加されたドキュメントの一意の識別子。
  • _version
  • ドキュメントのバージョン。ドキュメントが更新されるたびにインクリメントされます。
  • _seq_no
  • インデックス操作のためにドキュメントに割り当てられたシーケンス番号。シーケンス番号は、古いバージョンのドキュメントが新しいバージョンを上書きしないようにするために使用されます。楽観的同時実行制御を参照してください。
  • _primary_term
  • インデックス操作のためにドキュメントに割り当てられたプライマリターム。楽観的同時実行制御を参照してください。
  • result
  • インデックス操作の結果、createdまたはupdated。

Description

新しいJSONドキュメントを_docまたは_createリソースを使用してインデックスできます。_createを使用すると、ドキュメントがすでに存在しない場合にのみインデックスされることが保証されます。既存のドキュメントを更新するには、_docリソースを使用する必要があります。

Automatically create data streams and indices

リクエストのターゲットが存在せず、data_stream定義を持つインデックステンプレートに一致する場合、インデックス操作はデータストリームを自動的に作成します。データストリームの設定を参照してください。

ターゲットが存在せず、データストリームテンプレートに一致しない場合、操作は自動的にインデックスを作成し、一致するインデックステンプレートを適用します。

Elasticsearchには、いくつかの組み込みインデックステンプレートが含まれています。これらのテンプレートとの名前の衝突を避けるために、インデックスパターンの衝突を避けるを参照してください。

マッピングが存在しない場合、インデックス操作は動的マッピングを作成します。デフォルトでは、新しいフィールドとオブジェクトは必要に応じて自動的にマッピングに追加されます。フィールドマッピングに関する詳細については、mappingおよびupdate mapping APIを参照してください。

自動インデックス作成は、action.auto_create_index設定によって制御されます。この設定のデフォルトはtrueであり、任意のインデックスが自動的に作成されることを許可します。この設定を変更して、指定されたパターンに一致するインデックスの自動作成を明示的に許可またはブロックするか、falseに設定して自動インデックス作成を完全に無効にすることができます。許可したいパターンのカンマ区切りリストを指定するか、+または-で各パターンの先頭にプレフィックスを付けて、許可またはブロックするかを示します。リストが指定されると、デフォルトの動作は拒否されます。 

  3. #### Python
  5. ``````python
  6. resp = client.cluster.put_settings(
  7.    persistent={
  8.    "action.auto_create_index": "my-index-000001,index10,-index1*,+ind*"
  9.    },
  10. )
  11. print(resp)
  13. resp1 = client.cluster.put_settings(
  14.    persistent={
  15.    "action.auto_create_index": "false"
  16.    },
  17. )
  18. print(resp1)
  20. resp2 = client.cluster.put_settings(
  21.    persistent={
  22.    "action.auto_create_index": "true"
  23.    },
  24. )
  25. print(resp2)
  26. `

Ruby

  1. response = client.cluster.put_settings(
  2.   body: {
  3.    persistent: {
  4.    'action.auto_create_index' => 'my-index-000001,index10,-index1*,+ind*'
  5.    }
  6.   }
  7. )
  8. puts response
  10. response = client.cluster.put_settings(
  11.   body: {
  12.    persistent: {
  13.    'action.auto_create_index' => 'false'
  14.    }
  15.   }
  16. )
  17. puts response
  19. response = client.cluster.put_settings(
  20.   body: {
  21.    persistent: {
  22.    'action.auto_create_index' => 'true'
  23.    }
  24.   }
  25. )
  26. puts response

Js

  1. const response = await client.cluster.putSettings({
  2.   persistent: {
  3.    "action.auto_create_index": "my-index-000001,index10,-index1*,+ind*",
  4.   },
  5. });
  6. console.log(response);
  8. const response1 = await client.cluster.putSettings({
  9.   persistent: {
  10.    "action.auto_create_index": "false",
  11.   },
  12. });
  13. console.log(response1);
  15. const response2 = await client.cluster.putSettings({
  16.   persistent: {
  17.    "action.auto_create_index": "true",
  18.   },
  19. });
  20. console.log(response2);

Console

  1. PUT _cluster/settings
  2. {
  3.   "persistent": {
  4.    "action.auto_create_index": "my-index-000001,index10,-index1*,+ind*"
  5.   }
  6. }
  8. PUT _cluster/settings
  9. {
  10.   "persistent": {
  11.    "action.auto_create_index": "false"
  12.   }
  13. }
  15. PUT _cluster/settings
  16. {
  17.   "persistent": {
  18.    "action.auto_create_index": "true"
  19.   }
  20. }
my-index-000001またはindex10と呼ばれるインデックスの自動作成を許可し、index1*パターンに一致するインデックスの作成をブロックし、ind*パターンに一致する他のインデックスの作成を許可します。パターンは指定された順序で一致します。
自動インデックス作成を完全に無効にします。
任意のインデックスの自動作成を許可します。これがデフォルトです。

Put if absent

リクエスト形式_createを使用するか、op_typeパラメータをcreateに設定することで、作成操作を強制できます。この場合、指定されたIDのドキュメントがインデックスにすでに存在する場合、インデックス操作は失敗します。

Create document IDs automatically

リクエスト形式POST /<target>/_doc/を使用する場合、op_typeは自動的にcreateに設定され、インデックス操作はドキュメントの一意のIDを生成します。

Python

  1. resp = client.index(
  2.    index="my-index-000001",
  3.    document={
  4.    "@timestamp": "2099-11-15T13:12:00",
  5.    "message": "GET /search HTTP/1.1 200 1070000",
  6.    "user": {
  7.    "id": "kimchy"
  8.    }
  9.    },
  10. )
  11. print(resp)

Ruby

  1. response = client.index(
  2.   index: 'my-index-000001',
  3.   body: {
  4.    "@timestamp": '2099-11-15T13:12:00',
  5.    message: 'GET /search HTTP/1.1 200 1070000',
  6.    user: {
  7.    id: 'kimchy'
  8.    }
  9.   }
  10. )
  11. puts response

Js

  1. const response = await client.index({
  2.   index: "my-index-000001",
  3.   document: {
  4.    "@timestamp": "2099-11-15T13:12:00",
  5.    message: "GET /search HTTP/1.1 200 1070000",
  6.    user: {
  7.    id: "kimchy",
  8.    },
  9.   },
  10. });
  11. console.log(response);

Console

  1. POST my-index-000001/_doc/
  2. {
  3.   "@timestamp": "2099-11-15T13:12:00",
  4.   "message": "GET /search HTTP/1.1 200 1070000",
  5.   "user": {
  6.    "id": "kimchy"
  7.   }
  8. }

APIは次の結果を返します：

Console-Result

  1. {
  2.   "_shards": {
  3.    "total": 2,
  4.    "failed": 0,
  5.    "successful": 2
  6.   },
  7.   "_index": "my-index-000001",
  8.   "_id": "W0tpsmIBdwcYyG50zbta",
  9.   "_version": 1,
  10.   "_seq_no": 0,
  11.   "_primary_term": 1,
  12.   "result": "created"
  13. }

Optimistic concurrency control

インデックス操作は条件付きにすることができ、if_seq_noおよびif_primary_termパラメータによって指定されたシーケンス番号とプライマリタームが割り当てられた場合にのみ実行されます。不一致が検出された場合、操作はVersionConflictExceptionとなり、ステータスコードは409になります。楽観的同時実行制御の詳細を参照してください。

Routing

デフォルトでは、シャードの配置—またはrouting—は、ドキュメントのID値のハッシュを使用して制御されます。より明示的な制御のために、ルーターによって使用されるハッシュ関数に供給される値を、routingパラメータを使用して操作ごとに直接指定できます。例えば：

Python

  1. resp = client.index(
  2.    index="my-index-000001",
  3.    routing="kimchy",
  4.    document={
  5.    "@timestamp": "2099-11-15T13:12:00",
  6.    "message": "GET /search HTTP/1.1 200 1070000",
  7.    "user": {
  8.    "id": "kimchy"
  9.    }
  10.    },
  11. )
  12. print(resp)

Ruby

  1. response = client.index(
  2.   index: 'my-index-000001',
  3.   routing: 'kimchy',
  4.   body: {
  5.    "@timestamp": '2099-11-15T13:12:00',
  6.    message: 'GET /search HTTP/1.1 200 1070000',
  7.    user: {
  8.    id: 'kimchy'
  9.    }
  10.   }
  11. )
  12. puts response

Js

  1. const response = await client.index({
  2.   index: "my-index-000001",
  3.   routing: "kimchy",
  4.   document: {
  5.    "@timestamp": "2099-11-15T13:12:00",
  6.    message: "GET /search HTTP/1.1 200 1070000",
  7.    user: {
  8.    id: "kimchy",
  9.    },
  10.   },
  11. });
  12. console.log(response);

Console

  1. POST my-index-000001/_doc?routing=kimchy
  2. {
  3.   "@timestamp": "2099-11-15T13:12:00",
  4.   "message": "GET /search HTTP/1.1 200 1070000",
  5.   "user": {
  6.    "id": "kimchy"
  7.   }
  8. }

この例では、ドキュメントは提供されたroutingパラメータに基づいてシャードにルーティングされます：”kimchy”。

明示的なマッピングを設定する際、_routingフィールドを使用してインデックス操作がドキュメント自体からルーティング値を抽出するように指示することもできます。これは（非常に最小限の）追加のドキュメント解析パスのコストがかかります。_routingマッピングが定義され、requiredに設定されている場合、ルーティング値が提供されないか抽出されないと、インデックス操作は失敗します。

データストリームは、テンプレートでallow_custom_routing設定が有効になっている場合を除き、カスタムルーティングをサポートしていません。

Distributed

インデックス操作は、そのルートに基づいてプライマリシャードに指示され（上記のルーティングセクションを参照）、このシャードを含む実際のノードで実行されます。プライマリシャードが操作を完了した後、必要に応じて、更新は適用可能なレプリカに配布されます。

Active shards

システムへの書き込みの耐障害性を向上させるために、インデックス操作は操作を進める前に特定の数のアクティブシャードコピーを待機するように構成できます。必要な数のアクティブシャードコピーが利用できない場合、書き込み操作は待機して再試行する必要があります。必要なシャードコピーが開始されるか、タイムアウトが発生するまで待機します。デフォルトでは、書き込み操作は進行する前にプライマリシャードがアクティブであることを待機します（すなわち、wait_for_active_shards=1）。このデフォルトは、index.write.wait_for_active_shardsを設定することでインデックス設定で動的にオーバーライドできます。この動作を操作ごとに変更するには、wait_for_active_shardsリクエストパラメータを使用できます。

有効な値はallまたはインデックス内の各シャードの構成されたコピーの合計数までの任意の正の整数（number_of_replicas+1）です。負の値またはシャードコピーの数を超える数を指定すると、エラーが発生します。

例えば、3つのノードA、B、Cのクラスターがあり、レプリカの数が3に設定されたインデックスindexを作成したとします（これにより、シャードコピーが4つになります。ノードの数より1つ多いコピー）。インデックス操作を試みると、デフォルトでは、操作は進行する前に各シャードのプライマリコピーが利用可能であることを確認します。これは、BとCがダウンしていても、Aがプライマリシャードコピーをホストしている場合、インデックス操作はデータの1つのコピーのみで進行することを意味します。リクエストでwait_for_active_shardsが3に設定されている場合（すべての3ノードが稼働している場合）、インデックス操作は進行する前に3つのアクティブシャードコピーを必要とします。この要件は、クラスター内に3つのアクティブノードがあり、それぞれがシャードのコピーを保持しているため、満たされるべきです。しかし、wait_for_active_shardsをall（または4に設定すると、インデックス操作は進行しません。インデックス内の各シャードの4つのコピーがすべてアクティブでないためです。新しいノードがクラスターに追加されて4つ目のシャードコピーをホストするまで、操作はタイムアウトします。

この設定は、書き込み操作が必要な数のシャードコピーに書き込まれない可能性を大幅に減少させますが、完全に排除することはできません。なぜなら、このチェックは書き込み操作が開始される前に行われるからです。書き込み操作が進行中である場合、レプリケーションが任意の数のシャードコピーで失敗する可能性は依然としてありますが、プライマリでは成功する可能性があります。書き込み操作の応答の_shardsセクションは、レプリケーションが成功した/失敗したシャードコピーの数を示します。

Js

  1. {
  2.   "_shards": {
  3.    "total": 2,
  4.    "failed": 0,
  5.    "successful": 2
  6.   }
  7. }

Refresh

このリクエストによって行われた変更が検索に表示されるタイミングを制御します。refreshを参照してください。

Noop updates

インデックスAPIを使用してドキュメントを更新する際、ドキュメントが変更されていなくても常に新しいバージョンが作成されます。これが許容できない場合は、_update APIを使用し、detect_noopをtrueに設定してください。このオプションは、インデックスAPIが古いソースを取得せず、新しいソースと比較できないため、インデックスAPIでは利用できません。

ノープ更新が許容されない場合の厳密なルールはありません。これは、データソースが実際にノープである更新を送信する頻度や、Elasticsearchが更新を受信するシャードで実行するクエリの数など、多くの要因の組み合わせです。

Timeout

インデックス操作を実行するために割り当てられたプライマリシャードが利用できない場合があります。これには、プライマリシャードが現在ゲートウェイから回復中であるか、移動中であるなどの理由が考えられます。デフォルトでは、インデックス操作は失敗する前にプライマリシャードが利用可能になるまで最大1分間待機します。timeoutパラメータを使用して、待機時間を明示的に指定できます。以下は、5分に設定する例です：

Python

  1. resp = client.index(
  2.    index="my-index-000001",
  3.    id="1",
  4.    timeout="5m",
  5.    document={
  6.    "@timestamp": "2099-11-15T13:12:00",
  7.    "message": "GET /search HTTP/1.1 200 1070000",
  8.    "user": {
  9.    "id": "kimchy"
  10.    }
  11.    },
  12. )
  13. print(resp)

Ruby

  1. response = client.index(
  2.   index: 'my-index-000001',
  3.   id: 1,
  4.   timeout: '5m',
  5.   body: {
  6.    "@timestamp": '2099-11-15T13:12:00',
  7.    message: 'GET /search HTTP/1.1 200 1070000',
  8.    user: {
  9.    id: 'kimchy'
  10.    }
  11.   }
  12. )
  13. puts response

Js

  1. const response = await client.index({
  2.   index: "my-index-000001",
  3.   id: 1,
  4.   timeout: "5m",
  5.   document: {
  6.    "@timestamp": "2099-11-15T13:12:00",
  7.    message: "GET /search HTTP/1.1 200 1070000",
  8.    user: {
  9.    id: "kimchy",
  10.    },
  11.   },
  12. });
  13. console.log(response);

Console

  1. PUT my-index-000001/_doc/1?timeout=5m
  2. {
  3.   "@timestamp": "2099-11-15T13:12:00",
  4.   "message": "GET /search HTTP/1.1 200 1070000",
  5.   "user": {
  6.    "id": "kimchy"
  7.   }
  8. }

Versioning

インデックスされた各ドキュメントにはバージョン番号が付与されます。デフォルトでは、内部バージョン管理が使用され、1から始まり、各更新（削除を含む）でインクリメントされます。オプションとして、バージョン番号を外部値（例えば、データベースで管理されている場合）に設定できます。この機能を有効にするには、version_typeをexternalに設定する必要があります。提供される値は、0以上で約9.2e+18未満の数値の長い値でなければなりません。

外部バージョンタイプを使用する場合、システムはインデックスリクエストに渡されたバージョン番号が現在保存されているドキュメントのバージョンよりも大きいかどうかを確認します。もしそうであれば、ドキュメントはインデックスされ、新しいバージョン番号が使用されます。提供された値が保存されているドキュメントのバージョン番号以下である場合、バージョンの競合が発生し、インデックス操作は失敗します。例えば：

Python

  1. resp = client.index(
  2.    index="my-index-000001",
  3.    id="1",
  4.    version="2",
  5.    version_type="external",
  6.    document={
  7.    "user": {
  8.    "id": "elkbee"
  9.    }
  10.    },
  11. )
  12. print(resp)

Ruby

  1. response = client.index(
  2.   index: 'my-index-000001',
  3.   id: 1,
  4.   version: 2,
  5.   version_type: 'external',
  6.   body: {
  7.    user: {
  8.    id: 'elkbee'
  9.    }
  10.   }
  11. )
  12. puts response

Js

  1. const response = await client.index({
  2.   index: "my-index-000001",
  3.   id: 1,
  4.   version: 2,
  5.   version_type: "external",
  6.   document: {
  7.    user: {
  8.    id: "elkbee",
  9.    },
  10.   },
  11. });
  12. console.log(response);

Console

  1. PUT my-index-000001/_doc/1?version=2&version_type=external
  2. {
  3.   "user": {
  4.    "id": "elkbee"
  5.   }
  6. }

バージョン管理は完全にリアルタイムであり、検索操作のほぼリアルタイムの側面には影響されません。バージョンが提供されていない場合、操作はバージョンチェックなしで実行されます。

前の例では、提供されたバージョン2が現在のドキュメントバージョン1よりも高いため、操作は成功します。ドキュメントがすでに更新され、そのバージョンが2以上に設定されている場合、インデックスコマンドは失敗し、競合（409 HTTPステータスコード）を引き起こします。

良い副作用は、ソースデータベースの変更の結果として実行される非同期インデックス操作の厳密な順序を維持する必要がないことです。ソースデータベースからのバージョン番号が使用されている限り、たとえインデックス操作が何らかの理由で順不同で到着しても、単純なケースであっても、Elasticsearchインデックスをデータベースのデータを使用して更新することが簡素化されます。

Version types

Elasticsearchは、externalバージョンタイプに加えて、特定のユースケースのために他のタイプもサポートしています：

  • externalまたはexternal_gt
  • 保存されたドキュメントのバージョンよりも厳密に高い場合にのみドキュメントをインデックスしますまたは既存のドキュメントがない場合。指定されたバージョンは新しいバージョンとして使用され、新しいドキュメントと共に保存されます。提供されたバージョンは、非負の長い数値でなければなりません。
  • external_gte
  • 保存されたドキュメントのバージョンと等しいかそれ以上の場合にのみドキュメントをインデックスします。既存のドキュメントがない場合、操作も成功します。指定されたバージョンは新しいバージョンとして使用され、新しいドキュメントと共に保存されます。提供されたバージョンは、非負の長い数値でなければなりません。 
  3. ## Examples
  5. `````my-index-000001`````インデックスに`````_id`````が1のJSONドキュメントを挿入します：
  8. #### Python
  10. ``````python
  11. resp = client.index(
  12.    index="my-index-000001",
  13.    id="1",
  14.    document={
  15.    "@timestamp": "2099-11-15T13:12:00",
  16.    "message": "GET /search HTTP/1.1 200 1070000",
  17.    "user": {
  18.    "id": "kimchy"
  19.    }
  20.    },
  21. )
  22. print(resp)
  23. `

Ruby

  1. response = client.index(
  2.   index: 'my-index-000001',
  3.   id: 1,
  4.   body: {
  5.    "@timestamp": '2099-11-15T13:12:00',
  6.    message: 'GET /search HTTP/1.1 200 1070000',
  7.    user: {
  8.    id: 'kimchy'
  9.    }
  10.   }
  11. )
  12. puts response

Js

  1. const response = await client.index({
  2.   index: "my-index-000001",
  3.   id: 1,
  4.   document: {
  5.    "@timestamp": "2099-11-15T13:12:00",
  6.    message: "GET /search HTTP/1.1 200 1070000",
  7.    user: {
  8.    id: "kimchy",
  9.    },
  10.   },
  11. });
  12. console.log(response);

Console

  1. PUT my-index-000001/_doc/1
  2. {
  3.   "@timestamp": "2099-11-15T13:12:00",
  4.   "message": "GET /search HTTP/1.1 200 1070000",
  5.   "user": {
  6.    "id": "kimchy"
  7.   }
  8. }

APIは次の結果を返します：

Console-Result

  1. {
  2.   "_shards": {
  3.    "total": 2,
  4.    "failed": 0,
  5.    "successful": 2
  6.   },
  7.   "_index": "my-index-000001",
  8.   "_id": "1",
  9.   "_version": 1,
  10.   "_seq_no": 0,
  11.   "_primary_term": 1,
  12.   "result": "created"
  13. }

IDが存在しない場合、_createリソースを使用してmy-index-000001インデックスにドキュメントをインデックスします：

Python

  1. resp = client.create(
  2.    index="my-index-000001",
  3.    id="1",
  4.    document={
  5.    "@timestamp": "2099-11-15T13:12:00",
  6.    "message": "GET /search HTTP/1.1 200 1070000",
  7.    "user": {
  8.    "id": "kimchy"
  9.    }
  10.    },
  11. )
  12. print(resp)

Ruby

  1. response = client.create(
  2.   index: 'my-index-000001',
  3.   id: 1,
  4.   body: {
  5.    "@timestamp": '2099-11-15T13:12:00',
  6.    message: 'GET /search HTTP/1.1 200 1070000',
  7.    user: {
  8.    id: 'kimchy'
  9.    }
  10.   }
  11. )
  12. puts response

Js

  1. const response = await client.create({
  2.   index: "my-index-000001",
  3.   id: 1,
  4.   document: {
  5.    "@timestamp": "2099-11-15T13:12:00",
  6.    message: "GET /search HTTP/1.1 200 1070000",
  7.    user: {
  8.    id: "kimchy",
  9.    },
  10.   },
  11. });
  12. console.log(response);

Console

  1. PUT my-index-000001/_create/1
  2. {
  3.   "@timestamp": "2099-11-15T13:12:00",
  4.   "message": "GET /search HTTP/1.1 200 1070000",
  5.   "user": {
  6.    "id": "kimchy"
  7.   }
  8. }

IDが存在しない場合、ドキュメントをmy-index-000001インデックスにインデックスするためにop_typeパラメータをcreateに設定します：

Python

  1. resp = client.index(
  2.    index="my-index-000001",
  3.    id="1",
  4.    op_type="create",
  5.    document={
  6.    "@timestamp": "2099-11-15T13:12:00",
  7.    "message": "GET /search HTTP/1.1 200 1070000",
  8.    "user": {
  9.    "id": "kimchy"
  10.    }
  11.    },
  12. )
  13. print(resp)

Ruby

  1. response = client.index(
  2.   index: 'my-index-000001',
  3.   id: 1,
  4.   op_type: 'create',
  5.   body: {
  6.    "@timestamp": '2099-11-15T13:12:00',
  7.    message: 'GET /search HTTP/1.1 200 1070000',
  8.    user: {
  9.    id: 'kimchy'
  10.    }
  11.   }
  12. )
  13. puts response

Js

  1. const response = await client.index({
  2.   index: "my-index-000001",
  3.   id: 1,
  4.   op_type: "create",
  5.   document: {
  6.    "@timestamp": "2099-11-15T13:12:00",
  7.    message: "GET /search HTTP/1.1 200 1070000",
  8.    user: {
  9.    id: "kimchy",
  10.    },
  11.   },
  12. });
  13. console.log(response);

Console

  1. PUT my-index-000001/_doc/1?op_type=create
  2. {
  3.   "@timestamp": "2099-11-15T13:12:00",
  4.   "message": "GET /search HTTP/1.1 200 1070000",
  5.   "user": {
  6.    "id": "kimchy"
  7.   }
  8. }