본문 바로가기
반응형

db 성능개선13

JPA Entity Select에서 Update 쿼리 발생할 경우 JPA Entity를 단순히 조회만 하였는데도, 예상치 못하게 Update 쿼리가 발생하는 경우가 있습니다. 이를테면 다음과 같은 경우인데요. find로 조회만 하는데,다음과 같이 select와 update 쿼리가 발생 하였습니다.신기한 것은 전체 컬럼에 대한 Update 쿼리가 발생한것입니다. 이렇게 트랜잭션 내에서 Update 쿼리가 발생하면 보통은 Dirty Checking이 발생했음을 의심해볼만 한데요. 의심이라고 말씀드리는 이유는 실제로 다른 원인이 있을수도 있기 때문입니다. 자 그럼 왜 이렇게 발생했는지 실제 예제 코드와 함께 보겠습니다. 1. 예제 코드 먼저 위에서 발생한 Entity를 비롯한 서비스 코드는 다음과 같습니다. Order @Getter @NoArgsConstructor @Ent.. 2020. 11. 28.
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.
2. 페이징 성능 개선하기 - 커버링 인덱스 사용하기 2. 커버링 인덱스 사용하기 앞서 1번글 처럼 No Offset 방식으로 개선할 수 있다면 정말 좋겠지만, NoOffset 페이징을 사용할 수 없는 상황이라면 커버링 인덱스로 성능을 개선할 수 있습니다. 커버링 인덱스란 쿼리를 충족시키는 데 필요한 모든 데이터를 갖고 있는 인덱스를 이야기합니다. 즉, select, where, order by, limit, group by 등에서 사용되는 모든 컬럼이 Index 컬럼안에 다 포함된 경우인데요. 여기서 하나의 의문이 드는 것은 select절까지 포함하게 되면 너무 많은 컬럼이 인덱스에 포함되지 않겠냐는 것인데요. 그래서 실제로 커버링 인덱스를 태우는 부분은 select를 제외한 나머지만 우선으로 수행합니다. 예를 들어 아래와 같은 페이징 쿼리를 SELECT.. 2020. 10. 24.
1. 페이징 성능 개선하기 - No Offset 사용하기 일반적인 웹 서비스에서 페이징은 아주 흔하게 사용되는 기능입니다. 그래서 웹 백엔드 개발자분들은 기본적인 구현 방법을 다들 필수로 익히시는데요. 다만, 그렇게 기초적인 페이징 구현 방식은 서비스가 커짐에 따라 큰 장애를 유발할 수 있는데요. 서비스 초기에는 수천 ~ 수십만건정도로 데이터가 적어서 큰 문제가 없지만, 점차 적재된 데이터가 많아짐에 따라 페이징 기능이 수십초 ~ 수분까지 조회가 느려지는걸 경험하게 됩니다. 특히 1억건이 넘는 테이블에서의 페이징은 단순히 인덱스만 태운다고해서 성능 문제가 해결되진 않습니다. 그래서 이번 시간에는 일반적인 페이징 기능에서 성능을 개선하는 방법을 알아보겠습니다. 당연하겠지만, 인덱스를 이용한 쿼리 튜닝이 되어있다는 가정하에 진행됩니다. 조회 쿼리의 인덱스 사용조차.. 2020. 10. 15.
728x90
반응형

티스토리툴바