'dynamodb' 태그의 글 목록
www.recopick.com

안녕하세요. RecoPick 팀의 김성민입니다.

지난번 DynamoDB의 Write Capacity를 낮춰서 DynamoDB 비용 줄이기 글에 이어서 DynamoDB 비용을 어떻게 또 절감했는지 공유해드리고자 합니다.

지난번 글에서 설명한 것처럼 DynamoDB 비용을 좌우하는 주요 요인이 Write Capacity이기 때문에, 저희 팀에서는 Write Capacity를 줄여서 DynamoDB 비용을 줄였습니다.


하지만 아무리 Write Capacity를 절반 정도로 줄였다고 하더라도, Write 연산이 전혀 없는 시간에 Write Capacity를 일정 수준을 유지해 줘야 하므로 Write 연산이 전혀 없는 시간의 DynamoDB 비용이 여전히 낭비되는 문제가 있었습니다.

마른 수건이라도 한 번 더 짜 본다는 심정으로 Read, 특히 Write 연산이 없는 경우에 DynamoDB 비용을 줄 일 방법이 없을까 고민을 하던 중에 Read/Write 연산이 없는 경우, DynamoDB의 Read/Write Capacity를 낮춰서 비용을 줄일 수 있지 않을까 하는 생각이 들었습니다.

DynamoDB의 Read/Write Capacity 변화를 감시하다가, Read/Write Capacity가 낮아지면 자동으로 Read/Write Provisioned Capacity를 낮추고, 다시 높아지면 올려주면 될 것 같았습니다.

여기서 고려해야 할 점은 DynamoDB의 제약 사항 중, 1일 최대 4회까지 Read 혹은 Write Provisioned Capacity를 낮출 수 있다는 점입니다. Read/Write Provisioned Capacity를 올리는 것은 DynamoDB 비용이 증가하므로, 회수 제한이 없지만, 낮추는 것은 1일 4회로 제한되어 있기 때문에, Read/Write Capacity 변화가 빈번한 경우 자동으로 Read/Write Provisioned Capacity를 조정하기 어렵다는 생각이 들었습니다.

이러한 고민을 하던 중에 Dynamic DynamoDB라는 오픈 소스를 발견했습니다.
Dynamic DynamoDB는 앞서 설명한 것처럼, DynamoDB의 Read/Write Capacity 변화에 따라 Read/Write Capacity를 자동으로 조절해주는 도구입니다.

특히, Read/Write Capacity 증가 시점 및 비율 등을 설정으로 조절할 수 있기 때문에, 1일 4회로 제한된 Read/Write Capacity를 낮출 수 있는 DynamoDB의 제약 조건 내에서도 Provisioned Read/Write Capacity를 자동으로 변경할 수 있었습니다.

아래 그래프는 Dynamic DynamoDB 적용 후, DynamoDB의 Write Capacity 변화 그래프입니다.





Dynamic DynamoDB 설치 및 운영 방법은 Dynamic DynamoDB 문서를 참고 하시면 되기 때문에 자세한 설명은 하지 않겠습니다.


대신 몇 가지 주의하실 점을 설명해 드리자면,


(1) Read/Write 연산이 전혀 없으면서도 Read/Write Capacity를 줄이고자 한다면, allow-scaling-down-Reade-on-0-percentallow-scaling-down-writes-on-0-percent를 true로 설정해야 합니다.


(2) Dynamic DynamoDB는 기본적으로 CloudWatch의 5분 동안의 모니터링 결과를 사용해서 Read/Write Capacity를 조절하는데, CloudWatch 결과의 최신성을 조절하려면, lookback-window-start를 조정하시면 됩니다.

lookback-window-start 값을 5로 하면, now() - 5(분) 에서 now() (분)까지의 Cloud Watch 모니터링 결과를 사용하게 됩니다.

하지만 5분 미만의 Cloud Watch 모니터링 결과를 사용할 수 없으므로, 너무 작게 설정하면, Read/Write Capacity가 자동 조절되지 않습니다.


(3) 1일 4회까지 Read/Write Capacity를 낮출 수 있다는 Dynamo DB 제약 사항을 지키려면,

increase-{reads, writes}-with는 작게 decrease-{reads, writes}-with는 크게 하는 편이 좋습니다.

