글쓰는 감자

( 참고: https://www.youtube.com/watch?v=I7zcRxHbo98 )

DynamoDB concept 정리

• (Primary key = Partition key + Sort key), 해당 PK로만 쿼리 가능!!
• 제약 조건
  • Scaling
    • 처리량(throughput):
      • RCU: 4KB per second / WCU: 1KB per second (독립적)
      • Eventually Consistent는 Strongly Consistent 보다 RCU를 절반만 사용: 8KB per second
    • 사이즈(size): 
      • Item 최대 크기는 400KB(모두 사용하는 건 비권장)
      • 하나의 item에서 한글자만 바뀌어도 전체 item 다시 씀 → item 한 개의 크기를 작게, 여러개의 item으로 넣자!
    • 파티셔닝(partitioning):
      • 각 파티션은 1000 WCU/sec, 3000 RCU/sec (둘 중 하나가 초과되면 파티션 늘어남)
        • 테이블에 10만 RCU 설정 시 파티션의 구조가 100개로 늘어남
      • 데이터 용량이 10GB 초과 시 파티션 늘어남

DynamoDB에서 데이터 읽는 방법 (REST API)

• GetItem
  • Partition key의 정확한 값 지정
  • 정확히 0 또는 1개의 아이템을 반환
  • 아이템 크기에 따라 RCU 사용
• Query
  • Partition key의 정확한 값 지정
  • 선택적으로 non-key 어트리뷰트에 필터링 조건 추가
  • 일치하는 아이템 반환(여러 개 가능)
  • Key 조건과 일치하는 아이템의 크기에 따라 RCU를 소비하여 단일 결과 반환
• Scan
  • 키가 아닌 어트리뷰트에 대한 필터 조건 지정(필터 표현식과 일치하는 모든 아이템 반환)
  • 1MB 단위로 스캔 가능(리턴 메시지의 토큰 값으로 다음 1MB API 호출 반복)
  • OLTP(On-Line Transaction Processing) 환경에선 사용 못함
    • OLTP: 여러 과정의 연산이 하나의 트랜잭션으로 실행하는 프로세스(정규화 쪽..)
  • On-Line 마이그레이션 때 고민하게 될거다
    • 하나씩 다 옮겨버리면 되는거니까... (단순 작업)
• 대표적인 API 제약 조건
  • Query & Scan: 단일 호출로 최대 1MB 반환, 응답 메시지가 1MB 이상이면 LastEvaluatedKey을 이용해 pagination 가능
  • BatchGetItem: 단일 호출로 최대 100개 아이템 혹은 최대 16MB 반환
    • (API 서버와 DynamoDB 사이에 RoundTrip Time을 줄여 한번에 GetItem을 묶어 실행)
  • BatchWriteItem: 단일 호출로 최대 25 PutItem 혹은 DeleteItem 수행하며 최대 16MB 쓰기

LSI vs GSI

DynamoDB 키 디자인 패턴

Tenet

• 애플리케이션의 usecase가 DynamoDB와 맞는지
  • DynamoDB는 무한대에 가까운 item들 중에서 하나 또는 몇 개의 item을 primary key로 빠르게 찾는걸 잘함
  • 대량의 range 쿼리, fullstacks search, 집계 쿼리 못함
• 테이블 안에 파티션의 개수가 많을수록 애플리케이션의 데이터 액세스가 여러 개의 파티션에서 일어날 확률이 높아짐
  • Hot Partition의 확률이 낮아짐
  • size가 작은 여러 개의 테이블 보단, 하나의 큰 테이블이 장점이 더 많음!
• OLTP여야하고 OLAP의 분석이 필요할 경우 DynamoDB web으로 분석 파이프라인 생성해 워크로드 수행 

디자인 패턴 및 비정규화

• 비정규화
  
  •  " DynamoDB는 무한하게 많은 아이템 중에 하나 혹은 몇 개를 일정한 시간 안에 찾아낸다"
• RDBMS의 경우 데이터 모델 정규화에 대한 노력을 하는데 DynamoDB는 모든 데이터 액세스 패턴을 알고 시작한다.
  
  • RDBMS: 데이터 중복을 최소화하여 정규화된 테이블 간의 조인을 이용해 Ad-hoc하게 런타임의 디스크에서 데이터를 읽어 CPU 연산을 이용해 조인을 수행(과거엔 디스크가 더 비싸... 디스크에 최소의 데이터를 저장하고 런타임의 cpu 리소스를 많이 사용하게끔..)
  • NoSQL: 디스크 가격이 싸져 상황이 역전됨. 조인과 같은 복잡한 연산 불가(결과 셋 형태로 입력이 필요하다...?)

• 간단한 PK 유일 키: 사용자 프로파일, 세션 스토어, 상품 정보

• PK + SK 복합키: 
  • SK(Sort key):
    • 많이 사용되는 값: 알파벳, 숫자, 타임스탬프, ULID/KSUID
    • 오름차순, 내림차순 조회 가능
  • 예제: IoT 로그, 소셜 네트워크의 포스트 리스트, 주문 상세정보 혹은 이력 등

• 노래의 상세 정보만 조회 가능
• begins_with 연산자를 통해 Did로 시작하는 다운로드 이력만 조회 가능
• 쿼리 API를 이용해 PK id 1에 모든 아이템을 한번에 조회 가능

Key 디자인 시 지속적으로 생각할 포인트: 내가 보여줄 UI에 있는 데이터를 그대로 저장하는 것

싱글 테이블 디자인

• 모든 엔티티를 하나의 테이블로 설계하는 방법
• 장점: 적은 운영 부담, 높은 테이블 최대 성능 및 쓰로틀링 줄어들 수 있음
• 단점: 높은 러닝 커브, 시계열이나 다른 액세스 패턴의 엔티티에는 적합하지 않음
• 안티 패턴
  • PK를 UserID로 고정하고 시작하는 습관
    • 일반 사용자와 VIP를 같은 키 디자인으로 해결하려는 습관
    • 대량 트래픽을 유발하는 heavy user를 항상 고민해야함
  • 엔티티 별로 테이블을 만들려는 습관
  • GSI를 많이 사용하려는 습관
• 예시: 이커머스 애플리케이션 디자인
  • 키 디자인 full-cycle
    • 비즈니스 유즈 케이스 이해 → ER 다이어그램 그리기 → 모든 데이터 액세스 패턴 정리 → 키 디자인 시작
  • 비즈니스 유즈 케이스(엔티티 설정)
    • 고객(customer)은 온라인 샵에 방문하고 여러개의 온라인 상품을 둘러보다 여러개의 상품(products) 주문(order)
    • 주문과 연결된 인보이스(invoice)를 기반해 여러 결제수단을 결합해 지불(해당 영상에선 결제 관련 엔티티 다루지 않음)
    • 구매된 상품들은 하나 혹은 여러 곳의 물류 창고(warehouses)에서 픽업되어 고객의 주소로 배송됨(shipped)
  • ERD 그리기(엔티티 연결 관계)
    •  고객(customer)은 여러개 주문(order) 가능 / 주문(order)은 하나의 (invoice) / 주문(order) 안에 여러개의 상품(product) / 상품(product)은 여러개의 주문(order)에 속함
  • 모든 액세스 패턴 정리
    • 어떤 값으로 어떤 데이터를 조회하겠다. 
    • 실제 워크로드의 경우 읽기/쓰기 모두 정리되어야 함
  • 키 디자인 시작하기
    • NoSQL Workbench 다운로드
  • 참고: https://github.com/aws-samples/amazon-dynamodb-design-patterns/tree/master/examples/an-online-shop

❗ 솔직히 겁네 어렵네...?! ❗