*본 기고문은 벤더가 작성한 것으로 네트워크 월드 편집진의 수정을 거쳤다. 그러나 벤더의 시각이 일부 남아 있을 수 있다.
NoSQL은 강력한 데이터 모델이지만 많은 다른 독립적인 데이터스토어를 평정하기에는 부족한 점이 있다.
NoSQL 산업은 스키마(schema)에서 자유로운 설계, 무한한 클러스터 확장성, 탁월한 성능을 무기로 가파른 성장세를 이어왔다. 하지만 많은 이들은 여기에 적잖은 숨겨진 비용이 존재한다는 사실을 간과하고 있는 것이 현실이다. 데이터스토어의 무한 선택권(현재 225개)에서 오는 복잡성, 사용자에게 결과 산출물을 미리 요구한 결과 자주 발생하는 쿼리 지연, 하드웨어 이용의 비효율에서 야기되는 서버 확산 등이 바로 숨은 비용의 사례들이다.
꿈에 부풀어 NoSQL의 세계로 뛰어든 많은 기업들이 이러한 비용 앞에서 당황하곤 한다. 물론 특정 워크로드에 있어서는 NoSQL 데이터 모델이 핵심 가치와 데이터 유형 기술 전반에 있어 유효한 모델임이 분명하다. 또 이제는 NoSQL 데이터 모델을 멀티-모드, 멀티-모델 데이터베이스와 통합해 데이터 관리 방법론을 좀더 간소화해 하나로 만드는 경우를 발견하기도 한다.
이제 NoSQL의 진짜 모습에 관해, 그리고 SQL을 포기하는 당신의 결정이 옳은 지에 관해 이야기 해보자.
NoSQL 운동의 시작과 쇠퇴
NoSQL의 성장을 견인한 것은 전통적인 디스크 기반 관계형 데이터베이스가 다룰 수 있는 범위를 벗어난 확장성에 대한 수요와, 대형 DBMS 업체들의 고가 정책에 대한 불만이었다. 데이터의 성장 추세 속에서 개발자들은 사용자, 프로필 정보 등 모바일 애플리케이션과 관계된 단순한 데이터 구조의 이용이 늘어나게 됐고, 이를 이용할 더 나은 방안을 모색하게 됐다. 이런 고민 속에 NoSQL은 만족스런 성능을 보장하는 간편한 경로를 약속하는 존재로 등장했다.
NoSQL에 대한 시장의 지지는 한편으론 SQL은 배우기 어렵다는 인식에서 기인한 측면도 있다. 하지만 퍼펫 랩스(Puppet Labs)의 엔지니어링 디렉터인 마이클 스탱크는 이것이 초기의 부적절한 주장이라며, “실제로는 어떤 툴을 이용하더라도 각각에 따른 하나의 쿼리 언어를 배워야 한다”라고 언급했다.
최근 몇 년 사이 일어난 몇 가지 변화는 NoSQL이 전반적인 데이터베이스 시장에 녹아 들도록 하는 동인이 됐다.
가장 먼저, 인메모리 아키텍처를 통해 성능과 SQL의 양립 가능성이 입증됨에 따라, 초기 SQL의 발목을 잡던 문제가 해결됐다.
다음으로, 대부분의 NoSQL 데이터스토어들이 핵심/밸류 워크로드와 관련한 언어의 한계를 드러내기 시작했으며, 이어 보다 SQL에 가까운 구조, 혹은 SQL 자체를 재창조하려는 시도가 전개됐다. SQL을 출발지점으로 삼는다는 것은 다중 버전 동시 통제(MVCC, Multi-Version Concurrency Control)나 인덱스 같은 핵심 아키텍처 기능들(모두 변화하는 데이터 셋의 실시간 분석 작업에 꼭 필요한 기능들이다)을 통합한다는 것을 의미한다.
끝으로 관계형 데이터베이스 업체들이 복수 데이터 모델들을 포괄적으로 제공하며 통합해 그것의 가치를 인지하기 시작했다는 점 역시 주요한 변화다.
NoSQL의 쇠퇴에 관해서는 가트너가 명쾌하게 정리한 바 있다: “2017년이면 데이터베이스 관리 시스템(DBMS)을 차별화하는 수단으로 ‘NoSQL’이라는 라벨이 지니는 힘은 사라지게 될 것이다. NoSQL의 가치는 줄어들 것이고, 사용자 규모도 감소할 것으로 전망된다.”
SQL의 가치
역설적이게도, NoSQL에 대한 이러한 열풍에 이어 기업 및 데이터스토어들에게 레이어형 SQL(SQL-as-a-layer)의 가치가 높아졌다. 임팔라(클라우데라), 드릴(맵R), 하이브(호튼웍스)같은 프로젝트나, 페이스북의 프레스토(Presto)같은 솔루션을 통해 레이어형 SQL 하둡으로부터 데이터를 레스큐잉(rescuing) 하는 방식을 살펴보면 이를 이해할 수 있겠다.
또 스파크 SQL 기능을 갖춘 스파크 등의 프로세싱 프레임워크도 문서화와 핵심 가치 데이터스토어의 구세주로 등장해 SQL의 가치를 다시 한 번 확인하였다.
한편 인메모리 분산 시스템은 관계형 모델(relational model)을 온전히 유지하면서 워크로드를 감당할 수 있는 확장성과 성능을 구현할 수 있었으며, JSON 같은 NoSQL 데이터 형태를 포함할 수 있었다.
멀티-모델 데이터베이스여 영원하라
물론 NoSQL의 인기가 시들해졌다고 해서 NoSQL 모델 자체가 끝난 건 아니다. 그보다는 단일 데이터베이스 내에서 멀티 데이터 모델을 사용하는 경우가 많다는 의미일 것이다. 최근 451 리서치(451 Research)의 데이터 플랫폼 및 애널리틱스 리서치 디렉터인 맷 애슬렛도 사물인터넷 및 멀티 모델 데이터 인프라 관련 웹캐스트를 통해 다음과 같이 말한 바 있다.
• 데이터베이스 시장은 40년 넘게 관계형 데이터베이스 모델(그리고 SQL)이 장악해왔다. 운영 워크로드와 애널리틱스 워크로드 데이터베이스가 분리된 것이 일반적이었다.
• 새로운 데이터베이스는 인메모리와 프로세싱 성능 향상을 활용해 통합된 운영과 분석 처리 과정을 가능케 한다.
• 다수 언어에 대한 고집으로 NoSQL 데이터베이스 시장이 확장될 수 있었다. 이는 멀티 데이터 모델과 전문적 목적을 위한, 전문가를 위한 데이터베이스였다.
• 개별 애플리케이션을 지원하기 위해 복수의 데이터베이스를 사용하게 되면 상호의존적 성격이 강해져 유연성은 떨어지고 운영은 복잡해진다.
• 멀티 모델은 이러한 다수 언어에 대한 고집으로 야기될 수 있는 단점들에 유연성을 보완해주면서도 멀티 데이터 모델을 지원함으로써 운영상의 복잡성을 피했다.
아래의 그림은 멀티-모델, 멀티모드 데이터베이스가 어떻게 SQL과 NoSQL 데이터 모델의 결합을, 특히 JSON 및 핵심 가치, 그리고 기타 다른 워크로드 등을 지원하는지 잘 보여준다.
숨은 비용 계산하기
NoSQL은 분명 합리적인 비용으로 확장성과 성능을 누릴 수 있는 가치 있는 솔루션이다. 그러나 NoSQL을 개발하는 과정에 소요되는 비용을 따져보면 과연 이것이 진정 경제적인 해법인지에 의문이 가는 것도 사실이다. 여기 NoSQL의 숨은 비용들을 살펴보자.
*복잡성의 증대. 451 리서치의 애슬렛이 인용한 바에 따르면, NoSQL은 “개별 애플리케이션을 지원하는데 복수의 데이터베이스를 이용함으로써 운영 복잡도를 증가시킨다.”
새로운 데이터베이스의 추가는 데이터 팀에 재무, 운영적 부담을 안겨주는 요인이다.
*분석의 제약. SQL이 내포하고 있는 관계 대수를 포기함으로써 NoSQL 스토어는 분석에서는 한계를 지니게 됐다. 많은 NoSQL 스토어들이 카산드라 쿼리 언어(CQL, Cassandra Query Language)나 카우치베이스(Couchbase)용 N1QL 등 SQL형 쿼리 레이어를 시행하는 것도 이러한 한계 때문이다. 이러한 레이어를 통해 일부 분석 기능을 사용할 수는 있지만, ANSI SQL과 같은 수준의 것은 아니며, 또한 데이터스토어들이 SQL을 이용하는 기업용 툴들에 자연적으로 연결되는 것에도 제약을 준다. SQL과 같은 공개 표준을 중심으로 설계를 전개하는 기업들이라면 이런 분기 방식은 지양하는 것이 좋다.
참고로 본 기고문을 작성하며 필자는 실제 최종 사용자들과 많은 대화를 나눴다. 그들과의 대화는 필자에게도 NoSQL을 사용하며 겪게 되는 분석과 관련한 딜레마를 체감하는 기회가 됐다.
*쿼리 지연. 매우 복잡한 분석은 NoSQL 데이터스토어에는 매우 까다로운 과제가 될 수 있으며, 따라서 많은 기업들은 결과의 사전 산출을 강요 받게 된다. 탭조이(Tapjoy)는 H베이스(Hbase)의 사례에서 이런 문제를 포착했고, 샌프란시스코에서 치러진 인메모리 컴퓨팅 컨퍼런스 기간 중 진행된 그들의 프레젠테이션 섹션에서 그들의 사례를 소개했다. 이 배치 프로세싱(batch processing) 워크플로는 시스템 지연을 야기했고, 데이터의 비즈니스 가치를 떨어뜨리는 원인이 되기도 했다. 배치 지향 워크플로에서 도출되는 결과물은 불가피하게 시각 차이를 내제하며, 실시간 분석을 제공하는 것이 불가능하다.
*하드웨어 확산. 확장, 특히 클러스터 내 노드 수를 확장하는 과정은 명예의 훈장이 될 수 있다. 그것의 목표는 얼마나 많은 수의 노드를 배치하는지가 아닌, 얼마나 적은 수의 노드를 배치하는지에 달린 문제다. 이보다 더 중요한 것은 각 노드들의 트랜잭션 효율성이다. NoSQL 솔루션에 추가적 SQL 레이어를 덧붙여야 하거나 쿼리 구동 전 사전 산출을 반드시 완료해야 하는 상황에서, 이는 하드웨어 확산, 그리고 결과적으로 비용 증대를 야기한다.
* 모델은 유지하고, 워크로드는 통합. 다른 옵션도 존재한다. 최근 가트너는 이것을 ‘아방-가르드 관계형 데이터베이스’라 부르기도 했는데, 대게 인메모리 테크놀로지를 통해 SQL의 관계형 특성을 활용한 솔루션을 제공한다. 이러한 아방가르드 데이터베이스들은 상당수가 JSON같은 데이터도 포함하고 있어 정형/비정형 데이터를 위한 데이터 모델도 제공한다.
오늘날 고객들도 NoSQL을 대체할 새롭고, 더 저렴한 솔루션처럼 보였던 것이 사실은 생각보다 더 많은 비용을 초래하는 솔루션이었음을 깨닫고 있다. 다행히도, 하나의 솔루션으로 포괄적 SQL 분석과 필요한 성능을 모두 충족시킬 수 있는 데이터베이스 덕분에 이러한 문제를 해결할 수 있게 됐지만 말이다.
빅데이터 업계도 기업들이 데이터를 수집하고 처리하는 방식에서 일대 혁명이 일어날 것임을 눈치채고 있다. 하지만 이러한 분위기는 무엇보다도 빅데이터 관련 저명한 대변인인 그웬 샤피라의 말로 가장 잘 요약될 수 있을 것이다.
이 트윗은 단 한 줄로 NoSQL과 관련된 변화를 잘 보여준다. 스키마 없는 데이터 관리 옵션이 마치 만병통치약처럼 보였지만, 현실은 이와는 꽤 대조적이었다. 오히려 많은 이들이 오랜 세월에 걸쳐 입증된 구조와 스키마, 그리고 SQL의 가치를 다시금 깨닫고 있기 때문이다.
*Gary Orenstein은 MemSQL의 CMO다. dl-ciokorea@foundryco.com
