DynamoDB의 유형 속성

SQL에서 행의 테이블은 해당 유형입니다. — documents의 행은 문서입니다. 에이 DynamoDB 단일 테이블은 하나의 스키마 아래에 모든 엔터티를 혼합하므로 항목에는 아무 것도 포함되지 않습니다. "이게 뭐죠?"에 대한 기본 답변입니다.

Type 속성은 해당 답변을 다시 제공합니다. 모든 항목에 대한 일반 문자열입니다. 그것이 나타내는 엔터티의 이름을 지정합니다.

DynamoDB의 Type 속성이란 무엇입니까?

유형 속성은 항목이 나타내는 엔터티의 이름을 지정하는 EntityType: "Document"과 같이 모든 항목에 스탬프를 찍는 일반 문자열입니다. single table은 하나의 스키마 아래에 많은 엔터티를 혼합하기 때문에 항목에는 기본 제공 유형이 없습니다. 유형은 이를 다시 되돌려 놓으므로 코드가 행을 식별하고 GSI를 하나의 항목으로 필터링하며 마이그레이션 후에도 유지됩니다.

• 쓰기마다 유형을 스탬프 처리합니다. 속성 1개 — EntityType: "Document" — 모든 항목에 예외는 없습니다. 몇 바이트의 비용이 들고 나중에 절약됩니다.
• 혼합 파티션의 엔터티를 식별합니다. Query는 작업 공간을 반환합니다. 문서와 의견을 함께; 유형은 코드에 어떤 것이 있는지 알려줍니다. 키 접두사를 구문 분석하지 않고.
• GSI에 대한 단일 엔터티 필터링을 지원합니다. 유형을 인덱스로 투영합니다. 오버로드된 인덱스를 정확히 하나의 엔터티 유형으로 좁힐 수 있습니다.
• 마이그레이션을 위한 탈출구입니다. 리모델링이나 이동을 위해 내보낼 때 엔터티를 자체 테이블에 추가하는 경우 유형은 분할한 열입니다.

혼합 테이블이 유형을 잃는 이유

Single-table design는 모든 엔터티를 하나에 저장합니다. PK 및 SK와 같은 일반 키 뒤에 있는 테이블입니다. 그게 요점이에요 - 하나 Query은 부모와 그 자식을 함께 반환합니다. 하지만 이는 파티션이 이질적인.

SaaS 문서 협업 앱을 사용해 보세요. 하나의 작업 공간 파티션이 작업 공간을 보유합니다. 기록, 해당 문서 및 해당 문서에 대한 의견:

Query PK = "WS#acme"는 한 번의 청구 읽기로 4개 항목을 모두 돌려드립니다. 이제 당신의 코드에는 원시 항목 목록이 있으며 어느 것이 문서이고 무엇인지 말할 수 있는 신뢰할 수 있는 방법이 없습니다. 이는 주석입니다. SK에 대한 문자열 일치가 부족합니다. 키 형식이 변경되는 순간.

모든 품목에 유형을 스탬프로 찍으세요.

수정 사항은 쓰기마다 하나의 속성으로 엔터티 이름을 지정하는 것입니다.

item.EntityType === "Document"에서의 분기는 안정적인 동등성 검사입니다. SK.startsWith("DOC#") && SK.includes("#CMT#")을 분석하면 추측이 깨집니다. 키를 개정할 때. 유형은 키 인코딩에서 읽기 논리를 분리합니다. 그것이 진정한 승리입니다.

한 번의 읽기는 세 가지 엔터티 유형을 반환합니다. Type 속성은 각 항목을 키를 건드리지 않고 올바른 핸들러.

GSI를 하나의 항목으로 필터링합니다.

유형은 계속해서 색인을 얻습니다. 키가 설정된 GSI를 추가한다고 가정해 보겠습니다. GSI1PK = WS#acme, GSI1SK = updatedAt은 "최근에 변경된 모든 항목을 나열합니다. 이 작업 공간은 최신 항목부터"입니다. 문서에서 과부하된 인덱스 스윕 and 댓글 — 그러나 피드 UI에는 문서만 필요할 수 있습니다.

범위를 좁히는 두 가지 방법, 차이점은 돈입니다.

