[Lecture] 스프링부트로 직접 만들면서 배우는 대규모 시스템 설계 - (2)

📑 페이징처리와 무한스크롤

📌 대규모 게시글 목록 조회는 왜 복잡할까?

• 모든 게시글 데이터를 한 번에 조회해서 보여줄 수는 없다.
  • 메모리, 네트워크, 시스템 성능 등의 제약 때문이다.
• 따라서 대용량 데이터를 효율적으로 보여주기 위해 페이징 처리가 필요하다.

✅ 페이징을 왜 꼭 해야 하나?

• 서버에서 모든 게시글 데이터를 한꺼번에 불러와 메모리에 올리는 것은 비효율적이다.
  • 디스크에 저장된 데이터를 메모리로 전부 불러오는 건 느리고, 디스크 I/O 비용도 크다.
  • 메모리 한계를 초과하면 OutOfMemoryError(OOM)가 발생할 수 있다.
• 따라서 DB에서 특정 페이지만 추출하는 방식이 필요하다.
  • 이를 위해 페이징 쿼리가 사용된다. (LIMIT, OFFSET, WHERE id < ? 등)

🔄 페이징 방식의 종류

페이징 방식은 클라이언트나 서비스 특성에 따라 크게 2가지로 나뉜다:

1. 페이지 번호 방식

• 사용자가 이동할 페이지 번호를 명시적으로 선택함
• 예: 1페이지, 2페이지, 3페이지 ...
• 장점:
  • 원하는 페이지로 바로 이동 가능
  • 전체 페이지 수를 파악하기 좋음
• 예시:
  • Google 검색 결과 하단 페이지네이션 UI

2. 무한 스크롤 방식

• 사용자가 스크롤을 내리면 자동으로 다음 데이터를 불러오는 방식
• 장점:
  • UX가 자연스러워서 모바일 환경에 적합
  • "더보기" 버튼으로 구현되기도 함
• 주로 SNS, 피드 기반 UI에 많이 사용됨

✅ 마무리

페이징은 단순히 보기 편하게 만들기 위한 기능이 아니라,
성능과 안정성을 위해 반드시 필요한 설계 요소다.
특히 대규모 게시글 시스템에서는 DB, 메모리, 사용자 경험까지 고려한 정교한 페이징 설계가 중요하다.

---

📑 페이지 번호 방식 기반 페이징 처리

select * from article where board_id = 1 order by created_at desc limit 30 offset 90;

30 rows in set (3.81 sec) -- 고작 1,200만 건의 데이터에서 30건을 조회하는데 무려 4초!

 

좋아! 이번 슬라이드들에서는 페이지 번호 방식 기반 페이징 처리에 대한 개념과 SQL 작성 방법까지 설명하고 있어. 블로그에 정리할 수 있도록 요약해줄게👇

 

📄 게시글 목록 조회 – 페이지 번호 방식

✅ 페이지 번호 방식이란?

• 페이지를 번호로 구분해서 조회하는 방식
• 사용자가 N번 페이지를 요청하면 → 그에 해당하는 게시글 M개를 보여주는 구조

✅ 필요한 정보

1. N번 페이지에서 M개의 게시글을 보여준다는 기준
2. 전체 게시글 수를 알아야 페이지 번호를 계산할 수 있음
   • 예: 페이지당 30개, 총 94개의 게시글이면 → 4페이지까지 있음
   • 이걸 바탕으로 클라이언트 UI에서 페이지 버튼을 활성화할 수 있음

✅ 페이지 번호 방식의 SQL 작성법

• SQL의 LIMIT, OFFSET 문법을 활용
• LIMIT: 한 페이지에 보여줄 개수 (M)
• OFFSET: 몇 개 건너뛸지 → (N - 1) * M

-- 최신순으로 특정 페이지의 게시글 조회
select * 
from article
where board_id = {board_id}              -- 게시판 ID
order by created_at desc                 -- 최신순 정렬
limit {limit} offset {(N - 1) * limit};  -- N번 페이지에서 M개 조회

✅ 참고: 성능과 샤딩 고려

• board_id를 shard key로 사용하면,
  • 각 게시판에 대한 쿼리는 단일 샤드에서 처리 가능
  • → 확장성, 성능에 유리함

💬 마무리 요약

