DynamoDB을 사용하여 간단한 TODO를 만들면서 느낀점을 정리한 글 입니다.

결론을 말하자면 반쪽짜리 DB이다.

하지만 어떻게 최고의 성능을 보장하는 DB라고 생각한다.

그 이유는 DB의 가장 중요한 실행계획이 없다.

보통 mongoDB,Mysql,mariadb에서는 아래와 같은 작업을 실행해 어떻게 쿼리를 실행해야 빠를지 결정을 한다.

이미지 출처 :
http://www.dbguide.net/db.db?cmd=view&boardUid=148208&boardConfigUid=9&categoryUid=216&boardIdx=136&boardStep=1

하지만 Dynamodb는 실행계획을 전적으로 프로그래머한테 책임을 묻는다. 흔히 DB라고 하는거는 실행계획이 꼭 100% 최적화를 보장하지않는다 그래서 RDB같은계열은 실행계획에 힌트를 줄수 있다.

덕분에 스캔과 쿼리가 작동방식이 있으며 LSI,GSI 라는 인덱싱이 존재하는걸 알수있다.

또한 GSI같은 경우 테이블을 하나 더 만든다구 하는 논란이 있는데 이는 DB의 있어서 매우 당연한 작업이다. 다른 DB도 인덱싱을 하기위해 인덱싱용 파일을 따로 만들어서 작업을 한다. 보통
ibd 파일에 데이터와 인덱싱을 넣는다. LSI로만 하면 가장 베스트겠지만 이는 현실에 존재하지않는다고 생각된다.

여튼 이러한 설정도 개발자의 손으로 직접하다보니 설계자체가 어렵게 된다. 또한 더 짜쯩나게 AWS공식문서에는 다음과 같은 문구가 있다.

디자인을 잘하게되면 오직 하나의 테이블만 만든다. 라는 말이다. 나는 이 문구 때문에 아래와 같은 상태가 되어 하루동안 설계에 집중을 하게되었다.

그래서 제 나름대로의 결론을 되었는데 이 문구는 MSA시스템에서는 맞는 말이고, 복잡한경우는 하나의 테이블로 불가능하다는 것이다. 다른분은 어떤지 모르겠다.

또 다른 단점도 존재한다.

aws-sdk로만 작업을 해야한다는 점이다. 메이저한 ORM이 전혀없다. 저같은 경우 sdk를 ORM처럼 아래처럼 비슷하게 만들었다.

ORM이 없다는거는 중규모이상의 프로젝트에 개발생산성이 떨어진다는걸 의미 한다.

또 재미난거는 컬럼의 이름을 예약어로 적으면 큰일난다 해결방법이야 있지만 이거는 이거대로 빡친다.

예로 datatime라는 컬럼을 만들고 해당 컬럼을 datatime 을 아래와 같이 수정해보자.


출처 : https://qiita.com/kei-sato/items/2b7ae81e757f409fde21

위와 같이 에러가 출려된다. 왜냐면 아래의 예약어에 dataTime이라는 문자열이 존재하기 때문이다.

물론 아래와 같이 AWS에 공식페이지에 나오는 ‘:’토큰방식으로 시도해보아도 마찬가지로 에러가 뜬걸 확인할수 있다.

그러면 왜 토큰이있는데…

다시 결론을 이야기하면 작년에 나온 온디멘드 설정 덕분에 서버를 관리를 안해도 되는 수준까지 왔지만 정말 반쪽짜리 DB인샘이다. 만약 개발생산성과 설계의 스트레스를 덜 받고 싶다면 해당 제품을 사용하면 안된다.

다른 DB에 비해 개발자의 숙련도에 의존하는 DB이여서 실사용에는 문제가 많이 발생할거라고 보인다.

마지막으로 DynamoDB을 쓸예정(?)인 분은 다음의 영상을 보시는걸 추천한다.


댓글 남기기

이메일은 공개되지 않습니다. 필수 입력창은 * 로 표시되어 있습니다