2016.01.07

기고 | NoSQL의 '숨은 비용' 이야기

Gary Orenstein | Network World
*본 기고문은 벤더가 작성한 것으로 네트워크 월드 편집진의 수정을 거쳤다. 그러나 벤더의 시각이 일부 남아 있을 수 있다.


이미지 출처 : Thinkstock

NoSQL은 강력한 데이터 모델이지만 많은 다른 독립적인 데이터스토어를 평정하기에는 부족한 점이 있다.

NoSQL 산업은 스키마(schema)에서 자유로운 설계, 무한한 클러스터 확장성, 탁월한 성능을 무기로 가파른 성장세를 이어왔다. 하지만 많은 이들은 여기에 적잖은 숨겨진 비용이 존재한다는 사실을 간과하고 있는 것이 현실이다. 데이터스토어의 무한 선택권(현재 225개)에서 오는 복잡성, 사용자에게 결과 산출물을 미리 요구한 결과 자주 발생하는 쿼리 지연, 하드웨어 이용의 비효율에서 야기되는 서버 확산 등이 바로 숨은 비용의 사례들이다.

꿈에 부풀어 NoSQL의 세계로 뛰어든 많은 기업들이 이러한 비용 앞에서 당황하곤 한다. 물론 특정 워크로드에 있어서는 NoSQL 데이터 모델이 핵심 가치와 데이터 유형 기술 전반에 있어 유효한 모델임이 분명하다. 또 이제는 NoSQL 데이터 모델을 멀티-모드, 멀티-모델 데이터베이스와 통합해 데이터 관리 방법론을 좀더 간소화해 하나로 만드는 경우를 발견하기도 한다.

이제 NoSQL의 진짜 모습에 관해, 그리고 SQL을 포기하는 당신의 결정이 옳은 지에 관해 이야기 해보자.

NoSQL 운동의 시작과 쇠퇴
NoSQL의 성장을 견인한 것은 전통적인 디스크 기반 관계형 데이터베이스가 다룰 수 있는 범위를 벗어난 확장성에 대한 수요와, 대형 DBMS 업체들의 고가 정책에 대한 불만이었다. 데이터의 성장 추세 속에서 개발자들은 사용자, 프로필 정보 등 모바일 애플리케이션과 관계된 단순한 데이터 구조의 이용이 늘어나게 됐고, 이를 이용할 더 나은 방안을 모색하게 됐다. 이런 고민 속에 NoSQL은 만족스런 성능을 보장하는 간편한 경로를 약속하는 존재로 등장했다.

NoSQL에 대한 시장의 지지는 한편으론 SQL은 배우기 어렵다는 인식에서 기인한 측면도 있다. 하지만 퍼펫 랩스(Puppet Labs)의 엔지니어링 디렉터인 마이클 스탱크는 이것이 초기의 부적절한 주장이라며, “실제로는 어떤 툴을 이용하더라도 각각에 따른 하나의 쿼리 언어를 배워야 한다"라고 언급했다.

SQL은 배우기 어렵다는 (초기의 그릇된) 인식이 NoSQL을 탄생시켰다. 그러나 실제로는 어떤 툴을 이용하더라도 그들 각각에 따른 하나의 쿼리 언어를 배워야 한다. #실패

— 마이클 스탱크(@stahnma) 2015. 03. 17


최근 몇 년 사이 일어난 몇 가지 변화는 NoSQL이 전반적인 데이터베이스 시장에 녹아 들도록 하는 동인이 됐다.

가장 먼저, 인메모리 아키텍처를 통해 성능과 SQL의 양립 가능성이 입증됨에 따라, 초기 SQL의 발목을 잡던 문제가 해결됐다.

다음으로, 대부분의 NoSQL 데이터스토어들이 핵심/밸류 워크로드와 관련한 언어의 한계를 드러내기 시작했으며, 이어 보다 SQL에 가까운 구조, 혹은 SQL 자체를 재창조하려는 시도가 전개됐다. SQL을 출발지점으로 삼는다는 것은 다중 버전 동시 통제(MVCC, Multi-Version Concurrency Control)나 인덱스 같은 핵심 아키텍처 기능들(모두 변화하는 데이터 셋의 실시간 분석 작업에 꼭 필요한 기능들이다)을 통합한다는 것을 의미한다.

끝으로 관계형 데이터베이스 업체들이 복수 데이터 모델들을 포괄적으로 제공하며 통합해 그것의 가치를 인지하기 시작했다는 점 역시 주요한 변화다.
 


NoSQL의 쇠퇴에 관해서는 가트너가 명쾌하게 정리한 바 있다: “2017년이면 데이터베이스 관리 시스템(DBMS)을 차별화하는 수단으로 ‘NoSQL’이라는 라벨이 지니는 힘은 사라지게 될 것이다. NoSQL의 가치는 줄어들 것이고, 사용자 규모도 감소할 것으로 전망된다.” (데이터버시티(Dataversity) 인용)

 




