DynamoDB에 대한 5가지 오해

 

The DynamoDB Book

 

1. DynamoDB는 키-값 저장소일 뿐입니다.

당신은 DynamoDB가 단순한 액세스 패턴만 처리할 수 있다고 들었을지도 모릅니다. 개별 항목을 삽입하고 다시 읽어오는 것뿐이며, 그보다 복잡한 것은 "진짜" 데이터베이스를 사용해야 한다고 말이죠.
이보다 더 사실과 거리가 먼 말은 없습니다. DynamoDB는 여러 레코드 간의 관계(일대다 관계에 관한 11장과 다대다 관계에 관한 12장 참조)와 필터링에 관한 복잡한 요구사항(13장 참조)을 처리할 수 있습니다. 관계형 데이터베이스와는 다른 방식으로 수행하지만, 여전히 가능합니다.
18-22장의 예제에서는 GitHub 메타데이터 백엔드 전체를 모델링하는 것을 포함한 몇 가지 복잡한 패턴을 살펴봅니다. 더 복잡한 예제는 10개 이상의 엔티티와 20개 이상의 액세스 패턴을 포함합니다. 10개의 엔티티에서 멈춘 이유는 시간이 지나면서 반복적으로 되기 시작하기 때문입니다.

 

2. DynamoDB는 확장성이 없습니다.

제가 DynamoDB에 대해 듣는 가장 이상한 오해는 그것이 확장되지 않는다는 것입니다. "그래, 간단한 앱에서 약간의 데이터를 저장하는 데는 작동할 수 있을지 모르지만, 여러 사용자를 처리할 수 있을 거라고 기대하지 마라."
이는 터무니없는 말입니다. 아마존(Amazon.com 소매와 Amazon Web Services 모두)은 모든 Tier 1 서비스에 DynamoDB 사용을 요구합니다. Tier 1 서비스는 다운되면 돈을 잃게 되는 모든 서비스입니다.
고트래픽 아마존 서비스들을 생각해보세요: 쇼핑 카트, 재고, AWS IAM, AWS EC2. DynamoDB는 이러한 규모를 처리할 수 있습니다.
그리고 DynamoDB는 아마존 외부에서도 많은 대용량 고객들이 사용합니다. Lyft는 애플리케이션의 모든 승차 위치를 처리하기 위해 DynamoDB를 사용합니다. 어느 순간이든 도로 위에 있는 Lyft 차량의 수를 생각해보세요. 마찬가지로, 많은 모바일 게임 회사들이 대규모로 핵심 데이터에 대한 대용량 트랜잭션을 처리하기 위해 DynamoDB에 의존합니다.
저는 이러한 오해가 DynamoDB를 잘못 사용한 사람들로부터 비롯된다고 생각합니다. 그리고 액세스 패턴에서 스캔에 의존하거나 모든 데이터를 단일 파티션에 배치한다면, DynamoDB가 원하는 만큼 확장되지 않을 것이라는 것은 사실입니다. 하지만 이는 도구의 결함이 아니라 오용의 문제입니다.

 

3. DynamoDB는 엄청난 규모를 위한 것입니다.

DynamoDB는 오직 거대한 규모를 위한 것이다. 세 번째 오해는 그 반대입니다: DynamoDB는 오직 대규모에서만 사용되어야 한다는 것입니다.

이 역시 틀린 말입니다. DynamoDB는 서버리스 커뮤니티에서 모든 종류의 애플리케이션에 널리 퍼졌습니다. 쉬운 프로비저닝, 유연한 과금 모델, HTTP 연결 모델, 사용량 기반 가격 책정 등의 조합이 서버리스 생태계와 잘 맞아떨어집니다. 저는 모든 새로운 애플리케이션에 기본적으로 DynamoDB를 사용하며, 수많은 다른 개발자들도 같은 방식을 택하고 있습니다.

 

4. 데이터 모델이 변경될 경우 DynamoDB를 사용할 수 없다

이후 장에서 DynamoDB의 데이터 모델링 개념을 배울 때, 저는 모델링 전에 액세스 패턴을 알아야 한다는 점을 자주 강조할 것입니다. 관계형 데이터베이스에서는 쿼리 방식을 생각하지 않고 객체를 기반으로 테이블을 설계하는 경우가 많습니다. DynamoDB에서는 데이터를 어떻게 사용할지 알기 전까지 테이블을 설계할 수 없습니다.

액세스 패턴을 미리 알아야 하기 때문에, 많은 사람들은 이것이 시간이 지나도 액세스 패턴이 변경될 수 없다는 의미로 받아들입니다. 그렇지 않습니다! 다른 데이터베이스와 마찬가지로 DynamoDB 데이터 모델도 진화할 수 있습니다. 동일한 일반 DynamoDB 원칙이 적용됩니다—모델링하기 전에 새로운 액세스 패턴을 알아야 합니다—하지만 많은 변경사항은 기존 모델에 추가됩니다. 기존 레코드를 수정해야 할 경우, 그렇게 할 수 있는 간단한 패턴이 있습니다.

이 책의 15장에서 마이그레이션 전략에 대해 논의할 것이며, 22장에서는 이러한 전략이 실제로 어떻게 작동하는지 보여드릴 것입니다.

 

5. DynamoDB를 사용할 때는 스키마가 필요 없다.

DynamoDB(및 다른 NoSQL 데이터베이스)는 종종 스키마가 없다고 불리며, 이로 인해 개발자들은 엔티티와 관계를 미리 설계할 필요가 없어 속도를 얻을 수 있다고 생각합니다.

하지만 진정한 스키마 없는 데이터는 혼돈입니다. 테이블에 작성한 쓰레기를 읽어내는 데 행운을 빕니다.

DynamoDB가 관계형 데이터베이스만큼 스키마를 강제하지 않는 것은 사실이지만, 애플리케이션 어딘가에는 여전히 스키마가 필요할 것입니다. 데이터베이스 수준에서 데이터를 검증하는 대신, 이제는 애플리케이션 수준의 문제가 될 것입니다.

여전히 데이터 모델을 계획해야 합니다. 여전히 객체 속성에 대해 생각해야 합니다. NoSQL을 직무를 소홀히 하는 변명으로 사용하지 마세요.

이러한 오해를 부분적으로 해소했으니, 이제 DynamoDB가 무엇인지 살펴보겠습니다.