PostgreSQL

"The world's most advanced open source relational database."

— 세계에서 가장 고도로 진보된 오픈소스 관계형 데이터베이스라는, 학계와 업계가 자부하는 공식 타이틀.

MySQL이 지겹고 오라클 살 돈은 없는 스마트한 현대 기업들이 선택하는 데이터베이스의 궁극적 도피처이자, NoSQL 기능까지 먹어 치우는 욕심쟁이 포식자. 성능도 좋고 확장성도 완벽한데, 주기적으로 VACUUM을 안 돌려주면 디스크 용량이 무한 증식하다가 서버가 사정없이 뻗어버리는 무시무시한 부작용을 숨기고 있다.

1. 개요

PostgreSQL은 UC 버클리 대학에서 마이클 스톤브레이커(Michael Stonebraker) 교수의 프로젝트로 출발한, 객체-관계형 데이터베이스(ORDBMS) 표준을 자랑하는 오픈소스 DBMS이다. 단순히 관계형 모델에만 머물지 않고 복잡한 데이터 타입, 풍부한 인덱스 지원, 강력한 동시성 제어로 유명하다.

특히 기가 막힌 JSON 지원 기능(JSONB) 덕분에 'RDBMS의 탈을 쓴 NoSQL'로도 기능하며, 위치 정보를 다루는 GIS(GIS 공간 데이터) 영역에서는 사실상 대체 불가능한 표준(PostGIS) 지위를 점하고 있다. 대규모 트래픽과 철저한 표준 스펙 준수를 수호하는 테크 대기업(Netflix, 카카오 등)들이 MySQL을 버리고 대거 이주하는 종착지이기도 하다.(...)

2. MVCC(다중 버전 동시성 제어)와 VACUUM의 늪

2.1. MVCC (Multi-Version Concurrency Control)의 축복

PostgreSQL은 데이터를 수정할 때 기존 레코드를 직접 덮어쓰지 않고, 새로운 버전의 레코드를 생성하여 나란히 보관하는 MVCC 기법을 극단적으로 사용한다. 덕분에 어떤 사용자가 데이터를 읽고(Read) 있는 동안에도, 다른 사용자가 데이터를 수정(Write)하는 행위가 전혀 방해받지 않아 미친 듯한 고도의 트래픽 처리 성능을 자랑한다.

2.2. 쓰레기 청소부: VACUUM (바큠) 지옥

하지만 이 방식의 심각한 대가는 바로 데드 튜플(Dead Tuple)이라 불리는 쓰레기 데이터의 누적이다. 수정되기 전의 옛날 레코드는 데이터베이스 파일 내에 '유령'처럼 그대로 남아 디스크 공간을 갉아먹는다.

이 쓰레기를 주기적으로 정리해서 공간을 환원해 주는 작업이 바로 VACUUM(바큠)이다. PostgreSQL은 백그라운드에서 이를 자동으로 해주는 Auto-Vacuum 기능을 갖추고 있으나, 대량의 데이터 삽입/수정이 연속적으로 일어나는 피크 타임에 바큠이 눈치 없이 돌아가기 시작하면 디스크 I/O가 100%를 찍으며 전사 서버가 돌발사태로 돌입한다.1

이 때문에 고급 PostgreSQL DBA들의 메인 업무는 '언제 바큠을 어떻게 우아하게 작동시켜 시스템 성능 저하를 방지할 것인가'의 밀당 게임이 된다.(...)

3. RDBMS의 최종 진화: JSONB와 풍부한 인덱스 생태계

3.1. JSONB: MongoDB의 뚝배기를 깨는 RDBMS

PostgreSQL의 전성기는 단연 JSON을 바이너리 포맷으로 압축해 저장하는 JSONB 타입의 지원이다. 일반 텍스트 JSON 저장 방식과 달리 내부 데이터를 바이너리로 들고 있기 때문에, JSON 객체 내의 특정 키값에 직접 인덱스(GIN 인덱스)를 박아 수백 배 빠른 속도로 복잡한 비정형 데이터를 조회할 수 있다.

이로 인해 '스키마가 유연해야 하니 MongoDB를 쓰자!'던 주장이 무색하게, '그냥 정합성 완벽한 PostgreSQL에 JSONB 컬럼 하나 뚫어서 해결하자!'는 아키텍처 설계가 현대 백엔드 판도를 지배하게 되었다.2

3.2. 화려한 인덱스 라인업

일반적인 B-Tree 인덱스뿐만 아니라, 텍스트 전체 검색용 GIN, 다차원 공간 검색용 GIST, 정렬된 대용량 데이터 전용 BRIN 등 화려한 인덱스 라인업을 갖추고 있어 데이터 분석가들과 성능 오타쿠 엔지니어들에게 엄청난 지지를 얻고 있다.

4. 코끼리 마스코트와 VACUUM 공포

4.1. 코끼리 슬로닉 (Slonik)

PostgreSQL의 귀여운 코끼리 마스코트로, 러시아어로 코끼리를 뜻하는 'Slonik'에서 따왔다. 코끼리의 엄청난 기억력처럼 데이터를 절대 잊지 않고 보관하겠다는 멋진 의미이지만, 실무 개발자들에게는 '기억력이 너무 좋아서 데드 튜플(쓰레기)조차 지우지 않고 바큠할 때까지 움켜쥐고 있는 뚱뚱한 게으름뱅이'라며 가끔 원망 어린 놀림감이 되기도 한다.

5. 여담

  • 이름의 유래와 발음: 원래 UC 버클리에서 만든 데이터베이스 이름이 'Ingres'였고, 그 후속작이라 'Post-Ingres'라는 의미에서 'Postgres'가 되었다. 이후 SQL 표준을 붙여서 'PostgreSQL'로 개명되었으나, 발음이 '포스트그레스큐엘'로 너무나 길어 현업에서는 그냥 편하게 '포스트그레스(Postgres)'라고 부르는 경우가 99%이다.
  • 자유로운 라이선스의 진수: 무자비한 오라클 소유의 MySQL과 달리, PostgreSQL은 완벽한 중립적인 글로벌 커뮤니티가 소유하며 지극히 관대한 라이선스를 유지한다. 이 덕분에 전 세계의 클라우드 3사(AWS, GCP, Azure)가 PostgreSQL을 제멋대로 개조해서 자기들만의 상용 클라우드 DB 서비스(AWS Aurora 등)의 핵심 엔진으로 우려먹는 비즈니스를 영위하고 있다.
  • 미친 수준의 확장성: 사용자가 원한다면 데이터베이스 내부에 파이썬이나 자바스크립트 코드를 직접 박아 넣고 실행하는 기괴한 프로시저(PL/Python, PL/v8)를 개발해 돌릴 수 있다. 관계형 데이터베이스 안에서 파이썬 머신러닝 모델이 직접 도는 기적 같은 일이 실제로 벌어진다.

6. 관련 문서

각주

  1. 바큠 과정에서 락(Lock) 등급 관리를 잘못하면 특정 테이블 전체에 쓰기 락이 걸려 트랜잭션이 줄줄이 타임아웃을 뿜어내는 참극이 터진다.

  2. 실제로 NoSQL의 강자였던 도큐먼트 디비들의 입지를 PostgreSQL의 JSONB가 극적으로 축소시키는 결과를 낳았다.