GROUP BY 느린 이유? 메모리 지연이 핵심
원제: It's the memory latency, stupid
왜 중요한가
DB 엔진 성능 최적화에서 캐시 지역성(cache locality)이 알고리즘 복잡도보다 실제 처리량에 더 큰 영향을 줄 수 있음을 실증 데이터로 보여준다.
Pivot의 엔지니어 Maor Kern이 2026년 10월 28일 공개한 기술 블로그에서, CPU 사용률 100%에도 데이터베이스 성능이 나쁜 원인이 메모리 지연(memory latency)에 있다고 분석했다. GROUP BY 집계 연산을 사례로, 단순 HashTable 방식이 캐시를 사실상 무용지물로 만드는 구체적 수치와 실험 결과를 제시했다.
CPU가 1나노초에 4~8개 명령어를 처리하는 반면, RAM 접근에는 50~100ns가 걸린다. 즉, 메모리에서 값 하나를 읽어오는 동안 CPU는 이론상 400~800개 명령어를 처리할 수 있다. L1 캐시(~64KB, ~1ns)와 RAM 사이의 이 격차가 '가짜 100%' 문제의 본질이다. Linux 태스크 관점에서 CPU는 바쁘게 보이지만, 실제로는 메모리 응답을 기다리며 멈춰 있다.
Kern은 이를 GROUP BY 집계로 구체화했다. 수백만 개의 고유 그룹 키를 단순 HashMap으로 처리하면, 접근할 때마다 L1·L2·L3 캐시를 모두 빗나가 RAM까지 내려가는 'cold hit'이 연속 발생한다. 그는 자사 쿼리 엔진 Pivot의 최적화 로직을 제거하고 단순 HashMap 방식으로 교체한 뒤, ClickBench의 'hits' 데이터셋(9,900만 행)에서 `SELECT count(*), UserID FROM hits GROUP BY UserID` 쿼리를 실행했다. 고유 UserID는 약 1,700만 개로, HashMap 자체가 RAM을 가득 채울 만큼 커진다.
결론은 'CPU가 더 많은 일을 해서 메모리를 덜 보는 것'이 오히려 빠르다는 역설이다. 캐시 친화적 자료구조나 데이터를 작은 청크로 나눠 처리하는 방식이 단순 HashMap보다 실질 처리량에서 앞선다는 것을 실험으로 보였다.