데이터베이스

Spanner: DML 트랜잭션의 누적 변형 한도 삭제

2026년 9월 15일

Rajeshwar Vanka

Staff Software Engineer

Justin Makeig

Product Manager

지금 Gemini Enterprise Business Edition을 사용해 보세요

비즈니스 현장에서 Google AI를 만나기 위한 첫걸음

지금 시작하기

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

Spanner는 Google Cloud의 타협 없는 운영 데이터베이스로, 최신 분산 시스템에 필요한 수평적 확장성과 상시 가용성에 더해 관계형 데이터베이스의 풍부한 기능 모음과 익숙한 생태계를 제공합니다. 오늘날 은행, 소매, 미디어 및 엔터테인먼트, AI 인프라 등 다양한 산업의 혁신 기업이 가장 중요한 워크로드를 Spanner에서 실행하고 있습니다. 이번에 Spanner에서 더 크고 복잡한 트랜잭션을 보다 유연하게 처리할 수 있는 새로운 방법을 발표하게 되어 기쁩니다. 이를 통해 최고 수준의 데이터 일관성이 필요한 애플리케이션을 더욱 간편하게 구축할 수 있습니다.

운영 워크로드에서는 일반적으로 실시간 의사 결정과 세밀한 데이터 업데이트가 함께 이루어집니다. 예를 들어 전자상거래 앱의 여러 단계로 구성된 결제 과정에서 사기를 탐지하는 경우를 생각해 볼 수 있습니다. 이러한 변경 작업은 트랜잭션으로 처리되어야 합니다. 즉, 모든 작업이 성공하거나 모두 실패해야 하며, 이후의 요청에서는 항상 올바른 데이터가 조회되어야 합니다. 이번 Spanner의 ACID 트랜잭션 업데이트를 통해 애플리케이션은 익숙한 DML을 사용하면서 일관성, 확장성 또는 가용성을 저해하지 않고 한 번의 업데이트에서 더 많은 데이터를 처리할 수 있습니다.

더 높은 한도, 더 많은 유연성

이전에는 Spanner에서 DML 등을 사용해 하나의 트랜잭션에서 쿼리가 수행할 수 있는 변경 작업의 수를 80,000개로 제한했습니다. 이 값은 대략 업데이트되는 행 수와 열 수를 곱한 값에 종속 색인에서 발생하는 변경 작업을 더해 계산되었습니다. 애플리케이션은 시간이 지남에 따라 더 많은 데이터를 처리하고 새로운 기능을 제공하도록 발전합니다. 이에 따라 트랜잭션의 크기도 커지면서, 이전에는 한도에 여유가 있던 작은 트랜잭션도 이 한도에 도달할 수 있습니다.

이번 업데이트에서는 트랜잭션에 적용되던 80,000개의 mutation mod 한도를 개별 DML 문에 적용하도록 변경합니다. 이제 DML 문은 전체 트랜잭션에 적용되는 변형 한도에 더 이상 포함되지 않습니다. 따라서 하나의 트랜잭션에 INSERT, UPDATE, DELETE와 같은 DML 문을 개수에 제한 없이 포함할 수 있습니다. 단, 각 개별 문에서 생성되는 mutation mod 수는 80,000개 미만이어야 합니다.

주요 이점

더 큰 트랜잭션: 누적 변형 한도를 준수하기 위해 인위적으로 트랜잭션을 분할하는 대신, 비즈니스 요구사항에 따라 DML 문을 논리적으로 그룹화할 수 있습니다.
원활한 전환: 이번 변경사항은 기존의 모든 Spanner 클라이언트 라이브러리와 호환되므로 애플리케이션 코드를 업데이트할 필요가 없습니다.

기술적 고려사항

잠금 및 중단

이제 하나의 트랜잭션에 더 많은 DML 문을 포함할 수 있지만, 트랜잭션이 크고 실행 시간이 길어질수록 잠금이 더 오래 유지된다는 점에 유의해야 합니다. 이로 인해 잠금 경합 및 트랜잭션 중단이 발생할 가능성이 높아질 수 있습니다. 트랜잭션을 간결하게 유지하면 높은 성능을 유지하고 리소스 경합을 최소화하는 데 도움이 됩니다.

DML과 Mutation API 비교

한도 적용 방식은 데이터를 수정하는 데 사용하는 방법에 따라 다릅니다.

DML 문: 각 문(예: executeUpdate)은 80,000개 mod 한도를 기준으로 개별적으로 평가됩니다.
변형 API: insert() 또는 update()와 같은 클라이언트 라이브러리 메서드를 사용하는 경우 커밋 호출 시 변경사항이 제공됩니다. 80,000개 한도는 해당 호출에 포함된 전체 변형 집합에 계속 적용됩니다.

mutation mod 이해하기

Spanner는 수정되는 셀, 기본 키, 보조 색인 업데이트 등 변경 작업의 복잡성을 기준으로 mod 수를 계산합니다. 변경사항이 계산되는 방식에 대한 자세한 내용은 이 블로그를 참고하세요. CommitStats의 mutation_count를 통해 커밋된 트랜잭션에서 발생한 총 mod 수를 모니터링할 수 있습니다. mutation_count에는 모든 DML 문과 커밋 호출을 통해 해당 트랜잭션에 포함된 모든 변경사항이 집계됩니다.

Java 구현 예시

다음 예시에서는 새로운 한도 적용 방식에 따라 하나의 트랜잭션에서 여러 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;
          }
        });

변경되지 않은 사항

개별 문 한도: 하나의 DML 문에서 자체적으로 80,000개를 초과하는 mod가 생성되는 경우에는 현재와 동일한 오류가 반환됩니다.
기타 트랜잭션 한도: 바이트 단위의 최대 트랜잭션 크기와 같은 다른 제약 조건은 계속 적용됩니다. 자세한 내용은 여기를 참조하세요.

권장사항

CommitStats 모니터링: CommitStats에서 반환된 mutation_count를 활용하여 작업에서 발생하는 부하를 파악합니다.
대규모 작업 최적화: 하나의 문(예: 일괄 업데이트)이 한도를 초과하는 경우 Partitioned DML을 사용하거나 키를 기준으로 페이지를 나누는 것이 좋습니다.

Spanner는 다운타임 없이 확장해야 하는 운영 애플리케이션을 위한 신뢰할 수 있는 선택지입니다. 이러한 변형 한도 확대로 개발자는 Spanner의 전역 일관성을 활용하는 더 큰 트랜잭션을 실행할 수 있는 유연성을 확보할 수 있게 되었습니다. Spanner가 팀의 빠른 혁신을 지원하면서 위험을 줄이는 데 어떻게 도움이 되는지 알아보거나, 무료 체험판 또는 월 $54부터 시작하는 프로덕션 인스턴스로 직접 사용해 보세요.