차트 데이터 조회 시 기간별 뉴스 목록을 매핑해야할 때 MySQL, MongoDB성능 비교 (jade)

[Lcrescent3es]

프로젝트에서 고려중에 있는 MongoDB에 대해 MySQL과 비교분석할 예정입니다
현재 서비스에서 차트 조회 시 1~5년치 차트 데이터와 각 날짜에 맞는 뉴스 목록을 매핑해서 조회해야합니다.
n명의 유저가 요청을 보낼 때, DB의 데이터를 조회하는데 MySQL과 MongoDB 각각의 DB에서 성능이 어느정도 차이가 나는지 확인하기 위함입니다.
데이터의 변형은 없으며, 순수 Joined select 성능만 비교할 예정입니다.
지표: throughput/s
데이터: chart, news data(1년치, 5년치)
테스트케이스:
chart Read
news Read
chart, news Join Read (1회, 100회, 10000회, 100000회 요청)

------24/08/29(목)------

1. 딥다이브 방향 잡기

• 주제를 추가하려는 이유: MySQL과 MongoDB 성능 측정만으로는 이미 나와있는 블로그가 많고, 데이터만 쌓인다면 금방 끝날 것 같아서 추가했습니다
• 환경: 비교하는데 사용할 프레임워크와 ORM: SpringBoot, JPA (Joined query는 JPQL로)
• MySQL과 MongoDB 각각의 특징과 차이점에 대해 정리
• 개념적 딥다이브, 실습 추가
• MySQL과 MongoDB 순수 데이터 Join 성능 비교
  a. MySQL과 MongoDB 테이블 구조 동일하게 가져간 후 Joined query
  b. MongoDB에 뉴스와 차트를 JSON 형태로 저장 후 MySQL만 Joined query
  c. MySQL 인덱싱 후 Joined query

2. 추가 주제 1:

• SpringBoot의 기능을 활용해 MySQL과 MongoDB의 성능 향상 (고려중: DB 조회 결과를 JPA 2차 캐시의 entity 기준이 아닌, 캐싱하여 joined query 횟수를 최소화 - 해당 방법은 스프링의 메모리 사용량도 비교할 예정입니다)
• Elasticache Redis 캐싱과 proxy 캐싱 성능 비교(메모리 사용량, 속도)

3. 추가 주제 2:

• 클러스터링 MySQL, MongoDB에서 data insert 및 join read 성능 측정 (고가용성 서버의 분산 데이터베이스에서 joined query시 성능을 비교하기 위함입니다)

난이도별로 추가 주제를 설정했고, 추가 주제는 기존 주제가 완료될 시 단계별로 진행할 예정입니다.
다만, DB 설정을 현재 프로젝트 서버가 아닌, 데이터만 복사하여 개인 RDB, ElastiCache에서 진행해야할지 고려중입니다.

###오늘의 딥다이브 내용 - Overview

• 자료1�
• 자료2

1. MySQL

• 오픈소스 기반 RDBMS, 크로스 플랫폼 지원
• 동시성 관리, 트랜잭션, 정규화 기능 지원
• 커넥션 풀 기법으로 연결을 제어
• 수정 및 유지보수, 접근 제어 용이
• 데이터베이스 스키마를 통해 가시성 향상, 정형화된 데이터를 다룸으로써 관리에 용이
  a. 트랜잭션 - ACID 속성
  - 데이터베이스 시스템에서 트랜잭션이 안전하게 수행된다는 것을 보장한다는 속성
  - 원자성 (Atomicity): 트랜잭션과 연관된 모든 작업들이 반드시 실행되거나, 전혀 실행되지 않았다는 것을 의미
  - 일관성 (Consistency): 트랜잭션의 작업을 성공적으로 완료하면 데이터베이스를 일관된 상태로 유지
  - 고립성 (Isolation): 트랜잭션이 수행 중 다른 트랜잭션의 접근을 허용하지 않음
  - 지속성 (Durability): 트랜잭션이 성공적으로 수행되면 결과가 영원히 반영됨 (시스템 문제, DB 관리 체크 등 내부 로직에 의해 변형되지 않음)

장점

• 데이터 중복 최소화
• 데이터 무결성, 일관성 유지
• 데이터 보안

단점

• 운영, 관리비용이 시간에 비례하여 증가
• 데이터베이스 설계의 어려움
• 중앙제어식 관리 시스템의 취약성
• 대규모 데이터 관리의 어려움

2. MongoDB

• NoSQL 오픈 소스 데이터베이스
• 확장성, 유연성 면에서 RDBMS보다 유리함
• CAP 이론
  a: 분할 내성 (Partition tolerance): 메시지 전달이 실패하거나 시스템 일부가 망가져도 계속 동작
  • C, A는 트랜잭션 ACID의 A, C와 같다.
  • C A P 세 속성 중 두 속성만 보장할 수 있다는 특징이 있다.
  • mongoDB는 1차 노드와 데이터를 백업하는 2차 노드의 형태로 클러스터링하여 일관성을 보장한다.
  • 특정 노드가 실패하여 네트워크 파티션이 발생하면, 분할이 해결될 때 까지 쓰기 작업을 중지한 뒤 일관성이 보장되지 않는 노드를 종료하고, 연결을 재설정하여 일관성과 분할 내성을 보장한다.
