NoSQL

1. 개요

NoSQL은 전통적인 관계형 데이터베이스의 대안으로, 1998년 카를로 스트로찌에 의해 처음 명명되었으며, 2009년 Last.fm 개발자 요한 오스카르손에 의해 재도입되었다. NoSQL은 SQL 인터페이스를 사용하지 않으며, 대규모 데이터 처리와 유연성을 강조한다. 아키텍처는 결과적 일관성, 분산 아키텍처를 특징으로 하며, 키-값, 문서, 와이드 컬럼, 그래프 등 다양한 데이터 모델을 지원한다. 성능, 확장성, 유연성 측면에서 관계형 데이터베이스와 비교되며, ACID 속성 및 조인 지원 여부는 데이터베이스 종류에 따라 다르다. 쿼리 최적화 및 인덱싱은 데이터베이스의 설계 방식에 따라 차이를 보인다.

2. 역사

1998년, 카를로 스트로찌(Carlo Strozzi)는 표준 구조화 질의 언어 인터페이스를 사용하지 않는 자신의 경량 오픈 소스 관계형 데이터베이스를 NoSQL이라고 명명했다. 스트로찌는 현재의 NoSQL 운동이 "전반적인 관계형 모델에서 점차 멀어지고 있으므로" NoREL(비관계형)로 부르는 것이 더 적절하다고 언급했다.

2009년 초, 라스트 FM의 요한 오스칼손(Johan Oskarsson)은 오픈 소스 분산 데이터베이스를 논의하기 위한 미트업 행사를 조직하면서, 이와 같은 데이터베이스를 NoSQL이라고 불렀다. 이 이름은 고전적인 관계형 데이터베이스 시스템의 주요 특성인 ACID 제공을 주로 시도하지 않은 수많은 비관계형, 분산 데이터 저장 공간의 등장에 따라 사용되었다.

NoSQL이라는 용어는 1998년, SQL 인터페이스를 갖지 않는 경량 관계형 데이터베이스의 오픈 소스 소프트웨어의 이름으로 처음 사용되었다. 그 저자인 Carlo Strozzi는 NoSQL 운동에 대해 "관계 모델 전체와 선을 긋는 것이므로, 'NoREL' 등으로 명명해야 했다"고 주장하고 있다. 이 용어는 라스트 FM의 Johan Oskarsson의 요청에 의해 2009년 초에 개최된 오픈 소스 분산 데이터베이스에 대한 회합에서 Rackspace의 직원 Eric Evans에 의해 재도입되었다. 이 이름은 MySQL, MS SQL, PostgreSQL 등 관계형 데이터베이스 시스템에서 널리 사용되던 명명법을 참조하여 붙여진 것으로, ACID 보장을 제공하지 않는 비관계형 분산 데이터 스토어의 부상을 표현하려는 의도가 담겨 있었다.

NoSQL 운동이 널리 퍼짐에 따라, 그 이름이 갖는 부정적인 인상(SQL은 불필요하다 등)이 문제가 되어 논의가 일어나고 있다. Eric Evans는 NoSQL을 Not only SQL의 백크로님으로 이해하는 것이 바람직하다고 보고 있다.

3. 아키텍처

현대적인 관계형 데이터베이스는 소규모의 고빈도 트랜잭션이나 거대하지만 쓰기가 거의 없는 트랜잭션에 최적화되어 설계되었기 때문에, 최근 필요성이 높아지고 있는 대규모 데이터를 기반으로 한 data-intensive^영어 응용 사례에서는 성능이 저하되는 경우가 있다. 그러한 응용의 예로, 검색을 위한 문서의 인덱싱, 트래픽이 높은 웹사이트의 서버, 스트리밍 데이터의 배포 등이 있으며, Digg의 green badge, 페이스북의 받은 편지함 검색, eBay의 시스템 전체 등이 그 실례이다.

NoSQL의 아키텍처에서는, 결과적 일관성만을 보장하는 등 일관성 보장을 약하게 설계하거나, 트랜잭션을 하나의 데이터 항목으로 제한하는 경우가 많다. 보조적인 미들웨어 계층을 부가함으로써 완전한 ACID 보장을 제공하는 경우도 있다.

일부 NoSQL 시스템은 분산 아키텍처를 채용하고 있다. 이러한 시스템에서는, 많은 경우 분산 해시 테이블을 사용하여 데이터를 여러 서버에 중복되게 배치한다. 이를 통해, 서버를 추가하는 것만으로 시스템을 쉽게 스케일 업 시킬 수 있으며, 장애에 대한 내성도 강해진다.

4. 분류

NoSQL 데이터베이스는 데이터 모델에 따라 다양하게 분류할 수 있다.

스티븐 옌은 블로그 글에서 NoSQL 데이터베이스를 다음과 같이 분류했다.

