Cassandra 6.0-alpha1 と Accord トランザクション — 5年越しの「汎用トランザクション」は今どこまで来たか

はじめに — 5年越しの約束を中間点検する
Accordが約束したこと — CEP-15の目標
実際に何が出荷されたか — 「四半期アルファ」の実体
文法 — BEGIN TRANSACTIONの姿とワンショットモデル
モードとコスト — full、mixed_reads、off
既存テーブルを移行するコスト — マイグレーションはタダではない
その間5.xで使えるもの — SAIとベクトル検索の現実
では、いつから気にすべきか
おわりに
参考資料

はじめに — 5年越しの約束を中間点検する

Cassandraにおいて「トランザクション」は長らく半分の言葉でした。LWT(軽量トランザクション)はPaxosベースのCASなので、単一キーの中でしか動きません — Cassandraドキュメントの表現そのまま、"Paxos only supports a single key" です。複数パーティションをまたいで原子的にまとめる作業は、アプリケーション側がサガやバッチで模倣するしかありませんでした。

これを変えようという提案がCEP-15: General Purpose Transactionsです。追跡用JIRAであるCASSANDRA-17092は2021年10月30日に作成され、2025年1月21日になってようやく「Fixed」として閉じられ、trunkにマージされました。そして2026年3月21日付のアーティファクトとして6.0-alpha1がApache公式リポジトリに上がり、4月3日にdevリストでリリースが告知されました。提案から実行可能なリリースまで4年半。本稿執筆時点(2026年7月中旬)で、6.0はいまだalpha1がすべてであり、プロダクションラインは5.0.8(2026-04-16)です。

だからこそ、いま整理する価値があります。何が約束され、何が実際に出荷され、ドキュメントに書かれた制約は何で、あなたはいつから気にすればいいのか。

Accordが約束したこと — CEP-15の目標

CEP-15が明示した目標をそのまま移すとこうなります。

汎用トランザクション — データベース内のどのキー群でも一度にまとめられる
strict-serializable な分離レベル
最適なレイテンシ — 通常条件下では、すべてのトランザクションがWAN往復1回で済む
最適な障害耐性 — 少数のレプリカ障害でレイテンシや性能が影響を受けない
スケーラビリティ — 新たなボトルネックを作らない
Paxosからのライブマイグレーションのサポート

既存システムとの違いはリーダーがいないことです。CEP文書自体が先行事例をこう分類しています — FaunaDBとFoundationDBはグローバルリーダー方式(スケーラビリティのボトルネック)、DynamoDB・CockroachDB・YugabyteDBはトランザクションログとキーごとのリーダーを組み合わせた複雑な方式、そして学術的なリーダーレスアプローチ(EPaxos系)はまだ実際のDBで使われたことがない。Accordはこの三つ目の道をプロダクションDBに持ち込もうとする試みです。長期計画も文書に明記されています — この作業はプロジェクトでPaxosを置き換えると見込まれており、移行期間中は両プロトコルが共存したのち、Paxosは廃止予定です。

注意点が一つ。「WAN往復1回」はプロトコルレベルの主張であり、ミリ秒単位の公式ベンチマーク数値は、本稿執筆時点で公式文書のどこにもありません。後で見るように、リリースノートすら未だプレースホルダーの状態です。

実際に何が出荷されたか — 「四半期アルファ」の実体

6.0-alpha1のCHANGES.txtには実際にこの行が入っています。

6.0-alpha1
 * General Purpose Transactions (Accord) [CEP-15] (CASSANDRA-17092)
 * Automated Repair Inside Cassandra [CEP-37] (CASSANDRA-19918)
 * ...(抜粋 — このほかTCM、制約フレームワーク、UCS並列コンパクションなど多数)

来たのはAccordだけではありません。NEWS.txtの6.0新機能リストには、CEP-21トランザクショナルクラスターメタデータ(TCM)、CEP-37自動リペアスケジューラ、CEP-42制約フレームワーク、そしてJDK 21とGenerational ZGCのデフォルトGC採用が挙がっています。TCMはアップグレード手順そのものを変える変更なので、NEWS.txtの最上部に「これまでのアップグレードとは異なる運用手順が必要」という警告が付いています。

