언제 NoSQL을 사용하는게 좋을까?

하루히즘·2022년 1월 24일

서론

MySQL, MariaDB 같은 RDBMS만 써보다가 Redis, MongoDB 같은 NoSQL도 알게 된 이후로 언제 두 종류의 데이터베이스를 적절히 사용해야 하는지 평소에도 궁금했었다.

흔히 들을 수 있는 얘기는 정규화된 고정된 형태(스키마)의 데이터를 저장할 때는 관계형 데이터베이스가 맞지만 형태가 일정치 않은 데이터를 저장할 때는 NoSQL 데이터베이스를 활용하는 것이다. 거기다가 빠른 입출력 처리나 캐싱 기능에도 활용할 수 있으며 스키마가 정해지기 전까지는 NoSQL을 주 데이터베이스로 사용하는 것도 좋다는 의견이 있다.

실제로 활용 사례를 경험하기 전까지는 어떤 상황에 어떤 데이터베이스를 사용해야 할 지 결정하기 까다롭지만 조사해본 내용을 정리해보고자 한다.

본론

NoSQL의 등장 배경

진부하게 나오는 얘기지만 NoSQL은 결국 기존 SQL의 단점을 타파하고자 등장한 데이터베이스의 종류다. 빠르게 성장하고 다양한 형태로 변화하는 거대한 데이터를 다룰 수 있는 역량이 요구되기 시작하면서 기존에 정해진 형태(스키마)로만 데이터를 다룰 수 있는 SQL과 달리 자유로운 형태로 데이터를 저장할 수 있는 NoSQL이 각광받게 된 것이다.

NoSQL의 종류

NoSQL은 특정 데이터베이스 제품군을 의미하는게 아니라 기존 SQL의 대체제인 모든 제품을 통칭하는 단어다. 어쨌든 레코드를 특정 키로 조회하기 때문에 데이터의 어떤 속성을 키로 사용할 지는 차치하고 어떻게 데이터를 저장할 지를 고려해 볼 수 있는데 다음과 같은 4가지가 있다.

Document

데이터를 JSON, XML 같은 형태로 저장하는 문서형 데이터베이스. 데이터 뿐 아니라 데이터베이스가 읽을 수 있는 메타 정보도 담을 수 있으며 애플리케이션에서 객체를 다루는 것처럼 접근할 수 있어 범용 목적으로 적합하다. 요구사항에 따라 쉽게 구조를 변경할 수 있고 스케일-아웃에 적합하다.

Key-Value

가장 단순한 형태로 특정 키의 값에 레코드가 저장되는 형식. 기존 RDBMS에서 PK와 단 하나의 컬럼만 갖는 테이블에 비교할 수 있다. 대표적으로 Redis가 있다.

정말 단순한 구조기 때문에 대용량의 데이터라도 빠르게 조회할 수 있다는 장점이 있다. 값에 JSON 문서가 들어가면 문서형 데이터베이스와 무슨 차이인가 싶지만 문서형 데이터베이스에서는 데이터의 메타 정보를 활용할 수 있는 것과 달리 키-값 저장소에서는 단순히 키로 조회하고 쓰는 기능만 지원한다.

Column

테이블로 구성된 데이터베이스. RDBMS가 행(row)을 기준으로 레코드를 다뤘다면 컬럼형 데이터베이스에서는 열(column)을 기준으로 레코드를 다루는 방식이다. 대신 어떤 레코드가 어떤 열 값을 가질지 제약이 없으며 다른 레코드에는 없는 열 값을 가지거나 가지지 않을 수도 있다.

쿼리를 이용하여 레코드들의 특정 컬럼값에 대한 통계를 제공하는등 aggregation 기능에 강력하다.

Graph

그래프 자료구조처럼 데이터(상품의 이름, 가격 등)를 노드로 두고 이들이 어떻게 연결되어있는지 그 연관관계를 간선으로 나타내는 데 초점을 맞춘 데이터베이스. RDBMS에서는 데이터 간 연관관계를 별도의 데이터로 나타내야 했지만 그래프 데이터베이스에서는 이를 직접 저장한다.

데이터 간 연관관계를 파악할 때 JOIN이 필요없기 때문에 좀 더 수월하게 파악할 수 있다는 장점이 있다.

언제 사용할 것인가?

크게 다음과 같은 상황에서 NoSQL을 사용하는 것을 고려해 볼 수 있다.

스키마에 얽매이지 않고 다양한 형태(structured, semi-structured, unstructured)의 데이터를 다뤄야 할 때

SQL에서는 현실 세계의 데이터가 어떻든 간에 데이터베이스 제품군에 맞는 형식으로 변환하여 미리 고정된 자료구조(스키마)에 맞춰 삽입하고 조회해야 한다. NoSQL은 이런 고정된 자료구조에서 벗어나서 자료구조를 원하는 대로 정의할 수 있기 때문에 데이터를 데이터베이스 대신 애플리케이션에 좀 더 가깝게 다룰 수 있다.

