October 18, 2018 6 min to read

DynamoDB에 대해서 알아보자 - 1

AWS의 full-managed 제품에 심취해있는 drakejin. 이번에는 DynamoDB에 대해서 파해쳐보자!

주의

이 블로그의 내용은 대단히 주관적인 내용이 가득합니다. 그리고 양질의 글을 읽었지만 똥글이 나오는건 제 미숙함 때문입니다. 그럼에도 불구하고 피드백 많이 주신다면 자세히 조사하여 반영하도록 하겠습니다. 또한.. 가능한 링크로 올려놓은 자료들은 반드시 열어보시기 바랍니다. 분명 도움이 될 것입니다. (- -)(_ _)

이 글을 읽기전에

글을 읽는 대상인 독자님들은 RDBMS의 서비스를 경험해 보았다는것을 기본 전제로 합니다. 또한, mongoDB를 약간이나마 경험해보았다면 더 없이 좋습니다. 하지만, 그렇다 하더라도 자세하게 설명하도록 노력해보겠습니다. 이해가 안되는 부분이 있다면 언제든지 지적해주세요!

RDBMS와 NoSQL이란?

참고자료 - 먼저 읽고 보면 좋아요! https://dzone.com/articles/sql-vs-nosql

RDBMS, 내 멋대로 정의

data는 data들 간에 서로 관계를 가지고 있으며, 저장시에 data들 간의 관계를 함께 저장한다. 그리고 데이터들의 관계를 이용하여 목적에 부합하는 여러 format의 데이터를 출력할 수 있게 한다. 이는 데이터의 활용(서비스)에 좀 더 초점을 맞추었으며, 관계를 이용한 데이터의 정형, 무결을 유지하여 신뢰있는 저장소를 목표로 한다.

NoSQL, 내 멋대로 정의

data는 data 그저 데이터이며, RDBMS처럼 신뢰있는 저장소가 목표가 아닌, 빠르게 정보를 수집하고 소비할 수 있는 환경을 제공함에 있다. 그렇기 때문에 정형, 무결과는 거리가 멀며, dynamic 한 데이터들에 대해서 수용할 수 있는 환경을 제공한다. 이는 dynamic한 data들에 대한 저장, 소비에 초점을 맞추었으며 data의 빠른 저장 자체를 목표로 한다.

RDBMS와 NoSQL의 가장 큰 차이 대표적인 가장 큰 차이는 속성에 대한 자유도이다. NoSQL은 Schema가 자유롭다는 이야기는 이미 많이 들었을 것이다. 하지만 엄밀히 말해서 자유로운것은 속성(Attribute, Column)에 대한 내용 뿐이지, 모든것이 자유롭지는 않다. 우리는 개발자이고 성능을 고려하는 사람들이기 때문에, Bad Case와 Best Practice를 염두하며 작업을 한다. 때문에 NoSQL 패러다임을 따르고 있는 DATABASE 프로그램을 이용하며 ‘아 자유롭다’라고 느낀 사람이 있다면, 바지를 입고있는지 벗고 있는지부터 확인해봐야할 필요성이있다. (우리 무릎을 맞대고 같이 다시 생각해봐요. 우린 자유롭지 않았을거에요. 자유로웠다면 당신은 재택근무를 하고 있거나 잠시 일을 쉬고있었거나 아니면 알려지지 않은 은둔의 엄청난 천재일 수 도 있어요. 만약 천재시라면 그 지능 저에게 1%만 기부해주세요…)

NoSQL에 대한 오해

1. nosql의 스키마는 자유로워 -> nosql은 속성만 자유로워

nosql은 흔히들 데이터의 저장 형태가 정해져있지 않은 데이터베이스로 알고있다. 그리고 흔히들 firebase의 datastore, mongoDB로 쉽게 nosql을 접한다. 하지만 접하기 전에 nosql을 쓴다면 데이터의 저장을 이렇게 해야지 저렇게 해야지 라며 뇌내 망상에서 이런 스키마를 만들어내고 만다.

data = {
  [asdf-72j1-3j41...]: { name, age, job, status },
  [1f23-52j5-3ab1...]: { name, age, job, status },
  [6jfc-32j2-3jb1...]: { name, age, job, status },
  [qwdf-12j3-3123...]: { name, age, job, status },
  [grvs-71j5-3653...]: { name, age, job, status },
}

이는 내 친구의 이야기다.(zynkn! 네 이야기이다! 이 바보야!) 당연한 이야기지만 프로그래밍에는 정답은 없다. 하지만 best practice, bad practice는 있다. 그리고 이것은 결코 best practice는 아니며, 권장 사항도 아니다.(바보같은 설계! 그러니까 내가! nosql프로그램에서 기능과 내장함수들이 무엇이 있는지 먼저 보라했잖아! 청개구리같은 자식) nosql DB 프로그램들에서 제공하는 기능을 무시한채 설계가 나오면 위와 같이 하나의 저장소를 array가 아닌 map으로 만들게 된다. 사실 저러는게 쿼리문 만들 필요 없이 root data하나 긁으면 되니까. 초기에는 저게 편할 수 있겠지만, Condition Expression 또는 Query문이 조금이라도 복잡해진다면, 금방 폐기할 설계가 되어버린다.

명심하자 nosql은 저장할 스키마 자체의 형태가 없다는게 아니다. 속성에 대한 추가와 변경이 자유롭다는 것이다.

document (mongoDB에서는 collection 또는 document, 그리고 dynamodb에서는 table, RDBMS에서도 table 이라 하지만 무튼)을 Array의 형태가 아닌 Map으로 설계를 해버릴 수 있다.

