DynamoDB용 SQL: 무엇이 되고, 무엇이 안 되며, 그리고 Workbench

DynamoDB는 NoSQL 키-값 저장소이지만, 사람들이 기대하는 것보다 SQL 모양의 질문에 더 많이 — 그리고 바라는 것보다는 훨씬 적게 — 답합니다. 이것이 정직한 지도입니다: DynamoDB 위의 SQL에서 기본으로 실제로 얻는 것, 어디서 멈추는지, 그리고 네이티브 표면이 표현할 수 없는 JOIN / GROUP BY / 집계 쿼리를 실행하는 몇 가지 방법.

DynamoDB를 SQL로 쿼리할 수 있나요? 짧은 답

부분적으로요. DynamoDB는 PartiQL을 제공하며, AWS 문서는 이를 "Amazon DynamoDB에서 데이터를 선택, 삽입, 갱신, 삭제하는 SQL-호환 쿼리 언어"로 설명합니다. 그래서 SELECT * FROM "Orders" WHERE OrderID = 100을 쓸 수 있고 동작합니다.

하지만 PartiQL은 SQL 엔진이 아니라 DynamoDB API 위의 SQL-호환 표면입니다. 구문을 말하지만, 관계형 쿼리 능력을 더하지는 않습니다. AWS는 "Amazon DynamoDB가 PartiQL 쿼리 언어의 부분 집합을 지원한다"고 명시합니다 (참조). JOIN, GROUP BY, COUNT(*)에 손대는 순간, PartiQL이 할 수 있는 것을 벗어납니다 — 전체 기능별 비교는 PartiQL 대 SQL을 보세요.

PartiQL: SQL-호환 표면이지 SQL 엔진이 아님

PartiQL은 SQL처럼 보이는 문장을 SDK가 노출하는 것과 같은 데이터 플레인 작업으로 매핑합니다. 파티션 키 동등 조건이 있는 SELECT는 Query로, 없는 SELECT는 Scan으로 컴파일됩니다. AWS SELECT 참조에 따르면:

SELECT 문장을 사용하면 WHERE 절에 파티션 키와의 동등 또는 IN 조건이 제공되지 않은 경우 전체 테이블 스캔이 발생할 수 있습니다.

그래서 Query와 Scan을 지배하는 같은 액세스 패턴 규칙이 여전히 적용됩니다 — PartiQL은 그것을 익숙한 구문 뒤에 숨길 뿐입니다. 쿼리 플래너도, 조인도, 집합 기반 집계도 더하지 않습니다. 모든 문장은 하나의 네이티브 작업으로 무너집니다:

작업이 단일 Get/Query/Scan/Put/Update/Delete로 환원되지 않으면, PartiQL은 단순히 표현할 수 없습니다. 아래의 모든 것은 그 한 가지 사실의 결과입니다.

PartiQL이 커버하는 것

DynamoDB의 PartiQL은 네 가지 DML/쿼리 문장을 지원합니다:

• SELECT — 항목 읽기(Query 또는 Scan으로 컴파일)
• INSERT — 항목 추가(PutItem)
• UPDATE — 항목 수정(UpdateItem)
• DELETE — 항목 제거(DeleteItem)

또한 트랜잭션과 배치 작업을 지원합니다. 잘 구성된 읽기는 동등 또는 IN으로 파티션 키를 겨눕니다:

SELECT OrderID, Total
FROM "Orders"
WHERE OrderID IN [1, 2, 3] ORDER BY OrderID DESC

ORDER BY는 허용되지만, AWS 참조는 정렬 키를 "해시 키 또는 정렬 키" — 임의의 열이 아니라 파티션 키 또는 정렬 키 — 로 제한합니다. 그것이 PartiQL의 SELECT가 받는 천장입니다. 복사-붙여넣기 가능한 문장은 PartiQL 예제를 보세요.

PartiQL이 못 하는 것

이것들은 개발자가 "SQL"에서 가장 자주 기대하는 것들이며, PartiQL은 그 중 하나도 지원하지 않습니다:

