개발자 / 데이터ㆍ분석 / 애플리케이션

"NoSQL을 넘어" 분산 SQL의 당위성

Andrew C. Oliver | InfoWorld 2020.07.22
처음에는 파일이 있었다. 이후 구조적 파일을 기반으로 한 탐색형 데이터베이스가 나왔다. 그 다음으로 IMS와 CODASYL에 이어 약 40년 전에 최초의 관계형 데이터베이스가 등장했다. 1980년대와 1990년대에 걸쳐 “데이터베이스”는 곧 “관계형 데이터베이스”를 의미했다. SQL이 지배했던 시기다.

이후 객체 지향 프로그래밍 언어가 인기를 끌자 객체 지향 언어와 관계형 데이터베이스 간의 “임피던스 불일치”에 대한 해결책은 데이터베이스에 객체를 매핑하는 것이라고 생각하는 사람들이 나타났다. 그 결과로 나온 것이 “객체 지향 데이터베이스”다. 객체 데이터베이스에서 재미있는 점은 많은 경우 기본적으로 일반 데이터베이스에 객체 매퍼가 내장된 형태였다는 것이다. 이와 같은 데이터베이스의 인기가 식은 후 등장한 진정한 보편적 솔루션이 바로 2010년대의 “NoSQL”이다.
 
ⓒ Getty Images Bank
 

SQL에 대한 공격

NoSQL은 같은 맥락에서 관계형 데이터베이스와 SQL을 모두 공격했다. 이 당시의 가장 큰 문제는 인터넷이 40년 된 관계형 데이터베이스 관리 시스템(RDBMS) 아키텍처의 기반 전제를 무너뜨렸다는 것이다. 이들 데이터베이스는 귀중한 디스크 공간을 절약하고 수직으로 확장되도록 만들어진 것이다. 

그런데 사용자 수가 너무 많아져서 하나의 대형 서버로는 감당할 수 없게 됐다. NoSQL 데이터베이스의 중심 개념은 조인(join)이 없고 표준 쿼리 언어도 없고(SQL 구현에는 시간이 소요되므로) 데이터 무결성도 없는 데이터베이스가 있다면, 수평 확장이 가능하고 막대한 볼륨의 데이터를 처리할 수 있다는 것이다. 이렇게 해서 수직 확장의 문제는 해결됐지만 대신 새로운 문제가 발생했다.

온라인 트랜잭션 처리 시스템(OLTP)과 함께 온라인 분석 처리 시스템(OLAP)으로 불린 또 다른 형태의 관계형 데이터베이스가 개발됐다. OLAP 데이터베이스는 관계형 구조를 지원했지만 방대한 데이터가 반환된다는 점을 전제로 쿼리를 실행했다. 1980년대와 1990년대의 기업은 여전히 배치(batch) 처리에 크게 의존했다. 또한 OLAP 시스템은 개발자와 분석가가 n차원 큐브로 데이터를 상상하고 저장할 수 있는 기능을 개발했다. 2개의 색인을 기반으로 한 2차원 배열과 조회(lookup)를 상상해 보면 기본적으로 상수 시간만큼 효율적이지만, 여기에 또 다른 차원을 추가해서 3개 이상의 요소(예를 들어 공급, 수요, 경쟁사의 수)에 대한 조회를 할 수 있다면 더 효율적으로 분석하고 예측할 수 있다. 그러나 이를 구축하는 과정은 많은 노동이 필요하고 매우 배치 지향적인 작업이다.

스케일 아웃 NoSQL과 거의 같은 시점에 그래프 데이터베이스도 등장했다. 많은 부분이 그 자체로는 “관계형”이 아니거나 정해진 이론 및 관계형 대수학을 기반으로 하지 않고 부모-자식 또는 친구의 친구 관계를 기반으로 한다. 전형적인 예가 제품군-제품 브랜드-모델-모델의 구성 요소다. “내 노트북에 있는 메인보드”가 무엇인지 알아보려고 하는 경우, 제조업체의 조달 구조가 매우 복잡해서 브랜드나 모델 번호로는 충분하지 않을 수 있다. 제품군에 사용된 메인보드를 알고자 한다면 전통적인(CTE가 아닌) SQL에서는 여러 단계로 테이블에서 쿼리를 실행해야 한다. 처음에는 대부분의 그래프 데이터베이스는 샤딩을 전혀 하지 않았다. 사실 많은 유형의 그래프 분석은 데이터를 그래프로 저장하지 않고도 수행할 수 있다.
 

