본문 바로가기
반응형

Performance18

PostgreSQL (Aurora) 10 vs 11 버전 성능 비교 PostgreSQL은 버전별로 굉장히 많은 개선이 있다. 2022년 1월 13일 현재, AWS RDS Aurora는 PostgreSQL 버전을 10, 11, 12, 13까지 지원하고 있다. 실제 PostgreSQL은 14까지 나와있으며, 현재 Aurora가 아닌 RDS는 14 RC1 까지 준비되었다. 10 버전이 이미 출시된지 4년 이상 지났고, 현재까지 메이저 14버전까지 출시되면서 성능/자원관리/기능등 여러 개선이 있었다. 특히나 인덱스가 10.x에서 비효율적으로 작동하는 부분이 굉장히 크기 때문에 이를 버전 업그레이드를 통해 성능개선 효과를 볼 필요가 있다. 10 vs 11 비교 PostgreSQL의 10 ~ 14버전 간 여러 기능 비교 중, 인덱스 & 제약조건에 관한 비교를 본다. PostgreS.. 2022. 1. 13.
PostgreSQL에서 Order By가 선적용되는 슬로우 쿼리 해결책 PostgreSQL 10.x 를 사용하다보면 간혹 옵티마이저가 잘못된 판단을 할때가 있습니다. 이번 경우에는 Order By 가 선 적용되는 실행계획을 어떻게 개선할지 알아보겠습니다. 1. 문제 상황 이를 테면 아래 쿼리의 경우 보통 1~5초 정도 수행됩니다. SELECT "vouchers"."id" FROM "vouchers" AS "vouchers" WHERE "course_id" in (select "id" from "courses" WHERE ("slug" = '코딩테스트-자바-실전' AND "deleted_at" IS NULL)) AND "user_id" in (select "id" from "users" WHERE ("deleted_at" IS NULL)) AND "deleted_at" IS .. 2021. 8. 21.
Spring Batch 파티셔닝 (Partitioning) 활용하기 지난 시간에 소개 드린 멀티쓰레드 Step과 더불어 파티셔닝 (Partitioning)은 Spring Batch의 대표적인 Scalling 기능입니다. 서비스에 적재된 데이터가 적을 경우에는 Spring Batch의 기본 기능들만 사용해도 큰 문제가 없으나, 일정 규모 이상이 되면 (ex: 매일 수백만 row가 추가되는 상황에서의 일일 집계) 서버를 Scalling (Up or Out) 하듯이 배치 애플리케이션 역시 확장이 필요합니다. 이런 문제를 고려해서 Spring Batch 에서는 여러 Scalling 기능들을 지원하는데요. 대표적으로 다음과 같습니다. Multi-threaded Step (Single process / Local) 단일 Step을 수행할 때, 해당 Step 내의 각 Chunk를 별.. 2021. 1. 20.
Querydsl (JPA) 에서 Cross Join 발생할 경우 JPA 기반의 환경에서 Querydsl를 사용하다보면 @OneToOne 관계에서 Join 쿼리 작성시 주의하지 않으면 Cross Join이 발생할 수 있습니다. CrossJoin 이란 집합에서 나올 수 있는 모든 경우를 이야기 합니다. 예로 A 집합 {a, b}, B 집합 {1,2,3}이며 이들의 CrossJoin은 AxB로 다음과 같습니다. {(a, 1), (a, 2), (a, 3), (b, 1), (b, 2), (b, 3)} 당연히 일반적인 Join보다 성능상 이슈가 발생하게 됩니다. 이번 시간에는 어떤 경우에 이런 Cross Join이 발생하는지, 어떻게 해결할 수 있는지 확인해보겠습니다. 모든 코드는 Github에 있습니다. 1. 테스트 환경 테스트 환경은 다음과 같습니다. Spring Boot .. 2020. 11. 16.
3-2. 페이징 성능 개선하기 - 첫 페이지 조회 결과 cache 하기 모든 코드는 Github에 있습니다. 지난 시간에 이어 count와 관련된 2번째 개선 방법은 첫 번째 쿼리의 결과를 Cache하기 인데요. 방법은 간단합니다. 처음 검색시 조회된 count 결과를 응답결과로 내려주어 JS에서 이를 캐싱하고, 매 페이징 버튼마다 count 결과를 함께 내려주는 것입니다. 그리고 Repository에서는 요청에 넘어온 항목 중, 캐싱된 count값이 있으면 이를 재사용하고, 없으면 count 쿼리를 수행합니다. 이미지 원작자님께 허락을 받고 사용하였습니다. :) (다시 한번 감사드립니다!) 이 방식은 다음과 같은 상황에서 도움이 되는데요. 조회 요청이 검색 버튼과 페이지 버튼 모두에서 골고루 발생하고 실시간으로 데이터 적재 되지 않고, 마감된 데이터를 사용할 경우 이럴 경.. 2020. 11. 6.
3-1. 페이징 성능 개선하기 - 검색 버튼 사용시 페이지 건수 고정하기 모든 코드는 Github에 있습니다. 앞서 포스팅에서 실질 페이징 쿼리 성능을 올리는 방법들을 소개 드렸는데요. 1. 페이징 성능 개선하기 - No Offset 사용하기 2. 페이징 성능 개선하기 - 커버링 인덱스 사용하기 페이징 기능을 구현하는데 있어, 페이징 쿼리 자체를 개선하는 것도 방법이지만 그 외 다른 기능을 개선하는 방법도 함께할 수 있습니다. 여기서 말하는 그 외 기능은 바로 count 쿼리입니다. 일반적인 페이징 기능에 있어 데이터 조회와 함께 매번 함께 수행되는 것이 바로 count 쿼리인데요. 해당 조건으로 조회되는 총 건수를 알아야만 아래와 같이 pageNo들을 노출시킬 수 있기 때문입니다. (총 건수 / pageSize) 당연히 No Offset을 사용한다면 사용되지 않는 쿼리입니다.. 2020. 11. 1.

728x90