DynamoDB 비용 모델: SQL이 요금을 숨길 수 있는 이유

DynamoDB에 대해 진짜 SQL을 실행하는 것은 강력합니다 — 원래 그중 어느 것도 기본 제공하지 않는 데이터베이스 위에서 JOIN, GROUP BY, 임의의 WHERE 절을 얻습니다. 하지만 SQL은 쿼리 플래너와 모든 컬럼에 대한 보조 인덱스를 갖춘 엔진을 위해 설계되었고, DynamoDB에는 둘 다 없습니다. 완벽하게 적법한 SELECT이 테이블의 모든 항목을 읽고 — 그에 대해 과금하는 — 전체 테이블 Scan으로 컴파일될 수 있습니다.

이것이 SQL 추상화의 양날입니다. 비싼 액세스 패턴을 공짜처럼 보이게 만듭니다. 이 가이드는 그 아래의 비용 모델을 설명하여 편의가 결코 예상치 못한 요금으로 바뀌지 않게 하고, DynoTable이 쿼리를 실행하기 전에 비용을 어떻게 드러내는지 보여줍니다.

DynamoDB 위의 SQL은 왜 보이는 것보다 비용이 더 드나요?

관계형 데이터베이스는 여러분이 묻는 어떤 컬럼에 대해서도 인덱스를 만들기 때문에 WHERE status = 'active'에 효율적으로 답할 수 있습니다. DynamoDB는 그렇지 않습니다. 정확히 한 가지에 대해서만 효율적으로 답합니다. 파티션 키입니다(선택적으로 정렬 키나 글로벌 보조 인덱스로 좁혀짐). 그 밖의 모든 것은 Scan입니다.

• 파티션 키 동등 조건은 Query입니다. DynamoDB는 그 키 아래의 항목으로 바로 이동하여 그것들만 읽습니다. 제한적이고 저렴합니다.
• 그 밖의 모든 것은 Scan + Filter입니다. DynamoDB는 테이블의 모든 항목을 읽은 다음, 여러분의 WHERE를 FilterExpression으로 적용합니다 — 읽기 후에요. 반환된 소수의 행이 아니라 스캔한 모든 것에 대해 과금됩니다.

그 마지막 지점이 함정입니다. WHERE 절은 작업을 좁히는 것처럼 보입니다. 키가 아닌 속성에서는 출력만 좁힐 뿐입니다 — 읽기 비용은 이미 소비되었습니다.

Query 대 Scan: RCU 계산

DynamoDB는 읽기를 읽기 용량 단위(RCU)로 과금합니다:

• 1 RCU = 최대 4 KB 항목 하나의 강력한 일관성 읽기. 최종적 일관성 읽기는 단위의 절반 비용입니다. 읽기는 4 KB 단위로 올림됩니다.
• Query는 한 파티션 키 아래의 항목만 읽습니다 — 비용은 테이블이 아니라 일치하는 항목에 따라 커집니다.
• Scan은 한 번에 4 KB씩 테이블 전체를 읽습니다. 1 GB 테이블은 한 번의 전체 통과에 대략 262,000 최종적 일관성 RCU입니다 — 매번, 통과할 때마다요.

FilterExpression은 그 숫자를 줄이지 않습니다. 필터링은 읽기 후에 일어나므로, 필터링된 Scan은 필터링되지 않은 것과 정확히 같은 비용이 듭니다. 여러분의 데이터에 대한 실제 숫자는 항목 크기 계산기와 요금 계산기로 계산해 보세요.

어떤 SQL 구문이 조용히 Scan으로 바뀌나요?

• 파티션 키 동등 조건이 없는 WHERE → 읽기 후 필터가 있는 전체 Scan.
• JOIN → DynamoDB에는 서버 측 조인이 없습니다. 조인되는 각 테이블은 개별적으로 가져와 클라이언트 측에서 이어 붙입니다 — N+1 액세스 패턴, 조인되는 행당 한 요청입니다.
• COUNT, SUM, GROUP BY, 집계 → 서버 측 집계가 존재하지 않으므로, 일치하는 모든 항목을 읽습니다. Scan에서는 테이블 전체를 읽는다는 뜻입니다.
• 키가 아닌 속성에 대한 ORDER BY나 DISTINCT → 정렬과 중복 제거가 스캔된 것 전체에 대해 클라이언트 측에서 일어납니다.

