본문 바로가기

CS 잡지식

H2 설치 시, 주의 사항(매우 중요) 지금 보면, Gradle에서 h2 관련 라이브러리를 다운로드할 때, 버전[2.1.214]을 가져왔다. 그러면, 반드시 h2 데이터 베이스를 설치를 할 때에 버전[2.1.214]를 다운로드 해줘야 한다. 클라이언트(애플리케이션 계층)과 서버(H2 DB)와 버전이 안 맞으면 에러가 날 가능성이 크다. H2 DB에서 제공하는 H2VERSION() 함수를 사용하여, 자신의 H2 DB의 버전을 확인할 수가 있다. 아래와 같이 애초에 Gradle에서 라이브러리를 다운로드 할 때, h2의 버전을 [직접] 명시하여 다운로드 해 올 수가 있다. ( 그러나, 이 방법은 약간 비추. Spring Boot Starter가 해당 Spring boot 버전에 맞는 가장 좋은 h2 db 버전을 자동으로 다운로드를 해준다. 고로, .. 더보기
Spring 3.X.X에서의 변경 사항 1] Spring 2.X.X에서는 JAVA 11로 개발을 했었지만, Spring 3.X.X 부터는 JAVA 17 버전을 사용해야 한다. 2] Spring 2.X.X에서는 Juni4로 테스트 개발을 했었지만, Spring 3.X.X 부터는 Junit5로 테스트 개발을 해야 한다. 3] javax 패키지 이름을 jakarta로 변경해야 합니다. 오라클과 자바 라이센스 문제로 모든 javax 패키지를 jakarta로 변경하기로 했습니다. 3 4] H2 데이터베이스를 2.1.214 버전 이상 사용해주세요 더보기
[1:다]에서의 [데이터 중복] 문제를 직관적으로 이해하기 이게 보통 헷갈리는 것이 아니다. 고로, 앞으로는 헷갈리지 않게 아래를 충분히 숙지를 해두고, [1:다] 혹은 객체 안에 컬렉션이 있는 경우 어떻게 [데이터 중복] 문제가 발생하는지 바로 바로 떠올릴 수 있게 하자. @Entity class Team{ @Id@GeneratedValue private id; // 이것이 [1:다] 관계를 만든다 @OneToMany List members; } JPQL : "SELECT t FROM Team t" -> DB Table에는 Team Table, Member Table이 있어서, JOIN 연산을 한다. 팀A에 대해서 Member Table에는 2개의 Member(memberA,memberB라고 하자)가 존재한다. 그럼, DB 사이드에서는 2개의 ROW가 발생을 .. 더보기
순환 참조 문제 @RestController @RequiredArgsConstructor public class OrderApiController { //[주문 내역]에서 주문한 [상품 정보(OrderItem,Item필요)]를 // 추가로 조회하는 API private final OrderRepository orderRepository; private final OrderQueryRepository orderQueryRepository; //중간 생략 @Data static class OrderDto { private Long orderId; private String name; private LocalDateTime orderDate; private OrderStatus orderStatus; private Addre.. 더보기
컬렉션(Collection) 조회 전략 2가지 컬렉션 조회 전략 1] 걍 fetch join -> [데이터 뻥튀기]. [페이징] 이슈(DISTINCT, IN 쿼리로 해결 가능) 2] fetch_size 설정을 통해서 fetch join 없이 조회 -> [데이터 뻥튀기] 없고, [페이징] 이슈도 없음 -> 428번 게시물 참조! 더보기
batch_size의 설정 TIP!!(batch_fetch_size, @BatchSize) default_batch_fetch_size 의 크기는 적당한 사이즈를 골라야 하는데, 100~1000 사이를 선택하는 것을 권장한다. 이 전략을 SQL IN 절을 사용하는데, 데이터베이스에 따라 IN 절 파라미터를 1000으로 제한하기도 한다. 1000으로 잡으면 한번에 1000개를 DB에서 애플리케이션에 불러오므로 DB 에 순간 부하가 증가할 수 있다. 하지만 애플리케이션은 100이든 1000이든 결국 전체 데이터를 로딩해야 하므로 메모리 사용량이 같다. 1000으로 설정하는 것이 성능상 가장 좋지만, 결국 DB든 애플리케이션이든 순간 부하를 어디까지 견딜 수 있는지로 결정하면 된다 (사이즈를 너무 작게 잡으면, ROOP문이 많이 돌기에, SQL문이 많이 나간다) 더보기
(1 + N) 문제 해결책 - (Feat. Fetch Join, @BatchSize, batch_fetch_size 설정) Lazy 객체에서 생기는 (1+N) 문제의 대부분은 Fetch Join이라는 강력한 옵션으로 해결이 가능하다. 그러나 아래 사이트의 맥락을 이어서 부연 설명을 하자면, 多에 해당하는 컬렉션에 대해서 Fetch Join을 하게 되면 여러 가지 이슈가 생긴다(아래 사이트에도 나와 있지만, [페이징] 이슈 등) https://jbluke.tistory.com/427 [1:다]에서의 컬렉션(다) 조회 시 문제 : 페이징, (N+1)문제 등 https://jbluke.tistory.com/426 ( 이 사이트의 맥락에 이어서 설명을 하겠다) 컬렉션(Collection) fetch join 시, 발생하는 [데이터 중복] 문제!(소위 [데이터 뻥튀기]라고도 부름) [1:다]에서 생기는 문제이기도 jbluke.tist.. 더보기
[1:다]에서의 컬렉션(다) 조회 시 문제 : 페이징, (N+1)문제 (매우 매우 중요) https://jbluke.tistory.com/426 ( 이 사이트의 맥락에 이어서 설명을 하겠다) 컬렉션(Collection) fetch join 시, 발생하는 [데이터 중복] 문제!(소위 [데이터 뻥튀기]라고도 부름) [1:다]에서 생기는 문제이기도 함. (아래 사이트 참조) (하이버네이터 6부터는 자동으로 데이터 중복 해결해줌. (Feat. distinct) https://jbluke.tistory.com/346 1：多 jbluke.tistory.com @Entity @Table(name = "ORDERS") @Ge jbluke.tistory.com 그럼, [1:다] 관계에서 발생하는,즉 컬렉션(다) 조회 시 발생하는 [페이징] 이슈를 해결할 방법은 없는건가??? (참고로, [1:다]에서 생기는 .. 더보기

티스토리툴바