• JOIN 없음. PartiQL SELECT 구문은 단일 FROM {{table}}[.{{index}}] — 하나의 테이블 또는 하나의 인덱스이지, 키로 관련된 두 테이블이 결코 아닙니다. 이것이 단일 테이블 설계 트레이드오프입니다: 쿼리 계층이 나중에 데이터를 재형성할 수 없으므로 액세스 패턴을 미리 모델링합니다.
• GROUP BY 없음. 문법에 없습니다. 행을 그룹화할 절이 없습니다.
• 집계 함수 없음. PartiQL 함수 참조는 "집계 함수" 아래에 정확히 하나의 함수를 나열합니다: SIZE, 이는 단일 항목에 대한 속성의 바이트 크기를 반환합니다. 행에 걸친 COUNT, SUM, AVG, MIN, MAX는 없습니다. AWS는 명확히 말합니다: "이 목록에 포함되지 않은 모든 SQL 함수는 현재 DynamoDB에서 지원되지 않습니다."
• LIKE 없음, 서브쿼리 없음, UNION 없음, 윈도 함수 없음. 패턴 매칭은 contains / begins_with를 사용하고, 나머지는 동등물이 전혀 없습니다.

그래서 "지난달 고객별 총 매출" — 어떤 관계형 데이터베이스에서든 한 줄 GROUP BY — 은 PartiQL로 표현할 수 없습니다. 데이터를 스캔해서 꺼내 애플리케이션 코드에서 집계하게 됩니다.

DynamoDB 데이터에 대해 진짜 JOIN / GROUP BY / 집계 동작을 얻는 유일한 방법은 그 위에 실제 SQL 엔진을 실행하는 도구입니다. 두 가지가 있습니다: Amazon Athena의 페더레이션 커넥터, 그리고 DynoTable의 SQL Workbench.

Amazon Athena로 DynamoDB를 진짜 SQL로 쿼리하는 방법

"DynamoDB 위의 진짜 SQL"에 대한 AWS 자체의 답은 Amazon Athena DynamoDB 커넥터이며, 이는 "Amazon Athena가 DynamoDB와 통신할 수 있게 해 테이블을 SQL로 쿼리할 수 있게" 합니다. Athena가 완전한 SQL 엔진이므로, 이것은 실제로 JOIN과 집계를 줍니다 — AWS의 설명서 제목은 "Athena를 사용해 Amazon DynamoDB 테이블에 액세스, 쿼리, 조인하기"입니다.

함정은 설정과 비용입니다:

• 계정에 배포하는 Lambda 기반 페더레이션 커넥터입니다(Athena 콘솔 또는 Serverless Application Repository를 통해). 스키마는 AWS Glue로 연결되고 결과는 S3 버킷으로 흘립니다 (커넥터 문서).
• 내부적으로 여전히 DynamoDB의 Query와 Scan API 작업을 사용합니다. AWS는 "스캔을 사용하는 쿼리는 많은 수의 읽기 용량 단위(RCU)를 소비할 수 있다"고 경고하므로, 큰 테이블에 대한 분석 쿼리는 많은 항목을 읽고 — 과금합니다 (커넥터 비용). 스캔이 많은 쿼리가 무엇을 비용 들이는지 가늠하려면 항목 크기 계산기를 사용하세요.
• INSERT INTO 같은 쓰기 작업은 커넥터를 통해 지원되지 않습니다.

Athena는 예약된 분석과 BI 대시보드에 적합한 도구입니다. "그냥 두 테이블을 조인해서 결과를 눈으로 보고 싶다"는 일상 경우에는 무겁습니다 — 그것이 다음 섹션이 채우는 빈틈입니다.

DynoTable SQL Workbench: DynamoDB의 액세스 패턴 규칙 내의 SQL