data = [
  { id, name, age, job, status },
  { id, name, age, job, status },
  { id, name, age, job, status },
  { id, name, age, job, status },
  { id, name, age, job, status },
  { id, name, age, job, status },
]

1. nosql은 빠르다. 그리고 RDBMS는 nosql에 비해 느리다.

나는 nosql이 빠르다는것은 인정할 수 없다. nosql이 RDBMS보다 상대적으로 빠르다고 하는 부분은 바로 insertion에 대한 이야기가 주를 이루는데, RDBMS가 관계를 가진채로 저장이 되어야 하기 때문에 관계를 갖도록 유지하기위해 여러 테이블에 여러 행들을 넣어주기 때문에 느리다는 것이다.

하지만 이야기를 조금더 바꿔보자. RDBMS 하나의 테이블 그리고 NoSQL에서 document에 저장 한 번의 속도는 과연 누가 더 빠를까? 그리고 bulk로 insert 20만건을 해보았을 때 누가 더 빨랐을까? 더 나아가서 RDBMS에서 index와 primary key가 미 지정인 상태에서 insertion을 수행하면 과연 누가 더 빨랐을까?

과연 RDBMS는 느릴까?

No. RDBMS는 빠르다. 빠르다구요. 빨라요.

참고자료

• 참고자료 1 - 한달에 30억개의 데이터셋을 저장해야하는데 어떤 저장소가 좋아?: 가장 많은 답변이 참고
• 참고자료 2 - 만약 네 블로그 포스팅에 덧글을 다는 상황을 시뮬레이션 해보자. 그랬을때 nosql이 빠른 이유를 알려줄게
• 참고자료 3 - Couch DB(NoSQL) VS Aurora MySQLHBSmith의 매주 40억건의 데이터 집어넣기 ppt의 8번째 페이지: 결국 RDBMS를 선택’

NoSQL DB 어떤것을 선택해야 할까?

내가 DynamoDB를 공부하려는 이유

fullmanaged 환경의 Database를 맛보기위해, nosql이 궁금하기 때문에는 아니다. 단지 full-managed환경에 꽂혔을 뿐이다. 훨씬 재미있어 보인다. fullmanaged환경이기 때문에 동작이나 페러다임도 다를거라 생각했었다. 그리고 불안한 예상은 빚나가질 않고 적중했다. 나에게는 러닝커브가 겁나게 깊었다.

DynamoDB 간단 소개

dynamodb는 nosql 데이터베이스 입니다. 하지만 기본키가 있으며, indexing과 key 설정이 매우 중요합니다. 설계와 경우에 따라 검색을 할 수 없거나 성능이 매우 나쁜 상태로 쿼리를 보내게 되는 경우가 있습니다. 그렇다고 RDBMS에서 사용하던대로 key 설정을 잡았다가 아주 큰 낭패를 보게 됩니다. 근본적으로 RDBMS의 key하고 DynamoDB의 key설정은 전혀 다르기 때문입니다.

DynamoDB는 mongoDB와 같이 nosql이지만 partition key(mongodb에서는 shard key 라고 합니다.)가 존재합니다. 하지만 내부 동작 방식이 달라, row들의 유일한 값(RDBMS의 primary key 처럼)을 지정하는데 쓰이기도 합니다.

RDBMS에서도 partitioning이라는 기능이 있지만 DynamoDB에서 partition key는 공식 문서 best practice(Uniformity 가 Good인 부분의 사례)에서 언급했다 시피 RDBMS의 primary key같은 유일한 값을 partition key로 설정해도 괜찮다고 합니다.

네 이해가 안되시죠?

하나만 알고 넘어가시면 됩니다.

DynamoDB는 RDBMS처럼 key관리와 indexing이 중요하지만 nosql이다. nosql이지만 MongoDB와는 내부 동작방식이 다르다. 그냥 nosql 인것만 알아도 충분하다.

즉 그냥 기존에 알고있던것들과는 다르다. 그러니 새로 공부하자

DynamoDB의 장단점

간단하게 DynamoDB의 장점

full-managed

이거 하나면 충분합니다. 사실 이거 하나 때문에 공부해보는 것입니다.

• 클러스터링, 백업정책, 성능상향, 다중리젼 지원
• AWS라는 기업에서 운영하는 serverless 플랫폼의 DB이며, 운영하다 장애가 발생하는 날에는 AWS support의 도움으로 어떻게든 문제를 해결 할 수 있습니다.(영어 필수…)
• 오픈소스의 인프라보다 기업의 확실한 인프라 서비스에 고객감동을 먹을 수 있습니다.

간단하게 DynamoDB의 단점

단점……… 한 페이지로 이 모든 단점들에 대해 말할 순 없습니다.

• ORM 지원 라이브러리도 없고, 있다 하더라도 메이저하지도 않아서 쓰기에 불안합니다.
• 이런 상태에서 분량이 큰 REST API 서비스를 만들기라도 하는 날에는 nosql쿼리 코드를 관리하는 관리 전략이 필수요소가 될겁니다.
• 대부분의 nosql들이 가지고 있는 단점으로 여러 쿼리에 대해 일관성, 원자성을 보장하지 않는다. 즉, Transaction 이 없다. 전략으로 때워야 합니다.
• 제법 깊은 러닝커브 …. 무시 못합니다. 저희가 기존에 알고있던 RDBMS와 MongoDB의 혼종으로 생각하고 있다면 정말 크나큰 화를 입게 됩니다.

후기

다시 읽고나서 거울을 본 내 표정

다음 내용은 DynamoDB에서 제공하는 특별한 기능과 서비스 그리고 한계에 대해서 알아보겠습니다.