조용한 개발 노트

MongoDB를 두고 이런 평가를 자주 본다.“쓰기에는 강한데, 설계가 어렵다.” “확장은 쉬운데, 운영은 복잡하다.”이 평가는 절반만 맞다.MongoDB의 복잡함은 구현이 어설퍼서가 아니라, 처음부터 풀고자 한 문제가 달랐기 때문이다.이 마지막 글에서는 MongoDB 전반을 관통하는 설계 선택의 방향을 정리한다.MongoDB의 출발점은 “관계”가 아니었다MongoDB는 관계형 모델의 연장선에서 출발하지 않았다.대신, 다음 질문을 출발점으로 삼았다.“이 요청은 어떤 데이터를 항상 함께 사용하나?”이 질문은 Document 모델, Embedded 구조, Join 회피로 이어졌다.결과적으로 MongoDB는 관계를 재구성하는 DB가 아니라, 요청 단위 데이터를 빠르게 다루는 DB가 되었다.일관성보다 “접근 경..

MongoDB를 이야기할 때 빠지지 않고 등장하는 표현이 있다.“수평 확장에 강하다.”하지만 이 표현은 MongoDB의 설계를 절반만 설명한다.MongoDB는 “필요하면 Scale-out 할 수 있는 DB”가 아니라, 처음부터 Scale-out을 전제로 설계된 DB다.이 글에서는 MongoDB 공식 문서를 기준으로, MongoDB가 왜 Sharding을 선택적 기능이 아니라 설계의 출발점으로 삼았는지를 정리한다.Scale-up의 한계전통적인 데이터베이스 확장은 다음 경로를 따른다.CPU를 더 좋은 것으로 교체메모리를 늘림스토리지를 확장이 방식은 단순하고 효과적이지만, 명확한 한계를 가진다.비용이 선형적으로 증가하지 않는다하드웨어 상한이 존재한다단일 장애 지점이 남는다MongoDB는 이 한계를 구조적으로 ..

MongoDB를 분산 환경에서 쓴다는 말은, 대부분 Replica Set을 사용한다는 뜻이다.하지만 Replica Set에 대해 많은 오해가 함께 따라온다.“복제가 있으니 데이터는 안전하겠지.” “Primary만 바뀌면 자동으로 다 해결되겠지.”이 글에서는 MongoDB 공식 문서를 기준으로, Replica Set이 정확히 무엇을 보장하고, 어디까지는 보장하지 않는지를 경계 중심으로 정리한다.Replica Set의 기본 구조Replica Set은 하나의 Primary와 하나 이상의 Secondary로 구성된다.모든 쓰기는 Primary에서 수행된다Secondary는 Primary의 변경을 복제한다Primary 장애 시 자동 선출(Election)이 일어난다이 구조의 목적은 가용성과 내구성을 높이는 것이다..

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

MongoDB를 쓰다 보면 다른 데이터베이스에서는 거의 보지 못한 개념을 마주한다.Read Concern, Write Concern.이 둘은 단순한 옵션이 아니다. MongoDB가 정합성과 내구성의 판단을 시스템이 아닌 애플리케이션과 공유하기로 한 설계 선택을 가장 노골적으로 드러내는 인터페이스다.MongoDB는 “기본값”을 단순 상수로 두지 않는다많은 데이터베이스는 기본 Write Concern을 하나의 고정값으로 둔다.MongoDB는 그렇지 않다.MongoDB는 전역 기본값을 명시하지 않은 경우, Replica Set의 토폴로지를 보고 기본 Write Concern을 계산한다.이를 MongoDB 공식 문서에서는 Implicit Default Write Concern(IDWC)이라고 부른다.암시적 기본..

MongoDB를 오래 써본 사람일수록 이런 질문을 던진다.“왜 MongoDB는 처음부터 트랜잭션을 제공하지 않았을까?”이 질문에는 “기술력이 부족해서”라는 답이 붙기 쉽다. 하지만 실제 이유는 정반대다.MongoDB는 트랜잭션이 없는 구조를 전제로 최적화된 데이터베이스였고, 그 전제를 깨는 순간 전체 설계가 달라지기 때문이다.MongoDB가 처음부터 보장한 원자성MongoDB는 초기부터 다음 원자성을 강하게 보장해왔다.단일 Document 단위 원자성하나의 Document에 대한 쓰기는 항상 중간 상태 없이 적용되거나, 아예 적용되지 않는다.이 보장은 MongoDB 데이터 모델의 핵심 전제다.이 보장만으로 충분했던 이유MongoDB가 타깃으로 삼은 초기 워크로드는 다음과 같은 특성을 가졌다.요청 단위 데..

