일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- OS
- 자바
- ExceptionResolver
- FCM
- 직장인 회고
- 2024회고
- Test Doulbe
- MySQL
- 테크쇼
- softeer
- Server
- Test code
- mapstruct
- 공룡책
- modelmapper
- db
- 소프티어
- Service 계층 테스트
- Junit 5
- JPA
- Coputer Science
- 2025 계획
- Test
- 일상
- Spring
- enumSet
- Java
- proxyFactory
- 인프콘2023
- 갓생
- Today
- Total
목록ComputerScience (13)
공부내용공유
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/dSLE2m/btsJermw9mE/xudDdPS8vuGcGmIhLukIN0/img.png)
서론 이전 글에 이어서 이번에는 redis의 persistence 기능을 공부하였다, Redis는 메모리를 활용함으로 높은 퍼포먼스를 낼 수 있지만, 서버가 도중에 꺼졌을 때, 특정 작업을 원복해야할 때 등등 다양한 시나리오에 대응하기 위해서는 persistence의 도움이 필요하다. Redis는 AOF, RDB를 통해 persistence 기능을 지원하는데 각각 어떤식으로 작동하고 어떻게 사용하는지 정리할 예정이다. 본론 이번 글의 목차는AOF란RDB란무엇을 사용해야할까으로 구성될 예정이다. RDB(Redis DataBase)란? 스냅샷이란? 일단 SnapShot 이라는 개념을 간단히 알아보자. SnapShot은 Redis뿐만 아니라 다양한 소프트웨어에서 사용하는 기법으로 특정 시점에 데이터 저장..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/kJq9O/btsI6w3mIBw/HWjfZBtslM3fGfXDyWF4iK/img.png)
서론 최근 프로젝트를 진행하면서 풀어야할 요구사항이 있었는데 여러가지 방법이 있었지만 redis를 사용하면 어떨까 싶은 생각이 들었었다, 다만 redis를 사용해야하는 이유에 대해서는 단순히 in-memory라 빨라서, 여러 서버에서 접근이 가능해서 등등 추상적인 답변만 떠오르고 정확히 어떻게 동작하고 어떤 기능을 지원하는지 설명할 수 없었다. 이전에 들었던 redis 관련 세션 복습겸, 내용 정리를 한번 더 하고자 해당 글을 작성하였고 이번 글에서는 redis가 일반 db(disk를 주로 사용하는)보다 왜 빠른지에 대한 내용을 다룰 것이다. 본론 해당 글은 목차는Redis 간단하게 알아보기Redis는 싱글 스레드?Redis는 왜 빠를까?로 구성될 예정이다. Redis 간단하게 알아보기 redis는..
서론진행중인 프로젝트에서 쿼리에 Group By 를 사용해야하는 기능이 있었다. 학부생 때, SQL 문제를 풀 때 Group By를 사용하면 Select 절에는 Group By의 기준 값이나, 집계함수만 사용할 수 있는줄 알았는데 MySQL 5.7 이후로는 사용 가능 여부를 설정이 가능했다 (하지만 사용시 주의해야 할 점이있다). 이 글에서는 해당 내용에 대한 간단한 설명과 내가 group by로 해결하지 못하고 Window Function으로 해결한 간단한 쿼리를 정리할 예정이다. 본론GroupBy의 사실과 오해 간단한 예시 쿼리로 한번 설명해보자select category, max(price), from itemgroup by category 아이템을 카테고으로 그룹화 하고 카테고리의 이름, ..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/GVoxr/btsGZn77eNP/l5ayhGd6ivza0C18sYtP6k/img.png)
서론MySQL에서도 고려할만한 주제이지만 특히 MongoDB를 사용할 때 많이 고민하게 되는 부분은 정규화, 반정규화 이다. 결국 상황에 맞게 알잘딱깔센으로 하는게 대부분 자료들의 결론이지만 자료들(몽고DB 완벽 가이드, Real MongoDB)을 찾고 보면서 간략하게 내용을 정리해 보았다. 본론정규화 vs 비정규화 먼저 정규화와 비정규화의 차이를 학생과 과목을 예시로 살펴보자 - students (학생별 도큐먼트)- classes(과목별 도큐먼트)- studentClasses(학생과 강의를 참조하는 도큐먼트) 학교 수업 관리자가 학생들이 듣는 과목 리스트, 상세 정보들을 조회하고 싶다면 어떻게 해야할까? 일반적인 잘 정규화된 테이블에서 SQL의 방식은 Student 아이디로 Studen..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/oyagd/btsGNQor6c9/tjyXRK0QQpcsBKIIQaMwsk/img.png)
서론 프로젝트에서 벌크성 기능을 개발하면서 Mongo DB의 벌크성 쿼리에 대해 조사를 하게 되었다. (어떻게 작동하고, 오류 발생시 어떻게 처리할지) 해당 글에서는 내가 조사한 내용과 테스트 해본 내용을 정리할 예정이다. 본론 1. 쿼리 종류 먼저 Mongo DB에서 지원하는 벌크성 쿼리들을 종류를 나열해보면 insertMany updateMany deleteMany Bulk Write 정도로 구분할 수 있다. 여기서 조금 헷갈릴만한 부분은 Many 시리즈와 Bulk Write는 무슨 차이가 있을까이다. Many 시리즈 쿼리들은 말 그대로 여러 documente들에 대해 update, delete, insert와 같은 연산을 진행하는 쿼리이다. Bulk 쿼리도 위와 같은 방식으로도 여러 document..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/ceoL8P/btsGqQBufXZ/Q4dUsabaPabKHzLEbrsSz1/img.png)
서론 현재 우리 팀은 새로 시작하는 프로젝트들은 대부분 DB를 Mongo로 만들어 진행하고 있고 추후 RDB를 사용하고 있는 프로젝트들도 Mongo로 전환 예정이다. MongoDB로 이전하는 이유를 여쭤봤었는데 여러가지 이유가 있지만 제일 큰 이유는 샤딩되어 있는 DB의 원활한 관리라고 하셨다. (현재 도메인의 데이터가 굉장히 많아 여러 sub db에 데이터를 저장하고 있다.) 샤딩이 무엇인지 정리하고 MongoDB에서는 샤딩을 어떠한 방식으로 지원해주는지 정리하기 위해 이 글을 작성하였다. 본론 먼저 sharding만 알아보면 살짝 아쉬우니 이 김에 partitioning과 replication도 같이 알아보자! (두 개념도 알아야 MongoDB의 sharding 방식도 편하게 이해할 수 있다.) Pa..
![](http://i1.daumcdn.net/thumb/C150x150/?fname=https://blog.kakaocdn.net/dn/uImL0/btsFZuzFL5S/Ba2sMSmyD7pr5IhkRqlGvK/img.png)
서론 DB에 직접 bulk update 쿼리를 실행시켜야 했는데 어떻게 하면 조금이라도 최적화 시킬 수 있을까를 검색을 하였더니 temporal table을 만드는 방식이 있었다. 해당 방식을 이번에 처음 알았고 성능이 얼마나 달라질까 궁금하여 직접 일반 업데이트와 temporal table을 생성하여 업데이트 하는 방식을 비교해보았다. 이 글에서 어떤 식으로 쿼리를 작성했고, 결과는 어땠는지를 정리할 예정이다. 본론 실험 조건 데이터는 대략 10만개를 넣어주었다. 많은 필드를 업데이트 하지는 않았고, 단 한 필드만 업데이트 하면 되는 상황이었기에 테스트를 할 때도 한 필드만 업데이트를 했다. (만간에 여러개 업데이트 할 때도 테스트를 할 예정이다.) 일반 update query update item s..
![](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 이러한 쿼리로 구할 수 있다. 만약 인..
서론 프로젝트를 진행하면서 사용자가 원하는 종류에 따라서 기능을 실행해야 하는 요구사항이 있었다. 간단하게 예시를 들자면 Kakao, naver, google, iphone 과 같은 써드파티 로그인 기능들을 구현해야 하는 상황이라고 생각할 수 있다. 위와 같은 로그인 기능을 예시로 프로젝트에서 어떤 식으로 팩토리 패턴을 적용했는지 글을 작성할 예정이다. 본론 일단 팩토리 패턴을 적용하지 않은 간단한 예시 코드를 만들어보자. (각 써드파티 로그인 별로 인증 로직이 조금 다르다고 가정하겠다. ) // controller public Response login (@RequestBody loginRequest) { Boolean success = userService.login(loginRequest); ret..