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

스타트업에서 백엔드 엔지니어 실무를 하다보면 웹, 인프라/클라우드, 데이터베이스까지 폭 넓게 지식과 실무 경험을 쌓을 수 있다는 장점이 있습니다. 하지만 이렇게 일하다보면 "이건 왜 이렇게 돌아가는거지?" 하고 의문이 들 때가 있는데요, 오늘은 데이터베이스 그 중에서 인덱스가 왜 빠른지에 대해서 조금 깊이 알아보고자 합니다.그 유명한 B+Tree 구조에 대해서데이터베이스 인덱스에 대해서 이야기할때 가장 기본적이고 추상적인 설명은 이름 그대로 "데이터를 빠르게 찾기 위한 색인을 넣는 과정" 입니다. 하지만 실무를 어느정도 해본, 혹은 전공서적을 공부중인 학생이라면 이정도 설명으로는 충분하지 않습니다. 이 글의 조금더 깊이 알아본다는 주제를 충족하기 위해서는 우리는 대표적인 RDBMS 의 인덱스인 B+Tre..