💾[Database] 게시글 목록 조회 - 페이징 처리.

✅1️⃣ 비효율적인 페이징 처리.

• ↘︎ 서버 애플리케이션 내의 메모리로 디스크에 저장된 모든 데이터를 가져오고, 특정 페이지만 추출하는 것은 비효율적임.
  • ↘︎ 디스크 접근은 메모리 접근보다 느리기 때문임.
    • ↘︎ 디스크 I/O 비용
  • ↘︎ 디스크에 저장된 데이터는 메모리 용량을 초과할 수 있음.
    • ↘︎ Out of Memory(OOM)
      • ↘︎ 시스템에서 사용 가능한 메모리가 모두 사용되어 더 이상 할 당할 수 없는 상황.

        ✅2️⃣ 효율적인 페이징 처리.

• ↘︎ 데이터베이스에서 특정 페이지의 데이터만 바로 추출하는 방법이 필요함.
  • ↘︎ 페이징 쿼리

    ✅3️⃣ 페이징 방식.

• ↘︎ 클라이언트 또는 서비스 특성에 따라 크게 두 가지로 나뉨
  • ↘︎ 페이지 번호
  • ↘︎ ** 무한 스크롤**

    📌 페이지 번호 방식.

• ↘︎ 이동할 페이지 번호가 명시적으로 지정됨.
• ↘︎ 원하는 페이지로 즉시 이동 가능.

  📌 무한 스크롤 방식.

• ↘︎ 스크롤을 내리면 다음 데이터가 조회됨. ➞ 더보기.
• ↘︎ 주로 모바일 환경에서 사용함.

✅4️⃣ 페이지 번호 방식.

• ↘︎ 필요한 정보
  • ↘︎ 1️⃣ N번 페이지에서 M개의 게시글
  • ↘︎ 2️⃣ 게시글의 개수
    • ↘︎ 페이지 번호 활성화에 필요.
    • ↘︎ 예시: 페이지 당 30개의 게시글을 보여주고, 총 94개의 게시글이 있다면, 사용자는 클라이언트 화면에서 4번 페이지까지 이동할 수 있다는 사실을 인지해야 함.
  • ↘︎ 3️⃣ N번 페이지에서 M개의 게시글을 조회하려면?
    • ↘︎ SQL offset, limit을 활용하여 페이지 쿼리를 할 수 있음.
    • ↘︎ offset 지점부터, limit개의 데이터 조회.
  • ↘︎ 4️⃣ SELECT 쿼리로 만들어보면?
    • ↘︎ 게시판별 게시글 목록 최신순 조회
      • ↘︎ shard key = board_id이기 때문에, 단일 샤드에서 조회할 수 있음.
      • ↘︎ limit = M개의 게시글
      • ↘︎ offset = (N번 페이지 - 1) * M
        • ↘︎ N > 0
    • ↘︎ SQL QUERY

        SELECT * FROM article // 게시글 테이블
        WHERE board_id = {board_id} // 게시판별
        ORDER BY created_at DESC // 최신순
        LIMIT {LIMIT} OFFSET {OFFSET}; // N번 페이지에서 M개
      

      

    • ↘︎ 1,200만 건의 적은 데이터에서 30개의 게시글을 조회하는데 4초가 소요되었음. 정상적으로 서비스하기에는 어려운 상황임.

    

    • ↘︎ explain select * from article where board_id = 1 order by created_at desc limit 30 offset 90;
    • ↘︎ type = ALL ➞ 테이블 전체를 읽는다 (풀 스캔)
    • ↘︎ Extras = Using where; Using filesort ➞ where 절로 조건에 대해 필터링,
      • ↘︎ 데이터가 많기 때문에 메모리에서 정렬을 수행할 수 없어서, 파일(디스크)에서 데이터를 정렬하는 filesort 수행
      • ↘︎ 전체 데이터에 대해 필터링 및 정렬하기 때문에 아주 큰 비용이 든 것.

🙋‍♂️ Query Plain
데이터베이스에서 쿼리에 의해 데이터 접근이 실행되는 계획 또는 절차 사용법.
explain {query}

