Offcanvas

개발자 / 서버

클라우드 스케일!··· SQL과의 비교로 알아본 NoSQL

2022.06.28 Serdar Yegulalp  |  InfoWorld
SQL 데이터베이스는 일관성과 신뢰도를 보장하기 위해 데이터 유형에 제약을 부여한다. NoSQL은 이러한 제약을 없애 속도, 유연성 및 확장성을 선사한다. 
 
ⓒAdobe Stock Image

응용 프로그램을 개발할 때  흔한 고민은 데이터를 저장하기 위한 데이터베이스의 종류를 고르는 것이다. 가장 대표적으로 SQL과 NoSQL이 있다. 기존 SQL 데이터베이스(즉, 쿼리에 SQL을 사용하는 관계형 데이터베이스)는 수십 년간의 기술 진화, 모범 사례 및 테스트의 산물이다. 안정적인 트랜잭션 및 여러 현업 애플리케이션을 잇는 애드혹 쿼리에 적합하도록 설계돼 있다. 그러나 엄격한 스키마와 같은 한계로 인해 애플리케이션에 따라 적합하지 않기도 하다.

이러한 한계에 대안으로 나온 것이 NoSQL 데이터베이스다. NoSQL 시스템을 사용하면 개발자는 빠르고 유연성 있게 데이터를 저장하고 관리할 수 있다. 대부분의 NoSQL 데이터베이스는 구글, 아마존, 야후, 페이스북과 같은 대기업이 방대한 양의 콘텐츠를 저장하고 데이터를 처리하고자 개발했다. SQL 데이터베이스와 달리 NoSQL 데이터베이스는 수백 또는 수천 대의 서버로 스케일업 될 수 있다. 

그러나 NoSQL에도 단점은 있다. SQL 데이터베이스가 검증된 ACID(Atomicity, Consistency, Isolation, Durability) 속성을 기반으로 트랜잭션의 안정성을 확보하는 데 중점을 두는 데 반해, NoSQL 시스템은 속도와 확장성을 우선시한다. 여기에 더해 수십 년 동안 축적된 SQL의 도메인 지식에 비하면 NoSQL 시스템의 프로그래밍 메타포(programming metaphor)는 생소하게 느껴질 가능성이 높다. 

결과적으로 SQL과 NoSQL 데이터베이스는 서로 다른 장단점을 지닌다. 특정 프로젝트를 선택할 때는 양자택일이 불가피하지만, 큰 틀에서 보면 상호 보완적이기도 하다. 각각 다른 용도에 적합하며, 어느 하나가 다른 하나보다 절대적으로 우월하다고 할 수 없다.  대신 어떤 도구를 어떤 용도에 쓸 것이냐가 핵심이다.
SQL과 NoSQL의 근본적인 차이는 그리 복잡하지 않다. 데이터를 저장하고 및 검색하는 방법이 다를 뿐이다. 

SQL 데이터베이스에서는 모든 데이터가 고유한 구조를 가진다. 마이크로소프트 SQL 서버(Microsoft SQL Server), 마이SQL(MySQL), 포스트그레(Postgre)와 같은 SQL 데이터베이스나 오라클 데이터베이스(Oracle Database)는 스키마를 사용한다. 스키마란 데이터베이스의 구조와 제약조건에 관해 전반적인 명세를 기술한 것이다.

예를 들어 테이블의 특정 열을 정수로만 제한하여 열에 기록된 데이터의 정규화 정도를 높이는 용도로 활용된다. 엄격한 기준을 적용하는 스키마 덕에 데이터를 더 쉽게 집계할 수도 있다. 예를 들어 SQL JOIN 명령만 실행하면 두 테이블의 데이터를 결합하여 원하는 데이터가 한 번에 집계된다.  

반면 NoSQL에서는 데이터가 ’스키마 없는’ 즉, ’자유 형식’ 방식으로 저장된다. 모든 데이터를 어떤 방식으로도 저장할 수 있다. NoSQL 데이터베이스에 데이터를 저장하는 데는 네 가지 일반적인 모델이 있으며, 이는 4가지 유형의 NoSQL 시스템으로 이어진다:

1. 문서 데이터베이스(예: 몽고DB(MongoDB)) 
입력된 데이터는 스키마가 없는 JSON 구조 또는 ’문서’의 형태로 저장된다. 여기서 데이터는 정수에서 문자열, 자유 형식 텍스트에 이르기까지 모든 형식이 될 수 있다. JSON 문서에 포함할 필드의 데이터를 규정할 필요는 없다.

