NoSQL에 대해 알아보자

1. 들어가며

오늘 다룰 내용은 NoSQL이다. 곧 채원쿤과 프로젝트를 시작할텐데 아마 NoSQL을 DB로 사용하게 될 것 같다. 그런 김에 관련 내용을 공부하면서 내용을 정리할까 한다.

먼저 NoSQL에 대해 간단히 알아보고, 주요 특징을 살펴본다. NoSQL은 여러 제품군을 아우르기 때문에 여러 유형으로 분류되는데 NoSQL의 유형을 분류한 뒤, SQL과의 비교를 표로 정리한 뒤 마무리한다.

2. NoSQL이란?

2.1. 배경

지난 수십년간 SQL을 사용하는 전통적인 관계형 데이터베이스(이하 “RDB”)가 데이터베이스 시장을 점령했다. 과거에는 저장해야 할 데이터의 양이 많지도 않았고, 매출 기록이나 회원 정보 기록 등 상당히 단순하고 쉽게 정형화될 수 있는 정보만을 다루었기 때문에 RDB는 괜찮은 선택이었다. 이름만 대면 알만한 유명한 IT 기업들이 저마다의 RDB 제품을 가지고 있고, 기업 입장에서 데이터베이스를 운영관리해줄 DBA도 노동시장에 많으며 고객으로서 제품 지원도 빵빵하다. 이런 환경 속에서 어떤 기업이든 정보를 저장해야 할 데이터베이스는 꼭 필요하기 때문에 RDB는 시장을 독식할 수 있었다.

그런데도 수많은 관계형 데이터베이스 제품들은 구체적인 문법은 달라도 모두 SQL을 사용하기 때문에 SQL은 관계형 데이터베이스의 대명사처럼 쓰이게 됐다.(이 포스트에서도 이제 SQL로 관계형 DB를 지칭한다)

하지만 21세기가 되면서 기업들은 기존의 정형화된 데이터뿐만 아니라 메신저 텍스트, 음성 등 반정형화, 비정형화된 데이터도 저장하고 다루어야 하는 수요가 생겼다. 또한 ‘클라우드’, 또는 ‘분산형 컴퓨팅’이 주목받기 시작했지만 SQL은 이에 적합하지 않다. 여전히 SQL은 강력하고 훌륭한 정보저장 수단이지만 다양하고 복잡해진 기업 환경과 분산형 컴퓨팅 추세에 따라 SQL의 약점이 드러난 것이다.

즉, 기존의 SQL의 아성에 대항하는 새로운 데이터베이스가 필요해졌다.

2.2. NoSQL의 등장

그래서 기존의 관계형 데이터베이스에 대한 여러 대안이 등장했는데 이를 NoSQL이라고 총칭한다. NoSQL은 단어만 보면 ‘SQL을 쓰지 않는 데이터베이스’일 것 같지만 설명할 여러 이유들 때문에 SQL을 섞어 쓰기도 한다. 그보다는 ‘Not Only SQL’이라고 해석하는 게 더 적절하다. 그리고 NoSQL은 “관계형 데이터베이스이지 않은” 모든 데이터베이스의 데이터 모델과 제품을 아우른다.

사실 데이터베이스라는 게 너무 거창한 것이 아니기 때문에 NoSQL이라는 용어가 등장하기 전부터 관계형이지 않은 데이터베이스들이 일부 쓰이고 있었다. 하지만 SQL이 너무 확고한 위치에 있어 드러나지 않았을 뿐이다. 본격적으로 NoSQL이 등장하게 된 계기는 1998년 Carlo Strozzi라는 사람이 SQL 언어를 너무 고집하지 않는 관계형 DB를 소개하면서 사용했는데 재밌게도 이 사람은 관계형 DB를 소개하면서 이 용어를 썼다.

그러다가 2009년에 Johan Oskarsson이 “분산형을 추구하는 비관계형 데이터베이스”로서의 NoSQL을 재소개하면서 NoSQL이 본격적으로 고개를 내밀기 시작한다.

2.3. NoSQL의 특징

NoSQL은 말했다시피 2차원 테이블 간의 관계로 정보를 매핑하는 SQL과는 다르다. NoSQL은 “관계형이지 않은”(여집합) DB를 아우르기 때문에 종류가 매우 다양한데 대표적으로는 연관배열을 사용하는 key-value, 기존의 행 대신 열로 데이터를 저장하는 Column-based, Json이나 XML를 데이터로 삼는 Document-oriented 등이 있다. 여러 유형에 대한 분류는 밑의 장에서 좀더 살펴본다.

