DynamoDB 기본개념

Viva의 놀이터·2021년 7월 8일
0

AWS DynamoDB

목록 보기
1/5
post-thumbnail

DynamoDB

AWS DynamoDB는 Nosql 형식의 디비이다. 키-값으로 구성되어 있는 문서 데이터베이스입니다.

DynamoDB를 도입해야하는 이유

  1. 빠른 응답속도
    어떤 규모의 서비스라도 10ms 미만의 응답속도를 자랑한다.

  2. 완전 관리 시스템
    DynamoDB는 알아서 관리가 되는 서비스이다. 스토리지가 가득차면 알아서 늘어나고 트래픽이 늘어나면 성능을 알아서 조절한다. 뿐만 아니라 백업도 알아서 해결해주기 때문에 개발자는 데이터 조작 및 스키마 정의만 신경쓰면 된다.

  3. 저렴한 가격
    DynamoDB의 가격 정책으로는 온디멘드와 프로비저닝이 있다.
    온디멘드: 사용한 만큼 지불한다.
    프로비저닝: 사용할 만큼 미리 지불한다.

    유지비가 저렴하기 때문에 무료 사용량으로 왠만한 서비스는 처리가 가능하다.

DynamoDB 기본 아키텍쳐

테이블

테이블은 여러개의 아이템을 저장할 수 있는 공간이다. 테이블이 커지면 파티션 키를 기준으로 자동으로 여러개의 파티션으로 나뉘어 관리된다.

아이템

저장될 데이터 값을 의미한다. RDB에서는 로우 or 튜플을 의미한다. 아이템의 속성은 "",undefined를 허용하지 않기 때문에 주의해야한다.

데이터 타입

S = String , SS = String Set
N = Number , NS = Number Set
B = Binary , BS = Binary Set

BOOL, NULL, L(List), M(Map) 등의 데이터 타입을 사용 할 수 있다.

인덱스

DynamoDB의 쿼리 검색에 도움을 주는 도구로 'Primary Index'와 'Secondary Index'등이 있다.

DynamoDB에 사용되는 인덱스

파티션 키 (일반적인 PK)

RDB의 PK와 같은 개념이다. DynamoDB에서는 이를 파티션 키라고 부르고 단순 기본키(파티션 키), 복합 기본키(파티션 키 + 정렬 키)로 구분된다.

파티션 키는 Hash key라고 표현되고 0,1 연산만 가능하다(같다, 같지 않다.),

정렬 키는 Range key라고 표현되고 크기 비교, 범위 연산이 가능하다.

Secondary Index(보조 인덱스)

보조 인덱스를 구성하는 파티 션에 따라서 LSI와 GSI로 구분된다.

  • LSI(로컬 보조 인덱스): 테이블의 파티션 키와 같지만 정렬 키가 다름

  • GSI(글로벌 보조 인덱스): 테이블의 파티션 키와 정렬 키 둘다 다름

추가적으로 보조 인덱스는 키가 아닌 속성을 포함 할 수 있는데 이를 프로젝션(Projection)이라고 합니다.

프로젝션의 유형

  • KEYS_ONLY
  • INCLUDE
  • ALL

로컬 보조 인덱스(Local Secondary Index(LSI))

로컬 보조 인덱스 키를 사용하여 동일한 파티션 키 내에서 정보들을 정렬할 때 사용됩니다. LSI는 초기 테이블 생성 할 때 미리 설정해야하고 이후에 수정이나 삭제, 추가가 불가능합니다.

글로벌 보조 인덱스(Global Secondary Index)

기본키(파티션 키)나 정렬 키와는 별개로 인덱스 키로 사용가능한 것을 의미합니다. 로컬 보조 인덱스와 차이점은 추가,수정 및 삭제가 자유롭다는 점입니다.

로컬 보조 인덱스와 글로벌 보조 인덱스의 차이

LSI와 GSI는 비슷하면서도 다른 개념의 key입니다. 결론부터 말하자면 두 개념을 사용하여 쿼리를 검색할 수 있습니다. 그러나 수정은 할 수 없습니다. 수정은 오직 pk만 가능합니다. LSI는 테이블이 생성할 때 생성하고 그 이후의 추가, 수정, 삭제가 불가능합니다. 하지만 GSI는 추가, 수정, 삭제가 자유롭습니다.

