カサンドラでバッチステートメントがアトミックであるとはどういう意味ですか? 正確に言うと、ドキュメントは本質的に少し混乱します。クラスター内のノード全体でクエリがアトミックであることを意味しますか?
たとえば、100 個のクエリを含むバッチがあるとします。バッチの 40 番目のクエリが失敗した場合、バッチで実行された 39 のクエリはどうなりますか?
内部でバッチログが作成され、部分的なバッチの一貫性が維持されることを理解しています。残りの 39 エントリを削除し、バッチ クエリに必要なアトミックな性質を提供しますか。
MYSQL では、autocommit を false に設定しているため、ロールバックできます。そのような場合、cassandra はロールバックしますか?
実際には、アトミック バッチではなく、ログ バッチと呼ばれます。コーディネーターが書き込みを開始する前に、他の 2 つのノードに複製されたバッチも取得します。
これについて少し前にブログを書きました: http://christopher-batey.blogspot.co.uk/2015/03/cassandra-anti-pattern-cassandra-logged.html
特定の質問については、「残りの 39 エントリを削除し、バッチ クエリに必要なアトミックな性質を提供しますか」
いいえ - Casssandra にはロールバックの概念がありません。バッチ ログ レプリカは、すべてが成功するまでクエリを再試行し続けます。
最終的に一貫性があるのは C* の主要なアイデアであり、これと同じ方法でバッチを設計します。SQL の世界のトランザクションとは異なり、障害が発生した場合、バッチはロールバックではなく「再生」されます。
C* では、削除よりも追加の方がコストがかからないため、この設計の違いは合理的です。
注意すべきことの 1 つは、C* では分離が許可されていないことです。つまり、他のクライアントはまだ部分的に更新された値を読み取る可能性があります。
C* でのバッチの機能に関するディスカッション ページ https://issues.apache.org/jira/browse/CASSANDRA-4285
アトミック バッチは、オール オア ナッシングのようにする必要があります。アトミックなバッチ定義には対応していないため、部分的なログのみを再生する必要はないと思います。
-Vivek