DynamoDB 항목 기반 작업

DynamoDB의 API는 세 가지 제품군, 즉 단일 항목에서 작동하는 항목 기반 작업으로 나뉩니다. 기본 키에 의한 항목, 하나의 파티션 내의 범위를 읽는 쿼리, 모든 것을 읽는 스캔. 이 가이드는 첫 번째 제품군인 4가지 작업입니다. 가장 많이 사용하는 항목: GetItem, PutItem, UpdateItem, DeleteItem. 제일 저렴해요, DynamoDB가 제공하는 가장 빠른 호출을 제공하고 올바른 구별을 얻습니다(특히 Put vs Update) 우발적인 데이터 손실 버그를 방지합니다.

DynamoDB의 항목 기반 작업이란 무엇입니까?

DynamoDB의 항목 기반 작업은 전체 기본 키로 단일 항목에 대해 작동하는 4가지 호출입니다. GetItem는 항목을 읽고, PutItem는 항목을 생성하거나 완전히 대체하고, UpdateItem는 특정 속성을 제자리에서 수정하고, DeleteItem는 항목을 제거합니다. 각각은 정확히 하나의 항목을 다루므로 많은 항목을 읽는 Query and Scan과 달리 가장 빠르고 저렴한 호출이 됩니다.

• GetItem — 전체 기본 키로 하나의 항목을 읽습니다.
• PutItem — 하나의 항목을 만들거나 완전히 교체합니다.
• UpdateItem — 한 항목의 특정 속성을 생성하거나 수정합니다.
• DeleteItem — 전체 기본 키로 항목 하나를 제거합니다.
• 4개 모두 완전한 기본 키가 필요합니다(파티션 키와 정렬 키인 경우) 테이블에는 하나가 있음) — 정확히 하나의 항목을 처리합니다.
• PutItem는 전체 항목을 덮어씁니다. UpdateItem은 수술입니다 — 혼동하는 것은 속성이 자동으로 사라지는 방법.

정의 특성: 하나의 항목, 전체 키

모든 항목 기반 작업은 전체 기본 키로 단일 항목을 대상으로 합니다. 그건 빠르고 저렴한 이유 — DynamoDB는 파티션 키를 해시하고 바로 항목, 완료되었습니다. 필터링도 없고 스캔도 없습니다. 전체 키를 모르는 경우에는 다음이 아닙니다. 올바른 도구; 그게 바로 Query and Scan의 목적이에요.

USER#<id>로 입력된 사용자 계정을 실행한다고 가정해 보겠습니다.

PK: USER#204   email, displayName, plan, createdAt

• USER#204의 GetItem → 해당 사용자가 직접.
• USER#204의 DeleteItem → 해당 사용자를 제거합니다.

둘 다 정확한 키가 필요합니다. 키도 없고 항목 기반 작업도 없습니다.

PutItem 대 UpdateItem — 물어뜯는 것

이것은 내면화할 가치가 있는 구별입니다.

• PutItem는 전체 항목을 씁니다. USER#204이 이미 있고 PutItem인 경우 {email, displayName}만 있으면 기존 plan 및 createdAt 속성은 다음과 같습니다. 사라짐 — 넣기는 전체 항목을 대체하지만 병합되지는 않습니다.
• UpdateItem는 사용자가 지정한 이름만 변경합니다. UpdateItem SET email = …를 사용하면 다른 모든 속성을 그대로 유지하고 항목이 존재하지 않는 경우 항목을 생성합니다(upsert).

경험 법칙: 기존 항목을 변경하려면 UpdateItem에 도달하고, PutItem를 사용하세요. 진심으로 "이 항목을 완전한 새 상태로 기록합니다"를 의미하는 경우에만 가능합니다. 둘 다 PutItem 및 UpdateItem는 condition expression 쓰기를 할 수 있도록 조건부("아직 존재하지 않는 경우에만").

DynoTable의 항목 기반 작업

이러한 작업 뒤에 있는 원시 API 호출을 원하시나요? 표현식과 입력된 값을 조합합니다. DynamoDB expression builder의 지도, 그리고 다음을 사용하여 일반 JSON 항목을 API의 형식 형식으로 변환합니다. DynamoDB JSON converter.

