# NoSQL 데이터베이스 백과사전 항목 NoSQL 데이터베이스는 전통적인 관계형 데이터베이스(RDBMS)와 다른 데이터 모델, 스키마 설계, 분산 아키텍처를 활용하여 대용량 데이터 처리와 높은 확장성, 가용성을 달성하는 데이터 저장 기술 집합을 지칭한다. 일반적으로 구성되는 특징으로는 스키마리스 데이터 모델, 수평적 확장성, 분산 저장소, 그리고 일관성 모델의 차이로 인한 설계 유연성이 있다. NoSQL은 반드시 SQL을 배제하는 것이 아니라, 필요에 따라 SQL 계열 질의 기능을 보완적으로 이용하기도 한다. ## 개요 및 역사 - 기원: 대규모 웹 서비스와 빅데이터 필요성이 증가하면서 관계형 데이터베이스의 한계를 보완하기 위해 등장했다. 초기에는 특정 용도에 특화된 데이터 모델이 주를 이뤘으며, 이후 일반화된 분산 NoSQL 시스템이 확산되었다. - 특징적 전제: 대용량 데이터, 높은 쓰기/읽기 처리량, 지연 시간 최소화, 다중 지역 배포, 스키마 자유도, 다중 데이터 모델 지원의 필요성. - 현재 위치: 많은 시스템이 NoSQL과 RDBMS를 혼용하는 하이브리드 접근을 채택하고 있으며, 일부 시스템은 멀티 모델 데이터 저장을 통해 하나의 데이터베이스에서 여러 모델을 지원한다. ## 분류(Category) 및 대표 데이터 모델 NoSQL은 일반적으로 네 가지 주요 카테고리로 구분된다. 각 카테고리는 데이터 모델, 쿼리 방식, 강점 및 단점을 다르게 가져간다. ### 1) Key-Value Stores - 데이터 모델: 간단한 키와 값의 쌍으로 구성된 비정형 데이터 저장. - 특징: - 빠른 읽기/쓰기, 단순성, 스케일 아웃에 강함. - 복잡한 질의나 관계형 조인은 기본적으로 지원되지 않는 경우가 많음. - 대표 예시: Redis, DynamoDB의 일부 기능, Riak, Aerospike. - 용도: 세션 저장, 캐시, 상태 관리, 간단한 구성 저장 등. ### 2) Document Stores - 데이터 모델: JSON, BSON 등 문서(document) 단위로 데이터 저장. 문서는 컬렉션 단위로 관리된다. - 특징: - 스키마리스 또는 스키마 유연성, 중첩 문서 구조를 자연스럽게 저장 가능. - 일부 시스템은 트랜잭션과 일관성 모델에 제한이 있을 수 있으나 현대 시스템은 다중 도큐먼트 트랜잭션도 지원. - 대표 예시: MongoDB, Couchbase, CouchDB, Amazon DocumentDB, RavenDB. - 용도: 콘텐츠 관리, 로그, 이벤트 저장, 주문/고객 정보의 복합 문서 저장 등. ### 3) Column-Family Stores - 데이터 모델: 컬럼 패밀리로 구성된 넓은 열 스키마를 사용하며, 행은 키-값 쌍의 집합으로 구성되되 열의 스키마는 유연하다. - 특징: - 대용량 데이터의 대량 읽기/쓰기 및 고성능 분석에 적합. - 스키마 설계가 중요하며, 컬럼 패밀리 간의 모델링이 성능에 큰 영향. - 대표 예시: Apache Cassandra, HBase, ScyllaDB. - 용도: 로그 수집, 시계열 데이터, 메타데이터 저장, 대규모 분산 애플리케이션의 데이터 저장. ### 4) Graph Databases - 데이터 모델: 노드(node), 간선(edge), 속성(property)으로 구성된 그래프 구조. - 특징: - 관계가 핵심인 데이터 모델에 최적화. 그래프 탐색, 경로 계산, 연결성 분석에 강점. - 트랜잭션을 포함한 ACID 지원 정도는 DB에 따라 차이가 있음. - 대표 예시: Neo4j, ArangoDB, JanusGraph, Dgraph. - 용도: 소셜 네트워크, 추천 시스템, 네트워크 인프라 분석, 지식 그래프. ## 데이터 모델의 설계 관점 - 스키마 설계: NoSQL은 스키마리스 성향이 강하나, 운영 시점에는 데이터 접근 패턴에 맞춘 스키마 설계가 여전히 중요하다. 예를 들어 Document Store에서는 문서의 중첩 구조를 어떻게 구성할지, Column-Family Store에서는 열 패밀리 구성과 키 설계가 성능에 큰 영향을 준다. - 중복성(Denormalization)과 조회 성능: 관계형 데이터의 정규화와 달리 NoSQL에서는 조회 성능을 높이기 위해 데이터 중복 저장이 일반적이다. - 인덱싱: 각 데이터 모델에서 지원하는 인덱스 유형이 다르며, 올바른 인덱스 선택이 쿼리 성능의 결정적 요소다. - 트랜잭션 모델: 전통적 RDBMS의 강력한 트랜잭션(ACID)과 달리, 많은 NoSQL 시스템은 BASE(또는 eventual consistency) 관점의 모델을 따른다. 다중 문서 트랜잭션의 지원 여부는 DB에 따라 다르므로 요구사항에 맞춰 선택해야 한다. ## 일관성, 가용성, 분산 처리(CAP 이론) - CAP 이론: 한 분산 시스템은 일관성(Consistency), 가용성 Availability, 네트워크 분할 허용성 Partition tolerance 중에서 두 가지를 우선적으로 만족하고 나머지는 희생할 수 있다는 이론이다. - 일관성 모델: - 강한 일관성(Strong Consistency): 읽은 데이터가 항상 최신 상태를 반영. - 최종 일관성(Eventual Consistency): 시간이 지나면 결국 일관성을 달성. - 수렴 속도와 가용성 간의 트레이드오프를 고려해 설계. - BASE 원칙: Basically Available, Soft state, Eventual consistency. 대규모 분산 시스템의 설계 철학 중 하나로, 고가용성에 초점을 둔다. - 운영 시 고려사항: 서비스의 요구 응답 시간, 실패 복구 속도, 데이터 손실 허용도, 지연 허용 범위 등을 기반으로 일관성 모델을 선택한다. ## 트랜잭션과 일관성 관리 - 단일 문서/키-값 트랜잭션: 많은 NoSQL 시스템은 단일 문서 또는 단일 키-값 단위에서 원자성을 제공한다. - 다중 문서 트랜잭션: MongoDB 4.x 이상 등 일부 시스템은 다중 도큐먼트 트랜잭션을 지원한다. - 분산 트랜잭션 대 로컬 트랜잭션: 분산 환경에서의 트랜잭션은 성능과 신뢰성에 큰 영향을 미치므로, 애플리케이션 설계 시 필요한 경우에만 분산 트랜잭션을 도입하고, 가능하면 보정 가능한 이벤트 기반 패턴(Event Sourcing, CQRS 등)을 고려한다. ## 운영 및 보안 - 운영 특징: - 수평적 확장성에 따른 샤딩/리플리케이션 구성. - 내결함성, 백업/복구, 모니터링, 로깅의 중요성 증가. - 보안 관점: - 인증/인가, 암호화(전송 중/정적 데이터 암호화), 접근 제어 목록(ACL) 및 롤 기반 접근 제어(RBAC) 적용. - 보안 정책과 감사 로그 활성화. ## 성능 및 확장성 실무 가이드 - 요구사항 분석: 초당 트랜잭션(TPS), 평균 응답 시간(Latency), 데이터 규모, 성장 예측을 명확히 한다. - 데이터 모델 선정: 데이터 접근 패턴에 맞춘 데이터 모델 선택이 핵심이다. 예를 들어 읽기 중심인지 쓰기 중심인지, 관계형 데이터가 많은지 여부를 판단한다. - 초기 아키텍처 설계: 분산 배포 전략(다중 리전, 다중 가용영역), 샤딩 키 설계, 인덱스 구성, 캐시 전략. - 운영 전략: 모니터링 지표(지연, 에러율, 캐시 히트율, 노드 가용성, 재시도 수), 백업 주기, 장애 복구 계획. - 비용 관리: 저장 용량 증가와 네트워크 트래픽 비용 등 총소유비용(TCO)을 예측하고 비용 최적화를 위한 설정을 검토한다. ## 대표 시스템과 비교 포인트 - Key-Value Stores: 단순성, 초저지연, 캐시 성능에 강점. 데이터 모델이 단순한 애플리케이션에 적합. - Document Stores: 구조화된 문서 중심의 조회가 많은 애플리케이션에 적합. 스키마 진화에 대응하기 쉽다. - Column-Family Stores: 대규모 데이터의 분산 저장과 분석에 강점. 스키마 설계의 정밀도가 성능에 큰 영향을 미친다. - Graph Databases: 복잡한 관계 탐색, 그래프 기반 분석에 최적. 소셜 네트워크, 추천 시스템, 네트워크 분석 등에 적합. ## 도입 사례 및 활용 맥락 - 대규모 웹 서비스의 세션 저장 및 캐시 - 실시간 로그 수집 및 분석 파이프라인 - 전자상거래의 주문 및 고객 데이터 관리 - 소셜 네트워크의 관계망 탐색 및 추천 엔진 - IoT 데이터의 시계열 저장 및 질의 ## 선택 시 주의점 - 일관성 요구 정도와 트랜잭션 필요성: 강한 일관성이 필수인지, eventual consistency로 충분한지 판단. - 데이터 모델의 복잡도와 질의 패턴: 다중 조인 필요성 여부, 중복 저장의 허용 여부. - 운영 팀의 숙련도 및 생태계: 도구, 커뮤니티, 상용 지원 여부. - 다중 모델 필요성: 하나의 데이터 저장소에서 여러 모델을 지원하는지 여부. --- 관련 문서: [[NoSQL 데이터베이스 유형]], [[CAP 이론]], [[쿼리 언어 비교]], [[분산 시스템의 아키텍처]]