일단은 데이터베이스로서의 NoSQL의 주요 특징들을 살펴보면 다음과 같다.

반정형화, 비정형화된 데이터에 적합하다.
- SQL은 테이블로 대표되는 정형화된 데이터를 저장하는 데 초점을 맞추고 있다. 그러나 빅데이터 시대 이후로는 다양한 정형화되지 않은 데이터가 뿜어져나왔고 NoSQL은 이를 저장하기에 유용하다. 데이터의 계층 구조를 표현하기 위해 데이터베이스를 트리형으로 구성할 수도 있고 추상화된 그래프로 데이터베이스를 표현할 수도 있다.

“ACID” 대신 “Eventual Consistency”를 허용한다.
- SQL의 모든 transaction은 ACID한 특성을 유지해야 한다. ACID는 Atomicity, Consistency, Isolation, Durability의 두문자어인데 각각이 의미하는 조건은 다음과 같다.
  - Atomicity: 각 transaction은 여러 질의문으로 이루어질 수도 있는데 이런 각 transaction은 “단일 단위”여야 한다.
  - Consistency: Transaction은 데이터베이스의 불변값은 그대로 둔 채 한 상태를 유효한 다른 상태로 전이해야 한다.
  - Isolation: Transaction은 때로는 거의 동시에(Concurrently) 처리될 수 있는데 이때의 결과가 각 Transaction이 순차적으로 처리될 때의 결과와 같아야 한다.
  - Durability: Transaction은 한 번 처리된 뒤로는 시스템 오류 등의 이상이 있어도 그 결과가 유지되어야 한다.(즉, 처리결과가 비휘발성의 메모리에 저장되어야 한다)
- 그러나 NoSQL은 분산형의 특성상 정보의 일관성을 유지하기가 어렵다. 수많은 머신에 데이터를 분산저장했는데 한 영역에 Update가 생길 시 그것을 실시간으로 다른 영역에 전파하는 것이 쉽지만은 않기 때문이다. 반드시 어느 정도의 전파 비용은 수반될 수밖에 없다. 그래서 NoSQL은 Consistency를 조금 타협하고 꼭 실제 최신은 아닐 수 있지만 “업데이트가 되기 전까지는” 가지고 있는 최신의 데이터를 반환한다는 “Eventual Consistency”라는 개념을 사용한다.

대용량의 데이터 저장에 더 유리하다.
- 분산형 컴퓨팅에 유리한 NoSQL의 특성상 대용량의 데이터 저장에 매우 용이하다. 클러스터 내에 머신만 추가하면 되기 때문이다.

특정 도메인의 문제해결에 뛰어나다.
- SQL은 2차원 테이블에 모든 데이터를 일괄적으로 저장한다. 하지만 NoSQL은 Key-value, Graph 등의 자료형태로 데이터를 저장하는데 이로 인해 특정 도메인에서는 고성능을 낼 수 있다. 가령 소셜 네트워크를 사업 도메인으로 하는 회사에서 인간 관계는 모두 그래프이기 때문에 그래프 데이터베이스를 사용하면 그래프에 최적화된 API를 사용할 수 있고 데이터베이스 성능도 향상시킬 수 있다.

데이터를 질의하는 API가 다양하다.
- 모든 SQL은 말 그대로 SQL을 질의언어로 사용한다. 반면 NoSQL은 유형마다, 제품마다 다양한 질의언어가 있을 수 있다. NoSQL의 질의언어를 UnQL(Unstructured Query Language)라고도 하는데 대부분 SQL에 비해 저수준으로, 복잡한 질의가 어렵다. 복잡한 질의가 필요할 때는 데이터의 구조를 마사지하거나, 여러 질의를 중첩하기도 하고 때로는 SQL의 아이디어를 차용하기도 한다.

데이터 모델이 매우 다양하다.
- Document-oriented, Graph, Key-value 등 데이터 모델이 다양하다.

nosql data models

NoSQL은 충분히 성장했고 데이터베이스로서 충분히 사용가능해 보인다. 나도 이번 프로젝트에서 사용해볼 생각이다. 그런데 기업 입장에서 NoSQL을 사용할 때에는 무작정 도입할 것이 아니라 운영과 관련된 이슈도 고려해봐야 하는데 운영관리 측면에서 NoSQL의 특징은 다음과 같이 정리해볼 수 있다.

