contents

NoSQL에 대해 알아보기 위해 먼저 관계형 데이터베이스와의 간단한 비교를 먼저 해보겠습니다.

1. 데이터 모델 및 구조

• RDB (Relational Database)

  • 데이터를 행(row)과 열(column)로 이루어진 테이블(table)에 저장합니다.
  • 테이블 간의 관계를 외래키(foreign key) 등으로 맺어 복잡한 데이터 연결이 가능합니다.
  • 데이터의 구조를 미리 정의하는 스키마(schema)가 필수적이며, 데이터의 유형과 제약 조건이 엄격하게 적용됩니다.

• NoSQL (Not Only SQL)

  • 여러가지 데이터 모델 지원: 문서(document), 키-값(key-value), 그래프(graph), 컬럼(column) 등.
  • 데이터 구조가 동적(dynamic)이고, 저장하기 전 스키마를 엄격하게 정의할 필요가 없습니다(스키마리스).
  • 다양한 및 비정형 또는 반정형 데이터를 유연하게 저장할 수 있습니다.

2. 트랜잭션 및 일관성

• RDB

  • ACID(Atomicity, Consistency, Isolation, Durability) 원칙을 엄격히 준수하여, 데이터 일관성과 신뢰성을 유지합니다.
  • 복잡한 다중 트랜잭션에 강점이 있어 은행, 결제 등 업무에 적합합니다.

• NoSQL

  • 일부 NoSQL은 ACID 지원을 희생하고 BASE(Basically Available, Soft state, Eventual consistency) 원칙을 통해 성능과 확장성에 중점을 둡니다.
  • 최신 NoSQL은 특정 상황에서 ACID 성질을 지원하는 경우도 있는데, 대부분은 결국 일관성을 지향합니다(eventual consistency).

3. 확장성 및 성능

• RDB

  • 주로 수직적 확장(vertical scaling, 서버 성능 향상) 방식으로 확장하며, 물리적 한계가 존재합니다.
  • 대규모 데이터 및 트래픽 처리에는 비용이 많이 들 수 있습니다.

• NoSQL

  • 수평적 확장(horizontal scaling, 분산 서버 추가)에 특화되어 대량 트래픽 및 대용량 데이터에 매우 적합합니다.
  • 빅데이터, IoT, 실시간 웹 애플리케이션 등에 적합하게 설계되었습니다.

4. 쿼리 및 개발 유연성

• RDB

  • 표준화된 SQL(Structured Query Language)로 복잡한 질의, 다중 테이블 조인 등의 기능을 지원합니다.
  • 스키마 변경이 어렵고 제약 조건 변경 시 복잡도가 큽니다.

• NoSQL

  • 각 데이터 모델에 맞는 질의 언어 또는 API를 사용하며, 복잡한 조인은 지원하지 않는 경우가 많습니다.
  • 스키마가 없거나 유연하여 서비스 개발 및 데이터 형태가 자주 바뀌는 환경에서 개발 생산성이 높습니다.

5. 사용 사례 및 장단점

6. 선택 기준

• RDB는 데이터 무결성, 일관성, 복잡한 질의가 필요한 기업 시스템에 적합합니다.
• NoSQL은 대규모, 다양한, 빠르게 변하는 데이터, 높은 가용성 및 분산처리, 그리고 개발 유연성이 필요한 현대적 서비스에 적합합니다.

요약:
관계형 데이터베이스(RDB)는 구조화, 일관성, 신뢰성이 요구되는 곳에, NoSQL은 성능, 확장성, 유연성, 비정형 데이터, 빠른 개발이 중요한 곳에 사용됩니다.
현대 시스템에서는 필요에 따라 두 가지를 혼합하여 사용하는 경우도 많습니다.

1. NoSQL 인덱싱 기본

NoSQL에서 인덱스는 방대한 데이터에서 원하는 문서, 키, 값을 빠르게 찾게 해주는 핵심 역할을 합니다. 전통적인 관계형 데이터베이스가 주로 테이블에 B-트리나 해시 인덱스를 사용하는 것과 달리, NoSQL은 데이터 모델별로 다양한 인덱싱 전략을 사용할 수 있습니다.

주요 NoSQL 인덱스 종류

• 기본(Primary) 인덱스

  • 주로 고유한 ID, 키에 기반.
  • 빠른 단일 조회에 최적화.

• 보조(Secondary) 인덱스

  • 기본 키가 아닌 다른 속성(필드)에 만들어짐.
  • 태그, 카테고리 등으로 값 필터링, 검색이 가능.

