DynamoDB 공부+ 실사용하면서 느낀점

회사에서 신규서비스를 만들때 서버리스아키텍쳐를 도입하게되었는데, 그중 데이터베이스는 DynamoDB 를 쓰게되었다. 몇달간 사용해보면서 굉장히 많은 시행착오를 겪었다. 아래는 사용하면서 느낀점들이다.

Amazon DynamoDB는 어떤 규모에서도 10밀리초 미만의 성능을 제공하는 키-값 및 문서 데이터베이스입니다

일단 DynamoDB는 NOSQL이다. 학창시절부터 지금까지 몇번 사용해본 MySQL, postgreSQL, mariaDB같은 RDBMS와 너무 개념이 다르고 어려웠다. RDBMS와 NOSQL의 차이점은 AWS공식문서에 간단명료하게 잘나와있다.

DynamoDB의 장,단점

장점 : 장점은 사실 공식문서에 줄줄줄줄 써있다

• 완전 관리형 DB이기 때문에 aws에서 모든것을 관리해준다 .
• AWS 서비스들과 연동하기좋다 ( 특히 Lambda 와 궁합이좋다 )
• ACID 트랜잭션을 지원한다
• 어떤 규모에서도 10밀리초 미만의 성능 보장 !
• 그외에도 정말많다..어떤기업이든 자기네 서비스가 짱이라고 할것이다 (공식문서)

단점 : 단점은 내가 직접 느낀것들이다

• 감당할수있는 최대치를 넘어가면 응답 속도가 느려지는게아니라 그냥 요청을 거부해버린다
• 참고할만한 자료가 생각보다 별로없다
• 쿼리해서 데이터 꺼내오기가 아주 어렵다
• workbench툴이없다,
• 쿼리할때 사용하는 파라미터가 귀찮다
• 러닝커브가 생각보다 크다
• 그래서 한창 개발하는데 낭패보는 일이 생길수도있다. 오죽하면 DynamoDB 잘모르면 그냥 익숙한 RDBMS 쓰라는 말이있을까?
• 공식문서의 자극적인 문장(?)

---

단점하나씩 살펴보자

참고할만한 자료가 생각보다 별로없다
DynamoDB에대한 자료가 많지 않다. 그래서 결국 여러블로그의 글을 읽고읽고 돌고돌아 AWS공식문서로 돌아오게된다. 공식문서만한게 없다

쿼리해서 데이터 꺼내오기가 아주 어렵다
RDBMS는 테이블설계를 잘하고, 데이터를 정규화해서 넣어놓으면 데이터를 꺼내오기가 편하다. SQL에 여러가지 기능이 많기도하고..하지만 NOSQL인 DynamoDB는 데이터를 잃어버릴수도있다. DynamoDB는 데이터를 꺼내올때 반드시 partition Key를 넣어야되는데,그 partition Key를 모르면 Value를 찾을수가없기때문이다.

workbench 같은 툴이없다
mysql workbench나 dbeaver같은게 있으면 정말편한데 그런게없다.. (2020년 6월기준 찾아보니 베타버전으로 있긴있다고 합니다) 웹 콘솔에서 임시로 작업을 하다보면 현타온다. 웹 콘솔은 아무래도 한계가있다

쿼리할때 사용하는 파라미터가 귀찮다..(?)
SQL같은경우는 심플하면서 강력한 기능을 가지고있는데
DynamoDB의 query는 파라미터부터가 복잡하고 귀찮고 한눈에 알아먹기도 힘들다 . 기능도 거의 없다

const params = {
  TableName: '테이블명',
  IndexName: 'GSI이름', // 만약 GSI로 쿼리할때 사용,
  ProjectionExpression: 'select 할 속성들',
  KeyConditionExpression: '#company = :companyId', // key를 이용한 where
  ExpressionAttributeNames: {
    '#company': 'CompanyID', //예약어인경우 이렇게 사용해야된다"#cTime": "CreatedTime"
  },
  ExpressionAttributeValues: {
    //값 파라미터는 이렇게사용":companyId": "Test",
    ':deptType': dType,
    ':daysPrior': 1250456879634,
  },
  FilterExpression: '#dType = :deptType AND #ts > :daysPrior', // key값으로 뽑아온후 필터링하는 조건
};

위는 파라미터의 한 예시다..

공식문서의 자극적인 문장(?)
이건 그냥 반농담이긴한데,,

DynamoDB 애플리케이션에서는 가능한 적은 수의 테이블을 유지해야 합니다. 대부분의 잘 설계된 애플리케이션은 단 하나의 테이블만 요구합니다.

위 문장은 공식문서에 나와있는 문장을 그대로 복붙한것이다. 개발자라면 누구나 설계를 잘하고싶은 욕심이 있을것이다. 그렇기 때문에 난 단하나의 테이블에 집착했다.. 결국 지금은 테이블을 2개 쓰고있다(설계실패?) 2개로 서비스 운영하면서 느꼈지만 굳이 하나에 집착할필요가 없다고 생각한다.

---

만약 처음으로 돌아간다면 다시쓰고 싶지않지만..지금은 RDBMS보다 더 익숙해져버렸다. 애증의 DynamoDB 글 마침