us-east-1의 온디맨드 시 GSI Query는 2KB에서 100 혼합 항목을 반환합니다. 각 청구서는 대략 100 RCU 최종 일관성을 유지하며 FilterExpression가 청구됩니다. EntityType은 주석을 삭제하기 전에 모든 행을 측정합니다. 희소 인덱스 주석을 색인화하지 않음은 문서 행만 청구합니다. 두 모양을 모두 모델링합니다. pricing calculator.

FilterExpression는 항목을 읽은 후 및 용량이 읽힌 후 실행됩니다. 소비 — AWS는 필터링이 읽기 비용을 줄이지 않는다는 점을 명시적으로 밝혔습니다. (DynamoDB Developer Guide: FilterExpression). 유형 필터링은 무료가 아니라 정직합니다. 버린 댓글에 대한 비용을 지불하면 됩니다.

피드를 문서로 좁히기 위해 쿼리는 유형에 대한 조건을 전달합니다. 속성. FilterExpression, 이름, 값을 다음과 같이 조합합니다. DynamoDB expression builder — 다음을 방출합니다. #t = :doc 자리 표시자를 사용하면 예약어를 무시하지 않아도 됩니다.

KeyConditionExpression     GSI1PK = :ws
FilterExpression           #t = :doc
ExpressionAttributeNames   { "#t": "EntityType" }
ExpressionAttributeValues  { ":ws": "WS#acme", ":doc": "Document" }

인덱스가 문서만 만 전달하고 필터를 완전히 건너뛰기를 원하시나요? 쓰기 문서 항목에만 GSI1PK — sparse index. GSI 키가 없는 항목은 인덱스로 복제되지 않으므로 읽기 작업이 서류 혼자. Type 속성은 작성자에게 어떤 항목이 있는지 알려줍니다. 자격이 있습니다.

값을 안정적이고 특이하게 유지하세요.

값을 한 번 선택하고 열거형으로 처리합니다. Document, 전혀 가끔 Doc 때로는 document — 표류하는 값은 값이 없는 것보다 나쁩니다. 한 케이싱에서는 동등성 검사가 통과되고 다른 케이싱은 자동으로 누락됩니다.

항목당 하나의 유형입니다. 항목이 두 개의 개체처럼 느껴진다면 이는 일반적으로 모델링입니다. 냄새 - 각각 in its own collection or sort-key range씩 두 개의 항목이어야 합니다. 두 개의 모자를 쓰고 한 줄이 아닙니다.

마이그레이션 보상

필요하기 전에 유형을 스탬프 처리하는 이유는 리모델링입니다. 추천하는 리모델링 경로는 내보내기, 변환, 다시 가져오기이며 AWS 문서는 다음으로 대량 내보내기됩니다. 정확히 이런 종류의 오프라인 재구성을 위한 S3 (Exporting DynamoDB to S3).

그날이 오면 Type은 GROUP BY 열이 됩니다. 댓글을 올리고 싶다 자신의 테이블에 저장하거나 내보내기를 엔터티별 파일로 다시 정규화합니다. 분석 창고? EntityType에 덤프를 분할했습니다. 그게 없으면 넌 돌아왔어 수백만 행의 키를 리버스 엔지니어링합니다.

다음 단계

Type 속성은 저렴한 보험입니다. 혼합 읽기에서 엔터티를 식별하고 필터링합니다. 과부하된 GSI를 생성하고 리모델링할 때 깔끔하게 분할됩니다. 글을 쓸 때마다 스탬프를 찍으세요. 첫날부터 — 라이브 테이블에 다시 장착한다는 것은 전체 백필을 의미합니다.

관련 자료: 이 속성이 떠받치는 혼합 파티션 패턴은 single-table design, 희소 인덱스 뒤에 둘 인덱스 모양을 고르는 문제는 GSI vs LSI, 그리고 FilterExpression가 읽기 비용을 결코 아껴 주지 않는 이유는 Query vs Scan에서 다룹니다.

다음을 사용하여 유형에 필터를 구축합니다. DynamoDB expression builder, 그리고 try DynoTable 실제 혼합 개체 테이블을 찾아보고 유형을 확인하세요. 모든 항목에 걸쳐 열이 정렬됩니다.