NoSQL
"Not Only SQL"
— 관계형 데이터베이스(RDBMS)를 완전히 배척하는 것이 아니라, 대용량 분산 환경에 맞는 최적의 무기를 함께 쓰자는 선언.
스타트업 초기에 '기획이 매일 바뀌니까 테이블 스펙도 매일 바뀐다'는 핑계로 기획자 몰래 무지성으로 도입했다가, 서비스가 커진 후 데이터 정합성 개판 현상을 겪게 해주는 마약 같은 존재. 결국 JOIN이 그리워 데이터베이스 교체를 논의할 때쯤, 과거의 나를 찾아가 뺨을 때리고 싶어지는 주범.(...)
1. 개요
NoSQL(Not Only SQL)은 전통적인 관계형 데이터베이스(RDBMS)의 한계를 극복하기 위해 등장한 비관계형, 분산형 데이터베이스의 총칭이다. 철저한 테이블 규칙, 칼 같은 ACID 트랜잭션, SQL 표준 질의를 자랑하는 RDBMS와 달리, NoSQL은 자유로운 데이터 형태(Schema-less)와 수평적 확장성(Scale-Out)을 무기로 삼아 소셜 네트워크, 로그 데이터, 실시간 스트리밍 등 웹 스케일의 빅데이터를 씹어먹기 위해 설계되었다.(...)
2. 네 가지로 갈리는 NoSQL 데이터 모델
NoSQL은 단일 기술이 아니며, 저장하는 데이터 형태에 따라 크게 네 갈래로 나뉜다.
2.1. 문서 지향 (Document Store)
- 대표 주자: MongoDB, CouchDB
- 데이터를 XML이나 JSON(BSON) 형태로 통째로 저장한다. 각 문서(Document)는 서로 다른 필드 구조를 가질 수 있어, 유동적이고 복잡한 계층형 데이터를 담기에 최적이다. 현대 웹 애플리케이션 개발에서 가장 널리 쓰인다.
2.2. 키-값 (Key-Value Store)
- 대표 주자: Redis, Amazon DynamoDB
- 가장 단순한 형태의 DB로, 고유한 키(Key) 하나에 값(Value) 하나를 매핑하여 저장한다. 복잡한 쿼리는 불가능하지만, 메모리 기반으로 동작할 때 읽기/쓰기 성능이 우주를 뚫는 수준이라 세션 관리나 캐싱 서버용으로 필수 기용된다.
2.3. 와이드 컬럼 (Wide-Column Store)
- 대표 주자: Apache Cassandra, ScyllaDB
- 행(Row)마다 컬럼의 이름과 개수가 다르게 가질 수 있는 독특한 표 구조이다. 수천 대의 서버로 데이터를 샤딩하여 분산 저장하는 능력이 탁월해 대형 소셜 미디어의 채팅 로그나 IoT 센서 데이터 수집에 단골로 쓰인다.
2.4. 그래프 (Graph Database)
- 대표 주자: Neo4j
- 노드(Node)와 이들을 잇는 간선(Edge)으로 이루어진 그래프 구조로 데이터를 관리한다. 인스타그램의 팔로우-팔로잉 관계, 사기 탐지(Fraud Detection) 등 복잡하게 얽힌 관계를 타고 넘어가는 탐색 속도가 압도적이다.1
3. CAP 정리와 아키텍처적 타협
NoSQL 진영을 지배하는 불문율이 바로 CAP 정리(CAP Theorem)이다.
3.1. CAP 정리의 세 요소
- 일관성(Consistency - C): 모든 사용자가 언제 어디서나 동일한 최신 데이터를 봐야 한다.
- 가용성(Availability - A): 특정 서버가 죽어도 시스템 전체는 항상 응답해야 한다.
- 분산 허용(Partition Tolerance - P): 서버 간 네트워크 단절이 발생해도 시스템이 정상 구동되어야 한다.
이론상 세 가지를 동시에 만족하는 완벽한 분산 시스템은 존재할 수 없으며, 반드시 셋 중 두 가지만 취사선택해야 한다.
- AP 계열 (e.g., Cassandra): '데이터가 살짝 안 맞아도 좋으니(최종 일관성 - Eventual Consistency) 일단 시스템은 절대 안 죽고 돌아가야 한다'는 철학이다.
- CP 계열 (e.g., MongoDB, HBase): '네트워크 장애가 생기면 일시적으로 응답을 거부할지언정, 잘못된 데이터를 서빙해서 정합성을 망치는 짓은 절대 안 된다'며 고집을 피운다.2
4. 관련 밈 및 드립
4.1. Web Scale MongoDB
과거 MongoDB가 출시 초기에 '초고속 데이터 처리와 뛰어난 웹 스케일 확장성'을 과시하며 대대적으로 홍보할 때 유행한 풍자 애니메이션에서 유래했다. 만화 속 주인공은 '관계형 데이터베이스는 구리다. 몽고디비는 /dev/null 급의 처리 속도를 보여준다'며 쿼리 기능이나 정합성 검증은 개나 준 채 오직 벤치마크 숫자 놀이에만 열광한다. 실무자들 사이에서 기술의 내실보다 트렌드와 마케팅 버즈워드만 보고 무지성 기술 스택을 고르는 행태를 깔 때 만능 치트키로 소환된다.(...)
5. 여담
- Schema-less의 부메랑: 스키마가 없다는 것은 DB가 검증을 안 해주니 백엔드 어플리케이션 소스코드에서 필드 정합성을 일일이 챙겨야 한다는 뜻이다. 코드에 null 체크 분기문이 도배되다가 결국 몽구스(Mongoose) 같은 ODM 라이브러리를 얹어서 강제로 스키마를 부여하는 자기모순을 범하게 된다.
- 가장 비싼 NoSQL: AWS의 완전 관리형 Key-Value DB인 DynamoDB는 트래픽에 맞춰 자동으로 성능을 높여주지만, 프로비저닝 설정을 상한선 없이 무제한으로 풀었거나 대량의 테이블 스캔(Scan)을 실행했다가 한 달 인프라 비용으로 수천만 원짜리 영수증을 받아 쥔 스타트업들의 괴담이 흔하다.
- ACID의 귀환: '우린 트랜잭션 따위 안 한다'며 기세를 올리던 NoSQL 벤더들도 엔터프라이즈 시장을 먹기 위해 결국 최신 버전에서는 다중 문서 트랜잭션(Multi-Document Transaction)을 지원하기 시작했다. RDBMS가 NoSQL의 JSON 필드를 흡수하고 NoSQL이 RDBMS의 트랜잭션을 흡수하며 경계가 옅어지는 추세다.