조용한 개발 노트

MongoDB를 쓰다 보면 인덱스에 대해 이런 인상을 받기 쉽다.“분명 인덱스를 타는데, 생각보다 느리다.”이 느낌은 착각이 아니다. MongoDB 인덱스는 같은 B-Tree 구조를 쓰더라도 인덱스가 끝나는 지점이 다르다.이 글에서는 MongoDB 공식 문서를 기준으로, 인덱스 사용 여부와 Document 접근 여부가 왜 성능을 갈라놓는지 구조적으로 정리한다.MongoDB 인덱스도 B-Tree다먼저 분명히 짚고 가자.MongoDB의 기본 인덱스 역시 B-Tree 계열 구조를 사용한다.따라서 정렬, 범위 조회, 탐색 비용 같은 기본 성질은 관계형 데이터베이스와 동일하다.차이는 인덱스가 무엇을 가리키고, 쿼리가 어디까지로 끝나는가에서 시작된다.MongoDB 쿼리의 실제 실행 경로MongoDB에서 쿼리는 항상..

성능 이슈가 발생하면 가장 먼저 떠오르는 접근은 보통 이렇다.“느린 쿼리가 있다 → 쿼리를 고치자.”물론 쿼리가 원인인 경우도 있다. 하지만 InnoDB 환경에서 반복적으로 관측되는 성능 문제의 상당수는, SQL 문법이나 실행 계획 이전에 메모리와 IO 구조에서 발생한다.InnoDB에서 쿼리는 어디를 지나갈까InnoDB에서 쿼리가 실행될 때, 실제로 가장 빈번하게 오가는 경로는 다음과 같다.인덱스 페이지 접근데이터 페이지 접근Buffer Pool 히트 또는 미스필요 시 디스크 IO즉, 쿼리 성능은 SQL 문장 자체보다 페이지가 메모리에 있는지, 디스크에 있는지에 훨씬 민감하다.Buffer Pool은 InnoDB 성능의 중심이다InnoDB의 Buffer Pool은 디스크에 있는 데이터와 인덱스 페이지를 메..

6편에서 Exactly-once가 성립하는 조건과 한계를 살펴봤다. 이제 Kafka의 또 다른 오해로 넘어가 보자.“Kafka는 디스크에 쓰는데, 왜 이렇게 빠르지?”이 질문에 대한 답은 Kafka의 스토리지 구조가 아니라 운영체제와 IO를 바라보는 관점에 있다.Kafka는 디스크를 느리다고 가정하지 않는다많은 시스템은 디스크를 “느리고 비싼 자원”으로 취급한다. 그래서 캐시-락-복잡한 메모리 구조를 앞에 둔다.Kafka는 반대로 생각한다.디스크는 순차 쓰기라면 충분히 빠르다.이 전제가 Kafka의 모든 스토리지 설계를 결정한다.Append-only Log의 힘Kafka의 Partition은 append-only log다.항상 파일의 끝에만 쓴다중간 수정이 없다삭제는 즉시 하지 않는다이 구조 덕분에 랜덤..