페이지 번호 방식은 직관적이고 UI 구성에 좋지만,
OFFSET이 클수록 성능이 떨어질 수 있으므로,
규모가 크면 Cursor 기반 페이징 방식도 함께 고려해야 한다.

원하면 이어서 "Cursor 기반 무한 스크롤 페이징" 방식도 요약해줄게!
또는 이 내용을 Markdown/HTML로 바꿔줄 수도 있어.

---

📑 EXPLAIN을 활용해서 Query Plan 을 확인할 수 있다.

explain select * from article where board_id = 1 order by created_at desc limit 30 offset 90;

+----+-------------+---------+------------+------+---------------+------+---------+------+----------+----------+-----------------------------+
| id | select_type | table   | partitions | type | possible_keys | key  | key_len | ref  | rows     | filtered | Extra                       |
+----+-------------+---------+------------+------+---------------+------+---------+------+----------+----------+-----------------------------+
|  1 | SIMPLE      | article | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 12548751 |    10.00 | Using where; Using filesort |
+----+-------------+---------+------------+------+---------------+------+---------+------+----------+----------+-----------------------------+

 

좋아! 이 EXPLAIN 결과는 SQL 성능 분석을 위한 핵심 도구야.
지금 너가 조회한 쿼리:

SELECT * FROM article
WHERE board_id = 1
ORDER BY created_at DESC
LIMIT 30 OFFSET 90;

 

이 쿼리를 EXPLAIN으로 분석한 결과를 요약하면 다음과 같아👇

 

📌 EXPLAIN 분석 요약

항목	결과	의미
type	ALL	❗ 테이블 전체를 스캔함 (풀 테이블 스캔) → 성능 매우 안 좋음
rows	약 1,100만	이만큼의 행을 훑어야 한다는 의미
Extra	Using where; Using filesort

• Using where: 조건 board_id = 1로 필터링 중
• Using filesort: 정렬(created_at DESC) 을 위해 메모리에 올리지 못하고 디스크에서 정렬 수행함 → 느림 |

🧠 왜 느릴까?

• 인덱스가 없거나, 인덱스를 제대로 활용하지 못해서 ALL 스캔 발생
• ORDER BY created_at DESC 때문에 MySQL이 정렬을 따로 수행함 (filesort)
• OFFSET 90도 성능에 악영향: 앞의 90개는 건너뛰기 위해 미리 다 읽어야 함

✅ 개선 방향

1. 복합 인덱스 추가

CREATE INDEX idx_board_created ON article(board_id, created_at DESC);

1. WHERE 절과 정렬 조건을 모두 포함한 인덱스를 만들어야 함
   • 그래야 filesort 없이 인덱스만으로 정렬 가능
2. OFFSET 대신 Cursor 방식(무한 스크롤) 고려
   • 특히 페이지 번호가 커질수록 OFFSET은 느림

✅ 정리 요약

항목	설명
type = ALL	인덱스를 사용하지 않고 전체 테이블을 스캔 중
Using filesort	인덱스만으로 정렬하지 못하고, 디스크로 정렬하는 중
개선 필요	board_id + created_at 복합 인덱스 추가 필요
대안	OFFSET 대신 cursor 기반 페이징 고려 시 성능 개선 가능

필요하면 cursor 기반 페이징 쿼리 예시, filesort 없애는 쿼리 최적화 예시, MySQL 실행 계획 더 자세한 항목 설명도 이어서 알려줄게!

---

📑 RDB는 주로 B+ tree (Balanced Tree)

- 데이터가 정렬된 상태로 저장

- 검색, 삽입, 삭제 연산을 로그 시간에 수행 가능

- 트리 구조에서 leaf node 간 연결되기 때문에 범위 검색 효율적

create index idx_board_id_article_id on article(board_id asc, article_id desc);

 

- board_id 오름차순, article_id 내림차순 정렬

- 인덱스는 순서가 중요하다.

select * from article where board_id = 1 order by created_at desc limit 30 offset 90;

explain select * from article where board_id = 1 order by created_at desc limit 30 offset 90;

+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------+
| id | select_type | table   | partitions | type | possible_keys           | key                     | key_len | ref   | rows    | filtered | Extra |
+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------+
|  1 | SIMPLE      | article | NULL       | ref  | idx_board_id_article_id | idx_board_id_article_id | 8       | const | 6274375 |   100.00 | NULL  |
+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------+

 

