로컬 보조 인덱스 - Amazon DynamoDB

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

로컬 보조 인덱스

일부 애플리케이션은 기본 테이블의 기본 키만 사용하여 데이터를 쿼리하지만, 대체 정렬 키가 유용한 상황이 있습니다. 애플리케이션에서 정렬 키를 선택할 수 있도록 Amazon DynamoDB 테이블에 하나 이상의 로컬 보조 인덱스를 생성하고Query또는Scan이러한 인덱스에 대한 요청.

시나리오: 로컬 보조 인덱스 사용

예를 들어 DynamoDB 에서 테이블 생성 및 코드 예제에 대한 데이터 로드에 정의된 Thread 테이블을 생각해 봅시다. 이 테이블은 다음과 같은 애플리케이션에 유용합니다.AWS토론 포럼. 다음 그림은 테이블에서 항목을 구성하는 방식을 보여 줍니다. (일부 속성만 표시)


                포럼 이름, 주제, 마지막 게시물 시간, 댓글 수에 대한 목록이 포함되어 있는 스레드 테이블입니다.

DynamoDB 는 동일한 파티션 키 값을 가진 모든 항목을 인접한 방식으로 저장합니다. 이 예에서는 특정 ForumName에 의해 Query 작업으로 해당 포럼의 모든 스레드를 즉시 찾을 있습니다. 동일한 파티션 키 값을 가진 항목 그룹 내에서는 항목이 정렬 키 값을 기준으로 정렬됩니다. 정렬 키 (Subject) 가 쿼리에도 제공된 경우 DynamoDB 는 반환된 결과를 좁힐 수 있습니다. 예를 들어, “S3" 포럼에서Subject문자 “a”로 시작합니다.

일부 요청은 더 복잡한 데이터 액세스 패턴이 필요할 수 있습니다. 예:

  • 보기 및 회신 횟수가 가장 많은 포럼 스레드

  • 특정 포럼에서 메시지 수가 가장 많은 스레드

  • 특정 기간 동안 특정 포럼에 게시된 스레드 수

이러한 질문에 답변하려면 Query 작업으로 충분하지 않습니다. 대신, 전체 테이블을 Scan해야 합니다. 항목이 수백 개인 테이블은 많은 양의 프로비저닝 읽기 처리량을 소비하며 완료되는 데 오랜 시간이 소요됩니다.

하지만, Replies 또는 LastPostDateTime 같이 키가 아닌 속성에 하나 이상의 를 지정할 수 있습니다.

A로컬 보조 인덱스는 지정된 파티션 키 값에 대해 대체 정렬 키를 유지합니다. 로컬 보조 인덱스에는 기본 테이블의 일부 또는 모든 속성의 복사본이 포함되어 있습니다. 테이블을 생성할 때 로컬 보조 인덱스로 프로젝션되는 속성을 지정할 수 있습니다. 로컬 보조 인덱스의 데이터는 기본 테이블과 동일한 파티션 키를 기준으로 구성되지만, 다른 정렬 키를 사용합니다. 따라서 이와 같이 다른 차원에서 데이터 항목을 효율적으로 액세스할 수 있습니다. 쿼리 또는 스캔 유연성을 높이려면 테이블당 최대 5개의 로컬 보조 인덱스를 생성할 수 있습니다.

애플리케이션이 특정 포럼에서 최근 3개월간 게시된 모든 스레드를 찾아야 하는 경우를 가정하겠습니다. 로컬 보조 인덱스가 없으면 응용 프로그램은Scan전체Thread테이블을 만들고 지정된 기간 내에 속하지 않은 게시물을 삭제합니다. 로컬 보조 인덱스를 사용하면Query작업에서 사용할 수 있음LastPostDateTime를 정렬 키로 하고 데이터를 빠르게 찾을 수 있습니다.

다음 다이어그램은 라는 로컬 보조 인덱스를 보여 줍니다.LastPostIndex. 파티션 키는 Thread 테이블과 동일하지만 정렬 키는 LastPostDateTime입니다.


                포럼 이름, 주제 및 마지막 게시물 시간에 대한 목록이 포함되어 있는 LastPostIndex 테이블입니다.