즉, Batch 작업의 경우, Read/Write가 천천히 증가하다가 작업 종료 시점에 급격하게 줄어들기 때문에, 증가 비율보다 감소 비율을 크게 해서 작업 종료 시점에 Read/Write Capacity를 크게 낮춰서 1일 Read/Write Capacity 감소 횟수를 줄이는 것이 좋습니다.


[참고 자료]







Posted by recopick

댓글을 달아 주세요

안녕하세요. RecoPick팀의 김성민입니다. 

지난번 DynamoDB vs HBase 비교 분석 포스팅에 이어서 이번에는 DynamoDB의 Write Capacity를 줄이는 방법을 소개해 드리겠습니다. 

Dynamo DB의 장점은 다른 NoSQL(abase, Cassandra, MongoDB 등등)에 비해서 관리 비용이 거의 zero에 가깝다는 것입니다. 
사용자가 특별한 설정을 할 필요도 없고, Read/Write 성능 항상을 위해서 여러 가지 복잡한 설정 옵션을 고려할 필요가 없이, AWS 관리 console에서 몇 번의 클릭만으로 쉽게 관리할 수 있습니다. 

하지만 단점은 Read/Write Capacity 에 따라서 사용 요금이 큰 편차를 보인다는 것입니다.


 

 

 #1

 #2

 #3

 Indexed Data Storage

 Dataset Size (GB)

 1

 1

 1

 Provisioned Throughput Capacity

 Item Size (All attributes) (KB)

 64

 64

 64

 

 Number of items read per second (Reads/Second)

 0

 100

 0

 

 Number of items written per second (Writes/Second)

 250

 250

 500

 Data Transfer

Data Transfer Out (GB/Month)

 10

 10

 10

 

 Data Transfer In (GB/Month)

 10

 10

 10

Estimate of your Monthly Bill ($)

 

 9848.24

 9938.68

 19654.49


Table 1. DynamoDB의 월평균 예상 사용 요금



위의 표는 초당 Write 횟수에 따라서 DynamoDB의 월평균 예상 사용 요금이 비례하고 있음을 보여줍니다. 
위 표처럼, 초당 Write 회수가 250 Writes/Second에서 500 Writes/Second로 증가하면, 비용이 거의 2배로 오르게 됩니다. 

반면에 Read 회수에 따라서는 DynamoDB의 비용이 크게 변화되지 않습니다. 
결국, 초당 Write 횟수, 즉 Write Capacity 설정이 DynamoDB의 사용 비용에 큰 영향을 줍니다. 


하지만 현실적으로 적절한 Write Capacity 값을 찾기는 쉽지 않습니다. 

예를 들어, 아래 그래프와 같이 Write operation이 발생할 경우, 다음 중 가장 적합한 Write Capacity는 얼마일까요?

 
(1) 100 ~ 250 
(2) 250 ~ 500 
(3) 750 ~ 1,500 
(4) 1,500 ~ 

정확한 정답은 없지만, 아래 그래프를 보면, Write 회수가 평균 750 Writes/Second이고, 최대 1,500 Writes/Second이므로 Write Capacity 대략 750 ~ 1,500 정도가 되어야 할 것입니다.




Figure 1. DynamoDB Write Capacity 그래프 



즉, DynamoDB에서는 Write 횟수가 갑자기 증가하는 것을 대비해서 예측 가능한 최대 Write Capacity 만큼 설정해야 합니다. 결국, 순간 최대 Write 횟수에 의해서 DynamoDB의 사용 요금이 큰 영향을 미칠 수밖에 없습니다. 
만약, Write Capacity를 낮게 하게 되면, Write 회수가 순식간에 증가할 경우, write operation이 실패하기 때문에, 데이터를 안전하게 보관할 수 없게 됩니다. 

그렇다면, 어떻게 Write Capacity를 낮추면서, 순간적으로 Write operation이 증가할 경우에도 write operation의 실패 없이 데이터를 안전하게 보관할 수 있을까요? 
여러 가지 방법이 있을 수 있겠지만, 대략 아래와 같은 2가지 방법을 생각해 볼 수 있습니다. 

(1) Write 회수의 증감에 따라서, Dynamo DB의 Write Capacity를 자동으로 조절해 주는 방법 
(2) Write 회수 자체를 항상 일정한 수준으로 유지하는 방법 

1번의 경우, DynamoDB의 Write Capacity 조정 횟수 및 조정 폭이 제한적이고, 변경된 Write Capacity가 DynamoDB에 적용되는데 일정 시간이 걸리기 때문에, 온라인 트랜잭션 처리(OLTP) 시에는 적합하지 않을 수도 있습니다. 