모든 문제가 해결된건 아니다.

select * from article where board_id = 1 order by article_id desc limit 30 offset 1499970;

30 rows in set (3.23 sec)

 

쿼리 플랜은 동일하고 offset만 바꼈을 뿐인데 왜 이렇게 차이가 나지?

이를 이해하기 위해선 인덱스의 종류를 알 필요가 있다.

1. Clusterd Index

2. Secondary Index

 

📌 인덱스에 대한 이해 – MySQL(InnoDB)

✅ InnoDB란?

• MySQL의 기본 스토리지 엔진
• DB에서 데이터를 저장하고 관리하는 장치
• InnoDB는 **테이블마다 자동으로 Clustered Index(클러스터형 인덱스)**를 생성함

🧱 Clustered Index란?

• 테이블의 Primary Key를 기준으로 정렬된 인덱스
• 보통 Primary Key가 Clustered Index의 기준 키가 됨
• 이 인덱스의 leaf node가 실제 행(Row)의 데이터를 직접 담고 있음

📌 정리하자면:

Clustered Index는 정렬된 인덱스이며,
leaf 노드에 key-value처럼 Primary Key = Row 데이터 형태로 저장된다.

 

📊 예시 그림 – Clustered Index 구조

아래는 Clustered Index가 어떻게 생겼는지를 보여주는 구조도야:

                 [ Root Node ]
                    /    \
          [ id=1~3 ]    [ id=4~6 ]
            /   \           /   \
       [id=1] [id=2]   [id=4] [id=5]
       data1  data2    data4  data5

• 정렬 기준: Primary Key
• leaf node에 실제 데이터가 존재

📁 실제 테이블 적용 예: article 테이블

CREATE TABLE article (
  article_id BIGINT PRIMARY KEY,
  title VARCHAR(255),
  ...
) ENGINE=InnoDB;

• article_id는 Primary Key이므로,
  자동으로 Clustered Index로 생성됨

→ 즉, 아래와 같은 구조가 됨:

Clustered Index: key = article_id
---------------------------------
[article_id=1] → article1 row data
[article_id=2] → article2 row data
[article_id=3] → article3 row data
...

 

→ Primary Key를 조건으로 한 쿼리는 이 Clustered Index를 직접 사용해서 매우 빠르게 검색됨

 

✅ 요약

개념	설명
Clustered Index	InnoDB에서 기본적으로 테이블마다 생성됨 (보통 PK 기준)
leaf node	실제 행(row) 데이터를 포함
정렬 기준	Primary Key에 따라 자동 정렬
효율성	PK로 조회 시 매우 빠른 성능 제공
주의점	PK 외 다른 컬럼 기준 인덱스는 Secondary Index (→ row lookup 필요)

필요하면 다음도 설명해줄 수 있어:

• Clustered vs Non-clustered Index 차이
• Secondary Index와 Row Lookup 과정
• 인덱스 설계 시 주의할 점 (너무 많으면 안 되는 이유 등)

이미지 포함된 HTML/Markdown 버전도 원하면 만들어줄게!

 

우리가 생성한 Index (board_id_article_id index) 는 Secondary Index (Non-Clustered Index)다.

Secondary Index 의 leaf node는 다음 데이터를 가지고 있다.

1. 인덱스 컬럼 데이터

2. 데이터에 접근하기 위한 포인터

- 데이터는 Clustered Index가 가지고 있다.

  > Clustered Index에 접근하기 위한 포인터

  > Primary Key

 

📌 Secondary Index 조회 성능 저하의 원인 정리

✅ Clustered Index는?

• InnoDB는 **Primary Key를 기준으로 정렬된 인덱스(Tree 구조)**를 테이블마다 자동 생성
• 이 인덱스는 leaf 노드에 실제 row 데이터를 포함하고 있어 바로 조회 가능함
• 즉, Primary Key로 조회하면 성능이 매우 빠름

✅ Secondary Index는?

• Primary Key가 아닌 컬럼에 생성하는 인덱스
• leaf 노드에는 row 데이터를 직접 포함하지 않고,
  → 대신 **"해당 row의 Primary Key 값(PK pointer)"**를 가짐

🔁 Secondary Index를 이용한 데이터 조회 과정

1. Secondary Index 탐색
   • 원하는 조건(col=4)을 가진 **id(PK)**를 찾음