모든 로컬 보조 인덱스는 다음 조건을 충족해야 합니다.

  • 파티션 키는 기본 테이블의 키와 동일합니다.

  • 정렬 키는 정확히 하나의 스칼라 속성으로 구성됩니다.

  • 기본 테이블의 정렬 키가 인덱스로 프로젝션되며, 이 인덱스는 키가 아닌 속성으로 작동합니다.

이 예제에서 파티션 키는ForumName이고 로컬 보조 인덱스의 정렬 키는LastPostDateTime. 또한 기본 테이블의 정렬 키 값(이 예제의 경우 Subject)이 인덱스로 프로젝션되지만 인덱스 키의 부분이 아닙니다. 애플리케이션에 ForumNameLastPostDateTime을 기준으로 하는 목록이 필요할 경우 LastPostIndexQuery 요청을 실행합니다. 쿼리 결과가 LastPostDateTime 기준으로 정렬되고 오름차순 또는 내림차순으로 반환할 수 있습니다. 또한 쿼리는 특정 기간 내 LastPostDateTime이 있는 항목만 반환하는 등의 키 조건을 적용할 수 있습니다.

모든 로컬 보조 인덱스에는 기본 테이블의 파티션 및 정렬 키가 자동적으로 포함되며, 키가 아닌 속성을 인덱스로 프로젝션할 수 있습니다 (선택 사항). 인덱스를 쿼리할 경우 DynamoDB 는 이와 같이 프로젝션된 속성을 효율적으로 가져올 수 있습니다. 로컬 보조 인덱스를 쿼리할 때 쿼리는 특성을 검색할 수도 있습니다.하지인덱스로 프로젝션되지 않습니다. DynamoDB 는 기본 테이블에서 이러한 속성을 자동으로 가져오지만 지연 시간이 길어지고 프로비저닝된 처리량 비용이 높아집니다.

로컬 보조 인덱스는 개별 파티션 키 값당 최대 10GB의 데이터를 저장할 수 있습니다. 이 수치에는 기본 테이블과 인덱스에서 동일한 파티션 키 값을 가진 모든 항목이 포함됩니다. 자세한 내용은 항목 컬렉션 단원을 참조하세요.

속성 프로젝션

LastPostIndex에서 애플리케이션은 ForumNameLastPostDateTime을 쿼리 기준으로 사용할 수 있었습니다. 하지만 추가 속성을 검색하려면 DynamoDB 는 속성 지정을 위해Thread테이블. 이러한 추가 읽기를 가져오기(fetch)라고 하며 쿼리에 필요한 총 할당 처리량이 증가할 수 있습니다.

웹 페이지를 "S3"의 모든 스레드와 각 스레드에 대한 댓글 수 목록으로 채우고, 최근 댓글부터 시작하여 마지막 댓글 날짜/시간을 기준으로 정렬하려는 경우를 가정해 보십시오. 이 목록을 채우려면 다음과 같은 속성이 필요합니다.

  • Subject

  • Replies

  • LastPostDateTime

이 데이터를 쿼리하고 가져오기 작업을 회피하는 가장 효율적인 방법은Replies속성을 테이블에서 로컬 보조 인덱스로 복사합니다.


                포럼 이름, 마지막 게시물 시간, 주제 및 답변에 대한 목록이 포함되어 있는 LastPostIndex 테이블입니다.

프로젝션은 테이블에서 보조 인덱스로 복사되는 속성 집합입니다. 테이블의 파티션 키와 정렬 키는 항상 인덱스로 프로젝션되지만, 다른 속성을 프로젝션하여 애플리케이션의 쿼리 요건을 지원하는 것도 가능합니다. 따라서 인덱스에 쿼리를 실행할 때는 마치 속성이 자체 테이블에 저장되어 있는 것처럼 Amazon DynamoDB가 프로젝션의 모든 속성에 액세스할 수 있습니다.

