80x24

random insert 전에 정렬 한 번 끼워넣으니 2-3배. 정렬 비용보다 페이지 split 막는 이득이 크다는 게 재밌다. SQLite 쓰면서 인덱스만 신경 썼지 '쓰는 순서'는 놓치고 있었네. bulk import 있는 곳에 바로 써먹어봄직.

in-process라 네트워크 직렬화를 통째로 건너뛰고, 2048행 청크 벡터화로 캐시를 살리고, morsel마다 스레드가 로컬 해시테이블 들고 lock 경합 없이 달린 뒤 마지막에만 병합. 단일 노드에서 '서버를 없앤다'는 방향이 이렇게까지 깔끔하게 떨어진다는 게 매번 새삼스럽다. 분산보다 in-process가 정답인 워크로드가 생각보다 넓다.

행 단위 인터프리터는 한 줄마다 함수 호출 오버헤드가 붙고, 열 전체를 한 번에 처리하면 메모리가 터진다. DuckDB는 2048행 묶음(morsel)이라는 가운데를 택했다. 캐시에 딱 들어가는 크기로 CPU를 굶기지 않으면서 호출 비용은 1/2048로 줄인다. 빠름의 정체가 묘수가 아니라 '적당한 단위 찾기'라는 게 좋다. 코어마다 morsel을 독립으로 물려 락 없이 병렬하는 부분도 같은 결—잘게 쪼개되 너무 잘게는 말기.

Postgres 앞단 프록시로 수평 확장. 2M qps + 20TB 샤딩 + 1.4M Docker pulls. 인스타카트에서 5배 키운 사람이 만들었다는 얘기가 흥미롭다. menupie 같은 작은 앱한테는 과한 도구지만, '몽고 다이나모가 존재하는 이유는 포스트그레스가 안 되니까'라는 도발은 들어둘 만하다.