👆

좌우로 밀어서 보기

📌 열 고정 해제

용어	연관 데이터베이스
KV Store	Keyspace, Flare, SchemaFree, RAMCloud, Oracle NoSQL Database (OnDB)
KV Store - Eventually consistent	Dynamo, Voldemort, Dynomite, SubRecord, Mo8onDb, DovetailDB
KV Store - Hierarchical	GT.m, Cache
KV Store - Ordered	TokyoTyrant, Lightcloud, NMDB, Luxio, MemcacheDB, Actord
KV Cache	Memcached, Repcached, Coherence, Hazelcast, Infinispan, EXtremeScale, JBossCache, Velocity, Terracotta
Tuple Store	Gigaspaces, Coord, Apache River
Object Database	ZopeDB, DB40, Shoal
Document Store	CouchDB, Cloudant, Couchbase, MongoDB, Jackrabbit, XML-Databases, ThruDB, CloudKit, Prsevere, Riak-Basho, Scalaris
Wide Columnar Store	BigTable, HBase, Apache Cassandra, Hypertable, KAI, OpenNeptune, Qbase, KDI

다음은 데이터 모델에 따른 NoSQL 데이터베이스의 분류이다.

👆

좌우로 밀어서 보기

📌 열 고정 해제

유형	대표적인 예시
튜플 저장소	아파치 리버, 기가스페이스, 타란툴, TIBCO 액티브스페이스, OpenLink Virtuoso
트리플 저장소	알레그로그래프, 마크로직, 온토텍스트-OWLIM, 오라클 NoSQL 데이터베이스, 프로피움 센스, Virtuoso Universal Server
객체 데이터베이스	오브젝티비티/DB, 페르스트, ZODB, db4o, 젬스톤/S, 인터시스템즈 캐시, 제이드, 오브젝트데이터베이스++, 오브젝트DB, 오브젝트스토어, ODABA, Realm, OpenLink Virtuoso, 버산트 객체 데이터베이스
네이티브 다중 모델 데이터베이스	아랑고DB, 애저 코스모스 DB, 오리엔트DB, 마크로직, 아파치 이그나이트, 카우치베이스, 파운데이션DB, 오라클 데이터베이스
멀티밸류 데이터베이스	D3 픽 데이터베이스, 확장 가능한 스토리지 엔진 (ESE/NT), 인피니티DB, 인터시스템즈 캐시, jBASE 픽 데이터베이스, mvBase 로켓 소프트웨어, mvEnterprise 로켓 소프트웨어, 노스게이트 인포메이션 솔루션즈 Reality (the original Pick/MV Database), 오픈QM, Revelation Software's OpenInsight (Windows) and Advanced Revelation (DOS), UniData 로켓 U2, UniVerse 로켓 U2

NoSQL은 다음과 같이 주요 분류로 나눌 수 있다.

* 정렬된 컬럼 지향: 행 키에 대해 컬럼(이름과 값의 조합) 집합을 가지며, 행마다 원하는 수만큼 컬럼을 저장할 수 있다. 컬럼은 컬럼명에 따라 정렬되므로, 컬럼명에 시각을 사용하여 시계열 데이터를 저장할 수 있다. (예: Apache Cassandra, Apache HBase)
* 도큐먼트 지향 (Document-oriented, Document store): XML, JSON 등 스키마가 없어 유연한 데이터 구조를 가진다. (예: MongoDB, Apache CouchDB, Amazon DocumentDB) XML 데이터베이스 등에서는 XQuery를 이용할 수 있다.
* 그래프 지향: 노드(정점), 에지(변), 프로퍼티(속성)로 구성되며, 노드 간 관계 관리에 특화된 데이터베이스이다. (예: Neo4j, Amazon Neptune)

4.1. 키-값 저장소 (Key-Value Store)

연관 배열(맵 또는 딕셔너리라고도 함)을 기본 데이터 모델로 사용하는 데이터베이스이다. 이 모델에서 데이터는 키-값 쌍의 모음으로 표현되며, 각 키는 해당 모음에서 한 번만 나타난다.

키-값 모델은 가장 단순한 형태의 데이터 모델 중 하나이며, 더 복잡한 데이터 모델은 종종 이 모델을 확장하여 구현된다. 키-값 모델은 키를 사전식 순서로 정렬하는 모델로 확장될 수 있다. 이러한 확장은 특정 키 범위를 효율적으로 검색할 수 있다는 점에서 유용하다.

키-값 저장소는 결과적 일관성에서 직렬 가능성에 이르는 다양한 일관성 모델을 지원한다. 일부 데이터베이스는 키 정렬을 제공한다. 하드웨어 구현 방식 또한 다양하여, 일부는 데이터를 메모리(RAM)에 저장하고 다른 일부는 솔리드 스테이트 드라이브(SSD)나 회전 디스크(HDD)에 저장한다.

