DynamoDB 개요

 

DynamoDB란?

---

규모에 상관없이 빠르고 유연한 완전관리형 NoSQL 데이터베이스 서비스

-  AWS에서의 "완전관리형"이란 AWS가 해당 리소스를 사용자 대신 관리해준다는 의미입니다.

- DynamoDB는 서버리스 서비스이기 때문에 관리할 서버가 필요 없고, 용량에 맞게 테이블을 자동으로 확장/축소하는 Auto Scaling 기능을 이용하여 높은 성능을 유지하게 됩니다.

- Auto Scaling 기능을 통해 규모에 상관없이 사실상 무제한의 처리량, 저장 용량을 제공할 수 있습니다. 물론, 백업 및 복원의 기능도 제공을 합니다.

 

 

DynamoDB 주요 개념

---

DynamoDB에서는 데이터를 저장할 때 테이블이라는 개념을 사용합니다.

항목 (Item)

테이블에 Insert, Update, Delete 하게 될 속성들의 집합을 의미합니다. RDBMS(관계형 데이터베이스)에서의 행과 유사한 개념입니다.

 

속성 (Attribute)

항목을 구성하는 각각의 데이터들을 의미합니다. 저장 가능한 데이터 타입은 Amazon DynamoDB 유저가이드에서 참고하실 수 있습니다.

 

파티션 키 (Partition Key)

테이블을 생성할 때 필수적으로 설정을 해야하는 기본 키입니다. 파티션 키는 물리적 공간인 파티션을 특정 하는 키로, 이 파티션 키에 따라서 저장하는 항목들의 분배가 결정이 됩니다. 쉽게 말해 항목들의 주소로서 역할을 하게 됩니다. 이 파티션 키를 사용함으로써 특정 항목을 조회할 때, 테이블 전체를 조회하는 것이 아닌 특정 파티션 키를 가진 항목만 조회할 수 있어 성능을 대폭 향상 시킬 수 있습니다. 이러한 특징 때문에 파티션 키는 고유 값이 많은 속성으로 설정을 하는 것이 좋습니다.(예를 들어, 고객 ID, 디바이스 ID 등)

 

 

정렬 키 (Sort Key)

테이블을 생성할 때 선택적으로 설정할 수 있는 기본 키입니다. 정렬 키는 동일한 파티션 키를 가진 데이터를 정렬할 때 쓰입니다. 정렬 키와 파티션 키를 함께 이용함으로서 <, >, between, contains 등의 연산자를 이용한 범위 검색이 가능해집니다. 예를 들어, DynamoDB를 사용하고 있는 쇼핑몰 사이트가 있다고 가정해봅시다. 사용하고 있는 DynamoDB 테이블의 파티션 키를 고객 ID, 정렬 키를 고객이 물건을 주문한 시간이라고 설정한다면 between 연산자를 이용해 특정 기간 동안 고객이 주문한 물건에 대한 항목들을 검색하는 것이 가능해집니다.

여기서 파티션 키와 정렬 키는 기본 키임으로 생략할 수 없고, 또한 변경을 할 수 없습니다. 

 

 

 

 

 

DynamoDB의 뿌리 NoSQL의 탄생

---

 

- NoSQL에 탄생하기 전까지, 데이터베이스 시스템은 RDBMS (즉, 관계형 데이터베이스) 세상이었다. 스토리지 비용이 비쌌던 시절, 정규화를 통해 중복 데이터를 최대한 줄이는 것이 중요했고, 관계형 데이터베이스는 그것을 수행하기에 최적의 도구였다.

- 즉, 관계형 데이터베이스의 목적은 효율적인 스토리지의 사용이었다.

 

- 그러나, 최근들어 스토리지의 비용이 점차 저렴해지고, 대규모의 연산을 빠르게 처리해내는게 중요해짐에 따라,

데이터가 중복되도 좋으니, 데이터베이스도 빠르게 처리하는 것이 중요한 시대가 되었다.