MongoDB의 성능 특성을 이야기할 때, 빠지지 않고 등장하는 이름이 있다.WiredTiger.WiredTiger는 MongoDB의 기본 스토리지 엔진으로, MongoDB의 읽기·쓰기 성능과 동시성 특성을 사실상 결정하는 핵심 구성 요소다.이 글에서는 WiredTiger 공식 문서를 기준으로, WiredTiger가 왜 Copy-on-Write(CoW) 방식을 선택했는지, 그리고 이 선택이 어떤 성질을 만들어냈는지를 정리한다.스토리지 엔진이 해결해야 하는 질문스토리지 엔진의 본질적인 질문은 단순하다.“읽기와 쓰기를 어떻게 격리할 것인가?”동시에 다음 요구사항을 만족해야 한다.읽기는 빠를 것쓰기는 동시에 많이 처리할 수 있을 것장애 시 복구 가능할 것WiredTiger는 이 문제를 페이지를 직접 수정하지 ..

MongoDB를 운영해 본 팀에서 자주 나오는 말이 있다.“쓰기 트래픽이 늘어도 생각보다 잘 버틴다.”이 체감의 핵심에는 MongoDB의 동시성 제어 모델이 있다. 정확히 말하면, MongoDB는 “락이 없다”기보다는 락의 범위를 극도로 좁힌다.동시성 문제의 본질동시성 문제는 결국 이 질문으로 수렴한다.“누가, 어디까지 동시에 바꿀 수 있는가?”관계형 데이터베이스에서는 이 질문에 대한 답이 비교적 넓다.행 단위 락범위 락인덱스 간 간접 충돌이 구조에서는 의도하지 않게 넓은 영역이 잠길 수 있다.MongoDB의 선택: Document 단위MongoDB는 동시성 제어의 기준 단위를 Document로 한정한다.즉, 하나의 Document에 대한 변경은 해당 Document 안에서만 조율된다.다른 Documen..

MongoDB를 써본 개발자들이 공통으로 느끼는 인상이 있다.“대량 쓰기나 잦은 업데이트에서도 생각보다 잘 버틴다.”이 체감은 우연이 아니다. MongoDB의 Document 모델은 쓰기 경로를 단순화하는 방향으로 설계되었다.이 글에서는 MongoDB 공식 문서를 기준으로, Document 모델이 왜 쓰기에 강한지, 그 내부 구조적 이유를 정리한다.쓰기 성능은 ‘몇 번 만지느냐’의 문제다데이터베이스에서 쓰기 비용은 대체로 다음 질문으로 환원된다.몇 개의 레코드를 수정하는가?몇 개의 구조를 동시에 갱신하는가?얼마나 넓은 범위를 잠그는가?MongoDB는 이 질문들에 대해 가능한 한 단순한 답을 택한다.“하나의 문서만 수정한다.”Document 단위 원자성이 주는 이점MongoDB에서 쓰기의 기본 단위는 Do..

MongoDB를 설명할 때 흔히 이렇게 말한다.“관계형 데이터베이스가 아니다.”하지만 이 설명은 MongoDB를 이해하는 데 거의 도움이 되지 않는다. 중요한 질문은 이것이다.“MongoDB는 무엇을 포기했고, 무엇을 얻으려 했을까?”이 글에서는 MongoDB 공식 문서를 기준으로, MongoDB가 왜 관계형 모델을 버리고 Document 모델을 선택했는지를 내부 구조 관점에서 정리한다.관계형 모델이 전제로 하는 것관계형 데이터베이스는 다음 가정을 전제로 설계되었다.데이터는 정규화된다중복은 피해야 한다Join으로 관계를 복원한다이 모델은 데이터 정합성과 무결성을 유지하는 데 매우 강력하다.하지만 이 강점은 특정 환경에서 비용으로 바뀐다.Join은 언제 비용이 될까Join은 논리적으로 우아하지만, 실행 관..