あきらめるエントリからElasticsearch：CRUD文書は心に留めておくために

Elasticsearchにおいて、文書（ドキュメント）は、すべての検索可能なデータの最小単位です。これはElasticsearchにJSONに順に格納されます。各文書は、あなたがあなた自身を指定することができ、または自動的に生成ElasticsearchするユニークなIDを持っています。

私たちの前の比較の継続が不適切RDMS場合、私は、文書は、リレーショナルデータベースのテーブルにたとえることができると思います。

メタデータ

我々は先に述べたように、各文書は、文書を取得し、識別するための一意のIDを持っている、「_ ID」のレコードのフィールドは、文書のユニークIDである、それはメタデータの一つです。もちろん、他の文書のメタデータがある、のは、一つ一つを紹介しましょう

_index：ドキュメントのインデックス名が所属します
_type：タイプの文書が属します
_id：ユニークなID文書

これら3では、我々は文書を一意に識別することができ、もちろん、我々は7.0を必要とするか、後でアップ_TYPEません。我々は、他のメタデータのいくつかを見て次に

_source：生データJSON文書
_field_names：値がnullで、フィールド名ではありませんで、このフィールドは、インデックス文書に使用され、指定したフィールドの要求のために主に存在するが空であります
_ignore：このフィールドは、異常に起因する各の名前（ignore_malformed開け）、無視フィールドにインデックスと店の文書に使用されています
_meta：このフィールドには、いくつかのカスタムメタデータ情報を格納するために使用されます
_routing：データスライスが属する上で指定するために使用される、デフォルト値は、IDです
_version：バージョン情報文書
_score：関連性得点

文書を作成します。

文書を作成し、以下の4つの方法があります。

PUT / <インデックス> / _ DOC / <_ ID>
POST / <インデックス> / _ DOC /
PUT / <インデックス> / _ /作成<_ ID>
POST / <インデックス> / _ /作成<_ ID>

これらの4つの方法の違いは、IDを指定しない場合、それは自動的にElasticsearch IDを生成することです。あなたが_CREATEメソッドを使用する場合は、文書が存在しないことを確認する必要があり、利用_DOC方法は、その後、いずれかの新しい文書を作成し、あなたはまた、既存のドキュメントを更新することができます。

あなたが文書を作成するとき、あなたはまた、いくつかのパラメータを選択することができます。

リクエストパラメータ

