면접에서 이런 질문을 받은 적이 있다.배치 chunk size는 어떻게 잡으세요? 예전에는 꽤 단순하게 답했다.로컬에 비슷한 환경을 만들고, 부하 테스트를 돌려보면서 처리량과 latency가 괜찮은 값을 잡는다고. 틀린 답은 아니라고 생각한다.그런데 MySQL을 다시 공부하면서 이 답이 조금 얕게 느껴졌다. 계기가 된 부분은 InnoDB buffer pool의 LRU 관리 방식이었다. InnoDB는 strict LRU를 그대로 쓰지 않고, 새로 읽은 page를 LRU list의 midpoint 근처에 넣는다. 대량 scan이 buffer pool을 한 번에 오염시키지 않도록 막기 위한 장치다. MySQL 공식 문서에서는 이 동작을 buffer pool을 scan resistant하게 만들기 위한 전략으..

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..