ただし、リリースの性質は正確に読む必要があります。4月3日の告知はこう述べています — これは6.0シリーズの四半期(quarterly)アルファリリースであり、cassandra-6.0ブランチはまだ作られておらず、このリリースはアルファ品質ライフサイクルガイドラインを開始するものではなく、四半期アルファは開発・テスト目的のみである、と。2025年11月のリリースケイデンス提案スレッドを見ると趣旨は明確です — 四半期アルファはバックポートもサポートもない、「ビルドできることを確認して投票した特定日付のタグ」に過ぎません。

正式なサイクルはその直後に始まりました。2026年4月9日のスレッドでcassandra-6.0ブランチの分岐と6.0-alpha2が議論され(「これがアルファリリースライフサイクルを開始する」)、実際に現在のリポジトリにはcassandra-6.0ブランチが存在し、trunkは7.0開発へ移行しています。しかし7月中旬現在、公式ダウンロードページにある6.0系のアーティファクトはalpha1一つだけです。ベータもGA日程の約束もありません。

バージョン番号にまつわる裏話もあります。もともとこのリリースは5.1になる予定でしたが、2024年12月のdevリスト議論「5.1 should be 6.0」で、TCMとAccordが運用方式を根本的に変える世代交代であるという理由からメジャー番号を上げる方向にまとまりました。結果として5.1は出ず、次のバージョンは6.0になりました。

文書がコードに追いついていない兆候もそのまま見えます。NEWS.txtの6.0新機能セクションには「以下はプレースホルダーであり、まもなく修正される」という文言が残っており、肝心のAccordは新機能リストに項目すらありません。CQLトランザクションユーザーガイド(transactions.adoc)はtrunkにはありますが、cassandra-6.0ブランチにはまだありません。アルファを自分でテストするのでなければ、現段階ではブログや発表資料よりもリポジトリの一次文書を読むほうが正確です。

文法 — BEGIN TRANSACTIONの姿とワンショットモデル

trunkのトランザクションガイドに載っている構文はこんな形です。

BEGIN TRANSACTION
  LET sender = (SELECT balance FROM accounts WHERE user_id = ?);

  SELECT sender.balance;              -- 結果返却は更新文より前でのみ

  IF sender.balance >= 100 THEN
    UPDATE accounts SET balance = balance - 100 WHERE user_id = ?;
    UPDATE accounts SET balance = balance + 100 WHERE user_id = ?;  -- 別パーティションもOK
  END IF
COMMIT TRANSACTION

異なるパーティション(そして異なるテーブル)にまたがる読み取り-条件-書き込みが、一つの原子単位になります。LWTでは不可能だったことです。

重要なのは、これが対話型トランザクションではないという点です。RDBMSのようにBEGINを開いたままアプリケーションロジックとやり取りしながら複数の文を実行するモデルではなく、トランザクション全体を一つの文として一度に提出するワンショットモデルです。内部文書(CQL on Accord)がその理由を説明しています — トランザクションが触れるキー集合は実行前にすべて宣言されなければならず、実行中に変更することはできません。この事前宣言こそが、リーダーレスな依存関係追跡を可能にする代償です。

文書に明示された制約をまとめるとこうです。

LETのSELECTはちょうど1行だけを返さねばならず、パーティションキー全体を等号で指定する必要があり、範囲条件・複数パーティション・集計は不可
トランザクションブロック内では、カウンターテーブル、集計関数、ORDER BYとGROUP BY、独自のTTL・タイムスタンプ、範囲DELETEは使用不可
IF条件はANDのみサポート(ORなし)、null比較はすべてfalse
SET句での行参照の算術は不可 — SET balance = sender.balance - 100 のような書き方はできず、計算済みの値をパラメータとして渡す必要がある
結果を返すSELECTは更新文より前に来なければならず、更新後の値を見るにはコミット後に別途クエリする

性能ガイドも文書にありますが、その脚注がこの機能の成熟度を正直に物語っています — LETは5個、パーティションは3個未満から始めよとしつつ、これは「経験的に導かれた限界ではなく、提案されたガイドライン」だと自ら明かしています。つまりプロジェクト自身も、まだ実測に基づくチューニング指針を持っていないということです。

モードとコスト — full、mixed_reads、off