✅5️⃣ 인덱스에 대한 이해

📌 Intro

• ↘︎ 인덱스(Index)는 데이터베이스에서 데이터를 빠르게 검색하기 위해 사용하는 데이터 구조.
• ↘︎ 책의 색인(Index)과 비슷한 개념으로, 특정 데이터를 찾기 위해 모든 데이터를 처음부터 끝까지 탐색하지 않고도 원하는 데이터를 효율적으로 조회할 수 있도록 도와줌.

✅6️⃣ 인덱스의 핵심 개념.

• ↘︎ 빠른 검색 : 테이블에서 특정 데이터를 더 빠르게 찾을 수 있음.
• ↘︎ 정렬된 구조 : 인덱스는 일반적으로 B-Tree 또는 Hash 구조를 사용하여 데이터를 정렬함.
• ↘︎ 조회 성능 향상 : WHERE, JOIN, BY와 같은 SQL 연산 시 성능을 개선함.
• ↘︎ 공간 차지 : 인덱스를 유지하기 위해 추가적인 저장 공간이 필요함.
• ↘︎ 쓰기 성능 저하 : INSERT, UPDATE, DELETE 작업 시 인덱스를 업데이트해야 하므로 쓰기 작업의 성능이 저하될 수 있음.

✅7️⃣ 인덱스의 작동 원리.

• ↘︎ 데이터베이스는 테이블의 특정 컬럼(열)에 인덱스를 생성함.
• ↘︎ SQL 쿼리를 실행할 때, 인덱스가 있는 컬럼을 기준으로 데이터베이스 엔진은 인덱스를 먼저 조회함.
• ↘︎ 인덱스를 통해 데이터의 위치를 찾고, 해당 위치에서 데이터를 가져옴.

✅8️⃣ 인덱스의 종류.

1️⃣ 일반 인덱스(B-Tree Index)

• ↘︎ 가장 많이 사용되는 인덱스.
• ↘︎ 컬럼의 값을 오름차순 또는 내림차순으로 정렬하여 저장함.

2️⃣ 고유 인덱스(Unique Index)

• ↘︎ 인덱스가 지정된 컬럼은 중복된 값을 가질 수 없음.
• ↘︎ PRIMARY KEY나 UNIQUE 제약 조건이 포함된 경우 자동으로 생성됨.

3️⃣ 복합 인덱스(Composite Index)

• ↘︎ 두 개 이상의 컬럼을 결합하여 하나의 인덱스를 만듦.
• ↘︎ 복합 인덱스는 여러 조건을 동시에 사용할 때 유용.

4️⃣ 풀텍스트 인덱스(Full-Text Index)

• ↘︎ 문자열 검색에 최적화된 인덱스.
• ↘︎ 대량의 텍스트 데이터를 검색할 때 사용.

5️⃣ 해시 인덱스(Hash Index)

• ↘︎ 값을 해시 함수로 변환하여 저장.
• ↘︎ 정확한 값을 빠르게 찾을 때 사용.

✅9️⃣ 인덱스를 사용해야 하는 경우.

• ↘︎ WHERE 절로 특정 데이터를 자주 조회할 때.
• ↘︎ JOIN 연산이 빈번하게 발생할 때.
• ↘︎ ORDER BY 또는 GROUP BY 절로 정렬이나 그룹화가 필요할 때
• ↘︎ 자주 사용되는 컬럼에 대해 빠른 검색이 필요할 때.

✅1️⃣0️⃣ 인덱스 사용 시 주의점.

• ↘︎ 과도한 인덱스 생성 : 너무 많은 인덱스는 쓰기 성능을 저하시키고, 추가적인 저장 공간을 차지함.
• ↘︎ 불필요한 인덱스 : 자주 사용되지 않는 인덱스는 오히려 성능 저하를 유발할 수 있음.
• ↘︎ 인덱스 히트 비율(Index Hit Rate) : 쿼리가 인덱스를 제대로 활용하는지 모니터링해야 함.