인프런 커뮤니티 질문&답변

Josh B님의 프로필 이미지

작성한 질문수

MongoDB를 활용하여, 200억건 이상의 데이터 파이프라인 작성법

너무 고생하셨습니다.

단일콜렉션과 lookup

해결된 질문

작성

·

30

·

수정됨

1

안녕하세요

좋은 강의 감사합니다. 개념을 확립하는데 정말 도움이 많이 됐습니다. DB구조를 계속 고민하게 되어 질문 남겨봅니다.

상점table-도큐먼트가 10만개(필드20개) 정도 있고, 상품table-도큐먼트가 30만개(필드15개)정도 있는 DB입니다. 이걸 몽고디비 콜렉션에서 어떻게 구성하는 것이 좋을 지 아무리 고민해도 답이 안나와 선배님의 조언을 듣고 싶습니다. Main 검색은 상품명 이고 프론트에는 지역기반 필터가 있습니다. (지역은 상점과 상품 모두 필드로 포함)

강의를 듣고 내린 결론은 1도큐먼트로 통합인데 아래 3가지로 고민을 했었습니다.

 

  1. 상점과 상품을 one 도큐먼트로 통합 후 1 Collection 구성 ->30만 도큐먼트 (상품기준, 상점중복저장,필드25개)

  2. 상점 콜렉션에 상품을 어레이필드로 저장 -> 10만도큐먼트 (상점기준, 중복저장없음, 필드 21개)

  3. 각각의 콜렉션 후 lookup

  4. 상품 콜렉션에 상점을 어레이필드로 저장

저는 1번이 가장 빠를 것 같은데 조언 부탁드립니다.

 

감사합니다.

 

 

 

 

 

답변 2

0

July님의 프로필 이미지
July
지식공유자

2024. 09. 27. 21:27

일단 어디까지나 저의 개인적인 의견이지만 의견을 전달해드릴게요.

일단 DB선정을 RDB로 하시는것을 추천드립니다.

 

어디까지나 저의 의견이지만 상점에 여러가지의 상품이 무제한적으로 추가될수있다는 가정이 들어가 있습니다.

 

이런 경우에는 하나의 컬렉션에 Array형태로 저장하는것은 매우 잘못되었습니다. Array형태로 저장하는것은 어느정도 정해지거나 감당가능한 데이터를 저장할 때 사용해야합니다.

 

그래서 이 기준에 따라서 무조건적인 분할이 필요합니다. 그래서 lookup이 필수적으로 들어가게 될 거 같습니다.

그리고 lookup이 들어가도 큰 문제는 없어 보여요 쿼리를 두번 전송하거나 기본적으로 상품들에 대해서 상점이라는 강력한 match조건이 있기 때문이죠.

 

근본적으로는 이런 구조는 RDB가 가장 좋기는합니다. 제가 잠시 외부에서 모바일로 답변을 드린거라 잘못이해거나 설명이 잘못된 부분이 있을 수 있는데 혹시 추가적인 질문있다면 댓글 남겨주시면 감사하겠습니다.

 

Josh B님의 프로필 이미지
Josh B
질문자

2024. 09. 27. 21:59

답변감사드립니다!

몽고로 결정한 이유는 atlas search때문입니다. 엘라스틱을 직접 적용하는 것 보다 더 빠르게 배우고 적용이 가능할 것 같아서요. 샤딩, 클러스터링 이런 부분까지 감당할 수 없어서 매니지형으로 알아보다 보니 몽고디비까지 왔습니다. RDB를 사용하며 atlas만큼의 서비스를 제공하는 곳이 또 있을까요?

July님의 프로필 이미지
July
지식공유자

2024. 09. 27. 22:13

음 찾아본다면 있을수도 있겠지만 보통은 그냥 따로 분할해서 따로관리합니다. Msa가 보편화됨에따라 elastic과 mysql을 혼용해서 사용하는 상황입니다.

 

이는 어디까지나 제 상황이니 참고만해주세요.

July님의 프로필 이미지
July
지식공유자

2024. 09. 27. 22:13

그럼 일단 mongo를 사용해야하니 어쩔 수 없는 상황이니 lookup은 필수적으로 필요한 상황으로 보이네요 ㅠ

Josh B님의 프로필 이미지
Josh B
질문자

2024. 09. 27. 22:17

답변 감사드립니다. 갔다가 이길이 아니면 다시 돌아와야죠...

0

인프런 AI 인턴님의 프로필 이미지

2024. 09. 27. 20:56

안녕하세요, 인프런 AI 인턴입니다. Josh B님.

MongoDB 컬렉션 구성에 대해 고민하고 계시군요! 이와 관련된 기존 질문과 유사한 답변을 아래에 공유드립니다.

강사님께서 비슷한 주제에 대해 답변하신 게시물을 참고하시면 도움이 될 것입니다:

다음은 일반적인 답변 요약입니다:

  1. 단일 도큐먼트로 통합:

    • 하나의 상품 도큐먼트에 상점 정보를 포함하여 1개의 컬렉션을 만드는 방식입니다.
    • 통합된 도큐먼트 수: 약 30만 개
    • 이 방법의 장점은 간단한 구조와 빠른 조회 속도입니다. 필터링이나 정렬 작업에서 성능 이점을 얻을 수 있습니다.
  2. 상점 콜렉션에 상품을 어레이 필드로 저장:

    • 상점 도큐먼트 내에 상품 정보를 배열로 포함하는 방식입니다.
    • 통합된 도큐먼트 수: 약 10만 개
    • 이 방법은 중복 저장을 피하고 데이터 일관성을 유지할 수 있습니다. 그러나 배열 크기가 클 경우 일부 성능 저하가 있을 수 있습니다.
  3. 별도의 컬렉션을 사용하고 lookup:

    • 상점과 상품을 각각 별도의 컬렉션에 저장하고 필요할 때 조회 조인을 수행하는 방식입니다.
    • 이 방법은 데이터 분할과 관리가 용이하지만 조인 작업에서 성능이 다소 저하될 수 있습니다.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.

Josh B님의 프로필 이미지
Josh B
질문자

2024. 09. 27. 21:18

AI 답변은 이미 알고 있는 내용

Josh B님의 프로필 이미지

작성한 질문수

질문하기