- 스토리지를 희생하더라도, 성능을 최대한 끌어올리자, 그래서 NoSQL이 나온 것이다.

 

---

몇 가지 DynamoDB의 기본적인 특징

---

 

1. DynamoDB는 HTTP 통신을 한다. 해서, 다른 DB Resource들이 TCP Connection 기반인데 비해, Connectionless 하다.

 

2. AWS Lambda나 AppSync같은 것들이 DynamoDB와 궁합이 찰떡이다.

앞서 언급한 것과 같이 NoSQL의 탄생 목적 자체가 트래픽이 많아져 연산의 속도를 극대화 시켜야 하는 상황이다.

그러한 상황에선 scale-in/out 능력이 중요한데, Lambda나 AppSync도 그 목적에 부합하는 컴퓨팅 리소스이기 때문이다.

(반대로, scale-in/out 능력이 중요한 RDBMS와는 잘 맞지 않다.)

 

3. Key를 제외한 테이블의 Attribute들은 미리 정의 될 필요가 없다. 뭐든 들어갈 수 있다 Flexible하게. 

이런 부분도 미리 Schema가 만들어져 있어야 하는 RDBMS와는 매우 다른 부분이다.

 

4. Key의 구성 방법은 크게 두 가지로 나누어진다.

(1) Simple Primary Key

• Partition Key 하나만을 Primary Key로 쓰는 것이다.

(2) Composite Primary Key

• Partition Key와 Sort Key의 조합으로 Primary Key를 쓰는 것이다.

이 때,  Key를 어떻게 만드냐는(Simple Primary Key로 쓸지, Composite Primary Key로 쓸지),

우리가 데이터를 어떤 상황에서 액세스하는지, 그 유즈케이스를 잘 생각해보고 결정해야 한다.

 

---

DynamoDB에서 데이터를 핸들링 할 수 있는 3가지 방식

---

 

우리가 DynamoDB를 통해 데이터를 처리할 수 있는 방식은 크게 세가지로 나눌 수 있다.

 

1. Item-based actions

DynamoDB에서 Item은 관계형 데이터베이스로 치면 Row에 해당하는 것이다.

Item-based actions에는 Write, Delete, Update이 가능하다.

 

그리고, 하나의 Item을 대상으로 처리를 하는 것이기 때문에, 해당 액션을 하기 위해서는 Primary Key를 제공해야한다.

이 말을 다르게 하면, 한번에 여러 개를 처리 할 수는 없다는 의미이기도 하다. (batch request가 안된다 뜻)

 

 

예를 들어, 아래와 같이 영화 배우 정보(배우, 영화 제목, 배우의 역할, 개봉 연도, 장르) 테이블이 있다고 해보자.

Partition Key는 톰 행크스, Sort Key는 톰 행크스가 출연한 영화라고 했을 때,

"톰행크스가 출연한 모든 영화 삭제해줘" 이런 요청은 불가능하다는 것이다. 아이템 하나하나 처리해줘야한다.

 

 

2. Query

쿼리는 이름에서 풍겨지듯이, 데이터를 읽기 위한 액션이며, Read-only action이다.

한번의 요청으로 여러 개의 아이템들을 처리(fetch) 할 수 있다.

 

 

위의 그림 처럼, "톰 행크스가 출연한 모든 영화 가져와줘" 라고 요청 하는게 가능하다는 것이다.

 

이 때, Partition Key를 제공하는 것은 기본인데. 필요에 따라, Sort Key에다가 세부 조건을 적용할 수도 있다.

그러니까, "톰 행크스의 모든 영화를 가져와줘" 라고 할 수도 있지만,

"톰 행크스의 영화 중에, 알파벳 a~c안에 드는 글자로 시작하는 영화만 가져와줘" 할 수도 있는 것이다.

 

 

3. Scan

