CS/데이터베이스27 페이지네이션 최적화 - 03. 오프셋 기반 페이징 구현의 문제(1) 오프셋 기반의 페이징 구현 : 마지막 페이지를 구하기 위해 전체 갯수를 알아야 함 전체 페이지의 크기가 클수록 전체 사이즈를 구하는 것 자체가 큰 부하가 될 수 있음 실제 대용량 데이터를 제공하는 서비스를 본다면, 마지막 페이지에 대한 접근을 막거나 무한 스크롤 형태로 제공 그 외에도 쿼리를 보낼 때, offset과 limit의 쿼리를 사용 4번 Offset부터 시작하기 위해 0~3번 Offset까지 데이터를 다시 읽음 4번 Offset부터 size만큼 반환 실제로 반환하는 데이터는 2개인데, 반환하는 2개의 데이터를 읽기까지 4개의 데이터를 읽고 버리게 된다. **(**지금은 Offset이 작기때문에 4개만 버리지만, 실제로는 Offset 사이즈가 커지면 커질수록 버려지는 데이터들이 훨씬 많다) 따라서.. 2023. 6. 6. 페이지네이션 최적화 - 01. 페이지네이션이란 많은 양의 데이터를 어떻게 노출시킬 것인가? 다음 페이지 vs 스크롤 다음 페이지를 넘기는 방식 : 페이지네이션 페이지를 넘기지 않고 내리는 방식 : 스크롤 클라이언트가 원하는 페이지의 원하는 사이즈를 서버에게 요청 서버는 페이지와 사이즈에 따라 적절한 데이터를 스캔 (요청 내용 : page 0, size 2 → size를 2개로 나눴을 때 가장 첫번째 page를 요청하는것) 사이즈를 2로 나눴을 때 첫번째 데이터 2개를 찾아 해당하는 데이터를 반환 여기서는 6을 2개씩 나누면 3 → 첫번째 데이터는 1~2번 게시물 : 반환하는 것 대부분 서버는 전체페이지(totalPages) 혹은 전체 개수(totalElements)를 준다. (UI 상에서 마지막 페이지를 알아야 더보기 화살표를 표시하지 않기 때문) .. 2023. 6. 6. 조회 최적화를 위한 인덱스 이해하기 - 08. 인덱스를 다룰 때 주의해야 할 점 1. 인덱스 필드 가공 인덱스 필드에 가공이 들어가면 인덱스로 찾을 수 없음 // age는 int 타입 SELECT * FROM Member WHERE age*10 = 1 // 10을 곱하면 검색이 안됨 // age는 int 타입 SELECT * FROM Member WHERE age = '1' // type을 잘못 넣어준 경우 2. 복합 인덱스 왼쪽처럼 1개의 인덱스가 아닌 오른쪽처럼 복합 인덱스가 되면? 우선적으로 과일 컬럼이 정렬 과일 컬럼이 정렬되면 그 안에서 원산지 컬럼이 정렬됨 따라서 복합 인덱스에서 중요한 것은 선두 컬럼이다. 데이터의 식별 정도가 높은 값이 선두에 있는 것이 좋음 3. 하나의 쿼리에는 하나의 인덱스만 하나의 쿼리에는 하나의 인덱스만 탄다. 여러 인덱스 테이블을 동시에 탐색하.. 2023. 6. 4. 조회 최적화를 위한 인덱스 이해하기 - 04. 클러스터 인덱스 클러스터 인덱스 3줄 요약 클러스터 인덱스는 데이터 위치를 결정하는 키 값 MySQL의 PK는 클러스터 인덱스 MySQL에서 PK를 제외한 모든 인덱스는 PK를 가지고 있음 클러스터 인덱스는 데이터 위치를 결정 클러스터 키의 중요한 핵심 : 정렬을 이루고 정렬된 순서에 따라서 데이터의 주소가 결정되는 것 클러스터 키 4번이 Insert 정리 클러스터 키의 위치에 따라 데이터의 주소가 결정됨 클러스터 키 순서에 따라서 데이터 저장 위치가 변경된다 → 클러스터 키 삽입/갱신시에 성능이슈 발생 MySQL의 PK는 클러스터 인덱스 PK 순서에 따라서 데이터 저장 위치가 변경됨 → PK 키 삽입/갱신 시에 성능 이슈 발생 PK로 Auto Increment vs UUID 찾아보기 MySQL에서 PK를 제외한 모든 .. 2023. 6. 4. 이전 1 2 3 4 5 6 7 다음
