느린 쿼리를 마주한 백엔드 엔지니어의 첫 번째 반사 신경은 보통 인덱스 추가입니다. 하지만, 인덱스를 걸었는데도 쿼리 응답 속도가 꿈쩍도 하지 않거나, 되려 쓰기 성능(TPS)만 곤두박질치는 기이한 현상을 마주할 때가 있습니다. 이 글은 실제 이커머스 서비스의 트래픽을 처리하는 과정에서 발견한 잘못 설계된 복합 인덱스 한 줄에서 출발합니다.인덱스가 B+Tree가 물리적으로 데이터를 정렬하는 방식(Lexicographical Order), PostgreSQL의 힙(Heap) 테이블 한계와 HOT(Heap-Only Tuple) 업데이트 파괴로 이어지는 나비효과까지, RDBMS 엔진의 밑바닥을 파헤쳐 보겠습니다.겉보기엔 멀쩡한 인덱스의 함정문제의 시작은 이커머스 도메인의 핵심인 OrderItem (주문 상품)..

MySQL vs PostgreSQL 1편에서는 MySQL의 Index-Organized Table(IOT)과 PostgreSQL의 Heap Table 구조를 비교하며, 데이터를 저장하고 읽는(Read) 방식의 근본적인 차이를 알아보았습니다. PostgreSQL은 무거운 데이터를 억지로 정렬하지 않고 힙(Heap) 공간에 마구잡이로 던져 넣은 뒤, 인덱스에서 물리적 주소(TID)로 다이렉트로 꽂아버리는 방식을 택했습니다. 읽기(Read) 관점에서는 트리를 두 번 타야 하는 MySQL보다 구조적으로 훨씬 명쾌하고 빨라 보였죠. 하지만 데이터베이스의 진짜 숙명은 조회가 아니라 끊임없는 '변경(UPDATE)'에 있습니다. 오늘은 데이터가 변경되는 순간, 평화롭던 PostgreSQL의 힙 구조에 어떤 거대한 나비..

지난 글에서는 B+Tree의 원리를 통해 데이터베이스 인덱스가 디스크 I/O를 어떻게 획기적으로 줄여내는지 깊이 파헤쳐 보았습니다. 전 세계에서 가장 널리 쓰이는 RDBMS인 MySQL(InnoDB)을 기준으로 설명했었는데, 제가 실무에서 주로 다루는 PostgreSQL에 대한 설명이 부족해서 개인적으로 못내 아쉬웠습니다. 사실 MySQL InnoDB에 존재하는 클러스터링 인덱스(PK로 만들어진 B+Tree의 리프 노드에 실제 데이터가 예쁘게 정렬되어 저장되는 구조)는 PostgreSQL에는 존재하지 않습니다. 오늘은 PostgreSQL의 구루 히로노부 스즈키(Hironobu Suzuki)의 The Internals of PostgreSQL를 길잡이 삼아, 두 DB의 근본적인 저장 구조 차이와 읽기(Re..