[CURSOR PAGING] 커서 페이징처리.

 

🥞  오프셋 기반 페이징에서 -> 커서 방식 페이징으로 변경하기 전에 미리 알아보려 한다.

 

 

🥞🥞 오프셋 기반 페이징의 단점 : 

 

LIMIT / OFFSET 을 이용할 경우 offset이 늘어나는 양에 따라 비효율적인 동작을 하게된다. 

오프셋 이전의 데이터를 모두 조회하고 limit 와 offset에 해당하는 값만 가져오는 방식이기 때문에 

대량의 데이터를 가져오는 페이징에 적합하지 않다.

 

 

 

아래는 여러건의 데이터를 삭제하기 위한 쓰레드 작업에 커서 페이징을 적용하려다가 실패한 케이스이다. 

 

[AWS S3] object 여러 건 삭제 요청 /220811 수정

🧇 커서 값이 일정치 않고 인덱스로서의 기능을 할  수 없었기 때문이다. 

     당시에 인덱스가 정확하지도 않고, DB의 데이터를 실제로 삭제하는 등,  인덱스 커서가 아이디로서의 기능을 제대로 못하는 바람에.. 구현하지 못했음. 

 

 

 

🥠 실패한 내용 요약 

s3 스토리지의 thumbnail  파일을 용량으로 인해 삭제해야 할 일이 있었는데 aws s3 스토리지에 있는 오브젝트의 경로는 DB에 저장되어 있었고, 

 

-->  aws s3 삭제 요청은 최대 1000건만 지원  

--> 스레드를 4개 돌려서 1000개씩 지우자! 

--> 처리해야 할 섬네일 파일의 개수는 1억 6천만? 8천만? 건이었음 --> 페이징처리와 같은 방식의 쿼리를 날려서 셀렉한 천개씩 스레드로 돌리기 때문에,

--> 셀렉트 쿼리가 동작하는 속도가 중요함 / 8천만?건이 넘어가는 시점부터는 셀렉트 쿼리의 속도가 1분 가까이 가기 시작함. 

🥗 이 부분 떄문에 커서 페이징 구현하려고 했었음. 

페이징은 점점 느려질 수 있다. 테이블의 크기가 커지면서 느려질 수도 있고,
API 로직이 복잡해지면서 느려질 수도 있다. 
하지만, 애초에 OFFSET, LIMIT으로 조회하는 방식은 
앞에서 읽었던 행을 다시 읽어야하기 때문에 뒤로 갈수록 느리다. 

그리고 OFFSET, LIMIT은 인덱스 스캔과는 전혀 상관없는 명령어기때문에 인덱스의 이점을 살릴 수도 없다. 
이 때, 개선 가능한 방법이 No-Offset 페이징 혹은 커서 페이징이라고 불리우는 페이징 기법이다.

-->  한달 이후에는 새로운 장비가 들어오기 때문에 그 전에 온라인 스토리지의 용량을 확보해야함 ) 

 

 

 

🥠  커서 기반 페이징.

 

오프셋과 달리 어떤 데이터의 다음에 있는 데이터를 요청한다는 게 포인트. 

 

커서페이징으로 바꾸기에 앞서 단점도 미리 보아야 한다. 

 

출처 : https://bbbicb.tistory.com/40

왜 오프셋 페이징보다 커서 페이징일까?

 

실행에 앞서 사용가능한 경우인지 체크해야한다. 

 

 

현재 바꾸려하는 DB의 컬럼 중, task_id는 sequence 를 사용하는 방식이며, 

 

 

ID를 삭제하는 로직은 존재하지 않는다.  그러므로,

 

 

인덱스로서의 기준이 명확하고, 페이징에서 누락될 위험이 없다. 

 

 

 

 

 현재 쓰는 offset 방식 쿼리 : 

select
            a.task_id as task_id
            , a.src_path as src_path
            , a.tgt_path as tgt_path
            , a.task_status as task_status
            , a.progress as progress
            , a.task_start_dtm as task_start_dtm
            , a.task_end_dtm as task_end_dtm
            , a.assign_ip as agent_ip
            , a.creator_id as creator_id
            , to_char(a.created_dtm, 'YYYY-MM-DD HH24:MI:SS') as created_dtm 
      , b.type_nm as type_nm
      , c.task_rule_nm as task_rule_nm
from tb_task a
      ,tb_task_type b
      , tb_task_rule c
where a.type = b.type
and   
to_date(to_char(a.created_dtm, 'YYYY-MM-DD'),'YYYY-MM-DD') >= '2021-01-01'
and to_date(to_char(a.created_dtm, 'YYYY-MM-DD'), 'YYYY-MM-DD') <= '2025-01-01'      
and b.task_type_id = c.task_type_id
ORDER BY a.created_dtm desc
offset 500
LIMIT 100;

실행 계획은 다음과 같다.  애초에 데이터 양이 적어서 차이가 많이 안나는 경우이다.

 

 

 

커서 페이징으로 바꿀 경우. 

select
            a.task_id as task_id
            , a.src_path as src_path
            , a.tgt_path as tgt_path
            , a.task_status as task_status
            , a.progress as progress
            , a.task_start_dtm as task_start_dtm
            , a.task_end_dtm as task_end_dtm
            , a.assign_ip as agent_ip
            , a.creator_id as creator_id
            , to_char(a.created_dtm, 'YYYY-MM-DD HH24:MI:SS') as created_dtm 
      , b.type_nm as type_nm
      , c.task_rule_nm as task_rule_nm
from tb_task a
      ,tb_task_type b
      , tb_task_rule c
where a.type = b.type
and task_id < 500
and   
to_date(to_char(a.created_dtm, 'YYYY-MM-DD'),'YYYY-MM-DD') >= '2021-01-01'
and to_date(to_char(a.created_dtm, 'YYYY-MM-DD'), 'YYYY-MM-DD') <= '2025-01-01'      
and b.task_type_id = c.task_type_id
ORDER by task_id desc, a.created_dtm desc
LIMIT 100;

 

 

 

 

출처 글에서도 말하지만 처음 1페이지는 성능이 좋지 않다.

 

offset..

 

초기값 1페이지로 보여준다면.  page는 + 1 처리 필요.
    WHERE task_id > (0 * 1(page)) limit 20;

현재 1 번째 페이지에서 다음 페이지로 갈 경우 :
    offset : task_id + (list * page)
    WHERE task_id > offset limit 20;

현재 N 번째 페이지에서 다음 N번째 페이지로 갈경우 :
    offset : task_id + (list * N페이지).
    WHERE task_id > offset  limit 20;

 

 

 

잘못된 점이 있을 수 있습니다. 지적 부탁드립니다.