분산형 컴퓨팅에 최적화되어 있고 확장성이 뛰어나다.
- 대부분의 NoSQL 제품이 분산형 컴퓨팅을 염두에 두고 설계되었다. 그래서 머신의 수를 늘리는 수평적 확장(Horizontal Scaling)이 매우 용이하다. 기존의 SQL이 확장이 필요할 경우 RAM, CPU 등 머신의 성능을 향상시키는 수직적 확장(Vertical Scaling)에 집중하는 것과는 대조적이다.

NoSQL은 SQL에 비해 제품 지원을 받기 어렵다.
- 아직까지 대부분의 NoSQL은 오픈소스이다. SQL은 오픈소스도 있지만 회사에서 소유 관리하는 데이터베이스도 많다. SQL을 사용할 때보다 DB 관련 전문적 지원을 받기가 어렵고 힘들 수 있다.

인력 운영 비용이 더 비싸다.
- NoSQL은 표준화가 부족해서 다양한 유형을 품고 있으며 제품마다 질의 언어도 다르다. 이 말은 NoSQL의 러닝커브가 더 급격하다는 것이고 인력을 교육해 사용하는 비용이 SQL에 비해 더 든다는 것을 의미한다.
- SQL은 구체적인 문법은 조금씩은 다를 수 있어도 단일 질의 언어를 사용하기 때문에 SQL 제품들에 대한 러닝커브도 낮고 관련 전문가 시장도 성숙해 인력 풀 자체가 훨씬 크다.

3. NoSQL의 유형

NoSQL은 워낙 다양해서 어떻게 분류하느냐에 따라 10가지의 유형도 넘게 분류해볼 수 있다. 다만 여기서는 그중 유명하고 대표적인 유형을 살펴보고 관련된 제품도 알아보기로 한다.

3.1. Column-based

기존의 SQL은 레코드라고 하는 행 단위로 데이터를 저장한다. 이뜻은 실제 메모리 내에서 레코드가 순차적으로 배열되어 있다는 것을 의미한다.

하지만 Column-based(이하 “열 기반”) 유형은 SQL이 테이블의 데이터를 행 단위로, 다시 말해 레코드 단위로 디스크 내에 연속적으로 저장하는 것과 달리 열 별로 연속적으로 저장하는 것을 특징으로 한다.

Column based NoSQL

행 대신 열로 데이터를 저장하는 것은 특정 상황에서 매우 유용할 수 있다. 가령 열이 100개쯤 되는 데이터베이스에서 어느 레코드의 특정 한 부분만을 수정해야 할 때, 기존의 데이터베이스는 필요하지 않은 모든 열을 다 질의한다. 반면 열 기반에서는 필요한 열의 데이터만 로드하면 되기 때문에 행의 수가 같을 경우 필요한 I/O 작업이 줄어든다.

또 한 열에 들어가는 데이터는 형식이 일관되기 때문에 DB 내의 한 블록은 동일한 유형의 데이터를 보유하게 된다. 이때 블록 데이터에는 데이터의 유형에 맞게 압축 인코딩을 적용하여 디스크 공간을 절약하는 성능을 낼 수도 있다.

대표적인 제품으로는 AWS Redshift, Accumulo, Cassandra 등이 있다. 이중 Cassandra는 페이스북이 사용하고 있어 더 알려졌다.

3.2. Document-oriented

Document-oriented(이하 “문서 지향”) 유형은 “문서”라는 핵심 개념을 정의한다. 문서 지향 유형은 문서를 포장되고(encapsulated) 인코드된 데이터로 이해한다. 이때 데이터에 적용가능한 인코딩은 XML, YAML 등이 있는데 요즘은 JSON 인코딩이 자주 사용된다. 다시 말해 사용자에게 익숙한 JSON 객체로 문서(레코드)를 구성하는데 이들은 데이터베이스 내에서 자신을 특정하는 unique key를 가지고 있다.

SQL에서 레코드들을 테이블로 구성하듯이, 문서 지향 유형에서도 문서들을 특정 기준으로 구성하고 분류한다. 이때 사용할 수 있는 기준으로는 아래와 같은 것들이 있다.

테이블처럼 단순 집합(Collection)
태그
문서에 대한 메타데이터
디렉토리 계층 구조

