- 도입을 희망하는 기술
<aside>
MongoDB
- 오픈소스 NoSQL 문서 지향 데이터베이스
</aside>
- 기술 설명
<aside>
MongoDB는 문서 지향 NoSQL 데이터베이스로, JSON과 유사한 BSON(Binary JSON) 형태로 데이터를 저장한다. 이 프로젝트에서는 설문 조회 전용 데이터베이스로 활용하여, PostgreSQL의 메인 데이터와 별도로 빠른 읽기 성능을 제공하는 읽기 전용 복제본 역할을 담당한다.
</aside>
- 기술 장점
<aside>
- 스키마 유연성과 JSON 지원: MongoDB는 스키마가 없는(Schema-less) 구조로 설문의 다양한 옵션과 질문 정보를 유연하게 저장할 수 있다.
- PostgreSQL의 JSONB도 JSON 데이터를 지원하지만, MongoDB는 문서 단위로 최적화되어 있어 설문 데이터의 **중첩된 구조(질문-선택지)**를 더 효율적으로 처리할 수 있다.
- Redis는 캐시 용도로만 적합하고, 복잡한 쿼리나 집계 연산에는 한계가 있다.
- 읽기 성능 최적화: MongoDB는 메모리 기반의 인덱싱과 문서 지향 구조로 인해 복잡한 조인 없이도 설문 전체 정보를 단일 쿼리로 조회할 수 있다.
- PostgreSQL에서는 설문, 질문, 선택지를 조회하기 위해 여러 테이블 JOIN이 필요하지만, MongoDB에서는 하나의 문서에 모든 정보가 포함되어 있어 조회 성능이 우수하다.
- 수평적 확장성: MongoDB는 샤딩을 통해 데이터를 여러 서버에 분산 저장할 수 있어, 설문 데이터가 대용량으로 증가해도 읽기 성능을 유지할 수 있다.
- Spring Data MongoDB 통합: Spring Boot와의 완벽한 통합으로
@Document, MongoTemplate 등을 활용한 간편한 개발이 가능하다.
</aside>
- 단점 / 한계점 / 주의사항
<aside>
- 데이터 일관성: MongoDB는 ACID 트랜잭션을 완전히 지원하지 않아 데이터 정합성에 취약할 수 있다. 하지만 이 프로젝트에서는 읽기 전용 복제본으로만 사용하므로 이 문제는 최소화된다.
- 복잡한 쿼리 제한: 관계형 데이터베이스의 JOIN이나 복잡한 집계 함수에는 제한이 있다. 하지만 설문 조회라는 단순한 용도에는 충분하다.
- 메모리 사용량: MongoDB는 인덱스와 자주 사용되는 데이터를 메모리에 유지하므로, 메모리 사용량이 높을 수 있다. 하지만 읽기 성능 향상이라는 목적에는 적합하다.
- 데이터 동기화 복잡성: PostgreSQL의 메인 데이터와 MongoDB의 읽기 데이터 간 동기화 로직이 필요하며,
SurveyReadSyncService를 통해 비동기 동기화를 구현해야 한다.
</aside>
- 도입 배경과 필요성
<aside>
현재 프로젝트는 PostgreSQL을 메인 데이터베이스로 사용하고 있지만, 설문 조회 시 복잡한 JOIN 쿼리와 여러 테이블 스캔으로 인해 조회 성능에 한계가 있었다. 특히 설문 목록 조회나 상세 조회 시 응답 시간이 길어지는 문제가 발생했다.
따라서 MongoDB를 도입하여 읽기 전용 설문 데이터베이스를 구축할 필요가 있었다.
- 조회 성능 향상: 설문, 질문, 선택지 정보를 하나의 문서에 통합 저장하여 단일 쿼리로 모든 정보 조회가 가능하다. 이는 특히 설문 목록을 조회할 때 성능 향상을 가져온다.
- 메인 DB 부하 분산: PostgreSQL에서 빈번한 조회 쿼리를 MongoDB로 분산시켜 메인 DB의 부하를 줄이고 전체적인 시스템 성능을 향상시킨다.
- 비즈니스 로직과 조회 로직 분리: CQRS 패턴을 적용하여 데이터 수정은 PostgreSQL, 데이터 조회는 MongoDB로 역할을 분리하여 시스템의 확장성과 유지보수성을 향상시킨다.
- 설문 데이터 특성에 최적화: 설문 데이터는 계층적 구조(설문-질문-선택지)를 가지며 자주 조회되지만 수정은 적게 일어나는 특성이 있어, MongoDB의 문서 지향 구조와 읽기 최적화 특성에 매우 적합하다.
이를 통해 설문 조회 API의 응답 시간을 단축하고, 사용자 경험을 향상시키며, 시스템의 전체적인 성능과 확장성을 개선할 수 있다.