2. 키 밸류 저장소(Key-value store) (예: 레디스(Redis))
간단한 정수나 문자열에서 복잡한 JSON 문서에 이르기까지, 다양한 형식의 값을 문자열과 같은 키를 통해 데이터베이스에서 자유롭게 접근할 수 있다. 

3. 와이드 칼럼 스토어(Wide column stores) (예: Cassandra(카산드라)) 
여기서 데이터는 기존 SQL 시스템의 행과 달리 열에 저장된다. 이 덕분에 쿼리 또는 데이터 뷰가 필요할 때 원하는 수의 열(따라서 다양한 유형의 데이터)을 그룹화하거나 집계할 수 있다.

4. 그래프 데이터베이스(예: Neo4j) 
그래프 데이터베이스에서 데이터는 엔터티와 그 관계의 네트워크 또는 그래프로 구성된다. 그래프의 각 노드는 자유 형식의 데이터 청크(free-form chunk of data)로 표현된다. 

스키마가 없는 NoSQL 데이터베이스는 다음과 같은 경우에 유용하다. 

• 데이터에 빠른 접근을 원하며, 안정적인 트랜잭션이나 일관성보다 접근 속도와 단순성이 더 중요하다.   
• 대량의 데이터를 저장하고 있으며, 나중에 스키마를 변경하는 것은 느리고 힘들 수 있어 스키마에 제약받고 싶지 않다.   
• 한 개 이상의 소스에서 비정형 데이터를 가져올 수 있도록 유연성을 극대화하기 위해 데이터를 원래 형태로 유지하고 싶다.   
• 데이터를 계층 구조로 저장하려고 하지만 외부 스키마가 아닌 데이터 자체로 계층을 구성하고 싶다. NoSQL은 데이터를 쉽게 자기 참조(self-referencing)할 수 있게 해준다. 이는 SQL 데이터베이스가 흉내내기 어려운 특성이다. 

