New
-
JPA Entity Select에서 Update 쿼리 발생할 경우
JPA Entity를 단순히 조회만 하였는데도, 예상치 못하게 Update 쿼리가 발생하는 경우가 있습니다. 이를테면 다음과 같은 경우인데요. find로 조회만 하는데, 발생한 쿼리는 다음과 같이 select와 update가 실행 되었습니다. 신기한 것은 전체 컬럼에 대한 Update 쿼리가 발생한것입니다. 보통 이렇게 트랜잭션 내에서 Update 쿼리가 발생하면 보통은 Dirty Checking이 발생했음을 의심해볼만 한데요. 의심이라고 말씀드리는 이..
2020.11.28
-
오늘의 질문 2020.11.23
Q.1 Q. 안녕하세요. 현재 구직중인 취준생 개발자입니다. 여러 회사를 지원하면서 느낀 것이 이만큼의 요구사항이 진짜 신입으로서 당연히 해야하는 것인지 의문이 듭니다. 자바와 같은 프로그래밍언어, 데이터베이스, 자료구조, 알고리즘 등까지는 이해합니다. 헌데, 알고리즘 코딩 테스트만 준비해야할게 아니라 스프링/JPA와 같은 현업에서 사용하는 프레임워크라던가, 테스트코드, DDD등에 대한 지식까지 요구하고 Github 관..
2020.11.23
-
오늘의 질문 2020.11.17 (애기아빠의 신입 구직)
Q.1 Q. 28살 아기아빠입니다. 현재 상황은 html/css/php/mysql로 간단한 게시판을 만드는 정도의 실력과 4년전 비트교육을 들었다는 이력정도만 갖고 있는 구직중인 신입 개발자입니다. 기존에도 스타트업에 입사할 기회가 있었지만, 막상 입사해보니 IOS/안드로이드/리액트 등을 모두 개발할 수 있는 수준을 원하여서 퇴사하였습니다. 제가 이제 가정이 생겨서 돈을 벌어야하는 입장인데도 국비지원을 다시 가야할까? 아니면 돈..
2020.11.18
-
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보다 성능상 이슈가 발생하게 됩니다. 이번 시간에는 어떤..
2020.11.16
-
생각은 쉽다
아래 글은 제 브런치에 있던 글을 블로그로 옮긴 글입니다. 내가 대학교 졸업을 앞두고 있을때 한창 유행했던 것이 안철수님의 청춘 콘서트였다. 당시에 전국 대학교를 순회하면서 진행해주셨는데, 마침 내가 다니는 대학교에서도 이 콘서트가 진행되었다. 뭐 하나 팁을 얻을게 있을까 하고 참관 신청을 하고 강당으로 갔었다. 거기서 나는 몇년이 지나도 잊을 수 없는 문장을 들었다. "어떤 사람을 판단할때, 그 사람의 말과 생..
2020.11.07
-
3-2. 첫 페이지 조회 결과 cache 하기
3-2. 첫 페이지 조회 결과 cache 하기 모든 코드는 Github에 있습니다. 지난 시간에 이어 count와 관련된 2번째 개선 방법은 첫 번째 쿼리의 결과를 Cache하기 인데요. 방법은 간단합니다. 처음 검색시 조회된 count 결과를 응답결과로 내려주어 JS에서 이를 캐싱하고, 매 페이징 버튼마다 count 결과를 함께 내려주는 것입니다. 그리고 Repository에서는 요청에 넘어온 항목 중, 캐싱된 count값이 있으면 이를 재사용하고, 없으..
2020.11.06
-
3-1. 페이징 성능 개선하기 - 검색 버튼 사용시 페이지 건수 고정하기
모든 코드는 Github에 있습니다. 앞서 포스팅에서 실질 페이징 쿼리 성능을 올리는 방법들을 소개 드렸는데요. 1. 페이징 성능 개선하기 - No Offset 사용하기 2. 페이징 성능 개선하기 - 커버링 인덱스 사용하기 페이징 기능을 구현하는데 있어, 페이징 쿼리 자체를 개선하는 것도 방법이지만 그 외 다른 기능을 개선하는 방법도 함께할 수 있습니다. 여기서 말하는 그 외 기능은 바로 count 쿼리입니다. 일반적인 페이징 기능..
2020.11.01
-
2. 페이징 성능 개선하기 - 커버링 인덱스 사용하기
2. 커버링 인덱스 사용하기 앞서 1번글 처럼 No Offset 방식으로 개선할 수 있다면 정말 좋겠지만, NoOffset 페이징을 사용할 수 없는 상황이라면 커버링 인덱스로 성능을 개선할 수 있습니다. 커버링 인덱스란 쿼리를 충족시키는 데 필요한 모든 데이터를 갖고 있는 인덱스를 이야기합니다. 즉, select, where, order by, limit, group by 등에서 사용되는 모든 컬럼이 Index 컬럼안에 다 포함된 경우인데요. 여기서 하나의 의..
2020.10.24
-
1. 페이징 성능 개선하기 - No Offset 사용하기
일반적인 웹 서비스에서 페이징은 아주 흔하게 사용되는 기능입니다. 그래서 웹 백엔드 개발자분들은 기본적인 구현 방법을 다들 필수로 익히시는데요. 다만, 그렇게 기초적인 페이징 구현 방식은 서비스가 커짐에 따라 큰 장애를 유발할 수 있는데요. 서비스 초기에는 수천 ~ 수십만건정도로 데이터가 적어서 큰 문제가 없지만, 점차 적재된 데이터가 많아짐에 따라 페이징 기능이 수십초 ~ 수분까지 조회가 느려지는걸 경험하..
2020.10.15
-
Spring Boot에서 yyyy-MM 포맷으로 날짜 받고싶을때
Spring Boot에서 Request 항목으로 년월 (2020-09, 202009 등)만 필요할때가 종종 있습니다. 2020-09-01과 같은 일자의 경우 Request Dto로 LocalDate를 사용할 수 있었는데요. Spring Boot 환경에서의 LocalDate, LocalDateTime에 대한 상세한 내용은 이전에 작성된 SpringBoot에서 날짜 타입 JSON 변환에 대한 오해 풀기을 참고해보시면 좋습니다. 년/월만 있을 경우 LocalDate로 처리할 수가 없습니다. 그래서 아래와 같이 문..
2020.10.02
-
Spring Batch에서 socket was closed by server 발생시
시스템 이관을 진행하면서 각종 설정들이 기존 설정들과 달라 운영 테스트에서 여러 이슈를 만나게 되는데요. 최근 Spring Batch 환경 이관에서 기존 Job 들을 테스트 하던 중 다음과 같은 이슈를 만나게 되었습니다. Caused by: java.io.EOFException: unexpected end of stream, read 0 bytes from 4 (socket was closed by server) 기존에 잘 작동하던 Batch Job에서 왜 이런 문제가 발생하는지, 어떻게 하면 해결할 수 있는..
2020.09.29
-
ListItemReader 성능상 주의사항
Spring Batch를 사용하다보면 종종 ListItemReader 가 필요한 경우가 종종 있습니다. 물론 일반적으로는 ListItemReader를 사용하기 보다는 FlatFileItemReader, JdbcItemReader, MongoItemReader 등 Spring Batch에서 공식적으로 지원하는 ItemReader나 Custom ItemReader등을 만들어 사용하는 것을 추천합니다. 다만, 현재 Spring Batch의 ListItemReader 에서는 성능 이슈가 하나 있는데요. 이번 시간에는 해당 성능 이슈가..
2020.09.21
-
설거지까지가 요리다
한참 마녀사냥을 재밌게 볼 때가 있었다. 그린라이트라는 희대의 유행어를 만든 프로인데, 남녀사이의 고민을 4명의 남자 MC의 입담으로 풀어나가는 재미가 대단한 프로였다. 당시 기억에 남는 회차가 있었는데, 일일 MC로 조정치씨가 나와서 신혼 생활의 고충을 얘기하던 회차였다. 와이프인 정인씨가 요리 초보다 보니 설거지 거리가 잔뜩 나와 조정치씨가 결혼 후 주부습진이 생겼다는 것이다. 어디서나 흔하게 볼 수 있는 이..
2020.09.05
-
Querydsl select에서 상수 사용하기
쿼리 성능을 개선할 수 있는 여러 방법 중에 가장 쉬운 방법은 조회하는 컬럼의 수를 최소화하는 것입니다. dzone-6-simple-performance-tips-sql 무분별하게 Entity를 가져오기 보다는 Dto로 필요한 필드만 가져오길 권장하는 이유이기도 한대요. (물론 Entity를 사용하지 않음으로 Hibernate 1차 캐시도 없다는 것도 주요 이유입니다.) 조회에 필요한 필드들만 조회하였지만, 그럼에도 더 줄일 수 있는 방법은 무엇이 있을까요..
2020.09.03
-
MySQL Update Subquery 성능 비교 (ver.5.6)
지난 포스팅으로 select ~ where in (서브쿼리) 와 같은 서브쿼리가 MySQL 5.6 버전에서 대폭 최적화 되었음을 확인하였는데요. 이번에는 update ( update ~ where in (서브쿼리) ) 에서도 서브쿼리 최적화가 잘 작동하는지 확인해보겠습니다. 0. 테스트 환경 테스트 환경은 이전 select 테스트때와 같습니다. 메인 테이블 100만건 서브 테이블1 (인덱스 O) 1000건 서브 테이블2 (인덱스 X) 1000건 DDL 쿼리는 다음과 같습니다...
2020.09.01
