Recoding & Share Devlog

DynamoDB Stream DynamoDB 테이블에서 일어나는 일들(삽입, 수정, 삭제 등)이 일어날 시 시간적 순서에 맞게 Streams에 기록 Log는 즉각 암호화가 일어나며 24시간동안 보관됨 → 24시간 후 로그 소멸 주로 이벤트를 기록하고 이벤트 발생을 외부로 알리는 용도 (예시 : Lambda Function) 이벤트 전&후에 대한 상황 보관 (24시간 유효) 어플리케이션이 2개의 AWS SDK와 연동이 되어있다고 가정할때 한가지 예시로는 DynamoDB API며 직접 소통하며 하나의 고유한 Endpoint와 연결 하나의 API는 하나의 EndPoint와 연결이 된다 라고 볼 수 있다. ex) 쇼핑몰을 운영한다 할때, 고객이 물건을 구매할 때 이벤트로 인식하여 람다함수가 실행 SNS로 메세지..

DynamoDB Accelerator (DAX) 다이나모 디비에서 제공하는 클러스터 In-memory 캐시 10배 이상의 속도 향상 읽기 요청만 해당사항 (쓰기 요청x) 읽기 요청이 많거나 그 크기가 많을 때 사용 EX) 블랙프라이데이 → 쇼핑 웹사이트 운영 (수많은 읽기 요청 예상) DAX 원리 DAX 캐싱 시스템 테이블에 데이터 삽입 & 업데이트 시 DAX 에도 반영 읽기 요청에 맞는 데이터가 DAX 에 들어있을 시 DAX에서 데이터 즉시 반환 (Cache Hit) ↔ (Cache Miss) DAX의 단점 쓰기 요청이 많은 어플리케이션에서는 부적절함 기 요청이 많지 않은 어플리케이션에 부적절함 아직 모든 지역에서 제공하지 않음

데이터를 불러오는 두가지 방법 Query, Scan Query Primary Key를 사용하여 데이터 검색 Query 사용시 모든 데이터(컬럼) 반환 ProjectionExpression 파라미터 Scan 모든 데이터를 불러옴 (primary key 사용 X) 따로 필터를 추가 하여 원하는 데이터를 볼 수 는있다. (쿼리와 가장 큰차이) 쿼리는 이미 파티션이 적용되는 반면에 스캔은 그렇지 않다. ProjectionExpression 파라미터 Query VS Scan Query가 Scan보다 훨씬 효율적인 따라서, Query 사용 추천 데이터의 크기가 일정하지 않아 테이블의 크기가 계속 커진다면 Scan의 퍼포먼스는 악화된다. 다만, Scan을 사용하면서 보완할 수 있는 스킬이 있다. 순차적 방법 병행 스..

Index 특정 컬럼만을 사용하여 쿼리 테이블 전체가 아닌 기준점(pivot)을 사용해 쿼리가 이루어짐 매우 큰 쿼리 성능 효과 두가지의 Index 유형 존재 Local Secondary Index Global Secondary Index Local Secondary Index (LSI) 테이블 생성시에만 정의해줄 수 있음 따라서 테이블 생성 후 변경, 삭제가 불가능 똑같은 파티션키 사용, 그러나 다른 정렬키 사용 → 전혀 다른 뷰를 만들어 줄 수 있음 시간을 정렬키로 정의한다면 쿼리속도가 빨라짐 Global Secondary Index (GSI) 테이블 생성후에도 추가, 변경, 삭제 가능 다른 파티션키, 정렬키 사용 → 완전히 다른 뷰를 만들어줄 수 있음 뷰를 만든다 → 뷰가 복제가 된다. 뷰에서 데이..

DynamoDB NoSQL(Not Only SQL) 데이터베이스 매우 빠른 쿼리속도 Auto-Scaling 긴능 탑재 → 데이터의 크기가 커질 수록 테이블의 크기가 알아서 조정 (비용관리에 좋다) Key-Value 데이터 모델 지원 테이블 생성시 스키마 생성이 필요 없음 → 데이터가 들어올 때 알아서 스키마를 생성함 모바일, 웹, IoT 데이터 사용시 추천됨 → 실시간으로 들어오는 데이터를 관리할때 매우 좋음 SSD 스토리지 사용 → 따라서, 읽고 쓰기가 매우 빠름 테이블(Table) 로 구성되어있음 내부에는 아이템(items) - 행(row)과 개념이 비슷하다. 특징(Attributes) - 열(column)과 개념이 비슷하다. Key-Value (key : 데이터의 이름, Value : 데이터 자체)..