전체 글

요약기본 설정: 닫히지 않은 트랜잭션이 있으면 해당 트랜잭션을 사용한다.propagation = Propagation.REQUIRED호출한 메소드에 `@Transactional` 걸려 있으면 그 메소드에서 쓰던 트랜잭션을 그대로 쓴다=> 하나의 transaction만 수행됨`@Transaction(propagation = )` 설정으로 바꿀 수 있다https://kghworks.tistory.com/106 [SPRING] @Transactional을 얼마나 이해했는지 보자목차 @Transcational CASE 정리 참고 2022.08.19 - [개발/데이터베이스 시스템] - 트랜잭션 (transaction) SQLException 발동! throw new SQLException(); } @Transca..

개요아파치에서 스칼라로 개발한 오픈소스 메세지 브로커링크드인에서 최초 개발2011년 오픈소스화링크드인에서는 백엔드 데이터 흐름 처리 위한 목적스트리밍 데이터 원할한 처리정적인 데이터 저장이 아닌 동적인 데이터 처리 주 목적계속적으로 변하는 스트리밍 데이터⇒ 현대의 기업은 정적인 DB로는 관리할 수 없는 복잡성, 다양성을 띈 데이터 처리할 수 있는 시스템 요구ex) 배민 라이더 위치 추적, 지하철 칸별 혼잡도RDBMS의 트랜잭션 로그 마이너 기술 영향을 받아서 만들어졌음데이터가 생성, 변경될 때 마다 로그를 기록목표고성능이벤트분산스트리밍카프카 스트림이라는 별도의 기술(api) 사용스트리밍 프로세스에 최적화된 방법 제공사용 목적시스템 또는 애플리케이션 간에 실시간 데이터 파이프라인 만들 때 사용대용량 실시간..

개요deadlock 방지FK에 해당하는 레코드가 있는 지 조회하기 위해 lock이 걸리는데, 이 lock으로 인한 성능 저하를 줄이기 위해서이 두 가지 리스크가 FK Constraint를 걸어서 얻는 이점보다 크다고 판단함일반적으로 FK에 대응되는 레코드가 없을 때 발생하는 손실이 전체 DB 성능 저하보다 크지 않음JOIN 또는 SELECT 결과가 NULL일 테니 쉽게 탐지 가능함프로그래밍적으로 제어 가능단, FK Constraint는 끊어도 FK에 Index는 생성해야 한다JOIN 성능을 위해서일부 ORM은 FK Constraint를 끊으면 Index도 사라지니 잘 확인해야 한다JPA에서 FK Constraint 제거하는 방법foreignKey = @ForeignKey(ConstraintMode.NO_..

요약repository.getReferenceById()를 이용해 프록시 객체를 생성하고, 엔티티 생성 parameter에 엔티티 대신 넘긴다getReferenceById()는 JPA에 정의되어 있기 때문에 구현 없이 쓰면 된다프록시 객체는 Primary key(id) 만 초기화되어 있고, 다른 값은 모두 null인 객체이다설명Foreign Key가 있는 레코드를 생성할 때, DBMS에서는 Foreign Key(user_id 등)만 알면 INSERT문으로 레코드를 생성할 수 있다. 그러나 이를 JPA 코드로 표현하면 FK 뿐만 아니라 관계된 전체 객체가 필요한 것처럼 보인다.Habit habit = Habit.creationBuilder() .runTime(param.getRu..

사용 범위Service Layer에서 DTO를 return한다도메인을 보호하기 위해서도메인이 변경됐을 때 Controller에 미치는 영향을 줄이기 위해서Controller가 도메인에 의존하지 않게 하기 위해서DTO - Domain 변환은 Mapper class가 수행한다`MapStruct` 라이브러리를 이용해서 편리하게 구현할 수 있다목적많은 매개변수를 일괄 처리원격 작업을 할 때 네트워크 오버헤드 감소직렬화 로직 캡슐화직렬화 로직을 DTO 클래스로 모아서 변경 지점을 하나로 만듦Domain 모델을 Presentational 모델과 분리하여 두 모델을 독립적으로 변경할 수 있게 한다 참고 자료https://hudi.blog/data-transfer-object/ DTO의 개념과 사용범위DTO는 우테코 ..

개요WHERE IN 보다는 JOIN 문의 성능이 더 좋다WHERE IN 절은 실행 계획에서 OR절로 변환되어 N번의 동등(=) 비교를 수행하기 때문에 성능이 나쁘다MySQL 5.6버전부터는 실행 계획에서 IN절을 JOIN으로 변환하여 성능을 개선하였다서브쿼리 존재 유무만 판별할 때는 IN대신 EXISTS 문을 사용하여 성능을 개선할 수 있다서브쿼리를 반복해서 실행하는 단점이 있다그러나 서브쿼리 WHERE 조건에 인덱스가 걸려 있다면 IN보다 빠를 것으로 예상된다IN: 동등 비교를 서브쿼리 결과 수만큼 수행, 반복 vs EXISTS: 인덱스 타고 가서 데이터 존재 여부 판별을 반복서브쿼리 결과 row 수가 많다면 EXISTS가 유리, 적다면 IN이 유리할 것으로 예상된다서브쿼리 결과 row 수가 증가하면 ..

개요Event Driven Architecture는 MSA에서 Producer가 여러 Consumer 서비스를 직접 호출해야 했던 구조에서 Event Broker 하나에만 이벤트를 전송하면 되는 구조로 개선했다는 것이 가장 큰 특징이다. 이로 인해 서비스가 느슨하게 결합(Loosely Coupled)되고, 결합도가 낮아진다. 다음 문단부터 정리할 EDA의 장단점은 이러한 EDA의 특징 때문에 생기는 것이라고 이해할 수 있다.장점확장성시스템에 부하가 증가할 때 Producer와 Consumer를 scale out(수평적 확장) 할 수 있다.Producer가 Counsumer를 직접 호출하지 않기 때문에 시스템을 크게 재설계하지 않아도 된다유연성새로운 이벤트나 처리 로직을 추가할 때 기존 컴포넌트에 미치는 ..

https://www.ssemi.net/what-is-the-bearer-authentication/ 토큰 기반 인증 Bearer AuthenticationOAuth를 들어가려고 생각하다가, 이전에 Bearer scheme 부터 조져야 겠다는 생각을 먼저 해봤다 블로그에 글을 쓸 때 마다 드는 생각Bearer scheme 에 대해서 정확히 설명을 하기 위해서 여러 자료들을 봤www.ssemi.net