[NoSQL: 빅 데이터 세상으로 떠나는 간결한 안내서] 1장. 왜 NoSQL인가?

1장. 왜 NoSQL인가?

 

요점

- 관계형 데이터베이스는 20년 이상 성공적인 기술이고 지속성, 동시성 제어, 통합 메커니즘을 제공한다.
- 애플리케이션 개발자는 관계형 모델과 메모리 내 데이터 구조 간의 객체-관계 불일치로 불만이 많다.
- 데이터베이스를 통합점으로 사용하는 방식에서 데이터베이스를 애플리케이션 안에 캡슐화하고 서비스를 통해 통합하는 방식으로 이동하려는 움직임이 있다.
- 데이터 저장소 변화의 중요 요인은 클러스터에서 실행되는 엄청난 양의 데이터를 지원해야 한다는 점이었다. 관계형 데이터베이스는 클러스터에서 효율적으로 동작하도록 설계되지 않았다.
- NoSQL은 우여한 신조어다. 규정된 정의도 없다. 공통 특징을 살펴볼 수밖에 없다.
- NoSQL의 공통 특징은 다음과 같다.
  - 관계형 모델을 사용하지 않는다.
  - 클러스터에서 잘 동작한다.
  - 오픈 소스다.
  - 21세기 웹 환경을 위해 구축되었다.
  - 스키마가 없다.
- NoSQL의 등장의 가장 중요한 결과는 다중 저장소 지속성이다.

 

1.1 관계형 데이터베이스의 가치

 

1.1.1 데이터 저장

DB의 가장 명확한 가치는 많은 양의 데이터를 보관하는 것이다.

컴퓨터 아키텍처에는 대부분 두 종료의 저장 장치 개념이 있다.

- 빠르지만 휘발성인 '주 메모리'

- 크지만 느린 '보조 저장소'

 

디스크 같은 보조 저장소에는 파일 시스템과 DB를 이용하여 저장할 수 있다.

엔터프라이즈 애플리케이션에서는 대부분 보조 저장소로 데이터 베이스를 사용한다.

 

1.1.2 동시성

많은 사람이 동시에 같은 데이터를 보고 수정할 수 있다.

관계형 데이터베이스는 트랜잭션을 통해 데이터에 대한 모든 접근을 통제해 이런 문제를 처리하는데 도움을 준다.

트랜잭션은 오류 처리 역할도 한다. 오류가 발생하면 트랜잭션을 롤백할 수 있다.

 

1.1.3 통합

엔터프라이즈 애플리케이션은 여러 애플리케이션간의 협업이 생길 수 있다.

똑같은 데이터를 사용하고, 수정한 데이터가 다른 애플리케이션에서도 보여야 한다.

가장 흔한 방법은 여러 애플리케이션이 한 DB에 데이터를 저장하도록 하는 통합 데이터베이스 공유[Hohpe and Woolf]을 사용한다.  

 

1.1.4 표준 모델

관계형 데이터베이스는 앞에서 설명한 핵심 장점을 가장 표준적인 방법으로 제공해서 성공했다.

그 결과 개발자와 DBA는 관계형 모델의 기본을 여러 프로젝트에 적용할 수 있게 되었다.

벤더가 달라도 SQL 구문은 거의 비슷하고, 트랜잭션 동작도 차이 나지 않는다.

 

1.2 객체-관계 불일치

객체-관계 불일치 : 관계형 모델과 메모리 내 데이터 구조 간 차이

관계형 데이터베이스는 장점이 많지만, 완벽하지 않아 초창기부터 많은 불만이 있다.

=> 이는 ORM으로 많이 완화되었다. (아래 TMI 더보기 참조)

 

관계형 튜플 안의 값은 단순해야 하며, 중첩되 레코드나 리스트 등 다른 구조를 포함할 수 없다.

메모리 내 데이터 구조에서는 이런 제약이  없어 관계보다 더 복잡한 구조를 사용할 수 있다.

이 차이로 인하여 복잡한 메모리 내 데이터 구조를 DB에 저장하려면 관계형 표현으로 변환해야 한다.

 

TMI. 객체-관계 불일치는 애플리케이션 개발자에게 가장 큰 불만이었다.

