조용한 개발 노트

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

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