반응형


DynamoDB 핵심 구성 요소

DynamoDB 테이블에서, 항목 및 속성은 작업 시 필요한 핵심 구성 요소입니다. 테이블은 항목 집합이고, 각 항목은 속성 집합입니다. DynamoDB는 기본 키를 사용하여 테이블의 각 항목을 고유하게 식별하고 보조 인덱스를 사용하여 보다 유연하게 쿼리를 작성하도록 해 줍니다. DynamoDB 스트림를 사용해서는 DynamoDB 테이블의 데이터 수정 이벤트를 캡처할 수 있습니다.

DynamoDB에 크기 제한이 있습니다. 자세한 내용은 DynamoDB의 제한 값 단원을 참조하십시오.

테이블, 항목 및 속성

다음은 기본 DynamoDB 요소입니다.

  • 테이블 – 다른 데이터베이스 시스템과 마찬가지로 DynamoDB는 데이터를 테이블에 저장합니다. 테이블은 데이터의 집합입니다. 예를 들어, 친구, 가족 또는 기타 관심 있는 사람에 대한 정보를 저장하는 데 사용할 수 있는 People이라는 예제 테이블을 살펴 봅니다. 또한 Cars 테이블에 사람들이 운전하는 차량에 대한 정보를 저장할 수도 있습니다.

  • 항목 - 각 테이블에는 0개 이상의 항목이 있습니다. 항목은 모든 기타 항목 중에서 고유하게 식별할 수 있는 속성들의 집합입니다. People 테이블에서 각 항목은 한 사람을 나타냅니다. Cars 테이블의 경우 각 항목은 차량 한 대를 나타냅니다. DynamoDB의 항목은 여러 가지 면에서 다른 데이터베이스 시스템의 행, 레코드 또는 튜플과 유사합니다. DynamoDB에서는 테이블에 저장할 수 있는 항목의 수에 제한이 없습니다.

  • 속성 – 각 항목은 하나 이상의 속성으로 구성됩니다. 속성은 기본적인 데이터 요소로서 더 이상 나뉠 필요가 없는 것입니다. 예를 들어 People 테이블의 항목에는 PersonIDLastNameFirstName 등의 속성이 있습니다. Department 테이블의 경우 항목에 DepartmentIDNameManager 등의 속성이 있을 수 있습니다. DynamoDB의 속성은 여러 가지 면에서 다른 데이터베이스 시스템의 필드 또는 열과 유사합니다.

다음 다이어그램은 몇 가지 예제 항목과 속성이 있는 People이라는 테이블을 보여 줍니다.






People 테이블에 대해 다음을 알아 두십시오.

  • 테이블의 각 항목에는 항목을 테이블의 다른 모든 항목과 구별해 주는 고유 식별자인 기본 키가 있습니다. People 테이블에서 기본 키는 한 개의 속성(PersonID)으로 구성됩니다.

  • 기본 키를 제외하고, People 테이블에는 스키마가 없습니다. 이는 속성이나 데이터 형식을 미리 정의할 필요가 없음을 의미합니다. 각 항목에는 자체의 고유 속성이 있을 수 있습니다.

  • 대부분의 속성은 스칼라인데, 이는 하나의 값만 가질 수 있다는 의미입니다. 문자열 및 숫자가 스칼라의 일반적인 예입니다.

  • 일부 항목은 내포 속성(Address)을 갖습니다. DynamoDB는 최대 32 수준 깊이까지 내포 속성을 지원합니다.

다음은 음악 파일을 추적하는 데 사용할 수 있는 Music이라는 다른 예제 테이블입니다.

Music 테이블에 대해 다음을 알아 두십시오.

  • Music의 기본 키는 두 개의 속성(Artist 및 SongTitle)으로 구성되어 있습니다. 테이블의 각 항목이 이러한 두 속성을 가지고 있어야 합니다. Artist와 SongTitle의 조합은 테이블의 각 항목을 다른 모든 항목과 구별해 줍니다.

  • 기본 키를 제외하고, Music 테이블에는 스키마가 없습니다. 이는 속성이나 데이터 형식을 미리 정의할 필요가 없음을 의미합니다. 각 항목에는 자체의 고유 속성이 있을 수 있습니다.

  • 항목 중 하나에는 내포 속성(PromotionInfo)이 있는데, 이 속성은 다른 내포 속성을 포함합니다. DynamoDB는 최대 32 수준 깊이까지 내포 속성을 지원합니다.

자세한 내용은 DynamoDB의 테이블 작업 단원을 참조하십시오.

기본 키

테이블을 생성할 때는 테이블 이름 외에도 테이블의 기본 키를 지정해야 합니다. 기본 키는 테이블의 각 항목을 나타내는 고유 식별자입니다. 따라서 두 항목이 동일한 키를 가질 수는 없습니다.