보조 인덱스를 생성할 때는 인덱스로 프로젝션될 속성을 지정해야 합니다. DynamoDB 는 다음과 같은 세 가지 옵션을 제공합니다.

  • 키 전용— 인덱스의 각 항목은 테이블 파티션 키 및 정렬 키 값, 그리고 인덱스 키 값으로만 구성됩니다. 이KEYS_ONLY옵션은 의 크기를 최소화합니다.

  • 포함— 에 설명된 속성 외에KEYS_ONLY에서 키를 제외한 다른 속성이 지정과 함께 보조 인덱스에 포함됩니다.

  • ALL— 보조 인덱스에 원본 테이블의 모든 속성이 저장됩니다. 모든 테이블 데이터가 인덱스에 복사되기 때문에ALL프로젝션 결과 가능한 최대 보조 인덱스가 생성됩니다.

이전 다이어그램에서는 키가 아닌 Replies 속성이 LastPostIndex로 프로젝션됩니다. 애플리케이션은 전체 Thread 테이블 대신에 LastPostIndex을 쿼리하여 Subject, RepliesLastPostDateTime로 웹 페이지를 채울 수 있습니다. 키가 아닌 다른 속성을 요청할 경우 DynamoDB 는 속성 지정을 위해Thread테이블.

애플리케이션의 관점에서, 기본 테이블에서 추가 속성을 가져오는 작업은 자동으로 수행되므로 애플리케이션 로직을 다시 쓸 필요는 없습니다. 그러나 이와 같은 가져오기 작업을 수행하면 로컬 보조 인덱스를 사용하는 성능 상의 이점이 크게 감소할 수 있습니다.

속성을 로컬 보조 인덱스로 프로젝션하려면 프로비저닝 처리량 비용과 스토리지 비용 간 균형을 고려해야 합니다.

  • 지연 시간이 가장 낮은 몇 개의 속성만 액세스해야 할 경우 해당 속성만 로컬 보조 인덱스로 프로젝션하는 방법을 고려해 볼 수 있습니다. 인덱스가 작을수록 스토리지 비용과 쓰기 비용이 절감됩니다. 간혹 가져와야 하는 속성이 있을 경우 할당 처리량의 비용이 이러한 속성의 장기 저장 비용보다 크게 증가할 수 있습니다.

  • 애플리케이션이 키가 아닌 일부 속성에 빈번하게 액세스할 경우 해당 속성을 로컬 보조 인덱스로 프로젝션하는 방법을 고려해야 합니다. 로컬 보조 인덱스의 추가 스토리지 비용이 빈번한 테이블 스캔 수행으로 발생하는 비용보다 경제적입니다.

  • 키가 아닌 속성의 대부분에 자주 액세스해야 하는 경우 이러한 속성 또는 전체 기본 테이블을 로컬 보조 인덱스로 투영할 수 있습니다. 그러면 가져오기가 필요하지 않으므로 유연성이 극대화되고 프로비저닝된 처리량 소비가 최소화됩니다. 하지만, 모든 속성을 프로젝션하면 스토리지 비용이 최대 2배까지 증가할 수 있습니다.

  • 애플리케이션이 테이블에 빈번하게 쿼리하지 않지만 테이블 데이터에 대해 많은 쓰기 또는 업데이트 작업을 수행해야 할 경우 KEYS_ONLY를 프로젝션할 수 있습니다. 로컬 보조 인덱스는 최소 크기이지만 쿼리 작업에 필요할 경우 계속 사용할 수 있습니다.

로컬 보조 인덱스 생성

테이블에 하나 이상의 로컬 보조 인덱스를 만들려면LocalSecondaryIndexes파라미터CreateTable작업을 사용합니다. 테이블이 생성되면 테이블에 로컬 보조 인덱스가 생성됩니다. 테이블을 삭제할 경우 해당 테이블의 로컬 보조 인덱스도 삭제됩니다.

키가 아닌 하나의 속성을 로컬 보조 인덱스의 정렬 키로 지정해야 합니다. 선택한 속성은 스칼라 String, Number 또는 Binary여야 합니다. 다른 스칼라 유형, 문서 유형 및 집합 유형은 허용되지 않습니다. 데이터 형식에 대한 전체 목록은 데이터 형식 단원을 참조하십시오.

중요

로컬 보조 인덱스가 있는 테이블의 경우 파티션 키 값당 10GB의 크기 한도가 적용됩니다. 하나의 파티션 키 값의 총 크기가 10GB를 초과하지 않는 이상 로컬 보조 인텍스가 있는 테이블은 모든 수의 항목을 저장할 수 있습니다. 자세한 내용은 항목 컬렉션 크기 제한 단원을 참조하세요.