2016.01.07

기고 | NoSQL의 '숨은 비용' 이야기

Gary Orenstein | Network World
*본 기고문은 벤더가 작성한 것으로 네트워크 월드 편집진의 수정을 거쳤다. 그러나 벤더의 시각이 일부 남아 있을 수 있다.


이미지 출처 : Thinkstock

NoSQL은 강력한 데이터 모델이지만 많은 다른 독립적인 데이터스토어를 평정하기에는 부족한 점이 있다.

NoSQL 산업은 스키마(schema)에서 자유로운 설계, 무한한 클러스터 확장성, 탁월한 성능을 무기로 가파른 성장세를 이어왔다. 하지만 많은 이들은 여기에 적잖은 숨겨진 비용이 존재한다는 사실을 간과하고 있는 것이 현실이다. 데이터스토어의 무한 선택권(현재 225개)에서 오는 복잡성, 사용자에게 결과 산출물을 미리 요구한 결과 자주 발생하는 쿼리 지연, 하드웨어 이용의 비효율에서 야기되는 서버 확산 등이 바로 숨은 비용의 사례들이다.

꿈에 부풀어 NoSQL의 세계로 뛰어든 많은 기업들이 이러한 비용 앞에서 당황하곤 한다. 물론 특정 워크로드에 있어서는 NoSQL 데이터 모델이 핵심 가치와 데이터 유형 기술 전반에 있어 유효한 모델임이 분명하다. 또 이제는 NoSQL 데이터 모델을 멀티-모드, 멀티-모델 데이터베이스와 통합해 데이터 관리 방법론을 좀더 간소화해 하나로 만드는 경우를 발견하기도 한다.

이제 NoSQL의 진짜 모습에 관해, 그리고 SQL을 포기하는 당신의 결정이 옳은 지에 관해 이야기 해보자.

NoSQL 운동의 시작과 쇠퇴
NoSQL의 성장을 견인한 것은 전통적인 디스크 기반 관계형 데이터베이스가 다룰 수 있는 범위를 벗어난 확장성에 대한 수요와, 대형 DBMS 업체들의 고가 정책에 대한 불만이었다. 데이터의 성장 추세 속에서 개발자들은 사용자, 프로필 정보 등 모바일 애플리케이션과 관계된 단순한 데이터 구조의 이용이 늘어나게 됐고, 이를 이용할 더 나은 방안을 모색하게 됐다. 이런 고민 속에 NoSQL은 만족스런 성능을 보장하는 간편한 경로를 약속하는 존재로 등장했다.

NoSQL에 대한 시장의 지지는 한편으론 SQL은 배우기 어렵다는 인식에서 기인한 측면도 있다. 하지만 퍼펫 랩스(Puppet Labs)의 엔지니어링 디렉터인 마이클 스탱크는 이것이 초기의 부적절한 주장이라며, “실제로는 어떤 툴을 이용하더라도 각각에 따른 하나의 쿼리 언어를 배워야 한다"라고 언급했다.

SQL은 배우기 어렵다는 (초기의 그릇된) 인식이 NoSQL을 탄생시켰다. 그러나 실제로는 어떤 툴을 이용하더라도 그들 각각에 따른 하나의 쿼리 언어를 배워야 한다. #실패

— 마이클 스탱크(@stahnma) 2015. 03. 17


최근 몇 년 사이 일어난 몇 가지 변화는 NoSQL이 전반적인 데이터베이스 시장에 녹아 들도록 하는 동인이 됐다.

가장 먼저, 인메모리 아키텍처를 통해 성능과 SQL의 양립 가능성이 입증됨에 따라, 초기 SQL의 발목을 잡던 문제가 해결됐다.

다음으로, 대부분의 NoSQL 데이터스토어들이 핵심/밸류 워크로드와 관련한 언어의 한계를 드러내기 시작했으며, 이어 보다 SQL에 가까운 구조, 혹은 SQL 자체를 재창조하려는 시도가 전개됐다. SQL을 출발지점으로 삼는다는 것은 다중 버전 동시 통제(MVCC, Multi-Version Concurrency Control)나 인덱스 같은 핵심 아키텍처 기능들(모두 변화하는 데이터 셋의 실시간 분석 작업에 꼭 필요한 기능들이다)을 통합한다는 것을 의미한다.

끝으로 관계형 데이터베이스 업체들이 복수 데이터 모델들을 포괄적으로 제공하며 통합해 그것의 가치를 인지하기 시작했다는 점 역시 주요한 변화다.
 


NoSQL의 쇠퇴에 관해서는 가트너가 명쾌하게 정리한 바 있다: “2017년이면 데이터베이스 관리 시스템(DBMS)을 차별화하는 수단으로 ‘NoSQL’이라는 라벨이 지니는 힘은 사라지게 될 것이다. NoSQL의 가치는 줄어들 것이고, 사용자 규모도 감소할 것으로 전망된다.” (데이터버시티(Dataversity) 인용)

 


X