DynamoDB

• 0) DynamoDB란?
  • AWS의 완전관리 NoSQL. (대용량, 확장성, 신뢰성, 안정적성능)
  • Hashed Partition-Key 기반의 분산시스템.
  • 이벤트 기반의 AWS Lambda 지원.
• 1-1) 구성요소
  • Table == 로우 집합
  • Item == 로우
  • Attributes == 컬럼
    • Partition-Key : 필수적. (hash 기반에 파티션 단위로 분산)
    • Sort-Key : 선택적. (range 및 sort 쿼리 지원 , 1:N 및 M:N 관계모델링 지원)
• 1-2) 자료형
  • Key-Value형 : String, Number, Binary, StringSet, NumberSet, BinarySet
  • Document형 : Map, List, Null, Boolean
• 1-3) Partition-Key
  • 순서가 없는, 파티션 명시에 반드시 포함 되야 하는 값.
  • (Partition-Key 만 단독 사용) Partition Key = Item 유니크 식별자.
  • 적절한 중복도(Cardinality) 가 확보되지 않으면... 특정 파티션에 HotSpot 장애.
  • equal 쿼리에 적절.
• 1-4) Sort-Key
  • 특정 동일한 파티션의 Item 사이에서, 순서화 할수있는 값.
  • (Partition Key 와 함께 사용) Partition Key + Sort Key = Item 유니크 식별자.
  • 파티션은 3개의 가용영역(AZ)에 중복 저장됨.
  • range 및 sort 쿼리에 적절.
• 1-5) 인덱스
  • LSI(Local Secondary Index)
    • 해당 Table이 저장되는 파티션에 함께 저장됨. (동일한 Partition-Key)
    • 해당 Table의 Sort-Key 외에, 추가적인 Attribute으로 range 및 sort 가 필요한 상황.
    • 마찬가지로 동일한 파티션의 Item 사이에서만, 순서화 가능.
    • 해당 Table 생성시에만 최대 5개 까지 가능. (추후변경불가)
    • 같은 파티션에 있기 떄문에, Eventual Consistency 또는 Strong Consistency 둘다가능.
  • GSI(Global Secondary Index)
    • 별도 Table을 새로 만들어 저장. (별도의 Partition-Key 및 Sort-Key 가능)
    • 기존 Table에, 새로은 PK 및 SK 가 필요한 상황.
    • 비동기방식으로 처리되어, 충분한 '쓰기처리용량(WCU)'가 없으면~ 병목장애.
    • 기존 Table에 최대 5개 까지 추가 및 삭제 가능.
    • 각기다른 파티션에 있기 때문에, Eventual Consistency 만 가능.
      
      • 예) Client <-(수정)-> [기존 Table] <-(async수정)-> [GSI]
      • 분리된 파티션간 강한 일관성을 보장하는것... 힘들다!
• 1-6) 처리용량(CapacityUnit)
  • RCU(Read CU) : 초당 4KB단위의 비용. (강한 일관성시, 두배의 RCU 소비)
  • WCU(Write CU) : 초당 1KB단위의 비용. (당연히, 효율적 집약적 모델링 설계가 필요)
  • https://dev.classmethod.jp/articles/lim-dynamodb-capacity
  • https://jayendrapatil.com/aws-dynamodb-throughput-capacity
• 2) 쿼리방식
  • GetItem : PK를 이용해 Table 하나로 부터 Item을 획득함
  • Query : PK를 고정해두고, SK으로 쿼리 하는 방식
  • Scan : 무조건 full-scan... 비추. RCU가 많이 소모 됨. (Table 또는 Index 전체 Item 을 대상으로 함) 
  • https://www.slideshare.net/AmazonWebServices/design-patterns-using-amazon-dynamodb
  • (참로고 당연히? %Like% Search는 지원 안됨)
• 3) 모델링
  • 예) 서비스 요건으로, user 및 video 및 comments 라는 Entity 정의.
    • 1:1 , 1:N , N:M 모델링
      • ...
    • 한 테이블 모델링
      • user정보 : pk=user_{Id} , sk=user_{Id} // email, nick, ...
      • videa정보 : pk=video_{Id} , sk=video_{Id} // tags, title, ... 
      • comments정보 : pk=video_{Id} , sk=user_{Id} // word, rank, ...
      • GSI추가 : sk를 pk으로 pk를 sk으로 지정하여 생성.
      • (pk+sk 조합으로, 필요한 인덱싱을 구성한뒤~ 나머지 필요한 각기의 att는 마구잡이로 씀)
      • (pk == 특정 video_{Id}으로 쿼리 -> 해당 video정보 + 해당 video의 comments)
      • (sk == 특정 user_{Id}으로 GSI쿼리 -> 해당 user정보 + 해당 user의 전체 video에 comments)
• 4) 집계
  • DynamoDB 자체적으로 제공하는 집계 기능은 없다.
  • 데이터를 쌓아서 몰아 처리.
    • DynomoDB Streams -> RedShift -> 과거데이터 SQL 집계
    • DynomoDB Strams -> HDFS -> 과거데이터 EMR Hive 쿼리 집계
  • Event Trigger으로 그때그때 미리 계산.
    • DynamoDB Streams -> AWS Lambda -> 실시간 Count 및 Avg 집계
• ...

-끝-