私はElasticsearch Bulk APIを使用してドキュメントを作成または更新しています。弾性検索バルクAPI - インデックスと作成/更新
実際に作成または更新されているかどうかは知っていますが、すべてをindexにするか、SQLの意味で「upserts」にするだけでコードを単純化できます。
より明示的なcreateとupdateを使用して、indexを使用して（そして、ESにそれを理解させること）不利な点はありますか？
あなたがcreateを送信する場合は、あなたは文書が常に成功しますindexと同じドキュメントを送信するのに対し、それ以外のコールは失敗しますあなたのインデックスにまだ存在していないことを確認する必要があります。
すると、パフォーマンス上の理由ならば、あなたは（createまたはindexのいずれかで）文書を作成します知っていると、あなたは、だけにして意味をなすかもしれないupdateを使用して、わずか数のプロパティを更新します。
それ以外の場合は、常に完全なドキュメントを送信する場合は、作成と更新の両方で常にindexを使用します。 indexアクションが見つかるたびに、ESはドキュメントが存在しない場合は作成するか、存在する場合は置き換えますが、呼び出しは常に成功します。
短い答え：いいえ不都合はありません。
作成および更新エンドポイントは特別なケースです。作成すると、ドキュメントが既に存在する場合は何もしません。更新すると、ドキュメントのすべてのデータを持っていない場合は、いくつかのフィールドを追加するだけで、データを少なくすることができます。また、ドキュメントがすでに更新されている場合に備えて、索引付けされていることを確認することもできます。
ある文書を何度も何度も置き換える可能性があるとします（まったく同じ文書を何度も索引付けするなど）。 ESは実際に何かを "削除"しないので、後で古いバージョンをクリーンアップするためにガベージコレクタに残しておくと、ますます多くのドキュメントを追加してバージョン番号を増やしていませんか？その場合は、index vs createを使用していないため、短期間でインデックスを膨らませることになり、パフォーマンスに影響する可能性があります。将来のガベージコレクションの大量の使用もパフォーマンスに影響しないのでしょうか？これは私が疑問に思っている本当の疑問であり、修辞的なものではありません。ありがとう – cwarny
しかし、ドキュメントを更新するときに、フェッチしないで、それを修正して、それにインデックスを付けますか？文書全体を更新するには、文書を更新する方法は、文書を取得して変更し、文書全体を再索引付けすることです。これは本当です。ただし、更新APIを使用すると、1回のリクエストでカウンタを増分するような部分的な更新を行うことができます。 ドキュメントは変更不可能であり、変更することはできません。置き換えられるだけです。更新APIは同じ規則に従わなければなりません。 –