オペレーション003ドキュメント

A.文書を追加します。

上記のセクションでは、ユーザーのインデックスを削除しました。

今、私たちは、次のコマンドを実行します。

PUT /ユーザ/ _DOC / 1 
{ 
  "ユーザ名"： "トレック"、
  "年齢"：27 
}

　以下の結果が得られました。　

{ 
  "_index"： "ユーザ"、
  "_type"： "_DOC"、
  "_id"： "1"、
  "_version"：1、
  "結果"： "作成"、
  "_shards"：{ 
    "合計"：2、
    "成功"：1、
    "失敗"：0 
  }、
  "_seq_no"：0、
  "_primary_term"：1 
}

　　私たちは、結果の中から取得することができ、我々が正常に文書を追加しました。

私たちは、インデックスを照会し続けます。

GET /ユーザー

　　あなたは、次のような結果を得ることができます。

{ 
  "ユーザ"：{ 
    "エイリアス"：{}、
    "マッピング"：{ 
      "プロパティ"：{ 
        "年齢"：{ 
          "タイプ"： "長い" 
        }、
        "ユーザ名" { 
          "タイプ"： "テキスト"、
          "フィールド"：{ 
            "キーワード"：{ 
              "タイプ"：、 "キーワード" 
              、 "ignore_aboveを"：256 
            } 
          } 
        } 
      } 
    }、
    "設定"：{ 
      "インデックス"：{ 
        "CREATION_DATE"： "1569423964719" 
        、 "number_of_shards"： "1"、
        "number_of_replicas"： "1"、 
        "UUID"： "_7BZkTRISAm7zzCo5B17ow"、
        "バージョン"：{
          "作成"： "7030299" 
        }、
        "provided_name"： "ユーザ" 
      } 
    } 
  } 
}

　　私たちは、レコードを追加するときにことがわかったが、また、インデックスを作成しました。

これは、常に何も具体的な要件である、特徴的なのNoSQLデータベースです。

二つ。同上ドキュメント

上記では、ドキュメントを追加し、文書IDが1である開発します。

我々は指定しない場合、ESは自動的にドキュメントIDを生成するために、私たちを助けます。

次のように：

POST /ユーザ/ _DOC 
{ 
  "ユーザ名"： "トム"、
  "年齢"：33 
}

　　次のように得られた結果は以下の通りでした。

{ 
  "_index"： "ユーザ"、
  "_type"： "_DOC"、
  "_id"： "6pr4aG0BsjQtAa68ty9w"、
  "_version"：1、
  "結果"： "作成"、
  "_shards"：{ 
    "合計"：2、
    "成功"：1、
    "失敗"：0 
  }、
  "_seq_no"：1、
  "_primary_term"：1 
}

　　我々は、ランダムなid値にESを作成したことがわかりました。

また、当社は、このような結論を得ることができます。

上記のように実際には、要求の性質は、更新置かれます。

これは、リクエストの性質上、新たなポストである。我々は、ESが新たな操作を実行する、IDを指定しない場合は。

idが指定されている場合は、es処理ロジックが更新されます。

エスが、文書の内容を更新するために許可されていない、そのロジックは、最初に削除してから新しいドキュメントを追加することです。

我々は文書としてのid = 1は、以前に存在していないので、私たちは、ES意図が実際に新規であることがわかっています。

ここでは、ポストの違いについて話して、バックに入れているのと同じです。

あなたはこれらを分析していない場合、矛盾プット新しい操作、および一般的な安らかなスタイルを考えることは容易です。

四 .全量更新

コンテンツを更新する際、我々は、IDを指定する必要があります。

次のように：

PUT /ユーザ/ _DOC / 1 
{ 
  "ユーザ名"： "ティム" 
}

　　次のように得られた結果は以下の通りでした。

{ 
  "_index"： "ユーザ"、
  "_type"： "_DOC"、
  "_id"： "1"、
  "_version"：2、
  "結果"： "更新"、
  "_shards"：{ 
    "合計"：2、
    "成功"：1、
    "失敗"：0 
  }、
  "_seq_no"：2、
  "_primary_term"：1 
}

　　私たちは、コンテンツのバージョンは今、それは我々が詳細に言っていない楽観主義によってメカニズムであり、これは、2となることに注意する必要があります。

私たちは、文書ID = 1の内容を照会するために行きます。

GET /ユーザー/ _DOC / 1

　　以下の内容を取得し、我々は_sourceの内容を懸念しています。

{ 
  "_index"： "ユーザ"、
  "_type"： "_DOC"、
  "_id"： "1"、
  "_version"：2、
  "_seq_no"：2、
  "_primary_term"：1、
  "見つかった"：真、
  " _source」：{ 
    "ユーザ名"： "ティム" 
  } 
}

　　私たちは、ユーザ名を更新したいと思っていたことに驚いていますが、ESは、私たちはフィールドを更新助けるだけでなく、年齢のフィールドを削除しました。

それは原因は？

そして、上記の私たちのコンテンツは、実際には一貫性があるだけで最初の新機能を削除した後、操作を更新しない文書をES。

そのため、新しい文書が欠落している年齢のフィールドなかった、私たちのコマンドは、上記の、本質的である場合があります。

多くの場合、我々はそのような効果が発生する必要はありません。

IV。--partial更新部分更新操作。

次のコマンドを参照してください。

私たちは、最初に次の書類を作成します。

PUT /ユーザ/ _DOC / 3 
{ 
  "ユーザ名"： "ジョン"、
  "年齢"：33 
}

　　更新するには、次のコマンドを使用します。

POST /ユーザ/ _update / 3 
{ 
  "DOC"：{ 
      "ユーザ名"： "ジョン"、
      "年齢"：34 
  } 

}

　　我々が使用するローカル更新操作は、この操作は、ローカルコンテンツを更新します。

V.文書を削除します

DELETE /ユーザー/ _DOC / 1

　　私たちは、文書を削除する権利を削除する要求を送信することができます。

オペレーション003ドキュメント

おすすめ