MongoDB 데이터 모델링
MongoDB 데이터 모델링 (Data Modeling)
MongoDB 데이터 모델링은 데이터를 어떤 구조로 저장하고, 관련 엔티티끼리 어떻게 이어줄지를 정하는 일이에요. 관계형 데이터베이스처럼 스키마를 먼저 고정하지 않아도 되다 보니, 애플리케이션의 접근 패턴에 맞춰 자유롭게 데이터 구조를 잡아갈 수 있어요. 여기서는 MongoDB만의 유연한 데이터 모델이 어떤 원칙으로 움직이는지, 관계형 DB와 무엇이 다른지 하나씩 살펴볼게요.
유연한 데이터 모델
MongoDB는 **유연한 데이터 모델(flexible data model)**을 제공해서 다형적(polymorphic) 데이터를 저장할 수 있어요. 한 컬렉션에 들어 있는 도큐먼트들이 반드시 같은 필드 구성을 가질 필요가 없다는 뜻이에요. 예를 들어 products 컬렉션이라 했을 때, 어떤 도큐먼트는 price 필드가 있고 어떤 도큐먼트는 배송 관련 필드만 있어도 함께 저장됩니다.
데이터 모델링의 핵심 원칙은 함께 읽히는 데이터는 함께 저장한다는 것이에요. 애플리케이션이 실제로 어떻게 데이터를 꺼내 쓰는지(data access pattern)를 기준으로 구조를 정해야 성능을 최적화할 수 있어요.
MongoDB의 유연한 스키마는 개발하면서 데이터 모델을 반복적으로 개선할 수 있게 해줘요. 처음에는 단순하게 시작해서, 요구사항이 바뀌면 필드를 추가하거나 도큐먼트 구조를 다시 정리하면 되니까, 정교한 스키마 설계가 필요한 순간까지 기다렸다가 개선해도 됩니다.
도큐먼트와 관계 표현
도큐먼트 필드의 값에는 BSON 데이터 타입이 모두 들어갈 수 있어요. 다른 도큐먼트, 배열, 배열 안의 도큐먼트까지도 값이 될 수 있죠. 이 성질을 이용해서 서로 다른 유형의 관계를 표현할 수 있어요.
- 일대일(One-to-one): 한 도큐먼트가 정확히 하나의 도큐먼트와 연결돼요. 환자는 정확히 하나의 진료 기록을 갖는 경우가 대표적이에요.
- 일대다(One-to-many): 한 도큐먼트가 여러 도큐먼트와 연결돼요. 웹 애플리케이션 사용자 하나가 많은 게시글이나 댓글을 갖는 상황이에요.
- 다대다(Many-to-many): 서로 여러 도큐먼트와 연결될 수 있어요. 학생은 여러 과목에 수강하고, 각 과목은 여러 학생을 갖는 경우가 그 예예요.
관계를 모델링할 때는 데이터를 **임베딩(embedding)**할지, **레퍼런스(referencing)**로 참조할지 선택해요. 임베딩은 관련 데이터를 하나의 도큐먼트 안에 넣는 방식이고, 레퍼런스는 별도 도큐먼트의 _id를 값으로 들고 있어 나중에 조회하는 방식이에요. 애플리케이션의 접근 패턴에 더 잘 맞는 쪽을 고르면 됩니다.
관계형 DB와의 스키마 설계 차이
문서 데이터베이스 스키마를 설계할 때는 관계형 DB와 다음과 같은 차이를 기억해야 해요.
| 관계형 데이터베이스 | 문서 데이터베이스 |
|---|---|
| 데이터를 넣기 전에 테이블 스키마를 먼저 정해야 해요. 고정 스키마라 변경 시 의존 레퍼런스 영향까지 미리 계획해야 하죠. | 요구사항이 변하면 데이터 모델을 그때그때 쉽게 바꿀 수 있어요. |
| 애플리케이션이 필요한 데이터를 얻으려면 여러 테이블을 조인해야 하는 경우가 많아요. | 유연한 데이터 모델 덕분에 접근 패턴에 맞게 데이터를 저장할 수 있어요. 데이터를 임베딩하면 여러 컬렉션에 걸친 복잡한 조인을 피하면서 성능을 높이고 부하도 줄일 수 있어요. |
관계형 DB가 "정규화 + 조인"으로 데이터를 쪼개는 데 익숙하다면, MongoDB는 반대로 "함께 쓰는 데이터를 한 도큐먼트에 모으는" 쪽으로 사고를 바꾸는 게 핵심이에요.