모든 데이터 형식의 속성을 로컬 보조 인덱스로 프로젝션할 수 있습니다. 여기에는 스칼라, 문서, 집합이 포함됩니다. 데이터 형식에 대한 전체 목록은 데이터 형식 단원을 참조하십시오.

로컬 보조 인덱스에서 데이터 읽기

로컬 보조 인덱스에서 항목을 검색할 수 있는QueryScan작업. 이GetItemBatchGetItem로컬 보조 인덱스에 있는 작업을 사용할 수 없습니다.

로컬 보조 인덱스 쿼리

DynamoDB 테이블에서 각 항목에 대한 파티션 키 값과 정렬 키 값의 조합은 고유해야 합니다. 그러나 로컬 보조 인덱스에서 정렬 키 값은 특정 파티션 키 값에 대해 고유하지 않아도 됩니다. 로컬 보조 인덱스에 동일한 정렬 키 값을 가진 항목이 여러 개 있을 경우Query작업은 파티션 키 값이 동일한 모든 항목을 반환합니다. 응답 시 일치하는 항목이 특정 순서로 반환되지 않습니다.

최종 Consistent Read 또는 Strong Consistent Read를 사용하여 로컬 보조 인덱스를 쿼리할 수 원하는 유형의 일관성을 지정하려면 Query 작업의 ConsistentRead 파라미터를 사용합니다. 로컬 보조 인덱스로부터 강력하게 일관된 읽기는 언제나 최신 업데이트 값을 반환합니다. 쿼리가 기본 테이블에서 추가 속성을 가져와야 하는 경우 해당 속성은 인덱스와 일관성을 유지합니다.

특정 포럼의 토론 스레드에서 데이터를 요청하는 Query에서 다음과 같은 데이터가 반환된 경우를 가정해 보십시오.

{ "TableName": "Thread", "IndexName": "LastPostIndex", "ConsistentRead": false, "ProjectionExpression": "Subject, LastPostDateTime, Replies, Tags", "KeyConditionExpression": "ForumName = :v_forum and LastPostDateTime between :v_start and :v_end", "ExpressionAttributeValues": { ":v_start": {"S": "2015-08-31T00:00:00.000Z"}, ":v_end": {"S": "2015-11-31T00:00:00.000Z"}, ":v_forum": {"S": "EC2"} } }

이 쿼리에서

  • DynamoDB 액세스LastPostIndex, 사용ForumName파티션 키를 눌러 “EC2"에 대한 인덱스 항목을 찾습니다. 이 키가 있는 모든 인덱스 항목은 빠른 검색을 위해 인접한 상태로 저장됩니다.

  • 이 포럼 내에서 DynamoDB 는 인덱스를 사용하여 지정된LastPostDateTime조건.

  • 왜냐하면Replies속성이 인덱스로 프로젝션될 경우 DynamoDB 는 추가 프로비저닝 처리량을 소비하지 않고 이 속성을 가져올 수 있습니다.

  • Tags속성이 인덱스로 프로젝션되지 않았으므로 DynamoDB 는Thread테이블을 가져 오고이 속성을 가져 오는 것입니다.

  • 결과가 반환되고, LastPostDateTime을 기준으로 정렬됩니다. 인덱스 항목이 파티션 키 값을 기준으로 정렬된 다음 정렬 키를 기준으로 정렬되고, Query는 저장된 순서로 인덱스 항목을 반환합니다. ScanIndexForward 파라미터를 사용하여 결과를 내림차순으로 정렬할 수 있습니다.

왜냐하면Tags속성이 로컬 보조 인덱스로 프로젝션되지 않는 경우 DynamoDB 는 기본 테이블에서 이 속성을 가져오려면 추가 읽기 용량 유닛을 소비해야 합니다. 이 쿼리를 자주 실행해야 하는 경우에는 기본 테이블에서 가져오기가 되지 않도록 TagsLastPostIndex로 프로젝션해야 합니다. 그러나 가끔씩만 Tags에 액세스해야 하는 경우에는 인덱스에 Tags을 프로젝션하기 위한 추가 스토리지 비용을 지불할 가치가 없을 것입니다.

