DynamoDB 표현식 빌더
작업을 선택하고 요청을 시각적으로 만든 뒤, ExpressionAttributeNames 및 Values와 함께 올바르고 예약어에 안전한 표현식을 AWS SDK v3, CLI, boto3, PartiQL로 복사하세요.
DynamoDB 표현식을 직접 작성하면 오류가 나기 쉬운 이유
DynamoDB 요청은 눈에 띄는 부분에서 실패하는 경우가 드뭅니다. status가 예약어라 #-별칭이 필요해서, 숫자 id를 문자열로 보내 아무것도 일치하지 않아서, 또는 FilterExpression과 ConditionExpression이 같은 :v0 플레이스홀더를 재사용해서 실패합니다. 각각은 실행은 되지만 잘못된 행을 반환하는 요청을 만드는 작은 실수로 — 디버깅하기 가장 까다로운 종류입니다.
이 빌더는 타입이 지정된 모델로부터 요청 전체를 조립합니다. 모든 속성 이름은 별칭이 지정되고, 모든 값은 명시적인 DynamoDB 타입을 가지며, 키, 필터, 조건, 업데이트 플레이스홀더가 별도의 네임스페이스에 존재하므로 구조적으로 충돌이 불가능합니다. 출력은 타입 태그를 기반으로 만들어지며 텍스트로 추측하지 않으므로 — 숫자는 숫자로, base64 문자열은 바이너리로 유지됩니다.
업데이트 표현식과 조건부 쓰기도 동일하게 처리됩니다. 원자적 카운터, if_not_exists, list_append, 리스트 인덱스에 대한 REMOVE, 세트에 대한 ADD/DELETE, 낙관적 잠금 조건이 모두 하나의 올바른 UpdateExpression과 ConditionExpression으로 조립됩니다. PartiQL 탭은 정직합니다 — 프리미티브에 PartiQL 형식이 없을 때, 조용히 오작동하는 문을 출력하는 대신 어떤 것인지 알려줍니다.
먼저 Query와 Scan 중에서 고민 중이신가요? Query 대 Scan 차이를 설명하며, PartiQL 예제 SQL과 유사한 구문을 깊이 있게 다룹니다.
자주 묻는 질문
ExpressionAttributeName이란 무엇이며, # 와 : 접두사를 쓰는 이유는 무엇인가요?
DynamoDB 표현식은 예약어(name, status, size 등)인 속성 이름을 직접 참조할 수 없으며, 값 플레이스홀더는 실제 데이터를 표현식 문자열 밖에 둡니다. 그래서 모든 속성 이름은 ExpressionAttributeNames에서 #-플레이스홀더로, 모든 값은 ExpressionAttributeValues에서 :-플레이스홀더로 별칭이 지정됩니다. 이 빌더가 그 맵을 대신 생성하므로 예약어가 요청을 망가뜨리는 일은 없습니다.
각 값마다 타입(S, N, B…)을 선택해야 하는 이유는 무엇인가요?
DynamoDB는 속성 수준에서 타입이 지정됩니다. 숫자 5는 { "N": "5" }이고 문자열 "5"는 { "S": "5" }로 — 서로 다른 항목과 일치하는 다른 값입니다. 텍스트 입력으로는 둘을 구분할 수 없으므로 빌더는 각 값에 태그를 붙이도록 요청합니다. 출력되는 SDK, CLI, boto3, PartiQL 결과는 그 태그를 기반으로 만들어지며 텍스트로 추측하지 않으므로, 숫자 id는 숫자로, base64 blob은 바이너리로 유지됩니다.
업데이트 표현식과 조건부 쓰기도 만들 수 있나요?
예. Update는 SET(if_not_exists, 원자적 +/- 카운터, list_append 포함), REMOVE(#a[2] 같은 리스트 인덱스 포함), ADD(숫자 또는 세트), DELETE(세트 멤버)를 다루며 — 하나의 UpdateExpression으로 결합됩니다. 조건부 쓰기는 낙관적 잠금을 위해 Update, Put, Delete에 ConditionExpression(attribute_not_exists, 버전 확인 등)을 추가합니다. 키 조건과 값 조건은 별도의 플레이스홀더 네임스페이스를 사용하므로 절대 충돌하지 않습니다.
PartiQL이 때때로 “표현할 수 없음”인 이유는 무엇인가요?
PartiQL은 대부분의 읽기와 쓰기를 다루지만, 일부 DynamoDB 프리미티브는 PartiQL 형식이 없습니다. 조건부 INSERT, 세트 타입의 ADD/DELETE 업데이트 작업, size(), list_append, if_not_exists 같은 함수가 그렇습니다. 요청이 이 중 하나를 사용하면, PartiQL 탭은 조용히 잘못된 동작을 하는 문을 출력하는 대신 어떤 기능이 표현 불가능한지 정확히 알려줍니다 — 그런 경우에는 SDK, CLI, boto3 출력을 사용하세요.
내 데이터가 브라우저를 벗어나나요?
아니요. 빌더는 전적으로 클라이언트 측에서 실행됩니다 — 표현식과 코드 스니펫을 브라우저에서 생성하며 입력한 내용은 서버로 전송되지 않습니다. URL의 “링크 복사” 기능은 요청을 링크 자체에 직렬화하여 공유하거나 북마크할 수 있게 하지만, 그 데이터는 여러분의 손에 머뭅니다.