2번째 방법은 Write operation의 속도 지연이 없이 Write 회수 자체를 항상 일정한 수준으로 유지해야 한다는 점이 어렵습니다. Write operation을 수행하는 쪽에서는 DynamoDB의 Write Capacity에 상관없이 항상 원하는 수준으로 빠르게 write operation을 수행할 수 있도록 해야 합니다. 

저희 팀의 경우, Write operation을 수행하는 쪽이 될 수 있는 대로 DynamoDB의 Write Capacity에 의존하지 않고, 최대한 write throughput을 낼 수 있게 하려고 1번보다는 2번 방법으로 DynamoDB의 Write Capacity를 낮추도록 했습니다.


Write 회수 자체를 일정한 수준으로 유지하기 위해서 저희가 생각한 방식은 Producer-Consumer 패턴으로 Write operation을 처리하는 것입니다. 즉, 기존에는 DynamoDB에 바로 write operation을 수행했지만, DynamoDB에 write 을 수행하는 Producer와 DynamoDB 사이에 Queue를 도입해서 Producer는 Queue에 write를 하고, Consumer가 Queue에서 DynamoDB에 write 할 데이터를 꺼내와서 write operation을 수행하는 것입니다. 


기존 방식은 Producer의 write 회수와 속도가 DynamoDB의 Write Capacity를 결정했지만, Producer-Consumer 패턴에서는 
Queue의 대기 시간과 Consumer의 처리 속도 조절해서 DynamoDB의 Write Capacity를 최소화할 수 있습니다. 
그래서, Producer는 기존처럼 빠르게 write를 수행하고, Consumer가 DynamoDB에 일정한 속도로 DynamoDB에 write를 하게 함으로써, 항상 write 회수가 일정한 수준으로 유지될 수 있도록 하는 것입니다.


(a) Producer-Consumer 패턴 적용 전


(b) Producer-Consumer 패턴 적용 후


Figure 2. DynamoDB Write Operation 방식



하지만 Producer-Consumer 패턴을 구현할 때, 다음과 같은 2가지 점이 만족하여야 합니다. 


(1) Queue나 Consumer에서 장애가 발생하더라도 write operation이 자동으로 수행되어야 함. 

(2) Producer의 write 횟수가 갑자기 증가하더라도 producer의 write throughput을 떨어뜨리지 않을 정도로 Queue가 동작해야 하는 함 


위의 2가지 조건을 모두 충족 시키는 Kafka와 Storm을 사용하였습니다.
Kafka는 분산 Queue이기 때문에, 장애 발생 시, 자동으로 fail over가 가능하고, 확장성이 뛰어나기 때문에, 장비만 추가함으로써, write throughput을 높일 수 있습니다. 
Consumer로는 Storm을 사용하였는데, 역시 Kafka와 마찬가지로 장애 발생 시 자동으로 fail over가 가능할 뿐만 아니라, Hadoop과 다르게 실시간 streaming 처리가 가능하므로 Storm을 선택했습니다. 


물론, Kafka-Storm 대신 Amazon SQS와 Kinesis를 사용할 수도 있었지만, 저희 팀에서는 Kafka와 Storm을 사용하면서 이미 성능 검증을 마쳤기 때문에, Kafka와 Storm을 주저 없이 선택할 수 있었습니다. 


Producer-Consumer 패턴에 사용할 Queue와 Consumer로 Kafka와 Storm을 선택한 후, 실제 어떻게 DynamoDB의 Write Capactiy를 조정하기 위해서 아래와 같이 모델링 작업을 했습니다.


(1) DynamoDB Write operation 횟수 /  sec = 평균 Producer의 총 Write 횟수 / Queue 대기 시간 (sec)
(2) Queue 대기 시간 = Consumer의 프로세스 1개의 평균 처리 속도 x Consumer의 프로세스 개수


저희 팀의 요구 사항은 Producer의 초당 write 횟수와 관계없이 Dynamo DB의 초당 write 횟수를 조정하고 싶었기 때문에, 위의 식 (1)에서 평균 Producer의 총 Write 횟수는 고정값으로 하고 Queue 대기 시간을 변동 값으로 해서 초당 Dynamo DB Write 횟수를 원하는 수준으로 낮출 수 있도록 Queue 대기 시간을 추정했습니다. Queue 대기 시간은 위의 식 (2)에서 처럼 Consumer의 처리 속도가 일정할 경우, Consumer 프로세스의 개수에 좌우됩니다. 따라서 Consumer로 사용한 Storm 프로세스의 평균 속도를 측정한 후, Dynamo DB Write Capacity를 낮추기 위해 추정한 Queue 대기 시간에 맞도록 프로세스 개수를 조정했습니다.