로컬 보조 인덱스 스캔

다음을 수행할 수 있습니다.Scan로컬 보조 인덱스의 모든 데이터를 검색합니다. 요청에 기본 테이블 이름과 인덱스 이름을 제공해야 합니다. 와 함께Scan를 사용하면 DynamoDB 가 인덱스에 있는 모든 데이터를 읽고 애플리케이션에 반환합니다. 또한 일부 데이터만 반환하고 나머지 데이터를 무시하도록 요청할 수 있습니다. 이와 같이 하려면 Scan API의 FilterExpression 파라미터를 사용합니다. 자세한 내용은 스캔에 대한 필터 표현식 단원을 참조하세요.

항목 읽기 및 로컬 보조 인덱스

DynamoDB 는 자동으로 모든 로컬 보조 인덱스를 관련 기본 테이블과 동기화 상태로 유지합니다. 애플리케이션이 인덱스에 직접 쓰기를 수행하는 경우는 없습니다. 하지만 DynamoDB 가 이러한 인덱스를 유지하는 방식이 어떤 영향을 미치는지 이해하는 것이 중요합니다.

로컬 보조 인덱스를 생성할 때는 인덱스의 정렬 키로 사용할 속성을 지정해야 합니다. 해당 속성의 데이터 형식을 지정합니다. 다시 말해, 기본 테이블에 항목을 쓸 때마다 항목이 인덱스 키 속성을 정의할 경우 해당 형식이 인덱스 키 스키마의 데이터 형식과 일치해야 함을 의미합니다. LastPostIndex의 경우, 인덱스의 LastPostDateTime 정렬 키가 String 데이터 유형으로 정의됩니다. 항목에 항목을 추가하려고 하면Thread테이블에 대한 다른 데이터 유형을 지정LastPostDateTime(예:Number) 을 반환하면 DynamoDB 는ValidationException데이터 형식 불일치로 인해.

기본 테이블의 항목과 로컬 보조 인덱스의 항목이 일대일 관계를 가질 필요는 없습니다. 실제로 이러한 동작은 많은 애플리케이션에서 유리할 수 있습니다.

로컬 보조 인덱스가 많은 테이블은 인덱스가 적은 테이블보다 쓰기 작업에 더 높은 비용이 발생합니다. 자세한 내용은 로컬 보조 인덱스에서 프로비저닝된 처리량 고려 사항 단원을 참조하세요.

중요

로컬 보조 인덱스가 있는 테이블의 경우 파티션 키 값당 10GB의 크기 한도가 적용됩니다. 하나의 파티션 키 값의 총 크기가 10GB를 초과하지 않는 이상 로컬 보조 인텍스가 있는 테이블은 모든 수의 항목을 저장할 수 있습니다. 자세한 내용은 항목 컬렉션 크기 제한 단원을 참조하세요.

로컬 보조 인덱스에서 프로비저닝된 처리량 고려 사항

DynamoDB 에서 테이블을 생성할 경우 해당 테이블에 예상되는 워크로드에 대해 읽기 및 쓰기 용량 단위를 프로비저닝해야 합니다. 이러한 워크로드에는 테이블의 로컬 보조 인덱스에 대한 읽기 및 쓰기 작업이 포함됩니다.

프로비저닝된 처리 능력의 현재 요율을 보려면Amazon DynamoDB 요금.

읽기 용량 유닛

로컬 보조 인덱스를 쿼리할 때 소비되는 읽기 용량 단위의 수는 데이터가 액세스되는 방식에 따라 달라집니다.

테이블 쿼리와 마찬가지로, 인덱스 쿼리는 ConsistentRead값에 따라 최종적으로 일관된 읽기 또는 강력한 일관된 읽기를 사용할 수 있습니다. 하나의 강력한 일관된 읽기(Strongly Consistent Read)는 하나의 읽기 용량 단위를 소비하고 하나의 최종적 일관된 읽기(Eventually Consistent Read)는 그 절반만 소비합니다. 따라서, 최종적 일관된 읽기(Eventually Consistent Read)를 선택할 경우 읽기 용량 단위 요금을 줄일 수 있습니다.

