DynamoDB vs Google Cloud Spanner

DynamoDB와 Google Cloud Spanner는 둘 다 분산 클러스터 전반에 수평 확장하지만 정반대의 핵심 선택을 합니다. DynamoDB는 알려진 액세스 패턴을 중심으로 설계된 서버리스 AWS NoSQL 키-값 및 문서 저장소입니다. Spanner는 전역 분산 관계형 데이터베이스로, Google의 TrueTime 시계를 사용해 리전 전반에서도 전체 SQL과 강력한(외부적으로 일관된) 트랜잭션을 유지합니다.

DynamoDB와 Spanner 중 무엇을 써야 하나요?

AWS를 사용하고 있으며 요청당 과금과 키 기반 액세스에 대한 예측 가능한 지연 시간을 갖춘 서버리스 NoSQL 저장소를 원한다면 DynamoDB를 선택하세요. 전역 규모에서 관계형 SQL, 조인, 강력한 트랜잭션 일관성이 필요하다면 — 수평 확장하면서도 여전히 관계형처럼 동작하는 데이터베이스라면 — Google Cloud Spanner를 선택하세요. 규모에서의 관계형 보장 대 서버리스 NoSQL의 단순함이 결정 축입니다.

한눈에 보는 DynamoDB vs Spanner

특성	DynamoDB	Google Cloud Spanner
데이터 모델	NoSQL 키-값 및 문서; 유연한 항목별 스키마, 최대 400 KB 항목	관계형 — 테이블, 행, 열, 스키마(그래프, 키-값, 검색 기능도 노출)
쿼리 언어	네이티브 API(`GetItem`, `Query`, `Scan`)와 SQL 호환 언어 PartiQL	두 가지 방언의 전체 SQL — GoogleSQL과 PostgreSQL 호환 방언
조인 및 관계	JOIN 연산자 없음; AWS는 액세스 패턴 중심의 비정규화를 권장	전체 관계형 조인, 외래 키, 인터리브 테이블
일관성	기본값은 최종적 일관성(읽기); 요청당 강력한 일관성(읽기)(리전 내)	TrueTime 시계에 뒷받침되어, 리전 전반을 포함해 기본적으로 외부(강력한) 일관성
트랜잭션	리전 내 여러 항목에 걸친 ACID 트랜잭션	리전 전반을 포함한 전역적으로 일관된 ACID 트랜잭션
확장 모델	자동 파티셔닝; 서버리스 온디맨드 또는 프로비저닝된 용량	오토스케일링을 갖춘 프로비저닝된 컴퓨팅(노드 / 처리 단위)을 통한 수평 확장; 스토리지는 별도로 확장
다중 리전	Global Tables — 다중 리전, 액티브-액티브 복제(리전 간 최종적 일관성)	리전 전반에 걸쳐 강력한 일관성을 보존하는 다중 리전 구성
요금 / 운영 모델	요청당 과금(온디맨드) 또는 프로비저닝된 용량에 스토리지; 서버리스, AWS 전용	프로비저닝된 컴퓨팅 용량에 스토리지(및 네트워크); 노드/처리 단위 기반, GCP 전용
최적 워크로드	일관된 낮은 지연 시간이 필요한, 알려진 키 액세스를 가진 대규모 운영 앱	규모에서 강력한 일관성, SQL, 조인이 필요한 전역 관계형 시스템

DynamoDB가 더 나은 선택인 경우

AWS를 사용하며 서버리스 NoSQL을 원합니다. 온디맨드 용량은 프로비저닝할 것이 없고, 트래픽에 맞춰 확장되며, 유휴 시 0까지 확장됩니다.
액세스 패턴이 알려져 있고 키 기반입니다. DynamoDB의 파티션/정렬 키 모델은 키가 읽기를 중심으로 설계될 때 일관된 한 자릿수 밀리초 지연 시간을 제공합니다.
관계형 조인이나 전역 강력한 일관성이 필요하지 않습니다. 비정규화된 키 지향 모델이 맞는다면, 사용하지 않을 보장에 비용을 지불하지 않게 됩니다.
네이티브 AWS 통합을 원합니다 — IAM, Lambda, Streams와의 통합.

