💡 개요
오늘은 MongoDB의 쓰기 속도가 빠른 이유에 대해 정리해 보자.
🛠️ MongoDB 쓰기 작업
MongoDB가 MySQL보다 빠르게 작업을 수행할 수 있는 이유는 간단하다.
바로 트랜잭션 처리의 엄격성이 MySQL보다 떨어지기 때문이다.
우리가 아는 트랜잭션의 원칙은 ACID를 기반으로 이루어졌다.
- Atomicity (원자성) : 모든 작업이 모두 성공하거나, 모두 실패해야 함
- Consistency (일관성) : 트랜잭션 전 후의 데이터가 항상 유효한 상태여야 함
- Isolation (격리성) : 동시에 실행되는 트랜잭션은 다른 트랜잭션에게 영향을 주어선 안됨
- Durability (지속성) : 트랜잭션 종료 후 결과는 영구적으로 반영되어야 함
하지만 MongoDB는 이러한 전통적인 ACID과 다르게 BASE을 기반으로 한다.
- Basically Available (기본적으로 사용 가능) : 시스템은 항상 응답하며, 내부 데이터에 문제가 있더라도 일단 사용은 가능함
- Soft state (유동적인 상태) : 시스템의 상태는 늘 변할 수 있으며 일관성이 보장되지 않음
- Eventual consistency (최종적 일관성) : 당장은 무결성이 유지되지 않아도, 최종적으로는 무결성이 유지됨 (MongoDB의 복제 특성 때문!)
ACID와 BASE를 비교하면 확실하게 ACID가 데이터의 일관성이나 정합성 유지를 위해 더 엄격하게 관리하는 것을 알 수 있다.
→ 그렇기 때문에 RDB가 NoSQL보다 안전한 것은 명백한 사실!
이러한 이유 때문에 MongoDB가 대용량 데이터를 다루는 데에는 MySQL보다 성능적으로 더 좋다고 할 수 있을 것 같다.
뭐 기술적인 측면을 추가하여 설명하자면, MongoDB는 내부적으로 BSON(Binary JSON) 문서 단위로 데이터를 저장하기 때문에, 복잡한 JOIN 연산 없이 한 번의 쓰기로 전체 데이터를 처리할 수 있다.
뿐만 아니라 document-level locking을 사용해 다중 쓰기 작업 간의 충돌을 줄이고, MongoDB의 저장 엔진은 마치 "작업 내용을 메모장에 먼저 써놓고, 실제로는 나중에 천천히 정리하는 Write-Ahead Logging(쓰기 전 로그) 방식"이라서, 속도는 빠르면서도 데이터 안정성도 챙길 수 있다.
반면 MySQL은 일반적으로 행 단위 또는 테이블 단위 락을 사용하고, 트랜잭션의 일관성을 보장하기 위해 추가적인 동기화 작업이나 rollback log를 유지해야 하기 때문에 상대적으로 쓰기 작업이 느려질 수밖에 없다.
'개발 일기' 카테고리의 다른 글
[개발 일기] 2025.04.26 - Collections.synchronizedXXX() vs Concurrent Collections (1) | 2025.04.26 |
---|---|
[개발 일기] 2025.04.25 - 맥북 쿠버네티스 서비스 접근 (0) | 2025.04.25 |
[개발 일기] 2025.04.23 - 왜 두 번씩? (0) | 2025.04.23 |
[개발 일기] 2025.04.22 - 프로세스 생명 주기 (0) | 2025.04.22 |
[개발 일기] 2025.04.21 - Docker 익명 볼륨 (0) | 2025.04.21 |