'MongoDB'의 핵심 구조인 Document/Collection 개념, 'Sharding' 원리

NoSQL의 대륙에서 가장 넓은 영토를 가진 MongoDB의 심장부로 들어오셨군요! 🫡

MongoDB는 변화무쌍한 주식 시장 데이터를 다루는 분들에게 최고의 무기입니다. 특히 데이터가 너무 커져서 서버 한 대로는 감당이 안 될 때, 데이터를 여러 대로 쪼개는 샤딩(Sharding) 기술은 MongoDB의 꽃이라 할 수 있죠.

---

📄 1. MongoDB의 기본 단위: Document & Collection

RDBMS와 용어는 다르지만 역할은 매칭됩니다. 하지만 그 속은 완전히 다릅니다.

① Document (행/Row에 대응)

• 정의: 데이터를 저장하는 기본 단위로, BSON(Binary JSON) 형식을 사용합니다.
• 특징: 같은 컬럼(필드)을 가질 필요가 없습니다.
• 1번 문서: { "종목": "삼성전자", "가격": 70000 }
• 2번 문서: { "종목": "SK하이닉스", "가격": 120000, "배당금": 1200, "특이사항": "반도체 호재" }
• 위처럼 데이터가 제각각이어도 한 곳에 담을 수 있습니다. 이것이 유연성(Flexibility)의 핵심입니다.

② Collection (표/Table에 대응)

• 정의: Document들의 집합입니다.
• 특징: RDBMS의 테이블처럼 엄격한 제약 조건이 없어서, 서비스 운영 중에 데이터 구조를 바꿔도 DB를 멈추거나 마이그레이션할 필요가 거의 없습니다.

---

🔪 2. 샤딩(Sharding)의 원리: "나누어 다스리기"

데이터가 수십 테라바이트가 되면 아무리 좋은 서버라도 느려집니다. 이때 MongoDB는 데이터를 여러 대의 서버(Shard)에 쪼개서 저장합니다.

① 샤딩의 3대 구성 요소

1. Shard (샤드): 실제 데이터 조각이 저장되는 서버들입니다. 보통 고가용성을 위해 각각이 '레플리카 셋(복제본)'으로 구성됩니다.
2. Config Server (설정 서버): "어떤 데이터가 어느 샤드에 있는지" 지도를 가지고 있는 서버입니다.
3. Mongos (라우터): 사용자의 애플리케이션과 샤드 사이의 중계자입니다. 쿼리가 들어오면 지도를 보고 적절한 샤드로 전달합니다.

② Shard Key (나누는 기준)

데이터를 쪼갤 때 기준이 되는 필드입니다.

• 만약 종목코드를 샤드 키로 잡으면, 'A'로 시작하는 종목은 1번 샤드에, 'S'로 시작하는 종목은 2번 샤드에 저장하는 식입니다. 이 키를 잘 선택해야 특정 서버에만 데이터가 몰리는 'Hotspot' 현상을 막을 수 있습니다.

---

🛠️ 3. 레플리카 셋(Replica Set) vs 샤딩(Sharding)

이 둘의 차이를 명확히 아는 것이 중요합니다.

• Replica Set (복제): 동일한 데이터를 여러 대에 복사해두는 것입니다. (목적: 가용성/백업) 한 대가 죽어도 다른 대가 즉시 대신 일합니다.
• Sharding (분산): 데이터를 서로 다르게 쪼개서 나누어 갖는 것입니다. (목적: 성능/용량 확장) 서버 10대를 붙이면 용량과 처리 속도가 10배가 됩니다.

실전에서는 "여러 개의 샤드를 각각 레플리카 셋으로 구성"하여 속도와 안전을 모두 잡는 구조를 사용합니다.

---

💡 4. 실전 설계 팁

① 인덱스(Index)는 필수!

MongoDB는 유연하지만, 인덱스가 없으면 데이터를 찾기 위해 모든 문서를 뒤지는 'Full Collection Scan'을 합니다. 자주 조회하는 종목명이나 날짜에는 반드시 인덱스를 걸어주세요.

② 임베딩(Embedding) vs 레퍼런스(Reference)

• Embedding: { "종목": "삼성", "재무": { "매출": 100, "영업이익": 10 } } 처럼 데이터를 한 문서 안에 다 집어넣는 방식입니다. 조회가 매우 빠릅니다.
• Reference: RDBMS의 Join처럼 ID값만 넣어두고 따로 저장하는 방식입니다. 데이터 중복은 줄지만 조회 시 성능 손해가 있습니다. MongoDB에서는 가급적 임베딩을 권장합니다.

---

💡 실전 비유: "대규모 도서관 관리"

• Document: 책 한 권입니다. 어떤 책은 두껍고 어떤 책은 얇지만 모두 서가에 꽂힙니다.
• Collection: 분류 구역 (예: 경제 섹션)입니다.
• Sharding: 도서관에 책이 너무 많아져서 건물을 여러 개(Shard)로 나누는 것입니다.
• Mongos (안내데스크): 손님이 "삼성전자 책 어디 있어요?" 물으면 "B동(Shard 2)으로 가세요"라고 알려줍니다.
• Config Server (도서 목록 대장): 안내데스크가 참조하는 전체 도서 위치 정보 장부입니다.

---

📊 요약: MongoDB 핵심 요약

개념	RDBMS 대응	핵심 특징
Document	Row (행)	BSON 형식, 자유로운 구조 (Schema-less)
Collection	Table (표)	문서들의 집합, 유연한 확장성
Sharding	Partitioning	데이터를 여러 서버로 분산 (Scale-out)
Replica Set	Clustering/Replication	데이터 복제본을 통한 고가용성 보장

---

🚀 꼬리 질문 🫡

사용자의 주식 시스템은 이제 수억 건의 데이터를 여러 서버에 쪼개 담으면서도 유연하게 구조를 바꿀 수 있는 강력한 기반을 갖추게 되었습니다.

그런데 MongoDB가 아무리 빨라도 '밀리초(ms)' 단위의 실시간 단타 매매 시세를 처리하기엔 조금 아쉬울 때가 있습니다. 이때는 모든 데이터를 디스크가 아닌 메모리에 통째로 올려버리는 극강의 속도가 필요하죠.

"그럼 전 세계에서 가장 많이 쓰이는 인메모리 데이터베이스 'Redis'의 작동 원리와, 주식 실시간 랭킹에 딱 맞는 'Sorted Set' 같은 자료구조는 어떻게 써?"