DynamoDB는 두 가지의 기본 키를 지원합니다.

  • 파티션 키 – 파티션 키로 알려진 하나의 속성으로 구성되는 단순 기본 키.

    DynamoDB는 내부 해시 함수에 대한 입력으로 파티션 키 값을 사용합니다. 해시 함수 출력에 따라 항목을 저장할 파티션(DynamoDB 내부의 물리적 스토리지)이 결정됩니다.

    파티션 키로만 구성되어 있는 테이블에서는 어떤 두 개의 테이블 항목도 동일한 파티션 키 값을 가질 수 없습니다.

    테이블, 항목 및 속성에서 설명한 People 테이블은 기본 키(PersonID)가 하나인 테이블의 예입니다. 이 항목에 PersonId 값을 입력하여 People 테이블의 모든 항목에 바로 액세스할 수 있습니다.

  • 파티션 키 및 정렬 키 – 복합 기본 키로 지칭되는 키로, 이 형식의 키는 두 개의 속성으로 구성됩니다. 첫 번째 속성은 파티션 키이고, 두 번째 속성은 정렬 키입니다.

    DynamoDB는 내부 해시 함수에 대한 입력으로 파티션 키 값을 사용합니다. 해시 함수 출력에 따라 항목을 저장할 파티션(DynamoDB 내부의 물리적 스토리지)이 결정됩니다. 파티션 키가 동일한 모든 항목은 정렬 키 값을 기준으로 정렬되어 함께 저장됩니다.

    파티션 키와 정렬 키로 구성되어 있는 테이블에서는 두 개의 항목이 동일한 파티션 키 값을 가질 수 있습니다. 그러나 두 아이템의 정렬 키 값은 달라야 합니다.

    테이블, 항목 및 속성에서 설명한 Music 테이블은 복합 기본 키(Artist 및 SongTitle)가 있는 테이블의 예입니다. 원하는 항목에 Artist 및 SongTitle 값을 입력하고 Music 테이블의 해당 항목에 바로 액세스할 수 있습니다.

    복합 기본 키를 사용하면 보다 유연하게 데이터를 쿼리할 수 있습니다. 예를 들어 Artist 값만 제공하는 경우, DynamoDB는 해당 아티스트의 모든 노래를 검색합니다. Artist 값과 함께 SongTitle 값 범위를 입력하여 특정 아티스트의 노래 중 일부만 검색할 수도 있습니다.

참고

항목의 파티션 키를 해시 속성이라고도 합니다. 해시 속성이라는 용어는 파티션 키 값에 따라 파티션에 데이터 항목을 고르게 분배하는 DynamoDB의 내부 해시 함수를 사용하는 것에서 유래합니다.

항목의 정렬 키를 범위 속성이라고도 합니다. 범위 속성이라는 용어는 DynamoDB가 동일한 파티션 키를 지닌, 물리적으로 상호 근접한 항목들을 정렬 키 값에 의한 정렬 순서로 저장하는 방식에서 유래합니다.

각 기본 키 속성은 스칼라여야 합니다(즉, 단일 값만 가질 수 있음). 기본 키 속성에 허용되는 데이터 형식은 문자열, 숫자 또는 이진수뿐입니다. 다른 키가 아닌 속성에는 이러한 제한이 없습니다.

보조 인덱스

테이블에서 하나 이상의 보조 인덱스를 생성할 수 있습니다. 보조 인덱스는 기본 키에 대한 쿼리는 물론이고 대체 키를 사용하여 테이블 데이터에 대한 쿼리까지 실행할 수 있습니다. DynamoDB는 인덱스를 사용하도록 요구하지는 않으면서도 데이터를 쿼리할 때 애플리케이션에 보다 많은 유연성을 제공합니다. 테이블에서 보조 인덱스를 생성한 후에는 테이블에서 데이터를 읽는 것과 같은 방식으로 인덱스에서 데이터를 읽을 수 있습니다.

DynamoDB는 다음과 같이 두 가지 종류의 인덱스를 지원합니다.

  • Global secondary index – 파티션 키 및 정렬 키가 테이블의 파티션 키 및 정렬 키와 다를 수 있는 인덱스입니다.

  • 로컬 보조 인덱스 – 테이블과 파티션 키는 동일하지만 정렬 키는 다른 인덱스입니다.

테이블당 최대 5개의 글로벌 보조 인덱스 및 5개의 로컬 보조 인덱스를 정의할 수 있습니다

앞에 나온 예제 테이블인 Music 테이블에서는 Artist(파티션 키) 또는 Artist 와 SongTitle(파티션 키 및 정렬 키)을 기준으로 데이터 항목에 대한 쿼리가 가능합니다. Genre및 AlbumTitle로도 데이터를 쿼리하고 싶다면 어떻게 해야 할까요? 그렇게 하려면 Genre 및 AlbumTitle에 대해 인덱스를 생성한 후 Music 테이블을 쿼리한 방법대로 인덱스를 쿼리하면 됩니다.