NoSQL, ‘제각각’의 쿼리 방식
관계형 데이터베이스에서 사용되는 SQL은 데이터를 저장하고 검색하기 위해 서버와 통신하는 일정한 방식이라고 할 수 있다. SQL 구문은 고도로 표준화되어 있다. 따라서 개별 데이터베이스가 특정 작업(예: 창 기능(window functions)을 다르게 처리할 때도 있지만, 기본적으로 SQL 구문은 모두 동일하게 사용할 수 있다. 

반면, NoSQL 데이터베이스는 데이터를 쿼리하고 관리하는 용도로 각기 다른 구문을 쓴다. 예를 들어, 카우치DB(CouchDB)는 HTTP를 통해 전송되는 JSON 형태의 쿼리를 사용하여 데이터베이스에서 문서를 만들거나 검색한다. 몽고DB는 CLI 인터페이스나 언어 라이브러리에서 바이너리 프로토콜을 통해 JSON 객체를 전송한다.

SQL과 유사한 구문을 사용하여 데이터를 처리하는 일부 NoSQL 제품이 있기는 하다. 하지만 제한적이다. 예를 들어 와이드 칼럼 스토어 유형의 아파치 카산드라 (Apache Cassandra)는 자체 SQL과 유사한 카산드라 쿼리 언어(Cassandra Query Language, CQL)를 사용한다. ‘SELECT’ 또는 ‘INSERT’ 키워드와 같은 몇몇 CQL 구문을 SQL 플레이북에서 바로 사용할 수 있다. 그러나 카산드라에서 네이티브 방식으로 ‘JOIN’ 또는 하위 쿼리를 수행할 방법은 없다. 이러한 구문은 CQL에 존재하지 않는다. 

비공유 아키텍처(shared-nothing architecture)
NoSQL 시스템에서 공통적으로 쓰이는 구조는 ’비공유(shared-nothing)’ 아키텍처다. 비공유 아키텍처에서 클러스터의 각 서버 노드는 다른 모든 노드와 독립적으로 작동한다. 시스템은 클라이언트에 데이터를 반환하기 위해 다른 노드의 합의를 얻을 필요가 없다. 쿼리가 가장 가깝거나 편리한 노드에 반환되므로 아주 빠르게 실행된다. 

비공유 시스템의 또 다른 장점은 복원력과 스케일아웃 확장력이다. 클러스터를 스케일 아웃하고 싶다면 클러스터의 새 노드를 스핀업하고 다른 노드와 동기화할 때까지 기다리기만 하면 된다. 한 NoSQL 노드의 작동이 중단되더라도, 클러스터의 다른 서버는 계속 작동한다. 쿼리를 처리하는 노드가 적어지더라도 모든 데이터는 사용 가능한 상태로 유지된다.

비공유 아키텍처는 NoSQL 데이터베이스에만 국한되지 않는다.  일부 SQL 시스템도 마이SQL(MySQL)과 같은 비공유 방식으로 설정할 수 있다. 다만, 성능 개선의 대가로 클러스터 전체의 일관성이 하락되는 것은 감수해야한다. 

NoSQL의 한계 
NoSQL이 그렇게 많은 자유와 유연성을 제공한다면 왜 아직 SQL이 널리 쓰일까? 여전히 많은 애플리케이션이 SQL 데이터베이스가 제공하는 제약 조건, 일관성 및 안전성을 필요로 하기 때문이다. 이러한 경우, NoSQL의 몇몇 장점은 단점이 된다. NoSQL 시스템에서는 SQL 사용자가 당연하게 여기는 몇몇 기능이 없다는 점이 특히 두드러지는 단점이다.  

한계 1: 스키마의 부재 
자유형식의 데이터를 가져오더라도, 이를 활용하려면 거의 항상 데이터에 제약 조건을 적용해야 한다. 그러나 NoSQL에서 제약 조건을 부과한다는 것은 데이터 처리 업무를 데이터베이스가 아닌 애플리케이션 개발자에게 떠넘기는 것과 같다. 예를 들어 개발자는 객체 관계형 매핑 시스템이나 ORM으로 데이터를 구조화할 수 있다. 그러나 스키마가 데이터 자체에 적용되기를 원한다면 NoSQL은 통상적으로 이를 지원하지 않는다.

데이터에 대한 선택적 데이터 타이핑 및 유효성 검사 메커니즘을 제공하는 NoSQL 솔루션이 있기는 하다. 예를 들어 아파치 카산드라는 기존 SQL과 비슷한 여러 네이티브 데이터 유형을 제공한다. 

한계 2: ACID의 부재, 그러나 최종 일관성(eventual consistency)이라는 대안
NoSQL 시스템을 사용한다는 것은 더 나은 가용성과 성능을 위해 강력하고 즉각적인 일관성을 희생한다는 것을 의미한다. SQL 데이터베이스는 ACID라는 약어로 총칭되는 4가지 강점을 가지고 있다. 

1. 첫째는 원자성(Atomicity)이다. 트랜잭션이 분해가 불가능한 최소의 단위인 하나의 원자처럼 동작한다는 의미다. 따라서 트랜잭션이 모두 성공하거나, 아니면 모두 실패한다. 원자성 덕분에 데이터베이스의 부분적인 갱신이 더 큰 문제로 번지는 사태를 방지한다.  

2. 둘째는 일관성(Consistency)이다. 모든 사용자가 동일한 데이터 뷰를 이용할 수 있다. 

3. 세번째는 고립성(Isolation)이다. 트랜잭션이 서로 격리되어 서로 간섭하지 않는다. 

4. 마지막 4번째는 Durability(내구성)이다. 트랜잭션이 완료되기만 하면, 서버상에 장애가 생겨도 결과 값이 손실되지 않는다.  

NoSQL 시스템에서 이 4가지 ACID 특성을 다소 다르게 활용할 수 있기는 하다. 예컨대 클러스터 전체에 걸친 강한 일관성을 요구하는 대신 (이런 방식은 쿼리에 대한 응답을 지연시킨다), 최종 일관성(eventual consistency)이라는 대안이 있다. 이렇게 하면 클러스터의 다른 노드에 최신 쓰기 데이터가 복사될 때까지 기다리지 않고도 쿼리가 처리된다. 클러스터에 입력된 데이터는 ‘최종’적으로 어디에서나 사용할 수 있게 된다. 다만 접근 가능한 시점이 보장되지는 않는다. 

더불어 일관성 및 속도 간에 다양한 트레이드오프를 제공하는 몇몇 NoSQL 시스템도 있다. 예를 들어 마이크로소프트의 애저 코스모스 DB(Azure Cosmos DB)를 사용하면 쿼리당 일관성의 수준을 지정해 사용 사례에 맞는 동작을 선택할 수 있다. 트랜잭션의 모든 단계를 보장하는, ‘트랜잭션 시맨틱스’라고 불리는 방식도 있다. 이 방식은 예컨대 거래를 실행하고 재고를 감소하는 작업이 있다고 하면, 작업을 완료되거나 롤백하게 해준다. 트랜잭션 시맨틱스는 몽고DB와 같은 일부 NoSQL 시스템에서도 제공된다. 

한계 3: NoSQL의 종속 효과
대다수의 NoSQL 시스템은 개념적으로 유사하지만, 구현 방식에 차이가 있다. 시스템마다 데이터를 쿼리하고 관리하는 메타포와 메커니즘이 모두 다르다. 

이런 특성에는 부작용이 따른다. 바로 애플리케이션 로직과 데이터베이스가 결속될 가능성이 높다는 것이다. 하나의 NoSQL 시스템을 선택한 뒤 바꾸지 않는다면 이러한 결속성은 딱히 해가 될 게 없지만, 만약 시스템을 변경할 경우 큰 걸림돌이 될 수 있다.

예를 들어, 몽고DB(MongoDB)에서 카우치DB(CouchDB)로 (혹은 그 반대로)로 데이터 베이스를 마이그레이션한다고 치자. 데이터 마이그레이션 작업은 시작에 불과하다. 데이터 액세스 및 각 프로그램의 메타포 차이를 분석해야만 한다. 즉, 데이터베이스에 접근하는 응용프로그램을 일부 재개발해야 한다. 

한계 4: NoSQL 전문가에 대한 낮은 수요
NoSQL의 또 다른 단점은 상대적으로 전문가에 대한 수요가 낮다는 것이다. SQL의 인재 시장은 꽤 규모가 크지만, NoSQL 인재 시장은 아직 초기 단계에 머물러 있다. 

구체적으로, 취업정보 사이트 인디드(Indeed.com)에 따르면 2022년 기준으로 SQL 데이터베이스(MySQL, 마이크로소프트 SQL 서버, 오라클 데이터베이스 등)의 총 구직 공고 수가 몽고DB(MongoDB), 카우치베이스(Couchbase) 카산드라(Cassandra)보다 훨씬 더 높은 것으로 나타났다. NoSQL 전문가에 대한 수요는 여전히 전체 SQL 인재 시장의 일부분일 뿐이라는 점을 알 수 있다. 

SQL과 NoSQL의 공생
시간이 지날수록 SQL과 NoSQL 시스템 간의 차이는 점점 줄어들 것이다. 이미 많은 SQL 데이터베이스가 JSON 문서를 기본 데이터 유형으로 허용하며, 해당 데이터에 대해 쿼리를 수행하도록 해준다. 몇몇은 심지어 JSON 데이터에 제약 조건을 지정하는 네이티브 방법을 제공한다. 따라서 기존의 행 및 열 데이터와 동일하게 빈틈없이 처리된다.

한편 NoSQL 데이터베이스도 SQL과 유사한 쿼리 언어뿐만 아니라, SQL 데이터베이스의 다른 특징을 품어가는 추세다. 몽고DB의 ACID 속성이 대표적이다.

미래형 데이터베이스(현재 데이터베이스 시스템의 미래 버전도 포함)를 상상해보자면, 두 가지 패러다임에 모두 걸쳐 SQL과 NoSQL 기능을 함께 제공하는 시스템이 생길지도 모른다. 이렇게 된다면 파편화된 데이터베이스의 세계를 표준화하는 데 큰 도움이 될 것이다. 

그래도 당분간은 SQL 전용 시스템과 NoSQL 전용 시스템이 각자의 자리를 지킬 가능성이 높다. NoSQL으로 누릴 수 있는 설계 유연성, 수평적 확장성, 그리고 고가용성이 SQL 데이터베이스의 강력한 데이터 ‘읽기 일관성(read consistency)’ 및 여러 안전조치보다 더 중요하다면, NoSQL이 제격이다. 하지만 SQL의 여러 안전조치로 인한 혜택이 NoSQL의 각종 강점을 잊게하는 경우도 흔하다. 
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.