제가 DynamoDB 선택을 포기한 이유

2012년 1월 Amazon Web Service 에서

DynamoDB 서비스를 베타 런칭하였습니다.

개념은 엄청 혁신적이고 매력적이었습니다.

Read/Write Throughput 을 마음대로 조절할 수 있고

이에 따라 또 사용하는 용량에 따라 돈을 과금하고

확장 능력(Scalability) 나 가용 능력(Usability)가

Sharding이나 Replication 에 대한 개념 없이

무한대로 데이터를 읽고 쓰면 사용하는 용량이나

트래픽 처리를 알맞게 알아서 다 자동으로 해주는 것입니다.

(물론 throughput은 수동으로 설정, 알림 서비스를 통해 부족하면 알려줌) 

거기에 일반 HDD가 아닌 SSD로 구축한 서버라서

속도도 무지 빠릅니다.

또한 최대 용량 제한 또한 없어서

정말 DB 확장이나 그 방면에 대한 걱정거리를 말끔히 씻어주고

개발에만 집중할 수 있게 하는 그럼 꿈 같은 이야기이기에

혹 해서 열심히 알아보았습니다.

 

아주아주 긍정적으로 검토해보았으나

저에게는 DynamoDB의 단점이 너무나도 컷기에 선택을 안하기로 했습니다.

 그것은 바로 데이터형이 String, Number, Array 이렇게 3가지 밖에 없고

Query는 내가 지정한 Primary Key 밖에 되지 않고

Range라는 특이한 개념을 써서 비교 연산자를 통해

예를 들면 Timestamp를 Range로 설정하고 Primary Key와 함께

시간 범위로 Query를 날릴 수 있지만

이게 쿼리를 날릴 수 있는 전부이며

비효율적으로 전체 테이블을 스캔하는 scan을 사용하게 되면

테이블이 커질수록 속도가 저하되는 단점이 생기고

또 query와 scan 둘다 한번 실행시 최대 1MB까지밖에 검색을 하지 못하고

이어서 다시 명령어를 그 지점부터 계속 다시 실행해야하는 단점이 저에게는

너무나도 치명적인 단점으로 다가왔습니다.

물론 데이터 모델에 따라 충분히 적용 가능한 모델도 있겠지만.. 

세상에 Query를 Primary key로 밖에 못하고 그 외에는 전체 테이블 스캐닝에다가

한번 스캐닝은 1MB 제한이라니..

저런 치명적인 매력과 치명적인 단점이 함께 공존하네요 참..

MongoDB를 DynamoDB 처럼 서비스 하면 참 좋을텐데요 ㅎㅎ

Amazon Web Service 에서 아예 MongoDB 서비스가 나오거나 아니면

DynamoDB API가 많이 생겨서

Query 를 좀더 유연하고 다양하게 할 수 있다면 DynamoDB를 선택하는 사람이

더 많이 늘어나겠죠?