NoSQL 데이터베이스는 데이터 모델에 따라 다음과 같이 분류할 수 있다.

4.2. 문서 저장소 (Document Store)

문서 저장소의 핵심 개념은 "문서"이다. 문서 지향 데이터베이스마다 이 정의에 대한 세부 사항은 다르지만, 모든 데이터베이스는 문서가 일부 표준 형식 또는 인코딩으로 데이터(또는 정보)를 캡슐화하고 인코딩한다고 가정한다. 사용되는 인코딩에는 XML, YAML, JSON 및 이진 형식(예: BSON)이 있다. 문서는 해당 문서를 나타내는 고유한 키를 통해 데이터베이스에서 주소가 지정된다. 문서 지향 데이터베이스의 또 다른 특징은 내용에 따라 문서를 검색하는 API 또는 쿼리 언어이다.

구현 방식에 따라 문서를 구성하거나 그룹화하는 방식은 다음과 같다.

* 컬렉션
* 태그
* 보이지 않는 메타데이터
* 디렉터리 계층

관계형 데이터베이스와 비교했을 때, 컬렉션은 테이블과 유사하며, 문서는 레코드와 유사하다고 볼 수 있다. 하지만 둘은 다르다. 테이블의 모든 레코드는 동일한 필드 시퀀스를 갖는 반면, 컬렉션의 문서는 완전히 다른 필드를 가질 수 있다.

4.3. 와이드 컬럼 저장소 (Wide Column Store)

H베이스, 아큐물로, 카산드라 등이 와이드 컬럼 스토어에 해당한다. 스티븐 옌은 빅테이블, HBase, 카산드라, Hypertable, KAI, OpenNeptune, Qbase, KDI를 와이드 칼럼 저장소로 제시했다.

데이터 모델별 분류에 따르면, 와이드 칼럼 저장소에는 애저 코스모스 DB, 아마존 다이나모DB, 빅테이블, 카산드라, 구글 클라우드 데이터스토어, HBase, 하이퍼테이블, 스킬라DB가 있다.

4.4. 그래프 데이터베이스 (Graph Database)

그래프 데이터베이스는 유한한 수의 관계로 연결된 요소로 구성된 그래프로 관계가 잘 표현되는 데이터를 위해 설계되었다. 데이터의 예로는 소셜 관계, 대중 교통 링크, 도로 지도, 네트워크 토폴로지 등이 있다.

; 그래프 데이터베이스 및 쿼리 언어

5. 성능

벤 스코필드는 여러 유형의 NoSQL 데이터베이스의 등급을 다음과 같이 평가했다:

성능과 확장성 비교는 종종 YCSB 벤치마크를 통해 이루어진다. NoSQL 데이터베이스의 성능은 일반적으로 초당 연산 횟수로 측정되는 처리량 지표를 사용하여 평가된다. 성능 평가는 프로덕션 구성, 데이터베이스 매개변수, 예상 데이터 볼륨 및 동시 사용자 작업 부하와 같은 적절한 벤치마크에 주의를 기울여야 한다.

벤 스코필드는 다양한 범주의 NoSQL 데이터베이스를 다음과 같이 평가했다:

👆

좌우로 밀어서 보기

📌 열 고정 해제

데이터 모델	성능	확장성	유연성	복잡성	데이터 무결성	기능
키-값 저장소	높음	높음	높음	없음	낮음	가변적(없음)
열 지향 저장소	높음	높음	보통	낮음	낮음	최소
문서 지향 저장소	높음	가변적(높음)	높음	낮음	낮음	가변적(낮음)
그래프 데이터베이스	가변적	가변적	높음	높음	낮음-중간	그래프 이론
관계형 데이터베이스	가변적	가변적	낮음	보통	높음	관계 대수

성능 및 확장성 비교는 YCSB 벤치마크를 사용하여 가장 일반적으로 수행된다. 현대적인 관계형 데이터베이스는 소규모의 고빈도 트랜잭션이나 거대하지만 쓰기가 거의 없는 트랜잭션에 최적화되어 설계되었기 때문에, 최근 필요성이 높아지고 있는 대규모 데이터를 기반으로 한 응용 사례에서는 성능이 저하되는 경우가 있다. 그러한 응용의 예로, 검색을 위한 문서의 인덱싱, 트래픽이 높은 웹사이트의 서버, 스트리밍 데이터의 배포 등이 있으며, Digg의 green badge, 페이스북의 받은 편지함 검색, eBay의 시스템 전체 등이 그 실례이다.