인덱스 키 및 프로젝션된 속성만 요구하는 인덱스 쿼리의 경우 DynamoDB 는 테이블에 대한 쿼리와 같은 방식으로 프로비저닝된 읽기 작업을 계산합니다. 유일한 차이는 기본 테이블 항목의 크기가 아닌 인덱스 항목의 크기를 기준으로 계산이 이루어진다는 점입니다. 읽기 용량 단위의 수는 반환된 모든 항목에서 프로젝션된 모든 속성 크기의 합계입니다. 그런 다음 결과가 다음 KB 경계로 반올림됩니다. DynamoDB 가 프로비저닝된 처리량을 계산하는 방법에 대한 자세한 내용은 단원을 참조하십시오.DynamoDB 프로비저닝된 용량 테이블의 설정 관리.

로컬 보조 인덱스로 프로젝션되지 않은 속성을 읽는 인덱스 쿼리의 경우 DynamoDB 는 인덱스에서 프로젝션된 속성을 읽을 뿐만 아니라 기본 테이블에서 이러한 속성을 가져와야 합니다. 이와 같은 가져오기 작업은 Query 작업의 Select 또는 ProjectionExpression 파라미터에 프로젝션되지 않은 속성을 포함할 때 발생합니다. 가져오기를 수행하면 쿼리 응답이 더욱 지연되며 프로비저닝 처리량 비용도 증가합니다. 위에서 설명한 로컬 보조 인덱스의 읽기 이외에 가져온 모든 기본 테이블 항목에 대해 읽기 용량 단위가 청구됩니다. 이 요금은 요청된 속성뿐만 아니라 테이블에서 각각의 항목 전체를 읽는 데 부과되는 것입니다.

에서 반환된 결과의 최대 크기입니다.Query작업이 1MB입니다. 여기에는 반환된 모든 항목의 속성 이름 및 값의 크기가 포함됩니다. 하지만 로컬 보조 인덱스에 대한 쿼리의 경우 DynamoDB 가 기본 테이블에서 항목 속성을 가져올 경우 결과에 들어 있는 데이터의 최대 크기는 더 작을 수 있습니다. 이 경우 결과 크기는 다음의 합계입니다.

  • 다음 4KB로 반올림한 인덱스에서 일치하는 항목의 크기입니다.

  • 기본 테이블에서 일치하는 각 항목의 크기를 다음 4KB로 개별적으로 반올림한 값

이 수식을 사용하면 쿼리 작업에서 반환한 결과의 최대 크기는 1MB입니다.

예를 들어 각 항목의 크기가 300바이트인 테이블을 가정해 보겠습니다. 이 테이블에 로컬 보조 인덱스가 있지만 각 항목에서 200바이트만 인덱스로 프로젝션되었습니다. 이제 당신이Query이 인덱스를 사용하려면 쿼리가 각 항목에 대한 테이블 가져오기를 요구하고 쿼리가 4개 항목을 반환해야 합니다. DynamoDB 는 다음을 요약합니다.

  • 인덱스에서 일치하는 항목의 크기 200바이트×4개 항목 = 800바이트이며, 이 값은 최대 4KB로 올림됩니다.

  • 기본 테이블에서 일치하는 각 항목의 크기 (300바이트, 최대 4KB까지 올림) × 4개 항목 = 16KB

따라서 결과에 포함된 데이터의 총 크기는 20KB입니다.

쓰기 용량 유닛

테이블에 항목을 추가, 업데이트 또는 삭제하고 로컬 보조 인덱스를 업데이트할 경우 테이블의 할당 쓰기 용량 단위가 소비됩니다. 쓰기에 프로비저닝된 총 처리량 비용은 테이블에 쓰기 작업으로 소비된 쓰기 용량 단위와 로컬 보조 인덱스를 업데이트하여 소비된 쓰기 용량 단위의 합계입니다.