Accordは有効にすればすべてに一括適用されるわけではなく、テーブル単位で選択します。cassandra.yamlでaccord.enabled: trueを有効にしたうえで、テーブルごとにtransactional_modeを設定します。運用ガイドによれば3つのモードがあります。

off（デフォルト） — これまでのCassandraそのままです。SERIALはPaxosへ、それ以外は結果整合性の経路へ進み、トランザクション文は拒否されます。

full（推奨） — すべての読み書きがAccordを通過します。トランザクションでない読み手が存在しないと分かっているため、Accordは単一レプリカ読み取りと非同期コミットを使え、文書の表現ではWAN往復が2回から1回に減ります。その代わり、指定した整合性レベルは無視されます。

mixed_reads — 書き込みはAccordへ、非SERIALの読み取りは既存の経路へ。この場合、Accordの書き込みを既存の読み取りが見える必要があるため、要求された整合性レベルで同期コミットする必要があり、WAN往復は合計2回になります。文書自身が「ほとんどのユーザーはoffから直接fullへ行くべき」と勧めています。

ここで、マルチDC運用者なら必ず知っておくべき制約が出てきます。Accordがサポートする整合性レベルは、読み取りONE・QUORUM・SERIAL・ALL、書き込みANY・ONE・QUORUM・SERIAL・ALLがすべてです。LOCAL系(LOCAL_QUORUM、LOCAL_ONE、LOCAL_SERIAL)とTWO・THREEはサポートされておらず、サポート外のレベルを要求すると拒否されます。DCローカルのレイテンシに頼ってマルチリージョンを運用してきたワークロードにとって、現状のAccordにはその要求を表現する手段自体がありません。CEP-15もLOCAL_SERIALの代替(非グローバル動作モード)を「今後の目標」としてのみ記しています。おまけに、コミットの整合性レベルにONEを指定しても、静かにQUORUMとして実行されることも文書に明記されています。

性能に関しても、文書が正直に書き記しているコストがあります。LIMIT付きのパーティション範囲読み取りは、ノードごとのコマンドストア(デフォルト値: 利用可能なプロセッサ数)の数だけ分割実行されたのちコーディネーターでマージされるため、メモリとCPUがそれに比例して増幅します。ページングはページごとに別々のトランザクションであるため、全体結果の線形化可能性は保証されず、パーティション範囲読み取りはstrict-serializableな結果を出しません。範囲トランザクションはキートランザクションより依存関係追跡が高コストで、競合も頻発すると内部文書が明言しています。

既存テーブルを移行するコスト — マイグレーションはタダではない

新しいテーブルならWITH transactional_mode = 'full'で作ればそれで済みますが、既存のテーブルはライブマイグレーションを経る必要があります。理由がおもしろく、Accordはトランザクション復旧の際に読み取りを再実行する必要があるため読み取りが決定的でなければならず、非SERIALな書き込みはその決定性を壊してしまうからです。そのためマイグレーションは2段階になっています。

ALTER後の第1段階 — 非SERIALの書き込みはAccordへ行きますが(要求された整合性レベルで同期コミット)、SERIALはPaxosに残ります。データリペア(フルまたは増分)を一度実行して初めて、Accordが既存データを安全に読めるようになります。
第2段階 — すべての操作がAccordへ行きます。ただし、キーごとにPaxosキーリペアが先行する必要があり、最低でもWAN往復1回が追加され、Paxosの書き込みはQUORUMでしか見えないため、Accordの読み取りもQUORUMで行う必要があります。マイグレーション完了にはフルリペアとPaxosリペアの両方が必要です — 増分リペアはPaxosリペアが伝播したデータを含められないため使えません。

リペアのトリガーには自動化がありません。文書のとおり、互換性のあるリペアを定期的に回しているならマイグレーションはいずれ終わり、そうでなければnodetool consensus_admin finish-migrationで直接押し進める必要があります。マイグレーション中の範囲に触れるリクエストは、二つのシステムを行き来する分、最低でもWAN往復1回が余分に付きます。戻り道(fullからoffへ)も文書化されているのは救いです — 単一段階で、Accordリペアの後にPaxosへ復帰します。