2. **찾은 PK(id)**를 기반으로,
   → 다시 **Clustered Index(Primary Key Tree)**에 접근해 row를 찾음

👉 즉, 인덱스를 두 번 타야 한다!

 

📉 성능 이슈: 페이징 쿼리에서 느려지는 이유

예를 들어 다음과 같은 페이징 쿼리를 수행할 때:

SELECT * FROM article
WHERE board_id = 1
ORDER BY article_id DESC
LIMIT 30 OFFSET 1,499,970;

 

실행 흐름:

1. (board_id, article_id) 인덱스에서 **PK(article_id)**를 순서대로 탐색
2. 각 article_id마다 Clustered Index에서 실제 row data를 다시 조회
3. 이를 1499970번 반복해서 skip함
4. 마지막에 LIMIT 30개만 추출

⚠️ 결과

• 인덱스 트리를 2번 탐색하면서,
• 1,499,970개의 row를 스캔 후 30개만 사용
• → 성능 최악 (느려짐)

 

Q: 둘다 offset 1, offset 2, offset 3, ... offset 1499970 하는건 똑같잖아 차이점은 하나는 secondary index만 탄다는거고 다른 하나는 secondary index → clustered index 를 탄다는거고 근데 이렇게 시간차이가 많이나?

거의 20배 나네 왜지 내 생각에는 logN * 1499970 vs logN+logM*1499970 인데 맞나?

 

이 관찰은 아주 예리하고 정확한 방향으로 가고 있어요.
맞아요, 두 쿼리 다 offset 1499970까지 일일이 스캔해야 하는 것은 동일합니다.
하지만 성능 차이가 **20배 이상 나는 진짜 이유는 "데이터 접근 경로의 I/O 비용 차이"입니다.

 

✅ 핵심 차이: 데이터 접근 경로의 무게

항목	SELECT board_id, article_id	SELECT *
인덱스만으로 결과 도출 가능	✅ (covering index: 인덱스 레벨에서 모든 데이터 존재)	❌ (인덱스 → PK 값 → 실제 row 로 이동 필요)
스캔 시 필요한 I/O	인덱스 page만 스캔 (가볍고 빠름)	매 row마다 table row 접근 (무겁고 느림)
MySQL 접근 과정	1단계 (index만)	2단계 (index → clustered)
I/O cost (rough scale)	O(logN)	O(logN + logM) or O(logN) + disk seek

 

📉 디스크 접근 비용 예시

 

각 row에 대해:

• SELECT board_id, article_id는 인덱스 page에서 linearly scan
• SELECT *는 인덱스 → PK → row 위치로 가야 하므로 random disk I/O 발생
  (특히 InnoDB에서 clustered index는 데이터 자체니까 디스크 탐색 많음)

즉, 149만 번 * (디스크 탐색 + I/O)가 추가되는 거예요.

 

📐 시간복잡도로 비유하자면?

네 말처럼:

• Covering index:
  O(logN) (B+트리 인덱스 스캔만)
• Secondary index → PK:
  O(logN) + O(logM) + random I/O

→ 그런데 실제 시간 차는 CPU 연산량보다 디스크 I/O 패턴에 의해 좌우됩니다.

 

🧠 실무 감각적으로 표현하자면?

• Covering index:
  책 목차만 훑는 것
• Secondary index + PK:
  목차 보고 매번 책 본문으로 가서 내용까지 읽는 것

→ 그게 수백만 번 반복되면 당연히 현실 시간은 20배 이상 차이 나게 됩니다.

 

✅ 그래서 실무 팁

• offset이 크면 절대 SELECT * 하지 말 것
• preview용 쿼리는 covering index 활용
• 전체 row가 필요하면 Seek 방식으로 pagination 구현

 

✅ 요약 한 줄

Secondary Index는 데이터 조회 시 Clustered Index를 다시 한번 거치기 때문에,
OFFSET이 클수록 "두 번 타는 비용"이 누적되어 느려진다.

데이터는 offset 1,499,970부터 30개만 필요하다.

그런데 offset 1,4999,970을 만날 때 까지 데이터에 접근하고 있는 것이다. (Secondary Index → Clustered Index * 1,499,970)

이렇게 비효율적이고 무의미한 과정을 생략해보자.

 

우리가 만든 Secondary Index는 board_id 와 article_id를 포함한다.

