Cache 캐시는 나중에 요청할 결과를 미리 저장해 둔 후 빠르게 서비스해주는 것을 의미한다. 즉, 결과를 미리 저장하고 나중에 요청이 오면, 이 요청에 대해서 DB를 참조하지 않고 캐시에 접근하여 요청을 처리하는 기법이다. 그렇다면 어떤 데이터를 캐싱해야할까? 자주 조회되면서 쓰기가 거의 일어나지 않는 데이터에 대해서 캐싱해야한다. 캐싱을 할때 로컬캐싱 vs 글로벌 캐싱 캐싱할 데이터를 선정했다면, 이 데이터를 "어디"에 저장할지 고민해야한다. 일반적으로 로컬메모리에 저장하거나, Redis와 같은 별도 서버에 저장할 수 있다. 로컬캐싱 애플리케이션 서버의 메모리에 캐싱할 데이터를 저장하는 방법이며 일반적으로 Guava cache나 Caffeine cache를 많이 사용한다. 장점 애플리케이션 로직을 수..

Offset pagination SELECT * FROM items WHERE 조건문 ORDER BY id DESC OFFSET 페이지번호 LIMIT 페이지사이즈 offset(몇번째부터 가져올 것인가?)과 limit(몇개를 가져올 것인가?)예약어를 통하여 select전체 결과 중 일부만 가져오는 방법이다. 단점 페이지 요청 시, 데이터 변화가 있는 경우 중복 데이터 발생 예를 들어, 1페이지에서 20개의 row를 불러와서 유저에게 1페이지를 띄워주었다. 고객이 1페이지의 상품을 보고 있는 사이, 상품 운영팀에서 5개의 상품을 새로 올렸다면? 유저가 1페이지 상품을 다 둘러보고 2페이지를 눌렀을 때, 1페이지에서 보았던 상품 20개중 마지막 5개를 다시 2페이지에서 보게 된다. 대부분이 RDBMS에서 OF..

pull mode, push model 타임라인을 구현하는 방법에는 총2가지가 있다. 이때, 타임라인은, 인스타그램, 페이스북, 트위터와 같은 sns의 메인 피드를 의미한다. fanout : 사용자가 게시물을 작성하였을 때, 이 글을 봐야하는 모든 사람들(인스타그램의 팔로워, 페이스북 친구 등)에게 전달하는 과정 push model(fanout-on-write) : 쓰기 시점에 fanout하는 것을 의미한다. 즉, 사용자 1명이 게시글을 적을 때마다, 자신의 팔로워 모두에게 해당 글을 전파한다. pull model(fanout-on-read) : 읽기 시점에 fanout하는 것을 의미한다. 게시글을 적을 때는 별 동작이 없다가, 팔로워 1명이 새로고침하는 시점에 그 사람의 피드만 갱신한다. 따라서 on-..

오프셋 기반 페이지네이션 - 페이징 (장단점) offset만큼 읽는데 이전의 읽었던 것을 다시 쭉 읽은 후 조회해서 데이터가 많아지면 성능상 안 좋다. 데이터 중복 문제: 2페이지 끝까지 읽었는데 앞에 최신 데이터가 들어오면 3페이지 읽을 때 중복이 발생할 수 있다. JPA에서는 Pageable을 이용해서 쉽게 구현할 수 있다. 커서기반 페이지네이션 - 무한스크롤 (장단점) offset을 사용하지 않고 Cursor를 기준으로 다음 n개의 데이터를 응답해주는 방식이다. 따라서 cursor가 unique한 값이어야한다. 데이터 중복이 발생하지 않고, offset과 다르게 이전의 데이터를 읽지 않고 바로 다음 cursor에 대한 정보를 주면 되므로, 대량의 데이터를 다룰 때 성능상 좋다 대신 where절에 여..

petree의 jwt흐름도 Refresh Token을 Redis에 저장한 이유? Redis는 key-value쌍으로 데이터를 관리할 수 있는 data storage이다. DB가 아닌 data storage라고 표현하지 않은 이유는 기본적으로 Redis는 in-memory로 데이터를 관리하므로, 저장된 데이터가 영속적이지 않기 때문이다. 이때 in-memory란? - DISK DBMS의 경우 - 디스크에 저장된 내용을 메인 메모리로 로딩을 해야하며 실행을 위해서는 cpu로 해당 데이터를 재전송해야한다. 하지만 메모리가격보다 저렴하다. - in-memory DBMS의 경우 - 메인 메모리에서 바로 cpu로 데이터를 전송만 하면 되므로 구조상 간단하다. 하지만 비용이 비싸다. 이러한 Redis에 Refresh..

QueryDSL을 도입한 이유 JPQL(Java Persistence Query Language) JPA에서 제공하는 메소드 호출만으로 섬세한 쿼리작성이 어렵다는 문제로 탄생된 것으로 테이블을 대상으로 쿼리하는 것이 아닌 엔터티 객체를 대성으로 쿼리한다. QueryDSL JPQL을 java코드로 작성하게 해주는 JPQL Builder이다. (=쉽게 말해, JPQL을 java코드로 작성가능하다.) 장점 코딩 과정에서 문법에러를 미리 알 수 있으며, 검색을 위한 유동적인 쿼리를 작성할 수 있는 장점을 가지고 있다. 단점 JPA 1차 캐시사용이 불가능하다. JPA를 통해 select하게되면, 영속성 컨텍스트 1차 캐시에 데이터가 저장되는데, QueryDSL은 이를 무시하고 DB에서 직접적으로 조회해온다. 여기..