TMI. 객체-관계 불일치는 애플리케이션 개발자에게 가장 큰 불만이었고, 1990년에는 많은 사람이 관계형 데이터베이스가 메모리 내 데이터 구조를 그대로 디스크에 저장하는 새로운 데이터베이스로 대체되리라 믿었다. 이때는 객체 지향 프로그래밍 언어가 성장하던 시기였고, 이와 함께 객체 지향 데이터베이스가 등장했는데, 둘 다 새 천년의 소프트웨어 개발에 지배적 환경이 될 것으로 보였다. 그러나 객체 지향 언어는 성공해 프로그래밍의 주류가 된 반면, 객체 지향 데이터베이스는 세상에서 잊혀졌다. 잘 알려진 매핑 패턴을 구현한 하이버네이트(Hibernate), 아이바티스(iBATIS) 같은 객체-관계 매핑 프레임워크가 널리 사용되면서 객체-관계 불일치는 완화되었지만, 매핑 문제는 여전히 논쟁거리다. 

1.3 애플리케이션 데이터베이스와 통합 데이터베이스

관계형 데이터베이스가 우세였던 이유는 통합 데이터베이스 역할을 했다.

여러 팀에서 다양한 애플리케이션을 개발했고, 공통 데이터베이스에 데이터를 제정했다.

모든 애플리케이션이 일관된 데이터 집합을 가지고 동작해서 커뮤니케이션이 향상되었다.

 

이는 불리한 점도 있다. 여러 애플리케이션을 통합하려고 설계하나 구조는 훨씬 복잡해지기 마련이다.

애플리케이션마다 구조와 성능 요건이 다르다. (인덱스 방식 등)

 

1.4 클러스터의 공격

수평 확장 : 더 큰 장비, 더 많은 프로세서, 디스크 스토리지, 메모리
수직 확장 : 작은 장비를 많이 모아 클러스터 구성

2000년대부터 웹의 규모가 극적으로 성장하면서 웹 사이트 사용자 활동 추적을 위해 링크, 소셜 네트워크 활동 로그, 매핑 데이터 같은 대규모 데이터 집합이 나타났다. 사용자 수가 늘면서 데이터 양도 커졌다. 이에 더 많은 컴퓨팅 자원이 필요해졌다. 이를 처리하기 위해 수평 확장과 수직 확장을 할 수 있다.

 

하지만 데이터베이스는 클러스터에서 동작하지 않도록 설계되어 문제점이 따라왔다.

TMI. 문제점이 발생한 이유

오라클 RAC나 마이크로소프트 SQL 서버 같은 클러스터 관계형 데이터베이스는 공유 디스크 개념을 사용한다. 클러스터를 인식할 수 있는 파일 시스템을 사용해 고가용성 디스크 서브시스템에 데이터를 기록하는데 이는 클러스터의 디스크 서브시스템이 단일 고장점이 됨을 뜻한다. 물론 데이터 집합을 분리하고 각 데이터 집합을 별도 서버에서 처리하도록 샤딩 할 수 있다. 이렇게 하면 부하 분산을 할 수 잇지만, 애플리케이션에서 모든 샤딩을 제어해야 한다. 즉, 어떤 데이터를 어느 데이터베이스 서버에서 처리해야 하는지 애플리케이션에서 파악해야 한다. 또 여러 샤드에 걸치는 쿼리나 참조 정합성, 트랜잭션, 일관성 제어 같은 것은 또 물건너간다. 이는 '부자연스럽다'는 것이다.

이런 기술적 문제는 라이선싱 비용으로 더욱 악화된다. 상용 관계형 데이터베이스는 보통 단일 서버를 가정해 가격이 책정되므로, 클러스터에서 실행하려면 비용이 많이 든다.

 

구글의 빅 테이블, 아마존의 다이나모

관계형 데이터베이스와 클러스터 간의 부조화로 다른 대안을 고려하기 시작했다.

특히 구글과 아마존이 중대한 역할을 했는데, 두 회사 모두 대규모 클러스터 운영의 선두에 있다.

 

1.5 NoSQL의 출현

제대로 정의되지 않았지만 대부분이 오픈 소스고 21세기 초반에 개발되었으며 SQL을 사용하지 않는 데이터베이스

1990년대 후반 오픈 소스 관계형 데이터베이스[Strozzi NoSQL]에서  'NoSQL' 용어가 처음 등장하였다.

이 데이터베이스는 테잉블을 아스키 파일에 저장했고, 각 튜플은 탭으로 분리된 필드의 행으로 표현했다.