이런 방식으로 해서 저희 팀은 DynamoDB의 Write Capacity를 1/3 수준으로 낮출 수 있었습니다.



Figure 3.  DynamoDB Write Operation 방식 변경 후, Write Capacity 그래프 



요약 하자면, Kafka와 Storm을 이용해서 Producer Consumer 패턴으로 DynamoDB의 write operation 방식을 변경해서, write capacity를 1/3로 줄일 수 있었습니다.


참고로 Kafka와 Storm을 이용한 Producer Consumer 패턴의 다른 응용으로는 뉴스나 트위터와 같은 스트리밍 데이터의 트래픽을 regulation 하는데 사용 가능합니다. 혹은 slide share와 같이 사용자가 데이터를 올리는 경우에도 응용 가능합니다.


[참고 사항]
(1) Auto Scale DynamoDB With Dynamic DynamoDB - http://aws.typepad.com/aws/2014/02/auto-scale-dynamodb-with-dynamic-dynamodb.html

(2) Amazon Kinesis - http://aws.amazon.com/ko/kinesis/
(3) Amazon Kinesis: Real-Time Processing of Streaming Big Data - http://aws.typepad.com/aws/2013/11/amazon-kinesis-real-time-processing-of-streamed-data.html

(4) Amazon Simple Queue Service(Amazon SQS) - http://aws.amazon.com/ko/sqs/
(5) SQS: Super Queue Service - http://aws.typepad.com/aws/2007/05/sqs_super_queue.html

(6) AWS Simple Monthly Calculator (AWS 월 사용량 계산기) - http://calculator.s3.amazonaws.com/index.html

(7) Limits in DynamoDB - http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Limits.html 


(8) CDP:Job Observer Pattern - http://en.clouddesignpattern.org/index.php/CDP:Job_Observer_Pattern




Posted by recopick
TAG dynamodb

댓글을 달아 주세요

안녕하세요. RecoPick팀 김성민입니다.

오늘은 최근 RecoPick팀에서 DynamoDB를 사용하게 되면서 배웠던 사항을 QnA 형태로 정리했습니다. 참고로 그동안 제가 주로 HBase를 사용해왔기 때문에, 되도록 DynamoDB와 HBase를 비교하면서 설명해 보도록 하겠습니다.

1. HBase와 DynamoDB의 개념적인 차이?

  HBase와 DynamoDB의 개념적인 차이를 한마디로 말하자면, SortedMap(a.k.a TreeMap)과 HashMap의 차이점과 같습니다. java TreeMap은 element가 정렬되어서 저장되어 있으나, HashMap의 경우, 저장된 element의 정렬 순서를 보장하지 않습니다. 마찬가지로 HBase의 경우, 저장되는 데이터가 모두 alpha numeric 순서 정렬되어 있으나, DynamoDB는 저장되는 데이터의 정렬 순서를 보장하지 않습니다. 


2. HBase와 DynamoDB의 구조적인 차이?

  HBase는 Master-Slave 구조지만, DynamoDB는 Peer-To-Peer 구조로 되어 있습니다. 아래그림 처럼, HBase는 논리적으로 B+Tree 구조로 데이터를  분산해서 저장하지만, DynamoDB는 consistency hash 방식을 사용해서 저장합니다.


그림 1. Table location hierarchy



그림 2. Partitioning and replication of keys in Dynamo ring.


3. Eventually Consistent vs Strongly Consistent?

  DynamoDB의 경우,  eventually  consistent reading과 strongly consistent reading을 모두 지원하지만, Scan 연산의 경우는 eventually consistent reading만 지원합니다. (참고로, strongly consistent reading은 항상 최종 변경 내용을 반환해 주지만, eventually consistent reading은 최종 변경 내용을 항상 반환해 줄 수는 없다는 뜻입니다.)