예시 테이블 생성

create table

aws dynamodb create-table
	--endpoint-url http:// {localhost:8000} or {https://dynamodb.ap-northeast-2.amazonaws.com} // configure에 설정한 지역값
    --table-name VivaTest //테이블 이름
    --attribute-definitions // 이제부터 속성값을 정의할거야
      AttributeName=name,AttributeType=S //속성값의 이름은 name이고 타입은 String 타입이야
      AttributeName=timestamp, AttributeType=S //속성값의 이름은 timestamp이고 타입은 String 타입이야
      AttributeName=출퇴근상태, AttributeType=S //속성값의 이름은 출퇴근상태이고 타입은 String 타입이야
      AttributeName=컨티션, AttributeType=N //속성값의 이름은 컨티션이고 타입은 Number 타입이야
    --key-schema AttributeName=name,KeyType=Hash //테이블의 pk값은 name야
    --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1
    --global-secondary-index IndexName= 출퇴근상태Index, //글로벌 보조 인덱스 생성 속성값은 출퇴근상태Index
   KeySchema=["{
    AttributeName=출퇴근상태, //글로벌 보조 인덱스'출퇴근상태Index'의 pk키는 출퇴근상태
    KeyType=HASH}",{"
    AttributeName=timestamp, //글로벌 보조 인덱스'출퇴근상태Index'의 정렬 키는 timestamp
    KeyType=RANGE"}],
    Projection="",
    ProvisioinedThroughput="{
    ReadCapacityUnits=1,
    WriteCapacityUnits=1
    }"
    --local-secondary-index IndexName= NameAndCondition, //로컬 보조 인덱스 생성 속성값은 NameAndCondition
   KeySchema=["{
    AttributeName="name", //로컬 보조 인덱스 'NameAndCondition'의 pk값은 'name'
    KeyType=HASH}","{
    AttributeName="Condition", //로컬 보조 인덱스 'NameAndCondition'의 정렬 키는 'Condition'
    KeyType=RANGE}"]
    Projection="",
    ProvisioinedThroughput="{
    ReadCapacityUnits=1,
    WriteCapacityUnits=1
    }"
    
    
    

ex) 출퇴근을 반복하는 테이블을 표현하면

	name = pk
   	timestamp = 정렬키
   	LSI = NameAndCondition
	GSI = 출퇴근상태Index
    
    name	timestamp		출퇴근상태		Condition
    
    viva	2021.07.08.08.03	출근		5
    viva	2021.07.08.18.00	퇴근		3
    viva	2021.07.09.08.30	출근		2
    viva	2021.07.09.19.00	퇴근		1
    
    Lola	2021.07.08.08.03	출근		4
    Lola	2021.07.08.18.00	퇴근		3
    Lola	2021.07.09.08.30	출근		6
    Lola	2021.07.09.19.00	퇴근		7
    
    여기서 viva의 정보를 알고 싶을 때 사용하는 것이 pk=viva,
    viva의 정보를 시간순으로 정렬해서 보고 싶을 때 사용하는 것이 pk=viva, sort key = timestamp
    viva의 정보를 컨티션 순으로 보고 싶을 때 사용하는 것이 NameAndCondition(LSI) = viva
    출근 상태를 시간 순으로 보고 싶을 때 사용하는 것이 출퇴근상태Index(GSI) = 출근
   
   으로 표현될 수 있다.

What is 프로비저닝 모드?

프로비저닝 모드는 애플리케이션에 필요한 초당 읽기 및 쓰기 횟수를 지정합니다. Auto Scaling을 사용하여 트래픽 변경에 따라 테이블의 프로비저닝된 용량을 자동으로 조정할 수 있습니다. DynamoDB 사용을 정의된 요청 속도 이하로 관리하여 비용을 예측하기 편합니다.

프로비저닝 모드가 효율적인 상황

  1. 애플리케이션 트래픽이 예측 가능한 경우
  2. 트래픽이 일관되거나 점진적으로 변화하는 애플리케이션을 실행할 경우
  3. 비용 관리를 위해 용량 요구 사항을 예측할 수 있는 경우

유용한 참고 자료

https://docs.aws.amazon.com/ko_kr/amazondynamodb/latest/APIReference/API_CreateTable.html

profile
역사를 잊은 기술에겐 미래가 없다

0개의 댓글