관계형 데이터베이스의 스캔과 동일하며, 모든 아이템들을 다보는 기능이다.

 

 

---

DynamoDB의 활용을 극대화 할 수 있는 Secondary Indexes

---

 

만약에 우리가 테이블에 액세스하는 다섯가지의 액세스 패턴이 있다고 했을 때,

기존의 디자인으로, Primary Key (Partition Key only 혹은 Partition Key + Sort Key)를 이용해서, 두 가지는 만족시켰으나

나머지 세 가지의 패턴에 대해서는 만족시키지 못했다면?

 

몽땅 스캔해서 필터링? 그러면, 성능이 처참해질 것이다. 테이블의 사이즈가 커질수록.

이럴 때 쓰라고 DynamoDB에는 Secondary Index가 있다.

 

영화 배우 예시를 다시 한번 보자.

기존과 같은 테이블 구조에서, "Toy Story에 출연한 배우들을 보여줘"라는 액세스 패턴이 추가 될 때,

Query를 통해 가져올 수 있는 방법은 없다.

 

 

이런 상황에서, 아래 처럼 Global Secondary Index(GSI)를 적용하여,

Sort Key 내용을 GSI의 Partition Key로 하고, Partition Key 내용을 GSI의  Sort Key로 한다면,

Query를 통해 Toy Story에 출연한 배우들이 누군지 알 수 있게 된다.

 

 

Secondary Index를 적용하면, 그 형태에 맞는 Primary Key의 새로운 테이블(replicated)이 내부적으로 생겼다고 보면 된다.

 

대신 우리가 직접 테이블을 만들고 관리해 줄 필요없이, 사용자가 데이터를 더하거나 빼거나 수정했을 때,

 

그게 내부적으로 Secondary Index 적용에 의해 만들어진 테이블에 같이 적용되는 것이다.

 

---

관계형 데이터베이스는 잊어라

---

 

DynamoDB 데이터를 모델링 함에 있어서, 관계형 데이터베이스를 모델링 하던 경험은 독이 될 수 있다.

아래의 3가지 특징은 관계형 데이터베이스에서 데이터 모델링을 할 때 고려하는 것들인데,

DynamoDB에서는 이것과 정반대로 간다고 보면 비슷하다.

 

1. Normalization

관계형 데이터베이스에서 중복 데이터를 없애주기 위해썼던 정규화(normalization)는 DynamoDB에 적용하는 것이 거의 불가능하다

왜냐면, 정규화의 핵심은 Join인데, DynamoDB에 Join이라는 개념 자체가 없고, 애플리케이션 레벨에서 구현한다 하더라도 매우 비효율적이기 때문이다. 그래서, DynamoDB에서는 De-normalization을 한다.

 

2. Join

NoSQL 특징을 가진 데이터베이스에서는 불가능하다고 보면된다. 특히, 대용량 데이터의 상황에서 특히나 Expensive하다. 

 

3. One entity type per table

관계형 데이터베이스에는 Entity의 종류나 특성에 따라 테이블을 모두 나누었다. 예를 들어, '영화' 테이블, '배우' 테이블 이런식으로..

그러나 DynamoDB에서는 그런 것들을 모두 하나의 테이블에 표현할 수 있다.

오히려 하나의 테이블에 표현했을 때, Query의 성능이 극대화 된다.

 

참고

AWS의 대표적인 NoSQL 데이터베이스 서비스! Amazon DynamoDB에 입문 해봅시다. | DevelopersIO (classmethod.jp)

AWS의 대표적인 NoSQL 데이터베이스 서비스! Amazon DynamoDB에 입문 해봅시다. | DevelopersIO

https://www.youtube.com/watch?v=DIQVJqiSUkE&feature=youtu.be

60분만에 이해하는 DynamoDB 모델링: DynamoDB Modeling (tistory.com)

60분만에 이해하는 DynamoDB 모델링: DynamoDB Modeling