예를 들어 RDBMS에서는 컬럼값이 배열을 가질 수 없다. 하지만 문서형 데이터베이스에서는 JSON으로 데이터를 표현하여 배열을 포함한 복잡한 자료구조를 표현할 수 있고 이를 애플리케이션에서 JSON 파서 등으로 읽어서 좀 더 간편하게 다룰 수 있다. 비슷하게 새로 삽입된 데이터가 이전에 삽입된 데이터와 같은 컬럼(또는 키)을 가질 필요가 없기 때문에 좀 더 유연하게 데이터를 다룰 수 있다.

이런 유연성은 요구사항이 자주 변하는 애자일 애플리케이션 개발 방식에도 적합하다는 의견이 있다.

스케일-아웃을 통해 SQL보다 더 많은 데이터를 빠르게 처리해야 할 때(빅 데이터 vs 웹 애플리케이션 수준)

더 많은 데이터를 빠르게 처리한다는 것은 스케일-아웃과 연관된 특징이라 할 수 있다. RDBMS에서는 PK, FK를 이용한 JOIN 연관관계로 데이터를 구성하기 때문에 참조관계 등 일관성 보장 측면에서 확장이 자유롭지 않다. 그러나 NoSQL의 레코드는 그런 연관관계가 없는 독립적인 레코드기 때문에 확장(스케일-아웃)에 수월하여 유동적으로 서버를 확장하거나 축소하는 클라우드 환경에 적합하다는 것이다.

별다른 연관관계가 없다는 것은 단순히 키(PK)만으로 모든 데이터를 조회할 수 있다는 것을 의미하기 때문에 당연히 RDBMS보다 데이터를 빠르게 조회할 수 있다.

하지만 이건 연관관계가 필요한 경우에는 까다로워질 수 있다. 예를 들어 어떤 레코드가 어떤 속성을 가졌는지는 빠르게 파악할 수 있지만 반대로 어떤 속성을 가진 레코드들을 필터링(검색)하는 경우에는 적합하지 않다는 것이다(불가능한 것은 아니다. NoSQL에서도 쿼리를 사용 가능).

ACID 대신 BASE

모든 RDBMS가 ACID를 보장하는 것과 달리 NoSQL은 몇몇 제품이 지원하긴 하지만 대개 ACID를 보장하기 보다는 BASE 원칙을 따르는 것이 대부분이다. ACID 원칙이 Atomic, Consistency, Isolation, Durability 4가지 종류였다면 BASE는 다음과 같은 3가지 원칙으로 이루어져 있다.

Basically Available

기본적으로 가용하다는 원칙으로 데이터베이스 서버에 장애가 발생해도 백업 서버 등으로 가용성을 유지해야 한다는 원칙이다.

Soft State

데이터베이스의 데이터는 애플리케이션과 직접 상호작용하지 않아도 일관성을 맞추면서 변경될 수 있다는 원칙이다. 이게 무슨 말이냐면 확장된 다른 데이터베이스에서 일어난 변경 사항을 현재 데이터베이스에도 자동으로 반영하여 최종적인 일관성(eventual consistency)을 보장한다는 것이다.

Eventual Consistency

일관성이 즉시 유지되는 RDBMS의 immediate consistency 와는 달리 최종적인 일관성을 유지해야 한다는 원칙이다. 위의 Soft State와 비슷하게 현재 데이터베이스의 데이터에 변형(추가, 삭제 등)이 일어나면 그 시점에는 현재 데이터베이스와 분산된 다른 데이터베이스간 데이터가 일치하지 않기 때문에 일관성이 보장되지 않는다.

그러나 최종적으로는 복제(replication) 과정을 거치면서 모든 데이터베이스들이 동일한 데이터를 갖는 일관성을 보장하게 된다. 이 과정은 매우 빠르게 수행되지만 만약 필요하다면 ACID 처럼 일관성을 보장하는 옵션을 제공하는 제품군도 있다.

전반적으로 BASE 원칙은 정확도(consistency)를 희생하는 대신 속도와 확장성(스케일-아웃)이 뛰어나다는 NoSQL의 특징을 고려한 내용으로 RDBMS의 ACID와는 차이가 있는 것을 볼 수 있다.

결론

트랜잭션을 지원하지 않는다던지 ACID를 보장하지 않는다던지 등 기존에 NoSQL의 단점이라 알려진 부분에 대해 오해를 풀기 위한 MongoDB의 Everything You Know About MongoDB is Wrong! 라는 포스트가 있다.

삼성 SDS에서도 ScyllaDB에 대해서 다룬 포스트가 있는데 중반부에서 NoSQL 데이터베이스 간 비교 테이블이 있기 때문에 한 번 읽어보는 것을 권한다.

NoSQL 중 Document NoSQL에 해당하는 MongoDB와 SQL 중 PostgreSQL을 비교하는 포스트도 있다. 이것 역시 읽어볼 만한 글이다.

현대 인터넷 환경의 요구사항에 부응하여 등장한 데이터베이스인 만큼 많이 활용되고 있지만 어떤 단점이 있는지, 어떤 형태의 데이터베이스를 어떤 제품으로 어떤 상황에 사용할 수 있을지는 아직 감이 잡히지 않는다. 직접 다양한 종류의 데이터베이스를 써보고 어떤 식으로 다루는지 감을 잡아가야 할 것이다.