挿入、更新、および削除のバッチ処理

挿入、更新、および削除のバッチ処理。

単一のパーティションと複数のパーティションのどちらのバッチ操作でもアトミック性が確保されます。アトミック・トランザクションは不可分でそれ以上単純化できない一連の処理であり、すべて実行されるか、または何も実行されないかのどちらかです。単一パーティションのバッチ操作は本来、アトミックであるのに対し、複数のパーティションのバッチ操作でアトミック性を確保するにはバッチログを使用する必要があります。

一連の操作でアトミック性の確保が重要である場合は、バッチログを使用します。単一パーティションのバッチ操作は、パフォーマンスを向上させるため、1つのミューテーションとしてサーバー側で処理されます。ただし、操作の数が1つの操作の最大サイズを超えたり、クエリーがタイムアウトしたりしないことが条件となります。複数のパーティションのバッチ操作は、多くの場合、パフォーマンスの低下を引き起こすため、アトミック性を確保する必要がある場合にのみ使用してください。

バッチ処理は、単一パーティションの書き込み操作に有効です。しかし、パフォーマンスを最適化しようとして誤ってバッチ処理が使用されることがよくあります。バッチ操作によっては、パフォーマンスが実質的には低下する場合もあります。バッチ操作の中には、コーディネーター・ノードに大きな負荷をかけ、データ挿入の効率を低下させるものもあります。バッチ操作に関係するパーティションの数によってはマルチノード・アクセスの可能性があるため、レイテンシーが大幅に増大することがあります。すべてのバッチ操作で、コーディネーター・ノードは書き込み操作をすべて管理するため、完了までのボトルネックとなりかねません。

バッチ操作が適切な場合：

アトミック性と分離性が必要な場合に、単一のパーティションに対して挿入、更新、または削除を行う場合。アトミック性を確保することで、すべて書き込まれるか、または何も書き込まれません。また、分離性を確保することで、すべての操作が完了するまで部分的な挿入または更新に対するアクセスが行われません。
単一パーティションのバッチ処理によって、1つのメッセージがすべての操作のコーディネーターに送信されます。単一のパーティションのすべてのレプリカがデータを受け取り、コーディネーターは確認応答を待ちます。バッチログ・メカニズムは不要です。バッチに関係するノード数は、レプリカの数によって制限されます。
不整合の発生を避けるため、複数のパーティションへの小規模の挿入または更新のアトミック性を確保する場合。
複数のパーティションのバッチ処理によって、1つのメッセージがすべての操作のコーディネーターに送信されます。コーディネーターはバッチログを書き込み、そのバッチログは他のノードにレプリケートされて、コーディネーターが失敗した場合の不整合の発生を回避できます。次に、コーディネーターは影響を受けるパーティションを持つすべてのノードが操作に対して確認応答するのを待ってから、ログに記録されるバッチを削除します。バッチに関係するノードの数は、ログに記録されるバッチとバッチログのレプリカ・ノード（該当する場合）内の個別のパーティション・キーの数によって制限されます。整合性を保つために少数のパーティションのバッチ操作が必要な場合はありますが、このユース・ケースはどちらかといえば例外的です。

バッチ操作が適切でない場合：

特に大量のパーティションが関係する場合に、複数のパーティションに対してデータの挿入または更新を行う場合。
前述のように、複数のパーティションへのバッチ処理にはパフォーマンス・コストが発生します。ログに記録されないバッチ操作を使用するとバッチログの余計な時間コストが発生するのを回避できますが、同期的であるためにコーディネーター・ノードが依然としてパフォーマンスのボトルネックとなります。代わりの有効な手段として、ドライバー・コードを使用して非同期書き込みを行う方法があります。トークン認識ロード・バランスによって複数のコーディネーター・ノードに書き込みが分散され、挿入および更新操作の完了に要する時間を短縮できます。

バッチ処理された文により、クライアントとサーバー間、また場合によってはコーディネーターとレプリカ間のネットワーク往復を保存できます。ただし、バッチ操作を実行する前に慎重に検討し、必要かどうかを判断してください。データを最もすばやく読み込む方法については、「Batch loading without the Batch keyword」を参照してください。