1. 만약, Redis가 멈추거나 문제가 발생하여, Redis를 재기동 되었습니다.이때, 리프레시 토큰 또는 추후에 개발 예정이신 채널 선택 시 발생하는 정보들이 없어지게 될 텐데요. 이걸 해결하기 위한 방법은 어떤 것들이 있을까요?
→ 대부분의 경우 메모리의 관리로 해결해야 합니다. ( 재기동, 문제 발생 상황을 차단해야 합니다 ).
- O(N) 연산 X, 단순 get/set 등 O(1) 연산으로 처리해야 한다.
- O(N) 명령어는 keys / flushAll,flushDB / delete collections / get all collections 등
추가 조사가 필요합니다.
추가 1. 레디스 백업
→ 레디스 디폴트 설정 값도 있고, 더하여 단순 캐싱 기능만 하면 아래 방식의 영구 저장이 필요 없을 수 있습니다.
[REDIS] 📚 캐시 데이터 영구 저장하는 방법 (RDB / AOF)
2. 현재 카카오로그인 코드를 보게 되면, 카카오 로그인만을 위한 코드가 작성되어 있는데요. 만약에, 구글 로그인, 애플로그인, 네이버 로그인 등 외부 로그인을 추가하게 될 경우, 기존에 사용하는 코드의 변경 없이, 새로운 로그인 방식을 추가할 수 있는 방법은 없을까요?
추가 조사가 필요합니다.
Getting Started | Spring Boot and OAuth2
https://datamoney.tistory.com/333
3. @OneToMany 관계에서 List가 아닌 Set을 사용한 이유
→ list 와 set은 대표적으로는 중복을 허용하느냐 의 차이가 있습니다. 그리고 저희가 사용한 LinkedHashSet과 LinkedList/ArrayList 의 차이는 다음과 같습니다.
- ArrayList는 삽입이 일어 날 때마다 전체 ArrayList를 검색해야 할 뿐더러, 값이 계속해서 추가 될 경우에 크기를 재조정하는 연산이 추가 실행 됩니다. 이는 비효율적입니다. 그러나 조회 성능이 빠르다는 장점은 있습니다.
- LinkedList는 위의 문제를 해결 가능합니다. 그러나 조회 성능이 ArrayList보다 느리고, 중복된 값이 혹시 추가 될 경우에 문제가 될 여지가 있습니다.(테이블이 아닌 자바 객체 관점에서)
- LinkedList의 조회 성능 문제를 해결하기 위해서 “Hash”의 개념이 등장합니다. 해쉬는 내부적으로 배열을 사용하여 데이터를 저장하기 때문에 빠른 검색 속도를 가집니다. 더하여 데이터의 추가/삭제 시 기존 데이터를 밀거나 당기는 작업이 필요 없도록 데이터와 연관된 고유한 숫자를 만들어 이를 인덱스로 사용합니다.(LinkedHashMap)
- @OneToMany 를 사용하는 엔티티 컬렉션은 조회, 추가, 삭제가 매우 빈번하게 일어납니다. 따라서 위 ArrayList/LinkedList 의 문제점을 모두 해결 가능 한 대안이 LinkedHashSet이라고 생각했고, 이를 채택했습니다.
4. @Query에서 native=true를 사용하셨는데요. native=true를 사용하신 이유와 사용했을 때의 장단점을 설명하여주세요.
→ JPQL은 실제 DB의 SQL문으로 변환 할 때의 코스트가 있습니다. 조금의 성능 개선이라도 이루고자 하여 사용했습니다.
→ 조사 결과, 사용 할 필요가 크지는 않습니다. 원래 업데이트/딜리트 문에서 JPA는 셀렉트 쿼리가 나갑니다. 그 문제는 JPQL을 사용해서 해결 할 수 있습니다.
- 네이티브 쿼리를 쓰는 이유 중 가장 큰 이유는 DB에서만 사용 할 수 있는 명령어들을 사용하기 위함이라고 합니다.
- 기피하는 이유는 컴파일 시점에 잡아주지 않기 때문도 있고, 특정 컬럼만 조회하고 싶을 경우(이 경우에도 네이티브 쿼리를 많이 사용 하시더군요) JPA의 다른 기능을(Projection, DB 단에서 쓰는 용어이며 JPA에서 지원) 이용 할 수 있습니다.
→ 결론적으로, native qeury를 사용 할 이유는 없을 듯 합니다. (오류 가능성이 큽니다.)
김영한님의 답변을 남깁니다.
