언제 DynamoDB를 써야 하는가(그리고 쓰지 말아야 하는가)

DynamoDB는 그것을 위해 만들어진 워크로드에는 환상적인 데이터베이스이고 나머지에는 답답한 것입니다. 결정적 질문은 "웹 규모인가?"가 아니라 — **"내 액세스 패턴을 미리 알고 있으며, 그것이 키 기반인가?"**입니다. 그것을 제대로 맞추면 DynamoDB는 어떤 규모에서도 한 자릿수 밀리초 읽기를 주고, 틀리면 조인과 임의 쿼리의 부재와 영영 싸우게 됩니다.

언제 DynamoDB를 써야 하나요?

액세스 패턴이 알려져 있고 키 기반이며 대용량일 때, 그리고 관리할 서버 없이 어떤 규모에서도 예측 가능한 한 자릿수 밀리초 지연 시간을 원할 때 DynamoDB를 사용하세요. 임의 쿼리, 풍부한 조인, 또는 전체 데이터셋 분석에는 적합하지 않으며, 데이터가 작고 쿼리 형태가 계속 바뀌는 경우에도 마찬가지입니다.

• DynamoDB를 쓰세요 — 액세스 패턴이 알려져 있고, 키 기반이며, 대용량일 때, 그리고 관리할 서버 없이 어떤 규모에서도 예측 가능한 지연 시간을 원할 때.
• 피하세요 — 임의 쿼리, 풍부한 조인, 또는 전체 데이터셋에 대한 분석이 필요하거나, 데이터가 작고 쿼리 형태가 계속 바뀔 때.
• 핵심 거래: DynamoDB는 쿼리를 미리 설계하게 만들고, 그 대가로 커져도 결코 느려지지 않습니다.
• 이것은 다른 문법을 가진 관계형 데이터베이스가 아닙니다 — 관계형처럼 모델링하는 것이 고통의 1순위 원인입니다.

DynamoDB를 선호하게 하는 신호

다음 대부분이 성립할 때 DynamoDB가 빛납니다:

• 액세스 패턴을 미리 압니다. 앱이 하는 정확한 쿼리("id로 사용자 가져오기", "사용자 주문을 최신순으로 나열")를 나열할 수 있고, 그것이 변덕스럽게 바뀌지 않습니다. DynamoDB는 그 쿼리들을 중심으로 모델링됩니다.
• 액세스가 키 기반입니다. 임의 속성 조합을 스캔하는 게 아니라 알려진 파티션 키로 항목을 조회합니다.
• 확장과 예측 가능한 지연 시간이 중요합니다. DynamoDB는 테이블이 천 개의 항목을 담든 십억 개를 담든 일관된 한 자릿수 밀리초 성능을 냅니다.
• 운영 부담 제로를 원합니다. 인스턴스도, 페일오버도, vacuum도 없습니다 — 완전 관리형이며 온디맨드로 0까지 확장합니다.
• 쓰기 처리량이 높고 들쭉날쭉합니다. 이벤트 로그, IoT 텔레메트리, 세션/장바구니 상태, 리더보드 — 명확한 키가 있는 추가 중심 워크로드.

반대하는 신호

대신 관계형 데이터베이스(또는 검색/분석 엔진)에 손을 뻗으세요 — 다음일 때:

• 쿼리가 임의적입니다. 분석가가 임의 컬럼으로 데이터를 자르거나, 요구사항이 매주 바뀝니다. SQL의 유연성이 이깁니다. DynamoDB는 패턴마다 새 인덱스가 필요해집니다.
• 전체 데이터셋에 걸친 진짜 조인과 집계가 필요합니다. 보고, 비즈니스 인텔리전스, "지역별 월별 매출 합계" — 그건 OLAP/관계형의 일입니다.
• 데이터셋이 작고 트래픽이 적습니다. 조용한 관리자 앱의 수천 행은 DynamoDB의 확장에서 이득이 없고 SQL의 편의를 잃습니다.
• 아직 액세스 패턴을 예측할 수 없습니다. 아직 형태를 찾는 초기 제품인가요? 자유롭게 다시 쿼리할 수 있는 관계형 스키마가 패턴이 정착할 때까지 더 너그럽습니다.

결정하기 전에 비용 계산하기

DynamoDB 요금은 인스턴스 시간이 아니라 읽기, 쓰기, 스토리지를 따릅니다 — 그래서 들쭉날쭉하고 서버리스인 워크로드엔 저렴하고, 지속적으로 무거운 스캔엔 비쌀 수 있습니다. 실제 읽기/쓰기 비율을 DynamoDB 요금 계산기로 모델링한 뒤 결정하세요. 기술적으로 맞아 보이는 워크로드라도 비용으로도 계산이 맞아떨어져야 합니다.

맞다고 결정했다면

이제 작업은 모델링으로 옮겨 갑니다. DynamoDB는 테이블을 여러분의 쿼리를 중심으로 설계할 때 보답합니다 — DynamoDB에서 데이터를 모델링하는 법과 싱글 테이블 디자인, 그리고 명시적으로 싱글 테이블에 손대지 말아야 할 때를 보세요.

함정 + 다음 단계

• DynamoDB를 관계형 데이터베이스처럼 모델링하지 마세요 — 읽기 시점에 조인하는 정규화된 테이블은 DynamoDB가 가장 가혹하게 벌하는 안티패턴입니다.
• 분석용으로 고르지 마세요 — 보고를 위해서는 테이블을 스캔하는 대신 분석 저장소와 짝짓거나 그쪽으로 내보내세요.
• 액세스 패턴이 불확실한가요? 기다리세요. 쿼리를 알기 전에 DynamoDB를 채택하는 것은, 그것을 알 것을 요구하는 바로 그 데이터베이스를 고르는 일입니다.
• 관련: query vs scan이 "키 기반 액세스"가 실제로 무엇을 사주는지 보여 줍니다.

앱을 걸고 베팅하기 전에 DynamoDB 테이블을 탐색하고 싶으신가요? DynoTable을 받아 데이터에 직접 연결해 보세요.