로컬 보조 인덱스에 항목을 쓰는 비용은 몇 가지 요인에 따라 달라집니다.

  • 인덱싱된 속성을 정의하는 테이블에 새 항목을 쓰거나 이전에 정의되지 않은 인덱싱된 속성을 정의하도록 기존 항목을 업데이트하는 경우 항목을 인덱스에 넣으려면 1번의 쓰기 작업이 필요합니다.

  • 테이블을 업데이트하여 인덱스 키 속성 값이 A에서 B로 변경될 경우 두 번의 쓰기, 즉, 인덱스에서 이전 항목을 삭제하는 쓰기와 새 항목을 인덱스에 추가하는 쓰기가 필요합니다. 

  • 항목이 인덱스에 있지만 테이블 쓰기로 인해 인덱스 속성이 삭제된 경우 인덱스에서 기존 항목 프로젝션을 삭제하는 한 번의 쓰기가 필요합니다.

  • 항목이 업데이트되기 전후에 인덱스에 항목이 없을 경우 인덱스에 추가 쓰기 비용이 발생하지 않습니다.

이러한 모든 요인은 인덱스에 있는 각 항목의 크기가 쓰기 용량 단위를 계산하기 위한 1KB항목 크기보다 작거나 같은 경우를 가정합니다. 이보다 큰 인덱스 항목에서는 추가 쓰기 용량 단위가 필요합니다. 쿼리에서 어떤 속성을 반환해야 하는지 고려하고 해당 속성만 인덱스에 프로젝션함으로써 쓰기 비용을 최소화할 수 있습니다.

로컬 보조 인덱스의 스토리지 고려 사항

애플리케이션에서 테이블에 항목을 쓰는 경우 DynamoDB 는 해당 속성이 표시되어야 하는 모든 로컬 보조 인덱스에 올바른 속성 하위 집합을 자동으로 복사합니다. 귀하의AWS계정에는 기본 테이블의 항목 스토리지 비용 및 해당 테이블에 있는 로컬 보조 인덱스의 속성 스토리지 비용이 청구됩니다.

인덱스 항목에서 사용하는 공간의 양은 다음의 합계입니다.

  • 기본 테이블 기본 키(파티션 및 정렬 키)의 크기(바이트)

  • 인덱스 키 속성의 크기(바이트)

  • 프로젝션된 속성(있는 경우)의 크기(바이트)

  • 인덱스 항목당 100바이트의 오버헤드의

로컬 보조 인덱스의 스토리지 요구 사항을 추정하려면 인덱스의 평균 항목 크기를 추정한 다음 기본 테이블에 있는 항목의 수를 곱합니다.

테이블에 특정 속성이 정의되지 않은 항목이 포함되어 있지만 해당 속성이 인덱스 정렬 키로 정의된 경우 DynamoDB 는 해당 항목의 데이터를 인덱스에 쓰지 않습니다.

항목 컬렉션

참고

다음 단원은 로컬 보조 인덱스가 있는 테이블에만 적용됩니다.

DynamoDB 에서항목 모음는 테이블에서 동일한 파티션 키 값과 해당하는 모든 로컬 보조 인덱스를 갖는 항목의 그룹입니다. 이 단원 전반에 사용된 예제에서 Thread 테이블의 파티션 키는 ForumName이며 LastPostIndex의 파티션 키도 ForumName입니다. 동일한 ForumName을 가진 모든 테이블과 인덱스 항목은 동일한 항목 컬렉션에 포함됩니다. 예를 들어Thread테이블 및LastPostIndex로컬 보조 색인, 포럼에 대한 항목 모음이 있습니다.EC2및 포럼에 대한 다른 항목 모음RDS.

다음 그림은 포럼 S3의 항목 컬렉션을 보여 줍니다.

이 그림에서 항목 컬렉션은 ThreadLastPostIndex의 모든 항목으로 구성되어 있으며, 여기에서 ForumName 파티션 키 값은 "S3"입니다. 테이블에 다른 로컬 보조 인덱스가 있을 경우 해당 인덱스에서 ForumName이 "S3"인 모든 항목도 항목 컬렉션에 포함됩니다.

DynamoDB 에서 다음 중 임의 작업을 사용하여 항목 컬렉션에 대한 정보를 반환할 수 있습니다.

  • BatchWriteItem

  • DeleteItem

  • PutItem

  • UpdateItem

각 작업은 ReturnItemCollectionMetrics 파라미터를 지원합니다. 이 파라미터를 SIZE로 설정할 경우 인덱스에 있는 각 항목 컬렉션의 크기에 대한 정보를 볼 수 있습니다.