Spanner가 더 나은 선택인 경우

전역 규모에서 관계형 SQL이 필요합니다. Spanner는 수평 확장하면서도 조인, 스키마, 전체 SQL을 유지합니다 — 확장을 위해 관계형 의미론을 포기하지 않습니다.
리전 전반에 걸친 강력한 일관성이 필요합니다. TrueTime에 뒷받침된 외부 일관성은 다중 리전 트랜잭션이 마치 직렬화된 것처럼 동작하게 하며, 이는 DynamoDB의 Global Tables(리전 간 최종적 일관성)가 제공하지 않는 것입니다.
워크로드가 관계형이며 쿼리 유연성이 필요합니다. 정규화된 테이블 전반의 임의 조인과 진화하는 쿼리가 Spanner의 모델에 잘 맞습니다.
GCP를 사용하며 높은 가용성 SLA를 갖춘 관리형 전역 데이터베이스를 원합니다.

DynamoDB로 작업하기

DynamoDB가 맞는다면, DynoTable은 macOS, Windows, Linux에서 DynamoDB를 위한 네이티브 데스크톱 클라이언트입니다. 표준 AWS 자격 증명 체인을 읽으므로 데이터는 DynamoDB에 그대로 머무르고 마이그레이션할 것이 없습니다. Spanner의 SQL에 익숙한 팀을 위해, SQL Workbench는 관계형 형태의 쿼리 — 조인, GROUP BY, 집계 — 를 DynamoDB의 Query/Scan으로 컴파일해 DynamoDB의 액세스 패턴 규칙 안에서 표현하며, AI 어시스턴트는 사용자 본인의 AWS Bedrock 자격 증명으로 실행됩니다.

SQL for DynamoDB와 PartiQL vs SQL 가이드는 SQL에서 무엇이 넘어오는지 설명하며, 무료 DynamoDB Expression Builder는 키 조건, 필터, 업데이트 표현식을 SDK, CLI, PartiQL 형태로 생성합니다. DynoTable은 클로즈드 소스 상용 앱입니다. 이 페이지는 그 기능이 무엇인지를 설명하며, 어떻게 만들어졌는지는 다루지 않습니다.

FAQ

Spanner는 DynamoDB 같은 NoSQL 데이터베이스인가요?

아닙니다. Spanner는 전체 SQL, 조인, 스키마를 갖춘 관계형 데이터베이스로, 분산 시스템처럼 수평 확장할 뿐입니다. DynamoDB는 JOIN 연산자가 없는 NoSQL 키-값 및 문서 저장소입니다. Spanner의 차별점은 전역 규모에서 관계형이고 강력한 일관성을 지닌 의미론을 유지한다는 주장입니다.

DynamoDB는 Spanner처럼 전역 강력한 일관성을 제공하나요?

같은 방식은 아닙니다. DynamoDB는 단일 리전 내에서 강력한 일관성 읽기를 제공하며, Global Tables는 리전 전반에 복제하지만 리전 간에는 최종적 일관성을 갖습니다. Spanner는 TrueTime을 사용해 리전 전반에서도 트랜잭션에 외부(강력한) 일관성을 제공합니다.

DynamoDB가 Spanner를 대체할 수 있나요?

관계형 SQL이나 전역 강력한 일관성이 필요하지 않을 때만 가능합니다. 액세스가 키 기반이고 비정규화된 모델이 맞는다면 DynamoDB가 더 단순하고 서버리스입니다. 조인, 임의 SQL, 또는 강력한 일관성을 가진 리전 간 트랜잭션에 의존한다면, 그것이 바로 Spanner의 목적이며 — 대체한다는 것은 데이터를 DynamoDB의 키를 중심으로 재모델링하고 그러한 보장을 포기한다는 뜻입니다.