Secondary Index에서 필요한 30건에 대해서 (1,499,971 ~ 1,500,000) article_id 만 먼저 추출하고,

그 30건에 대해서만 Clustered Index에 접근하면 충분하지 않나?

article_id는 Clustered Index에 접근하지 않아도 충분히 가져올 수 있는 정보일지 모른다.

Secondary Index

select 
  board_id, 
  article_id 
from article 
where board_id = 1 
order by article_id desc 
limit 30 offset 1499970;

30 rows in set (0.37 sec)

explain
select 
  board_id, 
  article_id 
from article 
where board_id = 1 
order by article_id desc 
limit 30 offset 1499970;

+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------------+
| id | select_type | table   | partitions | type | possible_keys           | key                     | key_len | ref   | rows    | filtered | Extra       |
+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------------+
|  1 | SIMPLE      | article | NULL       | ref  | idx_board_id_article_id | idx_board_id_article_id | 8       | const | 6274375 |   100.00 | Using index |
+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------------+

 

Query Plan을 살펴보자

인덱스는 동일하게 사용되었으나, Extra=Using index가 추가됐다.

인덱스를 사용해서 데이터를 조회했음을 의미한다.

 

[비교군]

explain
select 
  *
from article 
where board_id = 1 
order by article_id desc 
limit 30 offset 1499970;

+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------+
| id | select_type | table   | partitions | type | possible_keys           | key                     | key_len | ref   | rows    | filtered | Extra |
+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------+
|  1 | SIMPLE      | article | NULL       | ref  | idx_board_id_article_id | idx_board_id_article_id | 8       | const | 6274375 |   100.00 | NULL  |
+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------+

 

이렇게 인덱스의 데이터만으로 데이터를 조회하는 것을 Covering Index 라고 함

﹡ Covering Index란 쿼리가 필요한 모든 데이터를 인덱스만 보고도 처리할 수 있는 경우

Clustered Index를 거치지 않고 바로 1499970까지 달렸다.

 

이제 추출된 30건에 대해서만 Clustered Index에 접근하면 된다.

30건의 article_id를 sub query의 결과로 만들고, article 테이블과 join 하자

select *
from (
  select 
    article_id
  from article
  where board_id = 1
  order by article_id desc
  limit 30 offset 1499970
) t1
left join article t2
on t1.article_id = t2.article_id

explain
select *
from (
  select 
    article_id
  from article
  where board_id = 1
  order by article_id desc
  limit 30 offset 1499970
) t1
left join article t2
on t1.article_id = t2.article_id

+----+-------------+------------+------------+--------+-------------------------+-------------------------+---------+---------------+---------+----------+-------------+
| id | select_type | table      | partitions | type   | possible_keys           | key                     | key_len | ref           | rows    | filtered | Extra       |
+----+-------------+------------+------------+--------+-------------------------+-------------------------+---------+---------------+---------+----------+-------------+
|  1 | PRIMARY     | <derived2> | NULL       | ALL    | NULL                    | NULL                    | NULL    | NULL          | 1500000 |   100.00 | NULL        |
|  1 | PRIMARY     | t2         | NULL       | eq_ref | PRIMARY                 | PRIMARY                 | 8       | t1.article_id |       1 |   100.00 | NULL        |
|  2 | DERIVED     | article    | NULL       | ref    | idx_board_id_article_id | idx_board_id_article_id | 8       | const         | 6274375 |   100.00 | Using index |
+----+-------------+------------+------------+--------+-------------------------+-------------------------+---------+---------------+---------+----------+-------------+

 

article_id 추출을 위한 sub query 생성 과정에서 파생 테이블이 생기지만 (DERIVED),

이 과정에서 Covering Index가 사용되었다.

작은 규모의 파생 테이블과 join하여 30건에 대해서만 Clustered Index(PRIMARY)에서 데이터를 가져온다.

 

이제 문제가 해결된걸까? 이젠 50,000번 페이지가 아니라 300,000번 페이지를 조회해보자

select *
from (
  select 
    article_id
  from article
  where board_id = 1
  order by article_id desc
  limit 30 offset 8999970
) t1
left join article t2
on t1.article_id = t2.article_id

30 rows in set (1.32 sec)

 

살짝 느린데? 1초 → 뒤로 갈수록 느려지는 문제는 여전한 것이다.

 

