일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- ExceptionResolver
- mapstruct
- Service 계층 테스트
- 2024회고
- FCM
- proxyFactory
- 자바
- 갓생
- enumSet
- 소프티어
- Test
- OS
- Server
- db
- 직장인 회고
- JPA
- Junit 5
- 인프콘2023
- 공룡책
- 일상
- Test Doulbe
- 2025 계획
- Spring
- modelmapper
- 테크쇼
- softeer
- Java
- Coputer Science
- Test code
- MySQL
- Today
- Total
목록분류 전체보기 (60)
공부내용공유
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/dM3hvM/btsFm7yYR3P/AIsLAwhVGyzG5YtuXrkBYk/img.png)
서론 인덱스가 쿼리 성능에 굉장히 많은 영향을 끼치는 것도 사실이지만 그 외에도 고려해야할 다른 요소들도 많다. 해당 글에서는 이전 글에서 다루지 않았던 인덱스 외 튜닝 포인트들을 (특히 실무를 진행하면서 만날법 한) 정리할 예정이다. 본론 Order By 관련 최적화 Order By 절에 명시된 칼럼에 인덱스가 있다면 이미 정렬되어 있는 상태이기 때문에 추가적인 정렬 작업이 필요 없어진다. 인덱스가 없다면 정렬 작업을 따로 수행해야 하는데 데이터 양이 Buffer 보다 적다 -> 메모리에서 정렬 데이터 양이 Buffer 보다 크다 -> 데이터들을 쪼개서 디스크에 넣고 정렬하고 합쳐서 정렬 실행계획을 확인했을 file sort가 있다면 정렬이 일어난거고 index가 있다면 인덱스를 통해 추가적인 정렬이 ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/4s8rf/btsFkW3RW1y/V7lAbexbZ9B2iOcMfNbcSk/img.png)
서론 어플리케이션의 성능을 고려했을 때 알고리즘, 쿼리 자체도 영향을 많이 끼치지만 인덱스는 단연 굉장히 높은 비중을 차지한다. 인덱스 설계, 튜닝을 할 때 어떤 부분들을 고려해야 하고 개선할 수 있는지 공부하기 위해 인프런의 MySql 성능 최적화 라는 강의와 MySQL 도큐먼트를 공부하고 정리하기 위해 이 글을 작성하였다. (해당 강의에는 다양한 최적화 방법을 다루고 있지만 이 글에서는 index 파트에 대해 다룰 것이다.) 본론 카디널리티 확인 방법 카디널리티는 다들 잘 알고있겠지만 다시 한번 정의를 설명하자면 특정 데이터 집합에서 유니크한 값의 개수이다. 그냥 특정 컬럼의 카디널리티는 select count(distinct(column)) from table 이러한 쿼리로 구할 수 있다. 만약 인..
서론 백엔드를 처음 공부하면서 접했던 계층 개념은 가장 흔히 쓰이는 presentation, service, repository 이 3개의 계층으로 나눈 패턴이었다, 입사를 하고나서 개발중인 프로젝트들 중 위 계층들 외에 business 계층을 추가하는 것을 보았고, 집에서 추가로 공부하면서도 business 계층을 사용하는 예시를 보게되었다. 해당 계층을 사용하면서 내가 느꼈을 때 어떤 이점이 있는지 간단하게 정리하고자 이 글을 작성하였다. (다른 장점, 틀린 내용이 있다면 댓글로 얘기해주세요!) 본론 일단 가장 핵심적인 목적은 도메인 로직만 들어있는 service 계층을 만들기 위해서이다. 도메인 로직만을 남김에 따라 인수인계를 할 때 처음 프로젝트를 보는 사람이 도메인 로직을 체력 낭비 없이 빠르게..
서론 프로젝트를 진행하다 보면 항상 검증에 대해 많이 고민을 하게된다. Request로 들어올 때 부터 철저히 검사해야할지, entity를 만들고 검증을 해야할지 등등... 이처럼 검증에 관해서는 굉장히 다양한 상황들이 있고 은총알은 없다고 생각한다. 해당 글에서는 내가 고민하면서 찾은 내용들, 받았던 조언들을 정리할 것이다. 본론 먼저 해당 글에서는 흔하게 사용되는 Presentation, Service, Repository 계층으로 나누어진다는 가정하에 글을 작성할 것이다. (entity 패키지, business 계층 같은 부가적인 부분은 생략한다.) 간단한 객체 생성에 대한 API를 예시로 어떤 계층에서 검증을 했을 때 어떤 장,단점이 있는지 알아보자. Presentation 계층 여기서 prese..
서론 spring secutiry에서 mvc에 설정되어 있는 cors config를 어떻게 가져오는 알아보기 위해 코드를 뒤집어 까다가 mvc에 핵심적인 코드를 만났다. spring으로 프로젝트를 진행하면 흔하게 접하는 EnableWebMvc, WebMvcConfigurer 등등을 보았고, 이번 mvc config에 있어서 핵심적인 클래스들, 작동 방식에 대해 이 글에서 정리할 예정이다. 본론 1. @EnableWebMvc @Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) @Documented @Import(DelegatingWebMvcConfiguration.class) public @interface EnableWebMvc { } 위처럼 작..
서론 cors 에 관한 설정은 security를 사용한다면 bean 이름을 security에서 제공하는 bean 이름으로 만들면 filter에 자동으로 주입이 된다. 그리고 spring mvc 차원에서도 WebMvcConfiguer와 같은 클래스를 상속하고 메서드를 오버라이딩 하면 해당 메서드에서 커스터마이징 한대로 설정이 적용된다. 만약 2가지 설정이 있으면 어떤 것이 작동하는지 궁금해져서 security 내부 코드를 간단하게 살펴보고 정리하였다. 본론 CorsConfigurer class public CorsConfigurer() {} public CorsConfigurer configurationSource(CorsConfigurationSource configurationSource) { this..
서론 프로젝트를 진행하면서 사용자가 원하는 종류에 따라서 기능을 실행해야 하는 요구사항이 있었다. 간단하게 예시를 들자면 Kakao, naver, google, iphone 과 같은 써드파티 로그인 기능들을 구현해야 하는 상황이라고 생각할 수 있다. 위와 같은 로그인 기능을 예시로 프로젝트에서 어떤 식으로 팩토리 패턴을 적용했는지 글을 작성할 예정이다. 본론 일단 팩토리 패턴을 적용하지 않은 간단한 예시 코드를 만들어보자. (각 써드파티 로그인 별로 인증 로직이 조금 다르다고 가정하겠다. ) // controller public Response login (@RequestBody loginRequest) { Boolean success = userService.login(loginRequest); ret..
서론 프로젝트를 하면서 검색 기능을 구현해야 했다. 기능 구현을 위해 알아봤던 내용을 간단하게 정리하였다. 본문 전문 검색 인덱스(Full Text Search Index) Full-Text-search-index(전문 검색 인덱스)란 많은 형태의 데이터가 있을 때 효율적으로 데이터를 찾는 방법중 하나로 텍스트로 구성된 데이터의 내용을 기반으로 생성한 인덱스이다. 메일, 메세지 내용을 기반으로 검색을 할 때 효율적으로 검색하기 위해 필요하다. MongoDB 전문 검색 인덱 알고리즘 불용어(stop word) 처리 가치 없는 단어를 필터링 주로 대명사, 관사, 전치사, 주요 동사 형태소 분석 검색어로 선정된 단어의 어근을 찾는 작업 처리과정 불용어 처리 there are not droids you are ..
서론 3개월간의 온보딩 프로젝트가 끝났다. 처음 해 본 온보딩 이었지만 정말 온보딩스러운 온보딩 프로젝트였다고 생각한다! (좋은쪽으로) 프로젝트가 끝난겸 기억나는 것에 대해 주저리 주저리 쓸 예정이다. 본론 무엇을 했었나 자세히 얘기할 수는 없지만 사용자들의 정책(?)들을 저장하고 해당 정책들을 활용해 다양한 로직을 수행하는 서버를 만드는 프로젝트였다. 기술 스택은 Java 17, Spring boot 2.7 , MongoDB 를 사용하였고 프로젝트를 진행하면서 중점으로 다룬 것은 생소한 NoSQL인 MongoDB 를 잘 활용하는 것 (schema 설계, index 설계 등등...) , 팀 컨벤션에 맞춘 개발, 소프트 스킬 등이었다. 2~3주 간의 필요 기술 공부, 기획서 분석, 스키마 설계등을 하였고 ..
서론 지금 진행중인 프로젝트에서 어떤 기능이 실패했을 때 로그성 정보를 DB에 저장하는 기능을 추가해야했다. 처음에 아무 생각없이 다른 service 계층에서 저장 로직을 가지고와 사용했는데 이러한 리뷰를 받았다. 로그 저장은 해당 기능의 주 관심사는 아닌거 같아요! event,aop,interceptor와 같은 기능을 사용해서 주 관심사와 부 관심사를 분리하는게 어떨까요? 완전 맞는 말이었고 해당 기능을 event를 통해 분리하였다. 사실 event라는 개념을 처음 사용해봐서 검색을 하고 비슷한 방식으로 적용하였는데 그렇게 사용하는 것은 event의 본질을 살리지 못했다 라는 리뷰를 받았고 event에 대해 제대로 공부하게 되었다. 이 글에서는 코드의 변화 과정을 기반으로 spring event의 올바..