NoSQL에 대해 자세히 알아보기

이제 정형화된 표(Table)라는 감옥을 탈출하여, 데이터의 야생이자 무한한 확장이 가능한 NoSQL(Not Only SQL)의 대륙으로 진격할 시간입니다! 🫡

사용자의 주식 시스템에서 쏟아지는 방대한 분봉 데이터, 전 세계 뉴스 텍스트, SNS의 비정형 반응들을 기존 SQL(RDBMS)에 쑤셔 넣으려다가는 금방 시스템이 비명을 지르며 멈추고 말 겁니다. NoSQL은 바로 그런 '빅데이터의 폭주'를 막기 위해 탄생했습니다.

---

🏗️ 1. NoSQL의 철학: "유연성과 확장성을 위해 관계를 포기하다"

RDBMS(MySQL, Oracle 등)가 "데이터 간의 관계"와 "무결성"에 목숨을 건다면, NoSQL은 "성능"과 "수평적 확장(Scale-out)"에 올인합니다.

① 스키마리스 (Schema-less)

• RDBMS: 테이블을 만들기 전에 컬럼 이름과 타입을 미리 정해야 합니다. (수정이 매우 힘듦)
• NoSQL: 데이터 구조가 정해져 있지 않습니다. 오늘 주식 데이터에 '날씨' 정보를 추가하고 싶으면 그냥 넣으면 됩니다.

② BASE vs ACID

• RDBMS (ACID): 데이터는 무조건 정확해야 하고 한 치의 오차도 없어야 합니다.
• NoSQL (BASE): Basically Available, Soft state, Eventual consistency. 데이터가 아주 잠깐 틀릴 수도 있지만, 결국에는(Eventually) 일관성을 맞춥니다. 대신 시스템은 멈추지 않고(Availability) 엄청나게 빠릅니다.

---

📂 2. NoSQL의 4대 핵심 모델: "목적에 맞는 무기 선택"

NoSQL은 데이터 저장 방식에 따라 크게 네 종류로 나뉩니다. 사용자의 주식 시스템 곳곳에 배치될 녀석들입니다.

① Document DB (예: MongoDB)

• 특징: JSON 형태의 문서를 그대로 저장합니다.
• 용도: 가장 범용적입니다. 주식 종목의 상세 정보(이름, 업종, 배당 정보 등)처럼 데이터 구조가 복잡하고 자주 바뀌는 경우에 최적입니다.
• 비유: 서류 봉투(Document)에 관련 서류를 몽땅 넣어 캐비닛에 보관하는 방식입니다.

② Key-Value DB (예: Redis, Riak)

• 특징: 이름(Key)과 값(Value)만 있는 가장 단순한 구조입니다.
• 용도: 초고속 조회가 필요할 때 씁니다. 실시간 현재가, 로그인 세션 관리 등.
• 비유: 사물함 번호와 그 내용물만 있는 사물함실과 같습니다.

③ Wide-Column DB (예: Cassandra, HBase)

• 특징: 행마다 다른 컬럼을 가질 수 있으며, 수천 대의 서버로 확장이 가능합니다.
• 용도: 사용자의 주식 분봉/틱 데이터 저장소입니다. 쓰기 성능이 미쳤다고 표현할 정도입니다. 페이스북이나 넷플릭스가 수조 건의 로그를 저장할 때 씁니다.
• 비유: 무한히 옆으로 늘어날 수 있는 거대한 엑셀 시트입니다.

④ Graph DB (예: Neo4j)

• 특징: 노드(데이터)와 간선(관계)으로 연결된 구조입니다.
• 용도: "A종목을 산 사람들은 B종목도 샀다"는 인맥/연관 관계 분석, 주식 작전 세력의 계좌 추적 등에 탁월합니다.
• 비유: 거미줄처럼 얽힌 인맥 지도입니다.

---

⚖️ 3. CAP 이론: "세 마리 토끼를 다 잡을 수는 없다"

NoSQL을 설계할 때 반드시 내려야 하는 결단입니다. 다음 세 가지 중 두 가지만 선택할 수 있습니다.

1. Consistency (일관성): 모든 사용자가 같은 시간에 같은 데이터를 봐야 함.
2. Availability (가용성): 노드 몇 개가 죽어도 시스템은 응답해야 함.
3. Partition Tolerance (분할 내성): 네트워크가 끊겨도 시스템이 동작해야 함.

• A그룹(우량주/배당주): 일관성이 중요하므로 CP 또는 CA 조합을 선택합니다.
• B그룹(테마주/실시간 뉴스): 0.1초라도 멈추면 안 되므로 AP 조합을 선택하여 빠른 응답을 보장합니다.

---

💡 4. 실전 전략: "Polyglot Persistence"

현대적인 아키텍트는 하나의 DB만 쓰지 않습니다.

• 사용자 계정/자산 정보: 여전히 RDBMS (MySQL 등)가 안전합니다.
• 실시간 시세 캐싱: Redis (Key-Value)로 초고속 처리합니다.
• 수년간의 주식 차트 데이터: Cassandra (Wide-Column)에 쏟아붓습니다.
• 종목 뉴스 및 비정형 데이터: MongoDB (Document)에 유연하게 쌓습니다.

이렇게 여러 DB를 용도에 맞게 섞어 쓰는 것을 폴리글랏 퍼시스턴스(Polyglot Persistence)라고 하며, 사용자의 시스템이 지향해야 할 종착역입니다.

---

💡 실전 비유: "한정식집 vs 푸드코트"

• RDBMS (한정식집): 모든 반찬이 정해진 자리에 완벽하게 차려져 나옵니다(Schema). 하나라도 부족하면 상을 내지 않습니다(ACID). 깔끔하지만 손님이 갑자기 천 명 오면 대응이 불가능합니다.
• NoSQL (푸드코트): 중식, 일식, 양식(4대 모델)이 각각 따로 있습니다. 손님이 원하는 메뉴를 빨리빨리 받아 갑니다. 손님이 만 명 오면 매장을 옆으로 계속 늘리면 됩니다(Scale-out). 다만 식기나 서비스 통일감(Consistency)은 조금 떨어질 수 있습니다.

---

📊 요약: NoSQL 선택 가이드

구분	Document	Key-Value	Wide-Column	Graph
대표주자	MongoDB	Redis	Cassandra	Neo4j
데이터 형태	JSON 객체	Key: Value	행별 유연한 컬럼	노드와 엣지
주요 강점	유연한 개발 속도	비교 불가한 속도	무한한 확장성	복잡한 관계 분석
주식 시스템 활용	종목 메타 데이터	실시간 호가 캐싱	수조 건의 틱 데이터	세력/연관 종목 분석

---

🚀 꼬리 질문 🫡

사용자의 주식 시스템은 이제 어떤 형태의 데이터가 들어와도, 얼마나 많은 양이 쏟아져도 버텨낼 수 있는 진정한 '데이터 댐'을 갖추게 되었습니다.

그런데 NoSQL 중에서 가장 먼저 손이 가게 될 녀석은 아무래도 활용도가 가장 높은 MongoDB일 것입니다. 하지만 몽고DB도 단순히 데이터를 넣는다고 끝이 아닙니다. '인덱스'를 어떻게 잡느냐, '샤딩'을 어떻게 하느냐에 따라 성능이 천차만별이죠.

"그럼 NoSQL의 대표주자인 'MongoDB'의 핵심 구조인 Document/Collection 개념과, 데이터를 여러 서버로 쪼개 저장하는 'Sharding' 원리는 어떻게 돼?"