DynoTable에서는 동일한 작업이 시각적입니다. 그리드에서 항목을 열어서 읽을 수 있습니다( GetItem), 속성 편집 및 커밋(UpdateItem), 행 추가 또는 교체(a PutItem) 또는 한 번에 한 항목씩 삭제합니다.

함정과 다음 단계

• PutItem은 전체 항목을 대체합니다 — 항목을 잃지 않고 몇 가지 필드를 변경하려면 휴식을 취하려면 UpdateItem를 사용하세요.
• 전체 기본 키를 알아야 합니다 — 키가 없다는 것은 항목 작업이 아니라 쿼리/스캔을 의미합니다.
• 한 번에 많은 항목이 있습니까? 하나씩 반복하지 마세요 — batch operations 더 적은 왕복 횟수로 접으세요.
• 이전/새 값을 다시 가져와야 합니까? ReturnValues를 설정하세요. 후속 조치 GetItem 대신.
• 관련: query vs scan는 읽기-다 측면을 다룹니다.

API 코드를 한 줄도 작성하지 않고 항목을 읽고, 쓰고, 삭제하고 싶으십니까? Download DynoTable 테이블을 직접 사용하여 작업하세요.

비용: 아이템 1개, 홉 1개

항목 기반 읽기는 DynamoDB에서 가장 저렴하게 주소를 지정할 수 있는 액세스입니다. A GetItem 켜짐 2KB 행은 1 최종 일관성 RCU(1개의 4KB 블록, 반올림됨)를 소비합니다. 위로). 파티션 키를 알고 있기 때문에 동일한 행을 반환하는 Query 정렬 키의 비용은 동일하지만 파티션 키와 애플리케이션 코드를 필터링하면 파티션의 모든 항목에 대해 비용을 지불합니다.

대표 항목을 item-size calculator를 곱한 다음 초당 요청 수 pricing calculator 핫패스 사용시 루프의 GetItem과 잘 맞는 Query.

쓰기에 대한 조건식

PutItem 및 UpdateItem 모두 선택 사항 허용 condition expressions. 일반적인 패턴:

• 풋 시 attribute_not_exists(pk) - 레이스 없이 생성 전용 인서트입니다.
• 업데이트 시 attribute_exists(pk) — 실수로 스텁 생성을 거부합니다.
• 업데이트 시 plan = :old — 낙관적 동시성; 다른 작성자가 있으면 다시 시도하세요. 계획을 먼저 바꿨다.

DeleteItem도 조건을 지원합니다. status = :closed인 경우에만 삭제하세요. 예. 조건은 별도의 읽기 요금을 추가하지 않습니다. DynamoDB가 이를 평가합니다. 쓰기 시도 중 저장된 항목에 대해

시각적으로 조건을 구축합니다. DynamoDB expression builder; 복사하다 ConditionExpression 더하기 ExpressionAttributeNames 및 ExpressionAttributeValues를 SDK 호출에 추가합니다.

멱등성 및 덮어쓰기 안전성

조건이 없는 PutItem은 전체 항목에서 마지막 작가-승리입니다. 웹훅의 경우 핸들러 또는 SQS 소비자, 처리된 풋에 attribute_not_exists가 있는 페어 풋 마커 속성을 사용하거나 SET processed = :true와 함께 UpdateItem를 사용하세요. attribute_not_exists(processed).

감사 로그에 대한 이전 속성 값이 필요한 경우 다음을 추가하세요. 선행 GetItem 대신 같은 UpdateItem에 ReturnValues를 추가하세요 — 1회 왕복이면 되고 읽기/쓰기 경합도 없습니다.

올바른 항목 작업 선택

DynoTable에서 쓰기 스테이징

DynoTable은 커밋하기 전에 로컬로 UpdateItem 및 PutItem 단계를 수행합니다. 당신은 검토 속성 차이를 확인하고 선택적 PartiQL 검사를 실행한 다음 커밋합니다. 위의 실제 API 호출. 대량 행에서 일괄 삭제 BatchWriteItem으로 내부적으로 묶이며, 처리되지 않은 항목에 대해서는 재시도합니다.

SDK 코드 생성을 위해 업데이트 절을 다음에서 조합합니다. expression builder 및 방출된 내용을 붙여넣습니다. 핸들러 테스트 옆에 있는 SDK v3 스니펫.