PostgreSQL storage를 공부하면서 가장 먼저 정리해야 할 감각은 이것이었다.PostgreSQL에서 우리가 row라고 부르는 것은, 내부적으로는 snapshot에 따라 visible하다고 판단된 heap tuple version이다. SQL을 쓸 때는 당연히 row 단위로 생각한다.SELECT *FROM usersWHERE id = 1; 겉으로 보면 users 테이블에서 id = 1인 row 하나를 읽는 작업이다. 그런데 PostgreSQL 내부로 들어가면 흐름이 조금 달라진다. PostgreSQL 인덱스는 row 전체를 저장하지 않는다. 인덱스 leaf에는 인덱스 대상 컬럼 값들과, 그 값을 가진 heap tuple 위치(TID)만 들어 있다. heap에는 하나의 logical row에 대한..

MySQL/InnoDB를 공부하다 보면 처음에는 쿼리, 인덱스, 실행 계획에 시선이 많이 간다.EXPLAIN에서 어떤 index를 타는지, type이 ref인지 range인지, rows 추정치가 얼마나 되는지부터 보게 된다. 그런데 InnoDB 내부 구조를 다시 정리하면서 가장 핵심이 되는 포인트가 조금 달라졌다. InnoDB는 row를 캐시하는 것이 아니라 page를 캐시한다. 이 한 문장을 기준으로 보면 여러 현상이 한 흐름으로 이어진다.왜 index range scan과 random lookup의 체감 성능이 다를 수 있는가왜 큰 배치 쿼리 하나가 평소 잘 돌던 OLTP API latency를 흔들 수 있는가왜 InnoDB가 단순한 LRU가 아니라 young/old sublist를 둬야 했는가왜 c..

이 글은 MVCC를 이론에서 시작해 실습으로 내려오는 순서로 정리한 글이다. 먼저 MVCC 가 왜 필요한지에 대해서 이해하고, MySQL과 PostgreSQL이 MVCC를 구현한 방식에 대해서 간단히 살펴본다. 마지막으로 간단한 SQL 실습을 통해서 MVCC가 동작함을 확인한다.1. MVCC의 목적MVCC(Multi-Version Concurrency Control)는 여러 트랜잭션이 동시에 같은 데이터를 읽고 써도, 읽기 일관성과 동시성을 함께 확보하려는 방식이다.핵심은 간단하다.하나의 row만 두고 락으로만 버티지 않는다.각 트랜잭션이 자기 시점에 맞는 버전을 보게 한다.읽기와 쓰기의 충돌을 줄인다.이 방식이 필요한 이유는 분명하다.읽기 트랜잭션이 쓰기 트랜잭션을 불필요하게 막지 않아야 한다.쓰기 트..

1. 들어가며: "VIEW에 윈도우 함수가 있으면 인덱스가 안 먹힌다?"최근 동료가 특정 기능을 작업하던 중 조회 성능이 급격히 저하되는 문제를 겪었다. 원인은 윈도우 함수가 포함된 VIEW 테이블을 조회할 때 발생한 현상이었으며, 이 조합이 Condition Push-Down을 방해한다는 점을 분석하였다. 평소 뷰를 편리하게 사용해왔으나 이러한 구체적인 성능 제약 사항은 경험해 본 적이 없었다. 이에 해당 지식을 직접 확인하고 이해하기 위해 로컬 환경에서 Docker를 이용해 상황을 재현하고 실험을 진행하였다.2. 이론적 배경: 왜 옵티마이저는 조건을 무시하는가?MySQL 옵티마이저는 뷰를 쿼리할 때 두 가지 실행 전략을 선택한다.Merge: 뷰의 정의와 외부 쿼리를 합쳐 하나의 최적화된 쿼리로 실행한..