4. Range query를 수행할 수 있는지?

  앞서 HBase와 DynamoDB의 개념상 차이에서 설명한 것처럼, DynamoDB는 개념적으로 정렬 순서를 보장하지 않는 HashMap이기 때문에, DB layer에서 range query를 지원하지 않습니다. 그럼에도 불구하고, DynamoDB에서 range query를 사용해야 한다면, 아래와 같은 방법을 고려 해 볼 수 있습니다.

  먼저 데이터 접근 패턴(access pattern)을 분석해서, DynamoDB의 키를 계층 구조로 설계하고, 동일한 키에 대해서 range query를 수행할 수 있도록 스키마를 설계해야 합니다.

  예를 들어, 1~100 사이 값을 unique id로 갖는 데이터를 저장할 때, 이 값을 그대로 key로 사용하면, DynamoDB에서는 "13~25의 값을 꺼내"와 같은 range query는 수행할 수 없습니다. 이를 우회하기 위해, 1~100 사이의 unique id를 10단위로 해서 아래와 같이 그룹핑을 한 후,



Group Id를 Hash Key로 하고, Unique Id를 Range Key로 설정해서 저장합니다. 

만약 id가 13~25 사이의 데이터를 가져오는 range query를 수행하고자 한다면, 먼저 해당 Unique Id들이 포함되는 Group Id들(이 경우에는 11, 21)를 찾습니다. 그리고 Group Id 11을 hash key로 갖는 데이터 중에서 unique id가 13~20 사이에 있는 데이터를 가져오는 query를 수행 합니다. 마찬가지로 Group Id 21을 hash key로 갖는 데이터 중에서 unique id가 21~25 사이에 있는 데이터를 가져오는 query를 수행해서 Unique Id가 13~25 사이의 데이터를 가져올 수 있습니다. 즉, DB에서는 지원하지 않지만, 스키마를 잘 설계하면, application layer에서 range query를 흉내내는 것은 가능합니다.


5. Secondary Index를 지원하는가?

  HBase의 경우 secondary index를 지원하지 않습니다. 따라서 Secondary index를 별도의 테이블로 생성해서 직접 관리해 줘야 하는 부담이 있습니다. 반면에, DynamoDB는 Local/Global Secondary Index 2가지를 지원하고 있습니다. 

  Local Secondary Index는 메인 테이블과 별개로 테이블이 생성되는 것은 아니고, 데이터를 저장하는 물리적인 node의 local storage에 색인 데이터가 생성되는 것입니다. 그리고 Local Secondary Index의 경우, 최대 10GB까지 데이터를 저장할 수 있습니다. 

  하지만 Global Secondary Index는  메인 테이블과 별개로 새로운 테이블이 생성되고, 메인 테이블의 일부 item들을 projection한 결과를 저장할 수 있습니다. 또한, Global Secondary Index는 메인 테이블의 내용이 변경될 경우, 데이터를 자동으로 동기화되는 장점이 있습니다.

  DynamoDB의 Secondary Index 기능은 매우 좋은 기능이지만, 다음과 같은 단점도 존재합니다.

 a. Loca/Global Secondary Index를 각각 테이블당 최대 5개까지 밖에 생성할 수 없습니다. 

 b. 테이블을 생성할 때, Secondary Index를 생성해 줘야 하며, 테이블 생성 완료 후, 변경이 불가능합니다. 만약 테이블이 생성된 후, Secondary Index를 추가하고 싶다면, 다른 테이블을 만든 다음, 데이터를 모두 옮겨줘야 합니다.

 c. Secondary Index가 추가될 때마다, write capacity가 감소합니다. 만약 Secondary Index가 없다면, 테이블에 1회 write operation을 수행한다면, 1번의 write만 일어나지만, Secondary Index가 있다면, Secondary Index 개수만큼 write가 추가적으로 발생하게 됩니다. 따라서 동일한 write capacity 상에서 Secondary Index를 추가할수록 사용 가능한 write operation은 그만큼 줄어들게 됩니다. (=돈이 많이 듭니다) 그러므로 불필요한 Secondary Index는 되도록 만들지 않는 것이 신상에 좋습니다.


6. Schema 변경이 자유로운가?

  DynamoDB 역시 다른 NoSQL 처럼, schemaless 하므로, schema 변경은 자유롭습니다. 하지만 하나의 테이블에 저장되는 item의 크기 (RDS의 row size와 같음)에는 64KB를 초과할 수 없습니다. HBase의 경우, 이론상 하나의 row에 저장할 수 있는 column 수에 제한이 없지만, DynamoDB의 경우, 한 item에 저장되는 데이터의 크기가 64KB를 넘지 않도록 주의해야 합니다.