NoSQL이 지킨 약속과 지키지 못한 약속

NoSQL 데이터베이스는 40년 이상 된 설계를 기반으로 하는 오라클 데이터베이스, DB2, 또는 SQL 서버에 비해 훨씬 더 잘 확장됐다. 그러나 NoSQL 데이터베이스의 각 유형에는 다음과 같은 새로운 제약이 있었다.
 
  • 키-값 저장소 : db.get(key)보다 더 간편한 조회는 없다. 그러나 세계의 데이터와 사용례 대부분은 이 방식으로 구조화할 수 없다. 또한 캐싱 전략에 대해서도 생각해야 한다. 주 키 조회는 모든 데이터베이스에서 빠르다. 중요한 것은 메모리에 무엇이 있느냐다. 최선의 경우 해시 맵처럼 확장된다. 그러나 데이터를 조합하기 위해 30개의 데이터베이스를 살펴야 하거나 복잡한 쿼리를 수행해야 한다면, 이 방법은 사용할 수 없다. 현재는 다른 데이터베이스 앞에 위치하는 캐시로 구현되는 경우가 더 많다. (예: 레디스(Redis))
 
  • 문서 데이터베이스 : 문서 데이터베이스의 인기는 JSON를 사용한다는 점과 객체를 JSON으로 직렬화하기 쉽다는 데 기인한다. 문서 데이터베이스의 첫 버전에는 조인이 없었고, 전체 “엔티티”를 하나의 거대한 문서로 만드는 데는 나름의 단점이 있었다. 트랜잭션 보장이 없었으므로 데이터 무결성 문제도 발생했다. 현재 문서 데이터베이스 일부는 비교적 약한 트랜잭션 형식을 지원하지만, 대부분 사람이 익숙한 수준의 보장은 아니다. 또한 처리량 측면에서 확장성이 더 우수하더라도 간단한 쿼리인 경우에도 지연 측면에서 느린 경우가 많다. (예: 몽고DB, 아마존 도큐먼트DB)
 
  • 열 저장소 : 조회 속도가 키-값 저장소만큼 빠르며 더 복잡한 데이터 구조를 저장할 수 있다. 그러나 3개 테이블(RDBMS 용어) 또는 3개의 컬렉션(몽고DB 용어)의 조인과 같은 작업은 좋게 말해서 매우 불편하다. 시계열 데이터에 적합하다. (1:00pm부터 2:00pm 사이에 일어나는 모든 정보 찾기 등)

그 외의 더 틈새 지향적인 NoSQL 데이터베이스도 있다. 그러나 이러한 모든 데이터베이스의 공통점은 공통 데이터베이스 언어를 지원하지 않고 “특수 목적”에 초점을 두는 경향이 있다는 것이다. 인기 있는 몇몇 NoSQL 데이터베이스(예를 들어 몽고DB)에는 좋은 데이터베이스 프론트엔드와 생태계 툴이 있어서 개발자들에게 유용하지만, 탄력성과 확장성 측면의 제약은 말할 필요도 없고, 스토리지 엔진에도 심각한 제약이 있다.
 

데이터베이스 표준은 여전히 중요하다

관계형 데이터베이스가 지배적으로 사용된 이유 중 하나는 공통된 툴 생태계다. 우선 SQL이 있었다. 변형 언어(dialect)는 다를 수 있지만(개발자 또는 분석가가 SQL 서버 6.5에서 오라클 7로 전환한다면, 쿼리를 수정해 외부 조인에 “(+)”를 사용해야 함) 간단한 것은 잘 동작하고 난해한 부분도 큰 어려움 없이 변환할 수 있었다.

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

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

Copyright © 2024 International Data Group. All rights reserved.