MongoDB 선택 이유 및 MongoDB에서 RDB+MongoDB로 변경

회사 이직한지 1개월 째, 화주와 포워더 간 물류 플랫폼 서비스인 ZIMGO 개발에 참여하게 되었다.

ZIMGO에서 서류함을 개발하게 되었는데, 서류함은 Packing List, Commercial Invoice 등 수/출입에 필요한 문서를 유저가 생성 및 관리하는 기능이었다. 

MongoDB 선택 이유

서류함 개발에 MongoDB를 사용하기로 했는데, 이유는 문서의 특징 때문이었다.

 

- 문서의 종류가 여러가지이다. (비정형 데이터)

- 검색할 때는 여러 종류의 문서가 함께 조회되어야 한다. 

- RDB로 하면 하나의 문서를 조회할 때, 여러 테이블 간의 복잡한 Join이 필요하다.

- 문서마다 데이터 형태가 다르므로, 테이블 설계가 어렵다. 

- 반면, MongoDB는 문서의 내용 전체를 JSON으로 저장할 수 있다.

- MongoDB는 테이블 설계가 필요없고, 테이블 간의 Join할 필요없다.

- MongoDB도 조회 기능을 제공한다.

MongoDB 문제점

MongoDB로 선택하고, 개발에 들어가려고 했는데 커뮤니티에서 아래와 같은 글을 발견하게 되었다.

질문 내용은 '데이터가 자주 보는 메인 페이지에 사용되고, 검색 조건과 여러가지 필터 및 정렬 조건이 가능해야 되는데 MongoDB로 어떻게 기능을 구현하는가'였다.

 

 

아래는 답변이다.

 

서류함의 문서 정보도 메인 페이지에서 자주 조회되고, 여러 필터와 정렬 조건이 있었기 때문에 글을 읽고 팀에 공유하였다. 아래와 같은 의견들로 우선 MongoDB로만 개발하기로 하였다.

 

- 개발 일정이 촉박하다

- 커뮤니티 글이라 신뢰성이 떨어진다

- Azure의 CosmosDB 중 MongoDB를 사용하고 있기 때문에 그냥 MongoDB와는 다를 수도 있다.

 

MongoDB로만 개발을 완료하였는데, 우려했던 조회 관련 이슈들이 나왔다.

 

- 필터와 정렬 조건이 많기 때문에 인덱싱이 매우 복잡하다.

- MongoDB 인덱스 자체가 사용하는 용량이 컸고 조회 성능도 느렸다.

- CosmosDB의 document의 id로만 1000건 조회 시 2초 정도 걸렸다. 

해결 방안

이슈 해결을 위해, 다음 2가지 해결 방안이 나왔다.

1. CosmosDB라 조회 성능이 안나오는 걸 수도 있다. AtlasDB를 사용해보자.

2. 메인 조회는 RDB를 사용하고, 문서 상세 조회는 CosmosDB의 MongoDB로 데이터를 가져오자. 

 

RDB만 사용하는 것은 문서의 비정형화된 패턴과 이로 인한 복잡한 테이블 설계 및 조인 문제로 제외됐다.

 

AtlasDB를 사용하면, MongoDB만 사용하는 것이므로 개발 소스를 변경할 필요가 없었다. 

하지만, AtalsDB를 사용할 시 성능이 잘나온다는 보장이 없었고, 그만큼 성능을 테스트하기 위해선 무료 버전으로는 불가능했다. 테스트 만을 위해서라도 40만원 상당의 비용 지출이 필요했다. 

또한, 모두 MongoDB 도입이 처음이어기 때문에 MongoDB 설계 관련 전문가가 없었다.

 

RDB와 MongoDB 혼용은 메인 조회를 위한 테이블 설계와 그에 맞는 개발 소스 변경이 필요했다.

 

결론적으로, RDB와 MongoDB를 혼용해서 사용하기로 했다.

RDB와 MongoDB 혼용

메인 페이지에 나오는 검색 결과, 검색 조건, 필터 조건에 해당하는 것은 모두 RDB에도 넣기로 했다.

메인 페이지 조회를 위해 아래와 같이 테이블을 설계했다.

 

우선 문서를 MongoDB에 저장하고, 문서 내용을 다시 RDB의 테이블에도 저장한다.

핵심은 MongoDB의 ID도 같이 저장하는 것이다.

문서 ID	MongoDB ID	문서 이름	검색 조건1	검색 조건2	필터 조건1	필터 조건2
Long	String	String	String	String	String	String

 

메인 조회 페이지에서 검색할 때는 RDB 테이블만 이용한다.

문서 상세 내용을 조회할 때는 서버에 문서 ID를 보내주면 RDB에서 MongoDB ID를 찾아 MongoDB에서 문서 내용을 가져온다.

 

개인적으로, 인덱싱과 조회 성능에서의 RDB 장점과 복잡한 조인이 필요 없이 문서를 저장할 수 있는 MongoDB의 장점모두 활용할 수 있는 방법이라고 생각한다.

 

RDB와 NoSQL 혼용 시 고려한 문제점은 조회 기능이나 필터 조건이 추가되면 RDB 테이블에 새로운 컬럼이 추가되어야하고,  MongoDB의 내용을 새 컬럼에 넣어줘야 한다는 것이다. 이 문제점은 추후에 기능 추가 시, MongoDB의 데이터를 RDB에 업데이트하는 것을 개발하기로 했다.