사실 동작과정을 생각해보면 당연한 것

article_id 추출을 위해 Secondary Index만 탄다고 해도 offset(89,999,970)만큼 Index Scan이 필요하기 때문.

 

해결 방법은?

 

📘 게시글 목록 조회 – 페이지 번호

✅ 데이터를 한 번 더 분리한다

• 예를 들어, 게시글을 1년 단위로 테이블 분리한다.
  • 개별 테이블의 크기를 작게 만들 수 있다.
  • 각 단위(1년)에 대해 전체 게시글 수를 따로 관리할 수 있다.

✅ offset을 페이지 단위가 아닌 게시글 수 단위로 skip

• offset은 단순히 인덱스 페이지를 넘기는 것이 아니라, 실제로 존재하는 게시글 개수 단위로 skip한다.
• 예시:
  • offset이 1년간 작성된 게시글 수보다 크면, 해당 년도의 게시글 전체를 skip
  • 즉, 더 큰 단위(예: 연도별 테이블)로 skip을 수행
• 이를 위해 애플리케이션에서 직접 처리하는 코드가 필요하다.

📘 게시글 목록 조회 – 페이지 번호 (2)

❓ 300,000번 페이지를 조회하는 사용자는 정상일까?

• 이는 데이터 수집을 목적으로 하는 어뷰저일 가능성이 있다.

🛠 정책으로 해결하기

• 예: 게시글 목록 조회는 최대 10,000 페이지까지만 허용
• 또는 시간 범위 혹은 검색 키워드 기반 조회 기능 제공
  • 작은 데이터 범위 안에서만 페이징을 수행하게 유도

📘 게시글 목록 조회 – 페이지 번호 (3)

🔁 무한 스크롤

• 페이지 번호 방식은 뒷 페이지로 갈수록 느려질 수밖에 없음
  • OFFSET 방식은 이전 데이터를 전부 스캔하기 때문
• 하지만 무한 스크롤은 어느 위치든 일정한 속도로 조회 가능
  • 이건 OFFSET 대신 WHERE id < ? ORDER BY id DESC LIMIT ? 같은 커서 기반 페이징 방식 덕분
• 페이지 번호 방식에 대한 설명을 마친 후, 무한 스크롤 방식을 자세히 살펴볼 예정

explain select count(*) from article where board_id = 1;

+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------------+
| id | select_type | table   | partitions | type | possible_keys           | key                     | key_len | ref   | rows    | filtered | Extra       |
+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------------+
|  1 | SIMPLE      | article | NULL       | ref  | idx_board_id_article_id | idx_board_id_article_id | 8       | const | 6274375 |   100.00 | Using index |
+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------------+

 

전체 개수 조회는 1초 이상 걸린다. (Covering Index 사용됐지만 120만 건 조회해야 해서)

 

근데 페이징을 생각해보면 

◀︎ 1 2 3 4 5 6 7 8 9 10 ▶︎                          : 301개 게시물의 유무만 알면 된다.

◀︎ 11 12 13 14 15 16 17 18 19 20 ▶︎          : 601개 게시물의 유무만 알면 된다.

◀︎ 21 22 23 24 25 26 27 28 29 30 ▶︎     : 901개 게시물의 유무만 알면 된다.

 

화면 구현을 위해 굳이 모든 게시글을 조회할 필요는 없다.

사용자가 현재 이용 중인 페이지 기준에 따라서, 게시글 개수의 일부만 확인하면 되는 것이다.

전체가 아니라 일부에 대해서만 카운트 할 수 있기 때문에 큰 비용없이 처리할 수 있다.

 

[공식화]

- 현재 페이지 : n (n>0)

- 페이지 당 게시글 개수 : m

- 이동 가능한 페이지 개수 : k

﹡(n - 1) / k 의 나머지는 버림

 

→ `((n - 1) / k + 1) * m * k + 1`

---

📑 트랜잭션 & B+ Tree 참고

쉬운코드

---

📑 Pageable 사용하면 최적화된 쿼리가 만들어지지 않아서 nativeQuery = true로 사용?

---

📑 페이지 번호 방식을 사용하면 데이터가 중복/누락 될 수 있다.

앞서 만든 인덱스 데이터 (board_id asc, article_id desc)

 

