목차

• 프로젝트 개요
• 문제 인식
• 해결 방안
• 사용 기술
• 실행 방법
• 시사점

프로젝트 개요

MySQL과 MongoDB의 Latency 비교 및 샤딩에 대한 연구

• NoSQL과 RDBMS에 수백만 row의 데이터를 각각 삽입한 후 텍스트 서치 API를 구현했을 때의 Latency를 비교
• 각 데이터베이스의 캐싱, 인덱싱, I/O 특징 및 샤딩의 필요성 연구

• 페이지네이션
• 데이터베이스 토글
• Concurrency 토글

문제 인식

1. 수백만 텍스트 Row가 있을 때 NoSQL(MongoDB)과 RDBMS(MySQL)의 쿼리 및 API 성능에 대한 분석이 필요
2. 각 데이터베이스에 샤딩이 필요하게 되는 데이터 Row 수 및 양에 대한 고찰 필요
3. React 18에서 도입된 Concurrency Worker 모델에 대한 성능 검증 필요

해결 방안

1. 수백만 기사 데이터를 각 데이터베이스에 삽입, UI 구현하여 다양한 조건에서의 쿼리 및 API 속도 비교분석
2. VM 서버 간 TCP 연결 및 DB 보안, 분산 시스템 적용 등 네트워크 관리, 캐싱, 텍스트 키워드 인덱싱 처리 등 DB 설계
3. 데이터베이스 및 Concurrency 토글 기능 개발

사용 기술

• React 18 (Concurrency)
• Express 4.8
• MySQL, MongoDB
• Nginx

실행 방법

1. git clone [email protected]:z3zzz/database-comparison.git
2. 환경변수 설정 (MYSQL_URL, MONGODB_URL)
3. 데이터 삽입 (각 데이터베이스)
4. 서버 실행

cd back;
yarn install;
yarn start;

6. 클라이언트 실행

cd front;
yarn install;
yarn start;

차별점

1. 하나의 API 프레임워크에서 복수의 Database 서버 연결 및 실시간 토글 기능
2. 수백만 텍스트 Row에 대한 인덱싱, 캐싱 및 각 데이터베이스 별 특성 비교
3. 3개 서버로 구현된 분산 시스템
4. 코드 재사용성과 3계층 구조, 루즈 커플링 등 Back-End 설계 방법론에 대한 이해 및 적용

시사점

1. 300만 row의 경우 캐싱, 인덱싱 미적용 시 MySQL(2초 이하)이 MongoDB(5초 이하) 대비 우수 / 캐싱, 인덱싱 적용 시 MySQL(1.1초 이하)과 MongoDB(1.3초 이하) 성능 유사
2. MongoDB의 경우 자동 캐싱이 이루어지는데, 이로인해 텍스트 서치 시 응답 시간의 일관성이 매우 낮음 (최소 0.5초, 최대 5초) / MySQL의 경우 응답 시간의 일관성이 높음
3. 인덱싱 적용 시 응답시간 평균 1초 내외로 사용자 경험 측면에서 큰 문제가 되지 않음 / 추가 리소스 사용 및 서비스 복잡도를 높이는 샤딩은 수백만 데이터 수준에서는 불필요함
4. 서비스 개발 시 DB 선정 및 설계는 해당 DB의 특징(예를 들어 MongoDB의 자동 캐싱 및 RAM 관리의 필요성), 인덱싱 적용 시의 성능, 서비스의 목적 및 사용자 경험을 모두 고려하여 신중하게 결정해야 하며, 샤딩은 최후의 수단으로 그 이전에 파티셔닝, 캐싱, 인덱싱을 우선 시도해야 함
5. 분산 시스템에서 DB 전환 시 Back-End 서버에의 영향은 DB pool에 연결할 때 사용하는 패키지뿐이며, 컨트롤러와 서비스 로직은 그대로임. 따라서 3계층 구조와 루즈 커플링을 적용하는 것이 코드 재사용률을 극대화할 수 있음
6. React 18에 새로 도입된 Transition, Suspense는 특수한 경우(UI 전환 시의 메모리 부하가 큰 경우)에 의미가 있고, 이외에는 큰 용도가 없음