(최종 프로젝트 진행중)
오늘은 프로젝트에서 나올 수 있는 예상 기술 질문에 대한 질답 시간을 가졌다.
※ 이하는 스스로 공부하며 적어둔 노트이며 불확실한 내용이 있을 수 있습니다. 학습용으로 적합하지 않음을 유념해주세요. ※
커서 기반 페이지네이션 v.s. 오프셋 기반 페이지네이션
커서 기반 페이지네이션 v.s. 오프셋 기반 페이지네이션
과 각각의 장단점
- offset
이전/다음 페이지의 결과를 요청할 때 페이지의 번호와 크기를 지정해 이전 페이지의 마지막 결과 행의 오프셋을 사용하여 다음 페이지의 결과를 가져오는 방식이다.
offset/limit을 사용한 쿼리 이용
- 장점:
- 페이지 단위로 구분해 유저가 페이지를 선택하고 이동가능하며 전체 페이지의 갯수를 알 수 있다.
- 직관적이고 구현이 간단하다. (어드민 페이지 같은 단순한 경우에 적합)
- 단점:
- 데이터 중복, 사용자가 사용하는 동안 새로운 게시글이 생기고 사용자가 다음 요청을 진행했을 때 데이터 값이 중복이 된다. (ex>최신 데이터가 생기면 1페이지에서 본 페이지가 2페이지로 밀리기 때문에 다음 페이지를 눌렀으나 이전 페이지가 보이는 현상이 생긴다. )같은 원리로 삭제 되었을 때 특정 게시글이 조회되지 않는 현상이 있을 수도 있다.
- offset 값이 클 경우 앞에 있는 모든 데이터를 다 읽어야 하기 때문에 뒤로 갈수록 속도가 저하된다.
- 필요하지 않은 결과도 가져오기 때문에 리소스가 낭비될 수 있다.
- 장점:
- cursor-based
이전/다음 페이지의 결과를 요청하면서 쿼리에 커서(cursor)를 사용하여 다음 페이지의 결과를 가져온다.
- 장점:
- 첫 페이지의 쿼리는 리밋으로 설정한 개수로 잘라서 보여지고 이후 페이지에 대한 요청은 사용자에게 응답한 데이터 중 마지막 게시글이 커서가 되어 데이터 중복 발생을 막을 수 있다.
- 이전/다음 페이지의 결과를 검색하면서 커서를 사용하여 다음 페이지의 결과를 가져오기 때문에 페이지가 많아져도 검색 속도가 저하되지 않는다.
- 데이터베이스에서 필요한 만큼만 결과를 가져오기 때문에 리소스 사용이 효율적이다.
- 유저가 접속해 실시간으로 사용하는 경우 커서 기반이 유리하다.
- 단점:
- 커서 기반 페이지네이션을 위해서는 정렬 기준에 포함되는 필드 중 하나 이상은 반드시 유니크값을 가져야 한다. 이렇게 각 페이지의 시작 위치를 식별하는데 사용 되는 커서를 유지 관리 해야하므로 복잡성이 증가할 수 있다.
- 이전/다음 페이지 이외의 페이지 이동이 불가능 하다. 사용자가 특정 페이지로 이동하려면 추가적인 작업이 필요하다.
- 조회 시 정렬 조건이 많아지거나 서버-클라이언트 사이에 커서 인터페이스가 추가 될 수록 구현이 어려워진다.
하지만 두 방법 모두 적절한 페이지에서 사용하지 않으면 효율적이지 않을 수 있기 때문에 사용할 페이지나 서비스에 대한 이해도가 필요할 것 같다. 일반적으로 대규모 데이터베이스에서는 커서 기반을 작은 규모일 경우에는 오프셋 페이지 네이션을 사용하는 것이 구현 및 유지보수가 더 쉽고 편리할 수 있다.
도움 많이 받은 블로그:
커서 기반 페이지네이션 (Cursor-based Pagination) 구현하기사실 처음에는 이 주제로 포스트를 쓰려고 했던건 아니고 Apollo GraphQL 에서 커서 기반 페이지네이션 구현 을 주제로 글을 쓰려고 했습니다. 그런데 막상 찾아보니 백엔드-프론트엔드를 함께 고려하여 커서 기반 페이지네이션을 잘 설명해 놓은 포스트가 없는 것 같아 이 글을 먼저 쓰게 되었습니다. 페이지네이션? 보통 서버에서 데이터를 가져올 때 모...
https://velog.io/@minsangk/커서-기반-페이지네이션-Cursor-based-Pagination-구현하기
면담 때 얻은 팁:
오프셋 기반은 O(N)이고 자료구조의 배열과 같다. 인덱스로 찍으면 주소를 산술 계산해서 O(1)로 얻어올 수 있지만, 원하는 ‘인덱스’를 계산해서 얻어내는 데 바로 오프셋 페이지네이션처럼 O(N)이 걸리는 거라고.
커서기반은 O(1)이고 자료구조의 더블 링크드 리스트와 같다고 했다. 커서가 앞뒤를 가리킨다는 점에서.
- 장점:
JWT의 단점
JWT의 단점
- 알고리즘 없이 암호화가 안 된 페이로드 정보가 그대로 노출된다는 점.
- 한 번 발급되면 토큰의 유효기간을 변경할 수 없다는 점. 만료 기간이 짧으면 보안성은 높아지지만 자주 토큰을 갱신해야 하므로 부담이 될 수 있다.
- JWT를 사용할 때 서버는 클라이언트에게 발급된 토큰만 검사해 서버 측에서 로그아웃 처리가 어렵다는 점.
- 오래된 암호화 알고리즘(파훼가 보고된)을 개발자가 모르고 선택해서 쓸 시 보안 우려가 있다는 점.
- 토큰 헤더에 이 토큰이 사용할 알고리즘을 명시한다는 점. 해커가 중간에 탈취해서 ‘이 토큰이 사용하는 암호화 알고리즘 = none’이라고 수정해버리면, 서명 확인 프로세스를 우회할 수 있게 된다. 즉, 이 토큰을 받은 서버 입장에서 ‘어, 얘는 처음부터 알고리즘이 none이었구나’ 하고선 서버에 저장된 암호키와 대조해 풀어보는 작업 없이 그대로 유효한 토큰이라고 통과시켜버리는 것이다.
https://www.youtube.com/watch?v=H6lpFRpyl14
JWT의 신뢰할 수 있는 대안, PASETO
JWT의 신뢰할 수 있는 대안, PASETO
: Platform Agnostic SEcurity TOken
: 강력한 서명 알고리즘 제공. 개발자가 알고리즘을 선택하지 않고 ‘파세토 버전’을 선택하면 된다. 최신 암호화 루트 2개만이 선택지로 활성화 및 제공된다.
파세토 버전 1: (생략)
파세토 버전 2: 더 현대적. “v2.local.암호화된페이로드.바닥글” 형태.
알고리즘 헤더가 존재하지 않아서 해커의 선택지가 줄어든다. AEAD 변조할 수 없다. 단순 로컬 대칭 키 알고리즘을 사용해도 페이로드가 (단순 인코딩이 아니라) 암호화되므로 데이터가 노출되지 않는다.
(참고: https://dev.to/techschoolguru/why-paseto-is-better-than-jwt-for-token-based-authentication-1b0c )
Uploaded by N2T