문서 지향에서는 테이블을 구성하는 기준이 다양하기에 단순한 테이블을 넘어서 다양한 구조로 데이터베이스를 구성할 수 있다는 장점이 있다. 예를 들어 어떤 회사의 조직도를 데이터베이스화하기 위해서 각 문서를 디렉토리 계층 구조로 구성해 데이터베이스를 만들 수 있다.

대표적인 제품으로는 MongoDB, IBM Domino, CouchDB 등이 있다.

3.3. Key-Value

Key-value Database

Key-value 유형은 연관배열(Associative array)을 데이터 모델로 사용한다. 연관배열은 map, dict 라는 이름의 자료구조로 주요 언어에서 제공하고 있어 우리에게도 친숙한 개념이다. 이 유형에서 데이터는 여러 Key, value 쌍을 모은 Collection(또는 테이블)으로 표현되는데 이때 키는 한 collection에서 한 번만 등장할 수 있다.

대표적인 제품으로는 Oracle NoSQL Database, Apache Ignite, Dynamo 등이 있다.

3.4. Graph

graph Database

이 세상의 모든 것은 그래프다. 소셜 네트워크도 그래프고, 회사의 조직도도 그래프고, 내 사지의 연결된 모양도 그래프다. 그래프 유형은 노드들의 관계를 표현하는 그래프를 데이터 모델로 하며 질의 언어도 노드(Node)와 에지(Edge) 등 그래프의 개념을 활용한다.

이 유형의 장점은 데이터들의 관계를 중요시해서 저장된 데이터들이 에지로 직접 연결될 수 있어 데이터 질의 시 특정 노드와 관련된 데이터를 한 번의 OP로 획득(Retrieve) 가능하다는 점이다.

대표적인 제품으로는 IBM DB2, Neo4j 등이 있다.

4. SQL과 NoSQL의 비교

이전 장에서 언급한 NoSQL의 특징을 SQL과 비교해서 표로 정리하면 다음과 같다.

특징	SQL	NoSQL
질의 언어	SQL을 사용한다.	유형마다 다양한 질의 언어를 사용한다. SQL을 부분적으로 사용하기도 한다.
데이터 모델	2차원 테이블로 데이터를 모델링함.	제품이나 유형에 따라 그래프, 연관배열 등 다양한 데이터 모델을 가질 수 있음.
ACID 속성	ACID를 기본으로 함.	ACID를 완벽히 구현하지 않고 “Eventual consistency” 개념을 도입.
확장성	보통 확장 시 수직적 확장(Scale up)	분산형의 특징으로 수평적 확장(Scale out)이 매우 용이.
API	구체적인 문법은 달라도 모든 SQL은 SQL를 API로 함.	다양한 모델에 맞게 다양한 API가 존재한다. 같은 유형에서도 제품에 따라 상이할 수 있다.
운영 관리	SQL 전문가는 시장에 풍부해 운영 비용도 상대적으로 저렴	표준화의 부족과 관련 시장이 성숙하지 않아 운영 인력 교육 등의 추가비용이 발생할 수 있음.
지원	오픈소스가 아닌 상용제품도 많아 전문적 지원이 가능	대부분 오픈소스 제품이 많아 전문적 지원을 받기 힘들다.
복잡한 질의 필요 시	SQL이 강력해 복잡한 질의도 가능하다.	질의 언어가 저수준이라 데이터 마사지, 여러 질의의 중첩 등 기교가 필요하다.
데이터의 활용	Business Intelligence 등의 활용에 강력하다.	질의 언어의 저수준성으로 데이터의 활용을 위한 복잡한 질의에 어려움이 있을 수 있고, 기존 BI 프로그램들이 NoSQL을 완벽히 지원하지 않을 수 있어 SQL에 비해 어려움이 있을 수 있다.
대표 제품	MySQL, PostgreSQL, SQLite	MongoDB, AWS Dynamo, Apache Ignite

5. 마치며

일단 포스트를 마쳤다. 사실 아쉬운 것은 내가 이 제품들을 하나라도 실제로 써보지 않아 뭔가 장님 코끼리 만지듯이 NoSQL을 이해하고 정리했다는 점이다. 내용에 아쉬운 부분이나 최악으로는 틀린 부분이 있을지도 모르겠다. 한 분이라도 지적해주면 정말 고마울 것 같은데…

이번 달 중에 실제로 한 번 써보며 어쩌면 내용을 업데이트할지도 모르겠다.

이상 포스트를 마칩니다.