다음은 DiaryController에서 일기를 등록하는 createDiary를 테스트하는 코드를 작성한 것이다.Controller 테스트 예제에서 Service에 MockBean으로 설정을 해놓길레 따라했지만 @Mock으로 해놓으니깐이런 에러가 발생했다.@WebMvcT

Business Exception 언체크 예외(런타임 예외)를 상속받는 예외 클래스를 작성한다. 여기서 체크 예외가 아닌 언체크 예외를 상속받도록 한 이유가 있다. 왜냐하면 일반적인 비지니스 로직들은 따로 catch해서 처리할 것이 없으므로 만약 체크 예외로 한다면

이전 게시글에서는 웹소켓에서 STOMP 프로토콜을 추가해 채팅 서버를 구현해보았습니다. 이번에는 STOMP에 외부 메시지 브로커인 RabbitMQ를 추가해보았습니다. STOMP 프로토콜로만 채팅서버를 구현했을 때는 다음과 같습니다. > - Spring 환경에서 STO

의사소통할 어플리케이션에 각각 메시지를 보넨다.메세지 큐는 일시적인 메시지 저장소를 제공한다. (목적지 프로그램이 바쁘거나 연결되지 않았을 때)메시지큐는 Producer, brocker(message Queue Software), Consumer로 구성되어 있다.메시지

이전 게시물에서는 웹 소켓을 이용한 채팅 서버를 구현해 보았다. 그러나 웹 소켓만으로는 채팅서버에 문제가 있습니다.다음과 같이 채팅방 식별자(아이디)와 Set<WebSocketSession>을 Map 자료구조를 통해 구현했습니다. 웹 소켓 서버가 2대 이상이라면,

기존의 단방향 HTTP 프로토콜과 호환되어 양방향 통신을 제공하기 위해 개발된 프로토콜.일반 Socket통신과 달리 HTTP 80 Port를 사용하므로 방화벽에 제약이 없으며 통상 WebSocket으로 불린다.접속까지는 HTTP 프로토콜을 이용하고, 그 이후 통신은 자

활동 두들린(스타트업) 서류 내가 지금껏 경험한 개발 내용을 잘 정리하여 이력서에 녹아내리니 아주 빠르게 성장하고 있는 스타트업 서류에 통과를 했다! 처음으로 서류를 통과하게 되어 매우 얼떨떨했다. 물론 지금껏 서류를 많이 내보진 않았다. 하하;;) 아직 많이 부족한

제가 작성한 이전 게시물에서 잘못된 생각으로 글을 작성한 것을 깨달았습니다. 깨닫게 되고 데이터를 조회하는 쿼리를 진짜진짜 간단히 쿼리 개선을 해보게 되었습니다. 우선 전체 상품 데이터를 조회하는 get_product_all_list 함수를 봐보겠습니다.이 함수에서 P

이전 게시물에서 알 수 있듯이 Elasticsearch를 사용하면 역색인 처리로 매우 빠른 검색이 가능하다는 것을 확인할 수 있었습니다. 그런데 Elasticsearch의 또 다른 장점 중 하나는 텍스트를 여러 단어로 변형하거나 텍스트의 특징을 이용한 동의어나 유의어

데이터베이스에는 50만 데이터가 있습니다.상품 검색 API의 latency를 줄이고 Vus를 늘리게된 성능개선을, k6를 통해 확인한 기록일지입니다. k6로 부하테스트를 쓴 이유와 각 테스트의 목적에 대해서는 이전글(전체 데이터 조회 성능 테스트 기록)을 참고하시면 될

부하테스트 : k6은 애플리케이션에 대한 부하를 시뮬레이션하고 이를 통해 애플리케이션의 성능과 안정성을 평가할 수 있습니다.확장성: k6은 클라우드 기반으로 구축되어 있으므로, 사용자 수가 증가함에 따라 애플리케이션의 성능을 테스트하는 데 적합합니다. (Vus 설정가능

인덱스 = 색인 : 쉽게 찾아볼 수 있도록 일정한 순서에 따라 놓은 목록데이터가 특정 기준으로 정렬되어 있다면 검색을 빠르게 할 수 있을 것이다.데이터베이스 테이블에 대한 검색 성능을 향상시키는 자료 구조이며 where 절 등을 통해 활용된다.인덱스의 특징인덱스는 항상

임베디드 타입 같은 값 타입을 여러 엔티티에서 공유하면 위험함 대신 값(인스턴스)를 복사해서 사용 값 타입 컬렉션 값 탑입 컬렉션 저장 ![](https://velog.

• @Entity로 정의하는 객체• 데이터가 변해도 식별자로 지속해서 추적 가능• 예)회원엔티티의 키나 나이 값 을변경해도 식별자로 인식가능• int, Integer, String처럼 단순히 값으로 사용하는 자바 기본 타입이나 객체• 식별자가 없고 값만 있으므로 변경시

특정 엔티티를 영속 상태로 만들 때 연관된 엔티티도 함께 영속 상태로 만들도 싶을 때예) 부모 엔티티를 저장할 때 자식 엔티티도 함께 저장.영속성 전이는 연관관계를 매핑하는 것과 아무 관련이 없음엔티티를 영속화할 때 연관된 엔티티도 함께 영속화하는 편리함 을 제공할 뿐

지연로딩 지연 로딩 LAZY을 사용해서 프록시로 조회 member1.getTeam().getName() ==> 실제 team을 사용하는 시점에 초기화(DB 조회) 즉시로딩 Member조회시 항상 Team도 조회(프록시가 아니라 진짜 엔티티를 가져옴) N+1문제

em.find() vs em.getReference() em.find(): 데이터베이스를 통해서 실제 엔티티 객체 조회 em.getReference(): 데이터베이스 조회를 미루는 가짜(프록시) 엔티티 객체 조회 프록시 객체는 원본 엔티티를 상속받음, 따라서 타

공통 매핑 정보가 필요할 때 사용(id, name)상속관계 매핑X엔티티X, 테이블과 매핑X부모 클래스를 상속 받는 자식 클래스에 매핑 정보만 제공 조회, 검색 불가(em.find(BaseEntity) 불가)직접 생성해서 사용할 일이 없으므로 추상 클래스 권장Member

관계형 데이터베이스는 상속 관계X슈퍼타입 서브타입 관계라는 모델링 기법이 객체 상속과 유사상속관계 매핑: 객체의 상속과 구조와 DB의 슈퍼타입 서브타입 관계를 매핑각각 테이블로 변환@Inheritance(strategy = InheritanceType.JOINED)테이

Team 엔티티에 List<Member> 컬렉션만 추가해주면 됨테이블에 양방향 연관관계는 FK 하나로만 설정할 수 있다. 그러나 객체에서의 양방향 연관관계는 서로다른 단방향 관계를 두 개 설정한다고 생각하면 된다.회원 -> 팀 연관관계 1개(단방향)팀 -> 회원