運用面のまとめ — マイグレーション期間中はレイテンシが増え、フルリペアという重い作業が必須であり、そのオーケストレーションはあなたの仕事です(6.0のCEP-37自動リペアがこの負担をどれだけ軽減してくれるかは、まだ実測事例がありません)。

その間5.xで使えるもの — SAIとベクトル検索の現実

Accordがアルファにとどまっている間、5.0(2024-09-05 GA)が導入したSAIとベクトル検索は、すでに2年近くGAとして稼働しています。こちらは期待値さえ正確に持てば十分です。

SAI(Storage-Attached Indexing)について、公式FAQ自ら線を引いています — SAIはエンタープライズ検索エンジンではなく、本質的にはフィルタリングエンジンです。文字列演算子は等号とCONTAINS系のみで、LIKEはサポートされていません。インデックスのディスクオーバーヘッドは非インデックスデータ比20〜35%と文書化されており、1クエリでSAIインデックスを3つ以上ANDで組み合わせると、2つまでしかインデックス処理されず残りは後段フィルタリングになります。パーティションキーなしのクエリは依然としてスキャッター・ギャザーであり、高カーディナリティ列の最悪の場合はクラスター全体スキャンになりうると文書自身が警告しています。SAIがデータモデリングの基本原則(パーティションキー中心の設計)を置き換えるのではなく補完するものである理由です。

ベクトル検索はJVector(DiskANN系のANNライブラリ)ベースで、VECTOR型は最大8K(2の13乗)次元、ANNクエリのLIMITは1,000以下でなければなりません。類似度関数はコサイン(デフォルト)・内積・ユークリッドの3種類ですが、文書が書き記した落とし穴の一つは覚えておく価値があります — 内積のほうが速いとされますが(文書の主張では50%)、正規化されていない埋め込みに内積を使うと、静かに無意味な結果が出てきます。インデックスオプションは作成後に変更できないため、ドロップして再作成する必要があります。専用のベクトルDBを置き換えるというより、すでにCassandraにあるデータの隣に埋め込みを置きたいときの選択肢と見るのが妥当です。エンジン別の比較は2026年データベースエンジンディープダイブで扱いました。

では、いつから気にすべきか

今すぐ本番運用中なら。 5.0.xにとどまります。4.0は6.0リリースとともに、4.1は7.0とともにサポートが終わる構造なので(公式ダウンロードページ基準)、5.0へのアップグレード圧力はすでに現実のものです。6.0アップグレード計画にはTCM移行という別個の運用手順が入ることを、あらかじめ書き留めておいてください。

Accordを試す価値がある場合。 LWTを複数パーティションにまたがって模倣するためにサガ・バッチのコードが積み上がったワークロード、そして単一リージョンまたはグローバルQUORUMが許容されるレイテンシプロファイル。こうしたチームなら、アルファの段階で自分のワークロードの競合パターンをあらかじめ測ってみる意味があります。ただし、四半期アルファにはサポートもバックポートもありません。

まだ気にしなくていい場合。 LOCAL_QUORUMでマルチDCを運用しているワークロード(表現する方法がありません)、カウンターテーブルに依存したワークロード(トランザクション不可)、RDBMS式の対話型トランザクションを期待するマイグレーション(ワンショットモデルです)、そしてベンチマーク数値を見て決めたいすべての場合 — 公式数値がまだないので見るものもありません。

おわりに

まとめるとこうです。Accordは、2021年の提案が2026年になってようやく実行可能な形で到着した、リーダーのないマルチパーティションstrict-serializableトランザクションという野心的な設計です。6.0-alpha1にコードは載りましたが、そのアルファは「ビルドできることを確認した日付タグ」に近く、リリースノートはプレースホルダーであり、性能についてはプロトコルの往復回数以上を語る公式資料がありません。構文のワンショットモデル、LOCAL整合性レベルの不在、フルリペアが必要なマイグレーション — この3つが現時点での実質的な境界線です。

逆に言えば、判断に必要な一次資料が全部公開されている、めずらしい時期でもあります。CHANGES.txtとイントリー文書、devリストだけで、これだけの絵が描けます。ベータが出てベンチマークが載り始めたら、また点検します — それまでは、この機能についての意思決定は、発表スライドではなく上記の文書を直接読んで行うことをお勧めします。