다음은ReturnItemCollectionMetricsSIZE로 설정한 상태에서 Thread 테이블에서 UpdateItem 작업을 실행하는 출력의 예제입니다. 업데이트된 항목에 ForumName 값 "EC2"가 있으므로 출력에 항목 컬렉션에 대한 정보가 포함됩니다.

{ ItemCollectionMetrics: { ItemCollectionKey: { ForumName: "EC2" }, SizeEstimateRangeGB: [0.0, 1.0] } }

SizeEstimateRangeGB객체는 이 항목 컬렉션의 크기가 0~1GB임을 나타냅니다. DynamoDB 는 이 크기 추정 값을 주기적으로 업데이트하므로 다음에 항목이 수정되면 숫자가 달라질 수 있습니다.

항목 컬렉션 크기 제한

항목 컬렉션의 최대 크기는 10GB입니다. 이 제한은 로컬 보조 인덱스가 없는 테이블에는 적용되지 않습니다. 로컬 보조 인덱스가 하나 이상 있는 테이블만 영향을 받습니다.

항목 컬렉션이 10GB 제한을 초과할 경우 DynamoDB 는ItemCollectionSizeLimitExceededException로 설정하면 항목 컬렉션에 더 이상 항목을 추가하거나 항목 컬렉션에 있는 항목의 크기를 늘릴 수 없습니다. (항목 컬렉션의 크기를 줄이는 읽기 및 쓰기 작업은 계속 할 수 있습니다.) 다른 항목 컬렉션에는 계속 항목을 추가할 수 있습니다.

항목 컬렉션의 크기를 줄이려면 다음 중 하나를 수행합니다.

  • 해당 파티션 키 값이 있는 불필요한 항목을 삭제합니다. 기본 테이블에서 이러한 항목을 삭제하면 DynamoDB 는 동일한 파티션 키 값을 가진 인덱스 항목도 제거합니다.

  • 속성을 제거하거나 속성 크기를 줄여 항목을 업데이트합니다. 이러한 속성이 로컬 보조 인덱스로 프로젝션될 경우 DynamoDB 는 해당 인덱스 항목의 크기를 줄입니다.

  • 동일한 파티션 키와 정렬 키로 새 테이블을 만든 다음 기존 테이블의 항목을 새 테이블로 이동합니다. 이 방법은 테이블에 자주 액세스하지 않는 과거 데이터가 있을 경우 효과적입니다. 또한 Amazon Simple Storage Service (Amazon S3) 에 이 기록 데이터를 보관하는 것도 고려해 볼 수 있습니다.

항목 컬렉션의 총 크기가 10GB 미만으로 감소하면 동일한 파티션 키 값을 가진 항목을 다시 추가할 수 있습니다.

항목 컬렉션의 크기를 모니터링하기 위해 애플리케이션을 활용하는 것이 가장 좋습니다. BatchWriteItem, DeleteItem, PutItem 또는 UpdateItem을 사용할 때마다 ReturnItemCollectionMetrics 파라미터를 SIZE로 설정하는 것이 그중 한 가지 방법입니다. 애플리케이션은 출력에 있는 ReturnItemCollectionMetrics 객체를 조사하고 항목 컬렉션이 사용자 정의 한도(예: 8GB)를 초과할 때마다 오류 메시지를 기록해야 합니다. 한도를 10GB보다 작게 설정할 경우 조기 경고 시스템이 제공되므로 항목 컬렉션이 한도에 가까워지면 미리 조치를 수행할 수 있습니다.

항목 컬렉션 및 파티션

각 항목 컬렉션의 테이블 및 인덱스 데이터는 단일 파티션에 저장됩니다. Thread 테이블 예제에서 동일한 ForumName 속성을 가진 모든 테이블 및 인덱스 항목은 동일한 파티션에 저장됩니다. "S3" 항목 컬렉션과 "EC2", "RDS"가 각각 세 개의 파티션에 따로 저장됩니다.

테이블 데이터가 각각의 파티션 키 값에서 고르게 분산되도록 애플리케이션을 설계해야 합니다. 로컬 보조 인덱스가 있는 테이블의 경우 애플리케이션이 단일 파티션의 단일 항목 컬렉션 내에 읽기 및 쓰기 작업의 "핫스폿"을 만들지 않아야 합니다.