NoSQL 문서 원본 보기

말 그대로 No [[SQL]], 즉 '[[SQL]]을 안 쓴다'는 뜻으로 해석할 수 있다. [[SQL]]을 활용할 수도 있다는 뜻으로 'Not Only [[SQL]]'을 뜻한다고 주장하기도 하지만, 사실 NoSQL 데이터베이스들이 [[SQL]] 기반의 [[관계형 데이터베이스]]와는 한참 동떨어져 있다 보니, 이런 [[데이터베이스]]를 쓰다 보면 [[SQL]]을 뭐하러 쓰지? 싶은 생각이 든다.

[[빅데이터]] 시대가 되면서 특히 NoSQL이 주목 받고 있다. [[빅데이터]]는 데이터의 양도 엄청나지만 데이터의 형태가 정형화되어  있지 않고 워낙에 변화무쌍한 것들이 많아서 데이터 구조의 일관성을 중시하는 [[관계형 데이터베이스]]에서는 까다로운 부분이 많다. 반면 NoSQL은 일관성을 크게 강제하지 않기 때문에 들어오는 대로 일단 막 집어넣고 볼 수 있다. 

데이터의 일관성은 관계형 데이터베이스가 가진 데이터의 무결성과 같은 장점을 보장하지만, 어떤 때에는 데이터의 처리를 까다롭게 만들고 경직되게 만드는 원인이기도 하다. 주소를 예로 들어 보자. 우리나라의 과거 형태 주소, 즉 지번 기반 주소를 외국의 도로명 기준 주소와 비교하면 다음과 같다.

* 지번 주소 : 시/도, 구, 동, 번지, 세부주소
* 외국의 도로명 주소 : 주, 시, 도로명, 건물번호, 세부주소

이게 다가 아닐 것이다. 어떤 나라는 또 다른 요소로 구성된 주소를 쓸 수도 있다. 만약 국제적인 쇼핑몰이라면 어떤 식으로 된 주소든 다 받아줘야 하는데, 나라마다 주소 체계가 제각각일 때 이를 받아주려면 테이블에 이들 모든 요소가 다 속성으로 정의되어 있는 테이블을 짜고, 각 튜플마다 필요 없는 속성은 비우는 식으로 처리해야 한다. 위의 주소 예라면, 

{| class="wikitable"
|-
! !! 주 !! 시/도 !! 구 !! 동 !! 도로명 !! 번지/건물번호 !! 세부주소
|-
| 지번 주소 || — || 서울시 || 영등포구 || 여의도동 || — || 1-1 || 내위키아파트 101호
|-
| 도로명 주소 || Victoria || Melbourne || — || — || Bourke Street || 1 || 1F
|}

<del>국제적으로 주소를 저장하려면 나라 이름도 저장해야 할 텐데? 넘어갑시다.</del>

그런데 한국은 아파트를 무지 좋아하는데, 아파트 이름을 그냥 세부주소에 다 퉁쳐서 저장하는 것은 나중에 검색이나 분류를 할 때 좋지 않다. 그래서 아파트는 따로 분리하는 게 좋을 것 같다. 이렇게 각국의 특성에 맞춰서 주소 스키마를 짜려면 밑도 끝도 없다. 나름대로 최대한 고려해서 크고 아름다운 테이블을 만들었는데 나중에 가서 또 다른 나라의 가입자를 받아야 하고 주소 체계가 다르다는 사실을 알게 되면 대략 [[멘붕]] 상태에 빠지게 된다.

반면 NoSQL은 미리 스키마를 짜놓고 딱 그에 맞게 데이터를 넣는 게 아니라, 데이터를 넣다가 분명 이 범주에 들어가야 할 데이터인데 구성 요소가 다르다면 그냥 그에 맞는 새 속성(필드)을 정의해서 새로 밀어넣을 수 있다. 그렇다고 기존 데이터에 새로운 필드가 추가되지도 않는다. 즉 데이터 구조의 일관성을 강제하지 않는다.

가장 큰 문제라면 [[SQL]]처럼 뭔가 일관된 인터페이스가 없다 보니, [[데이터베이스]] 제품별로 데이터를 넣고 빼고 가져오는 방법이 제각각이라는 것. 물론 SQL 기반 데이터베이스들도 자체 기능을 사용하기 위해서 표준에서 벗어난 구문들이 종종 추가되지만 그래도 [[SQL]]이라는 뼈대 위에 추가되는 형태인데 반해, NoSQL은 정말 제각각이다. 게다가 일관된 스키마를 강제하지도 않다 보니, 어떤 제품을 쓰다가 다른 제품으로 전환해야 할 때에는 특히나 마이그레이션 과정이 [[관계형 데이터베이스]]와는 비교도 할 수 없이 돌아버릴 수 있다.

[[관계형 데이터베이스]]에 익숙해 있던 사람들이 가장 돌아버리는 것은 무결성 문제로, 이를테면 NoSQL은 외래 키 개념이 없다. 예를 들어 [[관계형 데이터베이스]]는 테이블 b를 정의할 때 특정 속성이 테이블 a의 키값이 되도록 정의할 수 있으며, 만약 이 속성에 a의 키값이 아닌 다른 값이 들어 있는 데이터를 테이블 b에 집어넣으려고 하면 거부한다. NoSQL은 이런 거 없다. 그냥 다 받아준다. 또한 [[관계형 데이터베이스]]는 테이블 b에서 키값으로 쓰이고 있는 테이블 a의 어떤 튜플을 삭제하려고 하면 이 역시 거부한다. 먼저 테이블 b에서 해당 튜플을 지워야 한다. NoSQL은 이런 없다. 그렇기 때문에 무결성이 중요한 데이터라면 NoSQL이 오히려 지옥이 될 수 있다.

=종류=

* 문서 기반 : [[몽고DB]], [[카우치베이스]]