DynamoDB vs Redshift

DynamoDB와 Amazon Redshift는 드물게 대안 관계입니다. DynamoDB는 운영 데이터베이스입니다 — 알려진 키에 대한 한 자릿수 밀리초 읽기와 쓰기로 라이브 애플리케이션 트래픽을 처리합니다. Redshift는 "a fully managed, petabyte-scale data warehouse service in the cloud"로, 리포팅과 분석을 위해 대규모 데이터셋을 스캔하고 집계하도록 만들어졌습니다. 둘 다 운영하는 팀이 일반적이며, AWS는 둘 사이에 데이터를 한 방향으로 옮기는 관리형 통합을 제공합니다.

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

애플리케이션의 라이브 데이터 — 주문 접수, 세션 읽기, 키로 가져오는 레코드 — 에는 DynamoDB를 사용하세요. 전체 데이터셋에 걸쳐 질문해야 할 때 — 지역·월별 매출, 코호트 리텐션, 여러 소스를 조인하는 대시보드 — 에는 Redshift를 사용하세요. "어느 쪽"이라는 질문은 보통 "쓰기 경로에는 DynamoDB, 분석가에는 Redshift"로, 그 사이에 zero-ETL 통합을 두는 쪽으로 해결됩니다.

한눈에 보는 DynamoDB vs Redshift

특성	DynamoDB	Redshift
워크로드	운영(OLTP 스타일) — 키별 대량 읽기와 쓰기	분석 — 대규모 데이터셋 스캔 및 집계
데이터 모델	스키마 없는 NoSQL 항목 최대 400 KB; 항목마다 속성이 다름	선언된 열, 분산 키, 정렬 키를 갖춘 관계형 테이블
쿼리 언어	네이티브 API(`GetItem`, `Query`, `Scan`, …)와 PartiQL	전체 SQL, 그에 따른 BI 및 SQL 도구
조인 및 집계	서버 측 조인 없음; 집계는 서버 측 연산이 아님	조인, 윈도우 함수, `GROUP BY` 및 나머지 분석 SQL
액세스 패턴	알려진 키 중심으로 설계; Scan은 비싼 예외	스캔하도록 설계 — 많은 행을 읽는 것이 정상
지연 시간	요청당 한 자릿수 밀리초	분석 쿼리당 초~분, 훨씬 더 많은 데이터에 대해
확장	서버리스; AWS가 파티션 관리	서버리스 워크그룹 또는 프로비저닝된 클러스터; 쿼리 워크로드에 맞게 용량 조정
신선도	요청 시 read-your-write	적재 방식만큼 신선 — zero-ETL 통합은 15–30분마다 업데이트를 반영
요금 모델	요청당 또는 프로비저닝된 용량에 스토리지	컴퓨팅 용량에 스토리지; 유휴 서버리스 웨어하우스는 컴퓨팅 과금 없음

DynamoDB가 더 나은 선택인 경우

라이브 애플리케이션 트래픽. 알려진 키에 대한 예측 가능한 한 자릿수 밀리초 읽기와 쓰기, 어떤 요청률에서든.
항목마다 다른 schema. 한 테이블에 이질적인 항목은 DynamoDB에서 정상이며, 웨어하우스는 선언된 열을 원합니다.
서버리스 운영. 크기를 정하거나 패치하거나 일시 중지할 클러스터가 없습니다.
쓰기 집약 경로. DynamoDB는 고볼륨 쓰기를 본래 역할로 흡수합니다. 웨어하우스는 대량 적재와 읽기에 최적화되어 있습니다.

Redshift가 더 나은 선택인 경우

전체 테이블에 걸친 질문. 1년치 주문 집계는 본질적으로 Scan이며, DynamoDB가 피하라고 하는 액세스 패턴이고 Redshift가 설계된 패턴입니다.
여러 소스 간 조인. 웨어하우스는 조인합니다. DynamoDB에는 서버 측 조인이 없습니다.
BI 도구. Redshift는 JDBC/ODBC로 SQL을 말하므로 기존 대시보드와 "the same SQL-based tools and business intelligence applications that you use today"에 바로 들어갑니다.
프로덕션을 방해해서는 안 되는 분석. 복제본에 대해 분석을 실행하면 사용자에게 서비스하는 테이블의 부하를 줄일 수 있습니다.

함께 사용하기

표준 패턴은 단방향입니다. DynamoDB가 애플리케이션을 서비스하고, 복사본이 Redshift에 들어가며, 분석가는 그 복사본에서 작업합니다. AWS는 두 경로를 지원합니다 — "from Amazon S3 or Amazon DynamoDB into Amazon Redshift"로 직접 적재하는 구형 COPY 명령과, 복사본을 스스로 최신 상태로 유지하는 관리형 zero-ETL 통합입니다.

zero-ETL 통합이 실제로 하는 일

"Zero-ETL"은 라이브 뷰를 연상시킵니다. 그렇지 않으며, 대시보드를 설계하기 전에 세부 사항이 중요합니다.

타이머에 맞춘 복제 파이프라인입니다. AWS는 정확합니다. "On activation, the integration exports the full DynamoDB table to populate the Amazon Redshift database." 그다음 "the zero-ETL integration then incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports." 따라서 Redshift의 데이터는 최대 30분까지 오래됩니다. 일일 리포팅에는 괜찮고, 사용자가 마지막 행동이 반영되길 기대하는 것에는 맞지 않습니다.

