データベース

Spanner: DML トランザクションの累積ミューテーション上限を撤廃

2026年9月17日

Rajeshwar Vanka

Staff Software Engineer

Justin Makeig

Product Manager

Try Gemini Enterprise today

The front door to AI in the workplace

Try now

※この投稿は米国時間 2026 年 9 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

Spanner は、Google Cloud の妥協のない業務データベースです。水平スケーリングや常時稼働の可用性といった最新の分散型システムの利点に加え、豊富な機能セットや使い慣れたエコシステムといったリレーショナルデータベースの利点を兼ね備えています。現在、銀行、小売、メディア、エンターテイメント、AI インフラストラクチャなどの業界のイノベーターが、最も重要なワークロードに Spanner を利用しています。この Spanner において、このたび、より大規模かつ複雑なトランザクションを柔軟に処理する新しい方法が導入されたことをお知らせします。これにより、最高レベルのデータ整合性を必要とするアプリケーションを簡素化できるようになります。

一般に、業務のワークロードは、リアルタイムの意思決定ときめ細かい更新の組み合わせです。たとえば、e コマースアプリで複数ステップの購入手続き中に不正行為を特定する場合を考えてみましょう。このような変更はトランザクション単位、つまり、すべてが成功するか、すべてが失敗するかのどちらかである必要があります。また、後続のリクエストが正しいデータを参照できる必要があります。Spanner の ACID トランザクションに対する今回のアップデートにより、アプリケーションは使い慣れた DML を使用して、整合性、スケーラビリティ、可用性を損なうことなく、更新時により多くのデータを処理できるようになります。

高い上限で柔軟性が向上

これまで Spanner では、クエリが 1 回のトランザクションで実行できる変更（DML を使用する場合など）の上限が 80,000 件でした。これは、更新する行数と列数の積に、依存するインデックスを加えたものとして大まかに計算されていました。アプリケーションは、時間の経過とともに、より多くのデータを処理し、新しい機能を提供できるように進化します。こうした進化に伴い、トランザクションのサイズが拡大すると、以前は小さかったトランザクションがこの上限に達する可能性が生じます。

今回のアップデートでは、80,000 件というミューテーション数の上限がトランザクションから個々の DML ステートメントに移行されます。DML ステートメントは、トランザクションレベルの全体的なミューテーション数の上限に影響しなくなります。INSERT、UPDATE、DELETE など、個々の DML ステートメントが生成するミューテーション数が 80,000 件未満である限り、1 つのトランザクションにいくつでも DML ステートメントを含められるようになりました。

主なメリット

大規模なトランザクション: 累積ミューテーション数の上限に準拠するために、DML ステートメントを人為的に分割するのではなく、ビジネス要件に基づいて論理的にグループ化できます。
シームレスな移行: 今回の変更は、既存のすべての Spanner クライアントライブラリと互換性があるため、アプリケーションコードの更新は不要です。

技術的な考慮事項

ロックと中止

1 つのトランザクションに含めることができる DML ステートメントの数が増えた一方で、トランザクションの規模が拡大して実行時間が長くなると、ロックが保持される時間も長くなることに注意が必要です。これにより、ロックの競合やトランザクションの中止が発生する可能性が高まります。トランザクションを簡潔に保つことで、高いパフォーマンスを維持し、リソースの競合を最小限に抑えることができます。

DML と Mutation API

上限の適用は、データを変更する方法によって異なります。

DML ステートメント: 各ステートメント（executeUpdate など）がミューテーション数の上限 80,000 件に対して個別に評価されます。
Mutation API: insert() や update() など、クライアントライブラリのメソッドを使用する場合、ミューテーションは Commit 呼び出し中に提供されます。80,000 件の上限は引き続き、その 1 回の呼び出しに含まれるミューテーションのセット全体に適用されます。

ミューテーション数について

Spanner では、変更されたセル、主キー、セカンダリインデックスの更新を含め、変更の複雑さに基づいてミューテーション数が数えられます。ミューテーションの数え方について詳しくは、こちらのブログをご覧ください。commit されたトランザクションの合計ミューテーション数は、CommitStats の mutation_count を使用して確認できます。mutation_count には、すべての DML ステートメントと commit 呼び出しにわたって、トランザクションの一部であるすべてのミューテーションが含まれます。

Java の実装例

次の例は、新しい上限のロジックで、1 つのトランザクション内で複数の DML ステートメントを実行する方法を示しています。

読み込んでいます...

import com.google.cloud.spanner.DatabaseClient;
import com.google.cloud.spanner.Statement;
import com.google.cloud.spanner.TransactionContext;
import com.google.cloud.spanner.TransactionRunner.Work;

// Assuming dbClient is your initialized DatabaseClient
dbClient
    .readWriteTransaction()
    .run(
        new Work<Void>() {
          @Override
          public Void doWork(TransactionContext transaction) throws Exception {
            // Each executeUpdate call is evaluated separately against the 80k mod limit.

// Example 1: Updating specific products
            Statement stmt1 = Statement.newBuilder(
                        "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")
                    .bind("productId").to(1L)
                    .build();
            transaction.executeUpdate(stmt1); // Verified against 80k limit

Statement stmt2 = Statement.newBuilder(
                        "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")
                    .bind("productId").to(2L)
                    .build();
            transaction.executeUpdate(stmt2); // Verified against 80k limit separately

// Example 2: Inserting related order data
            Statement stmt3 = Statement.newBuilder(
                        "INSERT INTO OrderItems (OrderId, ItemId, Quantity) VALUES (@orderId, @itemId, @qty)")
                    .bind("orderId").to(100L)
                    .bind("itemId").to(1L)
                    .bind("qty").to(2)
                    .build();
            transaction.executeUpdate(stmt3);

Statement stmt4 = Statement.newBuilder(
                        "UPDATE Orders SET LastUpdated = PENDING_COMMIT_TIMESTAMP() WHERE OrderId = @orderId")
                    .bind("orderId").to(100L)
                    .build();
            transaction.executeUpdate(stmt4);

return null;
          }
        });

変更がない点

個々のステートメントの上限: 1 つの DML ステートメントが生成するミューテーション数が 80,000 件を超える場合は、現在と同じエラーが返されます。
その他のトランザクション上限: 最大トランザクションサイズ（バイト単位）など、その他の制約は引き続き有効です。詳細については、こちらをご覧ください。

ベストプラクティス

CommitStats をモニタリングする: CommitStats で返される mutation_count を利用して、処理によって生成される負荷を把握します。
大規模な処理を最適化する: 1 つのステートメント（一括更新など）が上限を超える場合は、パーティション化 DML の使用や、キーによるページ分けを検討します。

Spanner は、ダウンタイムなしでスケールする必要がある業務アプリケーションの選択肢として、信頼性に優れています。ミューテーション数の上限が引き上げられたことで、デベロッパーは Spanner のグローバル規模での整合性を活用して、より大規模なトランザクションを柔軟に実行できるようになります。Spanner を使用して、リスクを抑えつつイノベーションを推進する方法をご確認ください。また、無料トライアルや、月額わずか 54 ドルから利用できる本番環境インスタンスで、実際にお試しいただくこともできます。

外部の関連資料

- スタッフソフトウェアエンジニア、Rajeshwar Vanka

- プロダクトマネージャー、Justin Makeig

投稿先