7. TTL(Time-To-Live)을 지원하는가?

   HBase의 경우, TTL을 설정해서 일정 기간 이상 지난 오래된 데이터는 자동 삭제할 수 있도록 할 수 있지만, 현재까지 DynamoDB는 TTL을 지원하고 있지 않습니다. 많은 사용자들이  TTL 기능을 요구하고 있지만, 아직 AWS DynamoDB Team에서 지원해주지 못하고 있다고 합니다.

   따라서 TTL 기능이 필요한 경우, last modified time 과 같은 속성을 데이터에 추가해서 오래된 데이터는 사용자가 직접 삭제할 수밖에 없습니다. 로그 데이터와 같은 Time Series Data의 경우에는 일별, 주별 혹은 월별로 테이블을 별도로 생성한 후에, 오래된 데이터는 테이블 전체를 삭제하는 하는 편이 더 좋다고 합니다. 만약, 테이블을 시간 순서로 분리하지 않고, 하나의 테이블에 있는 오래된 데이터를 삭제할 경우, 삭제 연산 역시 write 연산이기 때문에 그만큼의 write capacity가 필요하고, 테이블 전체를 삭제하는 것보다 비효율적이라고 합니다.


8. Transaction을 지원하는가?

  MySQL과 같은 RDS를 사용하다가 HBase나 DynamoDB와 같은 NoSQL을 사용할 때, 가장 먼저 겪는 불편함은 mult-rows혹은 mutl-tables 간의 transaction 처리 일 것입니다. 대부분의 NoSQL은 scalibility를 위해서 transaction을 희생하고 있기 때문에, application개발 시에, transaction 이 필요하다다면, 난감한 상황에 처하게 됩니다.

  다행히 DynamoDB의 경우, mutl-rows transaction을 지원하는 java API를 제공하고 있습니다. Transaction 처리가 필요한 경우, 한 번쯤 검토를 해보시는 것도 좋을 것 같습니다. HBase의 경우, omidhaeinsa와 같은 transaction 기능을 지원하는 open source project가 진행 중이니 참고 하시기 바랍니다.


9. Multi-versioning 기능을 제공하는가?

   HBase의 경우, MAX_VERSION이라는 옵션을 사용해서, 여러 버전의 데이터를 저장할 수 있습니다. 예를 들어, MAX_VERSION을 3으로 설정하면, 동일한 row key에 대해서 최대 3개까지의 데이터를 저장하고, 버전별로 데이터를 읽어올 수 있습니다.

  DynamoDB의 경우, 아쉽게도 mult-versioning 기능을 지원하지 않기 때문에, (물론 내부적으로 multi-version을 이용해서 데이터를 관리합니다.) multi-versoning 기능이 필요한 경우, TTL과 마찬가지로 사용자가 직접 관리해줘야 하는 부담이 있습니다.


10. 쉽게 확장 가능한가?

  DynamoDB는 provisioned I/O를 보장해 주기 때문에, read/write throughput  필요에 따라서 scale-up 하기가 쉽습니다. AWS DynamoDB Console이나 Client API를 이용해서 쉽게 read/write throughput을 조정할 수 있습니다.

  하지만 scale-up은 임의대로 할 수 있지만, scale-down은 1일 4회로 제한되어 있습니다. 따라서 read/write peek 시점에만 일정 시간 동안 scale-up을 했다가, 다시 scale-down을 하고자 할 경우, 하루에 5번 이상 할 수 없습니다. 이런 경우에는 read/write 모니터링을 하면서, read/write 횟수를 일정하게 유지 할 수 있도록 시스템을 설계하는 것이 좋습니다. 그렇지 않을 경우, 요금 폭탄을 맞을 수도 있습니다. 

이상 10가지 정도 DynamoDB에 대해서 HBase와 비교하여 간략히 설명해 드렸습니다. DynamoDB의 경우, HBase가 지원하지 않는 좋은 장점들도 있지만, 데이터 모델의 차이 때문에 데이터의 접근 패턴에 따라서는 사용하기 어려운 부분도 있습니다.

언제나 그렇듯 정답은 없는 것 같습니다. 너무 뻔한 얘기지만, 역시 NoSQL을 사용하고잘 할 때는 NoSQL 마다의 특성을 잘 파악해서 사용 목적에 가장 잘 맞는 것을 선택해서 사용하는 것이 정답인 것 같습니다. ^^


[참고 자료]


Posted by recopick

댓글을 달아 주세요