• AWS의 완전관리형 NoSQL 데이터베이스, DDB라고도 부름
• 키, 값 구조라 파티션 키로 찾는 조회는 데이터가 아무리 커져도 응답 시간이 일정함, 대신 RDB처럼 자유로운 조회는 못 함
• 용량 모드는 둘로 나뉘고 트래픽 패턴에 따라 비용 차이가 큼
  • 온디맨드 : 요청한 만큼 과금, 예측이 어렵거나 들쭉날쭉한 트래픽에 적합
  • 프로비저닝 : 초당 읽기, 쓰기 용량을 미리 잡고 오토스케일링을 붙임, 꾸준한 트래픽이면 더 저렴함

특징

• 쿼리에 Order By 구문을 쓸 수 없고, 정렬은 테이블을 만들 때 잡은 Sort Key 순서로만 됨, 방향만 ScanIndexForward로 뒤집음
  • 조회 패턴을 먼저 정한 뒤 키를 설계해야 함, RDB처럼 나중에 쿼리를 바꿔 대응하기 어려움
• 기본 Partition Key 외에 보조 Index로 조회 경로를 늘릴 수 있음

  • LSI : Local Secondary Index, 같은 파티션 키 안에서 다른 정렬 키를 쓰는 인덱스, RDB의 복합키와 비슷한 역할

    • 테이블 생성 시점에만 만들 수 있고 나중에 추가, 삭제가 안 됨, 파티션 키 하나당 10GB 제한도 걸림

    

    • 위 예시로 ForumName이 PK, Subject가 SortKey라 가정하면, LSI는 동일한 PK값들 하에서만 인덱스 역할을 함
      • 여기선 S3인 PK에 한해 Subject가 a,b,c,d 인 값들로 LSI 쿼리를 수행함

  • GSI : Global Secondary Index, 파티션 키와 무관하게 테이블 전체에 거는 인덱스임

    • 사실상 별도 테이블이라 용량과 비용이 따로 붙고, 읽기는 최종 일관성만 지원함, 대신 나중에 추가, 삭제가 자유로움
    • 블록체인을 예시로 든다면, 특정 Hash 값을 GSI로 잡아 각 Hash들이 인덱스 값으로써 쿼리로 확인할 수 있게 되는 것
• 범위 조회는 같은 파티션 키 안에서 Sort Key에 대해서만 됨, Range Key는 Sort Key의 예전 이름이라 별도 기능이 아니었음
  • 파티션 키를 모르는 조건으로 범위를 훑으려면 GSI를 따로 두거나 Scan을 돌려야 하고, 둘 다 용량과 비용이 추가로 붙음
• PITR을 켜두면 최근 35일 안의 임의 시점으로 복구할 수 있음, 기본값이 꺼짐이라 운영 테이블은 만들 때 켜두는 편이 안전함
  • 복구는 새 테이블로 만들어지는 방식이라 애플리케이션이 보는 테이블명을 바꾸는 절차까지 같이 생각해둘 것

쿼리

• 데이터를 탐색하는데 DDB에서 어떻게 쿼리를 해야할지 모르겠다면 아래 그림을 참고할 것
• Query는 파티션 키를 지정해 해당 파티션만 읽고, Scan은 테이블 전체를 읽은 뒤 걸러냄
  • 필터를 걸어도 걸러지기 전에 읽은 만큼 과금되므로, 운영 테이블에 Scan을 돌리는 건 피해야 함

CLI 쿼리 예시

• cli 쿼리를 수행하려면 AWS CLI를 따로 설치해야 함
• 아래 --scan-filter는 예전 파라미터라 지금은 --filter-expression과 --expression-attribute-values 조합을 씀
• 특정 컬럼값의 필터링 스캔 예시

aws dynamodb scan --table-name {{테이블명}} --scan-filter '{ "{{컬럼명}}": { "AttributeValueList": [{"S": "2021-02-"}], "ComparisonOperator": "CONTAINS" } }'
aws dynamodb scan --table-name {{테이블명}} --scan-filter '{ "{{컬럼명}}": { "AttributeValueList": [{"S": "hgwt"}], "ComparisonOperator": "EQ" } }'