대용량 데이터 처리 회고 - 1

Ahn yi·2022년 11월 13일
0

java

목록 보기
10/22

대용량 데이터 프로젝트

  • 기간을 길게 잡으니 느슨해진 거 같다. 그러기에 목표 설정이 중요한거 같다. 일정대로 목표를 정하니 목표에 따라 느슨해진 마음도 모르게 움직이게 되었다. 우선 도서 관련 대용량 데이터 수집에 힘을 썼다.

    엑셀로 데이터를 수집하는 와중에 NULL 처리에 대해 조건을 걸었지만 처리가 제대로 되지 않아 애를 먹었다. (NULL체크는 되지만 엑셀 파일 만들어지는 로직에서 에러가 발생했다.)

위와 같이 애를 먹었고, 해결하지 못했지만 엑셀에 있는 정보를 데이터로 변형하는데 힘을 써서, 1600만건이 넘는 데이터를 수집하는데 성공했다. 그 후에, 전체 데이터 조회로 테스트를 진행하였다.

  • 1차 테스트 (Spring Data JPA, Pageable, 검색조건 - size : 10, orderBy : id, isAsc : false) - 데이터 양 : 대략 1600만건
    • 기본 전체 시간 (1 페이지)
      • total mills : 11256 ms
      • total nano: 11256577400 (약 11초)
    • 기본 전체 시간 ((중간 80만)800000 페이지)
      • total mills : 26439 ms
      • total nano: 26439338300 (약 26초)
    • 기본 전체 시간 ( (끝 대략 160만)1637039 페이지 )
      • total mills : 37051 ms
      • total nano: 37051575200 (약 37초)
    • 고민
      • 페이지에 따라 왜 속도가 다른지? - 인덱스?

1차 테스트 결과 위와 같은 결과가 나왔다. 인덱스와 같은 어떠한 조치도 취하지 않고 그저 페이징 처리만 하고 조회한 결과이다.

  • 2차 테스트 (FullText Scan, Spring Data JPA, Pageable, 검색조건 - word : “title”, size : 10) - 데이터 양 : 대략 1600만건
    • 기본 전체 시간 (1 페이지)
      • total mills : 423ms
      • total nano: 423026000(약 0.4초)
    • 기본 전체 시간 (각각의 페이지 )
      • total mills : 4-7 ms
      • total nano: 4652100(약 0.004초)
    • 고민
      • Count 쿼리를 최적화 하려면 어떻게 하면 될까?

2차로 풀 텍스트 인덱스 적용 후의 결과가 저렇게 나왔다.
추가적으로 위와 다르게 해봐야 될 거 같다고 생각하는 것들은 다음과 같다.

  • 조인 혹은 서브쿼리와 같이 쿼리가 복잡해졌을 경우의 처리 방법은 어떻게 될까?
  • 사용자가 몰릴 경우의 테스트는 어떻게 진행해야 할까?
  • 인덱스 말고 순수 쿼리로 성능 개선할 수 있는 방법은 무엇일까?

위와 같은 고민 및 다음주 할 일이 생기게 되었다.

그 전에, jpql 및 querydsl 공부를 진행할 예정이다!

profile
소통을 잘하고싶은 백엔드 개발자

0개의 댓글