특정 시점 복구(PITR)는 필수이며 — 이제 이유가 분명합니다. 전제 조건은 분명합니다. "A zero-ETL integration between Amazon DynamoDB and Amazon Redshift requires your source DynamoDB table to have Point-in-time recovery (PITR) enabled." AWS는 한곳에서 요구 사항을, 다른 곳에서 메커니즘을 문서화하며 둘을 연결하지는 않지만, 부착해야 하는 리소스 기반 정책이 실마리를 줍니다 — redshift.amazonaws.com에 dynamodb:ExportTableToPointInTime 작업을 부여합니다. 통합은 DynamoDB의 S3보내기 기계 위에 세워져 있으며, 그 기계는 연속 백업에서 읽습니다. PITR이 없으면보내기도, 통합도 없습니다.

늦게 마주치는 예산 결과가 있습니다. 큰 테이블에서 PITR을 활성화하면 테이블 크기에 대한 상시 요금이 생기며, 복구가 아니라 분석 파이프라인을 위한 비용입니다. 통합 가격을 Redshift 단독이 아니라 "Redshift + PITR"로 책정하세요 — 무료 DynamoDB 요금 계산기가 확정 전에 스토리지 쪽 규모를 잡아 줍니다.

기존 테이블을 막는 두 가지 제약. 둘 다 문서화된 제한이며, 사후에 고치기 어렵습니다.

"The DynamoDB table and Amazon Redshift cluster need to be in the same Region." 여러 리전을 통합하는 웨어하우스는 이 경로로 모두 끌어올 수 없습니다.
"The source DynamoDB table must be encrypted with either an Amazon-owned or Customer-managed AWS KMS key. Amazon managed encryption is not supported for the source DynamoDB table." AWS 관리형 암호화로 만든 테이블은 통합을 만들기 전에 암호화 설정을 바꿔야 합니다.

데이터 형태가 물어뜯는 지점. DynamoDB 항목은 설계상 이질적이고, 웨어하우스 테이블은 열을 갖습니다. 하나의 파티션 키 규칙 아래 여러 엔티티 타입을 담는 단일 테이블 설계는 복제만으로 깔끔한 스타 스키마가 되지 않습니다. 데이터가 도착한 뒤 Redshift에서의 모델링 작업을 계획하세요 — 통합은 파이프라인을 없애지, schema 설계를 없애지는 않습니다.

아직 웨어하우스가 필요 없을 때

모든 집계가 분석 문제는 아닙니다. "Redshift에 넣어야 한다"는 말의 상당수는 한 가지 질문에서 시작합니다 — 이 상태의 항목이 몇 개인지, 이 고객의 합계는 얼마인지, 어떤 파티션 키가 지배적인지 — 가끔, 한 테이블에 대해, 엔지니어가 묻는 질문입니다.

DynoTable의 SQL Workbench는 그 종류의 질문에 DynamoDB에 직접, 온디맨드로 답합니다. COUNT, SUM, AVG, MIN, MAX, GROUP BY, HAVING, DISTINCT가 있는 실제 SQL과 INNER/LEFT JOIN입니다. 포지셔닝은 의도적으로 좁습니다 — DynamoDB의 액세스 패턴 규칙 안에서의 SQL. 단일 SELECT이며 CTE, UNION, 윈도우 함수, 스칼라 하위 쿼리는 없습니다. 조인 대상은 파티션 키 또는 GSI 파티션 키여야 합니다. 결과는 부분 배지와 함께 스트리밍되고 쿼리가 끝까지 실행되면 정확해지며, 데이터를 읽는 데 드는 읽기 비용은 그대로 듭니다.

웨어하우스 대체는 아니며, 위 한계가 정직한 경계입니다. 그러나 복제 파이프라인, PITR 요금, schema 설계보다 빠른 답이며, 웨어하우스를 만들기 전에 그 질문이 가치 있었는지 알려 줍니다. Workbench 쿼리 실행은 유료 기능입니다. 편집기와 자동 완성은 무료입니다. DynoTable은 클로즈드 소스 상용 앱입니다. 이 페이지는 그 기능이 무엇인지를 설명하며, 어떻게 만들어졌는지는 다루지 않습니다.

FAQ

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

애플리케이션 트래픽용으로는 아닙니다. Redshift는 스캔하고 집계하도록 만든 데이터 웨어하우스이며, 한 자릿수 밀리초 지연 시간의 고볼륨 키 조회를 서비스하도록 설계되지 않았습니다. 둘은 나란히 운영되며, DynamoDB가 애플리케이션을 서비스하고 Redshift의 복제본이 분석을 서비스합니다.

Redshift의 DynamoDB 데이터는 얼마나 신선한가요?

zero-ETL 통합을 쓰면 최대 약 30분까지 오래됩니다. AWS는 초기 전체보내기 후 "incrementally replicates updates from DynamoDB to Amazon Redshift every 15-30 minutes using DynamoDB incremental exports"라고 문서화합니다. 라이브 뷰가 아니라 준실시간 리포팅으로 다루세요.

zero-ETL 통합에 PITR이 왜 필요한가요?

DynamoDB의 특정 시점보내기 위에 세워져 있기 때문입니다. 통합에 필요한 리소스 기반 정책은 Amazon Redshift에 dynamodb:ExportTableToPointInTime 작업을 부여하며, 그보내기는 PITR이 유지하는 연속 백업에서 읽습니다. 따라서 PITR 활성화는 통합의 실질적이고 지속적인 비용입니다.

참고 자료

Last verified 2026-08-02 against the official AWS Redshift Management Guide and DynamoDB Developer Guide.