MongoDB vs Spring Data JPA 정리

MongoDB vs Spring Data JPA 정리

1. 기본 개념 차이

JPA (RDB 기반)

• JPA는 객체(Entity)를 관계형 데이터베이스 구조에 맞게 변환해서 저장한다.
• 내부적으로는 Hibernate가 SQL을 자동 생성해서 DB(PostgreSQL 등)에 전달한다.

Entity 객체 → JPA → SQL 생성 → RDB 저장

MongoDB (NoSQL 기반)

• MongoDB는 객체를 그대로 JSON(Document 형태)로 저장한다.
• Spring Data MongoDB는 객체를 BSON(JSON 기반 바이너리)으로 변환해서 저장한다.

객체 → 그대로 Document(JSON) → MongoDB 저장

---

2. 저장 방식의 핵심 차이

JPA

• 테이블 기반 (행/열 구조)
• 정규화된 구조
• 관계 중심 (JOIN 사용)

예:

users
comments
comment_likes
article_views

→ 조회 시 JOIN 필요

---

MongoDB

• 문서(Document) 기반
• 비정규화(역정규화) 구조
• 한 문서에 필요한 데이터 몰아서 저장

예:

{
  userId: "...",
  recentComments: [...],
  commentLikes: [...],
  articleViews: [...]
}

→ 조회 시 한 번에 가져옴 (JOIN 없음)

---

3. 조회 방식 차이

JPA

• 데이터를 "쌓아두고"
• 조회 시점에 계산

SELECT ...
FROM comments
ORDER BY created_at DESC
LIMIT 10

→ 매번 계산

---

MongoDB

• "조회용 데이터"를 미리 만들어둠
• 최신 데이터만 유지 (예: 최근 10개)

recentComments 리스트에 항상 10개 유지

→ 조회 시 계산 없음 (바로 응답 가능)

---

4. 역할 분리 구조 (현재 프로젝트 기준)

RDB (JPA)

• 원본 데이터 저장
• 댓글, 좋아요, 사용자, 기사 등

MongoDB

• 조회 최적화용 데이터
• 사용자 활동 내역 (마이페이지 등)

즉:

RDB = Write 모델 (정확한 데이터)
MongoDB = Read 모델 (빠른 조회)

---

5. Document vs DTO 분리 이유

핵심 개념

• UserActivityDto → API 응답용
• UserActivityDocument → MongoDB 저장용

둘은 역할이 완전히 다르다.

---

6. 왜 DTO를 그대로 Mongo에 저장하면 안 되는가

겉보기에는 구조가 거의 같지만, 재사용하면 문제가 생긴다.

문제 1: API 변경 영향

예:

articleTitle → title

→ DTO 변경인데 Mongo 구조까지 깨짐

---

문제 2: 내부 필드 필요

Mongo에는 이런 필드가 필요할 수 있음:

updatedAt
deleted
sortKey

→ DTO에는 필요 없음

---

문제 3: 계산 필드

DTO에는 이런 필드가 있을 수 있음:

likedByMe

→ Mongo에는 저장 안 할 수도 있음

---

결론

DTO ≠ Document

• 구조는 비슷해도 된다
• 클래스는 반드시 분리한다

---

7. Item 구조가 필요한 이유

MongoDB Document 내부에는 "하위 객체"가 필요하다.

예:

UserActivityDocument
  └ CommentItem
  └ SubscriptionItem
  └ ArticleViewItem

이 Item은:

• DTO가 아니라
• MongoDB 내부 저장용 모델

---

데이터 흐름

저장 흐름

댓글 작성 / 좋아요 / 조회
→ UserActivityUpdateService
→ Document 내부 Item 추가
→ MongoDB 저장

조회 흐름

MongoDB 조회
→ UserActivityDocument
→ DTO 변환
→ 클라이언트 응답

---

8. 왜 Document와 DTO 구조가 비슷한가

이 프로젝트에서는 의도적으로 비슷하다.

이유:

• MongoDB를 조회용 스냅샷 저장소로 쓰기 때문

즉:

MongoDB = "API 응답 미리 만들어둔 상태"

---

9. final을 사용하지 않는 이유

MongoDB Document 필드에서 final을 쓰지 않는 이유:

이유 1: Spring Data 매핑 문제

• MongoDB → 객체 복원 시 필드 주입 필요
• final이면 재할당 불가

---

이유 2: 리스트 교체 필요

활동 내역은 이런 식으로 갱신 가능:

기존 리스트 → 새 리스트로 교체

final이면 불가능

---

이유 3: 의미 없음

final List<CommentItem>

→ 리스트 내부는 여전히 변경 가능

---

결론

Document 필드에는 final 사용하지 않는 것이 안전

---

10. BSON 개념

• BSON = Binary JSON
• MongoDB 내부 저장 포맷

겉으로는 JSON처럼 보이지만:

{ "id": "...", "comments": [] }

실제로는:

Binary 형태로 저장

---

11. 요약

JPA
- 관계형
- SQL 기반
- JOIN 사용
- 원본 데이터 저장

MongoDB
- 문서형
- JSON 기반
- JOIN 없음
- 조회 최적화용

---

최종 구조 정리

[ RDB ]
User / Comment / Like / Article
  ↓
(이벤트 발생)
  ↓
[ MongoDB ]
UserActivityDocument (스냅샷)
  ↓
[ API ]
UserActivityDto 응답