페이지네이션이란? OLTP 환경에서 사용자에게 반환되는 데이터들은 대부분 특정 기준으로 정렬된 일부 데이터이다. 예를 들면 웹개발의 가장 흔한 예시인 게시판이 그렇다. 게시판은 일반적으로 한 페이지에 약 20개의 게시글들을 최신순으로 노출시키고, 사용자가 다음 페이지로 넘어가게 되면 21 ~ 40번째 데이터가 그제서야 조회되는 방식으로 구현된다. 이 상황에서 서버는 사용자에게 전체 게시글 데이터를 전달하는 것이 아닌, 사용자가 위치한 페이지에 해당하는 데이터만을 반환하도록 API 설계가 이루어지는데 이를 페이지네이션 방법론이라고 부른다. 페이지네이션 종류 일반적으로 많이 사용되는 페이지네이션 기법에는 Offset 기반 페이지네이션과 Cursor(Keyset) 기반 페이지네이션이 존재한다. Offset 기..

개인적인 경험 상, 취업을 준비하는 개발자 지망생 분들이나 혹은 신입 내지 주니어 개발자 분들 사이에는 서브 쿼리를 사용하면 데이터의 검색 성능이 드라마틱하게 나빠질 것이라는 통념이 존재하는 것 같다. 나 또한 그렇게 생각해왔었는데 이게 정말 맞는지, 아니면 오해인 것인지 확인해보려한다. 서브 쿼리란? 서브 쿼리란 메인 쿼리가 존재하는 상황에서 메인 쿼리 내에 포함된 또 다른 쿼리를 의미한다. 어떤 절에 포함된 쿼리인지에 따라 스칼라 서브 쿼리(SELECT 문), 인라인 뷰(FROM 절), 서브 쿼리(WHERE 절, 그냥 서브 쿼리라고 하는 듯...) 등의 명칭으로 불린다. 아래는 서브 쿼리의 예시이다. -- 스칼라 서브 쿼리 SELECT p.id AS id, (SELECT email FROM accou..

현재 DB 스터디의 일환으로 '친절한 SQL 튜닝'을 한번 더 읽고 있다. 이번 파트는 소트 머지 조인 + 해시 조인 인데, 개인적으로 해당 서적을 이미 1회독한 상황이라 두 조인이 대략적으로 어떻게 작동하고, 어떤 상황에서 활용되는지는 이해하고 있다. 다만 1회독 시 잘 몰라서 그냥 넘어갔던 오라클의 PGA와 SGA의 개념이 있는데, 이번 기회에 이를 공부하고 넘어가면 좋겠다 싶어 공부한 내용들을 기록해두기 위해 이 글을 작성한다. 이 글에서는 책에서 간단하게 다뤄진 데이터 조회 시 SGA와 PGA 접근의 속도 차이에 중점을 두고 다뤄보려한다. 각 메모리 공간에 대한 소개 SGA SGA란 System Global Area의 약자로, DB 내 하나만 존재하면서 모든 세션이 공유하는 메모리 공간이다. SG..

다양한 데이터의 접근 형태에 일일이 대응하여 인덱스를 많이 만들 수 있는 환경이라면 인덱스 생성에 있어 고민의 여지가 적겠지만, 아쉽게도 인덱스가 많아지면 많아질수록 그에 따른 사이드 이펙트(DML 성능 저하, 저장 공간 차지)가 존재한다. 따라서 적은 수의 인덱스를 유지하는 동시에 다양한 데이터 접근 형태에 대해 인덱스 스캔을 지원하는 것은 중요하다. 이를 위해서는 복합 인덱스 기반으로 하나의 인덱스가 여러 상황을 커버할 수 있도록 테이블 설계가 이루어져야 한다. 해당 글에서는 이를 돕기 위해 복합 인덱스가 어떤 방식으로 작동하는지 알아보고, 복합 인덱스가 작동하는 경우의 수에 대해 다뤄보려고 한다. 이 글은 Mysql 기준으로 작성되었다. 복합 인덱스 작동 방식 복합 인덱스는 둘 이상의 칼럼을 통해 ..

일반적으로 Index Scan이라고 불리우는 기법들(Index Range Scan, Index Unique Scan 등)은 Single Block IO를 활용한다. (해당 내용에 대한 이해도가 부족하다면 이전 글 참조 -> 테이블 스캔 방식에 따른 DB Block IO 전략) 뒤에 설명하겠지만, 읽어야 할 블록이 버퍼에 존재한다고 해도 해당 블록에 접근하기 위한 메모리 상의 포인터를 획득하는 과정이 필요하다. 따라서 읽어야 할 인덱스 레코드가 많은 경우엔, 그 수 만큼 논리적 IO가 발생한다고 볼 수 있고 매번 포인터를 새롭게 획득한다고 생각할 수 있다. 만약 인덱스 리프 노드에서 읽어낸 테이블 ROWID가 대부분 동일한 블록을 가리키고 있다면? 그럼에도 불구하고 인덱스 레코드 수 만큼 포인터 획득 과정..

실제로 DB를 다루게 되는 상황에서 빠질 수 없는 것이 바로 인덱스이다. 인덱스를 통하면 특정 조건에서 데이터의 조회 성능이 비약적으로 증가한다는 것은 누구나 알고 있는 사실이다. 그러면서도, 인덱스를 남발하면 안된다는 것 또한 다들 알고있다. 이 때 등장하는 논리가 바로 인덱스가 차지하는 공간적 비용과 데이터 삽입 시 추가적으로 발생하는 시간적 비용에 대한 비중을 무시할 수 없다는 것이다. 그런데 막상 이렇게 겁만 주고 실제로 그 정도가 어느 정도인지 알려주는 자료는 많이 없어서 이에 대해 실제로 확인해보려고 한다. 테스트 환경은 Mysql이고, 아무런 릴레이션이 존재하지 않는 독립된 테이블에서 테스트를 진행하였다. -- 테이블 생성 create table item ( id BIGINT NOT NULL..