이것들 중 어느 것도 실행하는 게 잘못은 아닙니다 — 때로는 Scan이 바로 여러분이 원하는 것입니다. 요점은 언제 하나를 실행하는지 아는 것입니다.

SQL이 비용에 대해 정직하도록 어떻게 유지하나요?

• 액세스 패턴을 중심으로 키를 설계하세요. 가장 저렴한 쿼리는 여러분의 키 스키마가 이미 답하는 쿼리입니다. 단일 테이블 설계 도구와 Query 대 Scan 가이드로 계획하세요.
• Scan 대신 Query를 얻으려면 WHERE에 파티션 키 동등 조건을 넣으세요.
• 스캔하고 필터링하는 대신 두 번째 액세스 패턴을 위해 GSI를 추가하세요.
• 실행하기 전에 비용을 읽으세요. DynoTable의 Workbench는 여러분의 SQL을 실제 DynamoDB 작업으로 컴파일하고 계획을 보여줍니다 — Scan 대 Query, 어떤 인덱스를 사용하는지, 키 조건 대 스캔 후 필터, 그리고 추정 RCU 비용을요 — 그런 다음 전체 Scan과 N+1 조인을 인라인으로 표시합니다. DynamoDB가 결코 출시하지 않은 EXPLAIN입니다. 스캔이 느리고 비싼 이유와 온디맨드 대 프로비저닝 용량도 보세요.

DynoTable의 SQL이 비용 문제를 더 나쁘게 만드나요?

아닙니다 — 비용을 보이게 만들기 때문입니다. DynamoDB 위의 SQL에 대한 비판은 타당합니다. 스캔을 숨기는 추상화는 여러분이 스스로 발등을 찍게 놔둡니다. DynoTable의 답은 SQL을 없애는 것이 아니라, 그 뒤에 비용 X선을 두는 것입니다. Workbench의 모든 쿼리는 실행되기 전에 실제 DynamoDB 형태를 미리 보여주므로, SQL의 편의성과 네이티브 모델이 주는 RCU 및 키 설계에 대한 정직함을 모두 유지합니다.

이 중 어떤 것에도 AI 에이전트가 필요한가요?

아닙니다 — 테이블 뷰어, SQL Workbench, 비용 미리보기 모두 그것 없이도 완전히 작동합니다. AI 에이전트는 DynoTable의 대표 기능 중 하나로 — 스키마를 인식하는 쿼리를 작성하고, 데이터를 변환하는 등 여러 일을 하는 DynamoDB 네이티브 코딩 에이전트입니다 — 원할 때면 언제나 거기 있습니다. 여러분 자신의 AWS Bedrock에서 실행되므로, AWS에 직접 원가로 지불하고(마크업 없음), 여러분의 데이터는 결코 계정을 떠나지 않습니다. 도움이 될 때 켜세요. 코어 클라이언트는 어느 쪽이든 완전합니다.

내 작업은 이식 가능한가요?

네. DynoTable은 담장 친 정원이 아니라 표준으로 말합니다. 표준 SQL, 표준 AWS 자격 증명과 SSO, CSV/JSON 내보내기, TypeScript, JSON-Schema, 또는 Zod로의 추론된 스키마 내보내기, 그리고 여러분 자신의 도구와 에이전트가 연결할 수 있도록 하는 MCP 서버까지요. 여러분의 쿼리, 구성, 스키마는 깔끔하게 내보내집니다 — 아무것도 종속되지 않습니다.

사용해 보기

DynoTable 다운로드하고 여러분 자신의 테이블에 대해 SQL Workbench를 여세요 — 비용 미리보기가 실행하기 전에 모든 쿼리가 실제로 얼마나 드는지 보여줍니다.