PostgreSQL의 MVCC는 나쁘다. 다른 DB도 마찬가지다

PostgreSQL의 쓰기 증폭, 테이블 팽창, VACUUM 부담, 32-bit XID wraparound는 실제 문제지만, 이는 MVCC 자체의 결함이라기보다 과거 버전을 테이블에 남기고 나중에 정리하는 설계 선택에서 비롯됨 reader가 writer를 막지 않으려면 어느 DB든 과거 버전을 어딘가에 보관해야 하며, 차이는 과거 버전을 어디에 두고 / 어떻게 찾고 / 누가 언제 치우는지에 있음 Oracle/InnoDB는 undo log, SQL Server는 version store, MongoDB는 cache/history store, CockroachDB 같은 LSM 엔진은 timestamped key와 compaction을 사용해 PostgreSQL의 비용을 없애기보다 writer, reader, cache, tempdb, compactor 쪽으로 이동시킴 특히 오래 열린 snapshot은 모든 설계에서 문제가 되며, PostgreSQL은 garbage가 쌓이고, Oracle은 snapshot too old, InnoDB는 undo 증가, SQL Server는 tempdb 증가, WiredTiger는 cache pressure, LSM은 GC window 초과 같은 서로 다른 형태로 실패함 결국 MVCC의 비용은 보존됨: PostgreSQL은 garbage가 눈에 보이고 VACUUM을 직접 관리해야 하는 대신 reader를 막지 않고, 오래된 snapshot을 기본적으로 취소하지 않으며, 큰 transaction도 거의 즉시 rollback할 수 있는 쪽을 선택함 PostgreSQL MVCC가 비판받는 이유 PostgreSQL의 UPDATE는 기존 row를 수정하지 않고 완전한 새 row version을 heap에 추가함 기존 tuple에는 t_xmax를 기록하고 새 버전과 옛 버전을 모두 디스크에 남김 어떤 버전이 보이는지는 read 시점에 판단하며, 필요 없어진 버전은 나중에 VACUUM이 정리함 MVCC를 구현하는 모든 DB는 네 가지 질문에 답해야 함 과거 버전은 어디에 저장하는가: table 내부인지 별도 구조인지 version chain은 어느 방향인가: old → new인지 new → old인지 index는 무엇을 가리키는가: physical row location인지 logical key인지 누가 언제 cleanup하는가: background process인지 transaction 자체인지...