• BSON (Binary JSON) 형태로 데이터를 저장

장점

• 정형화되지 않은 데이터를 다루기 좋다
• SQL을 지원하여 RDBMS에서 마이그레이션하기 용이하다

단점

• 데이터를 입력할 때 field값도 같이 입력하는 경우가 많아, RDBMS보다 많은 저장공간을 필요로 한다
• 데이터 중복을 관리하기가 어렵다

------24/09/12(목)------

1. 성능 측정 메서드 조사

• Spring의 Stopwatch 사용
• 참고 블로그 링크

TimeTrace

/**
 * Timer AOP - interface
 * target: METHOD
 * Annotation retentions in RUNTIME
 */
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface TimeTrace {
}

• Controller에 proxy를 적용하기 위해 선언한 어노테이션

TimeTraceAspect

@Slf4j
@Component
@Aspect
public class TimeTraceAspect {
    @Pointcut("@annotation(com.example.deepdive.config.TimeTrace)")
    public void timeTracePointCut() {
    }

    @Around("timeTracePointCut()")
    public Object timeTraceAround(ProceedingJoinPoint joinPoint) throws Throwable {
        StopWatch stopWatch = new StopWatch();

        try{
            stopWatch.start();
            return joinPoint.proceed(); // 실제 타겟 호출
        } finally {
            stopWatch.stop();
            log.debug("{} - total time: {}ms",
                    joinPoint.getSignature().toShortString(),
                    stopWatch.getTotalTimeMillis()
            );
        }
    }
}

• Aspect + Advice code
• 메소드 호출 이전 StopWatch.start(); 호출
• 메소드 종료 시점에 StopWatch.stop(); 호출
• 이후 실행한 메소드명, 경과 시간을 ms기준(second는 너무 길고, nanosecond는 과하다고 생각하여 milisecond로 조정)으로 표시

- StopWatch.prettyPrint() 메소드로 교체하는 방안도 고려중

issue

• StopWatch의 실제 시간 측정 delay가 약 5~10ms로 예상됨
• MySQL, mongoDB의 연결시간을 측정한 후, 측정된 시간에서 차감하는 방식으로 delay를 배제할 예정

application.yml

...
spring: 
  jpa:
    show-sql: true
    hibernate:
      ddl-auto: none
    properties:
      hibernate:
        dialect: org.hibernate.dialect.MySQLDialect
        format_sql: true
        use_sql_comments: true
        generate_statistics: true
...
logging:
  level:
    org.hibernate.SQL: DEBUG
    org.hibernate.type: TRACE
    root: DEBUG
    io.lettuce.core: DEBUG
    io.netty: TRACE
...

• hibernate와 logback의 DEBUG log를 조회 가능하도록 설정
• hibernate의 쿼리 과정을 조회 가능하도록 설정
• lettuce와 netty는 추후에 사용할 redis 로깅 용도

2. 딥다이브 테스트 아키텍쳐

• Spring: local (macOS M3 pro)

• MySQL: aws RDB

• MongoDB: aws Document DB

• Redis: aws ElastiCache

• 단, 기존 DB를 이용하지 않고 새로운 DB를 사용하려면(Redis) 기존 서비스 RDB에 있는 데이터를 새로운 RDB와 Document DB로 옮기는 작업이 필요

3. Test case 추가 고려

• select query에 대해 unit test 외에도 load test를 추가로 진행, MySQL과 MongoDB의 서비스 내구성을 테스트 하는것이 어떨지 고려중
• 요금이 많이 나올 수 있어 신중히 고려할 필요가 있음

4. MongoDB TC 보완

• joined query: document간(chart-news) 참조를 지정한 후 $lookup 연산을 진행
• 하나의 문서로 저장: Embedded Documents 기능 활용
• 링크

------24/09/26(목)------

1. AWS Document DB와 Atlas 비교

• 링크
• MongoDB가 작성한 DocumentDB vs Atlas 문서를 참고했습니다.
• 해당 문서를 보면, 매우 강력하게 DocumentDB보다 Atlas가 낫다고 어필하는 분석 결과를 확인할 수 있습니다

• 그래서 documentDB가 아닌, MongoDB의 Atlas로 테스트를 진행하려고 합니다.

• 일단 M0 Sandbox(무료 버전)로 클러스터를 생성했는데, 후에 유료 버전으로 전환할 예정입니다.
  • 원인: 용량 제한
    • MongoDB의 무료 버전은 스토리지 최대 용량이 500MB인 반면, 유료버전은 2GB~1TB까지 넉넉한 저장공간을 가지고 있습니다.

  - 용량이 부족하다면 M2 cluster로 업그레이드 할 예정입니다.

2. 목업 데이터 세팅

• 현재 차트 목업 데이터는 전부 마련되었고, 뉴스 데이터는 2024.04~2024.08 기간동안의 데이터가 마련되었습니다.
• 2023.08~2024.08 기간동안의 뉴스 데이터를 마련할 때 까지 크롤링 작업을 진행하고 있습니다.
• 뉴스 데이터 마련이 끝나면 MongoDB에 데이터를 입력한 후 테스트를 진행할 예정입니다.

[startupcodekr]

왜 성능 비교해야하는지 프로젝트 시나리오 기준으로 제목을 작성해주세요