이 데이터베이스에서는 질의어로 SQL을 사용하지 않는다는 이유로 NoSQL 이라는 이름이 붙었다.

 

Strozzi NoSQL와 NoSQL이란 용어의 유래에 대해 더 알아보자.

이 데이터베이스에서는 유닉스 파이프라인으로 조합할 수 있는 셸 스크립트를 통해 조작이 이루어졌다. 용어가 우연히 일치한 것을 제외하면, 스트로치의 NoSQL은 이 책에서 설명하는 데이터베이스에 아무런 영향도 끼치지 못했다.

우리가 인식하는 NoSQL이란 용어 사용의 기원은 런던 출신 소프트웨어 개발자 조핸 오스카슨(Johan Oskarsson)이 2009년 6월 11일 샌프란시스코에서 조직한 비공식적모임으로 거술러 올라간다. 빅 테이블과 다이나모의 예는 대안 데이터 저장소를 실험하는 여러 프로젝트에 영감을 주었고, 이에 대한 논의는 당좋은 소프트웨어 컨퍼런스의 특지이 되기도 했다. 조핸은 하둡 서밋을 위해 샌프란시스코에 와 있는 동안 이런 새로운 종류의 데이터베이스에 대해 더 많이 알고 싶었다. 그는 시간이 많지 않았기 때문에, 관심 있는 사람은 누구나 참석해 한자리에 모여 자신의 작업을 발표할 수 있도록 비공식적 모임을 주관하기로 했다. 조핸은 모임의 이름을 짓고 싶었는데, 트위터 해시 태그로 쓰기 좋고, 짧고 기억하기 쉽지만, 구글 검색 결과가 너무 많지 않고 검색하면 빠르게 찾을 수 있는 그런 이름을 원했다.

그는 #cassandra IRC 채널에 제안을 요청해 몇 가지 제안을 받았고, 그중 에릭 에반스가 제안한 'NoSQL'을 선택했다.

그 당시는 그저 모임 이름을 생각했을 뿐이었고, 기술 동향 전체를 나타내는 이름으로 유행하리라고는 예상하지 못했다.

 

아래 Strozzi NoSQL 예시는 Wikipedia에서 발췌하였다.

employees 테이블 조회 예시

- SQL

select e.*, a.*, mgr.* from EMPLOYEES e, ADDRESSES a, MANAGERS mgr
WHERE .....

 

- document-oriented NoSQL 

$e = doc("/employee/emp_1234")
return $e/address/zip

 

NoSQL이란 용어는 정확하게 정의된 적이 없다.

모임을 위한 원래의 요청은 '오픈 소스, 분산, 비관계형 데이터베이스'를 위한 이름이였다.

분명한 점은, NoSQL 데이터베이스는 SQL을 사용하지 않는 것이다.

또 다른 주요 특징은 보통 오픈 소스 프로젝트라는 점이다.

 

NoSQL 데이터베이스는 대부분 클러스터에서 실행할 목적으로 만들어졌으며,

일관성에 대한 접근 방법뿐 아니라 데이터 모델에도 영향을 끼쳤다.

 

관계형 데이터베이스는 일관성을 위해 ACID 트랜잭션을 사용한다. 이는 클러스터 환경과 맞지 않다.

NoSQL 데이터베이스는 일관성과 분산에 관해 여러 종류의 선택 사양을 제공한다.

 

그러나 모든 NoSQL 데이터베이스가 클러스터에서 실행되도록 맞춰지지는 않았다.

그래프 데이터베이스는 NoSQL 데이터베이스의 한 형태로 관계형 데이터베이스와 비슷한 분산 모델을 사용하지만 복잡한 관계의 데이터 처리에 유리한 다른 데이터 모델을 제공한다.

 

대부분 NoSQL의 실제 뜻이 "Not Only SQL"이라고 하지만, 몇 가지 문제가 있다.

Not Only SQL이 맞다면 "NOSQL"로 써야 한다. 또한 'not only'의 뜻으로 뭔가를 NoSQL 데이터베이스라 부른다 한들 아무런 의미도 없다. 그런 식이라면 오라클이나 포스트그레스도 이 정의에 맞을 것이다.

 

우리는 NoSQL이 무엇의 약어인지 고민하는 대신 NoSQL이 무엇을 뜻하는지에 집중해야 한다.

=> 제대로 정의되지 않았지만 대부분이 오픈 소스고 21세기 초반에 개발되었으며 SQL을 사용하지 않는 데이터베이스