if_seq_no：文書のシリアル番号のみが更新の値を指定する場合
if_primary_term：ドキュメントがある場合は、プライマリ用語は更新の値を指定します
op_type：ドキュメントを作成するように設定を指定する必要がある場合はidが存在しない、または操作は失敗します。デフォルトのインデックスで有効な値のインデックスまたは作成し、
op_type：指定前処理されたパイプID
[更新：trueに設定した場合は、リフレッシュすぐに断片化の影響を受けて。リフレッシュスライスした後、検索操作が見える魚までwait_for場合は、お待ちしております。それがfalseの場合、それはスライスをリフレッシュしません。デフォルト値はfalseです
ルーティング：指定された経路をプライマリスライスに
タイムアウト：応答時間指定、デフォルトは30秒です
master_timeout：接続の長さに応じて、マスタノードは、デフォルトは30秒です
バージョン：明示的にバージョン番号を指定します
versionjype：指定タイプのバージョン番号：内部、外部、external_gte、力
wait_for_active_shards：操作を処理する前に、フラグメントの数がアクティブのコピーを保持しなければならない、すべて、または任意の正の整数に提供することができます。デフォルトは1、すなわち、本体のみに活性なフラグメントです。

Responseパケットボディ

情報の断片を提供する：** _破片
** _ shards.total **：文書を作成するために、作品の総数
成功したドキュメントフラグメントを作成数：** _ ** shards.successful
** _ shards.failed **：文書の断片の数の作成に失敗しました
** _インデックス**：文書がインデックスに属しています
** _タイプ**：ドキュメントタイプに属し、現在は_DOCをサポートしています
** _ ** ID：IDドキュメント
** _バージョン**：ドキュメントのバージョン番号
** _ SEQ_NO **：文書のシリアル番号
** _ primary_term **：文書の主な用語
結果：インデックスの結果は、作成または更新します

私たちは、文書を作成するときに指定したインデックスが存在しない場合は、ESは、自動的に私たちのためにインデックスを作成します。この操作では、デフォルトはtrueですaction.auto_create_indexフィールドを設定することによって制御することができます。あなたは自動的にインデックスの一部またはすべてが自動的に目的が作成されていません作成することができ、指定したインデックスを達成するために、このフィールドを変更することができます。

アップデートドキュメント

文書を作成する方法を知って、私たちは既存のドキュメントを更新する方法を見てみましょう。実際には、あなたは私たちがPUT / <インデックス>は/ _ DOC / <id>を使用して、前述した文書を作成するときの方法は、既存のドキュメントを更新することができます。また、ドキュメントを更新するための別の方法もあります：

POST / <インデックス> / _更新/ <_ ID>

両方の更新は異なっています。_DOC方法は、元の文書を削除し、新しいものを作成することです。_update方法は、増分更新、それはドキュメントを取得し、指定されたスクリプトを実行し、最終的に再インデックス化することで、更新処理です。

もう1つの違いは_update方法は、更新するためのスクリプトの使用をサポートし、デフォルトの言語は無痛で、あなたはパラメータLANGが設定してもよいということです。リクエストパラメータの面では、_updateは、より多くの次のパラメータの_DOCと比較します：

langは：スクリプト言語を指定します。
retry_on_conflict：競合が発生した再試行回数、デフォルトは0
** _ **ソース：falseに設定し、任意の検索フィールドを返しません
** _ source_excludes **：指定した検索結果は、ソースフィールドから除外する
** _ source_includes **：指定フィールドには、ソースを取得するために戻ります

ここではドキュメントを更新してきた自分の足の一例です

curl -X POST "localhost:9200/test/_update/1?pretty" -H 'Content-Type: application/json' -d'
{
    "script" : {
        "source": "ctx._source.counter += params.count",
        "lang": "painless",
        "params" : {
            "count" : 4
        }
    }
}
'

UPS

curl -X POST "localhost:9200/test/_update/1?pretty" -H 'Content-Type: application/json' -d'
{
    "script" : {
        "source": "ctx._source.counter += params.count",
        "lang": "painless",
        "params" : {
            "count" : 4
        }
    },
    "upsert" : {
        "counter" : 1
    }
}
'

指定された文書が存在しない場合は、新しいドキュメントを作成し、パラメータをアップサート使用することができ、かつ特定の文書がある場合、要求はスクリプト内のスクリプトを実行します。スクリプトを使用したいが、追加/文書を更新したくない場合は、doc_as_upsert使用することができます。

curl -X POST "localhost:9200/test/_update/1?pretty" -H 'Content-Type: application/json' -d'
{
    "doc" : {
        "name" : "new_name"
    },
    "doc_as_upsert" : true
}
'

クエリによる更新

このAPIは、文書、検索、バッチ更新のために使用されている、あなたは、特定の例で理解することができます。

curl -X POST "localhost:9200/twitter/_update_by_query?pretty" -H 'Content-Type: application/json' -d'
{
  "script": {
    "source": "ctx._source.likes++",
    "lang": "painless"
  },
  "query": {
    "term": {
      "user": "kimchy"
    }
  }
}
'

マニュアルの入手方法

ESがGET APIを使用して文書を取得し、要求された形式は次のとおりです。

GET / <インデックス> / _ DOC / <_ ID>

それはあなたがメタデータを必要とせずに、文書の内容だけをしたい場合は、あなたが使用することができ、文書データや、いくつかのメタデータを返します。

GET / <インデックス> / _ソース/ <_ ID>

リクエストパラメータ

ここではそれらを繰り返さないで、パラメータの前に言及されているドキュメントのいくつかの要求がありますが、彼らは以下のとおりです。

リフレッシュ
ルーティング
**_ソース**
** _ ** source_excludes
** _ ** source_includes
バージョン
version_type

まだ他の人が前にパラメータを言及していないが、特定の者を見てみよう

嗜好によって指定されたノードまたは断片の実行要求のために、_localのセットは、優先的に局所的断片を実行する場合。
リアルタイム：trueに設定すると、要求はなく、リアルタイム、ほぼリアルタイムです。デフォルトはtrueです
stored_fields：指定されたフィールドを返し、店舗フィールドが真であります

MGET

MGETは、2つの方法で要求された形式の大部分を取得するための一つの方法です。

GET / _mget
GET / <インデックス> / _ MGET

最初のインデックスは、リクエストボディに書かれています。第二は、URLへのインデックスであるが、この方法では、ESのセキュリティチェックをトリガすることができます。

MGETリクエストパラメータと同じを得るが、リクエストボディのdocに関連する検索条件を指定する必要

要求

GET /_mget
{
    "docs" : [
        {
            "_index" : "jackey",
            "_id" : "1"
        },
        {
            "_index" : "jackey",
            "_id" : "2"
        }
    ]
}

応答

{
  "docs" : [
    {
      "_index" : "jackey",
      "_type" : "_doc",
      "_id" : "1",
      "_version" : 5,
      "_seq_no" : 6,
      "_primary_term" : 1,
      "found" : true,
      "_source" : {
        "user" : "ja",
        "tool" : "ES",
        "message" : "qwer"
      }
    },
    {
      "_index" : "jackey",
      "_type" : "_doc",
      "_id" : "2",
      "_version" : 1,
      "_seq_no" : 2,
      "_primary_term" : 1,
      "found" : true,
      "_source" : {
        "user" : "zhe",
        "post_date" : "2019-11-15T14:12:12",
        "message" : "learning Elasticsearch"
      }
    }
  ]
}

削除ドキュメント

最後のA D CURD操作は、ここでは、文書を削除するには、どのようにESを見てみましょう。

削除要求は、IDを使用して指定されています

DELETE / <インデックス> / _ DOC / <_ ID>

削除された文書を決定するために取り外したときに、我々は通常のバージョンを指定するよりも、大規模な同時の場合、私たちは本当に削除したい文書です。我々はまた、導入する前に要求されたパラメータを削除し、私は特定の生徒について知りたい直接見ることができます公式ドキュメントを。

クエリによって削除

削除、更新と同様に、クエリAPIにより削除を持っています。

POST / <インデックス> / _ delete_by_query

また、クエリに一致する条件に応じて、第1の文書で、その後、これらの文書を削除します。クエリを実行する前に、Elasticsearchは、最初の削除プロセス場合、削除は失敗し帰国、運用紛争になり、インデックスが発生した変更し、指定されたインデックスのスナップショットを作成します。

あなたはより多くの文書を削除した場合、あなたもこの要求非同期実行を行うことができます、あなただけのセットWAIT_FOR_COMPLETION = falseにする必要があります。

リフレッシュパラメータリフレッシュとAPIのAPIを削除が異なる、削除リフレッシュパラメータはスライスのみの更新、およびこのAPIのリフレッシュパラメータであり、すぐに目に見える操作は、影響を受けるすべての部分をリフレッシュする必要があるかどうかを設定されています。

バルクAPI

最後に、私たちは特別なAPI、APIのバッチ操作をご紹介しましょう。これは、書き込みの2種類をサポートし、インデックス名がURLに書き込むことができ、あなたはまた、リクエストボディに書き込むことができます。

POST / _bulk
POST / <インデックス> / _バルク

この要求では、あなたは前にCRUD要求を任意に組み合わせて使用することができます。

curl -X POST "localhost:9200/_bulk?pretty" -H 'Content-Type: application/json' -d'
{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "test", "_id" : "2" } }
{ "create" : { "_index" : "test", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : {"_id" : "1", "_index" : "test"} }
{ "doc" : {"field2" : "value2"} }
'

リクエストボディに使用される構文は改行JSON（NDJSON）で区切られています。具体的にどのようにそれを使用するには？要求自体は、次に、改行文字は、次のサブコンテンツ別個要求で表されるパッケージ本体である場合、実際には、上記の例では、我々は、そのような要求のインデックスに対して、実証又は作成された、最初は包含され。

上記の例では、例えばインデックス要請、その包含は{「フィールド1」：「値1」}であり、それは次の行インデックス要求に表示されるように、。

バッチ実行動作の場合、単一の操作は失敗し、他の操作には影響しませんが、各操作の最終結果も返されます。

上記の例を実行した後、我々の結果はする必要があります

{
   "took": 30,
   "errors": false,
   "items": [
      {
         "index": {
            "_index": "test",
            "_type": "_doc",
            "_id": "1",
            "_version": 1,
            "result": "created",
            "_shards": {
               "total": 2,
               "successful": 1,
               "failed": 0
            },
            "status": 201,
            "_seq_no" : 0,
            "_primary_term": 1
         }
      },
      {
         "delete": {
            "_index": "test",
            "_type": "_doc",
            "_id": "2",
            "_version": 1,
            "result": "not_found",
            "_shards": {
               "total": 2,
               "successful": 1,
               "failed": 0
            },
            "status": 404,
            "_seq_no" : 1,
            "_primary_term" : 2
         }
      },
      {
         "create": {
            "_index": "test",
            "_type": "_doc",
            "_id": "3",
            "_version": 1,
            "result": "created",
            "_shards": {
               "total": 2,
               "successful": 1,
               "failed": 0
            },
            "status": 201,
            "_seq_no" : 2,
            "_primary_term" : 3
         }
      },
      {
         "update": {
            "_index": "test",
            "_type": "_doc",
            "_id": "1",
            "_version": 2,
            "result": "updated",
            "_shards": {
                "total": 2,
                "successful": 1,
                "failed": 0
            },
            "status": 200,
            "_seq_no" : 3,
            "_primary_term" : 4
         }
      }
   ]
}

バルク・オペレーションの実行が繰り返し単一の操作の点で比較して、性能の何らかの改善があるだろう。我々は非常に慎重に使用された場合でも、そう、いくつかのリスクが存在します。

概要

本論文では、メタデータと文書の文書の基本的な概念を紹介します。それから彼は、CRUD操作とバルクAPIドキュメントを導入しました。私はElasticsearch文書にあなたの記事を読んだ後、一定の理解を持っていると信じています。それは最終的にあなたがして、これらの実践的な操作を試してみてください正確にどのような役割を要求する様々なパラメータを見て、あなたのElasticsearchを開始します。私は個人的にあなたがより深い印象を持っていますAPI後に再度実験したと信じています。