NoSQL 이란, ‘Not only SQL’ 의 약자로 SQL 또는 관계형 데이터베이스 만을 사용하지 않고 여러 유형의 데이터베이스를 사용하는 확장된 데이터베이스 또는 데이터베이스 관리 시스템 (DBMS) 을 의미합니다. NoSQL 은, 2000년대 후반에 들어서면서 소셜 미디어 (예> 페이스북, 트위터 등) 와 빅데이터 등 훨씬 더 많은 데이터를 좀 더 효율적이고 빠르게 처리하기 위해 탄생한 데이터베이스 방식이라고 할 수 있습니다. (관계형 데이터베이스로 처리하게 될 경우, 많은 비용과 자원을 필요)
1. 관계형 데이터베이스 (SQL, RDBMS) vs 비관계형 데이터베이스 (NoSQL)
먼저 NoSQL 대비 SQL 의 가장 큰 차이점은 관계형 데이터베이스 구조 입니다.
관계형 데이터베이스는 행 (로우, Row / 튜플, Tuple / 레코드, Record) 과 열 (컬럼, Column / 속성, Attribute / 필드, Field) 로 구성된 하나 이상의 테이블 (관계, Relation) 에 데이터를 저장하며 필요에 따라 다른 테이블과도 관계를 맺습니다. 관계형 데이터베이스의 구조를 요약하면 다음과 같습니다.
| 관계형 데이터베이스 (RDBMS) 테이블 예제
– 각 열 은 한 가지의 데이터 유형을 정의 (예> 정수형, 실수형, 문자열, 날짜 등) 단, 중복 불가
– 각 행에는 고유의 키 (Primary Key) 가 있고, 이를 바탕으로 각 행을 구분 가능 (예> 학생의 학번)
– 하나의 행 전체를 객체, 즉 엔티티 (Entity) 라고 함 (예> 홍길동 학생을 나타내는 모든 정보들의 모음)
– 테이블은 여러 엔티티의 집합으로 이루어짐
– 테이블에서 각 열의 집합, 즉 데이터베이스의 논리적 설계를 스키마 (Scheme) 라고 함
2. 비관계형 데이터베이스 (NoSQL) 의 3가지 방식
비관계형 데이터베이스 (NoSQL) 에서는 위에서 설명한 SQL 방식과 같이 반드시 테이블의 형태에 데이터를 저장하지 않습니다. 비관계형 데이터베이스에서는 데이터를 저장하기 위한 여러가지 방법들 중 아래와 같이 크게 3가지의 방법이 주로 사용되고 있습니다.
(1) 키-값 스토어 (Key-value Store / 예> Oracle NoSQL, Redis, Amazon Dynamo)
키-값 데이터베이스 방식은 NoSQL 데이터베이스 방식들 중 가장 간단한 방식입니다. 예를 들어, 키-값 데이터베이스는 정수형, 문자열, 배열 등으로 이루어진 각 값들이 각각의 별도 키로 참조 또는 매핑 되는 구조를 갖습니다.
| [Key] | [Value] | |
| City | -> | New York City |
| State | -> | New York |
| Country | -> | United States |
이러한 구조의 간단함 덕분에 키에 참조된 값들을 읽는데 비교적 빠른 속도를 보장할 수 있습니다. 특히, 위의 예제와 같이 관계가 필요 없는 단순한 구조의 데이터를 읽고 쓰는 작업을 할 때 스토리지/디스크에서의 작업 대신 캐싱을 이용하면 더욱 빠른 속도로 작업이 가능해집니다.
예를 들어, 어떤 온라인 쇼핑몰에서 A 라는 사용자는 B 사용자와는 서로 다른 구매 활동들을 한다고 가정해보겠습니다, 이 때 각 사용자들의 장바구니에 담는 작업은 대부분 영구적인 작업이 아닐 수 있으며, 장바구니에 담는 작업을 캐싱을 기반으로 처리할 경우 관계형 데이터베이스 처리 방식에 비해 더 빠르고 효율적일 수 있습니다. (예> 인메모리 기반 NoSQL 데이터베이스를 활용)
단, 키-값 데이터베이스는 CRUD (Create, Read, Update, Delete) 작업과 같이 조금 더 복잡한 작업을 수행하는데는 한계가 있을 수 있습니다. 또한, 데이터의 크기가 증가함에 따라 특정 키-값 을 유지하는 것 또한 어려울 수 있습니다.
(2) 문서 지향 스토어 (Document-Based Store / 예> MongoDB, Couchbase)
위에서 설명한 여러개의 키-값들이 하나의 문서에 저장되는 방식입니다. 즉, 문서 (Document) 형태 (예> JSON, XML, YAML 등) 를 사용하는 데이터베이스로, 복잡한 데이터 구조 또는 계층 관계를 하나의 행 (Row) 에 저장 및 표현할 수 있습니다. 문서 지향 스토어에서 사용되는 DBMS 중 가장 유명한 MongoDB 는 JSON 을 사용하며 사용 예제는 다음과 같습니다.
1 {
2 "stu_id":20201234,
3 "subject":"Database",
4 "score":100,
5 "stu_name":"Steven"
6 }위와 같이 하나의 문서 안에서 ‘키 : 값’ 구조로 저장할 수 있으며, 여러 문서들의 묶음인 컬렉션 (Collection) 에서 서로 다른 문서들은 꼭 위와 서로 같은 공통된/고정된 형태의 스키마 (Scheme) 를 가지지 않아도 됩니다.
– 컬렉션 (Collection) 이란?
여러 문서들의 모음입니다. 컬렉션은 고정된 스키마를 정의하고 있지 않습니다. 따라서 하나의 컬렉션에 존재하는 문서들은 모두 다른 구조의 키-값들을 가질 수 있습니다. 컬렉션에서 여러 다른 스키마를 가지는 문서들을 저장하여 구분하는 이유는, 비슷한 성격의 데이터들을 모아서 더 빠른 처리를 할 수 있기 때문입니다.
예를 들어, 데이터베이스 안에 ‘학교’ 라는 문서 뿐 만 아니라 개인과 관련된 문서들이 함께 저장된다면 입/출력을 처리하는 것이 쉽지 않으며 데이터베이스의 성능이 떨어질 수 있습니다. 그러나 비슷한 종류의 데이터들을 함께 모아 놓으면 높은 효율의 입/출력이 가능해지며 이에 따라 데이터베이스의 성능을 개선할 수 있습니다. 또한 스키마의 변경이 필요할 때, 컬렉션 내에 있는 모든 문서들의 스키마에 대해 공통적으로 변경을 적용하지 않고도 일부만 변경 처리가 가능한 유연성을 가집니다.
– 서브컬렉션 (Sub-Collection) 이란?
예를 들어, 관계형 데이터베이스와 같이 문서 지향 스토어 에서도 같은 ‘학교’ 라는 속성에서 ‘선생님’ 과 ‘학생’이라는 서브컬렉션을 만들 수 있습니다. (예> school.teacher, school.student) 단, 이 때 ‘선생님’ 과 ‘학생’ 서브컬렉션들 사이에서는 아무런 관계가 정의되지 않습니다.
(3) 컬럼 지향 스토어 (Column-based Store / 예> Google’s Bigtable, Cassandra, HBase, Amazon Redshift)
관계형 데이터베이스와 같이 행 (튜플) 에 중점을 두는 것이 아닌 열 (속성) 에 중점을 둔 데이터베이스 시스템입니다. 따라서 컬럼 지향 형태의 데이터베이스 에서는 비슷한 속성 값, 즉 같은 특성을 가진 대량의 데이터를 계산해야 하는 데이터 웨어하우스 (Data Warehouse) 등에 적합합니다.
아래와 같이 연봉 정보가 포함된 테이블이 있다고 가정해보겠습니다.
| 사번 | 이름 | 직급 | 연봉 |
| 1 | Steven | 전무 | 10000 |
| 2 | John | 부장 | 7000 |
| 3 | Mike | 대리 | 5000 |
위와 같은 테이블은 관계형 데이터베이스와 큰 차이가 없어 보일 수 있습니다. 그러나 아래와 같이 탐색되는 방법은 다르다고 볼 수 있습니다.
먼저 다음과 같이 행 기준으로 데이터를 가져오는 기존의 관계형 데이터베이스의 읽기 방식입니다.
[1] 1, Steven, 전무, 10000; 2, John, 부장, 7000; ...이와 같이 하나의 행에 있는 모든 정보를 가져온 뒤, 필요한 데이터를 처리 (쿼리) 할 수 있을 것입니다. 그러나 컬럼 지향 방식은 다음과 같은 처리가 가능합니다. (같은 속성들의 모임 – 키스페이스 (Keyspace) 로 구성)
[1] 1,2,3; Steven, John, Mike; 전무, 부장, 대리; 10000, 7000, 5000; ...만약, 모든 직원들의 연봉 합계를 구하는 계산이 필요할 경우, 기존의 관계형 데이터베이스 에서는 일단 모든 행을 읽은 다음 별도의 연봉 정보를 따로 불러와서 계산을 해야 했겠지만 컬럼 지향 방식에서는 연봉 컬럼의 정보들만 불러와서 계산이 가능해집니다.
즉, 컬럼 지향 방식은 같은 속성 (유형) 의 데이터만 처리가 가능하므로 높은 압축률로 처리할 수 있는 장점이 있습니다.
3. NoSQL 의 장점과 단점 – SQL 과의 비교
(1) 장점
– 유연성
관리하기가 쉬우며 새로운 데이터 모델에 적용하기가 수월합니다. 따라서, NoSQL 은 조직의 다양하고 세부적인 데이터 처리 요구사항에도 쉽게 대응할 수 있습니다.
– 높은 확장성과 저비용
많은 NoSQL 관련 DBMS 들이 오픈소스로 개발되어 있고, 개발되고 있습니다. 따라서 저렴하게 이용 가능한 장점이 있으며, 특히 비용 관점에서의 진입 장벽이 낮으므로 많은 소규모 기업들 (예> 스타트업) 이 이용하고 있습니다. 특히 MongoDB, Amazon Dynamo 등을 이용하여 비교적 저렴한 비용으로 빅데이터 처리를 할 수 있습니다. 아울러 SQL 은 별도의 서버 및 스토리지 시스템에 설치되기 때문에, 트랜잭션 당 비용 또는 처리 GB 당 비용 청구 방식의 NoSQL 이 더 저렴할 수 있습니다.
추가로, NoSQL 데이터베이스는 여러대의 서버에 로드를 분산하는 방식이 구현 가능하므로, 좀 더 유연한 스케일업/스케일 아웃이 가능합니다. 그러나 기존의 데이터베이스에서는 더 많은 데이터베이스의 워크로드를 처리하기 위해서 성능이 더 높은 서버들을 구매하여 스케일 업하는 방식에 의존해야 했습니다.
(2) 단점
– 표준화된 리소스, 다양한 지원의 부족
NoSQL 은 SQL 과 달리 표준화된 구조 질의 언어 (SQL – Structured Query Language) 를 가지고 있지 않습니다. 이는 NoSQL 로의 마이그레이션 (Migration) 을 비교적 어렵게 하는 요소가 될 수 있습니다. 특히 이 때문에, NoSQL 전문가가 많지 않으며 대부분은 공식 지원 센터와 같은 곳에서 지원을 받는 것 보다 일반 커뮤니티 등을 통해 지원을 받아야 하는 경우가 많습니다.
– 분석, 그리고 비즈니스 인텔리전스
SQL 은 여전히 비즈니스 인텔리전스를 위한 범용 툴로 사용되고 있습니다. 그러나 NoSQL 에서는 분석이나 비즈니스 인텔리전스 등의 목적을 위한 툴은 부족한 상태입니다.
(3) 기타
SQL 기반의 데이터베이스는 ACID (원자성(Atomicity), 일관성(Consistency,) 독립성(Isolation), 지속성(Durability)) 의 속성을 강조합니다. 그에 반해 NoSQL 은 BASE (가용성(Basically Available), 독립성(Soft-State), 일관성(Eventual Consistency)) 의 속성을 강조합니다. 요약하여, NoSQL 은 가용성과 성능을 중시한 분산시스템에 더욱 무게를 두고 있습니다.
| 항목 | BASE | ACID |
|---|---|---|
| 적용대상 | NoSQL | RDBMS |
| 범위 | 시스템 전체 대상 | 개별 트랜잭션 적용 |
| 일관성 | 약한 일관성 | 강한 일관성 |
| 중점사항 | 성능과 가용성 | 무결성, 일관성 |
| 관리주체 | 주로 개발자 | DBMS 트랜잭션 |
| 데이터처리 | 유사 응답 허용 | 처리 순서 보장 |
| 변경성 | 변경 어려움 | 변경 용이 |
| 디자인 | 쿼리 디자인 중요 | 테이블 디자인 중요 |
| CAP이론 | C+P, A+P 만족 | C+A 만족 |
| 적용사례 | Big Table | Oracle RAC |
** CAP 이론 (브루어의 정리)
SQL 과 NoSQL 은 모두 CAP 이론을 기반합니다. CAP 이론이란 일관성 (Consistency), 가용성 (Availability), 분할 내성 (생존성, Partition Tolerance) 3가지를 모두 동시에 만족시킬 수 없다는 이론입니다. 따라서 이러한 이론과 네트워크 환경을 고려하여, 적절한 아키텍처와 계획을 구성하는 것이 중요합니다.
– 일관성 (Consistency) : 모든 노드들은 같은 시간에 같은 항목에 대해 똑같은 내용의 데이터를 사용자에게 보여주는 것을 보장한다는 의미입니다. 예를 들어, 지구 반대편에서 은행 계좌에 트랜잭션이 일어나도 잔액은 지구 어디에서나 동일하게 보여주어야 한다는 성질입니다.
– 가용성 (Availability) : 모든 사용자들이 정상적으로 읽기 및 쓰기가 가능해야 하며, 일부 노드들의 장애가 발생하더라도 다른 노드에 영향을 미쳐서는 안된다는 것을 의미합니다.
– 분할 내성 (생존성, Partition Tolerance) : 메세지 전달이 실패하거나 시스템의 일부가 망가져도, 전체 시스템은 계속 동작할 수 있어야 한다는 성질입니다.
위와 같은 CAP 이론 모델을 참조하여 구성할 수 있는 모델을 다시 요약하면 다음과 같습니다.
| 분류 | 설명 | 예시 |
|---|---|---|
| C+A | 메시지 손실을 방지하는 강한 신뢰형 | RDBMS (Oracle 등) |
| C+P | 데이터 보다는 성능이 중요한 퍼포먼스형 | Big Table, MongoDB |
| A+P | 일관성을 크게 요하지 않는 서비스에 적합 | CouchDB, Cassandra |
#Steven