1번 사용자는 페이지 번호 방식으로 1번째 스크롤에서 게시글 3개를 조회. (offset=0, limit=3)

이 시점에 2번 사용자에 의해 신규 게시글(article_id=8) 추가

1번 사용자는 스크롤을 내려서 2번째 스크롤을 조회.

게시글이 밀려서 article=5 게시글이 중복 조회된다.

 

다시 초기 상태 (사용자가 첫번째 스크롤을 조회하고 있다.)

2번 사용자가 article=2 게시글을 삭제한다.

사용자가 스크롤을 내려 2번 스크롤로 이동하면 article=4게시글을 누락한 채 article=3부터 조회하게 된다.

즉, 페이지 번호 방식은 무한 스크롤에 적합하지 않다.

 

해결하기 위해서는 무한스크롤에 적합한 방식이 필요하다.

 

무한스크롤에서는 마지막으로 불러온 데이터를 기준점으로 삼을 수 있다.

사용자는 첫번째 스크롤을 조회하고, article=5를 기준점으로 기억한다.

 

이 시점에 다른 사용자에 의해 article=8 게시글이 추가되고, 기존 사용자는 스크롤을 내려서 2번째 스크롤을 조회한다.

아까 기억한 article=5 미만의 데이터를 조회하게 된다. 

 

정확한 기준점(board_id=1, article_id=5)이 있기 때문에 인덱스 트리에서 로그시간에 기준점을 찾을 수 있다.

﹡ 로그시간인 이유는 B+Tree 라서 이분탐색이랑 비슷하게 탐색하게 되기 때문에

기준점에서 부터 limit 3개를 조회한다. 이번에는 게시글의 중복없이 조회될 수 있다.

이후 article=2로 기준점을 다시 기억하게 된다.

 

select * 
from article
where board_id = 1
order by article_id desc
limit 30;

select * 
from article
where board_id = 1
and article_id < #{이전에 조회한 마지막 기준점 article_id}
order by article_id desc
limit 30;

explain select * from article where board_id = 1 order by article_id desc limit 30;

+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------+
| id | select_type | table   | partitions | type | possible_keys           | key                     | key_len | ref   | rows    | filtered | Extra |
+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------+
|  1 | SIMPLE      | article | NULL       | ref  | idx_board_id_article_id | idx_board_id_article_id | 8       | const | 6274375 |   100.00 | NULL  |
+----+-------------+---------+------------+------+-------------------------+-------------------------+---------+-------+---------+----------+-------+

 

기준점을 O(logN) 시간을 통해 찾기 때문에 마지막페이지 조회속도도 동일하다.

 

기능 구현 순서 (레퍼지토리 → 레퍼지토리 테스트 → 서비스 → 컨트롤러 → API 테스트)

---

📑 PK 생성 전략

1) DB auto_increment

2) unique String or int

3) unique sorted String

4) unique sorted int

 

1) DB auto_increment

분산 데이터 환경 (샤드1, 샤드2)

﹡분산 데이터 환경에서 식별자가 중복될 수 있기 때문에, 식별자의 유일성이 보장되지 않는다.

(여러 샤드에서 동일한 PK를 가지는 상황)

﹡ 클라이언트 측에 노출하면 보안 문제

데이터 개수 또는 특정 시점의 식별자 예측

(방금 가입했더니 user_id=1,000 이면 1,000명의 사용자가 있다는 사실 유추 가능)

﹡간단하다는 장점

- 보안적인 문제를 크게 고려하지 않거나

- 단일 DB를 사용하는 경우 또는 애플리케이션 층에서 PK의 중복을 직접 구분하는 상황에서 사용 가능

 

보안적인 문제만 염려된다면, PK는 DB내에서의 식별자로만 사용하고,

애플리케이션 계층에서의 식별자로 사용하기 위해 별도의 유니크 인덱스를 사용할 수도 있다.

- PK = id (DB auto_increment)

- unique index = article_id(UUID 등)

- Client는 article_id만 식별자로서 노출 및 사용

Clustered Index & Secondary Index

우리는 이미 Clustered Index 와 Secondary Index를 학습했다.

 

PK 접근 → Key=Primary

유니크 인덱스 접근 → key=idx_article_id

별도의 식별자를 사용하면 Secondary Index로 포인터 찾은 후, Clustered Index로 접근하므로, 조회 비용이 증가한다.