Notice
Recent Posts
Recent Comments
Link
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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 | 29 | 30 |
Tags
- CS
- spring event
- 백엔드개발자
- 데이터베이스
- 인증
- 웹성능최적화
- 성능최적화
- Spring
- 웹개발
- http
- AbstractAggregateRoot
- 보안
- 백엔드개발
- SnowFalke
- 백엔드
- JPA
- 네트워크
- 백엔드기초
- db
- DEVIEW2023
- Spring Boot
- 프론트엔드
- devops
- 캐시
- 세션
- java
- interceptor
- 인프라
- 클린코드
- redis
Archives
- Today
- Total
목록java (5)
이것저것 개발기록
어떤 프로젝트를 진행하던 지금까지 DB의 PK에 대해서 생각해본적은 없었다. 왜냐하면 JPA에 설정해준 전략에 따라서 자동으로 생생해주었고, 항상 유니크한 값을 가지고 있다고 생각했기 때문이다. 하지만 서비스가 커질 수록, 트래픽도 많아지고 분산처리를 해야할 일도 생긴다. 이 말을 들을때도 별로 와닿지는 않았었다. 사실 그만큼의 서비스를 경험해본적도 없고.... 어쨌든! 이러한 요구사항이 생겼다. "기간제로 사용중인 서비스의 이용자의 이용빈도가 적고 사용하지 않기 때문에, 해당 이용자는 데이터 이관을 통해 다른 장비에서 모아서 관리하도록 해야한다." 계속해서 잘 사용하는 이용자에게 좀 더 원할한 서비스... 이를테면 처리도 빠르고 성능도 좋은 그런 서비스를 제공해야하기에 장비의 스펙도 올라가게 되는데, ..
Tech
2023. 1. 7. 20:51