NoSQL의 아키텍처에서는 결과적 일관성만을 보장하는 등 일관성 보장을 약하게 설계하거나, 트랜잭션을 하나의 데이터 항목으로 제한하는 경우가 많다. 보조적인 미들웨어 계층을 부가함으로써 완전한 ACID 보장을 제공하는 경우도 있다.

일부 NoSQL 시스템은 분산 아키텍처를 채용하고 있다. 이러한 시스템에서는 많은 경우 분산 해시 테이블을 사용하여 데이터를 여러 서버에 중복되게 배치한다. 이를 통해 서버를 추가하는 것만으로 시스템을 쉽게 스케일 업 시킬 수 있으며, 장애에 대한 내성도 강해진다.

6. 관계형 데이터 처리

대부분의 NoSQL 데이터베이스는 쿼리에서 조인 기능을 제공하지 않으므로, 일반적으로 데이터베이스 스키마를 다르게 설계해야 한다. NoSQL 데이터베이스에서 관계형 데이터를 처리하는 세 가지 주요 기술은 다음과 같다. (조인을 지원하는 NoSQL 데이터베이스는 조인 및 ACID 지원 표 참고)

* 다중 쿼리: 하나의 쿼리로 모든 데이터를 검색하는 대신, 원하는 데이터를 얻기 위해 여러 쿼리를 수행한다. NoSQL 쿼리는 전통적인 SQL 쿼리보다 속도가 빠른 경우가 많으므로 추가 쿼리의 비용이 허용될 수 있다. 과도한 수의 쿼리가 필요하다면, 다른 두 가지 접근 방식 중 하나가 더 적절하다.
* 데이터 중복 저장 (비정규화): 외래 키만 저장하는 대신, 모델의 데이터와 함께 실제 외래 값을 저장한다. 예를 들어, 각 블로그 댓글에는 사용자 ID 외에도 사용자 이름을 포함하여 추가 조회를 거치지 않고도 사용자 이름에 쉽게 액세스할 수 있도록 한다. 그러나 사용자 이름이 변경되면 데이터베이스의 여러 위치에서 이를 변경해야 한다. 따라서 이러한 접근 방식은 쓰기보다 읽기가 훨씬 더 일반적인 경우에 더 잘 작동한다.
* 데이터 내장 (임베딩): MongoDB와 같은 문서 데이터베이스에서는 더 적은 수의 컬렉션에 더 많은 데이터를 넣는 것이 일반적이다. 예를 들어, 블로그 애플리케이션에서 블로그 게시물 문서 내에 댓글을 저장하여 한 번의 검색으로 모든 댓글을 가져오도록 선택할 수 있다. 따라서 이 접근 방식에서 단일 문서는 특정 작업에 필요한 모든 데이터를 포함한다.

7. ACID 및 조인 지원

ACID(원자성, 일관성, 고립성, 지속성) 또는 JOIN 동작을 지원하는 것으로 문서에 표현되어 있는 경우 지원으로 표기한다. 그러나 이 기준에는 대부분의 SQL 데이터베이스와 비슷한 방식으로 완전히 지원할 필요는 없다.

8. 쿼리 최적화 및 인덱싱

다이나모DB, MongoDB, 카산드라, Couchbase, HBase, Redis와 같은 다양한 NoSQL 데이터베이스는 인덱싱되지 않은 필드를 쿼리할 때 다양한 동작을 보인다. 많은 경우 이러한 쿼리에 대해 전체 테이블 또는 컬렉션 스캔을 수행하며, 데이터를 검색한 후 필터링 작업을 적용한다. 그러나 최신 NoSQL 데이터베이스는 쿼리 성능을 최적화하기 위해 고급 기능을 통합하는 경우가 많다. 예를 들어 MongoDB는 복합 인덱스 및 쿼리 최적화 전략을 지원하고, 카산드라는 보조 인덱스 및 구체화된 뷰를 제공하며, Redis는 특정 사용 사례에 맞게 맞춤형 인덱싱 메커니즘을 사용한다. Elasticsearch와 같은 시스템은 효율적인 텍스트 기반 검색을 위해 역 인덱스를 사용하지만, 인덱싱되지 않은 필드에 대해서는 여전히 전체 스캔이 필요할 수 있다. 이러한 동작은 확장성 및 효율적인 키 기반 작업에 중점을 둔 많은 NoSQL 시스템의 설계 방식을 반영하며, 임의의 필드에 대한 최적화된 쿼리보다는 CRUD(생성, 읽기, 업데이트 및 삭제) 작업과 키 기반 조회가 뛰어나다. 그러나 조인 또는 인덱싱되지 않은 필터링을 포함하는 복잡한 쿼리에 대한 적합성은 데이터베이스 유형(문서, 키-값, 광범위 열 또는 그래프) 및 특정 구현에 따라 달라진다.