DynoTable의 SQL Workbench는 진짜 SQL — JOIN, GROUP BY, COUNT/SUM/AVG — 을 라이브 DynamoDB 테이블에 대해 데스크톱 클라이언트에서 실행하며, 세울 Lambda, Glue, S3가 없습니다. 행을 DynamoDB의 실제 Query/Scan 런타임을 통해 구체화한 다음, 그 위의 인메모리 엔진에서 전체 SQL을 실행합니다:

-- DynoTable Workbench에서 실행됨(PartiQL에서가 아님):
SELECT c.country, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
INNER JOIN customers c ON o.customerId = c.PK
GROUP BY c.country
ORDER BY revenue DESC

"DynamoDB의 액세스 패턴 규칙 내" 부분이 중요합니다. Workbench는 DynamoDB가 Postgres인 척하지 않습니다 — 여전히 그 아래에서 Query/Scan을 통해 읽으므로, 각 쿼리가 무엇을 비용 들이는지 인식한 상태를 유지하며, 액세스 모델을 숨기는 게 아니라 강제합니다:

• INNER JOIN과 LEFT JOIN만 — ON 대상 속성은 파티션 키나 GSI 파티션 키여야 합니다. RIGHT / FULL / CROSS / 콤마 조인은 없습니다.
• 아직 셀프 조인 없음, 서브쿼리 없음, 파생 테이블 없음, 윈도 함수 없음.
• 조인과 프로젝션은 스칼라 속성에 작동합니다.

원시 API를 위한 조건과 키 표현식만 구성하면 되고 — 전체 SQL 문장이 아니라면 — DynamoDB Expression Builder가 PartiQL 표면 없이도 올바른 FilterExpression / KeyConditionExpression을 생성합니다.

테이블을 탐색하고, 디버깅하고, 분석하기 위한 DynamoDB SQL 클라이언트가 목표라면, Workbench가 그 빈틈을 채웁니다 — 그리고 DynoTable의 나머지는 그것을 둘러싼 완전한 DynamoDB GUI입니다.

DynoTable 사용해보기로 여러분의 테이블에 대해 진짜 SQL을 실행하세요.

FAQ

DynamoDB에서 SQL을 실행할 수 있나요? SQL-호환 부분 집합인 PartiQL(키별 SELECT/INSERT/UPDATE/DELETE)을 실행할 수 있습니다. 전체 SQL — JOIN, GROUP BY, 집계 — 에는 그 위에 SQL 엔진이 필요합니다: Amazon Athena DynamoDB 커넥터, 또는 DynoTable의 SQL Workbench.

DynamoDB PartiQL이 JOIN을 지원하나요? 아니요. PartiQL SELECT 구문에는 단일 FROM 테이블 또는 인덱스가 있고 조인 문법이 없습니다. 조인은 DynamoDB 위에 계층화된 엔진이 필요합니다.

PartiQL이 GROUP BY나 COUNT, SUM 같은 집계를 지원하나요? 아니요. GROUP BY 절이 없고, 유일한 "집계" 함수는 SIZE(한 항목에 대한 속성의 바이트 크기)입니다. 행에 걸친 COUNT, SUM, AVG, MIN, MAX는 지원되지 않습니다.

DynamoDB는 SQL인가요 NoSQL인가요? NoSQL — 키-값 및 문서 저장소입니다. PartiQL이 그 위에 SQL-호환 쿼리 언어를 더하지만, DynamoDB에는 관계형 엔진도, 조인도, 집계도 없습니다.

PartiQL은 즉석 쿼리에 좋은가요? 키 기반 조회에는 그렇습니다. 분석적 즉석 쿼리(카운트, 롤업, 조인)에는 아닙니다 — PartiQL이 표현할 수 없고, 제약 없는 SELECT는 조용히 전체 테이블 스캔이 됩니다.

JOIN과 GROUP BY를 처리하는 DynamoDB SQL 클라이언트가 있나요? 예 — DynoTable의 SQL Workbench가 라이브 테이블에 대해 JOIN/GROUP BY/집계를 데스크톱에서 실행하고, Amazon Athena는 AWS 계정에 배포하는 페더레이션 커넥터를 통해 그것을 합니다.