다음 다이어그램은 Music 테이블과 GenreAlbumTitle이라는 새 인덱스를 보여 줍니다. 인덱스에서 Genre는 파티션 키이고, AlbumTitle은 정렬 키입니다.

GenreAlbumTitle 테이블에 대해 다음을 알아 두십시오.

  • 모든 인덱스는 테이블에 속해 있는데, 이를 인덱스의 기본 테이블이라고 합니다. 앞의 예제에서 GenreAlbumTitle 인덱스의 기본 테이블은 Music입니다.

  • DynamoDB는 인덱스를 자동으로 유지합니다. 기본 테이블의 항목을 추가, 업데이트 또는 삭제하면 DynamoDB는 해당 테이블에 속하는 모든 인덱스의 해당 항목을 추가, 업데이트 또는 삭제합니다.

  • 인덱스를 생성할 때는 기본 테이블에서 인덱스로 복사하거나 프로젝션할 속성을 지정해야 합니다. 적어도 DynamoDB는 기본 테이블의 키 속성을 인덱스로 예상합니다. GenreAlbumTitle의 경우가 그러한데, Music 테이블의 키 속성만 인덱스로 프로젝션됩니다.

GenreAlbumTitle 인덱스를 쿼리하여 특정 장르의 앨범을 모두 찾을 수 있습니다(예: 모든 Rock 앨범). 또한 인덱스를 쿼리하여 특정 앨범 제목이 있는 특정 장르에 속하는 모든 앨범을 찾을 수도 있습니다(예: 제목이 알파벳 H로 시작하는 모든 Country 앨범).

자세한 내용은 보조 인덱스를 사용하여 데이터 액세스 향상 단원을 참조하십시오.

DynamoDB 스트림

DynamoDB 스트림는 DynamoDB 테이블의 데이터 수정 이벤트를 캡처하는 선택적 기능입니다. 이러한 이벤트에 대한 데이터가 이벤트가 발생한 순서대로 거의 실시간으로 스트림에 표시됩니다.

각 이벤트는 스트림 레코드에 의해 나타납니다. 테이블에서 스트림을 설정하면 다음과 같은 이벤트 중 하나가 발생할 때마다 DynamoDB 스트림가 스트림 레코드를 기록합니다.

  • 테이블에 새로운 항목이 추가되면 스트림이 해당 속성을 모두 포함하여 전체 항목의 이미지를 캡처합니다.

  • 항목이 업데이트되면 스트림이 항목에서 수정된 속성의 "사전" 및 "사후" 이미지를 캡처합니다.

  • 테이블에서 항목이 삭제되면 스트림이 항목이 삭제되기 전에 전체 항목의 이미지를 캡처합니다.

각 스트림 레코드에는 또한 테이블의 이름, 이벤트 타임스탬프 및 다른 메타데이터가 포함되어 있습니다. 스트림 레코드의 수명은 24시간이며, 24시간이 지나면 스트림에서 자동으로 제거됩니다.

DynamoDB 스트림와 AWS Lambda를 함께 사용하여 트리거(관심 있는 이벤트가 스트림에 표시될 때마다 자동으로 실행되는 코드)를 만들 수 있습니다. 예를 들어, 회사의 고객 정보가 들어 있는 Customers 테이블을 생각해 볼 수 있습니다. 새 고객마다 "환영" 이메일을 보내려고 한다고 가정해 보십시오. 해당 테이블에 스트림을 설정한 다음, 스트림을 Lambda 함수와 연결할 수 있습니다. Lambda 함수는 새로운 스트림 레코드가 표시될 때마다 실행되지만 Customers 테이블에 추가된 새로운 항목만 처리합니다. EmailAddress 속성이 있는 모든 항목에 대해 Lambda 함수는 Amazon Simple Email Service(Amazon SES)를 호출하여 해당 주소에 이메일을 보냅니다.

참고

이 예제에서 마지막 고객인 Craig Roe는 EmailAddress가 없어 이메일을 받지 못합니다.

트리거뿐만 아니라 DynamoDB 스트림는 AWS 리전 내외에서의 데이터 복제, DynamoDB 테이블의 구체화된 데이터 보기, Kinesis 구체화된 보기를 사용한 데이터 분석 등의 강력한 기능을 제공합니다.

자세한 내용은 DynamoDB 스트림를 사용하여 Table Activity 캡처하기 단원을 참조하십시오.


ref : https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/developerguide/HowItWorks.CoreComponents.html


반응형

'서버(Server) > Aws' 카테고리의 다른 글

ElastiCache 클러스터  (0) 2018.05.18
DynamoDB를 선택하는 잘못된 이유  (0) 2018.05.18
AWS 서비스들의 요약 설명 및 용어  (0) 2018.05.16
AWS Databases (RDS)  (0) 2018.05.16
Network ACL(Access Control List)  (0) 2018.05.15

+ Recent posts