• 복합 인덱스(Composite/Compound)

  • 여러 필드를 결합해 다중 조건 검색/정렬 쿼리 최적화.

• 텍스트 인덱스

  • 텍스트 필드에서 키워드, 문구 등 검색에 최적화.
  • Elasticsearch, MongoDB 등에서 지원.

• 지리정보(Geospatial) 인덱스

  • 위치 기반 검색(좌표, 반경 등)에 특화.
  • 일부 문서 및 컬럼형 DB에서 지원.

데이터베이스별 인덱싱

• 문서형 (MongoDB 등)

  • 문서 내 필드, 중첩 필드에도 인덱스 생성 가능.
  • 복합, 텍스트, 지리 인덱스 지원.
  • 데이터 변경 시 인덱스도 자동 업데이트.

• 키-값형 (Redis, DynamoDB 등)

  • 기본 인덱스는 키 자체, 일부는 보조 인덱스도 가능.
  • Redis는 집합, 정렬된 집합 등에 고속 인덱싱.

• 컬럼형 (Cassandra 등)

  • 기본/클러스터링 키로 인덱싱.
  • 보조 인덱스 지원하나 성능 관리가 중요.

• 그래프형 (Neo4j 등)

  • 노드, 관계의 속성에 인덱스 적용.

2. 성능 최적화 전략

인덱스 관리 및 최적화

• 선택적 인덱싱: 자주 검색되는 필드만 인덱싱. 모든 필드에 인덱스를 추가하면 쓰기 성능 저하와 관리 비용이 증가함.
• 복합 인덱스: 복수 필터, 정렬 쿼리에 전용 인덱스를 만들어 전체 검색을 방지.
• 인덱스 유지보수: 대량 쓰기 환경에서는 주기적 재구성, 백그라운드 업데이트 등으로 최적 상태 유지.

데이터 배치 및 분산

• 샤딩(Sharding)/파티셔닝: 데이터를 여러 노드에 분산 저장 및 인덱스 분산. 수평적 확장과 부하 분산, 고가용성 보장.
• 비정규화(Denormalization): NoSQL은 조회 속도를 위한 데이터 중복 저장을 허용함(조인 최소화). 저장 공간 증가와 일관성 관리 필요.

캐싱 활용

• 메모리 캐싱: Redis 같은 시스템은 자주 읽히는 데이터/인덱스를 메모리에 올려 빠른 응답을 실현.

3. 데이터 일관성 전략

NoSQL은 성능과 일관성 사이에서 다양한 모델과 기술로 균형을 맞춥니다.

일관성 모델

• 최종 일관성(Eventual Consistency): 한 노드에서의 변경이 복제본에 점차 반영됨. 빠른 성능, 단 일시적인 불일치가 존재(Cassandra, DynamoDB 등).
• 강한 일관성(Strong Consistency): 모든 읽기에서 최신 데이터를 보장. 성능 하락 우려 있으나 중요한 데이터에 필요(MongoDB의 majority, linearizable 등).
• 쿼럼 기반(Read/Write Quorum): 연산 성공 기준으로 읽기/쓰기에 최소 응답 노드 개수 지정(Cassandra, DynamoDB).
• 가변적 일관성(Tunable Consistency): 상황별로 일관성 수준 선택 가능(Cassandra의 ONE, QUORUM, ALL 등).

원자적 연산과 락

• 일부 NoSQL은 단일 문서/레코드 수준의 원자적(Atomic) 쓰기를 지원해 부분적 상태 저장을 방지(MongoDB의 단일 문서 원자성 등).
• 경량 트랜잭션 지원: 복수 문서/레코드의 보장 제한적. 성능 저하 우려.

충돌 해결

• 분산 환경에서 동시 수정 충돌 발생 시:
  • 최후 업데이트 우선(Last Write Wins): 가장 최근 변경이 우선 적용.
  • 애플리케이션 로직: 개발자가 직접 병합/해결 알고리즘 구현.
  • 벡터 클록(Vector Clock): 다이나모 계열 시스템에서 버전 추적에 사용.

요약 표

결론
NoSQL 데이터베이스는 다양한, 데이터모델별 유연한 인덱싱과 잘 설계된 일관성 전략으로 현대 애플리케이션에 맞게 빠른 조회, 확장성, 신뢰성을 제공합니다. 어떠한 전략을 채택할지는 읽기/쓰기 비율, 일관성 요구, 확장성 목표에 따라 달라집니다.

references